[RTW] Does RTC-WEB need to pick a signaling protocol?

[Bernard Aboba]

With respect to b) one challenge is obtaining the IP addresses necessary to
create the SDP offer.   (see http://javascript.about.com/library/blip.htm).

On Tue, Feb 1, 2011 at 10:47 PM, Justin Uberti <juberti at google.com> wrote:

> Great example.
>
> And just like Gmail uses an SMTP gateway to connect its own HTTP-based
> protocol to the rest of the world, Gmail voice and video uses a XMPP gateway
> to connect its HTTP-based signaling to other XMPP clients. Others in this
> space have done similar things by implementing XMPP clients in Javascript.
>
> So I think we have existence proofs that this approach, in addition to
> being extremely flexible, is entirely workable today.
>
> The two things that we need to specify are
> a) the semantics of the signaling (i.e. the offer-answer mechanism that
> both SIP and XMPP are patterned around)
> b) the mechanism through which session offers and answers will be described
> (e.g. some SDP-ish thing that is suitable for the web).
>
> a) seems rather straightforward. b) will likely be trickier - we need
> something that can be mapped to SDP, for SIP gateways, but we probably want
> it to be represented as JSON for benefit of web developers. So the challenge
> becomes, what format can we define that can be unambiguously mapped to/from
> SDP, but doesn't bring with it all of the baggage of SDP?
>
> --justin
>
> On Mon, Jan 31, 2011 at 8:12 AM, Matthew Kaufman <
> matthew.kaufman at skype.net> wrote:
>
>> On 1/29/2011 6:35 AM, Jonathan Rosenberg wrote:
>>
>>>
>>> That said, even if one asks the question of whether it is a good idea for
>>> us to pick something, I think the answer is no. The enormous benefit of the
>>> web model is its ability for innovation and velocity. Standardization is not
>>> needed for communications within the domain of the provider; new features
>>> can be developed and deployed as quickly as they can be conceived.
>>>
>>
>> Agreed. Consider the case of Gmail (or any other web-based email)
>>
>> Did every web browser on the planet need to be upgraded to speak IMAP or
>> SMTP in order for Gmail to be implemented? No.
>>
>> Does the JavaScript that Gmail sends down to your browser in order to
>> implement its UI need to be standardized among web email platforms? No.
>>
>> Does Google need to use the same JavaScript libraries and PHP back-end
>> that SquirrelMail uses in order to implement a web email application? No.
>>
>> Can Google change that JavaScript tomorrow without breaking
>> interoperability? Yes, and they probably will.
>>
>> But could Gmail be as successful without the worldwide SMTP infrastructure
>> it ties in to? Probably not.
>>
>> I see the same situation here. A web browser with real-time communication
>> capabilities will work in conjunction with a web site that serves up the
>> HTML and JavaScript that makes up the calling application. For some
>> applications, this will be sufficient. For others, one will want to
>> implement SIP or XMPP/Jingle or something else in order to gateway these
>> calls to other networks. The SIP implementation can live in the JavaScript,
>> up in the web server, in a separate gateway, or any combination thereof.
>>
>> Matthew Kaufman
>>
>> _______________________________________________
>> RTC-Web mailing list
>> RTC-Web at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/rtc-web
>>
>
>
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtc-web/attachments/20110202/8e3320b7/attachment.html>