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

From: Justin Uberti <[email-masked]>
Date: Tue, 1 Feb 2011 22:47:24 -0800

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
<[email-masked]>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
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>

---

From: <[email-masked]>
Date: Wed, 2 Feb 2011 08:24:43 +0000

Hi Justin,

I’m not sure I fully understand the task b) that you describe below. You are not talking about a representation/mechanism for a wire protocol, but something related to the API? I mean, if everyone is going to define and implement their own “signaling” protocol on HTTP or websockets, what is it exactly that would need to be standardized?

If we use webmail as an example, there has been no need to define any mapping/format related to SMTP. So if that case is analogous to this one, why we need to do something different here? I know that the difference is that in RTC-Web we want to establish media streams end-to-end between the browsers, unlike in e-mail. So, the cases are not fully analogous after all. Some elaboration on that point would help many people to understand the RTC-Web need better, I think.

Thanks,
Markus

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Justin Uberti
Sent: 02 February, 2011 08:47
To: Matthew Kaufman
Cc: [email-masked]; DISPATCH list
Subject: Re: [dispatch] [RTW] Does RTC-WEB need to pick a signaling protocol?

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 <[email-masked]<mailto:[email-masked]>> 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.

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
[email-masked]<mailto:[email-masked]>
http://www.alvestrand.no/mailman/listinfo/rtc-web

---

From: Xavier Marjou <[email-masked]>
Date: Wed, 2 Feb 2011 09:58:09 +0100

I agree that it is important to have rtcweb interoperable with the rest of
the world (i.e. millions of existing end-points that use SIP or XMPP). I
think that interoperability with such protocols - which are IETF protocols
by the way - should really be in the scope of the charter.

On Wed, Feb 2, 2011 at 7:47 AM, Justin Uberti <[email-masked]> wrote:

> So I think we have existence proofs that this approach, in addition to
> being extremely flexible, is entirely workable today.
>
> On Mon, Jan 31, 2011 at 8:12 AM, Matthew Kaufman <
> [email-masked]> wrote:
>
>> 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.
>>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 2 Feb 2011 09:55:33 -0800

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).

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 02 Feb 2011 13:19:08 -0600

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" <[email-masked]> wrote:

> create the SDP offer.   (see http://javascript.about.com/library/blip.htm ). 
> 
>> On Mon, Jan 31, 2011 at 8:12 AM, Matthew Kaufman <[email-masked]>
>> wrote:
>>>> 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.
>>> 
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 3 Feb 2011 10:10:21 -0800

Given that people have been using workarounds to obtain IP addresses, the value of keeping this out of Javascript seems marginal. 

However, since the W3C will be handling APIs, not the IETF, this does raise the question of how issues like this will be coordinated.

Date: Thu, 3 Feb 2011 08:50:27 -0800
From: [email-masked]
To: [email-masked]
CC: [email-masked]; [email-masked]
Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol?

    

    On 02/03/11 01:32, Justin Uberti wrote:
    
      I would expect that the APIs that this group creates would
        handle the details of obtaining any needed addresses (whether
        they be local, server reflexive, or relayed endpoints). Do we
        think there is a significant security concern here (above and
        beyond exposing the ability to send audio and video from your
        computer)?

Apart from the known security concerns that come automatically from
    sharing IP addresses (such as revealing your network attachment
    location to whoever gets the IP address), I don't see any huge ones.

        On Wed, Feb 2, 2011 at 7:49 PM, Bernard
          Aboba <[email-masked]>
          wrote:

              Alternatives can be explored for how to represent the
              information provided by SDP, but the enumeration and
              testing of potential endpoints within an offer-answer
              exchange is at the core of ICE (RFC 5245), and is also a
              potential means for demonstrating media authorization.  If
              the Javascript limitations on enumeration of physical or
              logical addresses can't be overcome, we might have to live
              with server reflexive and relayed endpoint identifiers
              (assuming that server reflexive and relayed endpoint
              identifiers don't trigger similar concerns).  Replacing
              addresses with names could be done prior to the
              offer/answer exchange but this might introduce
              vulnerabilities (e.g. voice hammer attacks based on DNS
              cache poisoning).  

              Date: Wed, 2 Feb 2011 16:09:48 -0800

              From: [email-masked]

              To: [email-masked]

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

                  On 02/02/11 11:19, Henry Sinnreich wrote:
                   Is there
                        some understanding on the list on how the IP
                        addresses in SDP can be reconciled with the USAF
                        RFC 3424?

                  Nit: UNSAF, not USAF.

                        

                        “...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

                          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.”

                  In our case, the answer that has proved workable is
                  called STUN.

                        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:

                        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?

                  I'm all in favour of replacing SDP, but would not like
                  to require that before we can produce any output from
                  this group.

                  Justin's idea of sorting out what information we need
                  and specifying how that maps into SDP (just like is
                  currently done by Jingle) might be a reasonable
                  approach that can allow us to not fossilize SDP's
                  misfeatures forever.

                                         Harald

              

            RTC-Web mailing list

            [email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 04 Feb 2011 14:52:35 -0500

I think it is well within the scope of the IETF activity to define the 
protocols and, consequently, their semantics which must be exposed by 
the browser. The actual API is then the problem of the W3C.

As it relates to this question about IP addresses - I don't see the need 
to specify any kind of syntax at all around how IP addresses are 
conveyed. Rather, we just need to be certain that APIs exist which allow 
a Javacript application to obtain the IP addresses needed to construct 
the SDP.

Thanks,
Jonathan R.

On 2/3/2011 1:10 PM, Bernard Aboba wrote:
> Given that people have been using workarounds to obtain IP addresses,
> the value of keeping this out of Javascript seems marginal.
>
> However, since the W3C will be handling APIs, not the IETF, this does
> raise the question of how issues like this will be coordinated.
>
> ------------------------------------------------------------------------
>     I would expect that the APIs that this group creates would handle
>     the details of obtaining any needed addresses (whether they be
>     local, server reflexive, or relayed endpoints). Do we think there is
>     a significant security concern here (above and beyond exposing the
>     ability to send audio and video from your computer)?
>
>
> sharing IP addresses (such as revealing your network attachment location
> to whoever gets the IP address), I don't see any huge ones.
>
>
>     On Wed, Feb 2, 2011 at 7:49 PM, Bernard Aboba
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         information provided by SDP, but the enumeration and testing of
>         potential endpoints within an offer-answer exchange is at the
>         core of ICE (RFC 5245), and is also a potential means for
>         demonstrating media authorization. If the Javascript limitations
>         on enumeration of physical or logical addresses can't be
>         overcome, we might have to live with server reflexive and
>         relayed endpoint identifiers (assuming that server reflexive and
>         relayed endpoint identifiers don't trigger similar concerns).
>         Replacing addresses with names could be done prior to the
>         offer/answer exchange but this might introduce vulnerabilities
>         (e.g. voice hammer attacks based on DNS cache poisoning).
>         ------------------------------------------------------------------------
>         From: [email-masked] <mailto:[email-masked]>
>         To: [email-masked] <mailto:[email-masked]>
>             Is there some understanding on the list on how the IP
>             addresses in SDP can be reconciled with the USAF RFC 3424?
>
>         Nit: UNSAF, not USAF.
>
>             “...a process whereby some
>             workarounds when sound technical approaches are available.”
>
>         In our case, the answer that has proved workable is called STUN.
>
>
>             Obviously there is much more dead stuff in SDP besides using
>             the misleading IP addresses, but this seems to be a deep
>             architectural flaw.
>             Why not replace SDP, since it deals only with a/v codec
>             negotiation with a more general, standards based metadata
>             approach?
>             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?
>
>         I'm all in favour of replacing SDP, but would not like to
>         require that before we can produce any output from this group.
>
>         Justin's idea of sorting out what information we need and
>         specifying how that maps into SDP (just like is currently done
>         by Jingle) might be a reasonable approach that can allow us to
>         not fossilize SDP's misfeatures forever.
>
>         Harald
>
>
>         _______________________________________________ RTC-Web mailing
>         list [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>
> _______________________________________________ RTC-Web mailing list
> [email-masked] http://www.alvestrand.no/mailman/listinfo/rtc-web
>
>
>