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

[Bernard Aboba <[e-mail]>]

+1



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

> +1
> 
> Thanks, Henry
> 
> 
> On 9/14/11 9:56 AM, "Iñaki Baz Castillo" <[e-mail]> wrote:
> 
>> 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
> <[e-mail]>
> _______________________________________________
> rtcwe
>> b mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb