Subject: Re: [rtcweb] Use Case draft

From: "Jim Barnett" <[email-masked]>
Date: Tue, 1 May 2012 05:05:10 -0700

One way to describe the use case is to let the contact center's media server/gateway serve as the webRTC endpoint.  Then all the issues of call delivery, call monitoring, etc. disappear.  They are handled by application software that sits behind the webRTC endpoint.  The company I work for makes a good living selling software that deals with all these issues - including bathroom breaks - and that's how we would tend to think of this case.  To us, it's a new kind of call/connection coming into the contact center, which we translate into SIP at the border and then handle normally. 

It's not clear to me if this use case adds any extra requirements.  We would just have to be careful not to assume that a webRTC endpoint is always a person/browser-based user agent.  It may seem a bit unsettling that the webRTC endpoint can distribute the call somewhere  else and let others listen in, but as far as I can tell that is already the case.  If Bob calls Alice with full authentication and security, he can be sure that he is connected to Alice's user agent and that no one in between can listen in, but there's nothing stopping Alice from recording the audio, or forwarding it to a third party.  So Bob could in fact be talking to Mary if that's how Alice wants to arrange things (_behind_ her user agent).  In general, Bob is assured only that he is talking to someone Alice wants him to talk to, and that no one can snoop without Alice's permission.  That's very much the way things work with the call center - you are sure that you are 1) connected securely to your bank 2) talking to someone that the bank wants you to talk to 3) being recorded or snooped on only when the bank explicitly chooses to do so.  

- Jim 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marshall Eubanks
Sent: Monday, April 30, 2012 11:42 PM
To: Hutton, Andrew
Cc: [email-masked]
Subject: Re: [rtcweb] Use Case draft

On Mon, Apr 30, 2012 at 2:31 PM, Hutton, Andrew <[email-masked]> wrote:
> Whether anybody has been successful in the past with this type of use 
> case is I think irrelevant.
>
>
>
> The enterprise call centre use case is I think a vital use case 
> because it is a scenario in which one user is only concerned that they 
> can securely reach an organization/domain and is not concerned about 
> the individual within that domain  that they communicate with.  A 
> suspect quite a large percentage of RTCWEB applications will be like 
> this and it is not covered in the current use case draft.

I agree that this is a very useful use case and one I think is going to get a lot of traction. There is a very solid business case for this.  However, I have a fair amount of experience with a video call center for a client, and it is not as simple as it might seem.

The essence of course is that you get the next available person, i.e., it is anycast. Determining who the next available person is is not trivial, nor is error recovery. (If I call you, and you don't answer or the call drops or whatever,  I can leave a message or try later. If I call a help desk, and this happens, I want a new agent, ideally
automatically.) Call forwarding (e.g., first tier to second tier technical support) is essential, and it may be anycast or directed.
There are also some security oddities  - if I am connecting from home, I may need to authenticate, use a credit card, etc. If I am connecting from inside a store, and providing in store video technical support is big part of the market, then the store authenticates me off line and the call really should just be a button push, which implies that the store has previously authenticated some sort of master session. In addition, unlike most video calls, in the enterprise call center a supervisor may need to be able to monitor (i.e., watch) a call, and in some circumstances (financial or medical calls, for example) there will need to be third party recording. I believe that  these details would be different from the typical RTCWEB scenario.

Also, there will be a temptation to do the anycasting by the techniques used to load balance servers in a data center, but I think that may not be sufficient. The call "center" may in fact be spread completely across the planet (daytime support in the US, nighttime support in India, for example) and be on multiple autonomous systems (and even from people's homes), which gives rise to some of the transport issues NVO3 may face, but without any opportunity for packet tagging. Plus, there will complicated rules about who can be selected next. RTCWEB shouldn't worry about the intricacies of bathroom break policies; these complexities should be dealt with by an enterprise-side database, which to me (together with some of the other issues above) suggests that this would probably benefit from  API support.

Regards
Marshall

>
>
>
> So I think we need it.
>
>
>
> Regards
>
> Andy
>
>
>
>
>
>
>
>
>
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Igor Faynberg
> Sent: 30 April 2012 17:41
> To: [email-masked]
>
>
> Subject: Re: [rtcweb] Use Case draft
>
>
>
> Without numbers it is impossible to argue, but, if we talk about the 
> perceived need, I disagree.  Think of the people who travel abroad and 
> cannot call the 800 number. (I routinely use Web interface for calls 
> when
> traveling.)
>
>
>
> I am all for  the use case, as described by Jim.
>
> Igor
>
> On 4/30/2012 9:54 AM, Tim Panton wrote:
>
> ...
>
> I can't tell you the actual numbers, but when presented with the 
> choice of calling a toll free number
>
> or clicking a button marked "free internet call" - almost no-one on a 
> real, busy site clicked the button.
>
> ( for every button click there were several orders of magnitude more 
> 0800 calls from that page).
>
>
>
>
>
> So from my perspective this is a legacy interop use case with almost 
> zero user acceptance.
>
>
>
> (as far as I can see no-one has made this use-case desirable in 
> practice
> yet.)
>
> Tim.
>
>
>
>
>
>
>
> _______________________________________________
>
> rtcweb mailing list
>
> [email-masked]
>
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 1 May 2012 08:33:00 -0400

Dear Jim;

I think that we are mostly in agreement here. One point.

> It's not clear to me if this use case adds any extra requirements.  We would just have to be careful not to assume that a webRTC endpoint is always a person/browser-based user agent.  It may seem a…

The slight difference here is that if I call Alice at home, I have end
to end security (encryption) to Alice and the call only gets recorded
or snooped from her machine. That may not be sufficient in the
distributed call center case - the "supervisor" needs to be able to
monitor _without the cooperation of either end user_.  The threat
model is Alice (on the inside) and Eve (on the outside) are in cahoots
on some bad deed and want to cover their tracks. The call monitoring
should be done outside of Alice's sphere of influence. Say Alice is
working in a SOHO and is alone some of the time. Monitoring /
recording shouldn't rely on any of the equipment under her potential
control, which means it should occur in route, which means you
probably won't really have end to end encryption in this case.

Regards
Marshall

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 1 May 2012 15:14:18 +0200

Hi,

A number of use cases within Draft-ietf-rtcweb-use-cases-and-requirements-07 contain the statement "It is essential that the communication cannot be eavesdropped" however there is no definition of what is actually meant by "eavesdropped" although I think we all have an idea of what it means.

Maybe it would be better to replace these statements with something that refers to wiretapping and RFC 2804 (RAVEN) which actually has a definition of wiretapping.

Regards
Andy

> Behalf Of Ted Hardie
> Sent: 27 April 2012 17:15
> To: [email-masked]
> Subject: [rtcweb] Use Case draft
> 
> The chairs would like to ask the working group to focus on the use
> case draft.  If you have use cases that need to be added to the
> document or text changes you'd like to suggest, please send them in
> for discussion before May 15th.  After this round, we will look toward
> having a working group last call on the document (hopefully before the
> interim meeting).
> 
> regards,
> 
> Ted, Magnus, Cullen

---

From: "Fabio Pietrosanti (naif)" <[email-masked]>
Date: Tue, 01 May 2012 15:26:43 +0200

> Maybe it would be better to replace these statements with something that refers to wiretapping and RFC 2804 (RAVEN) which actually has a definition of wiretapping.

That's a core topic imho, especially because WebRTC would like to make
it appear like carrying on end-to-end security.

If WebRTC provide full end-to-end security no wiretapping should be
possible.

Because WebRTC, from the discussion done in this mailing lists, cannot
satisfy end-to-end security requirements (no wiretapping) in many cases,
then it's highly relevant that the user is aware if the connection is
secured peer-to-peer (so between the end-user-device of the parties that
are talking together) or if there's a gateway in the middle
decrypting/deciphering the call, and so potentially eavesdropping it.

I think that to avoid a "shame" on the reputation of WebRTC, it's very
and highly important to clearly state and explain how/when/who can do
eavesdropping.

At least to know "when" it's end-to-end security and when it's not, in a
clear, unique, identifiable way.

Fabio

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 1 May 2012 07:05:00 -0700

> Maybe it would be better to replace these statements with something that refers to wiretapping and RFC 2804 (RAVEN) which actually has a definition of wiretapping.

This seems like it's creeping into the security requirements question.
Rather than try to make the use cases document more precise, I'd
prefer to have those statements be in draft-ietf-rtcweb-security,
which actually has (or at least is intended to) have fairly precise
descriptions of what the relevant security properties are.

-Ekr

---

From: "Cavigioli, Chris" <[email-masked]>
Date: Tue, 1 May 2012 14:14:41 +0000

Wording needs to be clarified.
- "Eavesdropping" has a negative connotation of someone inappropriately listening in to another communication.  This should not happen.
- "Lawful intercept" is something telecom service providers are required to provide to law enforcement with all appropriate safeguards in place http://en.wikipedia.org/wiki/Lawful_interception 
-chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hutton, Andrew
Sent: Tuesday, May 01, 2012 6:14 AM
To: Ted Hardie; [email-masked]
Subject: Re: [rtcweb] Use Case draft - Eavesdropping.

Hi,

Regards
Andy

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 1 May 2012 10:35:17 -0400

> - "Lawful intercept" is something telecom service providers are required to provide to law enforcement with all appropriate safeguards in place http://en.wikipedia.org/wiki/Lawful_interception

Lawful intercept is a legal term, which in my opinion the IETF should
stay away from.  You will go into the weeds amazing fast otherwise.

I prefer "monitoring," which can be done for many reasons (see the
parallel discussion on enterprise call centers).

Regards
Marshall

---

From: Randell Jesup <[email-masked]>
Date: Tue, 01 May 2012 11:56:11 -0400

On 5/1/2012 1:06 AM, Stefan Hakansson LK wrote:
> On 04/30/2012 11:00 PM, Randell Jesup wrote:
>> The game case can need both reliable and unreliable data at the same
>> time, which gets us reliable, unreliable and multiple streams.
>
> You're right; but currently only game state updates is mentioned.
> Probably that use case should be updated.

Game state updates for a real online game can involve both reliable and 
unreliable data.  Some state can be out-of-date (player positions, 
visual state issues (lighting), etc) and the game will extrapolate 
positions; others (global critical state (live, dead, etc)) must be 
reliable.

-- 
Randell Jesup
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Tue, 01 May 2012 12:22:40 -0400

> parallel discussion on enterprise call centers).

I'm fine with discussing call center monitoring, and believe the 
authentication should be to "Key Bank" or "Key Bank Customer Service", 
not to "station 27 Boise Key Bank Call Center", which implies the WebRTC 
connection would terminate at the call center 'PBX'-equivalent and then 
have media (etc) routed (even via a second WebRTC connection) to the 
agent.  This means monitoring (and for financial firms, legally-required 
logging, etc) can occur via the PBX-equivalent (aka WebRTC Proxy).

We have explicitly avoided discussion of "Lawful intercept", which would 
involve complex (changing) legal requirements from every major 
jurisdiction, and we should continue to avoid wrestling with that 
python.  :-)

-- 
Randell Jesup
[email-masked]

---

From: Stefan Hakansson LK <[email-masked]>
Date: Wed, 2 May 2012 09:50:28 +0200

> descriptions of what the relevant security properties are.

As one of the editors of the use case doc, I agree.

The document was written at a time when everything was much vaguer, and 
we as a group had much much less insight, and this is reflected in the 
document. 'Eavesdropping' is one example, 'stream' is another (we now 
have things like MediaStream, MediaStreamTrack), and so on.

I think we should keep it that way rather than doing a major update; I 
think there is little gain in doing that.

Stefan

---

From: Stefan Hakansson LK <[email-masked]>
Date: Wed, 2 May 2012 10:45:50 +0200

On 05/01/2012 02:05 PM, Jim Barnett wrote:
> One way to describe the use case is to let the contact center's media
> server/gateway serve as the webRTC endpoint.  Then all the issues of
> call delivery, call monitoring, etc. disappear.  They are handled by
> application software that sits behind the webRTC endpoint.  The
> company I work for makes a good living selling software that deals
> with all these issues - including bathroom breaks - and that's how we
> would tend to think of this case.  To us, it's a new kind of
> call/connection coming into the contact center, which we translate
> into SIP at the border and then handle normally.
>
> It's not clear to me if this use case adds any extra requirements.

I think this is important to sort out. If the use case does not add any 
extra requirements, what's the point of adding it?

> We would just have to be careful not to assume that a webRTC endpoint
> is always a person/browser-based user agent.  It may seem a bit
> unsettling that the webRTC endpoint can distribute the call somewhere
> else and let others listen in, but as far as I can tell that is
> already the case.  If Bob calls Alice with full authentication and
> security, he can be sure that he is connected to Alice's user agent
> and that no one in between can listen in, but there's nothing
> stopping Alice from recording the audio, or forwarding it to a third
> party.  So Bob could in fact be talking to Mary if that's how Alice
> wants to arrange things (_behind_ her user agent).  In general, Bob
> is assured only that he is talking to someone Alice wants him to talk
> to, and that no one can snoop without Alice's permission.  That's
> very much the way things work with the call center - you are sure
> that you are 1) connected securely to your bank 2) talking to someone
> that the bank wants you to talk to 3) being recorded or snooped on
> only when the bank explicitly chooses to do so.
>
> - Jim
>
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Marshall Eubanks Sent:
> Monday, April 30, 2012 11:42 PM To: Hutton, Andrew Cc:
> [email-masked] Subject: Re: [rtcweb] Use Case draft
>
> On Mon, Apr 30, 2012 at 2:31 PM, Hutton,
> Andrew<[email-masked]>  wrote:
>> Whether anybody has been successful in the past with this type of
>> use case is I think irrelevant.
>>
>>
>>
>> because it is a scenario in which one user is only concerned that
>> they can securely reach an organization/domain and is not concerned
>> about the individual within that domain  that they communicate
>> with.  A suspect quite a large percentage of RTCWEB applications
>> will be like this and it is not covered in the current use case
>> draft.
>
> I agree that this is a very useful use case and one I think is going
> to get a lot of traction. There is a very solid business case for
> this.  However, I have a fair amount of experience with a video call
> center for a client, and it is not as simple as it might seem.
>
> The essence of course is that you get the next available person,
> i.e., it is anycast. Determining who the next available person is is
> not trivial, nor is error recovery. (If I call you, and you don't
> answer or the call drops or whatever,  I can leave a message or try
> later. If I call a help desk, and this happens, I want a new agent,
> ideally automatically.) Call forwarding (e.g., first tier to second
> tier technical support) is essential, and it may be anycast or
> directed. There are also some security oddities  - if I am connecting
> from home, I may need to authenticate, use a credit card, etc. If I
> am connecting from inside a store, and providing in store video
> technical support is big part of the market, then the store
> authenticates me off line and the call really should just be a button
> push, which implies that the store has previously authenticated some
> sort of master session. In addition, unlike most video calls, in the
> enterprise call center a supervisor may need to be able to monitor
> (i.e., watch) a call, and in some circumstances (financial or medical
> calls, for example) there will need to be third party recording. I
> believe that  these details would be different from the typical
> RTCWEB scenario.
>
> Also, there will be a temptation to do the anycasting by the
> techniques used to load balance servers in a data center, but I think
> that may not be sufficient. The call "center" may in fact be spread
> completely across the planet (daytime support in the US, nighttime
> support in India, for example) and be on multiple autonomous systems
> (and even from people's homes), which gives rise to some of the
> transport issues NVO3 may face, but without any opportunity for
> packet tagging. Plus, there will complicated rules about who can be
> selected next. RTCWEB shouldn't worry about the intricacies of
> bathroom break policies; these complexities should be dealt with by
> an enterprise-side database, which to me (together with some of the
> other issues above) suggests that this would probably benefit from
> API support.
>
> Regards Marshall
>
>
>>
>>
>>
>> So I think we need it.
>>
>>
>>
>> Regards
>>
>> Andy
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Behalf Of Igor Faynberg Sent: 30 April 2012 17:41 To:
>> [email-masked]
>>
>>
>> Without numbers it is impossible to argue, but, if we talk about
>> the perceived need, I disagree.  Think of the people who travel
>> abroad and cannot call the 800 number. (I routinely use Web
>> interface for calls when traveling.)
>>
>>
>>
>> or clicking a button marked "free internet call" - almost no-one on
>> a real, busy site clicked the button.
>>
>> ( for every button click there were several orders of magnitude
>> more 0800 calls from that page).
>>
>>
>>
>>
>>
>> So from my perspective this is a legacy interop use case with
>> almost zero user acceptance.
>>
>>
>>
>> practice yet.)
>> _______________________________________________ rtcweb mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>>
> _______________________________________________ rtcweb mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________ rtcweb mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 2 May 2012 09:05:38 +0000

Stefan,

This usecase add its own requirements from identity perspective as 
I mentioned earlier. 

WebRTC MUST allow "Anonymous" users secure session for call center
usecase. "Anonymous" User may be agent in the call center side or 
customer who does not require Identity to start the session.

Thanks
Partha 

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Stefan Hakansson LK
>Sent: Wednesday, May 02, 2012 2:16 PM
>To: [email-masked]
>> and that no one in between can listen in, but there's nothing stopping
>> Alice from recording the audio, or forwarding it to a third party.  So
>> Bob could in fact be talking to Mary if that's how Alice wants to
>> arrange things (_behind_ her user agent).  In general, Bob is assured
>> only that he is talking to someone Alice wants him to talk to, and
>> that no one can snoop without Alice's permission.  That's very much
>> the way things work with the call center - you are sure that you are
>> 1) connected securely to your bank 2) talking to someone that the bank
>> wants you to talk to 3) being recorded or snooped on only when the
>> bank explicitly chooses to do so.
>>
>> - Jim
>>
>>> about the individual within that domain  that they communicate with.
>>> A suspect quite a large percentage of RTCWEB applications will be
>>> like this and it is not covered in the current use case draft.
>>
>> The essence of course is that you get the next available person, i.e.,
>> it is anycast. Determining who the next available person is is not
>> trivial, nor is error recovery. (If I call you, and you don't answer
>> or the call drops or whatever,  I can leave a message or try later. If
>> I call a help desk, and this happens, I want a new agent, ideally
>> automatically.) Call forwarding (e.g., first tier to second tier
>> technical support) is essential, and it may be anycast or directed.
>> There are also some security oddities  - if I am connecting from home,
>> I may need to authenticate, use a credit card, etc. If I am connecting
>> from inside a store, and providing in store video technical support is
>> big part of the market, then the store authenticates me off line and
>> the call really should just be a button push, which implies that the
>> store has previously authenticated some sort of master session. In
>> addition, unlike most video calls, in the enterprise call center a
>> supervisor may need to be able to monitor (i.e., watch) a call, and in
>> some circumstances (financial or medical calls, for example) there
>> will need to be third party recording. I believe that  these details
>> would be different from the typical RTCWEB scenario.
>>
>> transport issues NVO3 may face, but without any opportunity for packet
>> tagging. Plus, there will complicated rules about who can be selected
>> next. RTCWEB shouldn't worry about the intricacies of bathroom break
>> policies; these complexities should be dealt with by an
>> enterprise-side database, which to me (together with some of the other
>> issues above) suggests that this would probably benefit from API
>> support.
>>
>> Regards Marshall
>>
>>
>>>
>>>
>>>
>>> So I think we need it.
>>>
>>>
>>>
>>> Regards
>>>
>>> Andy
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> perceived need, I disagree.  Think of the people who travel abroad
>>> and cannot call the 800 number. (I routinely use Web interface for
>>> calls when traveling.)
>>>
>>>
>>>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 02 May 2012 15:40:44 +0200

> - "Lawful intercept" is something telecom service providers are required to provide to law enforcement with all appropriate safeguards in place http://en.wikipedia.org/wiki/Lawful_interception
In fact the RAVEN RFC spent some time defining wiretapping:

    Wiretapping is what occurs when information passed across the
    Internet from one party to one or more other parties is delivered to
    a third party:

    1. Without the sending party knowing about the third party

    2. Without any of the recipient parties knowing about the delivery to
       the third party

    3. When the normal expectation of the sender is that the transmitted
       information will only be seen by the recipient parties or parties
       obliged to keep the information in confidence

    4. When the third party acts deliberately to target the transmission
       of the first party, either because he is of interest, or because
       the second party's reception is of interest.

    The term "party", as used here, can refer to one person, a group of
    persons, or equipment acting on behalf of persons; the term "party"
    is used for brevity.

    Of course, many wiretaps will be bidirectional, monitoring traffic
    sent by two or more parties to each other.

    Thus, for instance, monitoring public newsgroups is not wiretapping
    (condition 3 violated), random monitoring of a large population is
    not wiretapping (condition 4 violated), a recipient passing on
    private email is not wiretapping (condition 2 violated).

The call center case isn't wiretapping by RAVEN's definition, since 
conditions 1 and 2 don't hold.

Note also that chapter 4 of RAVEN is entitled "Why the IETF does not 
take a moral position".

---

From: Stefan Hakansson LK <[email-masked]>
Date: Wed, 2 May 2012 15:57:29 +0200

> customer who does not require Identity to start the session.

There is currently no requirement on "identity" in the document at all. 
It was deemed beyond the scope of it when the first version was created 
(and I think this what we tried say with the initial section on that the 
"document focuses on requirements related to real-time media streams."). 
This was also inspired by that web applications usually deal with 
identity in the app itself.

Identity has since been discussed at length. I think it is up to the 
group and the chairs to decide if the document should be updated to 
cover identity, and how that (in that case) should be phrased.

Br,
Stefan

---

From: "Jim Barnett" <[email-masked]>
Date: Wed, 2 May 2012 07:39:28 -0700

When I say that this use case may not add further requirements, I mean
that it looks like it would be possible to implement it given the
current definitions of the protocols.  However, the current use cases
are all written in terms of "the browser", which is not further defined.
But if "browser" means Mozilla, Chrome, etc., then I think it is
important to add a use case in which one of the end points is not a
browser, but an enterprise gateway (which will route the call to an
employee of its choice, and may record the call, etc.) It is important
to note that this is not a peer-to-peer use case; the gateway is not the
caller's peer.  The employee that the caller ends up talking to may be
considered a peer, but the webRTC call does not extend all the way to
that employee - it stops at the gateway.  

This is a very different use case from any in the current document.
That's why it's important to add it, even though (as far as I can tell)
it doesn't require us to change any of the work we've done.  

- Jim
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stefan Hakansson LK
Sent: Wednesday, May 02, 2012 4:46 AM
To: [email-masked]
Subject: Re: [rtcweb] Use Case draft

---

From: Stefan Hakansson LK <[email-masked]>
Date: Wed, 2 May 2012 17:48:44 +0200

> that employee - it stops at the gateway.

I think all use cases in section 4.3 are browser - GW cases. That said, 
there may be good reasons for adding this one as well.

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 02 May 2012 12:08:56 -0400

I am afraid I don't understand this.

For the call center case, when I "call" company X, I would like to make 
sure that I am connected to an agent representing X, and so the identity 
should looke like something "X_Agent_707," not "Anonymous."

Igor

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 2 May 2012 10:50:17 -0700

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jim Barnett
> Sent: Wednesday, May 02, 2012 7:39 AM
> To: Stefan Hakansson LK; [email-masked]
> Subject: Re: [WEBRTC] Use Case draft
> 

Somewhere, we need consensus on a model for interworking WEBRTC 
endpoints with non-WEBRTC endpoints.  

The decision comes down to this:  

  1. encumber WEBRTC endpoints with the interworking 
     effort, or 
  2. encumber a separate interworking device with the 
     interworking effort.

I believe we have a better chance of success with (2), where 
possible to do (2).

For some decisions, such as Consent Freshness (previously called Voice 
Hammer Attack in http://tools.ietf.org/html/rfc5245#section-18.5.1),
non-WEBRTC endpoints need to respond to those ICE connectivity
checks or have a gateway in front of them that responds to those
connectivity checks on their behalf.  This means that WEBRTC
cannot work directly with some existing SIP equipment (because
a lot of SIP equipment does not support ICE).

For other decisions, such as if we disallow un-encrypted RTP by
WEBRTC endpoints, we create a requirement that some device does
the interworking between WEBRTC endpoints (which do only SRTP) 
and non-WEBRTC endpoints (which do RTP).  That means, for that
interworking, we would adopt the interworking model on slide 7 
that I presented at IETF83,
http://www.ietf.org/proceedings/83/slides/slides-83-WEBRTC-3.pdf

However, when I presented slide 7, there were objections at the 
microphone that this model 'is broken'.  I would like to understand 
the objections so we can reach consensus on how interworking from
WEBRTC to non-WEBRTC is expected to occur.

-d

> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> Of Stefan Hakansson LK
> To: [email-masked]
> Subject: Re: [WEBRTC] Use Case draft
> 
> stopping
> > -----Original Message----- From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Marshall Eubanks Sent:
> > [email-masked] Subject: Re: [WEBRTC] Use Case draft
> >
> use
> >> A suspect quite a large percentage of WEBRTC applications will be
> i.e.,
> > would be different from the typical WEBRTC scenario.
> >
> packet
> > next. WEBRTC shouldn't worry about the intricacies of bathroom break
> >> From: [email-masked] [mailto:[email-masked]] On
> >> [email-masked]
> >> Subject: Re: [WEBRTC] Use Case draft
> >>
> >>
> >>
> a
> >> WEBRTC mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/WEBRTC
> >>
> >>
> >> _______________________________________________ WEBRTC mailing list
> >> [email-masked] https://www.ietf.org/mailman/listinfo/WEBRTC
> >>
> > _______________________________________________ WEBRTC mailing list
> > [email-masked] https://www.ietf.org/mailman/listinfo/WEBRTC
> > _______________________________________________ WEBRTC mailing list
> > [email-masked] https://www.ietf.org/mailman/listinfo/WEBRTC
> 
> WEBRTC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/WEBRTC
> WEBRTC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/WEBRTC

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 2 May 2012 19:54:03 +0200

> http://www.ietf.org/proceedings/83/slides/slides-83-WEBRTC-3.pdf

Hi, the link is broken (404). Could you please point to a working one?

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 2 May 2012 14:19:03 -0400

> Hi, the link is broken (404). Could you please point to a working one?

http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf

> However, when I presented slide 7, there were objections at the microphone that this model 'is broken'.  I would like to understand the objections so we can reach consensus on how interworking from WEBRTC to non-WEBRTC is expected to occur.

My objection is that the proposed system will require middleware to
interoperate with the
vast number of videoconferencing sessions out there, most of which use
RTP. From the
standpoint of a video service provider, buying hardware to support
video to laptops is likely to
lead to requests that participants download some other software which
interoperates natively.

This is an existing business with a fairly large scale and installed
base. Not operating the way that they do is not likely to go over
well.

Regards
Marshall

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 2 May 2012 20:20:12 +0200

On Wed, 2 May 2012 19:54:03 +0200

> Hi, the link is broken (404). Could you please point to a working one?

This one seems to work (just replace WEBRTC with rtcweb):

L.

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

---

From: Mary Barnes <[email-masked]>
Date: Wed, 2 May 2012 15:27:16 -0500

I agree with you in general, however, the link to your slides seems to be
broken.

Mary.

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 2 May 2012 16:35:18 -0400

> I agree with you in general, however, the link to your slides seems to be

Mary;

Marshall

---

From: "Fabio Pietrosanti (naif)" <[email-masked]>
Date: Wed, 02 May 2012 22:53:33 +0200

On 5/2/12 7:50 PM, Dan Wing wrote:
http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf
> WEBRTC to non-WEBRTC is expected to occur.

IMHO it would be much easier, as described in tons of previous email, to
use different Key Management for different requirements:

- SDES + SRTP for end-to-site (peer to gateway)
- DTLS-SRTP for end-to-end (peer to peer)

It would be a simpler approach for:

- Security (the user know the security level)
- Interoperability (Use standard protocols for the need to interoperate)

That way the "simpler, legacy, standard" technology would be used for
all voip "server applications" while the new burning (yet not used by
anyone) DTLS-SRTP will be used for peer-to-peer calls.

Please DO NOT reinvent the wheel for what's already existing and deployed.

Doing so, it's like going against the natural human behavior, it would
just represent a failure.

Fabio

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 2 May 2012 16:13:03 -0700

> From: Mary Barnes [mailto:[email-masked]]
> Sent: Wednesday, May 02, 2012 1:27 PM
> To: Dan Wing
> Cc: Jim Barnett; Stefan Hakansson LK; [email-masked]
> Subject: Re: [rtcweb] interworking with non-WEBRTC endpoints [was RE:
> Use Case draft]
> 
> I agree with you in general, however, the link to your slides seems to
> be broken.

-d

> 	> to note that this is not a peer-to-peer use case; the gateway
> is not
> 	> the
> 	> > Alice from recording the audio, or forwarding it to a third
> party.
> 	> So
> 	>
> 	> > 1) connected securely to your bank 2) talking to someone that
> the
> 	> bank
> 	>
> 	> > or the call drops or whatever,  I can leave a message or try
> later.
> 	> If
> 	>
> 	> > There are also some security oddities  - if I am connecting
> from
> 	> home,
> 	>
> 	> > from inside a store, and providing in store video technical
> support
> 	> is
> 	>
> 	> > supervisor may need to be able to monitor (i.e., watch) a
> call, and
> 	> in
> 	>
> 	> > enterprise-side database, which to me (together with some of
> the
> 	> other
> 	>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 3 May 2012 05:05:52 +0000

Igor,

When you call Company X, you need to assure that you are talking with Company X agent and not required to distinguish the agent.

The identity could be just X (no userpart) or anonymous. There is no difference between anonymous and agent007@X as there is no means to route directly agent007@x in the call centre scenario.

Thanks
Partha

>Of Igor Faynberg
>Sent: Wednesday, May 02, 2012 9:39 PM
>To: [email-masked]
>> This usecase add its own requirements from identity perspective as I
>> mentioned earlier.
>>
>>> Behalf Of Stefan Hakansson LK
>>>> One way to describe the use case is to let the contact center's
>>>> media server/gateway serve as the webRTC endpoint.  Then all the
>>>> issues of call delivery, call monitoring, etc. disappear.  They are
>>>> handled by application software that sits behind the webRTC
>>>> endpoint.  The company I work for makes a good living selling
>>>> software that deals with all these issues - including bathroom
>>>> breaks - and that's how we would tend to think of this case.  To us,
>>>> it's a new kind of call/connection coming into the contact center,
>>>> which we translate into SIP at the border and then handle normally.
>>>>
>>> I think this is important to sort out. If the use case does not add
>>> any extra requirements, what's the point of adding it?
>>>
>>>> We would just have to be careful not to assume that a webRTC
>>>> endpoint is always a person/browser-based user agent.  It may seem a
>>>> bit unsettling that the webRTC endpoint can distribute the call
>>>> somewhere else and let others listen in, but as far as I can tell
>>>> that is already the case.  If Bob calls Alice with full
>>>> authentication and security, he can be sure that he is connected to
>>>> Alice's user agent and that no one in between can listen in, but
>>>> there's nothing stopping Alice from recording the audio, or
>>>> forwarding it to a third party.  So Bob could in fact be talking to
>>>> Mary if that's how Alice wants to arrange things (_behind_ her user
>>>> agent).  In general, Bob is assured only that he is talking to
>>>> someone Alice wants him to talk to, and that no one can snoop
>>>> without Alice's permission.  That's very much the way things work
>>>> with the call center - you are sure that you are
>>>> 1) connected securely to your bank 2) talking to someone that the
>>>> bank wants you to talk to 3) being recorded or snooped on only when
>>>> the bank explicitly chooses to do so.
>>>>
>>>> - Jim
>>>>
>with.
>>>> ideally
>>>> There are also some security oddities  - if I am connecting from
>>>> home, I may need to authenticate, use a credit card, etc. If I am
>>>> connecting from inside a store, and providing in store video
>>>> authenticates me off line and the call really should just be a
>>>> button push, which implies that the store has previously
>>>> authenticated some sort of master session. In addition, unlike most
>>>> video calls, in the enterprise call center a supervisor may need to
>>>> be able to monitor (i.e., watch) a call, and in some circumstances
>>>> (financial or medical calls, for example) there will need to be
>>>> third party recording. I believe that  these details would be
>different from the typical RTCWEB scenario.
>>>>
>>>> techniques used to load balance servers in a data center, but I
>>>> think that may not be sufficient. The call "center" may in fact be
>>>> spread completely across the planet (daytime support in the US,
>>>> nighttime support in India, for example) and be on multiple
>>>> autonomous systems (and even from people's homes), which gives rise
>>>> to some of the transport issues NVO3 may face, but without any
>>>> opportunity for packet tagging. Plus, there will complicated rules
>>>> about who can be selected next. RTCWEB shouldn't worry about the
>>>> intricacies of bathroom break policies; these complexities should be
>>>> dealt with by an enterprise-side database, which to me (together
>>>> with some of the other issues above) suggests that this would
>>>> probably benefit from API support.
>>>>
>>>> Regards Marshall
>>>>
>>>>
>>>>>
>>>>>
>>>>> So I think we need it.
>>>>>
>>>>>
>>>>>
>>>>> Regards
>>>>>
>>>>> Andy
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 3 May 2012 05:23:19 +0000

Fabio,

Could you please explain how to differentiate through protocol means that the peer is site (gateway) or endpoint (webbrowser).

Thanks
Partha 

>Of Fabio Pietrosanti (naif)
>Sent: Thursday, May 03, 2012 2:24 AM
>To: [email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 03 May 2012 08:03:15 +0200

> base. Not operating the way that they do is not likely to go over
Marshall,

I'd like to draw your attention to two numbers:

- Number of installed room videoconferencing units: On the order of 1 
million.

http://www.polycom.com/global/documents/company/video_conferencing_by_the_numbers.pdf

- Number of installed Chrome browsers: On the order of 200 million.

http://www.techradar.com/news/internet/google-chrome-browser-hits-200-million-users-1033951

(pulling out Chrome just because I know we've promised to ship this 
stuff. And we auto-update, which means most of the users WILL be running 
a WebRTC-compatible browser the week after we release it.)

I argue strongly for doing things in ways that we know work, which means 
not inventing stuff until we really have to. And I've even argued 
strongly for doing things in ways that *permit* interoperation with 
those older devices - but not in the cases where doing so risks harming 
the security, stability and operational complexity of the installed base 
that is to come.

                     Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 03 May 2012 08:11:19 +0200

> The identity could be just X (no userpart) or anonymous. There is no difference between anonymous and agent007@X as there is no means to route directly agent007@x in the call centre scenario.
It' s easy to construct scenarios where having the ability to set up a 
connection directly to agent007@x is desirable - consider the case of 
anonymous counselling, where a call gets dropped in the middle of the 
conversation; while the caller wishes to know that the callee is really 
a representative of "X anonymous", and both parties wish to remain 
anonymous as persons, when the call gets dropped in the middle of the 
conversation, the calling party has a strong incentive to continue the 
conversation with the same party, if possible.

In this case, having a callee identity with a lifetime of "one 
conversation" seems highly desirable; any distributed ID system (such as 
1st party BrowserID) should be able to easily support that.

            Harald

---

From: "Fabio Pietrosanti (naif)" <[email-masked]>
Date: Thu, 03 May 2012 09:19:16 +0200

Well,

maybe it's just the "signaling provider" that will tell to the browser
what to use:

- simpler interoperable SDES/SRTP (saying to the user "send SRTP here
IP:Port with that Key)
- stronger non-interoperable DTLS-SRTP (saying to the user "go
peer-to-peer")

For example if the signaling provider know that it's providing:
a) A call to a center call
b) Call trough PSTN gateway (web call to PSTN)
c) Voicemail access
d) Financial call (stock brokerage)
e) Enterprise call (that would just need to proxy all calls)

then the signaling provider will notice to the user's WebRTC stack
SDES/SRTP in a *very simple* way without ICE/DTLS-SRTP and all that
protocol complexity.

Instead if that specific VoIP uses does not require a VoIP server to
provide value added services (transcoding, conferencing, bridging to
other telephony networks, recording, whatever) it would just goes as
DTLS-SRTP.

Some previous link on the topic:

* On DTLS-SRTP trust model (and consideration for SDES-SRTP)
http://www.ietf.org/mail-archive/web/rtcweb/current/msg04007.html

* End-to-end encryption vs end-to-end authentication (DTLS-SRTP / SDES-SRTP)
http://www.ietf.org/mail-archive/web/rtcweb/current/msg04032.html

*  DTLS-SRTP with end-to-end security: Short Authentication String
http://www.ietf.org/mail-archive/web/rtcweb/current/msg04123.html

Fabio

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 3 May 2012 07:39:27 +0000

Harald,

It is one of the main reason, the reliability & QOS of the established session is very important in the telecom/Enterprise world and the call disconnect for the established session due to technical reason will taken as an escalation :-( 

There are lot of reasons, the majority of the call centre may not prefer to provide the agent-id to the customer as it is not manageable solution. Dynamically deciding the available agent helps for better agent time utilization in the call center compare to direct dialing to the agent. The agent may work in shift (in the different timezone) wherein you will not be able to reach him in the same identity itself. In these type of call center, the case id or your existing some id is the way to continue your earlier conversation if it is recorded in some form. 

As an individual user, I don't want to register as a user of each website before calling their site to know about their product information.

As you wish, The premium user of the call center will be given the agent identity to contact. For example, you will be provided with Bank agent identity for your banking account related queries. Please note that you MUST be premium user of the bank to get that privilege or have to live with case-id or start from IVR & reach some new agent to start with.

Thanks
Partha

>Of Harald Alvestrand
>Sent: Thursday, May 03, 2012 11:41 AM
>To: [email-masked]
>> When you call Company X, you need to assure that you are talking with
>Company X agent and not required to distinguish the agent.
>>
>> The identity could be just X (no userpart) or anonymous. There is no
>difference between anonymous and agent007@X as there is no means to
>route directly agent007@x in the call centre scenario.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 03 May 2012 10:25:34 +0200

On 05/03/2012 09:39 AM, Ravindran, Parthasarathi wrote:
> Harald,
>
> It is one of the main reason, the reliability&  QOS of the established session is very important in the telecom/Enterprise world and the call disconnect for the established session due to technical reason will taken as an escalation :-(
I was thinking of scenarios like "the phone slipped out of my hand" and 
"I tripped over the PC power cord", actually.... there are plenty of 
reasons why calls get disconnected.
> There are lot of reasons, the majority of the call centre may not prefer to provide the agent-id to the customer as it is not manageable solution. Dynamically deciding the available agent helps for…
My point was not to dispute any of those for the cases you describe. But 
those cases are not the only cases; I've re-called into call centers 
where I've said "I was talking to John", and the responder says "OK, I 
see he's free, I'll transfer you".

The desire for "anonymous agents" is not synonymous with "doesn't 
support re-dial" - that was really my only point.
> As you wish, The premium user of the call center will be given the agent identity to contact. For example, you will be provided with Bank agent identity for your banking account related queries. Please note that you MUST be premium user of the bank to get that privilege or have to live with case-id or start from IVR&  reach some new agent to start with.
It seems we agree that some people will want to build applications where 
this functionality is available. That was really all I was trying to 
say, so I'm happy now.

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 3 May 2012 14:54:59 +0530

|My objection is that the proposed system will require middleware
|to interoperate with the vast number of videoconferencing sessions
|out there, most of which use RTP. From the standpoint of a video
|service provider, buying hardware to support video to laptops is
|likely to lead to requests that participants download some other 
|software which interoperates natively.

I find this argument nothing different from those for interoperating with legacy phones which probably would outnumber videoconferencing systems out there by a very large number. Given that video conferencing systems are fairly advanced, rather than requiring customers to use insecure communication, service providers could require those manufacturers to support secure communication at minimal cost. I don't see how insecure communication would go well with all those customers who would like to use web based communication over the Internet.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On Behalf Of Marshall Eubanks
|Sent: Wednesday, May 02, 2012 11:49 PM
|To: Iñaki Baz Castillo
|Cc: [email-masked]
|Subject: Re: [rtcweb] interworking with non-WEBRTC endpoints [was RE: UseCase draft]
|
|On Wed, May 2, 2012 at 1:54 PM, Iñaki Baz Castillo <[email-masked]> wrote:
|> 2012/5/2 Dan Wing <[email-masked]>:
|>> For other decisions, such as if we disallow un-encrypted RTP by
|>> WEBRTC endpoints, we create a requirement that some device does
|>> the interworking between WEBRTC endpoints (which do only SRTP)
|>> and non-WEBRTC endpoints (which do RTP).  That means, for that
|>> interworking, we would adopt the interworking model on slide 7
|>> that I presented at IETF83,
|>> http://www.ietf.org/proceedings/83/slides/slides-83-WEBRTC-3.pdf
|>
|> Hi, the link is broken (404). Could you please point to a working one?
|>
|
|http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf
|
|> However, when I presented slide 7, there were objections at the microphone that this model 'is
|broken'.  I would like to understand the objections so we can reach consensus on how interworking from
|WEBRTC to non-WEBRTC is expected to occur.
|
|My objection is that the proposed system will require middleware to
|interoperate with the
|vast number of videoconferencing sessions out there, most of which use
|RTP. From the
|standpoint of a video service provider, buying hardware to support
|video to laptops is likely to
|lead to requests that participants download some other software which
|interoperates natively.
|
|This is an existing business with a fairly large scale and installed
|base. Not operating the way that they do is not likely to go over
|well.
|
|Regards
|Marshall
|
|> Thanks a lot.
|>
|> --
|> Iñaki Baz Castillo
|> <[email-masked]>
|> _______________________________________________
|> rtcweb mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/rtcweb
|_______________________________________________
|rtcweb mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Jim Barnett" <[email-masked]>
Date: Thu, 3 May 2012 06:06:01 -0700

Yes, the use cases in  4.3 are browser-GW, though none of them really
covers the call center case (routing to an arbitrary agent, recording
the call, etc.)

However, the requirements in section 5 don't seem to mention legacy
connectivity, unless that's what F27 is supposed to cover ("The browser
MUST be able to initiate and accept a media session where the data
needed for establishment can be carried in SIP.")  It might be good to
have a specific legacy requirement along the forms of "The Browser must
be able to communicate with legacy devices that have the following
characteristics ...." Of course, this gets into the whole
interoperability discussion. For example, should the Browser be able to
interoperate with devices that don't support  ICE?  (I have been
assuming that the call center gateway would  support ICE).  

The enterprise use cases that Roman has mentioned are separate from
this, and would add new requirements, since they involve webRTC within
the enterprise connecting to external webRTC endpoints.  In the call
center use case, the webRTC call is terminated at the gateway.  

- Jim

-----Original Message-----
From: Stefan Hakansson LK [mailto:[email-masked]] 
Sent: Wednesday, May 02, 2012 11:49 AM
To: Jim Barnett
Cc: [email-masked]
Subject: Re: [rtcweb] Use Case draft

> to note that this is not a peer-to-peer use case; the gateway is not 
> the caller's peer.  The employee that the caller ends up talking to 
> may be considered a peer, but the webRTC call does not extend all the 
> way to that employee - it stops at the gateway.

> That's why it's important to add it, even though (as far as I can 
> tell) it doesn't require us to change any of the work we've done.
>
> - Jim

---

From: Stefan Hakansson LK <[email-masked]>
Date: Thu, 3 May 2012 16:43:52 +0200

> assuming that the call center gateway would  support ICE).

I think reqs F21 and F22 are typical legacy device interop related 
requirements as well.

What we did when writing the document was to assume that the device in 
the other end of a connection would have to implement basically the same 
set of protocols as a browser, then we added some specific requirements 
to simplify/reduce cost (carry signaling in SIP, telco codec, DTMF).

I say this to explain why there is no specific requirement on "must be 
able to interop with a device having the following characteristics", not 
to say that such a req does not make sense.

That said, I'm afraid that the work required to specify the exact 
characteristics of devices that the browser must be able to interop with 
would be very big. Would not the discussion lead into every nitty gritty 
detail?

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 3 May 2012 07:44:02 -0700

I concur with Marshall's objections, based on my discussions with customers. 

Video conferencing systems are frequently purchased with the expectation that they will be
used to communicate outside the organization, as well as with other devices, including PCs,
tablets and mobile devices.   

As an example, an enterprise with a video conferencing system may use it to communicate
with employees in the field who are using a notebook, tablet or mobile device. 

Therefore, while an enterprise may have a finite number of video conferencing units,  it will
often deploy them along with orders of magnitude more devices that interoperate with those
units.  

The usual requirements for a desirable mobile or tablet implementation apply here -- power
management (e.g. ability to utilize native encode/decode hardware) is an important capability.  Also,
the cost of supporting video transcoding for a large number of devices will frequently be prohibitive,
so that the expectation is that videoconferencing systems and implementations on PCs, tablets
and mobile devices will be able to negotiate a mutually supported codec. 

  

    
    Marshall,

    - Number of installed room videoconferencing units: On the order of
    1 million.

    

    (pulling out Chrome just because I know we've promised to ship this
    stuff. And we auto-update, which means most of the users WILL be
    running a WebRTC-compatible browser the week after we release it.)

    I argue strongly for doing things in ways that we know work, which
    means not inventing stuff until we really have to. And I've even
    argued strongly for doing things in ways that *permit*
    interoperation with those older devices - but not in the cases where
    doing so risks harming the security, stability and operational
    complexity of the installed base that is to come.

                        Harald

---

From: "Jim Barnett" <[email-masked]>
Date: Thu, 3 May 2012 07:52:30 -0700

Yes, I think that you're right that specifying the exact set of legacy
devices would be a painful task.  It may be that the current
requirements are sufficient for the call center use case, as long as we
understand that in that use case it is the call center gateway, and not
the agent workstation/browser, that is the webRTC endpoint.  The call
center's requirements for routing, recording/monitoring, etc. are
awfully hard to combine with webRTC if we think of the webRTC call as
going all the way to the agent.  

- Jim
P.S. Roman's enterprise  use cases are distinct from the call center
case, and do involve webRTC connections extending all the way into the
enterprise.  

-----Original Message-----
From: Stefan Hakansson LK [mailto:[email-masked]] 
Sent: Thursday, May 03, 2012 10:44 AM
To: Jim Barnett
Cc: [email-masked]
Subject: Re: [rtcweb] Use Case draft

On 05/03/2012 03:06 PM, Jim Barnett wrote:
> connectivity, unless that's what F27 is supposed to cover ("The 
> browser MUST be able to initiate and accept a media session where the 
> data needed for establishment can be carried in SIP.")  It might be 
> good to have a specific legacy requirement along the forms of "The 
> Browser must be able to communicate with legacy devices that have the 
> following characteristics ...." Of course, this gets into the whole 
> interoperability discussion. For example, should the Browser be able 
> to interoperate with devices that don't support  ICE?  (I have been 

> I think all use cases in section 4.3 are browser - GW cases. That 
> said, there may be good reasons for adding this one as well.
>
>>
>>> media

>>> endpoint

with.

>>> think

>>>> almost

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 04 May 2012 08:41:34 +0200

(changing subject line to fork thread)

> assuming that the call center gateway would  support ICE).
My memory of our last rounds of discussion was that we decided not to 
have a non-gateway legacy interop case because
a) given the variety of legacy equipment, it would basically require a 
specific device as the "interop partner" (a rathole), and
b) it would bind the architecture of RTCWeb in ways that might prevent 
us from achieving our goals in other ways (especially security issues).

YMMV.

---

From: Neil Stratford <[email-masked]>
Date: Fri, 4 May 2012 10:29:19 +0100

There is no reason that the RTP to SRTP/ICE gateway needs to be hosted server side, it could equally be a software component downloaded to each client machine running a WebRTC browser.

In fact, you could even do it in a Java Applet that's sole purpose is to relay RTP to SRTP and perform ICE with the local WebRTC stack.

No, actually, forget I said that.

Neil

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 4 May 2012 13:17:16 +0200

2012/5/4 Neil Stratford <[email-masked]>:
> There is no reason that the RTP to SRTP/ICE gateway needs to be hosted
> server side, it could equally be a software component downloaded to each
> client machine running a WebRTC browser.
>
> In fact, you could even do it in a Java Applet that's sole purpose is to
> relay RTP to SRTP and perform ICE with the local WebRTC stack.
>

No no no, you said that, you said that !!!
I cannot forget it, it's the most painful concept I've ever read !!! XDDD

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 4 May 2012 13:44:57 +0200

The Return of Java Applets :)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Iñaki Baz Castillo
Sent: 4. toukokuuta 2012 14:17
To: Neil Stratford
Cc: [email-masked]
Subject: Re: [rtcweb] interworking with non-WEBRTC endpoints [was RE: Use Case draft]

2012/5/4 Neil Stratford <[email-masked]>:
> server side, it could equally be a software component downloaded to 
> each client machine running a WebRTC browser.
>
> In fact, you could even do it in a Java Applet that's sole purpose is 
> to relay RTP to SRTP and perform ICE with the local WebRTC stack.
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 4 May 2012 13:22:38 +0200

> Could you please explain how to differentiate through protocol means that the peer is site (gateway) or endpoint (webbrowser).

The gateway (or the SIP/XMPP peer or whatever) will not announce
DTLS-SRTP support in its SDP.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 4 May 2012 09:13:58 -0400

+1 another reason to mandate H.264  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bernard Aboba
Sent: Thursday, May 03, 2012 10:44 AM
To: [email-masked]
Subject: Re: [rtcweb] interworking with non-WEBRTC endpoints

Video conferencing systems are frequently purchased with the expectation
that they will be
used to communicate outside the organization, as well as with other devices,
including PCs,
tablets and mobile devices.   

As an example, an enterprise with a video conferencing system may use it to
communicate
with employees in the field who are using a notebook, tablet or mobile
device. 

Therefore, while an enterprise may have a finite number of video
conferencing units,  it will
often deploy them along with orders of magnitude more devices that
interoperate with those
units.  

The usual requirements for a desirable mobile or tablet implementation apply
here -- power
management (e.g. ability to utilize native encode/decode hardware) is an
important capability.  Also,
the cost of supporting video transcoding for a large number of devices will
frequently be prohibitive,
so that the expectation is that videoconferencing systems and
implementations on PCs, tablets
and mobile devices will be able to negotiate a mutually supported codec. 

 

Marshall,

http://www.polycom.com/global/documents/company/video_conferencing_by_the_nu
mbers.pdf

http://www.techradar.com/news/internet/google-chrome-browser-hits-200-millio
n-users-1033951

(pulling out Chrome just because I know we've promised to ship this stuff.
And we auto-update, which means most of the users WILL be running a
WebRTC-compatible browser the week after we release it.)

I argue strongly for doing things in ways that we know work, which means not
inventing stuff until we really have to. And I've even argued strongly for
doing things in ways that *permit* interoperation with those older devices -
but not in the cases where doing so risks harming the security, stability
and operational complexity of the installed base that is to come.

                    Harald

---

From: Xavier Marjou <[email-masked]>
Date: Fri, 4 May 2012 15:50:38 +0200

+1

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 4 May 2012 07:46:38 -0700

> us from achieving our goals in other ways (especially security issues).

[BA] That was my recollection as well.  

The discussion we're getting into now involves how much the "gateway" will
need to do.  This will of necessity vary depending on how ancient the "legacy"
equipment is.  For example, if the "legacy" is only a few years old, it may 
support SRTP, and with appropriate RTCWEB accommodation (e.g. EKT or
SDES), the "gateway" would not need to decrypt/encrypt every media frame. 
In this scenario, the "gateway" functionality needed by WebRTC would be in
the range of capabilities already supported by SBCs (which are proliferating
like weeds even in "legacy" deployments).  So one could claim that the 
additional burden imposed by WebRTC interop gateways would be tolerable.

If the "legacy" is older (e.g. circa mid-2000s), then it will probably not
support SRTP, and the burden on the gateway becomes greater.  Personally,
I'm ok with this because many of those "extreme legacy" deployments are
nearing (or have already passed) "end of life" and by the time RTCWEB
is widely deployed, they will have become difficult to support/maintain. 
Since those "extreme legacy" deployments don't support most of the 
capabilities of WebRTC anyway without an upgrade (e.g. typically no video 
or IM&P), it doesn't seem sensible to me to warp the entire WebRTC
architecture to accommodate them.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 4 May 2012 18:17:07 +0200

2012/5/4 Harald Alvestrand <[email-masked]>:
> My memory of our last rounds of discussion was that we decided not to have a
> non-gateway legacy interop case

Hi Harald, is that really *decided*? I will ask the same question in a
different way:

If I have a SIP phone implementing ICE and DTLS-SRTP (which is
standarized for SIP regardless it has null impementation), will my SIP
phone be able to *directly* talk in the media plane with a WebRTC
browser? or not?

And also, what does it mean a "non-gateway"? Gateways are not
specified, they are custom boxes implementing some kind of protocol
translation. The only way in which it can be said that "there is not
non-gateway legacy interop" is by making WebRTC *explicitly*
non-compliant with any other existing device (for example by requiring
some annoying a=ensureWebRTC line in the SDP, in this way you can be
sure that WebRTC entities will interop with nobody but with specific
"gateways" that know the trick).

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 5 May 2012 09:24:48 -0700

> Behalf Of Iñaki Baz Castillo
> Sent: Friday, May 04, 2012 9:17 AM
> To: Harald Alvestrand
> Cc: [email-masked]
> Subject: Re: [rtcweb] Use Case draft - legacy interop
> 
> have a

That would work.

-d

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 5 May 2012 18:32:02 +0200

>> phone be able to *directly* talk in the media plane with a WebRTC

Ok, so then, taking into account that SIP defines the usage of
DTLS-SRTP in RFC 5763 (regardless no one device implements it), why
does this WG assumes that "interop with non WebRTC endpoints will be
made via *gateways*"?

Let me please repeat my question: if my SIP phone implements RFC 5763,
can my SIP phone directly interop at media plane with a WebRTC
browser? (I know you already replied this, but I want to be very very
sure) :)

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 5 May 2012 09:44:29 -0700

> phone be able to *directly* talk in the media plane with a WebRTC

[BA] While I believe that the answer to this question should be required to be "yes", I do not think we can yet say whether this will be true or not. 

For example, for interoperation to be possible, the "continuing consent" mechanism used in ICE would need to be backward compatible with existing implementations. 

This is not the case for the mechanism proposed in draft-muthu-behave-consent-freshness. 

Similarly, we would need to ensure that the DTLS-SRTP functionality specified in WebRTC could be used to interoperate with existing implementations, which as I understand it, support EKT.

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 5 May 2012 10:24:48 -0700

> From: Iñaki Baz Castillo [mailto:[email-masked]]
> Sent: Saturday, May 05, 2012 9:32 AM
> To: Dan Wing
> Cc: Harald Alvestrand; [email-masked]

Perhaps a more accurate statement would be:

  directly, if the remote endpoint supports ICE and supports
  DTLS-SRTP; otherwise, via a gateway.

> browser? (I know you already replied this, but I want to be very very

Sure seems it should work.  Only nuance that I am aware of at the moment
is WEBRTC seems to want to require Consent Freshness (periodic ICE
connectivity checks) for the duration of the call.  This is okay, and
would work with an existing SIP phone -- so long as the SIP phone
continues to respond to ICE messages.  It should.  But I doubt that
is exercised in SIPIT testing.  The other nuance is that, because
doing the SHA1 for MESSAGE-INTEGRITY isn't needed for consent freshness,
there is desire to allow those periodic ICE connectivity checks to
omit the MESSAGE-INTEGRITY, which is a change to ICE.  See 
draft-muthu-behave-consent-freshness.  Of course, that doesn't require
a gateway, but would require softening the implementation on the
phone.  draft-muthu-behave-consent-freshness might also add a new
SDP attribute, I dunno yet.

-d

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 07 May 2012 10:20:08 +0200

On 05/05/2012 06:32 PM, Iñaki Baz Castillo wrote:
> 2012/5/5 Dan Wing<[email-masked]>:
Inaki, your statement that "the WG assumes" is, as far as I can see, a 
straw man made out of red herrings.

The WG's opinion is what's captured in the WG's documents, and (if 
needed) announced by the chairs. Statements by participants are 
statements by participants. If you have issue with the WG's documents, 
quote the text you want changed, don't just make unfounded statements 
like you do above.

I've quoted the overview document before:

    As for all protocol and API specifications, there is no restriction
    that the protocols can only be used to talk to another browser; since
    they are fully specified, any device that implements the protocols
    faithfully should be able to interoperate with the application
    running in the browser.

Since you did not specify the product number of your hypothetical phone, 
and since the IETF has not finished specifying the set of protocols 
needed, there is no guarantee that interworking will happen in practice. 
That is, there's no guarantee that ICE + RFC 5763 is sufficient for 
interoperation.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 07 May 2012 23:14:34 +0200

Forking the thread, since this is a different detail.....

On 05/05/2012 07:24 PM, Dan Wing wrote:
> The other nuance is that, because
> draft-muthu-behave-consent-freshness.
Omitting MESSAGE-INTEGRITY would allow off-path attackers to inject fake 
connectivity checks, and thus to simulate continued consent.

If connectivity checks for content freshness are worth doing, they're 
worth protecting.
My $0.02.

                    Harald

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 7 May 2012 14:23:48 -0700

> From: Harald Alvestrand [mailto:[email-masked]]
> Sent: Monday, May 07, 2012 2:15 PM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Consent freshness and message-integrity (Re: [rtcweb] Use Case
> draft - legacy interop)
> 

To successfully do that, those off-path attackers would have to guess 
the random 96-bit STUN transaction-id.

-d

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 07 May 2012 23:46:16 +0200

> the random 96-bit STUN transaction-id.
You're right, successfully replying to consent freshness packets 
requires read access to the consent freshness packets being sent (I was 
thinking that consent freshness was being generated from the recipient, 
not the sender, which is opposite to what draft-muthu does .... or 
rather, it's not clear to me what direction a successful 
request/response exchange verifies the freshness of). So it's an on-path 
attacker. I'll go take that argument to behave; I don't think that 
tradeoff is in the right place.