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

[Roman Shpount <[e-mail]>]

+1
_____________
Roman Shpount


On Wed, Sep 14, 2011 at 4:08 PM, Bernard Aboba <[e-mail]>wrote:

> +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
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>