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

[Prakash <[e-mail]>]

+1

On Wed, Sep 14, 2011 at 1:59 PM, Victor Pascual
<[e-mail]> wrote:
> +1
> On Sep 14, 2011, at 10:22 PM, Roman Shpount <[e-mail]> wrote:
>
> +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
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>