Subject: [rtcweb] About defining a signaling protocol for WebRTC (or not)

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 14 Sep 2011 16:56:57 +0200

Hi all,

There are some threads about the need (or not) for a well defined
signaling protocol within WebRTC. I would like to comment about it.

WebRTC defines multimedia capabilities for web-browsers and mandates
protocols as RTP, STUN, ICE, and understanding of SDP (RFC 4566). The
aim of these protocols is to enable multimedia streams between a
web-browser and other endpoint (which could also be a web-browser).

But having the above is not enough since a signaling
protocol/mechanism for managing the media sessions is required (for
requesting a multimedia session to the endpoint, for terminating it,
for putting it in hold...).

Both SIP and XMPP (with Jingle) behave as a signaling protocol and
manage multimedia sessions based on SDP descriptions (SIP uses plain
SDP grammar as defined in RFC 4566 while XMPP uses a XML version of
the SDP format). So both SIP and XMPP could be a good choice. But also
any custom signaling protocol carrying like-SDP information.

If WebRTC mandates a specific signaling protocol then all the web
providers should incorporate such a protocol within their
infrastructure, which seems not feasible for me (let's say web pages
served by hosting datacenters which just provide an Apache server for
the web developer, for example).

So I wonder: why is a specific signaling protocol needed at all? AFAIK
the only we need is an API (within WebRTC) to manage multimedia
sessions (start it, terminate it, use codec XXXX, put on hold...). How
the client application (let's assume the JavaScript code) obtains such
information should be out of the scope of WebRTC. The client
application (JavaScript) just needs to retrieve (via HTTP, WebSocket
or whatever) the "SDP" information provided by the endpoint and use
such data for making API calls to the WebRTC stack by passing as
arguments the remote peer IP, port, type of session, codec to use, and
so on.

For example, if a web page makes usage of SIP over WebSocket or XMPP
over WebSocket, the signaling (also containing SDP information) would
be carried within SIP or XMPP messages. The only reqiremente would be
for the WebSocket server to be integrated within a SIP proxy/server
implementing draft-ibc-rtcweb-sip-websocket or a XMPP server
implementing draft-moffitt-xmpp-over-websocket. The client application
(JavaScript in the web page) should parse the SDP bodies and make
WebRTC calls when appropriate to initiate or answer multimedia
sessions. And then we get full interoperability with SIP/XMPP world
out there (without requiring a server/gateway performing conversion of
application level protocols).

In the same way, other web page which just requires multimedia
sessions between web-browsers, could prefer to implement a simple and
custom JSON format as a signaling mechanism on top of WebSocket (or
use HTTP Comet, long-polling, etc). It could map the SDP definition
into a JSON struct. Again the JavaScript code parses the SDP
information and calls WebRTC API functions to manage multimedia
sessions. The only requirement would be for the HTTP server to
implement WebSocket or HTTP Comet (or nothing if HTTP long polling is
used).

So my proposal is that WebRTC should not mandate a signaling protocol
in the web-browser, but just define a requeriment for managing
multimedia sessions from the JavaScript code given a well defined API.
IMHO this is the way that fits well with the flexibility of the web
and lets each web provider to decide which technology to use as
signaling protocol, rather than forcing him to implement
SIP/XMPP/other-protocol in server side.

Best regards.

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

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 14 Sep 2011 10:39:40 -0500

+1

Thanks, Henry

> Hi all,

There are some threads about the need (or not) for a well
> defined
signaling protocol within WebRTC. I would like to comment about
> it.

WebRTC defines multimedia capabilities for web-browsers and
> mandates
protocols as RTP, STUN, ICE, and understanding of SDP (RFC 4566).
> The
aim of these protocols is to enable multimedia streams between
> a

But
> having the above is not enough since a signaling
protocol/mechanism for
> managing the media sessions is required (for
requesting a multimedia session
> to the endpoint, for terminating it,

Both SIP and
> XMPP (with Jingle) behave as a signaling protocol and
manage multimedia
> sessions based on SDP descriptions (SIP uses plain
SDP grammar as defined in
> RFC 4566 while XMPP uses a XML version of
the SDP format). So both SIP and
> XMPP could be a good choice. But also
any custom signaling protocol carrying
> like-SDP information.

If WebRTC mandates a specific signaling protocol then
> all the web
providers should incorporate such a protocol within
> their
infrastructure, which seems not feasible for me (let's say web
> pages
served by hosting datacenters which just provide an Apache server
> for

So I wonder: why is a specific signaling
> protocol needed at all? AFAIK
the only we need is an API (within WebRTC) to
> manage multimedia
sessions (start it, terminate it, use codec XXXX, put on
> hold...). How
the client application (let's assume the JavaScript code)
> obtains such
information should be out of the scope of WebRTC. The
> client
or
> whatever) the "SDP" information provided by the endpoint and use
such data for
> making API calls to the WebRTC stack by passing as
arguments the remote peer
> IP, port, type of session, codec to use, and
so on.

For example, if a web
> page makes usage of SIP over WebSocket or XMPP
over WebSocket, the signaling
> (also containing SDP information) would
be carried within SIP or XMPP
> messages. The only reqiremente would be
for the WebSocket server to be
> integrated within a SIP proxy/server
implementing
> draft-ibc-rtcweb-sip-websocket or a XMPP server
implementing
> draft-moffitt-xmpp-over-websocket. The client application
(JavaScript in the
> web page) should parse the SDP bodies and make
WebRTC calls when appropriate
> to initiate or answer multimedia
sessions. And then we get full
> interoperability with SIP/XMPP world
out there (without requiring a
> server/gateway performing conversion of

In the
> same way, other web page which just requires multimedia
sessions between
> web-browsers, could prefer to implement a simple and
custom JSON format as a
> signaling mechanism on top of WebSocket (or
use HTTP Comet, long-polling,
> etc). It could map the SDP definition
into a JSON struct. Again the JavaScript
> code parses the SDP
information and calls WebRTC API functions to manage
> multimedia
sessions. The only requirement would be for the HTTP server
> to
implement WebSocket or HTTP Comet (or nothing if HTTP long polling
> is
used).

So my proposal is that WebRTC should not mandate a signaling
> protocol
in the web-browser, but just define a requeriment for
> managing
multimedia sessions from the JavaScript code given a well defined
> API.
and
> lets each web provider to decide which technology to use as
signaling
> protocol, rather than forcing him to implement
SIP/XMPP/other-protocol in
> server side.

Best regards.

-- 
Iñaki Baz
> Castillo
<[email-masked]>
_______________________________________________
rtcwe
> b mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 14 Sep 2011 15:08:53 -0500

+1

On Sep 14, 2011, at 10:39 AM, "Henry Sinnreich" <[email-masked]> wrote:

> rtcweb mailing list

---

From: Roman Shpount <[email-masked]>
Date: Wed, 14 Sep 2011 16:22:16 -0400

+1
_____________
Roman Shpount

---

From: Victor Pascual <[email-masked]>
Date: Wed, 14 Sep 2011 22:59:02 +0200

+1

On Sep 14, 2011, at 10:22 PM, Roman Shpount <[email-masked]> wrote:

> +1
> _____________
> Roman Shpount
> 
> 
> On Wed, Sep 14, 2011 at 4:08 PM, Bernard Aboba <[email-masked]> wrote:
> +1
> 
> 
>

---

From: Prakash <[email-masked]>
Date: Wed, 14 Sep 2011 14:00:44 -0700

+1

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Thu, 15 Sep 2011 00:05:17 +0200

+1

--
Saúl Ibarra Corretgé
AG Projects

---

From: [email-masked]
Date: Thu, 15 Sep 2011 08:58:01 +0800

+1

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: "Avasarala, Ranjit" <[email-masked]>
Date: Thu, 15 Sep 2011 12:52:54 +0800

Agree with you Inaki

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Iñaki Baz Castillo
Sent: Wednesday, September 14, 2011 8:27 PM
To: [email-masked]
Subject: [rtcweb] About defining a signaling protocol for WebRTC (or not)

Hi all,

Best regards.

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 15 Sep 2011 07:51:56 +0200

> multimedia sessions from the JavaScript code given a well defined API.

I think this is exactly what I've been advocating, so I agree as well.

I'd go one step further to say that the "well defined API" shouldn't be 
"SDP offer/answer via events" for negotiating codec parameters, but 
should instead be a way to manage the codec settings, with offer/answer 
or capneg or whatever you want implemented in the Javascript (or up at 
the server, your choice).

Matthew Kaufman

---

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

Hi Inaki,

As your draft draft-ibc-rtcweb-sip-vs-websocket indicates, it is possible for Javascript application to write any signaling protocol and so, there is no blocking factor for innovation in browser platform. I'm seeing the current infrastructure in RTCWeb as "raw socket" in Socket library. The raw socket provides the flexibility and no doubt about it. Also, RTCWeb supports for SIP, XMPP, or some <content> XML using SDP,or some other TLV protocol. 

My point is that the default signaling protocol has to be supported in RTCWeb client which should not be downloaded in runtime to make the dialog between two RTCWeb client. I asked for SIP initially as SIP is the de-facto protocol and mostly deployment. I agree with Peter & others that websocket could be another alternative in the web deployment. In case required, I'll come up the write up to show the needs of default signaling protocol for making dialog between browser to browser.

Please read inline.

Thanks
Partha

>web-browser and other endpoint (which could also be a web-browser).
<partha> I hope that the aim of the protocols is to enable multimedia stream between browser to browser only. In case browser to other end-point is outside the scope of RTCWEb. </partha> 

>any custom signaling protocol carrying like-SDP information.
<partha> I agree with Cullen for his proposal on SDP but I'm not sure whether we will end-up there </partha>

>the web developer, for example).
<partha> Please see the usecase, I have mentioned in http://www.ietf.org/mail-archive/web/rtcweb/current/msg00845.html. The issue in your argument is that you assume web server as RTCWEb server. I agree that it may be preferred but not a MUST item. </partha>

---

From: Soo-Hyun Choi <[email-masked]>
Date: Thu, 15 Sep 2011 16:29:48 +0900

+1

---

From: José Luis Millán <[email-masked]>
Date: Thu, 15 Sep 2011 09:50:17 +0200

Totally agree, Iñaki

+1

2011/9/15 Soo-Hyun Choi <[email-masked]>

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Thu, 15 Sep 2011 09:53:14 +0200

Hi,

[snip]

> My point is that the default signaling protocol has to be supported in RTCWeb client which should not be downloaded in runtime to make the dialog between two RTCWeb client. I asked for SIP initiall…

Do you mean there should be a 'default signaling protocol' on every browser? I'm not sure I'd like that. I (personally) see RTCWeb as a framework on top of which we can build RTC applications. The fact that one would use SIP and someone else uses something else is not crucial, IMHO. Now if some new simplified protocol is chosen for browser-to-browser communication we'd have yet another island of devices (browsers in this case) to which we'd need to gateway somehow.

[snip]

> <partha> I hope that the aim of the protocols is to enable multimedia stream between browser to browser only. In case browser to other end-point is outside the scope of RTCWEb. </partha> 

Well, why build a parallel universe just for the browsers? If RTCWeb would only define the media plane and developers themselves can choose the signaling protocol, the integration with existing communication systems (using SIP or XMPP for example since they are the most used ones) would be pretty straight-forward.

My 2 cents.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 15 Sep 2011 12:49:28 +0200

2011/9/15 Matthew Kaufman <[email-masked]>:
> I'd go one step further to say that the "well defined API" shouldn't be "SDP
> offer/answer via events" for negotiating codec parameters, but should
> instead be a way to manage the codec settings, with offer/answer or capneg
> or whatever you want implemented in the Javascript (or up at the server,
> your choice).

Hi Matthew,

You mean a way to simplify the "SDP management" from the JavaScript
code, am I right?

The web-browser JavaScript stack could include a native library to
parse a SDP body (maybe plain SDP as defined in RFC 4566 and also the
XML version used in XMPP/Jingle) so it returns some kind of JS
struct/object describing the peer-requested streams (something easier
than full understanding of SDP).

An also another native JS function to generate a SDP (plain or XML)
given some arguments (enable-audio, enable-video, and so on) to be
included in a custom signaling message (which could also be SIP or
XMPP).

Also functions for adding/modifying/deleting a stream, and callbacks
for the case in which the remote puts on hold a specific stream,
adds/modifies/deletes a stream...

This is: make an API that exposes SDP capabilities without requiring
understanding of the complex RFC 4566 (SDP).

Regards.

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

---

From: Tim Panton <[email-masked]>
Date: Thu, 15 Sep 2011 12:49:48 +0100

> understanding of the complex RFC 4566 (SDP).

Are we saying that SDP is so impossible to parse that the only way to do it 
is with a pre-existing native library ?!? If not I think we can do that transformation 
(when needed) in JavaScript.

Tim.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 15 Sep 2011 13:52:38 +0200

> (when needed) in JavaScript.

No, I just said that _maybe_ it wouldl be useful to provide such
parsing functions natively (given the fact that various protocol use
SDP bodies, as SIP and XMPP).

I'm fine with parsing SDP bodies in custom JavaScript code however :)

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

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 15 Sep 2011 14:02:48 +0200

Il giorno Thu, 15 Sep 2011 13:52:38 +0200
Iñaki Baz Castillo <[email-masked]> ha scritto:

> > Are we saying that SDP is so impossible to parse that the only way
> > to do it is with a pre-existing native library ?!? If not I think
> > we can do that transformation (when needed) in JavaScript.
> 

I don't understand the need for it to be SDP actually: Javascript
already has native and efficient ways to describe information (JSON,
XML), if SDP is what everybody wants then it would be easier to just
map SDP over them.

L.

-- 
Lorenzo Miniero, COB

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 15 Sep 2011 14:12:14 +0200

> XML), if SDP is what everybody wants then it would be easier to just

Assuming that the signaling protocol is custom, my JavaScript code
could receive pure SIP messages or XMPP messages, so the SDP comes in
plain or XML format.

I can parse it manually in my JS code (or use some native JS function
to parse them if they are provided) and convert it to JSON prior to
use it for WebRTC function calls.

Other web application could prefer to create its own signaling
protocol and carry SDP directly in JSON format, of course. Freedom for
all.

Best regards.

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

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 15 Sep 2011 15:09:33 +0200

On 09/15/11 14:02, Lorenzo Miniero wrote:
> Iñaki Baz Castillo<[email-masked]>  ha scritto:
>
>> 2011/9/15 Tim Panton<[email-masked]>:
The disadvantage of parsing to another structure (I am fond of JSON 
myself) is that one has to maintain a data definition for the format 
being parsed to, a defined transform between that and the "canonical SDP 
structure" has to be implemented in user space when one does SDP 
interoperability, both of those have to be updated for every SDP 
extension that someone defines somewhere, and one is still not free to 
define extensions on the non-SDP side if one still requires the ability 
to map them into SDP.

If one uses the "native" SDP format, which is the format in which every 
extension to the format gets documented, the browsers are the ones who 
*have* to parse it (although others are likely to).

                    Harald

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 15 Sep 2011 16:20:50 -0500

+1

Thanks, Henry

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Fri, 16 Sep 2011 05:26:45 +0530

Hi Saul,

I really didn't get your argument fully because in case there is no default signaling protocol, it is unavoidable to have island of devices without gateways but you argue other way around. 

I specifically asked for the scope of your opinion on RTCWeb work is between browser-to-browser or browser-to-other end-point to know whether parallel universe has to be build or not. In case there is no default signaling protocol, it is impossible to communicate between browser-to-endpoint without gateways. Let us assume that the intention of RTCWeb is to create island of browser devices even then the native signaling protocol for RTCWeb has advantage over Jquery library and plugin is not the solution.

Having said that, I agree that it is possible to implement RTP or STUN or SIP stack or codec using Javascript or plugins but interop and better performance is not guaranteed.

Thanks
Partha

>From: Saúl Ibarra Corretgé [mailto:[email-masked]]
>Sent: Thursday, September 15, 2011 1:23 PM
>To: Ravindran Parthasarathi
>Cc: Iñaki Baz Castillo; [email-masked]
>Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or
>not)
>
>Hi,
>
>[snip]
>
>> My point is that the default signaling protocol has to be supported in
>RTCWeb client which should not be downloaded in runtime to make the
>dialog between two RTCWeb client. I asked for SIP initially as SIP is
>the de-facto protocol and mostly deployment. I agree with Peter & others
>that websocket could be another alternative in the web deployment. In
>case required, I'll come up the write up to show the needs of default
>signaling protocol for making dialog between browser to browser.
>>
>
>Do you mean there should be a 'default signaling protocol' on every
>browser? I'm not sure I'd like that. I (personally) see RTCWeb as a
>framework on top of which we can build RTC applications. The fact that
>one would use SIP and someone else uses something else is not crucial,
>IMHO. Now if some new simplified protocol is chosen for browser-to-
>browser communication we'd have yet another island of devices (browsers
>in this case) to which we'd need to gateway somehow.
>
>[snip]
>
>>>
>> <partha> I hope that the aim of the protocols is to enable multimedia
>stream between browser to browser only. In case browser to other end-
>point is outside the scope of RTCWEb. </partha>
>>
>
>Well, why build a parallel universe just for the browsers? If RTCWeb
>would only define the media plane and developers themselves can choose
>the signaling protocol, the integration with existing communication
>systems (using SIP or XMPP for example since they are the most used
>ones) would be pretty straight-forward.
>
>My 2 cents.
>
>
>Regards,
>
>--
>Saúl Ibarra Corretgé
>AG Projects
>
>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 15 Sep 2011 20:52:03 -0400

Partha,

It is not possible to implement browser to browser calls unless both
browsers are on public IPs or on the same network. As far as signaling is
concerned, it is always going to be browser to server to browser call. Since
there is always a server on the signaling path and since implementing a
signaling gateway from long poll HTTP or websocket signaling interface to
SIP (as shown by a number of projects mentioned in this thread) is straight
forward enough to implement, there is no desire to create a standard
signaling protocol to be used in the browser. There is no benefit for the
application developer in following this standard, since it provides neither
more functionality no better performance then a custom protocol implemented
in JavaScript. Interop and fragmentation arguments do not apply to this
either, since it is the same as complaining that HotMail and GMail use
different protocols when implementing web mail. It does not affect anything
since this stays within the same application and is no more then an
implementation detail.
_____________
Roman Shpount

On Thu, Sep 15, 2011 at 7:56 PM, Ravindran Parthasarathi <
[email-masked]> wrote:

> Hi Saul,
>
> I really didn't get your argument fully because in case there is no default
> signaling protocol, it is unavoidable to have island of devices without
> gateways but you argue other way around.
>
> I specifically asked for the scope of your opinion on RTCWeb work is
> between browser-to-browser or browser-to-other end-point to know whether
> parallel universe has to be build or not. In case there is no default
> signaling protocol, it is impossible to communicate between
> browser-to-endpoint without gateways. Let us assume that the intention of
> RTCWeb is to create island of browser devices even then the native signaling
> protocol for RTCWeb has advantage over Jquery library and plugin is not the
> solution.
>
> Having said that, I agree that it is possible to implement RTP or STUN or
> SIP stack or codec using Javascript or plugins but interop and better
> performance is not guaranteed.
>
> Thanks
> Partha
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 16 Sep 2011 02:24:31 +0000

There is no need for a "default signaling protocol", because the "signaling" is between the browser's Javascript and its web server.  And as for the signaling protocol the web server has to support in order to speak to other servers or non-RTCweb endpoints, even if we specified to use SIP we'd just be summarily ignored by those who don't want to, because they actually don't *need* to.  It doesn't hurt interoperability of rtcweb if they don't implement SIP - it just means they can't talk to other SIP devices/servers.  But it's not like we need an RFC to say "if you don't implement X then you can't talk to people who do X".

Think of this RTCWEB concept as Skinny/SCCP.  The Web Server is Call Manager, and the browser is the Skinny phone, but in this case instead of needing a 7960 phone, the Skinny protocol was written in javascript and uses a browser's user interface for its GUI and the built-in RTP library for media. (in fact one could probably write a javascript to do just that, if Call Manager handled SCCP over websocket)  

Clearly the IETF does not need to define for Cisco a standardized replacement for the SCCP protocol for this to work, because one isn't needed since the client javascript and server are built by the same developers and they know how their proprietary signaling works.  So how about for the signaling Call Manager would use to other VoIP devices, like gateways or VoIP service providers?  Does the IETF need to tell Cisco what peer-to-peer protocol(s) to implement on Call Manager?  No, and we never have.  Cisco's product managers decide that.  They decide if Call Manager needs to be able to communicate a standard protocol at all, such as SIP or H.323, and which one/any of those.  They decide based on their use-cases/need.

Some rtcweb developers may not do any standard signaling protocol, ever.  For example many Instant Messaging providers still have closed environments to this day. (e.g., AIM, YIM, MSN, etc.)  Some may choose to only use H.323, or XMPP, or IAX, or even BICC.  Some may choose to only support SIP with 3GPP extensions.  Obviously most of us think/hope people do SIP, but really the market makes those types of decisions, not the IETF.  Just like the IETF standardized MGCP but didn't specify what the MGCP Call Agent had to support to speak to other Call Agents.  SIP was given as an example in MGCP, but not mandated.

The only thing we need to do for rtcweb is make sure the RTP library built into the browser supports media in such a way that it can communicate with other RTP peers at a media plane, regardless of what signaling protocol those peers might be using, preferably without going through media gateways.  And obviously since SIP is a very common protocol and defined by the IETF we need to make sure it's possible to use SIP on the rtcweb server, but we can't *mandate* that it be used or supported, and if we did it wouldn't change anything. 

-hadriel

---

From: Jim McEachern <[email-masked]>
Date: Fri, 16 Sep 2011 03:23:54 +0000

Hadriel,
Well said.  

Your closing paragraph sums it up nicely in my mind.

<snip>
The only thing we need to do for rtcweb is make sure the RTP library built into the browser supports media in such a way that it can communicate with other RTP peers at a media plane, regardless of what signaling protocol those peers might be using, preferably without going through media gateways.  And ... we need to make sure it's possible to use SIP on the rtcweb server....
</snip>

Jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Thursday, September 15, 2011 10:25 PM
To: Ravindran Parthasarathi
Cc: <[email-masked]>
Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]

-hadriel

---

From: "Avasarala, Ranjit" <[email-masked]>
Date: Fri, 16 Sep 2011 14:33:06 +0800

Agree.

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Friday, September 16, 2011 7:55 AM
To: Ravindran Parthasarathi
Cc: <[email-masked]>
Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]

-hadriel

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 16 Sep 2011 08:54:31 +0200

Roman,

On Sep 16, 2011, at 2:52 AM, Roman Shpount wrote:

> Partha,
> 
> It is not possible to implement browser to browser calls unless both browsers are on public IPs or on the same network. As far as signaling is concerned, it is always going to be browser to server to browser call. Since there is always a server on the signaling path and since implementing a signaling gateway from long poll HTTP or websocket signaling interface to SIP (as shown by a number of projects mentioned in this thread) is straight forward enough to implement, there is no desire to create a standard signaling protocol to be used in the browser. There is no benefit for the application developer in following this standard, since it provides neither more functionality no better performance then a custom protocol implemented in JavaScript. Interop and fragmentation arguments do not apply to this either, since it is the same as complaining that HotMail and GMail use different protocols when implementing web mail. It does not affect anything since this stays within the same application and is no more then an implementation detail.

I couldn't have said it better :-)

--
Saúl Ibarra Corretgé
AG Projects

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 16 Sep 2011 08:56:41 +0200

+1

--
Saúl Ibarra Corretgé
AG Projects

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Fri, 16 Sep 2011 13:00:42 +0530

|The only thing we need to do for rtcweb is make sure the 
|RTP library built into the browser supports media in such
|a way that it can communicate with other RTP peers at a 
|media plane, regardless of what signaling protocol those 
|peers might be using, preferably without going through 
|media gateways.  And obviously since SIP is a very common 
|protocol and defined by the IETF we need to make sure it's
|possible to use SIP on the rtcweb server, but we can't 
|*mandate* that it be used or supported, and if we did it 
|wouldn't change anything.

+1. 

We may also want to make sure that it is possible use SDP, but shouldn't
mandate that it be used.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hadriel Kaplan
|Sent: Friday, September 16, 2011 7:55 AM
|To: Ravindran Parthasarathi
|Cc: <[email-masked]>
|Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About
defining a signaling protocol
|for WebRTC (or not)]
|
|
|There is no need for a "default signaling protocol", because the
"signaling" is between the browser's
|Javascript and its web server.  And as for the signaling protocol the
web server has to support in
|order to speak to other servers or non-RTCweb endpoints, even if we
specified to use SIP we'd just be
|summarily ignored by those who don't want to, because they actually
don't *need* to.  It doesn't hurt
|interoperability of rtcweb if they don't implement SIP - it just means
they can't talk to other SIP
|devices/servers.  But it's not like we need an RFC to say "if you don't
implement X then you can't
|talk to people who do X".
|
|Think of this RTCWEB concept as Skinny/SCCP.  The Web Server is Call
Manager, and the browser is the
|Skinny phone, but in this case instead of needing a 7960 phone, the
Skinny protocol was written in
|javascript and uses a browser's user interface for its GUI and the
built-in RTP library for media. (in
|fact one could probably write a javascript to do just that, if Call
Manager handled SCCP over
|websocket)
|
|Clearly the IETF does not need to define for Cisco a standardized
replacement for the SCCP protocol
|for this to work, because one isn't needed since the client javascript
and server are built by the
|same developers and they know how their proprietary signaling works.
So how about for the signaling
|Call Manager would use to other VoIP devices, like gateways or VoIP
service providers?  Does the IETF
|need to tell Cisco what peer-to-peer protocol(s) to implement on Call
Manager?  No, and we never have.
|Cisco's product managers decide that.  They decide if Call Manager
needs to be able to communicate a
|standard protocol at all, such as SIP or H.323, and which one/any of
those.  They decide based on
|their use-cases/need.
|
|Some rtcweb developers may not do any standard signaling protocol,
ever.  For example many Instant
|Messaging providers still have closed environments to this day. (e.g.,
AIM, YIM, MSN, etc.)  Some may
|choose to only use H.323, or XMPP, or IAX, or even BICC.  Some may
choose to only support SIP with
|3GPP extensions.  Obviously most of us think/hope people do SIP, but
really the market makes those
|types of decisions, not the IETF.  Just like the IETF standardized MGCP
but didn't specify what the
|MGCP Call Agent had to support to speak to other Call Agents.  SIP was
given as an example in MGCP,
|but not mandated.
|
|The only thing we need to do for rtcweb is make sure the RTP library
built into the browser supports
|media in such a way that it can communicate with other RTP peers at a
media plane, regardless of what
|signaling protocol those peers might be using, preferably without going
through media gateways.  And
|obviously since SIP is a very common protocol and defined by the IETF
we need to make sure it's
|possible to use SIP on the rtcweb server, but we can't *mandate* that
it be used or supported, and if
|we did it wouldn't change anything.
|
|-hadriel
|
|
|On Sep 15, 2011, at 7:56 PM, Ravindran Parthasarathi wrote:
|
|> I really didn't get your argument fully because in case there is no
default signaling protocol, it
|is unavoidable to have island of devices without gateways but you argue
other way around.
|>
|> I specifically asked for the scope of your opinion on RTCWeb work is
between browser-to-browser or
|browser-to-other end-point to know whether parallel universe has to be
build or not. In case there is
|no default signaling protocol, it is impossible to communicate between
browser-to-endpoint without
|gateways. Let us assume that the intention of RTCWeb is to create
island of browser devices even then
|the native signaling protocol for RTCWeb has advantage over Jquery
library and plugin is not the
|solution.
|>
|> Having said that, I agree that it is possible to implement RTP or
STUN or SIP stack or codec using
|Javascript or plugins but interop and better performance is not
guaranteed.
|>
|> Thanks
|> Partha
|
|_______________________________________________
|rtcweb mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 16 Sep 2011 10:34:03 +0200

+1

The only I expect is that a WebRTC web-browser can establish a RTP
session with a remote SIP or XMPP+Jingle endpoint (without requiring
media gateways !!). How the signaling (SIP or XMPP) is carried between
the real SIP/XMPP endpoint and the browser should be out of the scope
of rtcweb (IMHO). Having said that, we have already shown a working
solution for carrying SIP between web-browsers and real SIP entities
out there (SIP over WebSocket). The same can be done for any other
protocol (it's already specified also for XMPP).

Regards.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 16 Sep 2011 11:02:01 +0200

> I really didn't get your argument fully because in case there is no default signaling protocol, it is unavoidable to have island of devices without gateways but you argue other way around.

A centralized signaling point is required (think about NAT). Signaling
is just supposed to be present between web-browsers visiting the same
web site, so the signaling can be perfectly carried within HTTP or
WebSocket protocol and be centralized in that server. Otherwise, are
you proposing the existence of a global/unique SIP proxy in the world
for all the web-browsers to intercommunicate?

WebRTC is not about communication between web-browsers as if they were
generic SIP phones contacting directly one to other.

> I specifically asked for the scope of your opinion on RTCWeb work is between browser-to-browser or browser-to-other end-point to know whether parallel universe has to be build or not. In case there is no default signaling protocol, it is impossible to communicate between browser-to-endpoint without gateways

Why is it impossible? If WebSocket is used as a new transport for SIP
and XMPP then web-browsers can establish a pure SIP or XMPP session
with a SIP/XMPP server implementing WebSocket transport. And for sure
that works.

Best regards.

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

---

From: Tim Panton <[email-masked]>
Date: Fri, 16 Sep 2011 15:24:44 +0100

+1

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 16 Sep 2011 18:29:00 +0000

On Sep 15, 2011, at 9:09 AM, Harald Alvestrand wrote:

> The disadvantage of parsing to another structure (I am fond of JSON myself) is that one has to maintain a data definition for the format being parsed to, a defined transform between that and the "canonical SDP structure" has to be implemented in user space when one does SDP interoperability, both of those have to be updated for every SDP extension that someone defines somewhere, and one is still not free to define extensions on the non-SDP side if one still requires the ability to map them into SDP.
> 
> If one uses the "native" SDP format, which is the format in which every extension to the format gets documented, the browsers are the ones who *have* to parse it (although others are likely to).

Right so the above paragraphs get to the heart of the matter, methinks.  Ultimately we need W3C to define an API, and the API has to provide a means of learning RTP/media info from the browser and commanding the browser to perform certain things with RTP/media.  One could expose this API as a true data structure, or as a long string of tokens to be parsed/serialized back/forth.  If the latter, then the choices are basically JSON or SDP.  And SDP seems advantageous because it appears to be the least work for the simple use-cases, because the javascript could just copy back/forth the SDP between the browser and server.  In other words you're optimizing for the very simple use-cases, in exchange for making it more complicated for the advanced use-cases.  Right?

OK, that's a laudable goal.  And I recognize that the decision has basically already been made, and nothing's going to change it. 

But email's free... so for the sake of posterity (and email archiving) here're some reasons not to use SDP anyway:
1) Incorporating SDP and the offer/answer model into the Browser and W3C API inexorably ties the W3C to the IETF MMUSIC working group for all time.  So far, I had been going on the assumption the IETF would be defining what the RTP library had to do/expose, while W3C would define the API.  But if the API includes SDP offer/answer, that portion is the IETF's domain too, afaik.  Anything the W3C wants to do in the future for that has to go through the IETF, not just IANA. (right?)

2) This isn't just about JSON vs. SDP - it's about SDP *offer/answer*.  SDP offer/answer wasn't meant to be an API between an application and its RTP library - it's a *protocol* between applications.  One side-effect of this is it has historic state.  For example, if an SDP offer contains two media lines, and one media is removed, the number of SDP media lines don't reduce back to one - EVER.  So if PeerConnection.removeStream() is invoked, the Browser needs to remember there was that stream and signal it in SDP as disabled for all time, until PeerConnection is closed.  If addStream() is invoked later, it could/could-not re-use that same (disabled) media line, or add a new one.

As another example, if a new SDP offer is sent out in SIP and gets rejected with a 488, the session reverts to the previously agreed SDP state.  The Browser would therefore have to keep state of previous SDP and revert to it to handle this case.  For example, if my Javascript started with only an audio MediaStream in PeerConnection and later added a video MediaStream to it, the new SDP offer would contain two media lines - if the offer gets rejected with 488, how is that communicated to the Browser and what will the browser do?

3) You might well want information conveyed across that "API" that is not meant to be sent on the wire in SDP - things you don't want defined by IANA as SDP tokens.  For example, you may want to provide packet counts, jitter, latency, and other meta-information about individual RTP codecs.  Using JSON allows you to have data member variables which will not get serialized into SDP, but are purely for the javascript's use, while still within the referential tree structure of the media stream info.  Or they may be for sending to peers, but simply not for SDP. (like you could send the jitter/latency info through the signaling channel)

4) Obviously if the application as a whole needs to do SDP offer/answer, then *someone* will have to implement it correctly, including the state-related stuff.  It could be the browser or the javascript that do this.  Chrome may do a perfect job of that in the browser, afaik.  But there are other browser vendors, including niche ones such as Dolphin and Skyfire.  What are the odds they all get it right the first time?

So which would you rather have updating an SDP engine, if one is even needed... or updating "every SDP extension that someone defines somewhere": the javascript which is written by the developer that knows what they want when they want it, and can update their code by updating their javascript (or not if they don't need to); or the browsers which are written by companies not under the javascript developer's control, at a time of the browser companies' choosing? 

Obviously for some things the browser will have to be updated regardless, for example to understand rather than just ignore new JSON entries, to provide new codecs, etc.  But not all new SDP attributes require changes in the media plane, nor encoding into JSON.  In fact, a lot doesn't - some of it's higher-application info, not really for the RTP library, and more of it's coming in the future. 

-hadriel

---

From: Ted Hardie <[email-masked]>
Date: Fri, 16 Sep 2011 13:43:34 -0700

On Thu, Sep 15, 2011 at 8:23 PM, Jim McEachern <[email-masked]>wrote:

> The only thing we need to do for rtcweb is make sure the RTP library built
> into the browser supports media in such a way that it can communicate with
> other RTP peers at a media plane, regardless of what signaling protocol
> those peers might be using, preferably without going through media gateways.
>  And ... we need to make sure it's possible to use SIP on the rtcweb
> server....
> </snip>
>
>
I think there is more to it than this for it to be a success.  We have to
make sure that it is relatively easy to adopt  rtcweb in javascript
applications.  The way we've discussed that in the past was "2 party video
chat in 20 lines of javascript".   If a novel signalling protocol is created
every time, that won't be a practical choice.  Even if the signalling is
segmented into libraries, the app will have to download the one in use by a
particular website, potentially every time.  This is better than a plugin in
some ways and potentially actually worse in others.

We also have to make sure that the resulting application does not flood or
fry the network. That means it will have to have real congestion control
mechanisms.   Trusting the javascript application for that has some real
issues which we've already discussed.   Splitting signaling and congestion
control isn't a lot better.  If congestion control at the network level is
managed by the browser but signalling is in the javascript, then information
about that state has to pass into the JS application, so it can manage the
signalling.  That makes the APIs more complex and runs the risk that a naive
javascript application will not adjust to the congestion control
requirements at all.

The early web took off in part because of the ease of embedding things like
images (compared to gopher, for example) into rich content.  We have the
opportunity to create native web applications with much richer and more
interactive experiences with rtcweb, but if it is not easy to do, it won't
have the same impact.  If this is something that can be done only by folks
who can roll their own signalling protocol, it's dead, because the number of
content authors is too small.  If it even requires selecting among an
unbounded set of variously maintained libraries , it will be frustrating for
the developer of simple applications.   At that level, the existing plugins
will simply be more stable and better known.

Providing baseline APIs into a well-known signaling capability seems to me
far more likely to result in a real flowering of rtcweb content.  That's why
I want it.

Just my two cents, not taken from any hat,

Ted

---

From: cbran <[email-masked]>
Date: Fri, 16 Sep 2011 13:50:30 -0700

+1 Ted  totally agree.

On 9/16/11 1:43 PM, "Ted Hardie" <[email-masked]> wrote:

>> other RTP peers at a media plane, regardless of what signaling protocol those
>> peers might be using, preferably without going through media gateways.  And
>> ... we need to make sure it's possible to use SIP on the rtcweb server....
>> </snip>
>> 
> 
> I think there is more to it than this for it to be a success.  We have to make
> sure that it is relatively easy to adopt  rtcweb in javascript applications. 
> The way we've discussed that in the past was "2 party video chat in 20 lines
> of javascript".   If a novel signalling protocol is created every time, that
> won't be a practical choice.  Even if the signalling is segmented into
> libraries, the app will have to download the one in use by a particular
> website, potentially every time.  This is better than a plugin in some ways
> and potentially actually worse in others.
> 
> We also have to make sure that the resulting application does not flood or fry
> the network. That means it will have to have real congestion control
> javascript application will not adjust to the congestion control requirements
> at all.
> 
> have the same impact.  If this is something that can be done only by folks who
> can roll their own signalling protocol, it's dead, because the number of
> Providing baseline APIs into a well-known signaling capability seems to me far
> more likely to result in a real flowering of rtcweb content.  That's why I
> want it.
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 16 Sep 2011 21:15:09 +0000

On Sep 16, 2011, at 4:43 PM, Ted Hardie wrote:

> We also have to make sure that the resulting application does not flood or fry the network. That means it will have to have real congestion control mechanisms.   Trusting the javascript application for that has some real issues which we've already discussed.   Splitting signaling and congestion control isn't a lot better.  If congestion control at the network level is managed by the browser but signalling is in the javascript, then information about that state has to pass into the JS application, so it can manage the signalling.  That makes the APIs more complex and runs the risk that a naive javascript application will not adjust to the congestion control requirements at all.

Yes you're right we have to make sure things don't collapse, but I'm confused why congestion control would be handled in the JS, or in signaling.  Wouldn't it be done in the RTP/RTCP layer, such as draft-alvestrand-rtcweb-congestion-00 or whatever, if the RTP peer supported it?  Who said it would be in signaling? (I must have missed something, or misunderstand you)

-hadriel

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 16 Sep 2011 16:35:53 -0700

Hi,

From:  Ted Hardie <[email-masked]>
Date:  Fri, 16 Sep 2011 13:43:34 -0700
To:  Jim McEachern <[email-masked]>
Cc:  "<[email-masked]>" <[email-masked]>
Subject:  Re: [rtcweb] RTCWeb default signaling protocol [was RE: About
defining a signaling protocol for WebRTC (or not)]

[Š]
>   We have to make sure that it is relatively easy to adopt  rtcweb in
> javascript applications.  The way we've discussed that in the past was "2
> party video chat in 20 lines of javascript".
[Š]

I think that something along these lines ought to be added to the
requirements draft (perhaps in softened form, and perhaps not even as a
Requirement but rather in the intro section), and a discussion about issues
that libraries may have ought to be added to framework drafts.

Stephan

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 16 Sep 2011 23:05:39 +0200

Agree.

> Think of this RTCWEB concept as Skinny/SCCP.  The Web Server is Call Manager, and the browser is the Skinny phone, but in this case instead of needing a 7960 phone, the Skinny protocol was written…

Actually, it is even better than this. Think of the RTCWEB Javascript 
API as "Skinny/SCCP". The web developer is then free to have "call 
manager" be up in the server and simply pass down data that is reflected 
directly into the API... or the web developer can use the fact that 
there's a complete programming environment on the browser to implement 
some or all of "call manager" *at the browser*, and that choice is 
completely in the application developer's hands.

They can write Skinny in Javascript and use the browser UI for the GUI 
and RTP library for media, and interoperate with SIP by building a 
complete SIP-to-Skinny translation at the server.

But they can also write SIP in Javascript and use the browser UI for the 
GUI and RTP library for the media, and interoperate with SIP by building 
just a Websocket-to-SIP converter up at the server.

Completely up to them... *if* we build a Javascript API that actually 
lets the programmer make this decision, just like they can make the same 
decision when they are programming to the Windows or Mac APIs.

On other other hand, if we bake too much in (a SIP implementation, all 
the semantics of SDP offer-answer, etc.) then the application developer 
either has their hands tied, or is forced to resort to silly things like 
taking an SDP offer and parsing it in Javascript to get the capabilities 
of the browser they're running in and then writing it back out as a 
different SDP offer that matches what they really want.

>
> Clearly the IETF does not need to define for Cisco a standardized replacement for the SCCP protocol for this to work, because one isn't needed since the client javascript and server are built by the same developers and they know how their proprietary signaling works.

Indeed. The protocol needs exactly the same level of standardization 
that Google needed to build Gmail. You need HTTP, possibly Websockets, a 
common programming language (Javascript) and a common set of interfaces 
(the Javascript API). The rest, including exactly what is transported on 
the wire, should be up to the developer. The format, how much of the 
logic lives at each end, etc.

>   So how about for the signaling Call Manager would use to other VoIP devices, like gateways or VoIP service providers?  Does the IETF need to tell Cisco what peer-to-peer protocol(s) to implement on Call Manager?  No, and we never have.  Cisco's product managers decide that.  They decide if Call Manager needs to be able to communicate a standard protocol at all, such as SIP or H.323, and which one/any of those.  They decide based on their use-cases/need.

Agree. If they want to connect to SIP providers for PSTN access, they 
can implement that. If they want to talk XMPP and Jingle because that's 
their preferred federation protocol, that's ok too.

>
> Some rtcweb developers may not do any standard signaling protocol, ever.  For example many Instant Messaging providers still have closed environments to this day. (e.g., AIM, YIM, MSN, etc.)

My employer is arguably one of the largest VoIP providers in the world, 
and most definitely isn't using standard signaling protocols.

>   Some may choose to only use H.323, or XMPP, or IAX, or even BICC.  Some may choose to only support SIP with 3GPP extensions.  Obviously most of us think/hope people do SIP, but really the market makes those types of decisions, not the IETF.  Just like the IETF standardized MGCP but didn't specify what the MGCP Call Agent had to support to speak to other Call Agents.  SIP was given as an example in MGCP, but not mandated.
>
> The only thing we need to do for rtcweb is make sure the RTP library built into the browser supports media in such a way that it can communicate with other RTP peers at a media plane, regardless of what signaling protocol those peers might be using, preferably without going through media gateways.

This, and supports enough security/safety that the library can be 
trusted to run in the browser environment. (This is where the ICE 
requirement comes from.)

>   And obviously since SIP is a very common protocol and defined by the IETF we need to make sure it's possible to use SIP on the rtcweb server, but we can't *mandate* that it be used or supported, and if we did it wouldn't change anything.

Obviously it is always possible to use SIP on the RTCWEB server. After 
all, it is fairly trivial to gateway from Flash Player and RTMP or RTMFP 
to SIP, and there's no commonality there at all. The odds are extremely 
high that we can make interoperation even easier, both by opening up the 
capability and control APIs and by using a standard media transport so 
that media gateways can be avoided in many cases.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 16 Sep 2011 23:12:40 +0200

On 9/15/11 3:09 PM, Harald Alvestrand wrote:
> being parsed to, a defined transform between that and the "canonical 
> SDP structure" has to be implemented in user space when one does SDP 
> define extensions on the non-SDP side if one still requires the 
> ability to map them into SDP.
>
> If one uses the "native" SDP format, which is the format in which 
> every extension to the format gets documented, the browsers are the 
> ones who *have* to parse it (although others are likely to).

Of course what you're also saying here is that it takes a trip to the 
IETF to make every extension. So if the *only* Javascript API for 
controlling the codec (or getting its capabilities by triggering an 
offer) is a pile of SDP in string form, then nothing that hasn't been 
standardized can be described.

For example: forcing the Opus codec to "music" mode no matter what the 
input.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 16 Sep 2011 23:32:06 +0200

> I really didn't get your argument fully because in case there is no default signaling protocol, it is unavoidable to have island of devices without gateways but you argue other way around.
Browsers cannot talk to each other without at least a web server to 
serve up the application (HTML and Javascript) and a server over which 
to exchange the ICE signaling information, so they won't be talking to 
each other "on their own" anyway.

Once you have that, RTCWEB calling is no more or less an island than 
web-based messaging services. Some of them let users compose messages 
that stay within the "walled garden" of the service (and that is their 
choice), others let users compose email which is exchanged with other 
services over standard protocols like SMTP.

>
> I specifically asked for the scope of your opinion on RTCWeb work is between browser-to-browser

RTCWEB needs to specify the browser-to-browser media and the APIs by 
which that media channel is created and controlled. That is all.

>   or browser-to-other end-point to know whether parallel universe has to be build or not.

For the media channel, it would be helpful if the "browser-to-browser" 
media uses a standard such as RTP so that "browser-to-other" can be done 
directly, without media gateways.

For signaling, this is not nearly so important a requirement, and in 
fact conflicts with the goals of providing flexible APIs that allow 
developers to use web browsers as a development platform... an operating 
system and runtime, rather than a pre-built "phone" as I've said before.

>   In case there is no default signaling protocol, it is impossible to communicate between browser-to-endpoint without gateways.

Signaling? True.

Media? Hopefully not.

>   Let us assume that the intention of RTCWeb is to create island of browser devices

The intention of RTCWeb is to bring real-time communication capabilities 
to the browser environment so that developers may create applications 
that leverage these features. Whether or not that results in an "island" 
will be up to the developers of these applications.

Does "the Linux operating system" create an "island of computer devices" 
because someone else needs to supply the software that lets them play 
real-time games with each other?

>   even then the native signaling protocol for RTCWeb has advantage over Jquery library and plugin is not the solution.

There is no need for a "native signaling protocol for RTCWeb", just a 
standard way of delivering applications (HTTP) and running them in the 
browser (HTML + Javascript)

> Having said that, I agree that it is possible to implement RTP or STUN or SIP stack or codec using Javascript or plugins but interop and better performance is not guaranteed.
Why is that even necessary for interop? Hotmail didn't write IMAP and 
SMTP in Javascript to make Hotmail work and yet it seems to interoperate 
with the world of SMTP email services just fine.

Matthew Kaufman

---

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

16 sep 2011 kl. 23:05 skrev Matthew Kaufman:

> This, and supports enough security/safety that the library can be trusted to run in the browser environment. (This is where the ICE requirement comes from.)

Matt,
Can you please elaborate how ice relates to security?

THanks,
/O

---

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

16 sep 2011 kl. 23:32 skrev Matthew Kaufman:

> Browsers cannot talk to each other without at least a web server to serve up the application (HTML and Javascript) and a server over which to exchange the ICE signaling information, so they won't be talking to each other "on their own" anyway.
They will be able to use the rtcweb data channel, which is a concern.

> 
> Once you have that, RTCWEB calling is no more or less an island than web-based messaging services. Some of them let users compose messages that stay within the "walled garden" of the service (and that is their choice), others let users compose email which is exchanged with other services over standard protocols like SMTP.
> 
>> 
> RTCWEB needs to specify the browser-to-browser media and the APIs by which that media channel is created and controlled. That is all.
According to the wg charter there's a data channel ability too.

> For the media channel, it would be helpful if the "browser-to-browser" media uses a standard such as RTP so that "browser-to-other" can be done directly, without media gateways.
> 
> For signaling, this is not nearly so important a requirement, and in fact conflicts with the goals of providing flexible APIs that allow developers to use web browsers as a development platform... an operating system and runtime, rather than a pre-built "phone" as I've said before.
> 
Data which can carry signalling - maybe...

Sorry to keep repeating the data channel issue, but it disturbes me a bit.

/O

---

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

On 09/17/2011 01:22 AM, Olle E. Johansson wrote:
>>> The only thing we need to do for rtcweb is make sure the RTP library 
>>> built into the browser supports media in such a way that it can 
>>> communicate with other RTP peers at a media plane, regardless of 
>>> what signaling protocol those peers might be using, preferably 
>>> without going through media gateways.
>>

Physics prediction on the data channel is possible, yet that doesn't 
agree to all server models.

Win8 reminds me of mosaic reborn, for example. Some argue over the order 
of the service stack, and they consider those end up in-between as MITM.

-- 

---
<i>The wheel.</i metro-link=t dzonatasolyndra>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 17 Sep 2011 17:27:10 +0000

> Can you please elaborate how ice relates to security?

There's a concern that malicious javascript can make your Browser start sending RTP packets at a target, and that enough people running such a javascript would be a nice botnet flooding a target.  For example, there could be some malicious website which has some interesting content on it to draw people to go to it (for example it mirrors real content from somewhere else, or it offers pirated content downloading, or porn, or whatever), and on the same webpage it embeds javascript that makes your Browser start sending RTP packets against root DNS servers or whatever.  IF they got enough browsers viewing their webpage, then it would be a DDoS flood of RTP against the target.  And of course if we have a UDP-based Data channel and the javascript can decide what goes in the data packet, then it could craft something nasty, to either perform a heavier resource exhaustion attack, or whatever.  Ultimately the concern is that UDP has no SYN/SYN-ACK exchange like TCP does, to verify the device you're going to send lots of packets to wants to receive any of them.

So ICE does that for you - it verifies the IP:port you're going to send your RTP packets to is willing to accept your packets. (it has some other security properties too, but I personally find the rest questionable, compared to this one)
So basically we're stuck with requiring ICE be used for every media/data session, and thus not being able to interop directly with devices which don't do ICE (which is most of the SIP world right now).

One open question is if javascript will even be allowed to open a media channel to a peer without human/user consent.  I thought we were requiring per-site consent.  I guess a malicious site could still offer legitimate media usage, and thus get user's consent, and then sometime in the future the same website could turn evil; or it could offer seemingly legitimate service that works, while in javascript creating a forked stream that is the one attacking someone else.

I wonder though if even requiring ICE is sufficient.  If I'm a malicious javascript, I could add enough ICE candidates against a target that it would be the same as an RTP stream in aggregate (I believe ICE's throttling limit was in fact approximately the rate of RTP by design, if I recall correctly).

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 17 Sep 2011 17:27:12 +0000

> They will be able to use the rtcweb data channel, which is a concern.

Yes, that's actually the most interesting piece of this whole thing, in my opinion.  Browsers don't typically offer raw sockets to javascript as far as I know.  And not only does it raise a lovely set of security concerns, but also network collapse issues since UDP has no congestion backoff and I believe the data channel we're talking about is UDP(?).

And since the data channel is actually peer-to-peer rather than client-to-server, the issues with not standardizing its protocol become harder. I.e., leaving it a raw socket will only work if it goes between the same javascripts, inside the same domain - if that's ok, then the only issue is this would be put into SDP, and SDP isn't constrained by a javascript domain.  Hmm... gosh, if only rtcweb didn't use SDP as its browser API...
:)

-hadriel

---

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

On 09/17/2011 10:27 AM, Hadriel Kaplan wrote:
> There's a concern that malicious javascript can make your Browser start sending RTP packets at a target, and that enough people running such a javascript would be a nice botnet flooding a target.  For example, there could be some malicious website which has some interesting content on it to draw people to go to it (for example it mirrors real content from somewhere else, or it offers pirated content downloading, or porn, or whatever), and on the same webpage it embeds javascript that makes your Browser start sending RTP packets against root DNS servers or whatever.  IF they got enough browsers viewing their webpage, then it would be a DDoS flood of RTP against the target.  And of course if we have a UDP-based Data channel and the javascript can decide what goes in the data packet, then it could craft something nasty, to either perform a heavier resource exhaustion attack, or whatever.  Ultimately the concern is that UDP has no SYN/SYN-ACK exchange like TCP does, to verify the
>    device you're going to send lots of packets to wants to receive any of them.
>

I'd be in favor of the "WebSIM" flavor of OpenSim as the test ground for 
your evil; with +Platform on OpenSim to make it "WebSim", thats a good 
start. I hesitate on further description of this here.

-- 

---

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 17 Sep 2011 22:01:00 -0700

> One open question is if javascript will even be allowed to open a media channel to a peer without human/user consent.  I thought we were requiring per-site consent.  I guess a malicious site could…

I don't see any reason not to allow (for instance) a data channel w/o
user consent.

> I wonder though if even requiring ICE is sufficient.  If I'm a malicious javascript, I could add enough ICE candidates against a target that it would be the same as an RTP stream in aggregate (I be…

At best this would be a DoS attack, however.

-Ekr

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 18 Sep 2011 10:09:20 +0200

On 09/16/2011 11:12 PM, Matthew Kaufman wrote:
>> extension that someone defines somewhere, and one is still not free 
>> to define extensions on the non-SDP side if one still requires the 
1) No reason that this should be the only interface. I've just argued 
that I think this interface needs to be supported
2) SDP has a relatively clean "ignore what you don't understand" 
extension model. It's not my impression that people who want to deploy 
stuff wait until the standards are done.
> For example: forcing the Opus codec to "music" mode no matter what the 
I haven't seen the definitions for signalling Opus in SDP, so don't know 
if such a capability is described there (which may or may not illustrate 
your point).

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 18 Sep 2011 11:32:53 +0200

On 09/18/2011 07:01 AM, Eric Rescorla wrote:
> On Sat, Sep 17, 2011 at 10:27 AM, Hadriel Kaplan<[email-masked]>  wrote:
I think it's reasonable to aim to do somewhat better than current HTTP 
practice, but not to demand that security for UDP connection be at a 
totally different level than for HTTP/WS connections. When the WG has 
talked about user consent, that has been related to use of user's camera 
and microphone.
> At best this would be a DoS attack, however.

And I see every reason for the browser to rate-limit the number of 
unsuccessful connection attempts a script can make.

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Sun, 18 Sep 2011 04:26:30 -0700

> if such a capability is described there (which may or may not illustrate

It's described in Section 7 of the current payload draft: 
https://datatracker.ietf.org/doc/draft-spittka-payload-rtp-opus/

There's no facility for forcing a "music" mode in the SDP because this 
can be done unilaterally by the encoder, as Opus currently requires 
decoder support for all modes to avoid negotiation failure. Also, as 
I've said before, this is about more than just the encoding format. It 
has (arguably more important) ramifications for the front-end filtering 
done on the input audio signal (i.e., whether or not you're sending 
input from a low-quality mic vs. the direct output of a synth or even 
pre-recorded/generated content).

What we proposed before was a simple means of passing in a "hints" 
object (whether a JS object of some undetermined form or a string or 
something else) which could be used to control optional parameters like 
these. That's sufficient for the "music mode" case, where support on the 
encoder side is optional and you don't really need to know if it 
succeeded (i.e., it's not something that will show up in the SDP, 
whether it's generated by the browser or by script). I don't think it's 
sufficient for Matthew.

---

From: Dzonatas Sol <[email-masked]>
Date: Sun, 18 Sep 2011 09:41:06 -0700

On 09/18/2011 02:32 AM, Harald Alvestrand wrote:
>>> There's a concern that malicious javascript can make your Browser 
>>> start sending RTP packets at a target, and that enough people 
>>> running such a javascript would be a nice botnet flooding a target.  
>>> For example, there could be some malicious website which has some 
>>> interesting content on it to draw people to go to it (for example it 
>>> mirrors real content from somewhere else, or it offers pirated 
>>> content downloading, or porn, or whatever), and on the same webpage 
>>> it embeds javascript that makes your Browser start sending RTP 
>>> packets against root DNS servers or whatever.  IF they got enough 
>>> browsers viewing their webpage, then it would be a DDoS flood of RTP 
>>> against the target.  And of course if we have a UDP-based Data 
>>> channel and the javascript can decide what goes in the data packet, 
>>> then it could craft something nasty, to either perform a heavier 
>>> resource exhaustion attack, or whatever.  Ultimately the concern is 
>>> that UDP has no SYN/SYN-ACK exchange like TCP does, to verify 
> the
>>> So ICE does that for you - it verifies the IP:port you're going to 
>>> send your RTP packets to is willing to accept your packets. (it has 
>>> some other security properties too, but I personally find the rest 
>>> questionable, compared to this one)
>>> So basically we're stuck with requiring ICE be used for every 
>>> media/data session, and thus not being able to interop directly with 
>>> devices which don't do ICE (which is most of the SIP world right now).
>>>
>>> One open question is if javascript will even be allowed to open a 
>>> media channel to a peer without human/user consent.  I thought we 
>>> were requiring per-site consent.  I guess a malicious site could 
>>> still offer legitimate media usage, and thus get user's consent, and 
>>> then sometime in the future the same website could turn evil; or it 
>>> could offer seemingly legitimate service that works, while in 
>>> javascript creating a forked stream that is the one attacking 
>>> someone else.
> talked about user consent, that has been related to use of user's 
> camera and microphone.
>>
>>> I wonder though if even requiring ICE is sufficient.  If I'm a 
>>> malicious javascript, I could add enough ICE candidates against a 
>>> target that it would be the same as an RTP stream in aggregate (I 
>>> believe ICE's throttling limit was in fact approximately the rate of 
>>> RTP by design, if I recall correctly).

One difference someone could introduce is pre-mapped and canonicalized 
resource names (and labels). For example, each escaped and underline 
name version matches a date; then, the connection must be done JIT such 
that that any eval() of the date-to-name is already done.

See also this with private resources in mind: 
http://wiki.secondlife.com/wiki/LSL_http_server

So maybe it's more clear how we could go from that to RTP usage, so SIP 
is helpful, yet somewhat backwards step in progress. Either way, the 
resource either expire or stay open for recorders/playback (as different 
from rougher rate-limits).

At minimal, we need ICE for the resource names that are already 
standard. Then we contemplate next either S/MIME or SSRC based on 
direction of duplex. I'd leave in the sideband option (in 802.11n?) even 
if it's not on the agenda, sideband is like voice and data already 
mapped like DSL, yet again, I would digress to spectrum.

Thanks.

-- 

---

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Mon, 19 Sep 2011 10:59:08 +0530

Ted/Cary,

I agree with you totally. The intention of RTCWeb default signaling
protocol is to build the real-time application by any JavaScript web
developer without the understanding intricacies of underlying signaling
protocol. Also, the default signaling protocol is not going to stop any
innovative new or existing signaling protocol in RTCWeb client(browser).

IETF provides default signaling protocol and W3C provides browser API.

Thanks

Partha

From: [email-masked] [mailto:[email-masked]] On Behalf
Of cbran
Sent: Saturday, September 17, 2011 2:21 AM
To: Ted Hardie; Jim McEachern
Cc: <[email-masked]>
Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About
defining a signaling protocol for WebRTC (or not)]

+1 Ted - totally agree.

On Thu, Sep 15, 2011 at 8:23 PM, Jim McEachern
<[email-masked]> wrote:

Hadriel,
Well said.

<snip>
The only thing we need to do for rtcweb is make sure the RTP library
built into the browser supports media in such a way that it can
communicate with other RTP peers at a media plane, regardless of what
signaling protocol those peers might be using, preferably without going
through media gateways.  And ... we need to make sure it's possible to
use SIP on the rtcweb server....
</snip>

I think there is more to it than this for it to be a success.  We have
to make sure that it is relatively easy to adopt  rtcweb in javascript
applications.  The way we've discussed that in the past was "2 party
video chat in 20 lines of javascript".   If a novel signalling protocol
is created every time, that won't be a practical choice.  Even if the
signalling is segmented into libraries, the app will have to download
the one in use by a particular website, potentially every time.  This is
better than a plugin in some ways and potentially actually worse in
others.

We also have to make sure that the resulting application does not flood
or fry the network. That means it will have to have real congestion
control mechanisms.   Trusting the javascript application for that has
some real issues which we've already discussed.   Splitting signaling
and congestion control isn't a lot better.  If congestion control at the
network level is managed by the browser but signalling is in the
javascript, then information about that state has to pass into the JS
application, so it can manage the signalling.  That makes the APIs more
complex and runs the risk that a naive javascript application will not
adjust to the congestion control requirements at all.

The early web took off in part because of the ease of embedding things
like images (compared to gopher, for example) into rich content.  We
have the opportunity to create native web applications with much richer
and more interactive experiences with rtcweb, but if it is not easy to
do, it won't have the same impact.  If this is something that can be
done only by folks who can roll their own signalling protocol, it's
dead, because the number of content authors is too small.  If it even
requires selecting among an unbounded set of variously maintained
libraries , it will be frustrating for the developer of simple
applications.   At that level, the existing plugins will simply be more
stable and better known.

Providing baseline APIs into a well-known signaling capability seems to
me far more likely to result in a real flowering of rtcweb content.
That's why I want it.

Ted

________________________________

---

From: Randell Jesup <[email-masked]>
Date: Mon, 19 Sep 2011 02:26:00 -0400

+1 (comments below in-line)

On 9/16/2011 4:43 PM, Ted Hardie wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hadriel,
>     Well said.
>
>     The only thing we need to do for rtcweb is make sure the RTP
>     library built into the browser supports media in such a way that
>     it can communicate with other RTP peers at a media plane,
>     regardless of what signaling protocol those peers might be using,
>     preferably without going through media gateways.  And ... we need
>     to make sure it's possible to use SIP on the rtcweb server....
>     </snip>
>
>
> video chat in 20 lines of javascript".   If a novel signalling 
> protocol is created every time, that won't be a practical choice.  
> Even if the signalling is segmented into libraries, the app will have 
> to download the one in use by a particular website, potentially every 
> time.  This is better than a plugin in some ways and potentially 
> actually worse in others.

I agree whole-heartedly.  My (and I'll say Mozilla's) position is that 
we believe that while enabling unique new signalling and negotiation 
makes interesting new applications possible, we also must make sure that 
this ability is equally available to a (say) games developer who wants 
to add voice or video chat to their game without having to learn or 
understand 20 years of discussions and experience with signalling and 
media protocols.

The point was made repeatedly when I explained this primary area of 
contention that we want it to be easy to use by the "little guys", and 
that even if signalling was a downloaded JS library, you'd end up with a 
wild mixture of old versions in use, which may complicate 
interop/federation (plus the overhead to pull them down, and some 
possible security issues).

>
> We also have to make sure that the resulting application does not 
> flood or fry the network. That means it will have to have real 
> congestion control mechanisms.   Trusting the javascript application 
> for that has some real issues which we've already discussed.   
> Splitting signaling and congestion control isn't a lot better.  If 
> congestion control at the network level is managed by the browser but 
> signalling is in the javascript, then information about that state has 
> to pass into the JS application, so it can manage the signalling.  
> That makes the APIs more complex and runs the risk that a naive 

I think we do want to optionally include the JS application in the 
decisions about bit allocation, but handle it automatically for most 
cases.  A class of complex WebRTC apps will want to be able to allocate 
the bits themselves, and in some cases drop or add streams (or switch 
operation modes) in response to bandwidth changes.  Details to be 
determined; I plan to make a proposal on this.  However, unless you go 
out of your way none of this will impinge on your straightforward WebRTC 
app.

> have the opportunity to create native web applications with much 
> richer and more interactive experiences with rtcweb, but if it is not 
> easy to do, it won't have the same impact.  If this is something that 
> can be done only by folks who can roll their own signalling protocol, 
> it's dead, because the number of content authors is too small.  If it 
> even requires selecting among an unbounded set of variously maintained 
> applications.   At that level, the existing plugins will simply be 
> more stable and better known.

+1

>
> Providing baseline APIs into a well-known signaling capability seems 
> to me far more likely to result in a real flowering of rtcweb 
> content.  That's why I want it.
>

-- 
Randell Jesup
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Mon, 19 Sep 2011 03:22:30 -0400

> Yes, that's actually the most interesting piece of this whole thing, in my opinion.  Browsers don't typically offer raw sockets to javascript as far as I know.  And not only does it raise a lovely…

Actually DTLS channels; they're effectively UDP, but encrypted.  However,
per a few messages you'll have seen from me, discussion at the last IETF
and the call a week and a bit ago, we will plan to extend the congestion
control domain to include controlling the data channels.  Ironically
reliable data channels would be easier to handle than unreliable (you
could just use TCP-over-UDP); but we plan to do better than that.

> And since the data channel is actually peer-to-peer rather than client-to-server, the issues with not standardizing its protocol become harder. I.e., leaving it a raw socket will only work if it go…

Well, depending on how the data channels are set up, they may not be required
to include in the SDP at all; they could be instantiated on-demand in the
of an open PeerConnection.

Data channels at this point are assumed to be application-specific and not
subject to being exchanged during federation; we should think a little about this.

-- 
Randell Jesup
[email-masked]

---

From: José Luis Millán <[email-masked]>
Date: Mon, 19 Sep 2011 12:17:37 +0200

Hi,

2011/9/19 Randell Jesup <[email-masked]>

>  On Thu, Sep 15, 2011 at 8:23 PM, Jim McEachern <[email-masked]<mailto:
>> jim.mceachern@genband.**com <[email-masked]>>> wrote:
>>
>>    Hadriel,
>>    Well said.
>>
> I agree whole-heartedly.  My (and I'll say Mozilla's) position is that we
> believe that while enabling unique new signalling and negotiation makes
> interesting new applications possible, we also must make sure that this
> ability is equally available to a (say) games developer who wants to add
> voice or video chat to their game without having to learn or understand 20
> years of discussions and experience with signalling and media protocols.
>
> As far as I know, this is achieved by a user level API regardless of the
signalling controller nature; browser built-in or JS stack, which serves as
an abstraction of the library underlying ins and outs.

> contention that we want it to be easy to use by the "little guys", and that
> even if signalling was a downloaded JS library, you'd end up with a wild
> mixture of old versions in use, which may complicate interop/federation
> (plus the overhead to pull them down, and some possible security issues).

 I would say that Mixture of old versions and the possible security issues
are problems to face in any case.

> decisions about bit allocation, but handle it automatically for most cases.
>  A class of complex WebRTC apps will want to be able to allocate the bits
> themselves, and in some cases drop or add streams (or switch operation
> modes) in response to bandwidth changes.  Details to be determined; I plan
> to make a proposal on this.  However, unless you go out of your way none of
> this will impinge on your straightforward WebRTC app.
>
>
>
>> like images (compared to gopher, for example) into rich content.  We have
>> the opportunity to create native web applications with much richer and more
Regards,

>
> --
> Randell Jesup
> [email-masked]
>
>
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

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

On Sep 19, 2011, at 2:26 AM, Randell Jesup wrote:

> 
> The point was made repeatedly when I explained this primary area of contention that we want it to be easy to use by the "little guys", and that even if signalling was a downloaded JS library, you'd end up with a wild mixture of old versions in use, which may complicate interop/federation (plus the overhead to pull them down, and some possible security issues).

And you think having it in the Browsers won't end up with a wild mixture of old versions in use, and complicated interop/federation?  
And on top of it you'll end up with a wild mixture of signaling vendors, because there'll be a mixture of Browser vendors and it's unlikely they'll all use the same source code inside.  What's worse, it won't be controllable by the JS developer.  At least with a JS library they're all using the same source code, and the JS developer knows what it was/did if it was an older version.

With regard to the issue of overhead of pulling it down every time, I thought browsers cache JS scripts, no? 

-hadriel

---

From: <[email-masked]>
Date: Mon, 19 Sep 2011 11:40:33 +0000

Hi,

>browsers cache JS scripts, no?

I suppose scripts are no different from other resources on the web, so they can be cached even locally at the browser. So in principle, there shouldn't be a need to pull down the same script from the same site over and over. But as far as I know, caching is based on URLs and not URNs. This means that even if two sites were using the same library, caching wouldn't notice that, if the URLs were different. I don't know if there is a solution to this (other than actually sharing the URL , which might not be practical). It would be interesting to learn. 

Markus

>Of ext Hadriel Kaplan
>Sent: 19 September, 2011 13:23
>To: Randell Jesup
>Cc: <[email-masked]>
>contention that we want it to be easy to use by the "little guys", and that even
>if signalling was a downloaded JS library, you'd end up with a wild mixture of
>old versions in use, which may complicate interop/federation (plus the
>overhead to pull them down, and some possible security issues).
>
>
>And you think having it in the Browsers won't end up with a wild mixture of
>old versions in use, and complicated interop/federation?
>And on top of it you'll end up with a wild mixture of signaling vendors,
>because there'll be a mixture of Browser vendors and it's unlikely they'll all
>use the same source code inside.  What's worse, it won't be controllable by
>the JS developer.  At least with a JS library they're all using the same source
>code, and the JS developer knows what it was/did if it was an older version.
>

---

From: Randell Jesup <[email-masked]>
Date: Mon, 19 Sep 2011 09:53:34 -0400

> And you think having it in the Browsers won't end up with a wild mixture of old versions in use, and complicated interop/federation?

Not compared to the complexity if it's all "roll-your-own".  No one suggested that
people be locked into a signalling protocol, and JS libraries are an option.  We do
have a lot of experience with pseudo-standard APIs implemented in JS, such as jquery
and many others, and these aren't unrealistic concerns.

I lean towards a proposal I made a week or two ago; to allow full access (which allows
user-written JS signalling libraries) but provide minimal SIP+O/A as an option within
the browser.  This could be a JS library, but the primary users of this would be the
"little guys" who just want simple setup of media streams, and they're most likely to
never update, while browsers are updated frequently.

> And on top of it you'll end up with a wild mixture of signaling vendors, because there'll be a mixture of Browser vendors and it's unlikely they'll all use the same source code inside.  What's wors…

That's entirely available to the application; they can use their own if they wish.
And while I suggest a simple SIP set be included, if we were certain a "standard" JS
lib were freely available and solid enough, that would make the argument stronger for
a JS lib.

> With regard to the issue of overhead of pulling it down every time, I thought browsers cache JS scripts, no?

Yes, and as of Firefox 3 if a script is served with Cache-Control: public, it will be
cached to disk even if coming from https.  Note that secure (https) content by default
isn't cached unless cache-control options are set.

I would strongly warn against fetching JS libs for a service like this over http, and as
part of the security review here we may well go further than that.

-- 
Randell Jesup
[email-masked]

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 19 Sep 2011 16:01:16 +0200

19 sep 2011 kl. 15:53 skrev Randell Jesup:

> but provide minimal SIP+O/A as an option within
> the browser

My apologies, but I don't think you know how hard that would be to define. SIP lite sounds simple, but is not a small task to define in the IETF.  

Looking back, I think the SIP RFC should had taken the same path as XMPP, one RFC for "core protocol basics" and one for the first app "PSTN telephony". That way we could have based a new dialect on the core and moved forward without listening to requirements to backporting all the stuff that is "SIP" today. Unfortunately, we're far away from that position today.

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 19 Sep 2011 16:03:17 +0200

2011/9/19 Randell Jesup <[email-masked]>:
> And while I suggest a simple SIP set be included, if we were certain a "standard" JS lib were freely available and solid enough, that would make the argument stronger for a JS lib.

Hi. Are you proposing that browsers should/would speak SIP for media
signaling? That would require a signaling central point (think about
NAT), does it mean that web sites should provide a like-"SIP proxy"
within their infraestructure? (think about web sites hosted in shared
datacenter by an Apache or other web server not behind the control of
the web developer).

Regards.

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

---

From: Randell Jesup <[email-masked]>
Date: Mon, 19 Sep 2011 10:20:02 -0400

On 9/19/2011 10:03 AM, Iñaki Baz Castillo wrote:
> 2011/9/19 Randell Jesup<[email-masked]>:
> signaling?
More that they provide a predefined API module(s) that would handle the simple
case using SIP/O+A.

> That would require a signaling central point (think about

It would require a SIP proxy only if the app developer decides to use the SIP
module.

-- 
Randell Jesup
[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Sep 2011 07:24:05 -0700

On Mon, Sep 19, 2011 at 6:53 AM, Randell Jesup <[email-masked]> wrote:
>> And you think having it in the Browsers won't end up with a wild mixture
>> of old versions in use, and complicated interop/federation?
>

Randell,

Does auto-updating change the landscape in terms of the browser
version distribution?

Mozilla have measurements on what fraction of the modern (i.e. post FF4)
browser base is running the latest version of Firefox?

Thanks,
-Ekr

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 19 Sep 2011 09:26:18 -0500

+1

Very solidly argued.

Henry

On 9/16/11 1:29 PM, "Hadriel Kaplan" <[email-masked]> wrote:

>> The disadvantage of parsing to another structure (I am fond of JSON myself)
>> is that one has to maintain a data definition for the format being parsed to,
>> a defined transform between that and the "canonical SDP structure" has to be
>> implemented in user space when one does SDP interoperability, both of those
>> have to be updated for every SDP extension that someone defines somewhere,
>> and one is still not free to define extensions on the non-SDP side if one
>> still requires the ability to map them into SDP.
>> 
>> extension to the format gets documented, the browsers are the ones who *have*
>> to parse it (although others are likely to).
> 
> 
> Right so the above paragraphs get to the heart of the matter, methinks.
> Ultimately we need W3C to define an API, and the API has to provide a means of
> learning RTP/media info from the browser and commanding the browser to perform
> certain things with RTP/media.  One could expose this API as a true data
> structure, or as a long string of tokens to be parsed/serialized back/forth.
> If the latter, then the choices are basically JSON or SDP.  And SDP seems
> advantageous because it appears to be the least work for the simple use-cases,
> because the javascript could just copy back/forth the SDP between the browser
> and server.  In other words you're optimizing for the very simple use-cases,
> in exchange for making it more complicated for the advanced use-cases.  Right?
> 
> OK, that's a laudable goal.  And I recognize that the decision has basically
> already been made, and nothing's going to change it.
> 
> 1) Incorporating SDP and the offer/answer model into the Browser and W3C API
> inexorably ties the W3C to the IETF MMUSIC working group for all time.  So
> far, I had been going on the assumption the IETF would be defining what the
> RTP library had to do/expose, while W3C would define the API.  But if the API
> includes SDP offer/answer, that portion is the IETF's domain too, afaik.
> Anything the W3C wants to do in the future for that has to go through the
> IETF, not just IANA. (right?)
> 
> 2) This isn't just about JSON vs. SDP - it's about SDP *offer/answer*.  SDP
> offer/answer wasn't meant to be an API between an application and its RTP
> library - it's a *protocol* between applications.  One side-effect of this is
> it has historic state.  For example, if an SDP offer contains two media lines,
> and one media is removed, the number of SDP media lines don't reduce back to
> one - EVER.  So if PeerConnection.removeStream() is invoked, the Browser needs
> to remember there was that stream and signal it in SDP as disabled for all
> time, until PeerConnection is closed.  If addStream() is invoked later, it
> could/could-not re-use that same (disabled) media line, or add a new one.
> 
> As another example, if a new SDP offer is sent out in SIP and gets rejected
> with a 488, the session reverts to the previously agreed SDP state.  The
> Browser would therefore have to keep state of previous SDP and revert to it to
> handle this case.  For example, if my Javascript started with only an audio
> MediaStream in PeerConnection and later added a video MediaStream to it, the
> new SDP offer would contain two media lines - if the offer gets rejected with
> 488, how is that communicated to the Browser and what will the browser do?
> 
> 3) You might well want information conveyed across that "API" that is not
> meant to be sent on the wire in SDP - things you don't want defined by IANA as
> SDP tokens.  For example, you may want to provide packet counts, jitter,
> latency, and other meta-information about individual RTP codecs.  Using JSON
> allows you to have data member variables which will not get serialized into
> SDP, but are purely for the javascript's use, while still within the
> referential tree structure of the media stream info.  Or they may be for
> sending to peers, but simply not for SDP. (like you could send the
> jitter/latency info through the signaling channel)
> 
> 4) Obviously if the application as a whole needs to do SDP offer/answer, then
> *someone* will have to implement it correctly, including the state-related
> stuff.  It could be the browser or the javascript that do this.  Chrome may do
> a perfect job of that in the browser, afaik.  But there are other browser
> vendors, including niche ones such as Dolphin and Skyfire.  What are the odds
> they all get it right the first time?
> 
> So which would you rather have updating an SDP engine, if one is even
> needed... or updating "every SDP extension that someone defines somewhere":
> the javascript which is written by the developer that knows what they want
> when they want it, and can update their code by updating their javascript (or
> not if they don't need to); or the browsers which are written by companies not
> under the javascript developer's control, at a time of the browser companies'
> choosing? 
> 
> Obviously for some things the browser will have to be updated regardless, for
> example to understand rather than just ignore new JSON entries, to provide new
> codecs, etc.  But not all new SDP attributes require changes in the media
> plane, nor encoding into JSON.  In fact, a lot doesn't - some of it's
> higher-application info, not really for the RTP library, and more of it's
> coming in the future.
> 
> -hadriel
>

---

From: Jim McEachern <[email-masked]>
Date: Mon, 19 Sep 2011 14:52:16 +0000

Comment inline

Jim

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Randell Jesup
> Sent: Monday, September 19, 2011 9:54 AM
> To: [email-masked]
> Not compared to the complexity if it's all "roll-your-own".  No one suggested
> that people be locked into a signalling protocol, and JS libraries are an option.
> We do have a lot of experience with pseudo-standard APIs implemented in
> JS, such as jquery and many others, and these aren't unrealistic concerns.
> 
> I lean towards a proposal I made a week or two ago; to allow full access
> (which allows user-written JS signalling libraries) but provide minimal
> SIP+O/A as an option within the browser.  This could be a JS library, but the
> primary users of this would be the "little guys" who just want simple setup of
> media streams, and they're most likely to never update, while browsers are
> updated frequently.

Are you suggesting that the "minimal SIP+O/A as an option within the browser" be baked into the browser, or simply provided as a standard JS library that would be made available to those who wanted to use it.  It sounds like you are suggesting the later, but I want to be certain, since it could make a big difference.

> And while I suggest a simple SIP set be included, if we were certain a
> "standard" JS lib were freely available and solid enough, that would make the
> argument stronger for a JS lib.
> 
> Yes, and as of Firefox 3 if a script is served with Cache-Control: public, it will
> be cached to disk even if coming from https.  Note that secure (https)
> content by default isn't cached unless cache-control options are set.
> 
> I would strongly warn against fetching JS libs for a service like this over http,
> and as part of the security review here we may well go further than that.
> 
> 
> --
> Randell Jesup
> [email-masked]
>

---

From: Randell Jesup <[email-masked]>
Date: Mon, 19 Sep 2011 10:59:11 -0400

On 9/19/2011 10:24 AM, Eric Rescorla wrote:
> On Mon, Sep 19, 2011 at 6:53 AM, Randell Jesup<[email-masked]>  wrote:

Absolutely.

> browser base is running the latest version of Firefox?
I know there are better figures out there (but I'm not sure if they're
public, and I'm just working off these).

http://www.w3schools.com/browsers/browsers_firefox.asp

Note that FF6 was released during the middle of August, so 9.5% FF6,
15.9% FF5 (2.9% FF4) is actually pretty good.

May->July went from 23.4% FF4, 0.3% FF5 (betas probably) to 4.6% FF4,
23.2% FF5 (0.6% FF6 betas).

Those are out of all browsers, not just firefox, so the totals for firefox
are around 40-42%.

FF3.6 users are around 10% (roughly 1/4 of FF users) and slowly declining.
There are issues there with large managed deployments; I won't re-open that
can of worms here beyond saying we're working with such users to find ways
to get them the ability to move forward.

Chrome by all accounts has a higher uptake of new versions; largely from
the silent background update behavior and partly from not having (or having
less) locked-down enterprise deployments the way IE and Firefox do.

We're looking into ways to make updating easier, more automatic and less
painful for users without violating the principle of user control. (Again,
a topic for another forum.)

-- 
Randell Jesup
[email-masked]

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Mon, 19 Sep 2011 17:06:24 +0200

Hi,

> It would require a SIP proxy only if the app developer decides to use the SIP

I might be missing something, but how would Alice communicate with Bob if both are behind NAT and there is no server involved? Asking some IP and port out of band? I'm not aware of any Bonjour-style protocol for the Internet, is there something similar which could be leveraged?

I see no clean way for 2 browsers to communicate without a server involved, and since it's not feasible to mandate that every browser manufacturer deploys one, I'd rather not have any simplified or default protocol.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 19 Sep 2011 17:46:54 +0200

Hardiel,

As we all low to discuss and nitpick each other arguments I do have a
comment on some of your points.

On 2011-09-16 20:29, Hadriel Kaplan wrote:

> 
> But email's free... so for the sake of posterity (and email
> archiving) here're some reasons not to use SDP anyway:
> 1) Incorporating SDP and the offer/answer model into the Browser and
> W3C API inexorably ties the W3C to the IETF MMUSIC working group for
> all time. So far, I had been going on the assumption the IETF would
> be defining what the RTP library had to do/expose, while W3C would 
> define the API. But if the API includes SDP offer/answer, that 
> portion is the IETF's domain too, afaik. Anything the W3C wants to do
> in the future for that has to go through the IETF, not just IANA. 
> (right?)

Depends on what parts of SDP you want to extend. And in fact most things
can be done with not having to write an RFC.

SDP attributes (a=) has the registration policy of Specification
Required which means W3C can do what they want themselves an then ask
IANA for registration.

The Proto needs an RFC, but it can be RFC-editor or Informational.
However, as new proto is a new transport, I do expect some IETF
involvement anyway to make sure it works with the existing ones.

I guess these are the two most important. And I am not going to discuss
all of them, especially as some extensions may more properly belong in
other parts of IETF than MMUSIC. For the ones interested in IANA rules
for SDP, go look at section 8 in RFC4566.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 19 Sep 2011 18:00:57 +0200

On 2011-09-17 19:27, Hadriel Kaplan wrote:
> Yes, that's actually the most interesting piece of this whole thing,
> in my opinion.  Browsers don't typically offer raw sockets to
> javascript as far as I know.  And not only does it raise a lovely set
> of security concerns, but also network collapse issues since UDP has
> no congestion backoff and I believe the data channel we're talking
> about is UDP(?).

Well, it is something over UDP. We clearly need UDP for NAT traversal
considerations. However, we also clearly need congestion control
implemented in the browser, not in the JS to prevent two targets to
unfairly saturate the path between the peers.

> 
> And since the data channel is actually peer-to-peer rather than
> client-to-server, the issues with not standardizing its protocol
> become harder. I.e., leaving it a raw socket will only work if it
> goes between the same javascripts, inside the same domain - if that's
> ok, then the only issue is this would be put into SDP, and SDP isn't
> constrained by a javascript domain.  Hmm... gosh, if only rtcweb
> didn't use SDP as its browser API... :)

We need to standardize a number of Transport protocol functionalities
for the RTCWEB data transport solution. To the degree that I do like to
resurface some of my earlier suggestions around this. Why not use DCCP
with TFRC or TCP like congestion control tunneled over UDP.

The whole specification is ready. Which avoids any hiccup with the
transport people and IESG.

We can run either IP/UDP/DCCP/DTLS or specify the reverse if we want to
protect also DCCP headers by defining IP/UDP/DTLS/DCCP.

The main argument has been against implementation readiness of this
solution. I would note that any homegrown solution will also not be
implemented and available. And there do exist some stack implementations.

And when it comes to complexity, one will realize that most functions
are in fact needed anyway.

Cheers

Magnus Westerlund

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 19 Sep 2011 12:38:32 -0400

I am 100% with Randell.  (Incidentally, my idea of "minimal SIP" has 
been that the browser keeps the SIP state machine while receiving and 
sending SIP messages, with parsing left to application: the outbound 
parameters are supplied--and the inbound ones interpreted--by the JS 
application. In this way, pretty much all versions of SIP can be 
accomodated, while none of them has to be supported by the browser.)

On a different topic, I am confused by the very name of this thread, as 
well as the "was" thread that it replaced. I thought that RTCWeb was 
about "packaging" the existing protocols, not inventing new ones...

Igor

On 9/19/2011 9:53 AM, Randell Jesup wrote:
> ...
> ...
> "standard" JS
> ....

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 19 Sep 2011 18:40:52 +0200

> are in fact needed anyway.

Just to throw in another abbreviation: MSRP

Isn't MSRP developed for this kind of sessions between users? Is there something in the protocol design that stops it from being p2p?

With MSRP, there's development experience as well as NAT traversal solutions.

/O

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Mon, 19 Sep 2011 09:55:48 -0700

> Isn't MSRP developed for this kind of sessions between users? Is there something in the protocol design that stops it from being p2p?

Perhaps I'm confused, but doesn't MSRP rely on reliable, in-order delivery?

---

From: Dzonatas Sol <[email-masked]>
Date: Mon, 19 Sep 2011 10:06:13 -0700

> With regard to the issue of overhead of pulling it down every time, I thought browsers cache JS scripts, no?

They should cache the JIT resultant bytecode.

-- 

---

---

From: Randell Jesup <[email-masked]>
Date: Mon, 19 Sep 2011 14:44:23 -0400

On 9/19/2011 10:52 AM, Jim McEachern wrote:

> I lean towards a proposal I made a week or two ago; to allow full 
> access (which allows user-written JS signalling libraries) but provide 
> minimal SIP+O/A as an option within the browser. This could be a JS 
> library, but the primary users of this would be the "little guys" who 
> just want simple setup of media streams, and they're most likely to 

I am suggesting that it be baked into the browser, but optional to use.  I am
willing to consider alternatives that provide similar ability to the web author,
such as external "standard" libraries, or intermediate forms like someone
suggested such as the SIP state machine in the browser, but parsing in the JS
(which would also require a "standard" external library, just smaller).

-- 
Randell Jesup
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Mon, 19 Sep 2011 14:51:11 -0400

> I see no clean way for 2 browsers to communicate without a server involved, and since it's not feasible to mandate that every browser manufacturer deploys one, I'd rather not have any simplified or…
You misunderstood me; I meant "if you use an optional SIP module, you'll
need to have a SIP proxy on your server".  WebRTC in general presumes some sort
of server architecture to solve the discovery/invitation problem.  There *are*
some possible uses of WebRTC that might not use a central server(s).   The simplest
would be the "phone-tag" server, where you and the person you want to talk to
exchange IP addresses and external port numbers over the phone, and type them into
the web app, which then opens a default-configured PeerConnection and re-negotiates
to the actual configuration.

-- 
Randell Jesup
[email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 19 Sep 2011 21:14:35 +0200

> transport people and IESG.
The last few times this has surfaced, the conversation has turned 
suddenly silent when I've asked where to find a DCCP-over-TFRC stack I 
can experiment with.... are there any out there that are "production ready"?

The pseudoTCP stacks in libjingle have seen service for a long time....

                 Harald

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 19 Sep 2011 13:33:29 -0700

...
> devices which don't do ICE (which is most of the SIP world right now).

To work, they "just" need to do ICE-Lite.  ICE-Lite is the ability to 
respond to ICE's media path STUN messages.  ICE-Lite does not require a 
STUN server, does not require a TURN server, and does not require 
gathering IP addresses that everyone finds (oddly) difficult.

Those that don't do ICE-Lite can be front-ended with an SBC that does
ICE-Lite for them.

> One open question is if javascript will even be allowed to open a media
> channel to a peer without human/user consent. 

I'll bet a beer it'll happen without human consent, yes.

> I thought we were
> requiring per-site consent.  I guess a malicious site could still offer
> legitimate media usage, and thus get user's consent, and then sometime
> in the future the same website could turn evil; or it could offer
> seemingly legitimate service that works, while in javascript creating a
> forked stream that is the one attacking someone else.
> 

Yep, if you 0wn enough hosts, just their "can I send you a flood of
media packets" requests could, itself, be a flood of traffic.

Let's talk about DNSSEC responses being a source of attack.

-d

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Mon, 19 Sep 2011 22:33:47 +0200

Hi,

> to the actual configuration.

Still, you need this "phone-tag" server, so who will provide it? I don't see a way for 2 parties to communicate without help from outside the browser, thus, I wouldn't define any sort of protocol, even if we could simplify one.

My 2 cents,

--
Saúl Ibarra Corretgé
AG Projects

---

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

> Still, you need this "phone-tag" server, so who will provide it? I don't see a way for 2 parties to communicate without help from outside the browser, thus, I wouldn't define any sort of protocol,…

The purpose of including a protocol (which is optional to use) isn't to allow
direct browser-to-browser discovery or initiation without a server.  In fact,
it doesn't help *or* hurt that use-case.  A primary reason for including a protocol
is to make it easy to build things.  We don't *just* want organizations with the
resources of Google or Skype or Cisco (or Mozilla) to be the ones who can make
use of this new capability; we want all web developers to feel it's within their
grasp.  This could be satisfied in a few ways, as discussed: "baked in" simple
SIP/O+A; a JS lib plus support pieces for SIP/O+A like the state machine baked
in; or a pure JS implementation.  But we are wary of putting it out with merely
the hope that a good-enough JS lib will show up someday (and there are other pros
and cons; no need to repeat them here).

As far as needing external servers: there are some ideas we're floating around
that would allow for server-less or virtually server-less operation of WebRTC
clients including discovery and initiation, from behind NATs.  We haven't
speced it out or even proven it's workable yet, but we're going to look very
closely at some type of proof-by-existence for this idea.

-- 
Randell Jesup
[email-masked]

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 19 Sep 2011 15:46:14 -0700

On 9/19/2011 3:36 PM, Randell Jesup wrote:
> is to make it easy to build things.
>

By that logic we should have a built-in shopping cart to make creating 
web storefronts easier, a built-in email client to make it easier to 
build the next Gmail, etc.

Except that all the interesting things that have ever happened on the 
web are because clever people used the minimal built-in stuff to make 
something much more than the sum of its parts, not because the masses 
used the pre-built parts to replicate what already exists.

I don't want my web browser to have a phone inside of it. I want my web 
browser to be the thing that someone turns into the next great real-time 
communications experience... whatever that is.

Matthew Kaufman

---

From: Roman Shpount <[email-masked]>
Date: Mon, 19 Sep 2011 18:59:15 -0400

Randell,

What I fail to understand is in what way would adding signaling to the web
browser would  make things easy to build? How is what you are proposing
better then 2 or 3 well written samples?

On the other hand, if you decide to build such simple signaling interface,
depending on what use case you are trying to address you will end up with
very different libraries. You have to decide how complex you want to make
this library on the server vs the client side. You will need to decide if
the purpose of this library is to simplify browser-to-browser or
browser-to-PSTN calls. There is going to be a large number of very complex
decisions none of which have obvious answers and will greatly affect the
overall library design.

Most importantly, I think this is a misconception that you can build
something that can be developed in 20 lines or less and be useful. Real-time
communication is order of magnitude more complex then most of the web
related applications. You need to deal with multiple event sources, deal
with event collisions, negotiation failures, call state machines. And this
is what required for the basic call setups. Once you start dealing with
transfers, conferences, call status monitoring, things become even more
complex. It is almost impossible to develop something that is simple to use
that serves more then one or two specific use cases. If we try to invent
something like this we might never finish.
_____________
Roman Shpount

On Mon, Sep 19, 2011 at 6:36 PM, Randell Jesup <[email-masked]>wrote:

>>>  Still, you need this "phone-tag" server, so who will provide it? I don't
>> see a way for 2 parties to communicate without help from outside the
>> browser, thus, I wouldn't define any sort of protocol, even if we could
>> simplify one.
>>
>

---

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

Hi Roman,

I agree with you in case you wish to have all class 5 services in this architecture. In the web game server wherein the basic call has to be established between two parties, this complexity is not required. One of the main aim of the RTCWeb default signaling protocol is to make two party real-time communication easy with less development effort for any web developer.

Thanks

Partha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: Tuesday, September 20, 2011 4:29 AM
To: Randell Jesup
Cc: [email-masked]
Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]

Randell,

What I fail to understand is in what way would adding signaling to the web browser would  make things easy to build? How is what you are proposing better then 2 or 3 well written samples?

On the other hand, if you decide to build such simple signaling interface, depending on what use case you are trying to address you will end up with very different libraries. You have to decide how complex you want to make this library on the server vs the client side. You will need to decide if the purpose of this library is to simplify browser-to-browser or browser-to-PSTN calls. There is going to be a large number of very complex decisions none of which have obvious answers and will greatly affect the overall library design.

Most importantly, I think this is a misconception that you can build something that can be developed in 20 lines or less and be useful. Real-time communication is order of magnitude more complex then most of the web related applications. You need to deal with multiple event sources, deal with event collisions, negotiation failures, call state machines. And this is what required for the basic call setups. Once you start dealing with transfers, conferences, call status monitoring, things become even more complex. It is almost impossible to develop something that is simple to use that serves more then one or two specific use cases. If we try to invent something like this we might never finish.
_____________
Roman Shpount

On Mon, Sep 19, 2011 at 6:36 PM, Randell Jesup <[email-masked]> wrote:

-- 
Randell Jesup
[email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 20 Sep 2011 05:59:10 +0000

On Sep 20, 2011, at 1:27 AM, Ravindran Parthasarathi wrote:

> I agree with you in case you wish to have all class 5 services in this architecture. In the web game server wherein the basic call has to be established between two parties, this complexity is not required.

OK, let's take the game example... only 2-player games would be able to use a simple rtcweb-SIP agent.  Anything more than 2-player would want to use the multi-party "conferencing" model of rtcweb, which can't even be signaled with SIP today as far as I can tell. (not that I've thought about it too much, but I can't see how it would without some changes to SIP)

> One of the main aim of the RTCWeb default signaling protocol is to make two party real-time communication easy with less development effort for any web developer.

Why doesn't using JS libraries provide that ease of development, assuming there's a good "signaling agent" JS library for whatever communication model the deployer wants/needs?  If there isn't a good JS library, then one would wonder why we think all browsers will have a good built-in signaling agent instead. 

-hadriel

---

From: Randell Jesup <[email-masked]>
Date: Tue, 20 Sep 2011 02:39:24 -0400

> OK, let's take the game example... only 2-player games would be able to use a simple rtcweb-SIP agent.  Anything more than 2-player would want to use the multi-party "conferencing" model of rtcweb,…

It should be easy - either as N-1 2-person calls to the person hosting the game, or
N calls via a central server (equivalent to a mixer), or as a full mesh of direct
calls (3 2-person calls for a 3-person game, 6 for a 4-person game, etc), or even
sparse meshes (makes sense in a game where not all players are 'near' each other).

> Why doesn't using JS libraries provide that ease of development, assuming there's a good "signaling agent" JS library for whatever communication model the deployer wants/needs?  If there isn't a go…

Well, there are a lot more available C/C++ SIP libraries than JS SIP libraries
(I've heard of one non-open-I-assume one under development), to start with.
The same applies to XMPP (one known implementation - may not be free), etc.  Let
alone well-tested and used JS SIP/etc libraries.  Yes, we could develop them.  I
don't see that as being easier than developing the equivalent in C++, assuming
you decided to start both efforts from scratch - and one may well not have to
start from scratch.

-- 
Randell Jesup
[email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 20 Sep 2011 07:19:51 +0000

> sparse meshes (makes sense in a game where not all players are 'near' each other).

Can't do N-1 2-person calls to the person hosting the game, because rtcweb doesn't support "full" mixing in the browser, only local media mixing. (ie, everyone will hear the person hosting the game, and the person hosting the game will hear everyone else, but the rest won't hear each other)

Calls via a central media server require a central media server, which kinda defeats the "easy" concept and using our shiny new toy of rtcweb.

A full mesh is what *should* happen, but SIP/SDP can't do it, afaict.  It would treat them either as independent calls even at a media layer, or as a full-mixer conference focus model.  The closest thing we have would probably be the Join header, but I believe it's semantics is to join as a full mixer conf call.  Isn't this full-mesh media-forking thing actually a new semantic for SIP/SDP?  (it's hard to believe with 100+ drafts/RFCs this scenario hasn't already been addressed in SIP - I must be just having a memory leak)

-hadriel

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Tue, 20 Sep 2011 09:28:40 +0200

+1.

If we add some signaling protocol to the browser to ease web developers then someone might say "why don't we also add X, Y and Z". The browser only needs the media plane, the signaling can be elsewhere, and it's far better to have it elsewhere.

As Roman pointed out, RTC applications are not something that can nor should be done in 20 lines of JS. It's just complex. If people want to make simple apps they can build a simple JS library using an invented simple protocol. But RTCWeb shouldn't encourage this IMHO.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Randell Jesup <[email-masked]>
Date: Tue, 20 Sep 2011 03:45:59 -0400

> Can't do N-1 2-person calls to the person hosting the game, because rtcweb doesn't support "full" mixing in the browser, only local media mixing. (ie, everyone will hear the person hosting the game…

Ok; I hadn't looked at what controls we're giving the JS app (mostly focusing on IETF
level stuff).  W3C issue.  It would be nice if an app could set up a bridge; I'm
a little surprised it can't.

> Calls via a central media server require a central media server, which kinda defeats the "easy" concept and using our shiny new toy of rtcweb.

I never said all uses are easy.   Simple uses are easy (like 2-person games), complex uses
are possible (and as easy as we can do).  I'd like to avoid a separate mixer, though,
I agree.

> A full mesh is what *should* happen, but SIP/SDP can't do it, afaict.  It would treat them either as independent calls even at a media layer, or as a full-mixer conference focus model.  The closest…

SIP has been very focused on device<->server interaction, not device<->device.  However:
note that we have an app that knows why it has these calls in place; we're not defining an
abstract, portable protocol use here.

It would be worthwhile to work out the details of these 'mesh' and ad-hoc (bridged) conference models and if they fit into the security model, since they enable (and reduce the cost of) a
number of important uses.

-- 
Randell Jesup
[email-masked]

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 20 Sep 2011 10:09:24 +0200

2011/9/20 Ravindran Parthasarathi <[email-masked]>:
> One of the main aim of the RTCWeb default signaling protocol is to make two
> party real-time communication easy with less development effort for any web
> developer.

Hi, let me some comments please:

1) "RTCWeb default signaling protocol" is not defined neither it
exists. I would ask you for not talking about it as if it was already
approved since that could become confusing for readers. Also, given
other threads it's clear that most of the people here is contrary to a
"RTCWeb default signaling protocol" or "SIP built-in the browser".
They have also given good rationale across multiple threads.

2) If browsers speak pure SIP then the server side MUST also speak
SIP. How to accomplish with that in shared web hostings? Must the web
admins learn about SIP and installing/configuring a
OpenSER/Kamailio/OpenSIPS/SER SIP proxy/registrar? This question has
been made several times in some threads. No reply yet (same occurs
with other given arguments).

3) Making the signaling path a separate flow means that the web server
(so the web application in server side) would not be aware about
sessions status. So if for example two users visit the same page and
speak through their web browsers and later one of them logouts from
the web, the server has no easy way to force the call termination.
Neither a "forum-administrator" could reject an spammer from an audio
conference room (or it would be hard to accomplish). In contrast, if
the signaling is carried via HTTP/WebSocket, the logic is centralized
and the server application would be aware of existing sessions.

Best regards.

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 20 Sep 2011 08:17:15 +0000

> a little surprised it can't.

If it could, we'd probably have the siprec/remote-recording requirement accommodated.  :)

> abstract, portable protocol use here.

Aha!  So it's not "SIP" that you meant... you meant "something that looks like SIP but isn't SIP per the RFCs".  ;)

-hadriel

---

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

> If it could, we'd probably have the siprec/remote-recording requirement accommodated.  :)
Well, take a look at the source code for FreeSwitch or Asterisk and you'll see that "setting up a bridge" is not a piece of cake...
You are making the assumption that you have no formatting issues and don't need to change framerate for video, orientation or anything else or audio transcoding.

> Aha!  So it's not "SIP" that you meant... you meant "something that looks like SIP but isn't SIP per the RFCs".  ;)
According to RFC 3261 SIP is a peer 2 peer protocol and not a device->server protocol. Just making a point.

/O

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Tue, 20 Sep 2011 14:24:21 +0530

Hi Inaki,

I have answered to you in the another thread (http://www.ietf.org/mail-archive/web/rtcweb/current/msg01172.html).  I understand that there are lot of thread, So you might have confused.  As I indicated in the earlier mail, I'll come up with the write up to discuss the need for "RTCWeb default signaling protocol". Please note in the mail thread that there is no mention of SIP as a RTCWeb default signaling protocol. The argument is between "nothing" vs "default" signaling protocol.

SIP or XMPP based protocol will be selected as a default protocol based on technical merit of a given RTCWeb signaling problem but it is a second stage.

Thanks
Partha

>From: Iñaki Baz Castillo [mailto:[email-masked]]
>Sent: Tuesday, September 20, 2011 1:39 PM
>Cc: Roman Shpount; Randell Jesup; [email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 20 Sep 2011 08:56:11 +0000

> You are making the assumption that you have no formatting issues and don't need to change framerate for video, orientation or anything else or audio transcoding.

Nope, I'm not making any such assumption.  I was just pointing out that if the browser did full mixing, then we'd have the remote recording use-case thing done too. 

> According to RFC 3261 SIP is a peer 2 peer protocol and not a device->server protocol. Just making a point.

I'm not sure if you meant that in response to my remark or Randell's?  What I meant by saying "it's not really SIP" wasn't because I think SIP is not device<->device (on the contrary, it is)... but rather that if rtcweb uses SIP but then doesn't actually follow the rules of SIP, then it's *not* SIP.

-hadriel

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 20 Sep 2011 11:04:12 +0200

> I'm not sure if you meant that in response to my remark or Randell's?  What I meant by saying "it's not really SIP" wasn't because I think SIP is not device<->device (on the contrary, it is)... but…
Sorry, both comments was meant for Randell. But thank you for your response :-)

My opinion is that a limited version of SIP for rtcweb would not only be impossible to develop and keep in a limited scope, it would hurt the RTCweb process. And it's interesting to observe how many SIP oldtimers in this list that maintain that opinion...

It might be something worthwile to define in the process of trying to move SIP towards the Internet Standard goal, but that's a separate issue.

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 20 Sep 2011 11:14:47 +0200

2011/9/20 Ravindran Parthasarathi <[email-masked]>:
> I have answered to you in the another thread (http://www.ietf.org/mail-archive/web/rtcweb/current/msg01172.html).  I understand that there are lot of thread, So you might have confused.

Hi Ravindran. It seems that you avoid replying to the questions in my
previous mail (3 points you have never answered). Same arguments was
given in the thread you point above, again without responses. Why?

> SIP or XMPP based protocol will be selected as a default protocol based on technical merit of a given RTCWeb signaling problem but it is a second stage.

What does it mean "SIP or XMPP based protocol will be selected as a
default protocol [...]"? Anyone reading your mails would assume that
such a decision is already taken. Is it? who took it?

Regards.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 20 Sep 2011 11:23:49 +0200

> My opinion is that a limited version of SIP for rtcweb would not only be impossible to develop and keep in a limited scope, it would hurt the RTCweb process. And it's interesting to observe how man…

I'm strongly contrary to built SIP on browsers (by the same arguments
given in various threads).

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

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Tue, 20 Sep 2011 17:22:50 +0530

Hi Inaki,

Please read inline.

Thanks
Partha

>Sent: Tuesday, September 20, 2011 2:45 PM
>> I have answered to you in the another thread
>(http://www.ietf.org/mail-archive/web/rtcweb/current/msg01172.html).  I
>understand that there are lot of thread, So you might have confused.
>
<partha> The intention is not to avoid your questions. I have answered the questions which are relevant to "default" vs "nothing". For example, 

"2) If browsers speak pure SIP then the server side MUST also speak SIP. How to accomplish with that in shared web hostings? Must the web admins learn about SIP and installing/configuring a OpenSER/Kamailio/OpenSIPS/SER SIP proxy/registrar? This question has been made several times in some threads. No reply yet (same occurs with other given arguments)." 

It is the question on SIP deployment issue for web admin and it has no relevance to "default" vs "nothing" signaling protocol in RTCWeb client. 

Apart from this, couple of questions are circled in different threads and reply has to be propagated again because of the discontinuity in the thread but there is no conclusion. I'm afraid that it may dilute the discussion. It is the main motivation for me to write the text rather than handling in e-mail thread alias. </partha>

>> SIP or XMPP based protocol will be selected as a default protocol
>based on technical merit of a given RTCWeb signaling problem but it is a
>second stage.
>
>such a decision is already taken.

<partha>  I could not imagine how to you assume that default protocol decision is already taken based on the above statement </partha>

 Is it? who took it?

---

From: José Luis Millán <[email-masked]>
Date: Tue, 20 Sep 2011 14:34:39 +0200

Hello,

2011/9/20 Ravindran Parthasarathi <[email-masked]>

> Hi Inaki,
>
> I have answered to you in the another thread (
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg01172.html).  I

To be honest, I'm also confused. You opened two new threads to respond to
Saúl and Tim respectively from the original one.

>  As I indicated in the earlier mail, I'll come up with the write up to
> discuss the need for "RTCWeb default signaling protocol".

That`s OK. Let's read it and discuss about it then.

> Please note in the mail thread that there is no mention of SIP as a RTCWeb
> default signaling protocol. The argument is between "nothing" vs "default"
> signaling protocol.
>

Up to now, that 'default' you mean is not even a formal proposal.

Thanks

> SIP or XMPP based protocol will be selected as a default protocol based on
> technical merit of a given RTCWeb signaling problem but it is a second
> stage.
>
> Thanks
> Partha
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 20 Sep 2011 16:36:43 +0200

> can experiment with.... are there any out there that are "production ready"?

To my knowledge there is a DCCP stack in Linux. Exactly it status is
unknown to me and which of the CC it supports. There has been also
additional projects for implementations.

I would note that no implementation exist of DTLS with a CC algorithm
and additional mechanism. Thus that would be a from scratch
implementation effort without any input what has been done so far.

And if we can in fact decide early on something fully specified you have
a lot of time to implement this before the rest are standards ready.

> The pseudoTCP stacks in libjingle have seen service for a long time....

Well, that is addressing another set of requirements namely the reliable
data transport. Lets not confuse the two sets. We appear to have
interest in both unreliable and reliable data transport.

Regarding pseudoTCP we still need a specification for it. I think for
example the psuedo header used in the checksum needs specification in
TCP over UDP. It might not be a big spec, but someone needs to write it
and find a home for it. I would note that we are somewhat limited in
this WG to actually do protocol work.

cheers

Magnus Westerlund

---

From: Ted Hardie <[email-masked]>
Date: Tue, 20 Sep 2011 17:00:44 +0200

On Tue, Sep 20, 2011 at 12:46 AM, Matthew Kaufman <[email-masked]
> wrote:

>
> By that logic we should have a built-in shopping cart to make creating web
> storefronts easier, a built-in email client to make it easier to build the
> next Gmail, etc.
>
> Except that all the interesting things that have ever happened on the web
> are because clever people used the minimal built-in stuff to make something
> much more than the sum of its parts, not because the masses used the
> pre-built parts to replicate what already exists.
>
I may still be jet-lagged (okay, I am still jet-lagged), but the reductio ad
absurdum of that seems to be "I don't want my web browser to have a baked in
file transfer protocol, I want it to be a platform for building the next
great file transfer protocol experience".

Having a standard signaling method for setting up media session neither
prevents the creation of other signaling methods nor does it limit what
sessions are getting created.  It does facilitate doing the things we know
we want to do in the common case--which includes  making embeddable
interactive audio/video easy to code and deploy.

Again, just my two Rappen.

Ted

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 20 Sep 2011 08:13:33 -0700

> Nope, I'm not making any such assumption.  I was just pointing out that if the browser did full mixing, then we'd have the remote recording use-case thing done too.

The browser that does "full mixing" is then consider the simulator, so I 
would like to make sure that mix is done in real-time (capable of 
dispersement by solid surfaces rendered, like ray-cast for audio).

I think the question is if there needs to be an API for the mixer (in 
constraint to rtcweb), as I can see that may be harder to interact with 
simulators. Or, do we think of browsers that may have hal mixers (1st 
person spatial only) that don't provide any simulation.

-- 

---

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 20 Sep 2011 18:41:20 +0200

I agree with the points Hadriel makes. And I would add another point. SDP sometimes has several ways of doing the same thing, some official, some de facto. For example, cap-neg as the official way of negotiating a profile (say AVP versus SAVP) and well-practiced but simpler techniques for doing the same thing. By having JSON at the API, it is left to the application (JS or server) to decide which techniques to use when federating, according to the environment it finds itself in. I believe this is the right way to go. Please don't lock this into the browser and force cap-neg (say) on everyone.

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: 16 September 2011 19:29
> To: Harald Alvestrand
> Cc: <[email-masked]>
> Subject: [rtcweb] SDP offer/answer vs. JSON (was: About 
> defining a signaling protocol for WebRTC (or not))
> 
> 
> > The disadvantage of parsing to another structure (I am fond 
> of JSON myself) is that one has to maintain a data definition 
> for the format being parsed to, a defined transform between 
> that and the "canonical SDP structure" has to be implemented 
> in user space when one does SDP interoperability, both of 
> those have to be updated for every SDP extension that someone 
> defines somewhere, and one is still not free to define 
> extensions on the non-SDP side if one still requires the 
> > If one uses the "native" SDP format, which is the format in 
> which every extension to the format gets documented, the 
> browsers are the ones who *have* to parse it (although others 
> are likely to).
> 
> 
> Right so the above paragraphs get to the heart of the matter, 
> methinks.  Ultimately we need W3C to define an API, and the 
> API has to provide a means of learning RTP/media info from 
> the browser and commanding the browser to perform certain 
> things with RTP/media.  One could expose this API as a true 
> data structure, or as a long string of tokens to be 
> parsed/serialized back/forth.  If the latter, then the 
> choices are basically JSON or SDP.  And SDP seems 
> advantageous because it appears to be the least work for the 
> simple use-cases, because the javascript could just copy 
> back/forth the SDP between the browser and server.  In other 
> words you're optimizing for the very simple use-cases, in 
> exchange for making it more complicated for the advanced 
> use-cases.  Right?
> 
> OK, that's a laudable goal.  And I recognize that the 
> decision has basically already been made, and nothing's going 
> to change it. 
> 
> 1) Incorporating SDP and the offer/answer model into the 
> Browser and W3C API inexorably ties the W3C to the IETF 
> MMUSIC working group for all time.  So far, I had been going 
> on the assumption the IETF would be defining what the RTP 
> library had to do/expose, while W3C would define the API.  
> But if the API includes SDP offer/answer, that portion is the 
> IETF's domain too, afaik.  Anything the W3C wants to do in 
> the future for that has to go through the IETF, not just 
> IANA. (right?)
> 
> 2) This isn't just about JSON vs. SDP - it's about SDP 
> *offer/answer*.  SDP offer/answer wasn't meant to be an API 
> between an application and its RTP library - it's a 
> *protocol* between applications.  One side-effect of this is 
> it has historic state.  For example, if an SDP offer contains 
> two media lines, and one media is removed, the number of SDP 
> media lines don't reduce back to one - EVER.  So if 
> PeerConnection.removeStream() is invoked, the Browser needs 
> to remember there was that stream and signal it in SDP as 
> disabled for all time, until PeerConnection is closed.  If 
> addStream() is invoked later, it could/could-not re-use that 
> same (disabled) media line, or add a new one.
> 
> As another example, if a new SDP offer is sent out in SIP and 
> gets rejected with a 488, the session reverts to the 
> previously agreed SDP state.  The Browser would therefore 
> have to keep state of previous SDP and revert to it to handle 
> this case.  For example, if my Javascript started with only 
> an audio MediaStream in PeerConnection and later added a 
> video MediaStream to it, the new SDP offer would contain two 
> media lines - if the offer gets rejected with 488, how is 
> that communicated to the Browser and what will the browser do?
> 
> 3) You might well want information conveyed across that "API" 
> that is not meant to be sent on the wire in SDP - things you 
> don't want defined by IANA as SDP tokens.  For example, you 
> may want to provide packet counts, jitter, latency, and other 
> meta-information about individual RTP codecs.  Using JSON 
> allows you to have data member variables which will not get 
> serialized into SDP, but are purely for the javascript's use, 
> while still within the referential tree structure of the 
> media stream info.  Or they may be for sending to peers, but 
> simply not for SDP. (like you could send the jitter/latency 
> info through the signaling channel)
> 
> 4) Obviously if the application as a whole needs to do SDP 
> offer/answer, then *someone* will have to implement it 
> correctly, including the state-related stuff.  It could be 
> the browser or the javascript that do this.  Chrome may do a 
> perfect job of that in the browser, afaik.  But there are 
> other browser vendors, including niche ones such as Dolphin 
> and Skyfire.  What are the odds they all get it right the first time?
> 
> So which would you rather have updating an SDP engine, if one 
> is even needed... or updating "every SDP extension that 
> someone defines somewhere": the javascript which is written 
> by the developer that knows what they want when they want it, 
> and can update their code by updating their javascript (or 
> not if they don't need to); or the browsers which are written 
> by companies not under the javascript developer's control, at 
> a time of the browser companies' choosing? 
> 
> Obviously for some things the browser will have to be updated 
> regardless, for example to understand rather than just ignore 
> new JSON entries, to provide new codecs, etc.  But not all 
> new SDP attributes require changes in the media plane, nor 
> encoding into JSON.  In fact, a lot doesn't - some of it's 
> higher-application info, not really for the RTP library, and 
> more of it's coming in the future. 
> 
> -hadriel
>

---

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

In the simulated room, the board posted the note-well such that all 
participants, even unknown, had this much quickness in resolution rather 
than be stuck in cap-neg in more blind situations.

On the media plane, we may be able to make those "styx" notices, much 
like iNotify, yet these are one of those things that just works and 
still needs improvements, like this.

 From the top, the API needs the JSON-to-XPointer device driver for late 
binds; use-case: default emulation of scripted UI-only with saved-state.

Is there some default for display size? Shop owners may want some signal 
sent that switches modes on all display units from after-hours to 
real-time. With some notices, where it makes sense, you don't always 
want to-allow augmentation of posted note-well displays.

On 09/20/2011 09:41 AM, Elwell, John wrote:
>> Cc:<[email-masked]>

-- 

---

---

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

Login to the simulator may mean no login needed to other credentials; 
further, this is where some debate over ICE or...

http://www.ietf.org/about/note-well.html

...browser in the simulator.

Maybe we can SSRC the XPointer XML, and focus on that interop with OAuth 
MAC in single UDP over S/MIME or IPv6.

Again, where this makes sense: OAuth MAC plus S/MIME TOGETHER. I bet the 
browsers devs can guess the default.

On 09/20/2011 10:24 AM, Dzonatas Sol wrote:
> participants, even unknown, had this much quickness in resolution 
> rather than be stuck in cap-neg in more blind situations.
>
> From the top, the API needs the JSON-to-XPointer device driver for 
> late binds; use-case: default emulation of scripted UI-only with 
> saved-state.
>
> Is there some default for display size? Shop owners may want some 
> signal sent that switches modes on all display units from after-hours 
> to real-time. With some notices, where it makes sense, you don't 
> always want to-allow augmentation of posted note-well displays.
>
>> I agree with the points Hadriel makes. And I would add another point. 
>> SDP sometimes has several ways of doing the same thing, some 
>> official, some de facto. For example, cap-neg as the official way of 
>> negotiating a profile (say AVP versus SAVP) and well-practiced but 
>> simpler techniques for doing the same thing. By having JSON at the 
>> API, it is left to the application (JS or server) to decide which 
>> techniques to use when federating, according to the environment it 
>> finds itself in. I believe this is the right way to go. Please don't 
>> lock this into the browser and force cap-neg (say) on everyone.
>>
>> John
>>
>>
>>

-- 

---

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 20 Sep 2011 14:50:42 -0500

+1

> A full mesh is what *should* happen, but SIP/SDP can't do it, afaict.  It
> would treat them either as independent calls even at a media layer, or as a
> full-mixer conference focus model.  The closest thing we have would probably
> be the Join header, but I believe it's semantics is to join as a full mixer
> conf call.  Isn't this full-mesh media-forking thing actually a new semantic
> for SIP/SDP?  (it's hard to believe with 100+ drafts/RFCs this scenario hasn't
> already been addressed in SIP - I must be just having a memory leak)

Thanks, Henry

On 9/20/11 2:19 AM, "Hadriel Kaplan" <[email-masked]> wrote:

>>> OK, let's take the game example... only 2-player games would be able to use
>>> a simple rtcweb-SIP agent.  Anything more than 2-player would want to use
>>> the multi-party "conferencing" model of rtcweb, which can't even be signaled
>>> with SIP today as far as I can tell. (not that I've thought about it too
>>> much, but I can't see how it would without some changes to SIP)
>> 
> Can't do N-1 2-person calls to the person hosting the game, because rtcweb
> doesn't support "full" mixing in the browser, only local media mixing. (ie,
> everyone will hear the person hosting the game, and the person hosting the
> game will hear everyone else, but the rest won't hear each other)
> 
> Calls via a central media server require a central media server, which kinda
> defeats the "easy" concept and using our shiny new toy of rtcweb.
> 
> A full mesh is what *should* happen, but SIP/SDP can't do it, afaict.  It
> would treat them either as independent calls even at a media layer, or as a
> full-mixer conference focus model.  The closest thing we have would probably
> be the Join header, but I believe it's semantics is to join as a full mixer
> conf call.  Isn't this full-mesh media-forking thing actually a new semantic
> for SIP/SDP?  (it's hard to believe with 100+ drafts/RFCs this scenario hasn't
> already been addressed in SIP - I must be just having a memory leak)
> 
> -hadriel
>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 21 Sep 2011 11:07:48 +0200

> As Roman pointed out, RTC applications are not something that can nor should be done in 20 lines of JS. It's just complex. If people want to make simple apps they can build a simple JS library usin…
Let me just say that I totally disagree on this point.

The developers of applications that need audio and video capabilities 
are not RTC developers. Their main focus and main skill set will lie 
elsewhere.

In a little more than 20 lines of code, it is possible to set up a call 
using a variant form of the existing W3C API. I know, I have seen the 
code. Other examples (in a slightly different variant) are part of the 
Ericsson demo.
What's perhaps more important is that none of those 20+ lines mention 
anything about codecs, bit rates, congestion control or any of the 
numerous other issues we've been hashing out.

With the API we support, simple things MUST be simple. Complex things 
must be possible.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 21 Sep 2011 11:19:47 +0200

> additional projects for implementations.
I checked out the Linux stack, and concluded that it was:
a) not supporting DCCP over UDP
b) not possible to extract it and embed it in a browser
The only project I could find for userspace DCCP was untouched for at 
least 3 years, and did not compile.
> a lot of time to implement this before the rest are standards ready.
My worry is that without the ability to experiment, I have no way of 
verifying that the protocol satisfies the properties we are attributing 
to it.

Also, we *know* we'll be shipping products well ahead of the standards' 
final approval, with appropriate warnings that things *will* change 
between product versions. We don't have "a lot of time".
> interest in both unreliable and reliable data transport.
Yup, I pulled that in as an example of "code maturity".
> this WG to actually do protocol work.
It will have to seek approval elsewhere, if needed.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 21 Sep 2011 12:24:11 +0200

> Perhaps I'm confused, but doesn't MSRP rely on reliable, in-order delivery?

Right, MSRP is supossed to work over TCP or TLS. In fact, TLS usage is
a "SHOULD" and TCP is just supposed to be used for debugging purposes.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 21 Sep 2011 12:28:54 +0200

> a "SHOULD" and TCP is just supposed to be used for debugging purposes.

Using a reliable transport means that, in case both peers are behind
NAT, a MSRP Relay server (RFC 4976) is required. So as in the case of
a "RTCweb default signaling protocol" I wonder: would we expect a
'mod_msrp' module for Apache? :) (I don't).

Regards.

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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 21 Sep 2011 11:47:36 +0100

On 21 Sep 2011, at 10:19, Harald Alvestrand wrote:
>>>> We need to standardize a number of Transport protocol functionalities for the RTCWEB data transport solution. To the degree that I do like to resurface some of my earlier suggestions around this. Why not use DCCP with TFRC or TCP like congestion control tunneled over UDP.
>>>> 
>>>> The whole specification is ready. Which avoids any hiccup with the transport people and IESG.
>>> 
>>> The last few times this has surfaced, the conversation has turned suddenly silent when I've asked where to find a DCCP-over-TFRC stack I can experiment with.... are there any out there that are "production ready"?
>> 
>> To my knowledge there is a DCCP stack in Linux. Exactly it status is unknown to me and which of the CC it supports. There has been also additional projects for implementations.
> 
> The only project I could find for userspace DCCP was untouched for at least 3 years, and did not compile.

Agreed. The Linux DCCP code seems reasonably mature, but doesn't support the UDP encapsulation. The user-space DCCP-TP code is not in a good state to build upon.

>> I would note that no implementation exist of DTLS with a CC algorithm and additional mechanism. Thus that would be a from scratch implementation effort without any input what has been done so far.
>> 
>> And if we can in fact decide early on something fully specified you have a lot of time to implement this before the rest are standards ready.
> 
> My worry is that without the ability to experiment, I have no way of verifying that the protocol satisfies the properties we are attributing to it.

This is a little pessimistic. The Linux DCCP code can certainly be used for lab-based experiments, and these can be made to give a reasonable idea of the performance of DCCP with the existing CCIDs. Not perfect, sure, but should be good enough to show whether the basic idea is worth exploring further. 

The main reason to consider DCCP-over-UDP isn't running code though, it's the solid specification. I'd argue that it will be easier to start with the DCCP spec, profile it down to what's needed by this group, plug in a new congestion control algorithm (CCID), and implement the result, than it would be to start both the specification and implementation efforts from scratch. As a congestion-controlled, connection-oriented, unreliable datagram service, there's not a lot in DCCP that we wouldn't want for RTCWeb (and those bits we might want to modify, such as the congestion control algorithm, are things where DCCP supports extensions).

> Also, we *know* we'll be shipping products well ahead of the standards' final approval, with appropriate warnings that things *will* change between product versions. We don't have "a lot of time".
>> Well, that is addressing another set of requirements namely the reliable data transport. Lets not confuse the two sets. We appear to have interest in both unreliable and reliable data transport.
> 
>> Regarding pseudoTCP we still need a specification for it. I think for example the psuedo header used in the checksum needs specification in TCP over UDP. It might not be a big spec, but someone needs to write it and find a home for it. I would note that we are somewhat limited in this WG to actually do protocol work.
> 
>> --------------------------------------------------------------------
>> --------------------------------------------------------------------
>> --------------------------------------------------------------------
> 

-- 
Colin Perkins
http://csperkins.org/

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 21 Sep 2011 11:24:46 +0000

On Sep 21, 2011, at 5:07 AM, Harald Alvestrand wrote:

> The developers of applications that need audio and video capabilities are not RTC developers. Their main focus and main skill set will lie elsewhere.

I agree.  That's why JS libraries exist, though, isn't it?

> In a little more than 20 lines of code, it is possible to set up a call using a variant form of the existing W3C API. I know, I have seen the code. Other examples (in a slightly different variant) are part of the Ericsson demo.

Well, to be fair, the Ericsson code has this at the top of the main HTML page's script:
<script type="text/javascript" src="signaling.js"></script>

And that separate JS is another ~100 lines of code.  
And that "signaling" code doesn't appear to actually handle the rendezvous function of signaling - you have to email the other party a cookified URL to reach you at for the particular session. (I think)
And it doesn't appear to handle terminating a session (other than by closing the browser window).

But then, it's just a demo.
[note: I'm not disparaging the demo - it's a cool demo]

> What's perhaps more important is that none of those 20+ lines mention anything about codecs, bit rates, congestion control or any of the numerous other issues we've been hashing out.

Right, nor should they - the browsers should do that stuff internally, and only if the JS actually wants/needs to get involved somehow should it need to (through callbacks/whatever).
No one's been saying the JS needs to be responsible for codecs, bit rates, congestion control, or anything much media related.

We've only been arguing about:
1) Using SDP and the SDP offer/answer as the media API
2) Whether there should be a "default" signaling component built in as well, or let JS libraries handle it

> With the API we support, simple things MUST be simple. Complex things must be possible.

Yes, it should be "as simple as it can be, but no simpler".  The tricky part's always figuring out what that means. :)

Why isn't this simple enough:
<script src="http://ajax.googleapis.com/ajax/libs/sigpipe/1.0/sigpipe.min.js"></script>

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 21 Sep 2011 11:45:13 +0000

Just to make sure I'm on the same wavelength, you're talking about:
1) Defining PseudoTCP over UDP (a la libnice and jingle) for stream-oriented reliable data delivery.
2) Defining DDCP over UDP for message-oriented unreliable data delivery.
3) Requiring the browser to implement and only expose those two options for the "data" stream type and not raw UDP, so that we can enforce congestion control of the data channel. (oh, and the option for it to be PseudoTCP/DTLS/UDP or DCCP/DTLS/UDP)

Correct?

-hadriel

---

From: Colin Perkins <[email-masked]>
Date: Wed, 21 Sep 2011 13:09:49 +0100

Yes, essentially (plus RTP over UDP for the media, of course).

Colin

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 21 Sep 2011 12:12:20 +0000

OK, makes sense.

-hadriel

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 21 Sep 2011 14:13:10 +0200

> 'mod_msrp' module for Apache? :) (I don't).

Nothing says the relay has to be in the web server. 

As a side note: the first SIP proxy I tested was in fact an Apache module.

/O

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 21 Sep 2011 15:48:32 +0200

Hi,

> 3) Requiring the browser to implement and only expose those two options for the "data" stream type and not raw UDP, so that we can enforce congestion control of the data channel. (oh, and the optio…

I'm not familiar with DDCP, but MSRP requires a reliable transport AFAIK, so would DDCP be appropriate for that purpose, for example? I guess that Pseudo TCP would.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 21 Sep 2011 15:52:16 +0200

> Nothing says the relay has to be in the web server.

I expect that WebRTC is an added value for webs, and 99% of webs in
the world are hosted in a shared datacenter.

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

---

From: Randell Jesup <[email-masked]>
Date: Thu, 22 Sep 2011 03:53:25 -0400

> 1) Defining PseudoTCP over UDP (a la libnice and jingle) for stream-oriented reliable data delivery.

I would also consider SCTP-over-UDP in place of PseudoTCP-over-UDP for reliable
data delivery.  Similar arguments apply as for DCCP (solid specification), and
in addition the FreeBSD implementation apparently supports SCTP-over-UDP and is
very portable, so good working code is available to start.  SCTP also has other
benefits, like optional out-of-order delivery, and a datagram ('message') orientation.

> 3) Requiring the browser to implement and only expose those two options for the "data" stream type and not raw UDP, so that we can enforce congestion control of the data channel. (oh, and the optio…

This is certainly an option.  I'll note it means we'll run congestion control
on the data channels separately from media and from other data channels - this
is similar to how opening multiple TCP connections works.  I was hoping I could
find a way to include all the data channels in a single congestion-control framework
with the media channels, which would allow the application optional control over the
allocation of bits between media and data.  (I.e. a long-running file transfer could
starve the media channels eventually in bufferbloat situations.)

For DCCP (since it allows replacing the congestion-control algorithm) we may still
be able to meet my hopes for unreliable data; but reliable data is still a bit
out in the cold.

    Randell

-- 
Randell Jesup
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Thu, 22 Sep 2011 11:27:44 -0400

> benefits, like optional out-of-order delivery, and a datagram 

I'm in touch with the SCTP-over-UDP draft authors, and received this:

    so you want a reliable and unreliable datagram service. You can use SCTP for both:
    1. Standard SCTP/UDP for a reliable datagram service.
    2. SCTP/UDP with the PR-SCTP extension and using a policy which doesn't do
        retransmissions. This is also implemented in the FreeBSD implementation
        and the derived ones, like the one for Mac OS X, Userspace and so on.

    There is also an RFC for running DTLS/SCTP which also applies to DTLS/SCTP/UDP
    to secure the traffic. We also have running code for it as you can get a
    patch for OpenSSL from
    http://sctp.fh-muenster.de/dtls-patches.html
    It has been submitted to the OpenSSL maintainers for inclusion in OpenSSL 1.0.1.

    Please let us know if you have any further question.

So, overall this seems *very* promising - both in terms of a single framework to use
for all the data channels (one interface/API, etc), existing congestion control
(unfortunately TCP-like -- loss-based -- but oh well), and a working, open
-over-UDP/-over-DTLS spec and implementation.

I'd still love to tie the congestion control into the unified control we're looking
at for the media streams, but I think we can make this work well even without that.

-- 
Randell Jesup
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Thu, 22 Sep 2011 12:45:41 -0400

> -over-UDP/-over-DTLS spec and implementation.

They also inform me that there are alternative CC implementations in the 
BSD code, and the CC code it replaceable/overridable, so even better.

-- 
Randell Jesup
[email-masked]

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Thu, 22 Sep 2011 23:52:49 +0530

Hadriel,

Please read inline.

Thanks
Partha

>From: Hadriel Kaplan [mailto:[email-masked]]
>Sent: Tuesday, September 20, 2011 11:29 AM
>Cc: Roman Shpount; Randell Jesup; <[email-masked]>
>Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE:
>Aboutdefining a signaling protocol for WebRTC (or not)]
>
>
>> I agree with you in case you wish to have all class 5 services in
this
>architecture. In the web game server wherein the basic call has to be
>established between two parties, this complexity is not required.
>
>OK, let's take the game example... only 2-player games would be able to
>use a simple rtcweb-SIP agent.  Anything more than 2-player would want
>to use the multi-party "conferencing" model of rtcweb, which can't even
>be signaled with SIP today as far as I can tell. (not that I've thought
>about it too much, but I can't see how it would without some changes to
>SIP)
> 
<partha> In fact rtcweb client shall acts as conference un-aware client
in the conference model and game server acts as conference server. I
have worked in 3-party conference using SIP in the endpoint but I have
never seen endpoint acts as conference server. So, I may be missing
something here </partha>

>
>
>> One of the main aim of the RTCWeb default signaling protocol is to
>make two party real-time communication easy with less development
effort
>for any web developer.
>
>Why doesn't using JS libraries provide that ease of development,
>assuming there's a good "signaling agent" JS library for whatever
>communication model the deployer wants/needs?  If there isn't a good JS
>library, then one would wonder why we think all browsers will have a
>good built-in signaling agent instead.
>
<partha>The disadvantage with JS is that each server has to provide its
own instance of JS library. It may be possible to have plugin instead of
JS but it will defeat the purpose of RTCWeb charter. </partha>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 22 Sep 2011 15:07:12 -0400

Partha,

I would consider the fact that each server has its own JS library a huge
advantage -- each server needs to interop with its own library. If we want
to add extensions, we can add them in the server and JS, and not worry about
creating a new standard and going through an interop.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 22 Sep 2011 21:16:27 +0200

2011/9/22 Ravindran Parthasarathi <[email-masked]>:
> The disadvantage with JS is that each server has to provide its
> own instance of JS library.

And that's the magic of the WWW world: the fact that each provider is
free to provide exactly what it needs. That leads to the success of
the WWW and allows fast innovation.

> It may be possible to have plugin instead of
> JS but it will defeat the purpose of RTCWeb charter.

A plugin like Flash, Java or ActiveX? sure we want that?

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

---

From: Randell Jesup <[email-masked]>
Date: Thu, 22 Sep 2011 16:04:12 -0400

On 9/22/2011 2:22 PM, Ravindran Parthasarathi wrote:

> something here</partha>

I've built videophones that do in-phone 3 or 4 way conferencing (bridging
and mixing the audio and video).  It can also be done without mixing by
forwarding.  I'm unclear on if that would be possible in webrtc; is there
any way to loop around or mix audio/video from one PeerConnection to another.
(You can always turn off AEC and loop the audio... ;-)

-- 
Randell Jesup
[email-masked]

---

From: Jozsef Vass <[email-masked]>
Date: Thu, 22 Sep 2011 17:58:41 -0700

I am in support of having some basic mechanism in the browser as part of rtcweb to enable developers to quickly and easily setup media between participants. Furthermore, if an API is too complex or too hard to use, people will not use it or misuse it. I can only see a handful of companies developing advanced calling feature on top of rtcweb, most people just want to have something simple to work without caring too much about the details.

Maybe it would be advantages to specify such a very basic use case, e.g., targeting gaming. It must work behind NATs using peer-to-peer media transport (but fallback to media relay may not be required). Since it is targeting closed community, there is no need for interoperability, there is no need for SIP, Jingle, etc. At the minimum, this would require a simple service for ip address lookup and to aid NAT and firewall traversal.

For example, when a user registers with this service, he/she is assigned an identifier or blob. In order to communicate with another party, all they need to do is to exchange this information (this can be done using websocket, etc.) and setup media channel. There should be no need for parsing SDP, etc.

Jozsef

---

From: Roman Shpount <[email-masked]>
Date: Thu, 22 Sep 2011 21:19:04 -0400

With the API we are discussing (ie have methods to generate an offer,
process an answer or answer update to the last generated offer, process the
last offer refusal, process an offer and generate an answer to it) it is
very simple to build a simple point to point RTC call:

First client uses the API to generate an offer.

First client sends this offer (at this point it does not matter if offer is
JSON or SDP encoded, as long as client can get this description and encode
it into something that can be send over http), using http post to a web
server.

Web server stores this offer into some type of storage (local file, in
memory db)

Second client pulls the web server using some sort of timer for an offer
using http GET.

As soon as offer is created and stored, web server reads the offer from the
storage and sends it to the second client.

Second client uses API to process the offer and generate an answer.

Second client sends the answer to the web server using http post.

Web server stores answer in the storage.

After sending the offer first client is pulling web server for the offer
using some sort of timer http get.

As soon as answer is created and stored, web server reads the answer from
the storage and sends it to the first client.

First client gets an answer from the web server, passes it to the API as an
answer to the last offer.

Connection is setup!. No SIP is used. Application like this can be developed
by a fifth grader as a homework project and installed on any shared hosting
provider. If you have websockets or some other javascript eventing library
you can make this a lot more interactive.

If you do SIP on the other hand, you will end up with a the same or more
work as a developer, will have to install a lot more software on the web
server, will have to learn a whole bunch about new signaling protocols until
you figure out why things do not work.
_____________
Roman Shpount

On Thu, Sep 22, 2011 at 8:58 PM, Jozsef Vass <[email-masked]> wrote:

> I am in support of having some basic mechanism in the browser as part of
> rtcweb to enable developers to quickly and easily setup media between
> participants. Furthermore, if an API is too complex or too hard to use,
> people will not use it or misuse it. I can only see a handful of companies
> developing advanced calling feature on top of rtcweb, most people just want
> to have something simple to work without caring too much about the details.
>
> Maybe it would be advantages to specify such a very basic use case, e.g.,
> targeting gaming. It must work behind NATs using peer-to-peer media
> transport (but fallback to media relay may not be required). Since it is
> targeting closed community, there is no need for interoperability, there is
> no need for SIP, Jingle, etc. At the minimum, this would require a simple
> service for ip address lookup and to aid NAT and firewall traversal.
>
> For example, when a user registers with this service, he/she is assigned an
> identifier or blob. In order to communicate with another party, all they
> need to do is to exchange this information (this can be done using
> websocket, etc.) and setup media channel. There should be no need for
> parsing SDP, etc.
>
> Jozsef
>
> Subject: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was
> RE: About defining a signaling protocol for WebRTC (or not)])
>
> >> What I fail to understand is in what way would adding signaling to the
> web browser would  make things easy to build? How is what you are proposing
> >> On the other hand, if you decide to build such simple signaling
> interface, depending on what use case you are trying to address you will end
> up with very different libraries. You have to decide how complex you want to
> make this library on the server vs the client side. You will need to decide
> if the purpose of this library is to simplify browser-to-browser or
> > If we add some signaling protocol to the browser to ease web developers
> then someone might say "why don't we also add X, Y and Z". The browser only
> needs the media plane, the signaling can be elsewhere, and it's far better
> to have it elsewhere.
> >
> > As Roman pointed out, RTC applications are not something that can nor
> should be done in 20 lines of JS. It's just complex. If people want to make
> simple apps they can build a simple JS library using an invented simple
> protocol. But RTCWeb shouldn't encourage this IMHO.
> The developers of applications that need audio and video capabilities are
> not RTC developers. Their main focus and main skill set will lie elsewhere.
>
> using a variant form of the existing W3C API. I know, I have seen the code.
> Other examples (in a slightly different variant) are part of the Ericsson
> demo.
> anything about codecs, bit rates, congestion control or any of the numerous
> other issues we've been hashing out.
>

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Mon, 26 Sep 2011 09:10:51 +0200

> Maybe it would be advantages to specify such a very basic use case, e.g., targeting gaming. It must work behind NATs using peer-to-peer media transport (but fallback to media relay may not be requi…

This is a no go. What "closed community" are you talking about? Interoperability is a MUST here, even if I'm in favor of not having any default signaling protocol specified. We need to be able to communicate with other protocols without building gateways. This can be achieved with both SIP and XMPP, so I see no need for reinventing the wheel. Lets let developers use whatever protocol they like and just use RTCweb for the media part.

> For example, when a user registers with this service, he/she is assigned an identifier or blob. In order to communicate with another party, all they need to do is to exchange this information (this…

What service? Who would host a server?

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 26 Sep 2011 09:55:21 +0200

2011/9/23 Jozsef Vass <[email-masked]>:
> there is no need for interoperability, there is no need for SIP, Jingle, etc. At the minimum, this would require a simple service for ip address lookup and to aid NAT and firewall traversal.

...and when you need more features (like adding video within an
existing audio session, or putting the session on hold, or negotiating
codecs and encryption parameters) you will realize that you are
reinventing SDP.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 26 Sep 2011 10:08:58 +0200

> answer to the last offer.

I strongly agree.

Just take into account that the second client could reject the call
("I'm bussy"), so there would not be SDP answer. Of course carrying
that information (the call rejection) is responsability of the
signaling protocol (which also carries the SDP bodies, as it occurs in
SIP and XMPP/Jingle).

> Connection is setup!. No SIP is used.

But it could be (I mean encapsulating SIP over HTTP or WebSocket)  :)
So freedom for all.

> Application like this can be developed
> provider.

And the audio/video sessions go through the web server so the web
application logic can decide wheter to terminate an existing
audio/video session (in case an user has been banned from a room-chat,
for example).

> If you have websockets or some other javascript eventing library

WebSocket is for sure the way to go.

> server,

Yes. In case the browser must speak native SIP or XMPP that will be
the end of this history (because a SIP proxy/registrar or XMPP server
would be required for ***each*** website).

> will have to learn a whole bunch about new signaling protocols until

The only server side requirement would be providing a STUN/TURN server
(and TURN authentication accounts).

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

---

From: Jozsef Vass <[email-masked]>
Date: Mon, 26 Sep 2011 10:17:07 -0700

Look at it from a game developer's perspective. I do not want to build a softphone phone with advanced features, just to add voice chat to the game. Online registered players should be able to chat with each other, but really no need to interoperate with anything else (and preferred not to).  Quite often, it is a group of people who are playing together, so multiparty chat is highly desirable.  As I game developer, I do not event know what is SIP, Jingle or SDP and probably do not even care about it.

If you want to communicate behind NATs, firewalls, you need to run a service to determine the reflexive address (in addition to your web server) at least.

Jozsef

-----Original Message-----
From: Saúl Ibarra Corretgé [mailto:[email-masked]] 
Sent: Monday, September 26, 2011 12:11 AM
To: Jozsef Vass
Cc: Harald Alvestrand; [email-masked]
Subject: Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)])

--
Saúl Ibarra Corretgé
AG Projects

---

From: Jozsef Vass <[email-masked]>
Date: Mon, 26 Sep 2011 10:19:17 -0700

All these advanced features will probably be used by a handful of companies/developers. I would rather see something simple, xml based that is more compatible with the web than SDP. 

Jozsef

-----Original Message-----
From: Iñaki Baz Castillo [mailto:[email-masked]] 
Sent: Monday, September 26, 2011 12:55 AM
To: Jozsef Vass
Cc: Harald Alvestrand; [email-masked]
Subject: Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)])

> For example, when a user registers with this service, he/she is assigned an identifier or blob. In order to communicate with another party, all they need to do is to exchange this information (this…

...and when you need more features (like adding video within an existing audio session, or putting the session on hold, or negotiating codecs and encryption parameters) you will realize that you are reinventing SDP.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 26 Sep 2011 19:50:47 +0200

> Look at it from a game developer's perspective. I do not want to build a softphone phone with advanced features, just to add voice chat to the game. Online registered players should be able to chat…

Indeed there should be a simple mechanism for allowing web developers
to run audio/video sessions in their web applications, but that should
not avoid or make impossible for others to run a SIP or XMPP/Jingle
client within a web.

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

---

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

Hi Jozsef,

I agree with you that game developer has no need to know the intricacies of signaling protocol and also, how the underlying framework makes it work for traverse through NAT. But the discussion here is which JS API will make it happen and what are the protocol intricacies involved to make it happen?

As you wish based on lower level JS API, it is possible to give only one API like peerconnnect([username]) to start the session and how they connect which is not RTCWeb developer headache but underlying framework will take care of the stuff. 

What level of interop is required for the online registered players? All RTCWEb browser (Mozilla, chrome, IE) player should be able interop without need of browser specific JS or plugin. Here, there is a need of defining the common underlying protocol (which is not RTCWeb developer concern).

Thanks
Partha  

>Of Jozsef Vass
>Sent: Monday, September 26, 2011 10:47 PM
>To: Saúl Ibarra Corretgé
>Cc: [email-masked]
>Subject: Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol
>[was RE: About defining a signaling protocol for WebRTC (or not)])
>
>Look at it from a game developer's perspective. I do not want to build a
>softphone phone with advanced features, just to add voice chat to the
>game. Online registered players should be able to chat with each other,
>but really no need to interoperate with anything else (and preferred not
>to).  Quite often, it is a group of people who are playing together, so
>multiparty chat is highly desirable.  As I game developer, I do not
>event know what is SIP, Jingle or SDP and probably do not even care
>about it.
>
>If you want to communicate behind NATs, firewalls, you need to run a
>service to determine the reflexive address (in addition to your web
>server) at least.
>
>Jozsef
>
>Subject: Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol
>[was RE: About defining a signaling protocol for WebRTC (or not)])
>
>
>> I am in support of having some basic mechanism in the browser as part
>of rtcweb to enable developers to quickly and easily setup media between
>people will not use it or misuse it. I can only see a handful of
>companies developing advanced calling feature on top of rtcweb, most
>people just want to have something simple to work without caring too
>much about the details.
>>
>> Maybe it would be advantages to specify such a very basic use case,
>e.g., targeting gaming. It must work behind NATs using peer-to-peer
>media transport (but fallback to media relay may not be required). Since
>it is targeting closed community, there is no need for interoperability,
>there is no need for SIP, Jingle, etc. At the minimum, this would
>require a simple service for ip address lookup and to aid NAT and
>firewall traversal.
>>
>
>This is a no go. What "closed community" are you talking about?
>Interoperability is a MUST here, even if I'm in favor of not having any
>default signaling protocol specified. We need to be able to communicate
>with other protocols without building gateways. This can be achieved
>with both SIP and XMPP, so I see no need for reinventing the wheel. Lets
>let developers use whatever protocol they like and just use RTCweb for
>the media part.
>
>> For example, when a user registers with this service, he/she is
>assigned an identifier or blob. In order to communicate with another
>party, all they need to do is to exchange this information (this can be
>done using websocket, etc.) and setup media channel. There should be no
>need for parsing SDP, etc.
>>
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 26 Sep 2011 20:44:58 +0200

2011/9/26 Ravindran Parthasarathi <[email-masked]>:
> What level of interop is required for the online registered players? All RTCWEb browser (Mozilla, chrome, IE) player should be able interop without need of browser specific JS or plugin.

Ravindran, you insist of that even when multiple comments tell you the
opposite. If Mozilla, Chrome or IE browsers are visiting the *same*
website then they *already* share the *same* JavaScript (loaded from
the website) so they can signal the media thought the web server (by
using HTTP or WebSocket) as defined in the retrieved JavaScript code.
This is easy to understand IMHO and this is how WWW works for years =>
interoperability between clients visiting the same website. Period.

If the browsers speak *native* SIP (as you suggest in many threads)
then the web server is unaware of what is happening at media level
between the visitors (because the web server, where the application
logic is, does not see the signaling traffic).

> Here, there is a need of defining the common underlying protocol (which is not RTCWeb developer concern).

No, it's not. You can repeat 1000 times by ignoring any rationale
already replied to you in multiple threads. But that changes nothing.
WebRTC does not need native SIP or native XMPP/Jingle spoken by web
browsers. In fact, that would stop innovation, would mandate website
admins to provide a SIP/XMPP server within their infrastructure (how!)
and would make WebRTC unfeasible in shared web hostings.

The only point of discussion here is the requirements for the custom
JavaScript code retrieved from the web server in order to interoperate
with the WebRTC stack in the browser, and the JS API defining the
methods to read and generate media descriptions (like-SDP) that would
be sent to the other peer via the signaling path (HTTP/WebSocket).

Regards.

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

---

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

Hi Inaki,

Your vision of Javascript signaling protocol is exactly opposite to Jozsef proposal of having XML mechanism. Please try to understand that everybody is not excited to develop their own signaling protocol even though you consider it as a freedom world. I have insisted multiple time that I'm asking for one RTCWeb signaling protocol across browser vendor but it is not required to be SIP. The aim of having standard RTCWeb signaling protocol is to make basic dialog between two different browsers (For ex: Mozilla & chrome) user. 

Having seeing the list discussion on signaling intricacies in this alias, it is no point in asking each web developer to create their own signaling protocol. It is better for IETF to recommend one protocol which best suit RTCWeb signaling requirement and best simple API for signaling protocol will be defined by W3C.

Please read inline.

Thanks
Partha

>Sent: Tuesday, September 27, 2011 12:15 AM
>Cc: Jozsef Vass; Saúl Ibarra Corretgé; [email-masked]
>> What level of interop is required for the online registered players?
>All RTCWEb browser (Mozilla, chrome, IE) player should be able interop
>without need of browser specific JS or plugin.
>
<partha> WWW works with plugin. If you think otherwise, there is no much
Work for IETF in this WG </partha>

>If the browsers speak *native* SIP (as you suggest in many threads)
<partha> I asked initially because it is defacto recommended IETF 
real-time protocol </partha>

>logic is, does not see the signaling traffic).
<partha> IMO, it is your bad assumption. There are "n" number of way to
Design server even if they speak different protocol which is a common 
Practice in gateway implementation </partha>

>No, it's not.
<partha> There is a strong need to define signaling protocol which helps
Browsers to interop and also reduce the complexity for web developers </partha>

 You can repeat 1000 times by ignoring any rationale
>browsers. In fact, that would stop innovation, would mandate website

<partha> I have clarified multiple time that your innovation is not going 
to stop by defining standard signaling protocol. Let say X protocol become
standard signaling protocol which does not mean that you should not 
implement your SIP over websocket using Javascript. So, this is false 
propaganda by few folks that it would stop innovation. </partha>

>and would make WebRTC unfeasible in shared web hostings.
<partha> In case you talking about manageability of the servers, lot of more
Stuff involved than simple protocol decision </partha>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 26 Sep 2011 21:32:49 +0200

Hi Ravindran, comments inline:

2011/9/26 Ravindran Parthasarathi <[email-masked]>:
> The aim of having standard RTCWeb signaling protocol is to make basic dialog between two different browsers (For ex: Mozilla & chrome) user.

And me and others already said that the aim of WebRTC is not
converting web browsers into generic SIP phones capable of
establishing a call between them without visiting the same page
(replace "SIP" with whichever protocol).

WebRTC adds value to the WWW world, so it's assumed that first of all,
browsers visit some website, so they can get something (JavaScript
code).

> Having seeing the list discussion on signaling intricacies in this alias, it is no point in asking each web developer to create their own signaling protocol. It is better for IETF to recommend one…

Ok, but such protocol should be carried within HTTP or WebSocket,
rather than being a native SIP/XMPP/whatever-custom-protocol built-in
the web browsers. Do we agree on this? I think the answer is "not", so
please continue reading.

> Work for IETF in this WG </partha>

AFAIK one of the aims of WebRTC is allowing multimedia sessions within
browsers *without* the need of external plugins (like Flash or Java
applets).

> real-time protocol </partha>

I'm sure that fans of XMPP would not like that (even less taking into
account that XMPP is much more deployed in pure Internet than SIP).

> Practice in gateway implementation </partha>

So you want a "built-in protocol" not to bore web developers with
custom and complex signaling protocols, but at the same time you want
to force them to build a hyper-complex gateway in server side. ¿?¿?

> Browsers to interop and also reduce the complexity for web developers </partha>

Again: browsers MUST not *directly* interop with other browsers in the
*signaling* plane. If two browsers visit the same page and download
the *same* JavaScript, such JS already can say the browsers how to
signal the media.

Please, don't insist on the same again and again. There is NO need at
all for web browsers to natively and directly speak
SIP/XMPP/other-protocol between them. In fact, that is undesirable.

> propaganda by few folks that it would stop innovation. </partha>

Ok. But in other mails you propose that WebRTC should be an island for
web browsers. Wouldn't that stop innovation?

> Stuff involved than simple protocol decision </partha>

No. What I meant is very clear: if the signaling (or the "default
signaling" as you propose) is not carried via HTTP or WebSocket, then
it would require another kind of centralized server (as a SIP proxy in
the provider side). So all those websites hosted in shared hosting
datacenters (i.e. using a shared Apache with different virtual
domains) would have no chance to use WebRTC. Just it.

Regards.

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

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Tue, 27 Sep 2011 01:22:30 +0530

Hi Inaki,

<snip> 
Ok, but such protocol should be carried within HTTP or WebSocket, rather than being a native SIP/XMPP/whatever-custom-protocol built-in the web browsers. Do we agree on this? I think the answer is "not", so please continue reading. </snip>

Your assumption is wrong here. When I ask for standard signaling protocol, websocket will be one of the alternative to considered for further discussion in case there is an agreement for having standard signaling protocol.

Thanks
Partha

>Sent: Tuesday, September 27, 2011 1:03 AM
>> The aim of having standard RTCWeb signaling protocol is to make basic
>dialog between two different browsers (For ex: Mozilla & chrome) user.
>
>> Having seeing the list discussion on signaling intricacies in this
>alias, it is no point in asking each web developer to create their own
>signaling protocol. It is better for IETF to recommend one protocol
>which best suit RTCWeb signaling requirement and best simple API for
>signaling protocol will be defined by W3C.
>

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Tue, 27 Sep 2011 09:26:31 +0200

Hi,

> Your assumption is wrong here. When I ask for standard signaling protocol, websocket will be one of the alternative to considered for further discussion in case there is an agreement for having sta…

I'd consider WebSocket the transport, not the signaling protocol per se. After reading your last emails I'm not exactly sure about what you are proposing. Let me state a starting point: two browsers can't communicate with each other without meeting somewhere, like a server for example. Both are behind NAT and there is no discovery mechanism, so the only way for them to communicate is to visit a website, for example.

Now, if two users (browsers) are already in the same website, they'd have downloaded the same JS libraries from the web server, as Inaki pointed out, so they may speak SIP, XMPP or whatever signaling protocol.

What I think you are suggesting is that RTCweb-enabled browsers include some sort of signaling library built-in, is this correct? Even if they do that you'll need server cooperation to reach each other, and even in the multiplayer game example, you are always connected to a server.

Thus, I strongly disagree to trying to include any signaling protocol as part of RTCweb. Developers may choose a JS library to do that, or even develop their own, and deploy it in the web servers that power their site.

Regards,

--
Saúl Ibarra Corretgé
AG Projects