Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client]

From: Matthew Kaufman <[email-masked]>
Date: Mon, 05 Sep 2011 20:39:19 -0700

On 8/23/2011 5:57 PM, Ravindran Parthasarathi wrote:
>
> I'm interested in hearing the reasons for why SIP MUST NOT be used in 
> browser.
>

The primary reason for avoiding a protocol like SIP between the web 
browser and its associated server(s) is that adding *any* functionality 
requires a round of standardization effort, whereas following the web 
model (HTML and Javascript in the clients, arbitrary signaling over 
HTTP) allows for immediate and frequent innovation on that channel.

Matthew Kaufman

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 06 Sep 2011 09:13:39 -0400

I find this reasoning hard to understand.  First, the SIP standard has 
been around for a decade. What new standardization is needed?

Igor

On 9/5/2011 11:39 PM, Matthew Kaufman wrote:
> browser and its associated server(s) is that adding *any* 
> functionality requires a round of standardization effort, whereas 
> following the web model (HTML and Javascript in the clients, arbitrary 
> signaling over HTTP) allows for immediate and frequent innovation on 
> that channel.
>
> Matthew Kaufman
>

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Wed, 7 Sep 2011 00:06:23 +0530

Matthew,

Even in case of SIP, there is no need of standardization in case it is
within single webserver(skype). SIP supports x-header or proprietary
header to extend the way you want it for providing innovative
functionality. There is no extension barrier from SIP perspective but it
ensure that basic call works across web servers. For example, skype
browser user will able to talk to gmail real-time user even though all
skype functionality are not supported.

 In case you have the points why HTTP allows innovation but SIP will
not, let us discuss in detail.

Thanks

Partha

From: Igor Faynberg [mailto:[email-masked]] 
Sent: Tuesday, September 06, 2011 6:44 PM
To: Matthew Kaufman
Cc: Ravindran Parthasarathi; [email-masked]
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote
recording - RTC-Web client acting as SIPREC session recording client]

Igor

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 06 Sep 2011 11:40:38 -0700

On 9/6/11 11:36 AM, Ravindran Parthasarathi wrote:
> functionality.

Not if SIP is baked in to the browser it doesn't. If the browser 
implements a SIP phone in native code, I have no way of adding 
"x-header" or anything else. I live with the functionality provided by 
the browser.

If on the other hand, you want SIP implemented in Javascript then sure, 
if a developer wants to use it, great. If they want to extend it, that's 
fine too. And if they'd rather use another model, they are free to do 
that. Just as you would expect from a *platform*.

> There is no extension barrier from SIP perspective but it ensure that 
> basic call works across web servers. For example, skype browser user 
> will able to talk to gmail real-time user even though all skype 
> functionality are not supported.
>
See above.
> not, let us discuss in detail.

See above. I want you to be free to use SIP, but not *required* to use SIP.

And there's some security reasons that I'd rather you tunnel it over 
HTTP rather than opening up your ability to send UDP packets to port 5060.

Matthew Kaufman

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 6 Sep 2011 20:47:10 +0200

6 sep 2011 kl. 20:40 skrev Matthew Kaufman:

>> Even in case of SIP, there is no need of standardization in case it is within single webserver(skype). SIP supports x-header or proprietary header to extend the way you want it for providing innovative functionality.
> 
> Not if SIP is baked in to the browser it doesn't. If the browser implements a SIP phone in native code, I have no way of adding "x-header" or anything else. I live with the functionality provided by the browser.
That's an implementation detail. One can easily add an API call to add headers on the outbound INVITE.

> 
> If on the other hand, you want SIP implemented in Javascript then sure, if a developer wants to use it, great. If they want to extend it, that's fine too. And if they'd rather use another model, they are free to do that. Just as you would expect from a *platform*.
> 
>> There is no extension barrier from SIP perspective but it ensure that basic call works across web servers. For example, skype browser user will able to talk to gmail real-time user even though all skype functionality are not supported.
> See above.
>>  
>>  In case you have the points why HTTP allows innovation but SIP will not, let us discuss in detail.
> 
> And there's some security reasons that I'd rather you tunnel it over HTTP rather than opening up your ability to send UDP packets to port 5060.
SIP runs on TCP and TLS ports too.

I am not arguing for either side, just correcting some details...

/O

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Wed, 7 Sep 2011 00:32:24 +0530

Matthew,

<snip>>> And there's some security reasons that I'd rather you tunnel it
over
>SIP runs on TCP and TLS ports too. </snip>

In case one port opening (80) will not create security issue but how
opening two ports (80 & 5060) will cause security issue? Could you
please explain the security reason between port 80 for HTTP and 5060 for
SIP

Please read inline for further comments.

Thanks
Partha

>-----Original Message-----
>From: Olle E. Johansson [mailto:[email-masked]]
>Sent: Wednesday, September 07, 2011 12:17 AM
>To: Matthew Kaufman
>>> Even in case of SIP, there is no need of standardization in case it
>is within single webserver(skype). SIP supports x-header or proprietary
>implements a SIP phone in native code, I have no way of adding "x-
>header" or anything else. I live with the functionality provided by the
>browser.
[Partha] My understanding is same as olle. Javascript API MUST provide
the mechanism to add proprietary SIP headers or else I agree with you
that solution is useless.

>
>>
>> If on the other hand, you want SIP implemented in Javascript then
>sure, if a developer wants to use it, great. If they want to extend it,
>that's fine too. And if they'd rather use another model, they are free
>to do that. Just as you would expect from a *platform*.
>>
>> See above. I want you to be free to use SIP, but not *required* to
use
>SIP.
[Partha] In case Javascript API supports for adding new headers, there
is no difference right?

>SIP runs on TCP and TLS ports too.
[Partha]

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 6 Sep 2011 15:24:43 -0400

What about semantics (adding just a X-header won't help there) or how much SIP would be left anyhow if all semantical control is exposed through the API?

I think bridged line appearance is a good test to run against different models.

Thanks,
Tolga

-----Original Message-----
From: [email-masked] on behalf of Olle E. Johansson
Sent: Tue 9/6/2011 2:47 PM
To: Matthew Kaufman
Cc: [email-masked]
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as	SIPREC	session recordingclient]

/O

_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 06 Sep 2011 15:46:36 -0400

The key question is:  What MUST the browser provide to support a SIP 
implementation in an application? (I asked this question a few thousand 
messages back, but the thread was inconclusive.)

HTTP alone cannot do the job. How will the user agent receive 
notifications, for example?

Igor

---

From: Justin Uberti <[email-masked]>
Date: Tue, 6 Sep 2011 16:22:50 -0400

Notifications can be received over WebSockets, or any of the existing
mechanisms web applications use for server->client notifications.

On Tue, Sep 6, 2011 at 3:46 PM, Igor Faynberg <
[email-masked]> wrote:

>>>> within single webserver(skype). SIP supports x-header or proprietary header
>>>> to extend the way you want it for providing innovative functionality.
>>>>
>>> implements a SIP phone in native code, I have no way of adding "x-header" or
>>> anything else. I live with the functionality provided by the browser.
>>>
>>> fine too. And if they'd rather use another model, they are free to do that.
>>> Just as you would expect from a *platform*.
>>>
>>>> basic call works across web servers. For example, skype browser user will
>>>> able to talk to gmail real-time user even though all skype functionality are
>>>> not supported.
>>>>
>>> See above.
>>>
>>>>
>>> And there's some security reasons that I'd rather you tunnel it over HTTP
>>> rather than opening up your ability to send UDP packets to port 5060.
>>>
>> ______________________________**_________________
>> rtcweb mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>>
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 06 Sep 2011 14:11:10 -0700

> What about semantics (adding just a X-header won't help there) or how much SIP would be left anyhow if all semantical control is exposed through the API?

Exactly what I was going to say. Simply adding headers is not 
sufficient, unless you can also tell the far end to ignore the existing 
headers and control the functionality directly... in which case we're 
just using SIP as a transport.
> I think bridged line appearance is a good test to run against different models.

Actually nearly any of the 100s of specialized existing SIP 
specifications is a good test, but the best ones are indeed the ones 
that *still* aren't final specifications.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 06 Sep 2011 14:16:24 -0700

On 9/6/11 12:02 PM, Ravindran Parthasarathi wrote:
>> SIP runs on TCP and TLS ports too.</snip>
> opening two ports (80&  5060) will cause security issue? Could you

There has been a whole lot of work regarding what browsers do and don't 
do over HTTP. (Think: cross site access, what headers can be controlled 
from script, etc.) We would be forced to reinvent all of this for a 
reduced-functionality SIP in order to get the same protections. (Should 
a browser that runs Javascript loaded from www.evil.com be able to send 
SIP INVITE to addresses inside your firewall?)

And there is a whole lot of infrastructure that allows organizations to 
safely allow HTTP to pass in and out of their infrastructure.
> that solution is useless.

Not nearly sufficient as I stated before. The problem is the semantics 
of all the existing SIP messages and headers, not whether or not you can 
add more.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 06 Sep 2011 14:25:07 -0700

> been around for a decade. What new standardization is needed?

The issue is whenever you wish to innovate and add functionality.

See the long, long list of RFCs that extend SIP. For some examples:
RFC3515 - Refer method
RFC3842 - Message waiting
RFC3891 - Replaces header
RFC3911 - Join header
RFC3960 - Early media
RFC4411 - Reason header for preemption

Never mind all the things that aren't even finished...

draft-ietf-bliss-shared-appearances
draft-ietf-bliss-call-park-extension

true bridged line appearances

etc

etc

If all you want is a basic point-to-point phone, there's a short list of 
RFCs you implement and you're done. But that isn't a platform for 
innovation... it is just a phone.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 06 Sep 2011 14:28:02 -0700

On 9/6/11 2:25 PM, Matthew Kaufman wrote:
>> I find this reasoning hard to understand.  First, the SIP standard 
>> has been around for a decade. What new standardization is needed?
>

To make this really simple, an analogy:

What would Gmail be like if every web browser had a built-in IMAP client 
(== "a complete SIP implementation") *and* that was the only way you 
could display tables of email subject lines in the browser window (== 
"the only way to use the codec and RTP transport")?

Matthew Kaufman

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Sep 2011 19:16:41 -0400

The bridged line appearance case is an interesting one. It is definitely 
a feature that sip has trouble with.

There are proprietary solutions for shared line appearance that use sip 
for call set up, along with other protocols. (Or at least *can* use sip, 
even if they usually use something else proprietary.) But they are 
proprietary, so that you have to buy the whole solution from one vendor, 
generally including all the phones.

IIUC, with RTCWEB as Matthew is proposing it, you would be able to use 
anybody's phone that had a browser and supported RTCWEB. The limitation 
is that then all of the phones that want to be part of the shared line 
appearance group will need to share a server. IOW, you will need an 
RTCWEB capable web server representing the AOR.

That could be a big hurdle for retrofitting existing sip-based phone 
systems, though perhaps an attractive approach for up and coming 
competitors to those existing systems.

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 7 Sep 2011 09:07:40 +0200

> I think bridged line appearance is a good test to run against different models.
Well, I tried to stay neutral but examples likes this makes me not want SIP in the browser. DTMF, Early Media, bridge line apperances and other PSTN legacy will make the implementation too focused on classical telephony and we'll spend too much time implementing features that are application specific and we can implement in controlling applications, client or server-side. 

Cullen tried to make a draft with "limited" SIP (maybe "SIP Lite") but it will be hard to protect that from the myriad of extensions that add PSTN functionality that's not really needed to set up multimedia calls between two browser users. It may be needed for gatewaying to legacy systems, but if we don't "stop Olle in the gate" - verbatim translation of a Swedish saying that propably doesn't mean much to most people on the list - I think we will never be done.

Of course, being a SIP developer, I started off with thinking that SIP in the browser was the default route. I am beginning to understand that the browser is the user interface part we all need, the media handler. We all have different requirements on how to control that media GUI and to get anywhere I am beginning to think the logic for signalling to set up rendevouz points and manage sessions has to move "somewhere else" where we can implement SIP, XMPP or some other protocol that fulfills the need of our respective application.

To fearlessly  jump into another can of worms, I still think we should have confidentiality - SRTP - by default. We know that these applications will run on a myriad of devices on a myriad of networks and it will not work to let users have to decided whether or not they want confidentiality. If Skype did not have confidentiality by default, there would be articles every summer and xmas in the evening taboloids about how easy it is to listen in to your neighbours calls and that would have hurted Skype badly. 

/O

> I am not arguing for either side, just correcting some details...

---
* Olle E Johansson - [email-masked]
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden

---

From: Roman Shpount <[email-masked]>
Date: Wed, 7 Sep 2011 12:48:31 -0400

Just to adding my two cents on why SIP must not be used: SIP was designed
for a very different use case then rtcWeb. SIP was designed to run over UDP
on a network with no NAT. It was intended as a light weight protocol to
implement IP phones on the corporate networks. It was designed for devices
with limited resources and limited and fixed functionality. There was a
significant amount of effort to add support for SIP over NAT, but this is
far from being complete. Getting SIP over TCP to work from NAT environments
is still a challenge. Unfortunately you do need SIP over TCP to support ICE
due to the increased offer size. In fact, I am not aware of any system that
implements SIP over TCP over NAT (RFC 5626) in combination with ICE.

On the other hand, rtcWeb is designed for large number of clients running
behind NAT. We do not have the same limitations on the end user device
performance. There is no real reason to use UDP as primary signaling
protocol. Unlike on IP phones, HTTP client and JavaScript are already
available and will not create an additional implementation burden. Thus, I
think we should keep the offer/answer and use HTTP and JavaScript to
implement the signaling.
_____________
Roman Shpount

On Wed, Sep 7, 2011 at 3:07 AM, Olle E. Johansson <[email-masked]> wrote:

> > What about semantics (adding just a X-header won't help there) or how
> much SIP would be left anyhow if all semantical control is exposed through
> the API?
> >
> Well, I tried to stay neutral but examples likes this makes me not want SIP
> in the browser. DTMF, Early Media, bridge line apperances and other PSTN
> legacy will make the implementation too focused on classical telephony and
> we'll spend too much time implementing features that are application
> specific and we can implement in controlling applications, client or
> server-side.
>
> Cullen tried to make a draft with "limited" SIP (maybe "SIP Lite") but it
> will be hard to protect that from the myriad of extensions that add PSTN
> functionality that's not really needed to set up multimedia calls between
> two browser users. It may be needed for gatewaying to legacy systems, but if
> we don't "stop Olle in the gate" - verbatim translation of a Swedish saying
> that propably doesn't mean much to most people on the list - I think we will
> never be done.
>
> Of course, being a SIP developer, I started off with thinking that SIP in
> the browser was the default route. I am beginning to understand that the
> browser is the user interface part we all need, the media handler. We all
> have different requirements on how to control that media GUI and to get
> anywhere I am beginning to think the logic for signalling to set up
> rendevouz points and manage sessions has to move "somewhere else" where we
> can implement SIP, XMPP or some other protocol that fulfills the need of our
> respective application.
>
> To fearlessly  jump into another can of worms, I still think we should have
> confidentiality - SRTP - by default. We know that these applications will
> run on a myriad of devices on a myriad of networks and it will not work to
> let users have to decided whether or not they want confidentiality. If Skype
> did not have confidentiality by default, there would be articles every
> summer and xmas in the evening taboloids about how easy it is to listen in
> to your neighbours calls and that would have hurted Skype badly.
>
> /O
>
>
> > Thanks,
> > Tolga
> >
> >
> > Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE:
> Remoterecording - RTC-Web client acting as     SIPREC  session
> recordingclient]
> >
> >

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 07 Sep 2011 12:53:49 -0400

Not that I disagree with any single thing that  Matthew said in his 
detailed respond, which I very much appreciate, but

1) I don't see why any other protocol will be easier to change a priori 
in order to meet the "innovation" requirements (I use quotes because I 
believe we need to see actual requirements before deciding that any 
protocol needs to change)

2) I believe we must address compatibility. For instance, with so much 
investment in by mobile operators in SIP-based IMS, the wireless 
handsets need to support it.

There are two approaches:  One, which Justin just mentioned is to rely 
on WebSocket (this is actually what I wrote about a while ago);  the 
second is to put a core SIP skeleton in the browser so that the actual 
headers can be completed by an application.

I think that we ought to investigate both (in my opinion, the second one 
will make life easier for developers).

I wonder if we can agree on a requirement that the browser must have 
sufficient set of capabilities to support development of SIP in the 
application.  Ultimately, this is what I want to ensure.

Igor

On 9/6/2011 5:25 PM, Matthew Kaufman wrote:
> If all you want is a basic point-to-point phone, there's a short list 
> of RFCs you implement and you're done. But that isn't a platform for

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 07 Sep 2011 12:58:23 -0400

On 9/7/2011 3:07 AM, Olle E. Johansson wrote:
> ...I am beginning to think the logic for signalling to set up rendevouz points and manage sessions has to move "somewhere else" where we can implement SIP, XMPP or some other protocol that fulfills the need of our respective application.

Yes, as long as the browser will support moving this logic somewhere else.
> ...To fearlessly  jump into another can of worms, I still think we should have confidentiality - SRTP - by default...

Eric had many interesting things to say about this. I definitely think 
we ought to explore this point.

Igor

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Wed, 7 Sep 2011 22:59:14 +0530

Matthew,

When I asked for SIP, I have meant RFC 3261 only. The basic reason for
asking SIP is to make the basic call works between browser to browser
across web servers. Without SIP in browser, it is not going happen.
Innovative application is going to be proprietary whether it is HTTP or
SIP or any other protocol for that matter.

My reasoning are as follows:

1)      SIP makes browser more intelligence compare to dump signaling
mechanism like MEGACO and browser acts as MG. 

2)      The importance of basic call interop is that there is no need of
many individual id like skype id, Google id  and yahoo id by everyone in
the world to communicate others. I wish to have single id like e-mail id
to be maintained by browser-to-browser users to communicate with others.

3)      SIP helps to interop for basic call with other existing realtime
application in Enterprise & Telecom provider.

4)      There is no need to build two different signaling logic in VoIP
servers for each service. Your own example of Bridge line appearance
will need two implementation by the single vendor because desktop
application or hardphone implementation based on SIP and browser based
implementation is depend on HTTP metadata. It is possible to avoided by
having one signaling protocol.

In RTCWEB does not standardize the signaling protocol interface between
browsers, the interop across webservers is next to impossible and it
will be restricted to single webserver (company) only. Please let  me
know in case I'm missing something here.

Thanks

Partha

From: Matthew Kaufman [mailto:[email-masked]] 
Sent: Wednesday, September 07, 2011 2:55 AM
To: [email-masked]
Cc: Ravindran Parthasarathi; [email-masked]
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote
recording - RTC-Web client acting as SIPREC session recording client]

etc

etc

Matthew Kaufman

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 07 Sep 2011 19:43:25 +0200

On 09/07/11 19:29, Ravindran Parthasarathi wrote:
>
> Matthew,
>
> When I asked for SIP, I have meant RFC 3261 only.
>
This is 269 pages, and has 26 normative dependencies including S/MIME. 
It's not a small dependency.
>
> The basic reason for asking SIP is to make the basic call works 
> between browser to browser across web servers. Without SIP in browser, 
> it is not going happen. Innovative application is going to be 
> proprietary whether it is HTTP or SIP or any other protocol for that 
> matter.
>
> 1)SIP makes browser more intelligence compare to dump signaling 
Why does that "intelligence" need to be in the browser, rather than in 
the Javascript?
>
> 2)The importance of basic call interop is that there is no need of 
> many individual id like skype id, Google id  and yahoo id by everyone 
> in the world to communicate others. I wish to have single id like 
> e-mail id to be maintained by browser-to-browser users to communicate 
> with others.
>
This only makes sense for applications that fit the "call an identified 
party" paradigm.
>
> 3)SIP helps to interop for basic call with other existing realtime 
> 4)There is no need to build two different signaling logic in VoIP 
> implementation is depend on HTTP metadata. It is possible to avoided 
> by having one signaling protocol.
>
One protocol can be achieved by multiple applications choosing to 
implement one protocol.
It doesn't have to be enforced by the prtoocol being embedded in the 
browser.
>
> In RTCWEB does not standardize the signaling protocol interface 
> between browsers, the interop across webservers is next to impossible 
> and it will be restricted to single webserver (company) only. Please 
> let  me know in case I?m missing something here.
>

I think the main thing you are missing is that there are many 
applications that people want to build on top of RTCWEB that are not 
telephones, and will not fit with telephone-based paradigms.

---

From: <[email-masked]>
Date: Wed, 7 Sep 2011 17:57:16 +0000

Hi,

The "web servers" in different domains could implement SIP and gateway calls from one domain to another that way. I think it is a reasonable assumption that basic voice calls (and maybe video) could interoperate between domains in this way without requiring SIP in the browser.

I mostly agree with Matthew's statements in this thread. I believe it is possible for an application developer to implement "call setup" (the "signaling") already in today's browsers, and Websockets is going to make that even a bit more efficient regardless of RTCWeb. So the RTCWeb should not focus on that aspect, but the missing part, which is the real-time media transport between browsers.

It is not a totally crazy idea to have SIP in the browser, though. It could be useful in many scenarios, like interacting with existing PBX or IMS infra, while adding some cool web based stuff in the app on the side. But in the interest of making progress in the more critical parts, I would postpone that standardization effort into the second phase of RTCWeb. Or maybe a new WG like SIPWeb :) This is of course based on the naïve assumption that the first phase of RTCWeb will not do anything that would prevent browsers to support SIP later on.

Markus

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Ravindran Parthasarathi
Sent: 07 September, 2011 20:29
To: Matthew Kaufman; [email-masked]
Cc: [email-masked]
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client]

Matthew,

When I asked for SIP, I have meant RFC 3261 only. The basic reason for asking SIP is to make the basic call works between browser to browser across web servers. Without SIP in browser, it is not going happen. Innovative application is going to be proprietary whether it is HTTP or SIP or any other protocol for that matter.

1)      SIP makes browser more intelligence compare to dump signaling mechanism like MEGACO and browser acts as MG.

2)      The importance of basic call interop is that there is no need of many individual id like skype id, Google id  and yahoo id by everyone in the world to communicate others. I wish to have single id like e-mail id to be maintained by browser-to-browser users to communicate with others.

3)      SIP helps to interop for basic call with other existing realtime application in Enterprise & Telecom provider.

4)      There is no need to build two different signaling logic in VoIP servers for each service. Your own example of Bridge line appearance will need two implementation by the single vendor because desktop application or hardphone implementation based on SIP and browser based implementation is depend on HTTP metadata. It is possible to avoided by having one signaling protocol.

In RTCWEB does not standardize the signaling protocol interface between browsers, the interop across webservers is next to impossible and it will be restricted to single webserver (company) only. Please let  me know in case I'm missing something here.

Thanks
Partha

Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client]

On 9/6/11 6:13 AM, Igor Faynberg wrote:
I find this reasoning hard to understand.  First, the SIP standard has been around for a decade. What new standardization is needed?

etc

etc

If all you want is a basic point-to-point phone, there's a short list of RFCs you implement and you're done. But that isn't a platform for innovation... it is just a phone.

Matthew Kaufman

---

From: Randell Jesup <[email-masked]>
Date: Wed, 07 Sep 2011 15:20:14 -0400

> Of course, being a SIP developer, I started off with thinking that SIP in the browser was the default route. I am beginning to understand that the browser is the user interface part we all need, th…

I also started from the same point - assume SIP.  SIP gives you all the 
things that the zillions of hours and emails to define it and define 
extensions and secure it provides, without having to reinvent all those 
wheels (or ask app developers to reinvent them).  Why go through the 
horrible pain of choosing something else, or why throw the app 
developers to the wolves to fend for themselves?

However...

Two things have swayed me.  The primary one is the suggestion of 
Offer/Answer in the browser.  This breaks out the important negotiation 
piece that almost any application would need, and while not perfect, SDP 
O/A is a zillion times simpler than SIP with all the extensions one 
could use.

The other thing that swayed me was thinking about federation and the 
apps that will be built with this.  A webrtc app talks to its 
(web)server, other webrtc clients running the app that talk to the 
server, and to other webrtc applications/networks that federate with it 
(and their clients).

Federation is in the same hands as the person who provides/wrote the 
app.  If they have no interest in federation you can't force it, and 
they may have no use for all the fancy SIP standards.

On the other hand, if they *want* to either provide access to the wider 
communication net that is the PSTN network, now or in the future, or 
they want easy federation with other networks, it behooves them to use 
SIP or something very close to it or equivalent/convertible (at a basic 
level at least) to it.

So what conclusions do I draw from this?

1) O/A via SDP in the browser simplifies a lot of things (including 
handling new codecs, etc).  It doesn't extremely limit an application, 
though we should think about how an application can interact with the 
fmtp/etc parameters used.

2) SIP as a *separate* item that can be cleanly and easily *added* to a 
webrtc app to handle the call setup/etc is a good idea.

This means a webrtc app could use something else, or roll its own.  Many 
would use SIP.

This would require (limited) SIP to be available as part of webrtc in 
the browser - but as an option, not as a mandate.  An application could 
use an extended SIP client via JS or other mechanism.  Basic SIP would 
need to be in all webrtc implementations so the apps could rely on 
having the option.

This would make building apps & services that can (optionally) call PSTN 
phones easy (very easy perhaps), while not limiting the ability of app 
developers to innovate.  It also makes it easier to build servers to 
handle webrtc apps.

-- 
Randell Jesup
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Wed, 07 Sep 2011 15:20:23 -0400

Splitting the two topics....

> To fearlessly  jump into another can of worms, I still think we should have confidentiality - SRTP - by default. We know that these applications will run on a myriad of devices on a myriad of netwo…

There is a strong argument for this.  The strongest argument for the 
other side is  you don't need a media gateway to talk to non-WebRTC 
endpoints, just a signalling gateway.  This means less delay potentially 
(especially if the application provider has gateways only in one 
geographic location) and less expense for the server provider for a 
pretty common usecase (gateway to PSTN).  The delay could be a 
significant issue.
It was also brought up that some usecases for internal PBX/business use 
would not need/prefer forced encryption.  As mentioned at the meeting, 
encrypting to the media gateway only gets you a modicum of privacy 
(though it might protect you from the "neighbor's wifi capture" case).

You could make forced-encryption the default, and allow the application 
control over whether to allow it is turned off for specific cases, like 
a PSTN call, or under the server's control.  Signalling is secure, so it 
could even use a direct optional downgrade from SAVP* to AVP* (i.e. 
similar to the best-effort-strp draft)

It's a tough call - guaranteed (local) security is nice, but I worry 
about those relay cases like taiwan->USA media gateway->taiwan.  Not a 
huge deal on signaling/call-setup, but media...

-- 
Randell Jesup
[email-masked]

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 7 Sep 2011 21:59:45 +0200

7 sep 2011 kl. 21:20 skrev Randell Jesup:

> There is a strong argument for this.  The strongest argument for the other side is  you don't need a media gateway to talk to non-WebRTC endpoints, just a signalling gateway.  This means less delay potentially (especially if the application provider has gateways only in one geographic location) and less expense for the server provider for a pretty common usecase (gateway to PSTN).  The delay could be a significant issue.
> It was also brought up that some usecases for internal PBX/business use would not need/prefer forced encryption.  As mentioned at the meeting, encrypting to the media gateway only gets you a modicum of privacy (though it might protect you from the "neighbor's wifi capture" case).
> 
> You could make forced-encryption the default, and allow the application control over whether to allow it is turned off for specific cases, like a PSTN call, or under the server's control.  
If that's the case, we have to force a UI directive that all browsers adapt - like the green bar for EV certs - so the user is aware that confidentiality is missing. I don't really see a reason why servers would disable this. Weather or not they are media endpoints and if they use encryption on the other session leg is propably out of scope. Our history with the SIPS: uri has shown how hard it is to try to build a secure architecture with middlemen involved. 

> Signalling is secure, so it could even use a direct optional downgrade from SAVP* to AVP* (i.e. similar to the best-effort-strp draft)
How can you assert that signalling is secure? When, how?
> 
> It's a tough call - guaranteed (local) security is nice, but I worry about those relay cases like taiwan->USA media gateway->taiwan.  Not a huge deal on signaling/call-setup, but media...
I think that if we try to require secure media all the way through servers and gateways, we are setting the bar way too high for rtcweb. If we can handle the media that the browser handles in the local RTP streams and force that to a secure level, we have reached a good platform to continue to work with. 

In order to be able to proceed with confidentiality as a requirement, we have to discuss key exchange for the SRTP streams. I think there are at least two ways forward - to remove it from signalling path and go for an inband key exchange a la ZRTP or declare it out of scope for RTCweb and let the various protocols handle key exchange in different ways. Its going to be very hard for users to judge how secure an application is regardless of solution. Can you explain the difference between SIP SDES and ZRTP for your "normal" users? The security guy in me would of course recommend in-band so that the intermediary servers never see my key. The web guy says "oh yeah, but most of the calls will be between you and my conference mixer or media gateway anyway, so what's the difference?"

I also think that secure identites (a la RFC4474 for SIP) should also be out of scope for RTCweb, but something we can continue to work with when building the applications and protocols that use rtcweb as a media handler. This is still an issue in SIP, XMPP and many other protocols and something we really need for realtime communication.

/O

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 07 Sep 2011 13:03:34 -0700

On 09/07/2011 12:20 PM, Randell Jesup wrote:
>> To fearlessly  jump into another can of worms, I still think we 
>> should have confidentiality - SRTP - by default. We know that these 
>> applications will run on a myriad of devices on a myriad of networks 
>> and it will not work to let users have to decided whether or not they 
>> want confidentiality. If Skype did not have confidentiality by 
>> default, there would be articles every summer and xmas in the evening 
>> taboloids about how easy it is to listen in to your neighbours calls 
>> and that would have hurted Skype badly.
>>
>
> endpoints, just a signalling gateway.  This means less delay 
> potentially (especially if the application provider has gateways only 
> in one geographic location) and less expense for the server provider 
> for a pretty common usecase (gateway to PSTN).  The delay could be a 
> significant issue.
> It was also brought up that some usecases for internal PBX/business 
> use would not need/prefer forced encryption.  As mentioned at the 
> meeting, encrypting to the media gateway only gets you a modicum of 
> privacy (though it might protect you from the "neighbor's wifi 
> capture" case).
>
> You could make forced-encryption the default, and allow the 
> application control over whether to allow it is turned off for 
> specific cases, like a PSTN call, or under the server's control.  
> Signalling is secure, so it could even use a direct optional downgrade 
> from SAVP* to AVP* (i.e. similar to the best-effort-strp draft)
>

Flip-side: contracts already force encryption, and that is one reason 
why people do not want contracts; they want open wi-fi so neighbors have 
no walls across net points. Developers fear those pitchforks when they 
could have used security other than contract-stated default. That messes 
up everybody elses units not on those contacts, so you are back to ICE 
or force each person back to single connection to trunk internet lines 
and stateful-hubs (i.e. rtcweb on the base phone, not the hand-set, with 
audio-whitespaces or the base phone unit acts as DSL-filter end-point.).

-- 
--- http://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 7 Sep 2011 22:10:29 +0200

7 sep 2011 kl. 19:29 skrev Ravindran Parthasarathi:

> In RTCWEB does not standardize the signaling protocol interface between browsers, the interop across webservers is next to impossible and it will be restricted to single webserver (company) only. Please let  me know in case I’m missing something here.

Ravindran,
I don't follow the logic here. If you have SIP in the browser, the web server will only be involved when loading the web page. SIP will take care of the rest.

In order to explain my current view (which might change): Try to divide a sip phone in two parts. One part handles the multimedia - codecs, encryption, qos (RTCP). The other part handles sessions - setup, teardown, transfers etc. The way I see it (which is my personal view, not this lists) is that rtcweb is the media handler. We can build various controlling applications on client and server side, using the protocol we like - it could be SIP but also a range of other protocols, including proprietary protocols. I do hope that SIP wins here of course. I don't think we should fight another round of session management protocol wars in rtcweb - but that opinion is based on the architecture I described here.

Getting what we need to be able to set up media sessions in a web browser from applications like Asterisk is a great win. We have what we need to handle the session management part :-)

I hope this helps you to understand my view that SIP should not be part of the rtcweb set of standards. It is not about whether SIP can be in the browser or not, it's just about putting some sort of scope limit on this IETF project. SIP can still be implemented - and will propably be - in the browser. At my first SIPit in Stockholm many years ago, I tested with someone who already at that time had a SIP client in the browser.

Cheers,
/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 7 Sep 2011 22:17:17 +0200

7 sep 2011 kl. 19:43 skrev Harald Alvestrand:

> This is 269 pages, and has 26 normative dependencies including S/MIME. It's not a small dependency.
Agree. That RFC is way too focused on ONE application, the phone call.

> One protocol can be achieved by multiple applications choosing to implement one protocol.
> It doesn't have to be enforced by the prtoocol being embedded in the browser.
Right. 

> I think the main thing you are missing is that there are many applications that people want to build on top of RTCWEB that are not telephones, and will not fit with telephone-based paradigms.

SIP has already been integrated with years of work of telephone-based paradigms. It's there and we have it. Let's not force that into RTCweb because it will make it way too complex and be an issue when it comes to interoperability between browsers, because most will implement selected parts only (like in SIP today). We don't want that.

I already face that interoperability problem each time I attend SIPit - which btw is open for registration at www.sipit.net for all of you that work with development of SIP apps and devices and need to test interoperability ;-) 

/O

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 07 Sep 2011 13:19:54 -0700

> How can you assert that signalling is secure? When, how?

Real-time is the assertion and is not secure unless we volunteer for 
double entry-systems. "Forward-looking statements..."... "do" you want 
signal quality enforcement? "...and questions."

Do you compare them to market value quotes and the number of votes for 
their rate of appearance? I think subscribers of this WG want security 
for mere difference on the floor; eggshell areas defy rate of gravity, 
or imagine the cone of silence gone wild.

By scalar value.

--

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 7 Sep 2011 16:18:06 -0400

> similar to the best-effort-strp draft)

This has implications for the parallel thread about the use of SDP offer/answer.

The solution MMUSIC has standardized for best-effort SRTP is SDP CapNeg, RFC 5939.  Do we want to require CapNeg support in browsers?

--
Jonathan Lennox
[email-masked]

---

From: Christopher Blizzard <[email-masked]>
Date: Wed, 07 Sep 2011 13:20:04 -0700

> huge deal on signaling/call-setup, but media...

I want secure-by-default, maybe even secure-only.

Even if it's not secure-only there's also an important UI consideration 
depending how we end up doing that in browsers.  In the past we've made 
the secure mode special (the lock icon in the early days, now the 
green/blue bar) but I think that we should be making the insecure mode 
special.  That is, always mark a connection as very clearly unencrypted 
via UI affordances.  Just like banks "wanting to know how to get the 
lock icon" we should be making call sites "wanting to know how to get 
rid of that huge ugly warning that makes us look bad."

Once again, I would much prefer secure-only, but I'll take 
secure-by-default across browsers if I can get it.

--Chris

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 07 Sep 2011 16:20:22 -0400

On 9/7/2011 4:03 PM, Dzonatas Sol wrote:
> ....
> why people do not want contracts; they want open wi-fi so neighbors 
> have no walls across net points.

I admit, I am not one of these people... And where the neighbors can get 
in, anyone else can, too.

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 07 Sep 2011 13:48:44 -0700

On 09/07/2011 01:20 PM, Igor Faynberg wrote:
> I admit, I am not one of these people... And where the neighbors can 
> get in, anyone else can, too.
>

Experience only: we grew-up in areas without fences, only barb-wire, or 
"posts". In these fenced-in neighborhoods, I'm tired of the need "to 
pitch" openness to "anyone"; I sound evangelical now, yet others say 
street-smart.

Good difference?

--

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 07 Sep 2011 16:54:41 -0400

:)

On 9/7/2011 4:48 PM, Dzonatas Sol wrote:
>>> Flip-side: contracts already force encryption, and that is one 
>>> reason why people do not want contracts; they want open wi-fi so 
>>> neighbors have no walls across net points.
>>
> Experience only: we grew-up in areas without fences, only barb-wire, 
> or "posts". In these fenced-in neighborhoods, I'm tired of the need 
> "to pitch" openness to "anyone"; I sound evangelical now, yet others 
> say street-smart.
>
> Good difference?
>

---

From: Randell Jesup <[email-masked]>
Date: Wed, 07 Sep 2011 17:57:25 -0400

On 9/7/2011 4:20 PM, Christopher Blizzard wrote:
>>> and it will not work to let users have to decided whether or not 
>>> they want confidentiality. If Skype did not have confidentiality by 
>>> default, there would be articles every summer and xmas in the 
>>> evening taboloids about how easy it is to listen in to your 
>>> neighbours calls and that would have hurted Skype badly.
>>>
>>
>> Signalling is secure, so it could even use a direct optional 
>> downgrade from SAVP* to AVP* (i.e. similar to the best-effort-strp 
>> draft)
>>
>> about those relay cases like taiwan->USA media gateway->taiwan.  Not 
>> a huge deal on signaling/call-setup, but media...
>>
>>
>
> Even if it's not secure-only there's also an important UI 
> consideration depending how we end up doing that in browsers.  In the 
> past we've made the secure mode special (the lock icon in the early 
> days, now the green/blue bar) but I think that we should be making the 
> insecure mode special.  That is, always mark a connection as very 
> clearly unencrypted via UI affordances.  Just like banks "wanting to 
> know how to get the lock icon" we should be making call sites "wanting 
> to know how to get rid of that huge ugly warning that makes us look bad."

A "listening-ear" icon maybe? :-)

Agreed on defaults, maybe on secure-only.  I should note that if it's 
secure-to-media-gateway, that doesn't tell you if it's secure past that 
point, so the lack of the "listening-ear" icon doesn't really mean it's 
*really* secure.  We discussed this some at the last IETF I think.  If 
you can verify the receiver at the other end you may have more assurance 
about who you're talking to... but that's a tough question on it's own.

My experience is that media gateways a great for NAT traversal, and are 
so-so to sucking for conversational quality unless they're very close to 
one or the other endpoint (and may not be great there), and they can 
have serious costs associated with them for the service.

> secure-by-default across browsers if I can get it.

The proposal would put it under control of the application to allow; 
presumably only an app that included in their service access to legacy 
media endpoints would do so.

I'll note that allowing this has minimal (not zero) security impact as 
this is UDP; a bigger issue with this might be ICE.  Currently the ICE 
requirement make this idea rather moot, unless the app can control that 
too (typically this is used to connect to PSTN gateways that you don't 
need ICE to access).   Without ICE there may be larger security issues 
per ekr's draft that just showed up; though I'll note that UDP isn't 
generally a major method of DoS or attack on a site.  It might be used 
in theory for SPIT though; if that's a real threat in any volume that 
may kill this idea.

-- 
Randell Jesup
[email-masked]

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 07 Sep 2011 15:23:14 -0700

> When I asked for SIP, I have meant RFC 3261 only.

As I pointed out earlier, this is the top of a very slippery slope.

Certainly you must have meant 3261 + early media + PRACK (for instance), 
yes?

> between browser to browser across web servers.
>

SIP is in no way required to make this happen.

> Without SIP in browser, it is not going happen.
>

Totally disagree.
>
> Innovative application is going to be proprietary whether it is HTTP 
> or SIP or any other protocol for that matter.
>

True. But having to reverse-engineer out the phone part is really 
painful for the application developer who is trying to build something else.

> mechanism like MEGACO and browser acts as MG.

SIP in the browser makes the browser less *flexible* than an API with 
more direct control over the internal objects (camera, codec, network 
connection) and yet no more intelligent, as the browser has a runtime 
that can be programmed to do anything you want at the client side.

> e-mail id to be maintained by browser-to-browser users to communicate 

This isn't going to happen, and is even closer to my fears about "IMAP 
in the browser" expressed earlier.

> application in Enterprise & Telecom provider.

So what? I hope people understand that RTCWEB could be about so much 
more than enterprise and telecom providers doing two-party phone calls.

Among other things, you can build augmented reality systems out of it 
(see how Flash streaming has been used similarly), multi-party 
experiences that aren't calls (Google hangouts), and many other 
applications we haven't even thought of yet... as long as we don't 
cripple the APIs.
> by having one signaling protocol.

It doesn't even work over that "one signaling protocol", so that doesn't 
help. And again, there is no reason that a web site providing RTC 
applications to/from a browser need necessarily be serving "SIP phones" 
as clients as well. Maybe that just isn't the business they're in.
> between browsers, the interop across webservers is next to impossible

Totally disagree. We need to standardize the *media transport* between 
the browsers, and W3C needs to standardize the *API* by which we can 
send Javascript to the browser that executes the same way on every 
browser, but that doesn't mean the signaling protocol needs to be 
specified any more than IETF needed to intervene to ensure that the XML 
or JSON data that goes between your browser and Gmail is the same as the 
data that goes between your browser and Yahoo mail when you're using 
each to compose email messages.

> and it will be restricted to single webserver (company) only.
>

Disagree. Just like Gmail and Yahoo mail can send messages to each 
other's users over a standard protocol for federation, so can RTCWEB. In 
fact, SIP is probably a great choice for inter-provider trunking. And 
conveniently, we plan to support the same *media transport* that other 
SIP devices use (RTP), so there'll be even more interoperability than 
just browser-to-browser federated between providers.

> Please let  me know in case I'm missing something here.
>

See above.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 07 Sep 2011 15:30:58 -0700

On 9/7/11 12:20 PM, Randell Jesup wrote:
>
> I also started from the same point - assume SIP.  SIP gives you all 
> the things that the zillions of hours and emails to define it and 
> define extensions and secure it provides, without having to reinvent 
> all those wheels (or ask app developers to reinvent them).  Why go 
> through the horrible pain of choosing something else, or why throw the 
> app developers to the wolves to fend for themselves?
>
> However...
>
> Offer/Answer in the browser.  This breaks out the important 
> negotiation piece that almost any application would need, and while 
> not perfect, SDP O/A is a zillion times simpler than SIP with all the 
> extensions one could use.

I agree with this. While I am also opposed to SDP O/A, these are two 
unrelated arguments to have... and not baking a SIP phone into the 
browser is *more* important than avoiding a repeat of the offer/answer 
problems.

> server, and to other webrtc applications/networks that federate with 
> it (and their clients).
>

And for numerous types of apps (think: server-based augmented reality 
systems), "federation" doesn't even make sense.

>
> On the other hand, if they *want* to either provide access to the 
> wider communication net that is the PSTN network, now or in the 
> future, or they want easy federation with other networks, it behooves 
> them to use SIP or something very close to it or 
> equivalent/convertible (at a basic level at least) to it.
>

I agree that it would simplify some interop cases, but at an unfortunate 
cost in lack of flexibility and functionality. Still not nearly as bad 
as if we put a full SIP stack in there though.

>
> 2) SIP as a *separate* item that can be cleanly and easily *added* to 
> a webrtc app to handle the call setup/etc is a good idea.

I would be open to looking at this again, *after* RTC is already in 
browsers and successful, to see if it actually solves a real use case.

Matthew Kaufman

---

From: Randell Jesup <[email-masked]>
Date: Wed, 07 Sep 2011 18:28:19 -0400

> The solution MMUSIC has standardized for best-effort SRTP is SDP CapNeg, RFC 5939.  Do we want to require CapNeg support in browsers?

Yeah, ok, I'm not going there.  :-)  It's probably not needed for this 
use-case anyways.

-- 
Randell Jesup
[email-masked]

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 07 Sep 2011 15:32:43 -0700

On 9/7/11 12:59 PM, Olle E. Johansson wrote:
> If that's the case, we have to force a UI directive that all browsers adapt - like the green bar for EV certs - so the user is aware that confidentiality is missing. ...

I started to address this issue in my security inspector draft. Feel 
free to comment on this so we can improve upon those requirements.

Also, I think we want to have confidentiality with a specific set of 
requirements, namely those that you get if you use DTLS-SRTP with DH and 
AES, not just "SRTP".

Matthew Kaufman

---

From: Randell Jesup <[email-masked]>
Date: Wed, 07 Sep 2011 18:39:18 -0400

> How can you assert that signalling is secure? When, how?

I'm assuming the signalling is occurring as SIP over an HTTPS connection 
to the server, or SIP-over-TLS - haven't really given it a lot of 
thought other than this connection is securable is we start with an 
HTTPS connection to the server.

> I also think that secure identites (a la RFC4474 for SIP) should also be out of scope for RTCweb, but something we can continue to work with when building the applications and protocols that use rt…

All good issues for discussion (there's been some before) that I don't 
have time to respond to right now.

-- 
Randell Jesup
[email-masked]

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 07 Sep 2011 15:55:50 -0700

Then the outside bank wall is the ROI, not silly when you compare 
real-time events to JPEG 2K.

Security at the bank-teller, or ATM, what nobody thinks about anymore. 
We want proof that the double-entry system works between the hand-held 
mobile unit and ATMs such that the way they "solve tether-ball" TOGETHER 
is standard. Maybe no more lines at the bank; it's "wait state", like 
DDoS. Should our bank ATMs recognize our car proximities? Congestion.

Then we consider if the precursory model is "being commented upon". Do 
we have world-wide security approved by the world bank? And, 
analogue-E911? Described within IETF that works flying over celltowers.

I think the term "low-hanging fruit" is derogatory, culturally. I think 
we can still say "digital-only" if you want secure-by-default, or decide 
on import/export portal material across-state in cubic security units, 
or scale to virtual "entertainment" rooms.

How about logoff-to-delete-all login-certificates; simple 
un-federialization for security compromises: "not silly when" everybody 
does not want their "on-logoff" exploited for connection quality and 
state recovery. AI is not on the agenda, yet maybe auto-mute *coughs* 
from the signals is? As well as, other recognized input by familiar 
auto-typists, and finish the book cover with two images, or half by 
difference in geolocation.  I digress and flip-it-back, or expect 
further discussion on geo-mimes as SSRC, yet the forward-looking state 
would be by syllabic mimes for security. Maybe we still need some clear 
"technocratic" value for comparison with SSRC.

Maybe this is just some description of one relational database without 
auto-increment, yet by auto-algorithm already given and stored. Next 
generation of steady-cam that is schema-aware on quadcopter with 
quad-cores: hardware-chron shared in APU bridged with one virtual core 
of the multi-core CPU. Simply, 55' TV with RC-control of 800x600 cam 
such that the feedback window position moves within larger display area 
instead of one always-centered stabilized-viewport.

Helps to lay this out in 12D separation for the kernel with 6D of people 
you never met: a stack. The federal model puts the concepts in virtual 
bubbles, where security by binary is already known, globally. Servers 
want to simulate the "circles" put on Real3D, yet I see no certification 
that this technology is ready for BSD, yet bizarre'd for *cough* 
"fruit". I don't think their patent is gonna expire.

We can ramble on about digital-only security without algorithms as 
passwords, yet we need ones like above for default security. I question 
security technologies that orders qubits within the limits of binary 
systems. I read this up and down and feel like I cross the line if I aim 
the PIP cam and track body sections, as that is easier language for 
others to help themselves. :)

--

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Sep 2011 20:14:13 -0400

Chris,

I agree with you that the UI indication of security is important.
But its also *hard* for this application, for a variety of reasons:

- While it may be easy for the browser to know if the media stream
   is itself secured, its hard (impossible) to know that its secured
   to its ultimate end point. That is the problem with intermediaries.

- it may turn out that not all the streams in the "call" have the
   same degree of security.

Of course this can all be dealt with via proper definition of what the 
UI indication means, and doesn't mean. But doing that will just render 
it meaningless to many users. To be widely understood, the indication 
will need to be simple, and closely aligned with what people "expect".

Consider a stream that is secured to a PSTN gateway, and then travels 
over the PSTN to somebody's phone. Should that be considered a "secure" 
call? Or an "insecure" call? Or somewhere between those?

Its going to be hard work to figure out what can both be reliably 
reported to users and also be understandable and meaningful to users.

	Thanks,
	Paul

On 9/7/11 4:20 PM, Christopher Blizzard wrote:
>>> To fearlessly jump into another can of worms, I still think we should
>>> have confidentiality - SRTP - by default. We know that these
> via UI affordances. Just like banks "wanting to know how to get the lock
> icon" we should be making call sites "wanting to know how to get rid of
> that huge ugly warning that makes us look bad."
>

---

From: Silvia Pfeiffer <[email-masked]>
Date: Thu, 8 Sep 2011 11:15:46 +1000

If implementations count for anything, check out:

http://phono.com/
and
https://docs.google.com/present/view?id=0AcNAXuadeXIxZGY4NDl4Z2RfNTlod3BrOXNjZA&hl=en&pli=1

They use SIP with web sockets.

Cheers,
Silvia.

On Thu, Sep 8, 2011 at 8:30 AM, Matthew Kaufman
<[email-masked]> wrote:
>> horrible pain of choosing something else, or why throw the app developers to
>> the wolves to fend for themselves?
>>
>> However...
>>
>> piece that almost any application would need, and while not perfect, SDP O/A
>> is a zillion times simpler than SIP with all the extensions one could use.
>
> unrelated arguments to have... and not baking a SIP phone into the browser
> is *more* important than avoiding a repeat of the offer/answer problems.
>
>>
>> The other thing that swayed me was thinking about federation and the apps
>> that will be built with this.  A webrtc app talks to its (web)server, other
>> webrtc clients running the app that talk to the server, and to other webrtc
>> applications/networks that federate with it (and their clients).
>>
>> Federation is in the same hands as the person who provides/wrote the app.
>>  If they have no interest in federation you can't force it, and they may
>> have no use for all the fancy SIP standards.
>
>> communication net that is the PSTN network, now or in the future, or they
>> want easy federation with other networks, it behooves them to use SIP or
>> something very close to it or equivalent/convertible (at a basic level at
>> least) to it.
>>
> cost in lack of flexibility and functionality. Still not nearly as bad as if
> we put a full SIP stack in there though.
>
>>
> I would be open to looking at this again, *after* RTC is already in browsers
> and successful, to see if it actually solves a real use case.
>
> Matthew Kaufman
>

---

From: Christopher Blizzard <[email-masked]>
Date: Wed, 07 Sep 2011 09:07:43 -0700

> reported to users and also be understandable and meaningful to users.

Indeed.  It suffers from the same problem that self-signed certs suffer 
from.  That is, you can't guarantee end to end encryption unless you 
know who you are talking to.  And in our current system requires 3rd 
party signings to do that, which as we've seen over the last couple of 
weeks is not always...great.

Do we want to try and tackle that here?  (I'm guessing not!)

--Chris

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Thu, 8 Sep 2011 10:04:55 +0530

Matthew,

Could you please let me know why early media MUST exist in browser to
browser communication. Remote ringback (18x with SDP) is less used in
lot of existing SIP deployments as well. I'm talking about RFC 3261 User
Agent (UA) functionality in browser which helps browser to browser
real-time communication using RTCWeb1.0. SIP phone is very different
from SIP UA which is using HTTP as a configuration interface. 

Also, RTCWEB client + RTCWeb server makes to feel a modern exchange in
web world (Plain Old Telephony System phone with exchange architecture).
I think so because POTS phones are dumb which does not know its identity
and every event like offhook, onhook has to passed to exchange whereas
RTCWeb client (browser) has to pass every event to webserver and
webserver has whole intelligence to make it work. In case it is local
exchange (same site like skype), there will be no need of signaling but
the identity is outside the single site, it is not defined and it is
outside the scope of RTCWEb.

Please read inline.

Thanks

Partha

From: Matthew Kaufman [mailto:[email-masked]] 
Sent: Thursday, September 08, 2011 3:53 AM
To: Ravindran Parthasarathi
Cc: [email-masked]; [email-masked]
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote
recording - RTC-Web client acting as SIPREC session recording client]

Matthew,

The basic reason for asking SIP is to make the basic call works between
browser to browser across web servers.

[Partha] Please explain in more detail why so.

Totally disagree.

True. But having to reverse-engineer out the phone part is really
painful for the application developer who is trying to build something
else.

[Partha] I have worked in multiple SIP UA implementation which is not
restricted to telecom or unified communication as part of one of best
selling SIP UA stack company. I'm really wondering why phone to be
reverse Engineered. I'm wondering why browser is not possible to acts as
SIP UA. 

SIP makes browser more intelligence compare to dump signaling mechanism
like MEGACO and browser acts as MG. 

[Partha] I'm talking abt SIP UA framework which provides Javascript API.
There is no flexibility issue here because Javascript API will have all
the control which you are interested.

The importance of basic call interop is that there is no need of many
individual id like skype id, Google id  and yahoo id by everyone in the
world to communicate others. I wish to have single id like e-mail id to
be maintained by browser-to-browser users to communicate with others. 

[Partha] they are different.

SIP helps to interop for basic call with other existing realtime
application in Enterprise & Telecom provider.

There is no need to build two different signaling logic in VoIP servers
for each service. Your own example of Bridge line appearance will need
two implementation by the single vendor because desktop application or
hardphone implementation based on SIP and browser based implementation
is depend on HTTP metadata. It is possible to avoided by having one
signaling protocol.

 

In RTCWEB does not standardize the signaling protocol interface between
browsers, the interop across webservers is next to impossible

[Partha] Please note that I'm talking about viewer about partha.com to
start the real-time communication with partha with his (Android) browser
if they are interested. To achieve this, partha.com webdeveloper has no
need to build call control in case SIP exists in both browsers. 

See above.

Matthew Kaufman

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Thu, 8 Sep 2011 10:39:53 +0530

Harald,

For browser as a SIP UA application, browser has to no need to compliant
with 269 pages of RFC 3261 as proxy core is irrelevant to it. I also
agree with you that browser-to-browser communication, I could not see
the strong reason for supporting S/MIME. As part of the RTCWeb
architecture & solution, we will able to explore the SIP UA requirement
for making browser SIP compliant. Say for example, forking does not make
sense in case of browser as SIP UA application, forked response will be
rejected with CANCEL in browser without Javascript intervention. The
main requirement is to build the right SIP UA framework in browser by
which Javascript developer will be able to use to the maximum extent
without impacting the basic 2 two party communication in the internet.  

As mailed in another thread, RTCWEB client + RTCWeb server makes to feel
a modern exchange in web world (Plain Old Telephony System phone with
exchange architecture). I think so because POTS phones are dumb which
does not know its identity and every event like offhook, onhook has to
passed to exchange (webserver) whereas RTCWeb client (browser) has to
pass every event to webserver and webserver has whole intelligence to
make it work. I got this feel more when someone is talking about MEGACO
or MGCP between RTCWEB client & webserver. My understanding is that SIP
does not fit well to legacy telephone-based paradigm by any means but
MEGACO or MGCP are the better choice which maps to SS7 architecture
well. I'm interested in seeing RTCWeb client perform the basic routing
rather than webserver does the routing on behalf of RTCWEb client.

I agree with you that in case it is local exchange (same site like skype
or Google hangout) communication, there will be no need of signaling but
I'm interested in communication with one of the Google real-time user in
internet without having any Google id.  I believe that SIP will make it
work.

Thanks

Partha

From: Harald Alvestrand [mailto:[email-masked]] 
Sent: Wednesday, September 07, 2011 11:13 PM
To: Ravindran Parthasarathi
Cc: Matthew Kaufman; [email-masked]; [email-masked]
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote
recording - RTC-Web client acting as SIPREC session recording client]

Matthew,

The basic reason for asking SIP is to make the basic call works between
browser to browser across web servers. Without SIP in browser, it is not
going happen. Innovative application is going to be proprietary whether
it is HTTP or SIP or any other protocol for that matter.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 8 Sep 2011 07:43:14 +0200

8 sep 2011 kl. 00:39 skrev Randell Jesup:

> I'm assuming the signalling is occurring as SIP over an HTTPS connection to the server, or SIP-over-TLS - haven't really given it a lot of thought other than this connection is securable is we start with an HTTPS connection to the server.

That only guarantees confidentiality the first hop of signalling, provided that the TLS certificates was properly verified. That's a long way from assuming that signalling is secure.

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 8 Sep 2011 07:48:01 +0200

8 sep 2011 kl. 02:14 skrev Paul Kyzivat:

> Of course this can all be dealt with via proper definition of what the UI indication means, and doesn't mean. But doing that will just render it meaningless to many users. To be widely understood, the indication will need to be simple, and closely aligned with what people "expect".
> 
> Consider a stream that is secured to a PSTN gateway, and then travels over the PSTN to somebody's phone. Should that be considered a "secure" call? Or an "insecure" call? Or somewhere between those?
> 
> Its going to be hard work to figure out what can both be reliably reported to users and also be understandable and meaningful to users.
> 
Agree. I see your way of thinking as an argument to make all sessions confidential, encrypted by default. We can't reliable define a "secure call" and separate insecure sessions from secure sessions. Which mean that a UI indication won't mean anything. We can just make sure that the first hop is protected, the rest is up to the application that operates the media session.

/O

---

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 8 Sep 2011 07:51:08 +0200

> They use SIP with web sockets.

Nice. That will make it easy to hook in the rtcweb/webrtc media layer.

Now, I don't see clearly if you want to argue for or against SIP as part of rtcweb standards with these examples, but that may be my biased eyes reading... ;-)

/O

---

---

From: Silvia Pfeiffer <[email-masked]>
Date: Thu, 8 Sep 2011 16:19:32 +1000

I'm arguing for leaving it out, since obviously it's already possible
to support it in the browser through web sockets. We wouldn't put
SMPTE support into browsers either just to be able to read email in
browsers.

I wonder: if you are arguing for it, what is it that is not possible
with such a JS implementation that would require introduction of a
totally new technology into the browser (with all associated security
risks)?

Silvia.

On Thu, Sep 8, 2011 at 3:51 PM, Olle E. Johansson <[email-masked]> wrote:
> Now, I don't see clearly if you want to argue for or against SIP as part of
> rtcweb standards with these examples, but that may be my biased eyes
> reading... ;-)
> /O
>
> Cheers,
> Silvia.
>
>

---

From: Randell Jesup <[email-masked]>
Date: Thu, 08 Sep 2011 02:21:04 -0400

> That only guarantees confidentiality the first hop of signalling, provided that the TLS certificates was properly verified. That's a long way from assuming that signalling is secure.

Well, as this is rtcweb, the application knows it's talking to the 
service associated with the app directly, so there should be no 
intermediaries in the SIP fashion between the app and the service it 
provides.  I hadn't meant to have my statement apply to "federated" 
connections between services, which is where your objection would 
primarily come in.  (There is the issue of "can someone spoof 
https://foo.com/"; the answer *should* be no, and if so then that first 
hop is secure).

But this may be moot anyways given my response to Jonathan Lennox on 
this topic about Cap-Neg (shudder).

-- 
Randell Jesup
[email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Sep 2011 08:35:04 +0200

Hi,

>>>Signalling is secure, so it could even use a direct 
>>>optional downgrade from SAVP* to AVP* (i.e.
>>The solution MMUSIC has standardized for best-effort SRTP 
>>is SDP CapNeg, RFC 5939.  Do we want to require CapNeg 
>>support in browsers?
> 
>Yeah, ok, I'm not going there.  :-)  It's probably not needed 
>for this use-case anyways.

The same question exists for AVPF, which has been suggested to be mandated.

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 08 Sep 2011 08:53:23 +0200

On 09/08/2011 07:09 AM, Ravindran Parthasarathi wrote:
>
> Harald,
>
> For browser as a SIP UA application, browser has to no need to 
> compliant with 269 pages of RFC 3261 as proxy core is irrelevant to 
> it. I also agree with you that browser-to-browser communication, I 
> could not see the strong reason for supporting S/MIME. As part of the 
> RTCWeb architecture & solution, we will able to explore the SIP UA 
> requirement for making browser SIP compliant.
>
So you're advocating for creating a "SIP lite" subset that RTCWEB 
browsers implement.
I think we have been down this road before, and it's not a happy one.
But sure - if you want us to implement some part of SIP, *please start 
stating what part* rather than making wooly statements.

Subsets are Real Hard Work.
>
> Say for example, forking does not make sense in case of browser as SIP 
> UA application, forked response will be rejected with CANCEL in 
> browser without Javascript intervention. The main requirement is to 
> build the right SIP UA framework in browser by which Javascript 
> developer will be able to use to the maximum extent without impacting 
> the basic 2 two party communication in the internet.
>
> As mailed in another thread, RTCWEB client + RTCWeb server makes to 
> feel a modern exchange in web world (Plain Old Telephony System phone 
> with exchange architecture). I think so because POTS phones are dumb 
> which does not know its identity and every event like offhook, onhook 
> has to passed to exchange (webserver) whereas RTCWeb client (browser) 
> has to pass every event to webserver and webserver has whole 
> intelligence to make it work.
>
Don't forget that the RTCWEB client (the browser) contains an open, 
fully programmable application platform - the Javascript engine. That's 
a HUGE difference to the POTS phone.
>
> I got this feel more when someone is talking about MEGACO or MGCP 
> between RTCWEB client & webserver. My understanding is that SIP does 
> not fit well to legacy telephone-based paradigm by any means but 
> I agree with you that in case it is local exchange (same site like 
> skype or Google hangout) communication, there will be no need of 
> signaling but I'm interested in communication with one of the Google 
> real-time user in internet without having any Google id.  I believe 
> that SIP will make it work.
>
If by saying "the Google real time user in Internet", you mean a Google 
Talk user, you have that already. It's called Google Voice. It uses SIP, 
but not in the browser.

Talking to someone who doesn't want to talk to you is an use case we 
don't intend to support.
>
> Thanks
>
> Partha
>
> *From:*Harald Alvestrand [mailto:[email-masked]]
> *Sent:* Wednesday, September 07, 2011 11:13 PM
> *To:* Ravindran Parthasarathi
> *Cc:* Matthew Kaufman; [email-masked]; [email-masked]
> *Subject:* Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: 
> Remote recording - RTC-Web client acting as SIPREC session recording 
> client]
>
> SIP makes browser more intelligence compare to dump signaling 
> individual id like skype id, Google id  and yahoo id by everyone in 
> the world to communicate others. I wish to have single id like e-mail 
> id to be maintained by browser-to-browser users to communicate with 
> others.
>
> This only makes sense for applications that fit the "call an 
> identified party" paradigm.
>
> There is no need to build two different signaling logic in VoIP 
> let  me know in case I'm missing something here.
>
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 8 Sep 2011 09:13:39 +0200

> totally new technology into the browser (with all associated security
Oh, if you mean me I apologize for not being clear. I don't want SIP in rtcweb at all. Your examples are good examples on my way of thinking about rtcweb as a media layer for separate apps. That I want SIP to power those apps is a another issue :-)

/O

---

---

From: Silvia Pfeiffer <[email-masked]>
Date: Thu, 8 Sep 2011 18:46:36 +1000

> Oh, if you mean me I apologize for not being clear. I don't want SIP in rtcweb at all. Your examples are good examples on my way of thinking about rtcweb as a media layer for separate apps. That I…

Sorry. :-)
I was speaking to the larger community on this list, not you
personally when I said that. Apologies.
I think we totally agree.

Cheers,
Silvia.

---

From: Michael Procter <[email-masked]>
Date: Thu, 8 Sep 2011 10:33:54 +0100

Paul, Olle,

Both of you correctly point out that determining when a session is
secure is a very hard problem - one that is nigh-on impossible except
for certain restricted scenarios.  But I think we may have missed the
change of emphasis in Chris' proposed UI change.  Instead of marking a
session as secure (which is hard to determine), he is suggesting
marking it as insecure (which is easier!).

If the signalling and media entering and leaving the browser are not
secured by an appropriate mechanism, then the session should be marked
as 'insecure'.  If they are secured, then Chris' proposal would have
no indication on the browser, which intuitively seems to match what we
know about the session - secure to the server but 'who knows' after
that.  Whether that is good enough for you will depend on whether you
trust the service you are using.

Michael

On 8 September 2011 06:48, Olle E. Johansson <[email-masked]> wrote:
>> Of course this can all be dealt with via proper definition of what the UI
>> indication means, and doesn't mean. But doing that will just render it
>> meaningless to many users. To be widely understood, the indication will need
>> to be simple, and closely aligned with what people "expect".
>>
>> Consider a stream that is secured to a PSTN gateway, and then travels over
>> the PSTN to somebody's phone. Should that be considered a "secure" call? Or
>> an "insecure" call? Or somewhere between those?
>>
>> Its going to be hard work to figure out what can both be reliably reported
>> to users and also be understandable and meaningful to users.
>>
> Agree. I see your way of thinking as an argument to make all sessions
> confidential, encrypted by default. We can't reliable define a "secure call"
> and separate insecure sessions from secure sessions. Which mean that a UI
> indication won't mean anything. We can just make sure that the first hop is
> protected, the rest is up to the application that operates the media
> session.
> /O

---

From: Tim Panton <[email-masked]>
Date: Thu, 8 Sep 2011 10:38:48 +0100

> 1)      SIP makes browser more intelligence compare to dump signaling mechanism like MEGACO and browser acts as MG.

You'd be astonished what you can implement in javascript, just because it isn't baked into the browser,
it doesn't mean the protocol will be dumb. Take a look at how phono.com does XMPP for a proof by example.

> 2)      The importance of basic call interop is that there is no need of many individual id like skype id, Google id  and yahoo id by everyone in the world to communicate others. I wish to have sin…

Be very careful what you wish for. You really don't want the users of a virtual video phone in Habbo Hotel to be able to accidentally call an adult Chatroulette service just by typing the right SIP address. Web services represent 
communities with rules, any interop between those services needs to be centrally authorised.

> 3)      SIP helps to interop for basic call with other existing realtime application in Enterprise & Telecom provider.

It really doesn't . I'd guess a very small % of SIP endpoints are directly exposed to the internet, almost all are behind some sort of SBC, adding a permissioning and auth filter layer.

> 4)      There is no need to build two different signaling logic in VoIP servers for each service. Your own example of Bridge line appearance will need two implementation by the single vendor becaus…

The classic VoIP use-case is only a small (and diminishing) part of the ways that rtcweb will be used. 
Rtcweb will typically provide additional features to a community, not be the focus itself. Look at audio in second-life
as an example, it adds to the experience, but SL existed and works without it. (And that's salient, SL is still one of
the biggest providers of wideband calls!)

> In RTCWEB does not standardize the signaling protocol interface between browsers, the interop across webservers is next to impossible and it will be restricted to single webserver (company) only. P…

Sites who's users wish to interop will do so via XMPP, SIP or SS7 or IMS or whatever is appropriate.
(A small GSM cell operator providing a portal app might choose to interop at the SS7 level to gain billing etc)

Sites that don't wish to interop won't and it should not be forced on them. I don't want my bank calling my second life avatar.

Tim.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 8 Sep 2011 11:45:27 +0200

> communities with rules, any interop between those services needs to be centrally authorised.
..or not authorised. Regardless, the decision about that is not in scope for rtcweb in my opinion.

> It really doesn't . I'd guess a very small % of SIP endpoints are directly exposed to the internet, almost all are behind some sort of SBC, adding a permissioning and auth filter layer.
We can discuss for along time why SIP isn't used on the open Internet - but that's just a good example on why we need to follow Skype and secure all media streams. Hopefully we can build an open federation of SIP services somewhere down the road, like the existing open XMPP federation. That's in my opinion also out of scope of rtcweb.

> Sites that don't wish to interop won't and it should not be forced on them. I don't want my bank calling my second life avatar.

Hmm. Do you have a trust problem with the bank or the avatar? ;-)

Agree that we need to keep rtcweb focused on the media handling and let the application developers decide on signalling model. Personally, I need it to interface with SIP and XMPP platforms so selecting either one for inclusion in rtcweb would mean that I have to add gateways, which is never a good solution.  Let's try to keep signalling out of scope for the rtcweb project.

/O

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 8 Sep 2011 08:21:17 -0400

Indeed.

More generally, the question is: should it be possible to send an offer that by default does DTLS/SAVPF for RTCWeb, but also can fall back to other RTP profiles to support legacy devices?

If yes, then either browsers need to support CapNeg, or RTCWeb needs to use something other than SDP Offer/Answer.

If no, then supporting interop, without a media gateway, with other non-RTCWeb modes (e.g., no ICE, no rtcp mux, no audio/video mux, etc.) becomes IMO a lot less compelling.
	
-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Thursday, September 08, 2011 2:35 AM
To: Randell Jesup; Jonathan Lennox
Cc: [email-masked]
Subject: AVPF [was: [rtcweb] Encryption mandate (and offer/answer)]

Hi,

>>>downgrade from SAVP* to AVP* (i.e.
>>The solution MMUSIC has standardized for best-effort SRTP is SDP 
>>CapNeg, RFC 5939.  Do we want to require CapNeg support in browsers?
> 

Regards,

Christer

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 08 Sep 2011 09:55:01 -0400

Finally, I am getting an answer to my question!  Thanks, Silvia!

One question: Is it possible to get the full library source code?  (I 
cannot find the this.phone.dial code, but this is the one that sends the 
INVITE as far as I figured out.  Most important, I cannot find how 
notifications are handled.)

Igor

|
|

---

From: Tim Panton <[email-masked]>
Date: Thu, 8 Sep 2011 15:01:29 +0100

On 8 Sep 2011, at 14:55, Igor Faynberg wrote:

> One question: Is it possible to get the full library source code?  (I cannot find the this.phone.dial code, but this is the one that sends the INVITE as far as I figured out.  Most important, I cannot find how notifications are handled.)
> 
> Igor

The full source code is at: https://github.com/phono/PhonoSDK

Tim.

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 08 Sep 2011 10:04:24 -0400

On 9/8/2011 2:53 AM, Harald Alvestrand wrote:
...
> stating what part* rather than making wooly statements.

I thought I had already proposed a subset: INVITE, SUBSCRIBE/NOTIFY, and 
REFER.

Igor

---

From: Sohel Khan <[email-masked]>
Date: Thu, 8 Sep 2011 07:28:38 -0700 (PDT)

I did not receive a Meeting Bridge or Webex link for Sept 8th virtual meeting.
If anyone can forward the link, I would appreciate.
Thanks. 

Regards,
Sohel Khan

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 08 Sep 2011 16:30:26 +0200

On 09/08/11 16:04, Igor Faynberg wrote:
>> But sure - if you want us to implement some part of SIP, *please 
>> start stating what part* rather than making wooly statements.
>
> I thought I had already proposed a subset: INVITE, SUBSCRIBE/NOTIFY, 
> and REFER.

That's the commands. What are the parameters?

As I've said before, unless I've misunderstood what SUBSCRIBE/NOTIFY are 
for (I think they are just for presence), I want them totally outside 
the scope of RTCWEB; they are appropriate for implementation in 
Javascript if someone needs them.

I don't know what REFER is for well enough to have an opinion of whether 
it's relevant.

              Harald

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 8 Sep 2011 07:44:48 -0700

Harald said:

    "As I've said before, unless I've misunderstood what SUBSCRIBE/NOTIFY
    are for (I think they are just for presence), I want them totally
    outside the scope of RTCWEB; they are appropriate for implementation
    in Javascript if someone needs them."

    [BA] I had thought that someone posted a link to a SIP Javascript library that was designed to be used with jquery (similar to Strophe, but for SIP).  Has there been an argument demonstrating that this *has* to be native?  Overall, I'm not sure why we're having this discussion.

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 08 Sep 2011 10:54:58 -0400

Well,  maybe we should take it off-line--I will be happy to explain a 
few things in October. Just some in-line answers:

> That's the commands. What are the parameters?

My proposal is to populate the methods with parameters in the JavaScript 
application.
>
> As I've said before, unless I've misunderstood what SUBSCRIBE/NOTIFY 
> are for (I think they are just for presence), 

No, no, no! Not just for presence, although it can be used for presence. 
  These precious methods came from PINT, how could you forget this! 
  They allow the client to subscribe for an event at the server and then 
receive notifications asynchrously.  This specific feature cannot be 
implemented using HTTP (just as INVITE cannot).  We used them in PINT 
pretty much to enable the client to learn when PSTN call is 
disconnected, but the SIP group had found many other uses later.

Again, my objective is to ensure that SIP (with all its bell and 
whistles) can be supported by a JS application.  I am just starting to 
study the code kindly sent my way a few minuts ago, but when I am 
convinced that this can be done based on WebSocket alone, I will stop 
harping on this.

Igor

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 08 Sep 2011 10:56:09 -0400

Yes, I just got the link, and I am studying the code.

> [BA] I had thought that someone posted a link to a SIP Javascript 
> library that was designed to be used with jquery (similar to Strophe, 
> but for SIP).  Has there been an argument demonstrating that this 
> *has* to be native?  Overall, I'm not sure why we're having this 
> discussion.

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Thu, 8 Sep 2011 20:28:20 +0530

Harald,

I'm talking about INVITE subset only.

Thanks

Partha

From: Harald Alvestrand [mailto:[email-masked]] 
Sent: Thursday, September 08, 2011 8:00 PM
To: [email-masked]
Cc: Ravindran Parthasarathi; Matthew Kaufman; [email-masked]
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote
recording - RTC-Web client acting as SIPREC session recording client]

...

             Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 08 Sep 2011 17:01:09 +0200

On 09/08/11 16:54, Igor Faynberg wrote:
> My proposal is to populate the methods with parameters in the 
> JavaScript application.
It seems that writing up your proposal in enough detail that we can tell 
which parts you intend to have done in Javascript and which parts in 
browser code is an useful exercise, because I just don't seem to get the 
picture.
> No, no, no! Not just for presence, although it can be used for 
> presence.  These precious methods came from PINT, how could you forget 
> this!  They allow the client to subscribe for an event at the server 
> and then receive notifications asynchrously.  This specific feature 
> cannot be implemented using HTTP (just as INVITE cannot).  We used 
> them in PINT pretty much to enable the client to learn when PSTN call 
> is disconnected, but the SIP group had found many other uses later.
If the issue is getting a signal from a Web server to a client, there's 
approximately 100 ways to get notifications from the server to the 
client using HTTP (hanging GET being one of them). Now that WS is 
getting standardized, there will be 101.

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Thu, 8 Sep 2011 20:43:32 +0530

Harald,

I'm proposing for "SIP UA framework for RTCWeb browser", the framework
provides Javascript API. In case you mean the same as "SIP lite". I'm
fine with it. SIP UA framework helps to support two-party communication
from RTCWeb browser and uses HTTP as presence or configuration
interface. 

As I mentioned in the another mail, I'm talking about INVITE subset of
RFC 3261 in browser.  

Thanks

Partha

Sent: Thursday, September 08, 2011 12:23 PM

Harald,

for making browser SIP compliant.

Say for example, forking does not make sense in case of browser as SIP
UA application, forked response will be rejected with CANCEL in browser
without Javascript intervention. The main requirement is to build the
right SIP UA framework in browser by which Javascript developer will be
able to use to the maximum extent without impacting the basic 2 two
party communication in the internet.  

make it work.

I got this feel more when someone is talking about MEGACO or MGCP
between RTCWEB client & webserver. My understanding is that SIP does not
fit well to legacy telephone-based paradigm by any means but MEGACO or
MGCP are the better choice which maps to SS7 architecture well. I'm
interested in seeing RTCWeb client perform the basic routing rather than
webserver does the routing on behalf of RTCWEb client.

 

Thanks

Partha

Matthew,

---

From: Roman Shpount <[email-masked]>
Date: Thu, 8 Sep 2011 11:35:43 -0400

Partha,

What I am failing to understand is what you plan to use SIP for. SIP would
be useful to call a SIP end point on the public IP or behind the same NAT.
If you want to call another SIP end point behind NAT, especially if you need
to use TCP to send ICE offers or security with TLS, you will need an
assistance of some type of server on the public IP. In order for this to
work both server and the client will need to implement something like RFC
5626. This will require building something fairly tricky to essentially
proxy all the SIP requests from the client to all the other SIP points.
Building this is no easier then implementing the same thing using an HTTP
server application which works with a client JavaScript library. If our
primary goal were implementation of Intranet SIP phones, that would be an
acceptable solution. For consumer oriented RTC service this is completely
useless.

On the other hand extending SIP based infrastructure to implement new
functionality is a lot more complex. Adding new features will require
standardization or navigating a large number of conflicting SIP related
specifications which are currently in force. Also, keep in mind that
compliance to a lot of more advanced SIP specifications does not necessarily
imply easy interoperability with existing devices. Compliance to a lot of
those standards require a custom SIP server or SBC which implements them
using a much smaller subset supported by each different SIP device. Bottom
line, adding new features in SIP based environment typically requires a lot
of server development, which is pretty much what will be required for doing
signaling via an HTTP connection.

I will concur that using HTTP with JavaScript is a lot less efficient then
using SIP for both the client and the server, since client will need to
implement more functionality using JavaScript and the server will need to
maintain large number of connections and proxy all the requests, but this is
a drawback of any AJAX based solution. This is something that seems to be
acceptable to the industry and should not be a decisive factor.
_____________
Roman Shpount

On Thu, Sep 8, 2011 at 11:13 AM, Ravindran Parthasarathi <
[email-masked]> wrote:

>  Harald,****
>
> ** **
>
> I’m proposing for “SIP UA framework for RTCWeb browser”, the framework
> provides Javascript API. In case you mean the same as “SIP lite”. I’m fine
> with it. SIP UA framework helps to support two-party communication from
> RTCWeb browser and uses HTTP as presence or configuration interface. ****
>
> ** **
>
> As I mentioned in the another mail, I’m talking about INVITE subset of RFC
> 3261 in browser.  ****
>
> ** **
>
> Thanks****
>
> Partha****
>
> ** **
>
> *From:* Harald Alvestrand [mailto:[email-masked]]
> *Sent:* Thursday, September 08, 2011 12:23 PM
>
> *Subject:* Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote
> recording - RTC-Web client acting as SIPREC session recording client]****
>
>  ** **
>
> On 09/08/2011 07:09 AM, Ravindran Parthasarathi wrote: ****
>
> Harald,****
>
>  ****
>
> with 269 pages of RFC 3261 as proxy core is irrelevant to it. I also agree
> with you that browser-to-browser communication, I could not see the strong
> reason for supporting S/MIME. As part of the RTCWeb architecture & solution,
> we will able to explore the SIP UA requirement for making browser SIP
> compliant.****
>
> So you're advocating for creating a "SIP lite" subset that RTCWEB browsers
> implement.
> ****
> Say for example, forking does not make sense in case of browser as SIP UA
> application, forked response will be rejected with CANCEL in browser without
> Javascript intervention. The main requirement is to build the right SIP UA
> framework in browser by which Javascript developer will be able to use to
> the maximum extent without impacting the basic 2 two party communication in
> the internet.  ****
>
>  ****
>
> As mailed in another thread, RTCWEB client + RTCWeb server makes to feel a
> modern exchange in web world (Plain Old Telephony System phone with exchange
> architecture). I think so because POTS phones are dumb which does not know
> its identity and every event like offhook, onhook has to passed to exchange
> (webserver) whereas RTCWeb client (browser) has to pass every event to
> webserver and webserver has whole intelligence to make it work.****
>
> Don't forget that the RTCWEB client (the browser) contains an open, fully
> programmable application platform - the Javascript engine. That's a HUGE
> difference to the POTS phone.
>
> ****
>
> I got this feel more when someone is talking about MEGACO or MGCP between
> RTCWEB client & webserver. My understanding is that SIP does not fit well to
> legacy telephone-based paradigm by any means but MEGACO or MGCP are the
> better choice which maps to SS7 architecture well. I’m interested in seeing
> RTCWeb client perform the basic routing rather than webserver does the
> routing on behalf of RTCWEb client.****
>
>  ****
>
> I agree with you that in case it is local exchange (same site like skype or
> Google hangout) communication, there will be no need of signaling but I’m
> interested in communication with one of the Google real-time user in
> work.****
> Talk user, you have that already. It's called Google Voice. It uses SIP, but
> not in the browser.
>
> Talking to someone who doesn't want to talk to you is an use case we don't
> intend to support.
>
> ****
>
>  ****
>
> Thanks****
>
> Partha****
>
>  ****
>
> *From:* Harald Alvestrand [mailto:[email-masked]<[email-masked]>]
>
> *Subject:* Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote
> recording - RTC-Web client acting as SIPREC session recording client]****
>
>  ****
>
> On 09/07/11 19:29, Ravindran Parthasarathi wrote: ****
>
> Matthew,****
>
>  ****
>
> When I asked for SIP, I have meant RFC 3261 only.****
>
> This is 269 pages, and has 26 normative dependencies including S/MIME. It's
> not a small dependency.****
>
>
>
>
> ****
>
> going happen. Innovative application is going to be proprietary whether it
> is HTTP or SIP or any other protocol for that matter.****
>
>  ****
>
> My reasoning are as follows:****
>
> like MEGACO and browser acts as MG. ****
>
> Why does that "intelligence" need to be in the browser, rather than in the
> Javascript?
>
>
> ****
>
> world to communicate others. I wish to have single id like e-mail id to be
> maintained by browser-to-browser users to communicate with others. ****
>
> ****
> application in Enterprise & Telecom provider.****
>
> There is no need to build two different signaling logic in VoIP servers for
> each service. Your own example of Bridge line appearance will need two
> implementation by the single vendor because desktop application or hardphone
> implementation based on SIP and browser based implementation is depend on
> HTTP metadata. It is possible to avoided by having one signaling protocol.
> ****
>
> ****
>  ****
> browsers, the interop across webservers is next to impossible and it will be
> restricted to single webserver (company) only. Please let  me know in case
> I’m missing something here.****
>
>
> I think the main thing you are missing is that there are many applications
> that people want to build on top of RTCWEB that are not telephones, and will
> not fit with telephone-based paradigms.****
>
> ** **
>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 8 Sep 2011 11:50:57 -0400

I think we should provide a way in JavaScript API to specify if encryption
is required. We should be able to negotiate an open channel connection as
well as encrypted one, if for not other reason then for debugging. It would
be extremely hard to debug and troubleshoot any issues if all communications
are encrypted.

On the Offer/Answer side of the question, I don't think the question is to
support or not support offer answer. I think what we should try to
accomplish is a JavaScript API that allows to create solutions that will
interop with offer answer. We can have API methods that provide additional
media negotiation capabilities and it will be up to an application to decide
if offer/answer interoperability is required for it or if other more feature
complete or convenient API should be used. Not all the calls originated from
the RTC client will need to be connected to old PSTN devices, but ability to
be able to connect to old PSTN devices without using a media proxy is highly
desired.
_____________
Roman Shpount

On Thu, Sep 8, 2011 at 8:21 AM, Jonathan Lennox <[email-masked]> wrote:

> Indeed.
>
> More generally, the question is: should it be possible to send an offer
> that by default does DTLS/SAVPF for RTCWeb, but also can fall back to other
> RTP profiles to support legacy devices?
>
> If no, then supporting interop, without a media gateway, with other
> non-RTCWeb modes (e.g., no ICE, no rtcp mux, no audio/video mux, etc.)
> becomes IMO a lot less compelling.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Sep 2011 12:02:52 -0400

On 9/8/11 2:21 AM, Randell Jesup wrote:
>>> I'm assuming the signalling is occurring as SIP over an HTTPS
>>> connection to the server, or SIP-over-TLS - haven't really given it a
>>> lot of thought other than this connection is securable is we start
>>> with an HTTPS connection to the server.
>> That only guarantees confidentiality the first hop of signalling,
>> provided that the TLS certificates was properly verified. That's a
>> long way from assuming that signalling is secure.
>>
>
> primarily come in.

How would a user know whether the service he is using is federated or not?

E.g. it may be possible for one user of a service to configure "call 
forwarding" using federation. Other users of the service will not 
necessarily know if they are talking to a user that has federation enabled.

	Thanks,
	Paul

  (There is the issue of "can someone spoof

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Sep 2011 12:19:41 -0400

> trust the service you are using.

I agree that this might provide some utility that isn't otherwise 
achievable. However, trusting the service remains an issue. Big brother 
will probably ensure that most of them have back doors.

	Thanks,
	Paul

> Michael
>
> On 8 September 2011 06:48, Olle E. Johansson<[email-masked]>  wrote:
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Sep 2011 12:26:17 -0400

On 9/8/11 5:38 AM, Tim Panton wrote:

> Sites that don't wish to interop won't and it should not be forced on
> them. I don't want my bank calling my second life avatar.

While I agree with your general point, I can see why my SL avatar might 
want to call my bank. :-)

	Thanks,
	Paul

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Thu, 8 Sep 2011 22:41:17 +0530

In principle, I like your idea.

Thanks
Partha

>From: [email-masked] [mailto:[email-masked]] On
Behalf
>Of Randell Jesup
>Sent: Thursday, September 08, 2011 12:50 AM
>To: [email-masked]
>much SIP would be left anyhow if all semantical control is exposed
>through the API?
>>>
>> Well, I tried to stay neutral but examples likes this makes me not
>want SIP in the browser. DTMF, Early Media, bridge line apperances and
>other PSTN legacy will make the implementation too focused on classical
>telephony and we'll spend too much time implementing features that are
>application specific and we can implement in controlling applications,
>client or server-side.
>>
>> Cullen tried to make a draft with "limited" SIP (maybe "SIP Lite")
but
>it will be hard to protect that from the myriad of extensions that add
>PSTN functionality that's not really needed to set up multimedia calls
>between two browser users. It may be needed for gatewaying to legacy
>systems, but if we don't "stop Olle in the gate" - verbatim translation
>of a Swedish saying that propably doesn't mean much to most people on
>the list - I think we will never be done.
>>
>> Of course, being a SIP developer, I started off with thinking that
SIP
>in the browser was the default route. I am beginning to understand that
>the browser is the user interface part we all need, the media handler.
>We all have different requirements on how to control that media GUI and
>to get anywhere I am beginning to think the logic for signalling to set
>up rendevouz points and manage sessions has to move "somewhere else"
>where we can implement SIP, XMPP or some other protocol that fulfills
>the need of our respective application.
>

---

From: Christopher Blizzard <[email-masked]>
Date: Wed, 07 Sep 2011 22:46:13 -0700

> trust the service you are using.

Yes, this is a great way to put what I was saying.  Thank you!

--Chris

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 08 Sep 2011 15:22:26 -0400

> If the issue is getting a signal from a Web server to a client, 
> there's approximately 100 ways to get notifications from the server to 
> the client using HTTP (hanging GET being one of them). 

I thought  that COMET-like polling is inefficient. Hanging GETs 
require server resources to hold a TCP session o open. Firewalls and IE7 
time out  a GET after 30-60 seconds.

> Now that WS is getting standardized, there will be 101.
>

  101st, seems to be a solution, I agree.  But it has not finished 
standardization, while SIP has.

Igor

---

From: Justin Uberti <[email-masked]>
Date: Thu, 8 Sep 2011 15:29:52 -0400

On Thu, Sep 8, 2011 at 3:22 PM, Igor Faynberg <
[email-masked]> wrote:

> **
> approximately 100 ways to get notifications from the server to the client
> using HTTP (hanging GET being one of them).
>
>

In that case, you start a new hanging GET. If Gmail can work using this
approach, telephony applications should be able to use it too.

> standardization, while SIP has.

I would argue that WebSocket is considerably more mature than WebRTC.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 08 Sep 2011 13:51:34 -0600

On 9/8/11 1:22 PM, Igor Faynberg wrote:
> standardization, 

draft-ietf-hybi-thewebsocketprotocol is close to approve as a Proposed
Standard (discussed on this morning's IESG telechat, still a few issues
to clean up). Not that PS means finalization.

> while SIP has.

SIP is not a full Standard. rfc3261bis, anyone? ;-)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 08 Sep 2011 19:56:56 -0400

According to Article 37 of  Geneva Conventions, I am raising a white 
flag and requesting a 24-hour truce to collect dead and wounded.

I will return to my trench at the expiration of the truce.

Igor

---

From: "Aaron Clauson" <[email-masked]>
Date: Fri, 9 Sep 2011 23:55:49 +1000

Another 2 cents from a SIP person.

I think attempting to incorporate SIP (or Jingle et al) into RTCWeb would be
a bad idea for the reason that it would significantly slow down and
complicate the standard. If SIP is included in RTCWeb then there will need
to be a discussion, already emerging here, about which parts of SIP to
include and all the other intricacies of SIP; transports, sips vs sip,
request routing etc etc. 

Writing a javascript SIP stack is a small task compared to getting the
RTCWeb media capabilities built into browsers. As soon as the first browser
appears that supports RTP then javascript SIP stacks will start popping up
all over the place.

I for one would love to be able to process calls in my browser and to be
able to do it yesterday. Slowing the RTCWeb process down for something that
will take care of itself anyway, namely readily available javascript
signalling libraries, would be a shame.

Aaron

---

From: Justin Uberti <[email-masked]>
Date: Fri, 9 Sep 2011 12:31:14 -0400

This feels like a pretty fundamental question. I thought we were getting
pretty close to a consensus for the signaling mechanism with Cullen's
presentation, but this seems to complicate that significantly.

---

From: Alan Johnston <[email-masked]>
Date: Fri, 9 Sep 2011 12:47:55 -0500

Here's my thinking on this.  We have CapNeg because the default
profile for VoIP and video is unfortunately insecure RTP.  We also
need to have a single pass offer/answer negotiation since this is what
we are used to having.

While I am not in favor of allowing insecure RTP in browsers, I know
some feel this is a requirement.  I do like Chris's suggestion that
SRTP be the default, with no chrome messages trying to indicate the
security of the call, but that if RTP is used, we are universally
agreed that is is very insecure and the browser chrome should make it
very, very clear to the user that their privacy is being disregarded
by the service.

If we make SRTP the default, and allow RTP, we could do the same in
our signaling negotiation.  The default will be SRTP - this can be
expressed in SDP without CapNeg.  Should the RTCWEB clients choose to
instead negotiate RTP, then this could be done with a second SDP
Offer/Answer exchange.  This would provide yet another incentive for
services to use the secure mode.

A signaling gateway could support CapNeg and handle using 3PCC the
AVP/SAVP negotiation outside of RTCWEB.

Otherwise, if we require CapNeg in the browser, this is a large leap
in complexity, and without proven interoperability and deployment of
CapNeg today, a very risky proposition.

- Alan -

On Fri, Sep 9, 2011 at 11:31 AM, Justin Uberti <[email-masked]> wrote:
>> If yes, then either browsers need to support CapNeg, or RTCWeb needs to
>> use something other than SDP Offer/Answer.
>>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 9 Sep 2011 14:01:48 -0400

> services to use the secure mode.

So would it work like this?
Assume participants A (prefers secure) and B (only supports insecure)
A -> B (offer with DTLS/SRTP)
B -> A (answer with 488 or other error)
A -> B (offer with plain old RTP)
B -> A (answer with 200)

I prefer Jingle's way of allowing crypto to be agreed upon in a single o/a
exchange, but this seems OK too.

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 09 Sep 2011 11:11:32 -0700

On 9/9/11 10:47 AM, Alan Johnston wrote:
>    The default will be SRTP - this can be
> Offer/Answer exchange.

I believe you've just designed a downgrade vulnerability.

Matthew Kaufman

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 09 Sep 2011 11:32:39 -0700

> I believe you've just designed a downgrade vulnerability.

 From the CPU perspective, any analogue signal is "insecure" (no matter 
how useful), and the words are interchangeable until something is 
purposely made further insecure or further processed unto digital-only.

Downgrade is recoverable, yet something that leads to collapse of state 
from the VM is not.

--

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 9 Sep 2011 11:35:16 -0700

> I believe you've just designed a downgrade vulnerability.

Unless I'm missing something, if you (a) support an insecure mode and (b) allow
negotiation of insecure vs. secure, there's not really any way to
avoid a downgrade
issue; the attacker can always pretend not to support security and how do you
know better? Obviously, it helps if you can negotiate the use or non-use of
media security over a secure-ish signaling channel, but that doesn't reduce
the threat from the signaling service.

Best,
-Ekr

---

From: Justin Uberti <[email-masked]>
Date: Fri, 9 Sep 2011 14:53:50 -0400

> the threat from the signaling service.

We can of course expose the encryption state to the application so that it
can decide if it wants to proceed with/warn about the downgrade to plain old
RTP.

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 09 Sep 2011 12:05:06 -0700

On 09/09/2011 11:53 AM, Justin Uberti wrote:
>
>
> On Fri, Sep 9, 2011 at 2:35 PM, Eric Rescorla <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     <[email-masked] <mailto:[email-masked]>> wrote:
> We can of course expose the encryption state to the application so 
> that it can decide if it wants to proceed with/warn about the 
> downgrade to plain old RTP.
>

That would be federalization then, not downgrade.

--

---

From: Alan Johnston <[email-masked]>
Date: Fri, 9 Sep 2011 14:23:31 -0500

Ekr is correct.  If we allow RTP, which I think is a mistake, then
there is always a downgrade attack.

My point was that if we must support insecure media, we could avoid
the complexity of CapNeg by not requiring a single pass non-secure
media negotiation.

- Alan -

---

From: Roman Shpount <[email-masked]>
Date: Fri, 9 Sep 2011 15:39:46 -0400

I think RTP vs SRTP should be handled similarly to HTTP vs HTTPS. If the
current session is secure (started by HTTPS) only secure media should be
allowed, or unsecure connections should only be allowed after the user
consent. If the session is started by HTTP, unsecure media should be allowed
since all the signaling is insecure in the first place. Please keep in mind
that secure media is not limited to SRTP. RTP over DTLS is as or more secure
then SRTP.
_____________
Roman Shpount

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 09 Sep 2011 12:46:12 -0700

On 09/09/2011 12:23 PM, Alan Johnston wrote:
> there is always a downgrade attack
>    

Two encrypted states that negotiate with each other is not an attack. 
There is just no obvious equality between the two "when introduced."

Let the federated servers introduce them; otherwise, it's browser to 
browser with the bigger unknown.

Maybe QoS can include syllabic gain performance measurements to test 
that continuously, yet that is forward-thinking for many despite known 
proof.

> On Fri, Sep 9, 2011 at 1:35 PM, Eric Rescorla<[email-masked]>  wrote:
>    
>>>> � The default will be SRTP - this can be
>>>> expressed in SDP without CapNeg. �Should the RTCWEB clients choose to

--

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 09 Sep 2011 12:54:01 -0700

On 09/09/2011 12:39 PM, Roman Shpount wrote:
> I think RTP vs SRTP should be handled similarly to HTTP vs HTTPS.

Then that would be the same footsteps as HTTPS, and many of us silently 
do not want that standardized again.

We want the stateful layer, and all routes HTTPS ends that state ("this 
part is done" despite bis).

> If the current session is secure (started by HTTPS) only secure media 
> should be allowed, or unsecure connections should only be allowed 
> after the user consent.

That's like one-way street that wouldn't support "third-party" (use-cases).

> If the session is started by HTTP, unsecure media should be allowed 
> since all the signaling is insecure in the first place.

We can just use OPTIONS here, so this path is not an "attack".

> Please keep in mind that secure media is not limited to SRTP. RTP over 
> DTLS is as or more secure then SRTP.
> _____________
> Roman Shpount
>
>
> On Fri, Sep 9, 2011 at 3:23 PM, Alan Johnston 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Ekr is correct. �If we allow RTP, which I think is a mistake, then
>     On Fri, Sep 9, 2011 at 1:35 PM, Eric Rescorla <[email-masked]
>     [email-masked] <mailto:[email-masked]>

--

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 9 Sep 2011 22:22:07 +0200

Hi,

In general I agree with Alan that we should try to avoid CapNeg.

Regarding AVPF vs AVP, we also first need to decide whether AVP will be supported in the first place. Then, if we decide to support AVP, we have to make a similar decision whether to use CapNeg or to rely on a "fallback" offer/answer.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan Johnston
Sent: 9. syyskuuta 2011 22:24
To: Eric Rescorla
Cc: Randell Jesup; Jonathan Lennox; [email-masked]
Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]

Ekr is correct.  If we allow RTP, which I think is a mistake, then there is always a downgrade attack.

My point was that if we must support insecure media, we could avoid the complexity of CapNeg by not requiring a single pass non-secure media negotiation.

- Alan -

On Fri, Sep 9, 2011 at 1:35 PM, Eric Rescorla <[email-masked]> wrote:
>>>   The default will be SRTP - this can be expressed in SDP without 
>>> CapNeg.  Should the RTCWEB clients choose to instead negotiate RTP, 
>>> then this could be done with a second SDP Offer/Answer exchange.
>>
> Unless I'm missing something, if you (a) support an insecure mode and 
> (b) allow negotiation of insecure vs. secure, there's not really any 
> way to avoid a downgrade issue; the attacker can always pretend not to 
> support security and how do you know better? Obviously, it helps if 
> you can negotiate the use or non-use of media security over a 
> secure-ish signaling channel, but that doesn't reduce the threat from 
> the signaling service.
>
> Best,
> -Ekr
>

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 09 Sep 2011 13:55:35 -0700

> In general I agree with Alan that we should try to avoid CapNeg.

The only security needed "to avoid" that is the guarantee/certificate of 
the pure software VM process (i.e. OSI); otherwise, CapNeg is hardware 
hacking.

The stateless API is the default capabilities, so there is no carrier 
for some secure state otherwise. Discovery of further capabilities is 
ideal in duration of the carrier.

I find it helpful to munge client and server APIs into one API set 
instead of separate definitions as proof. Capabilities then are just 
driver issues, not application issues.

>>>> � The default will be SRTP - this can be expressed in SDP without
>>>> CapNeg. �Should the RTCWEB clients choose to instead negotiate RTP,

--

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 9 Sep 2011 23:14:03 +0200

What security do we avoid by avoiding CapNeg?

Regards,

Christer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dzonatas Sol
Sent: 9. syyskuuta 2011 23:56
To: [email-masked]
Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]

> In general I agree with Alan that we should try to avoid CapNeg.

The only security needed "to avoid" that is the guarantee/certificate of the pure software VM process (i.e. OSI); otherwise, CapNeg is hardware hacking.

The stateless API is the default capabilities, so there is no carrier for some secure state otherwise. Discovery of further capabilities is ideal in duration of the carrier.

I find it helpful to munge client and server APIs into one API set instead of separate definitions as proof. Capabilities then are just driver issues, not application issues.

> Behalf Of Alan Johnston
>> way to avoid a downgrade issue; the attacker can always pretend not 
>> to support security and how do you know better? Obviously, it helps 
>> if you can negotiate the use or non-use of media security over a 

--

---

From: Randell Jesup <[email-masked]>
Date: Fri, 09 Sep 2011 17:15:24 -0400

> there is always a downgrade attack.

Yes, that's true.  The same issue was involved in the best-effort-srtp 
draft, which unfortunately
was dropped because CapNeg would "solve" it.  (For historical note, it's 
still not "solved"
because CapNeg support is >>>> more complex than best-effort-srtp and 
not generally deployed,
and I doubt ever will be ala SDPng (though I'm not close to status on 
CapNeg.)

Hmmm.  A real downgrade attack requires that the signalling be 
compromised.  I wonder if there
are characteristics of a webrtc transaction that could help avoid this 
sort of attack (for example,
a secondary way out-of-scope here for the app to know ahead of time if 
the target will need to
be downgraded).  Or some way for the service to vouch for the downgrade 
(i.e. wasn't a MITM).
You have to trust the service, but in this case you're doing so to this 
degree anyways.

> the complexity of CapNeg by not requiring a single pass non-secure

There is another option.  I talked about services that wanted to support 
PSTN  could decide if they
were willing to support a downgrade.  The application could know it's 
calling a PSTN gateway and
if it does know that, avoid a media gateway by not offering encrypted 
media.

I see a significant use-case for some services will be calling PSTN 
numbers and services, much
as it is now for VoIP.
Yes, a bunch of new non-legacy services wouldn't use/want it.  But the 
app for a PSTN-using service
could specifically allow it.

So the question comes down to what's the advantage to using unencrypted 
RTP?
1) No media gateway needed.  This is the big one.  Saves on $$$, saves 
on delay (sometimes a lot),
     may save on complexity in a PBX type of situation.
     But is there an issue due to ICE requirements?  If those can't be 
turned off safely too, that kills this
     whole discussion I think.
2) Debug/etc tools work better with RTP.  Not important.
3) May simplify/improve some E911 cases.  Might be important; likely not.

So, effectively it comes down to "is advantage 1 worth the 
complexity/risk?"  Anyone want to defend that
case?

-- 
Randell Jesup
[email-masked]

---

From: Justin Uberti <[email-masked]>
Date: Fri, 9 Sep 2011 17:29:22 -0400

On Fri, Sep 9, 2011 at 5:15 PM, Randell Jesup <[email-masked]>wrote:

> because CapNeg support is >>>> more complex than best-effort-srtp and not
> generally deployed,
> Hmmm.  A real downgrade attack requires that the signalling be compromised.
>  I wonder if there
> are characteristics of a webrtc transaction that could help avoid this sort
> of attack (for example,
> a secondary way out-of-scope here for the app to know ahead of time if the
> target will need to
> I see a significant use-case for some services will be calling PSTN numbers
> and services, much
> as it is now for VoIP.
> Yes, a bunch of new non-legacy services wouldn't use/want it.  But the app
> for a PSTN-using service
> 1) No media gateway needed.  This is the big one.  Saves on $$$, saves on
> delay (sometimes a lot),
>    But is there an issue due to ICE requirements?  If those can't be turned
> off safely too, that kills this

In Quebec City, the mic discussion also noted a use case for enterprises
that want to log communications.

Regarding #1, the ability to avoid media gateways for "contemporary devices"
has been a design requirement from the start. I think we need to have a
clear understanding that this requirement creates serious, unavoidable
problems before jettisoning it.

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 09 Sep 2011 14:34:46 -0700

Real-time is your default security; "to avoid" that in this WG.... 
edited: The only security needed for an API is the guarantee/certificate 
of the pure software VM process (i.e. OSI) ("to avoid CapNeg"); 
otherwise, CapNeg is hardware hacking.

[Not everybody complies with the strictness of nuclear licenses, and 
clarity only goes so far.]

--

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 09 Sep 2011 15:02:29 -0700

On 09/09/2011 02:15 PM, Randell Jesup wrote:
> was dropped because CapNeg would "solve" it.  (For historical note, 
> it's still not "solved"
> be downgraded).  Or some way for the service to vouch for the 
> downgrade (i.e. wasn't a MITM).
> You have to trust the service, but in this case you're doing so to 
> this degree anyways.
>
> There is another option.  I talked about services that wanted to 
> support PSTN  could decide if they
> So the question comes down to what's the advantage to using 
> unencrypted RTP?

The ICE toggle already exists. Perhaps you meant non-media in the 
insecure audio-only state? Also known as high-fidelity.

> complexity/risk?"  Anyone want to defend that

The virtual "stateless" driver supposedly doesn't exist unless you want 
to pass DAE only for CapNeg and rely on object recognition and painful 
convex optimizations.

Again, shape is reliable, not a risk. Do you let the federated-servers 
know these traffic-shapes?

--

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 10 Sep 2011 00:06:02 -0400

This isn't really an rtcweb issue - its a secure media O/A issue.

The exact same thing could arise if we had somebody with an urgent 
desire to do secure media with fallback to insecure media in SIP.
All the arguments against capneg would be exactly the same.

The problem is that people aren't finding capneg a usable solution to 
this problem, just the way that people didn't find SDPng a solution to 
the inadequacies of SDP.

While it is possible for rtcweb to adopt its own solution to the 
problem, that only solves half the problem. And it then creates an 
interop problem with SIP.

The "right" solution is to go back to mmusic for an O/A mechanism for 
secure/insecure media that is more usable than capneg. If its deemed 
that doing this would take too long, and its necessary to do something 
special for rtcweb, then a parallel effort ought to be started to sort 
out how it can interoperate with SIP or anything else that uses O/A.

(The "good" news is that I doubt there are many (any?) deployed uses of 
capneg in SIP for negotiation of secure/insecure media.)

	Thanks,
	Paul

On 9/9/11 5:15 PM, Randell Jesup wrote:
>>> (b) allow

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sat, 10 Sep 2011 09:17:16 +0200

> 3) May simplify/improve some E911 cases.  Might be important; likely not.

911/112 cases might be typical phone calls that *require* confidentiality. In Sweden 112 is used for a lot more than accidents - call the priest, report child abuse and others that really are calls that in now way should be listened-in to by other users on the LAN or the IP network.

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sat, 10 Sep 2011 09:52:01 +0200

> the threat from the signaling service.
Have we solved the issues with a "secure-ish signaling channel" anywhere? I don't think we can assume that they exist in the architecture and build solutions based on that assumption. 

SIP/TLS end2end is still very hard to handle. Single hop is definitely protected assuming that we have a CA trust path that we trust, but mutli-hop is still very hard to assure as being "secure-ish" after all these years with SIP.

HTTPS is not an answer here either, especially not with the deployment of enterprise SSL proxys that fake a site certificate in order to be able to listen-in to the traffic.

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sat, 10 Sep 2011 09:54:59 +0200

9 sep 2011 kl. 21:39 skrev Roman Shpount:

>  Please keep in mind that secure media is not limited to SRTP. RTP over DTLS is as or more secure then SRTP

Interesting. Can you please elaborate? I haven't heard that being stated before and it made me curious.

Thanks,
/O

---

From: Roman Shpount <[email-masked]>
Date: Sat, 10 Sep 2011 07:47:46 -0400

SRTP is a simple media encryption using signaling channel exchanged keys and
salt to do simple counter mode AES with content signing using HMAC-SHA1. It
also implements a dictionary based replay protection. DTLS offers wider
encryption and content signing algorithm selection, end-point handshake
based on certificates, certificate validation using certificate authority.
In general, DTLS offers same protection that TLS does, while SRTP is
simplified and optimized for media.

In regard to the overall discussion, if we want interop with existing VoIP
infrastructure, we need to support RTP with AVP. 99% of all SIP deployments
do not support and cannot support SRTP. None of the wholesale VoIP telephony
carriers support SRTP (some offer VPN or direct interconnects if you care
about privacy). Consumer VoIP companies (like Vonage or Comcast) do not
support or use SRTP for any calls from their customer equipment. In places
were encryption is supported (like Skype) it is often either something
different from SRTP. In order to connect to all those environments without
media proxy we need plain RTP. Otherwise we will need to put a media proxy
(SBC) to connect to them.

Finally, there is a reasonably low expectation of privacy as far as voice
calls are concerned. Most of the PSTN phone calls go over the wire connected
to an unlocked box outside your house. Anybody (and by this I mean anybody
walking down the street) can listen to your calls including emergency ones.
People like to raise security as concern but for 99% of the calls, as well
as for 99% of the web traffic which goes over HTTP vs HTTPS, nobody cares.
_____________
Roman Shpount

On Sat, Sep 10, 2011 at 3:54 AM, Olle E. Johansson <[email-masked]> wrote:

> DTLS is as or more secure then SRTP
>
>

---

From: Matthew Kaufman <[email-masked]>
Date: Sat, 10 Sep 2011 09:22:41 -0700

On 9/10/2011 4:47 AM, Roman Shpount wrote:
> SRTP is a simple media encryption using signaling channel exchanged 
> keys and salt to do simple counter mode AES with content signing using 
> HMAC-SHA1. It also implements a dictionary based replay protection. 
> DTLS offers wider encryption and content signing algorithm selection, 
> end-point handshake based on certificates, certificate validation 
> using certificate authority. In general, DTLS offers same protection 
> that TLS does, while SRTP is simplified and optimized for media.

I think you left out a description of DTLS-SRTP and made other 
simplifications.

>
> In regard to the overall discussion, if we want interop with existing 
> VoIP infrastructure, we need to support RTP with AVP. 99% of all SIP 
> deployments do not support and cannot support SRTP. 

They also cannot complete the ICE STUN handshake that is required to 
prove to the browser that they are willing to accept media.

> None of the wholesale VoIP telephony carriers support SRTP (some offer 
> VPN or direct interconnects if you care about privacy). 

Likewise regarding ICE.

> Consumer VoIP companies (like Vonage or Comcast) do not support or use 
> SRTP for any calls from their customer equipment. 

And again regarding ICE.

> In places were encryption is supported (like Skype) it is often either 
> something different from SRTP. In order to connect to all those 
> environments without media proxy we need plain RTP. 

Even if we need plain RTP, that isn't an argument for SDES-keyed SRTP.

Matthew Kaufman

---

From: Dzonatas Sol <[email-masked]>
Date: Sat, 10 Sep 2011 09:33:53 -0700

> Even if we need plain RTP, that isn't an argument for SDES-keyed SRTP.

SRTP appears useful for subscriptions.

--

---

From: Dzonatas Sol <[email-masked]>
Date: Sat, 10 Sep 2011 11:20:24 -0700

> SRTP appears useful for subscriptions.

Yes, I'm thinking that this WG can say JS *needs* subscriptions to 
virtual dirvers (or at least ABI drivers), and that JS works on RFC.

Is that a bend?

--

---

From: Dzonatas Sol <[email-masked]>
Date: Sat, 10 Sep 2011 11:37:27 -0700

> virtual dirvers (or at least ABI drivers), and that JS works on RFC.

If 16-bit, use ICE, otherwise use 64-bit ABI. Simple?

--

---

From: Dzonatas Sol <[email-masked]>
Date: Sat, 10 Sep 2011 11:45:26 -0700

> If 16-bit, use ICE, otherwise use 64-bit ABI. Simple?

<individual>If 16-bit environment, use ICE; otherwise, use 64-bit 
NAT.</individual>

That was me "talking".

--

---

From: Roman Shpount <[email-masked]>
Date: Sat, 10 Sep 2011 14:52:19 -0400

Yes, I did simplify things quite a bit in regard to *RTP-over-DTLS*, but the
main point was that SRTP is not the only or the most secure media transport
out there.

As far as ICE is concerned, it is backwards compatible with non-ICE end
points. The worst you can end up with (and this is not mandated, but just
the recommended procedure for selecting the default flow in the standard) is
going through a TURN server (if one is available) every time you are talking
to a non-ICE end point. If in the API we provide a way to specify STUN/TURN
servers used for media, we can effectively turn ICE off for some calls.

On the related note, I do think that specifying and providing STUN and TURN
servers should be responsibility of the RTC application developer and not
the browser configuration. TURN server can consume quite a bit of bandwidth
and one can see that they will be provided as a paid service in combination
with RTC application itself.
_____________
Roman Shpount

On Sat, Sep 10, 2011 at 12:22 PM, Matthew Kaufman <[email-masked]
> wrote:

>> SRTP is a simple media encryption using signaling channel exchanged keys
>> and salt to do simple counter mode AES with content signing using HMAC-SHA1.
>> It also implements a dictionary based replay protection. DTLS offers wider
>> do not support and cannot support SRTP.
>>
>
> They also cannot complete the ICE STUN handshake that is required to prove
> to the browser that they are willing to accept media.
>
>
>  None of the wholesale VoIP telephony carriers support SRTP (some offer VPN
>> or direct interconnects if you care about privacy).
>>
>
> Likewise regarding ICE.
>
>
>> something different from SRTP. In order to connect to all those environments
>> without media proxy we need plain RTP.
>>
>

---

From: Matthew Kaufman <[email-masked]>
Date: Sat, 10 Sep 2011 22:41:40 +0200 (CEST)

On Sep 10, 2011, at 11:52 AM, Roman Shpount <[email-masked]> wrote:

> 
> 
> On the related note, I do think that specifying and providing STUN and TURN servers should be responsibility of the RTC application developer and not the browser configuration. TURN server can consume quite a bit of bandwidth and one can see that they will be provided as a paid service in combination with RTC application itself.
> 

I think we need both... In a corporate environment, there might be the desire or need to send everything to a a TURN service operated by the organization, independently of whether or not the service provider operates such services.

Matthew Kaufman

Sent from my iPad

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 10 Sep 2011 16:03:32 -0700

[BA] Can you provide a citation for the assertion that confidentiality could be *required* for an emergency services call?

I am not aware of any such a regulatory requirement in the US. 

From: [email-masked]
Date: Sat, 10 Sep 2011 09:17:16 +0200
To: [email-masked]
Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]

9 sep 2011 kl. 23:15 skrev Randell Jesup:3) May simplify/improve some E911 cases.  Might be important; likely not.

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 11 Sep 2011 02:16:54 +0200

Hi,

>This isn't really an rtcweb issue - its a secure media O/A issue.

Well, it depends. If you are supposed to be able to provide different alternatives (SRTP vs RTP and AVPF vs AVP) simultanously, it might have impact on the browser requirement, and the browser/app API.

>interop problem with SIP.

A send-a-new-offer-if-the-first-offers-fails mechanism would be backward compatible - assuming the offerer can guess why the first offer failed.

Also, using the AVP and RTP profiles, together with attributes that specifies the AVPF and SRTP stuff would also work. Of course, it goes against the current AVPF and SRTP specifications, and since current legacy deployments would not understand such attributes, they would always end up using AVP and RTP.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 10 Sep 2011 21:44:07 -0400

> Well, it depends. If you are supposed to be able to provide different alternatives (SRTP vs RTP and AVPF vs AVP) simultanously, it might have impact on the browser requirement, and the browser/app…

I didn't mean it had no impact on rtcweb. Only that the O/A issues are 
not unique to rtcweb.

> A send-a-new-offer-if-the-first-offers-fails mechanism would be backward compatible - assuming the offerer can guess why the first offer failed.

It *might* work in some cases, but it would be iffy.
If the connection is being federated via SIP, I don't know if the intent 
is that both O/As be done in the same INVITE or int separate INVITEs. 
Each has its own limitations:

If done in a single INVITE, its quite possible that the INVITE with the 
first offer will be rejected entirely, without giving chance for a 2nd 
INVITE. If done as separate INVITEs, there is chance that they might not 
go to the same destination. At the least, that could lead to extended 
setup times.

And, IIRC, that approach was discussed before going with the capneg, and 
was rejected. So that approach *may* violate some RFC, though I don't 
know which one.

	Thanks,
	Paul

>> because CapNeg support is>>>>  more complex than best-effort-srtp and
>> not generally deployed,

---

From: Randell Jesup <[email-masked]>
Date: Sat, 10 Sep 2011 22:03:43 -0400

> Also, using the AVP and RTP profiles, together with attributes that specifies the AVPF and SRTP stuff would also work. Of course, it goes against the current AVPF and SRTP specifications, and since…

I think what you've speced here is basically similar to the 
draft-best-effort-srtp proposal.

-- 
Randell Jesup
[email-masked]

---

From: Stefan Håkansson LK <[email-masked]>
Date: Sun, 11 Sep 2011 10:49:16 +0200

In my mind I had built a slightly different model of how this would work. In essence, the SDP o/a would not be allowed to negotiate encryption or not, that should be set when creating the PeerConnection object:

* The level of media protection to use (NONE, SDES-SRTP or DTLS-SRTP) should be set by the web app when a PeerConnection object is created (possibly part of the configuration string)
* One pre-requisite for the PeerConnection to enter the “open” state (and for streams to be set up) must be that the same level of protection is selected by both peer apps
* We should never allow any SDP o/a to negotiate away from the selected level of protection.

This would work just fine in the most common use cases as it is the same app, served by the same server, running in both browsers, and since support of NONE, SDES-SRTP and DTLS-SRTP in browsers should be mandated. The service provider/app developer decides.

The tricky part would be interop. But if we take the ‘browser to browser, but the app coming from different sources’ case, the two teams developing the apps must communicate any way to make them interop. Agreeing on whether to use NONE, SDES-SRTP or DTLS-SRTP is just one detail to agree on.

Developers of apps to interop with legacy must acquire enough info about the system to interop with to make the right setting of PeerConnection for the specific case.

Remember, the primary target for this activity is browser-to-browser. This should be simple and straightforward for the app developer. That the app developer would have to think a bit more for interop cases is quite OK IMO.

Stefan
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Randell Jesup [[email-masked]]
Sent: Sunday, September 11, 2011 4:03 AM
To: [email-masked]
Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]

--
Randell Jesup
[email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 11 Sep 2011 12:59:50 +0000

I doubt you'd get MMUSIC to change their tune. (pun intended)
They don't seem to accept lack of adoption as an indication that we need an alternative for things.  For example, mandating ICE for IPv4/v6 dual-stack offers.

-hadriel

On Sep 10, 2011, at 12:06 AM, Paul Kyzivat wrote:

> The "right" solution is to go back to mmusic for an O/A mechanism for secure/insecure media that is more usable than capneg. If its deemed that doing this would take too long, and its necessary to do something special for rtcweb, then a parallel effort ought to be started to sort out how it can interoperate with SIP or anything else that uses O/A.
> 
> (The "good" news is that I doubt there are many (any?) deployed uses of capneg in SIP for negotiation of secure/insecure media.)
> 
> 	Thanks,
> 	Paul
>

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Sun, 11 Sep 2011 06:39:03 -0700

> * The level of media protection to use (NONE, SDES-SRTP or DTLS-SRTP) should be set by the web app

Why wouldn't this devolve to, "Don't communicate anything. Instead, try 
to create a PeerConnection with DTLS-SRTP, and when that fails, try to 
create a second one with NONE," in the actual webapp.

Or, more likely, since NONE will have a better chance of working with 
legacy devices, "Try to create a PeerConnection with NONE, and when that 
fails, try to create a second one with DTLS-SRTP." Assuming anyone 
bothers with the second step. Having the choice of SDES-SRTP or 
DTLS-SRTP will also make it more likely people won't bother with either, 
as they won't know which one to use. We can try to create incentives 
with browser chrome, but there's only so much that can do.

---

From: Dzonatas Sol <[email-masked]>
Date: Sun, 11 Sep 2011 09:38:11 -0700

I think the real question is more simple: if 32-bit audio "could be 
*required* for emergency services".

It doesn't seem standard beyond 24-bit, yet I can imagine the filter 
attempt for DSL-to-DTLS.

On 09/10/2011 04:03 PM, Bernard Aboba wrote:
> [BA] Can you provide a citation for the assertion that confidentiality 
> could be *required* for an emergency services call?
>
> ------------------------------------------------------------------------
> From: [email-masked]
> 911/112 cases might be typical phone calls that *require* 
> confidentiality. In Sweden 112 is used for a lot more than accidents - 
> call the priest, report child abuse and others that really are calls 
> that in now way should be listened-in to by other users on the LAN or 
> the IP network.
>
> /O
>
> _______________________________________________ rtcweb mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Mon, 12 Sep 2011 00:53:52 +0530

Peter,

Thanks for forwarding info about draft-ietf-hybi-thewebsocketprotocol. I
started this mail thread to know whether RTCWeb1.0 is a unofficial
RFC3261bis for the line side (endpoint to access server) :-) [I really
don't know the better term for the line side]. Endpoint may be desktop,
smart phone (android), laptop, tablet, CPE, etc.,

Till reading this draft, I assumed websocket as a socket layer for HTTP
and it is bad assumption :-(. In short, browser is able to create two
way communication with webserver (which has globally routable address).
Two browser creating websocket with web servers will be able to
communicate with each other. This architecture exactly fits in SIP world
as
 
                       SIP UA <---->B2BUA<----->SIP UA

And resultant as   browser<---> webserver <----> browser. I tend to
agree with you that Websocket looks as a better choice for this simple
web architecture as there is no need of identity exchange here because
webserver knows and authenticated both browsers with the corresponding
identity. In fact, B2BUA with globally routable address will interop
better with any endpoint for that matter. The difference comes into
picture for federation (interop between servers). I'm not very clear
whether websocket is intended for federation as well or not. Most of the
discussion RTCWeb points to use SIP as a federation protocol which may
change later. I'm interested knowing your view here. For this mail, I
assume that SIP as a federation protocol of RTCWeb1.0 and I'm ready to
change if it is the right thing to do :-)

I'm asking for the single protocol based on my gateway implementation
experience in signaling protocol like SIP, H.323, and basic of MEGACO,
Q.931 (ISDN) etc., My understanding is that mapping of between tow
protocols leads to get the common set in both protocol and under
utilization of specific protocol functionality. The mapping is not
perfect lot of times and one of the example which I know in IETF product
is RFC 3398. It is not possible in RFC 3398 to proper reverse mapping of
cause code for ISUP in case conversion in first gateway converts ISUP to
SIP, second gateway converts is SIP to ISUP, ISUP cause code value in
second gateway is not same what is received in first gateway and this
leads to lot of interop issue which includes passing of reason SIP
header with Q.931 IE recently as per IETF-80 decision (workaround bug
fix). This is not the only mapping failure which I have seen during the
gateway implementation. So, I prefer to look for the strong reason for
putting multiple protocol (SIP, websocket) as a RTCWeb architecture. 

Apart from this, my understanding is that websocket + REST XML is the
best choice in web world but SIP + REST XML is an overkill. My
understanding is based on SIPREC metadata XML design where I explored to
make REST XML which is generic for SIP and other protocols, but I
realized that REST XML is overkill for SIP as it has dialog context in
both server & client. Please let me know your comments on this.

Also, Endpoint shall be single IETF protocol for real-time communication
rather than having two protocols (SIP, websocket) for any application.
It looks inconsistent for Endpoint application to use SIP and Endpoint
browser application to use websocket. IMO, IETF should give some clarity
for better real-time network design here.

Thanks
Partha

Behalf
>Of Peter Saint-Andre
>Sent: Friday, September 09, 2011 1:22 AM

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Mon, 12 Sep 2011 01:43:59 +0530

Hi Aaron,

Javascript SIP stacks (Ex: phono.com) exists already and RTCWeb1.0 is
not a gating factor for those development. My worry is that RTCWeb1.0 is
standardized and then identify the gap in signaling which is not a good
protocol design. It is better to discuss with signaling rather than just
solving media protocol requirement alone. In case any implementation
deployed, the backward compatibility has to be provided till the end of
the product and RTCWeb1.0 is a not an exception.

For the time factor concern, let us work for the quick closer and I have
no disagreement there. But I have problem in case it is mentioned as the
issues will not be solved to meet the WG deadline.

Thanks
Partha

Behalf
>Of Aaron Clauson
>Sent: Friday, September 09, 2011 7:26 PM
>To: [email-masked]
>Subject: Re: [rtcweb] SIP MUST NOT be used in browser?
>

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Mon, 12 Sep 2011 02:36:22 +0530

Hi Roman,

IIUC, SIP 2.0 (RFC 3261) and its extensions are not flexible for public
internet two-party communication and HTTP (websocket) + Javascript is a
better known solution for this communication but less efficient. I tend
to agree with you in case my understanding about your mail is correct. 

My way of looking at this problem solving using websocket with no other
its extension is that the time of market delivery of RTCWeb1.0 without
looking for the future. I'm worried because these sort of deliverables
creates chaos during RTCWeb2.0 wherein RTCweb2.0 will be restricted to
RTCWeb 1.0 to meet backward compatibility. Very good example is not that
folks are not interested in SIP 2.0 with its extensions or SIP 3.0 as
you mentioned below J

Please read inline.

Thanks

Partha

From: Roman Shpount [mailto:[email-masked]] 
Sent: Thursday, September 08, 2011 9:06 PM
To: Ravindran Parthasarathi
Cc: Harald Alvestrand; [email-masked]
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote
recording - RTC-Web client acting as SIPREC session recording client]

Partha,

What I am failing to understand is what you plan to use SIP for. 

[Partha] SIP for real-time communication using IETF standard.

SIP would be useful to call a SIP end point on the public IP or behind
the same NAT. If you want to call another SIP end point behind NAT,
especially if you need to use TCP to send ICE offers or security with
TLS, you will need an assistance of some type of server on the public
IP. In order for this to work both server and the client will need to
implement something like RFC 5626. This will require building something
fairly tricky to essentially proxy all the SIP requests from the client
to all the other SIP points. Building this is no easier then
implementing the same thing using an HTTP server application which works
with a client JavaScript library. If our primary goal were
implementation of Intranet SIP phones, that would be an acceptable
solution. For consumer oriented RTC service this is completely useless.

[Partha]. You are comparing RFC 5626 with
websocket(draft-ietf-hybi-thewebsocketprotocol ). Please correct me here

On the other hand extending SIP based infrastructure to implement new
functionality is a lot more complex. Adding new features will require
standardization or navigating a large number of conflicting SIP related
specifications which are currently in force. 

[Partha] I hope that you are talking about backward-compatibility issue
which I mentioned earlier. Any new protocol looks green for the basic
call and the mentioned supplementary services. While keep adding more
service, HTTP will land in the same place. So, I'm not fully convinced
here. I really don't know why do you think SIP based infrastructure is
complex but I agree with you that SIP API design matters.

Also, keep in mind that compliance to a lot of more advanced SIP
specifications does not necessarily imply easy interoperability with
existing devices. Compliance to a lot of those standards require a
custom SIP server or SBC which implements them using a much smaller
subset supported by each different SIP device. Bottom line, adding new
features in SIP based environment typically requires a lot of server
development, which is pretty much what will be required for doing
signaling via an HTTP connection.

[Partha] I agree with you that SIP interop is not straight forward
because legacy implementation issues but HTTP connection calls new
gateway with new mapping of the protocol. Please note that SIP
normalization in SBC is well established compare to creating new HTTP +
XML metadata to SIP gateways.

I will concur that using HTTP with JavaScript is a lot less efficient
then using SIP for both the client and the server, since client will
need to implement more functionality using JavaScript and the server
will need to maintain large number of connections and proxy all the
requests, but this is a drawback of any AJAX based solution. This is
something that seems to be acceptable to the industry and should not be
a decisive factor.

[Partha] The industry tries to re-use  existing infrastructure for easy
interop but does not mean that it is the best solution and IETF has to
be adopt the same. IETF shall provide the better protocol. The industry
adopts if the right protocol is designed or selected.

_____________
Roman Shpount

On Thu, Sep 8, 2011 at 11:13 AM, Ravindran Parthasarathi
<[email-masked]> wrote:

Harald,

Thanks

Partha

Harald,

Thanks

Partha

Matthew,

---

From: Roman Shpount <[email-masked]>
Date: Sun, 11 Sep 2011 22:45:01 -0400

Not sure if you want to configure TURN servers per organization. It is not
guaranteed that the TURN server will be used for the call. Additionally you
do want TURN server on the public internet, out side of the corporate
network. I think what you are trying to accomplish should be implemented via
proxy. SOCKS5 proxy can be used for media and can be used to enforce
corporate policies. When connecting to an external TURN server, a regular
HTTP proxy can be used, but in this case you normally end up with two
different media relay agents (proxy and a TURN server).
_____________
Roman Shpount

On Sat, Sep 10, 2011 at 4:41 PM, Matthew Kaufman
<[email-masked]>wrote:

> > On the related note, I do think that specifying and providing STUN and
> TURN servers should be responsibility of the RTC application developer and
> not the browser configuration. TURN server can consume quite a bit of
> bandwidth and one can see that they will be provided as a paid service in
> combination with RTC application itself.
> >
>
> I think we need both... In a corporate environment, there might be the
> desire or need to send everything to a a TURN service operated by the
> organization, independently of whether or not the service provider operates
> such services.
>
> Matthew Kaufman
>
> Sent from my iPad
>

---

From: Roman Shpount <[email-masked]>
Date: Sun, 11 Sep 2011 22:58:08 -0400

I guess what I do not understand in this discussion is why do we need to
negotiate all of this in the offer/answer. We need something that can
interop with offer answer, but no more then that. The client JavaScript
application should have control and ability to specify what kind of offer is
generated. We can use the exisitng HTTP connection to get all the additional
restrictions and options for the call. It is normally known to the
application if the security is needed and supported. The functionality of
figuring out device capabilities and user intent of this call (secure call
to the bank or public video chat) should be left to the application and
should not be part of this specification. What's currently is missing is
ability to transmit and receive media. The rest of the features, such as
getting events including new call event from the server, sending events to
the server, maintaining a persistent connection from behind firewall and NAT
is already present in the current web infrastructure. We do not need a new
signaling protocol or standard. We do not need to add an existing signaling
protocol not implemented by the browser such as SIP. It adds no new
functionality and makes standard bigger and more difficult to comply. All
that is needed is media.
_____________
Roman Shpount

On Sun, Sep 11, 2011 at 9:39 AM, Timothy B. Terriberry <
[email-masked]> wrote:

> Why wouldn't this devolve to, "Don't communicate anything. Instead, try to
> create a PeerConnection with DTLS-SRTP, and when that fails, try to create a
> second one with NONE," in the actual webapp.
>
> fails, try to create a second one with DTLS-SRTP." Assuming anyone bothers
> with the second step. Having the choice of SDES-SRTP or DTLS-SRTP will also
> make it more likely people won't bother with either, as they won't know
> which one to use. We can try to create incentives with browser chrome, but
> there's only so much that can do.
>

---

From: Roman Shpount <[email-masked]>
Date: Sun, 11 Sep 2011 23:27:33 -0400

Partha,

What I was saying that even with the current web client infrastructure you
can implement everything you need to create a signaling channel. You can use
a hanging HTTP request technique to send notifications to the client. This
is less efficient then websocket, but this is available and is used by a lot
of applications that implement IM and other real time event notifications.

My main point is that communications using RFC 3261 SIP would be limited to
communications between two clients on the public internet or on the same
natted network. This is useless to a consumer oriented RTC application,
where each end point would be behind its own NAT. To communicate using SIP
from behind NAT you need some types of SIP extensions. The standard that
intends (and somewhat fails) to provide a generic solution for
communications between SIP end points behind NAT is RFC 5626. This is the
only solution that allows support for SIP over TCP and SIP over TLS
(security) from behind NAT. It essentially makes clients proxy all its SIP
requests through a persistent connection to a proxy located on the public
IP. The main downsides of this solution is that I do not know of the single
one actually implemented and available (to be honest we just built one) and
that it still has problems with things like connection reset in the middle
of a SIP transaction. As far as efficiency of this solution is concerned it
is no more network, CPU, or implementation efficient then building an HTTP
to SIP proxy doing the same thing. If web RTC becomes a reality I would see
that someone can take a month or two and implement  such HTTP to SIP proxy
using SIP servlets or a custom module to opensips. This is no more
complicated then that. Once again, this does not even need websockets, but
would certainly benefit from them.

If we go this route we do not need to add anything to HTTP. We do not need
to standardize this. This all falls within an already existing capabilities
of JavaScript and things like XMLHttpRequest. There is nothing for the
standard committee to do in regard to signaling. We will not add any value
by creating new standards here. We can try to adapt SIP for RTC, but in some
sense existing browser environment provides a signaling channel that is
better, more flexible, more robust, secure, and most importantly already
implemented.

As far as working with telephone companies, our best course of action is to
provide something that, with some application knowledge, can be mapped to
SIP. If we want to terminate to the existing telephone network this is the
only course of action. Everything else will result into something were media
would need to be proxied. It does not matter how good or robust protocol we
create here, it will take telephone companies 5-10 years to adopt and
implement it. This is not the time-frame that we can afford.
_____________
Roman Shpount

On Sun, Sep 11, 2011 at 5:06 PM, Ravindran Parthasarathi <
[email-masked]> wrote:

>  Hi Roman,****
> better known solution for this communication but less efficient. I tend to
> agree with you in case my understanding about your mail is correct. ****
>
> ** **
>
> My way of looking at this problem solving using websocket with no other its
> extension is that the time of market delivery of RTCWeb1.0 without looking
> for the future. I’m worried because these sort of deliverables creates chaos
> during RTCWeb2.0 wherein RTCweb2.0 will be restricted to RTCWeb 1.0 to meet
> backward compatibility. Very good example is not that folks are not
> interested in SIP 2.0 with its extensions or SIP 3.0 as you mentioned below
> J****
>
> ** **
>
> Please read inline.****
>
> ** **
>
> Thanks****
>
> Partha****
>
> ** **
>
> ** **
>
> *From:* Roman Shpount [mailto:[email-masked]]
> *Sent:* Thursday, September 08, 2011 9:06 PM
> *Cc:* Harald Alvestrand; [email-masked]
>
> What I am failing to understand is what you plan to use SIP for. ****
>
> *[Partha] SIP for real-time communication using IETF standard.*
>
> SIP would be useful to call a SIP end point on the public IP or behind the
> same NAT. If you want to call another SIP end point behind NAT, especially
> if you need to use TCP to send ICE offers or security with TLS, you will
> need an assistance of some type of server on the public IP. In order for
> this to work both server and the client will need to implement something
> like RFC 5626. This will require building something fairly tricky to
> essentially proxy all the SIP requests from the client to all the other SIP
> points. Building this is no easier then implementing the same thing using an
> HTTP server application which works with a client JavaScript library. If our
> useless.****
> *[Partha]. You are comparing RFC 5626 with
> websocket(draft-ietf-hybi-thewebsocketprotocol ). Please correct me here*
>
> specifications which are currently in force. ****
>
> *[Partha] I hope that you are talking about backward-compatibility issue
> which I mentioned earlier. Any new protocol looks green for the basic call
> and the mentioned supplementary services. While keep adding more service,
> HTTP will land in the same place. So, I’m not fully convinced here. I really
> don’t know why do you think SIP based infrastructure is complex but I agree
> with you that SIP API design matters.*
>
> existing devices. Compliance to a lot of those standards require a custom
> SIP server or SBC which implements them using a much smaller subset
> supported by each different SIP device. Bottom line, adding new features in
> SIP based environment typically requires a lot of server development, which
> is pretty much what will be required for doing signaling via an HTTP
> connection.****
>
> *[Partha] I agree with you that SIP interop is not straight forward
> because legacy implementation issues but HTTP connection calls new gateway
> with new mapping of the protocol. Please note that SIP normalization in SBC
> is well established compare to creating new HTTP + XML metadata to SIP
> gateways.*
>
>
>
> acceptable to the industry and should not be a decisive factor.****
>
> *[Partha] The industry tries to re-use  existing infrastructure for easy
> interop but does not mean that it is the best solution and IETF has to be
> adopt the same. IETF shall provide the better protocol. The industry adopts
> if the right protocol is designed or selected.*
>
>
> _____________
> Roman Shpount
>
> **
>
> [email-masked]> wrote:****
>
> Harald,****
>
>  ****
>
> *Sent:* Thursday, September 08, 2011 12:23 PM****
>
>
> Subsets are Real Hard Work.****
>
> difference to the POTS phone.****
>
> intend to support.****
> https://www.ietf.org/mailman/listinfo/rtcweb****
>
> ** **
>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Mon, 12 Sep 2011 08:33:26 +0200

I think there is no protection against badly written apps. If the 
signaling messages ("SDPs") are not properly protected as an example, 
there is another security hole. People not bothering with protecting 
media may not bother to protect the signaling either.

I also think the default in my model protection (if the app makes no 
input) should be DTLS-SRTP.

Stefan

---

From: Stefan Håkansson LK <[email-masked]>
Date: Mon, 12 Sep 2011 08:36:57 +0200

Agree fully. The SDP o/a is IMO there to set up media streams already 
agreed on (including level of protection) using other means.

On 2011-09-12 04:58, Roman Shpount wrote:
> application should have control and ability to specify what kind of
> offer is generated. We can use the exisitng HTTP connection to get all
> the additional restrictions and options for the call. It is normally
> known to the application if the security is needed and supported. The
> functionality of figuring out device capabilities and user intent of
> this call (secure call to the bank or public video chat) should be left
> to the application and should not be part of this specification. What's
> currently is missing is ability to transmit and receive media. The rest
> of the features, such as getting events including new call event from
> the server, sending events to the server, maintaining a persistent
> connection from behind firewall and NAT is already present in the
> current web infrastructure. We do not need a new signaling protocol or
> standard. We do not need to add an existing signaling protocol not
> implemented by the browser such as SIP. It adds no new functionality and
> makes standard bigger and more difficult to comply. All that is needed
> is media.
> _____________
> Roman Shpount
>
>
> On Sun, Sep 11, 2011 at 9:39 AM, Timothy B. Terriberry
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Why wouldn't this devolve to, "Don't communicate anything. Instead,
>     try to create a PeerConnection with DTLS-SRTP, and when that fails,
>     try to create a second one with NONE," in the actual webapp.
>
>     Or, more likely, since NONE will have a better chance of working
>     with legacy devices, "Try to create a PeerConnection with NONE, and
>     when that fails, try to create a second one with DTLS-SRTP."
>     Assuming anyone bothers with the second step. Having the choice of
>     SDES-SRTP or DTLS-SRTP will also make it more likely people won't
>     bother with either, as they won't know which one to use. We can try
>     to create incentives with browser chrome, but there's only so much
>     that can do.
>
>     _________________________________________________
>     rtcweb mailing list
>     https://www.ietf.org/mailman/__listinfo/rtcweb
>     <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Mon, 12 Sep 2011 12:27:54 +0530

Changing the title for giving the clear context of discussion.

Peter,

 

Thanks
Partha

Behalf

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 12 Sep 2011 09:42:44 +0200

> try to create a second one with NONE," in the actual webapp.

Yes.

> legacy devices, "Try to create a PeerConnection with NONE, and when 
> that fails, try to create a second one with DTLS-SRTP." Assuming 
> anyone bothers with the second step. 

Yes, I believe this is why ekr suggested in his email that 
DTLS-SRTP-only is more likely to result in encrypted connections than 
having both choices available is.

> Having the choice of SDES-SRTP or DTLS-SRTP will also make it more 
> likely people won't bother with either, as they won't know which one 
> to use.

Agree. This is the best reason for not supporting SDES for keying.
> We can try to create incentives with browser chrome, but there's only 
> so much that can do.
Agree.

The best way to evaluate this is "if I was the one sitting in a cafe 
using this, what would I want my browser to do"... and the answer to 
*that* question is "I always want DTLS-SRTP between my browser and the 
other end, or worst case, the gateway". (Even if there seem to be good 
reasons to support plain RTP.)

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 12 Sep 2011 10:32:58 +0200

On 9/12/11 4:45 AM, Roman Shpount wrote:
> Not sure if you want to configure TURN servers per organization. It is 
> not guaranteed that the TURN server will be used for the call. 
> Additionally you do want TURN server on the public internet, out side 
> of the corporate network. I think what you are trying to accomplish 
> should be implemented via proxy. SOCKS5 proxy can be used for media 
> and can be used to enforce corporate policies.

True, but there's no reason why a TURN server couldn't also be used, 
assuming that there is a way to specify a server (and the long-term 
credentials to be used)

SOCKS is particularly bad for UDP, and even SOCKS5 doesn't improve much 
upon that... this does bring up the question of whether or not the use 
cases should be updated to ensure that a client being a SOCKS proxy can 
use RTCWEB.

Matthew Kaufman

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 12 Sep 2011 15:42:20 +0200

I believe in Japan privacy concerns of the caller outweigh the desire to receive all information at the call taker.

Regards

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: 11 September 2011 00:04
To: [email-masked]; [email-masked]
Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]

________________________________
From: [email-masked]
Date: Sat, 10 Sep 2011 09:17:16 +0200
To: [email-masked]
Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]

/O

_______________________________________________ rtcweb mailing list [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Mon, 12 Sep 2011 20:52:17 +0530

Asking for the browser to support SIP is like asking for the OS kernel
to support 100s of SIP specs to cater to various kinds of applications,
instead of implementing what portion of SIP you care about in the
application itself -- it just doesn't look scalable. Even if you want to
experiment with a new SIP header you would have to wait for the browser
vendor to release the new version of the browser or make changes to the
browser code yourself, severely hampering application development.
 
Muthu
 
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ravindran Parthasarathi
Sent: Thursday, September 08, 2011 8:44 PM
To: Harald Alvestrand
Cc: [email-masked]
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE:Remote
recording - RTC-Web client acting as SIPREC sessionrecording client]
 
Harald,

 
Thanks
Partha

 

 

Thanks
Partha

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Sep 2011 09:55:11 -0600

> change if it is the right thing to do :-)

I think that the protocol used for server-to-server federation is a
matter for the service providers and thus is not in scope for RTCWeb.
Some s2s links might use SIP, some might use XMPP/Jingle, etc.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Sep 2011 12:42:15 -0400

> Developers of apps to interop with legacy must acquire enough info about the system to interop with to make the right setting of PeerConnection for the specific case.

I think I can buy this approach up to this point - that the JS in the 
browser can know that something special is required because its an 
interop case.

The harder point is knowing *what* is required in the interop case.
If the goal is to avoid needing a media gateway in this case, then what 
is required will be determined as part of the O/A. Or it can 
contractually negotiated for each different federation target.

Hadriel seems to be arguing that a media gateway will always be needed 
in the federation case. Making that assumption will certainly simplify 
rtcweb, but it also ensures a cost for federation. It is essentially the 
same cost that is incurred when sip users and service providers require 
the use of SBCs at their borders. So far that has been a cost that 
people have willingly paid.

This can be abstracted as a partitioning of the features covered by RFC 
3264 O/A into categories:
- features to be entirely fixed for rtcweb
- features to be chosen/negotiated by the web application using
   application-specific logic and communicated to the browser via JS
   prior to session establishment.
- features to be negotiated via o/a by the browser
- features to be negotiated via o/a in JS running in the browser

Then the discussion has been about people arguing for different 
partitionings - mostly extremes. Some that I am seeing:

1) (Cullen) everything should be negotiated by o/a in the browser.
    (Presumably with some interaction with JS for ICE candidate
    selection.) The logical conclusion of this (I'm not sure Cullen
    is arguing for this) is that capneg must be included and used
    to handle the security negotiation.

2) (Hadriel?) The security mechanism, and use of ICE,
    is fixed for rtcweb. ICE candidate selection and all the
    rest of o/a is handled in JS.

(That is just a stab - sorry if I have mis-characterized. Please jump in 
and correct me.)

This is a fundamental decision to make. When federating, features that 
are chosen prior to session establishment will be the result of private 
agreements and result in a form of balkanization. When federating via 
sip to a target that doesn't have fixed values for features that must be 
pre-agreed, the only option will be a media gateway.

	Thanks,
	Paul

---

From: Dzonatas Sol <[email-masked]>
Date: Mon, 12 Sep 2011 10:14:22 -0700

On 09/12/2011 08:55 AM, Peter Saint-Andre wrote:
>>                         SIP UA<---->B2BUA<----->SIP UA
>>
>> And resultant as   browser<--->  webserver<---->  browser. I tend to

Yesterday I thought browser-hints could help with transitions to 
federation, especially for RTCWeb-to-SIP:

http://tools.ietf.org/html/draft-nottingham-http-browser-hints-02

Thanks.

--

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Tue, 13 Sep 2011 00:11:47 +0530

Peter,

<snip> > I think that the protocol used for server-to-server federation
is a 
> matter for the service providers and thus is not in scope for RTCWeb.
</snip>

Sec 4.2.5 of draft-ietf-rtcweb-use-cases-and-requirements-04 includes
the usecase for federation. My assumption is based on this usecases.
Till now, there is no better protocol than SIP exists for this
discussion.

> </snip>

I agree with you that signaling interop is not focus of RTCWeb and only
one webserver is solution space then your solution looks like working.
Even then, I prefer single signaling protocol rather than ad-hoc
signaling protocol by each web developer.

Dzonatas,

I lean towards SIP federation because of the maturity of the SIP
protocol. Last 10 years of bug fix in SIP stack makes it more stable now
:-) 

Thanks
Partha

Behalf
>Of Dzonatas Sol
>Sent: Monday, September 12, 2011 10:44 PM
>To: [email-masked]
>Subject: Re: [rtcweb] SIP vs Websocket in RTCWeb [was RE: SIP MUST NOT
>be used in browser?]
>

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Tue, 13 Sep 2011 00:27:34 +0530

Hi Muthu,

Browser is yet another application in the system which has the
programming environment using Javascript.  I explained my point of view
in another mail thread:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg01058.html. My
proposal is similar to SIP stack with C or C++ API but RTCWeb API is
designed based on Javascript. Like normal SIP stack, the new headers
shall be added by the use of Javascript API. SIP stack in browser shall
composes of transaction layer, encoding & decoding of the SIP message,
and UAC & UAS functionality mentioned in RFC 3261. I agree that agreed
upon NAT traversal mechanism of signaling protocol has to be supported
for RTCWeb.  Jquery library shall be built for the high level API's.

These sort of SIP framework will scale for any sort innovative real-time
application with better performance compare to any other protocol known
in IETF. As the core SIP stack is build within browser, javascript
programmer will focus on application and not on the protocol
intricacies.

Thanks

Partha

From: Muthu Arul Mozhi Perumal (mperumal) [mailto:[email-masked]] 
Sent: Monday, September 12, 2011 8:52 PM
To: Ravindran Parthasarathi; Harald Alvestrand
Cc: [email-masked]
Subject: RE: [rtcweb] SIP MUST NOT be used in browser?[was RE:Remote
recording - RTC-Web client acting as SIPREC sessionrecording client]

Muthu

Harald,

Thanks

Partha

Harald,

Thanks

Partha

Matthew,

---

From: Jozsef Vass <[email-masked]>
Date: Mon, 12 Sep 2011 14:10:00 -0700

Neither the website nor the documents mention the use of Flash, which is evident if you try the app. They also make use of the acoustic echo cancellation capability available in Flash.

Jozsef

-----Original Message-----
From: Silvia Pfeiffer [mailto:[email-masked]] 
Sent: Wednesday, September 07, 2011 6:16 PM
To: Matthew Kaufman
Cc: [email-masked]
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient]

http://phono.com/
and

Cheers,
Silvia.

On Thu, Sep 8, 2011 at 8:30 AM, Matthew Kaufman <[email-masked]> wrote:
>> through the horrible pain of choosing something else, or why throw 
>> the app developers to the wolves to fend for themselves?
>>
>> However...
>>
>> not perfect, SDP O/A is a zillion times simpler than SIP with all the extensions one could use.
>
> browser is *more* important than avoiding a repeat of the offer/answer problems.
>
>>
>> server, and to other webrtc applications/networks that federate with it (and their clients).
>>
>>  If they have no interest in federation you can't force it, and they 
>> may have no use for all the fancy SIP standards.
>
>> handling new codecs, etc).  It doesn't extremely limit an 
>> application, though we should think about how an application can 
>> interact with the fmtp/etc parameters used.
>
> I agree that it would simplify some interop cases, but at an 
> unfortunate cost in lack of flexibility and functionality. Still not 
> nearly as bad as if we put a full SIP stack in there though.
>
>>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 12 Sep 2011 17:32:28 -0400

Neither do they websockets (they use BOSH
http://xmpp.org/about-xmpp/technology-overview/bosh/) or SIP (at least not
for client to server communications).
_____________
Roman Shpount

On Mon, Sep 12, 2011 at 5:10 PM, Jozsef Vass <[email-masked]> wrote:

> Neither the website nor the documents mention the use of Flash, which is
> evident if you try the app. They also make use of the acoustic echo
> cancellation capability available in Flash.
>
> Jozsef
>
> Remoterecording - RTC-Web client acting as SIPREC session recordingclient]
>
> app.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Sep 2011 15:39:23 -0600

> signaling protocol by each web developer.

Using DNS SRV records, it's easy enough to figure out what protocols are
supported by the peer service with which you want to federate.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: SHANMUGALINGAM SIVASOTHY <[email-masked]>
Date: Mon, 12 Sep 2011 23:51:06 +0200

Hi All!

Some info on signaling protocol

1. Compositional Control of IP Media,  
http://www2.research.att.com/~pamela/cmc.pdf

2. Understanding SIP Through Model-Checking,  
http://www2.research.att.com/~pamela/under2.pdf

In paper [1], she argued that new protocol is better than SIP. The  
comparison includes:
  A. Transaction vs idempotent
  B. Program complexity
  C. Media bundling

  Enjoy reading.

Best regards
Siva

> supported by the peer service with which you want to federate.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 12 Sep 2011 23:17:34 +0000

On Sep 12, 2011, at 12:42 PM, Paul Kyzivat wrote:

> If the goal is to avoid needing a media gateway in this case, then what is required will be determined as part of the O/A. Or it can contractually negotiated for each different federation target.
> 
> Hadriel seems to be arguing that a media gateway will always be needed in the federation case. Making that assumption will certainly simplify rtcweb, but it also ensures a cost for federation. It is essentially the same cost that is incurred when sip users and service providers require the use of SBCs at their borders. So far that has been a cost that people have willingly paid.

I am not arguing a media gateway would always be needed for federation.  I said one would be needed to interface/federate with SIP in the PSTN.  Between two rtcweb domains, no media gateway would/should be required. (there may be one anyway, but hopefully not just to make the call work for interop)

> Then the discussion has been about people arguing for different partitionings - mostly extremes. Some that I am seeing:
> 

Only if SRTP is optional - if it's mandatory to use always, then obviously you don't need cap-neg for it.

>   rest of o/a is handled in JS.

Right - if the rtcweb application as a whole needs to use SDP offer/answer at all, it could do so in the JS or in the server.  The browser should stay the heck away from it.  Browsers should be as dumb as we can keep them.  That's the secret sauce to successful web apps, imho - the client browser is dumb, but the javascript its executing is smart.  The browser doesn't know I'm browsing emails in gmail.  It's just executing code issuing API calls for GUI elements.  If an Operating System came with an RTP library built into it, would you therefor expect the operating system to do SDP offer/answer?  Or would you expect it to expose an API of discrete RTP attributes/settings for the application to interface to and do with as it wished?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 13 Sep 2011 03:50:11 +0000

> Only if SRTP is optional - if it's mandatory to use always, then obviously you don't need cap-neg for it.

Actually I take that back - you'll need cap-neg anyway, so that a SIP call sent to rtcweb can use it in a best-effort manner (ie, in case a SIP peer sends a default m-line with RTP but with cap-neg for SRTP, so that the rtcweb side can process it and answer choosing SRTP).

-hadriel

---

From: Tim Panton <[email-masked]>
Date: Tue, 13 Sep 2011 11:11:33 +0100

Minor nit - Phono isn't  a javascript SIP Stack. It is a javascript XMPP stack.
The server-side gateways out to SIP etc.

Tim.

---

From: Tim Panton <[email-masked]>
Date: Tue, 13 Sep 2011 11:31:46 +0100

Phono does not always use Flash and when it does, it uses flash _only_ to access the media.

Phono is structured as a XMPP implementation in Javascript that handles all the signalling to remote XMPP servers.
It then has what you might think of as an Javascript ServiceProviderInterface layer that provides  the streaming of audio from the microphone/speaker to/from an rtp endpoint. (and nothing else)

Currently there are 3 (or 4) implementations of the SPI, one uses flash, a second uses a java applet. It also has 
plugins for phonegap on iOS and android. All except the flash implementation speak native RTP. 

The important point is that the SPI is the same across all these implementations, so the XMPP layer is independent of the implementation details of the media access . 

I hope that clarifies things.

Tim.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 13 Sep 2011 15:45:43 +0200

> The server-side gateways out to SIP etc.

A major thing is that you call it a minor nit. That is an important observation for the specs.

/O

---

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Tue, 13 Sep 2011 22:14:53 +0530

Tim,

Thanks for pointing it out and my example is wrong. 

My point is that RTCWeb1.0 deliverables is not a gating factor for
Javascript based SIP Stack or other signaling protocol using Javascript.
Also, RTCWeb signaling protocol selection is important for interop. 

Thanks
Partha

>Sent: Tuesday, September 13, 2011 7:16 PM
>To: Tim Panton
>>> not a gating factor for those development. My worry is that
RTCWeb1.0
>is
>>>> complicate the standard. If SIP is included in RTCWeb then there
>will
>>>> need
>>>> appears that supports RTP then javascript SIP stacks will start
>popping
>>>> up
>>>> all over the place.
>>>>
>>>> I for one would love to be able to process calls in my browser and
>to
>>> be
>>>> able to do it yesterday. Slowing the RTCWeb process down for
>something
>>>> that

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 14 Sep 2011 01:05:02 +0530

|Like normal SIP stack, the new headers shall be added 
|by the use of Javascript API. SIP stack in browser 
|shall composes of transaction layer, encoding & decoding
|of the SIP message, and UAC & UAS functionality mentioned 
|in RFC 3261
 
With the browser implementing just 3261 the application will more often
than not end up implementing 3262, 3311, 3515, 3891, 3892, 3265, 5626
etc, depending on what it wants to do. 
 
|As the core SIP stack is build within browser, javascript 
|programmer will focus on application and not on the protocol 
|intricacies.
 
This is not true, unless the programmer has JS libraries for what the
browser doesn't support at his/her disposal. Implementing a portion of
SIP inside the browser doesn't look worth.
 
Muthu  
 
From: Ravindran Parthasarathi [mailto:[email-masked]] 
Sent: Tuesday, September 13, 2011 12:28 AM
To: Muthu Arul Mozhi Perumal (mperumal); Harald Alvestrand
Cc: [email-masked]
Subject: RE: [rtcweb] SIP MUST NOT be used in browser?[was RE:Remote
recording - RTC-Web client acting as SIPREC sessionrecording client]
 
Hi Muthu,

 
Thanks
Partha

 
Muthu

Harald,

 
Thanks
Partha

 

 

Thanks
Partha

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 13 Sep 2011 16:32:27 -0700

> Behalf Of Matthew Kaufman
> Sent: Monday, September 12, 2011 12:43 AM
> To: Timothy B. Terriberry
> Cc: [email-masked]
> >> * The level of media protection to use (NONE, SDES-SRTP or DTLS-
> SRTP)
> >> should be set by the web app
> >

SDES is also not as secure as DTLS-SRTP, reference RFC5479.

-d

---

From: Tim Panton <[email-masked]>
Date: Thu, 15 Sep 2011 10:53:13 +0100

> SDES is also not as secure as DTLS-SRTP, reference RFC5479.

I had my mind rather forcibly changed on this by reading this:
https://www.owasp.org/index.php/File:SSL_paved_with_good_intentions.pdf
and
http://www.slate.com/id/2265204/

Basically any key exchange that depends for it's security on https: is worthless.

Tim (as usual speaking for himself)

P.S. I particularly enjoyed the idea of embedding logos in X509 certs (seems this is valid).

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 20 Sep 2011 16:35:35 -0700

> From: Tim Panton [mailto:[email-masked]]
> Sent: Thursday, September 15, 2011 2:53 AM
> To: Dan Wing
> Cc: 'Matthew Kaufman'; 'Timothy B. Terriberry'; [email-masked]

DTLS-SRTP does not validate certificates at all like HTTPS.

-d

> P.S. I particularly enjoyed the idea of embedding logos in X509 certs
> (seems this is valid).=