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

[Henry Sinnreich]

Is there some understanding on the list on how the IP addresses in SDP can
be reconciled with the USAF RFC 3424?
http://www.rfc-editor.org/rfc/rfc3424.txt

³...a process whereby some
   originating process attempts to determine or fix the address (and
   port) by which it is known - e.g. to be able to use address data in
   the protocol exchange, or to advertise a public address from which it
   will receive connections.
There are only heuristics and workarounds to attempt to achieve this
   effect; there is no 100% solution.  Since NATs may also dynamically
   reclaim or readjust translations, "keep-alive" and periodic re-
   polling may be required.  Use of these workarounds MUST be considered
   transitional in IETF protocols, and a better architectural solution
   is being sought.  The explicit intention is to deprecate any such
   workarounds when sound technical approaches are available.²

Obviously there is much more dead stuff in SDP besides using the misleading
IP addresses, but this seems to be a deep architectural flaw.
There were some early attempts to do SDPng and we know today much more:
http://tools.ietf.org/html/draft-ietf-mmusic-sdpng-07

Why not replace SDP, since it deals only with a/v codec negotiation with a
more general, standards based metadata approach?
For example including Web conferencing displays and UI control capabilities.
Of course such a new approach must be easily mapped to the existing global
SIP VoIP infrastructure.

Or are the no  ³sound technical approaches² available at all?

Thanks, Henry


On 2/2/11 11:55 AM, "Bernard Aboba" <bernard.aboba at gmail.com> wrote:

> 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
>> 
> 
> 
> 
> _______________________________________________
> dispatch mailing list
> dispatch at ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtc-web/attachments/20110202/5e01e214/attachment.html>