DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from
 :mime-version:to:cc:subject:references:in-reply-to:content-type; q=dns; s=mx;
 b=jPbTqZLGf1iwSBXLM5Ny2Wxi903a6FlXWGA+hhRMq8d1wA/p
 xj/JbO1Z5PQhkRwy+AAeocdK93yExoHAdQI6xmW3RH1WBFUQr+LFQINwV5ZtalGW
 U4kPC0Mc0N2/YPH8wZAHvu2dzcQPROnxqwy+a7u+bH4/qktN1Td+qwH6VPc=
Message-ID: <4E8279AD.6030409@skype.net>
Date: Tue, 27 Sep 2011 18:34:37 -0700
From: Matthew Kaufman <matthew.kaufman@skype.net>
User-Agent: Mozilla/5.0 (Windows NT 5.1;
 rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Roman Shpount <roman@telurix.com>
References: <CAD5OKxtNjmWBz92bRuxka7e-BUpTPgVUvr3ahJGpmZ-U5nuPbQ@mail.gmail.com>
 <CAOJ7v-1rzdmviAnGknVZmrU_TDNoC3NmWd1g6iyx0WzZ4xB3Pw@mail.gmail.com>
 <4E820825.9090101@skype.net>
 <CAD5OKxvmKi3Py0gNcTdREdfS07hA-=f6L+u8KKVgSWztMft9kQ@mail.gmail.com>
 <CALiegfmL4VSRE+kgs5kXzQc3mCHnKpU-EAbVPKO4QNEYLKje=A@mail.gmail.com>
 <4E821E47.4080205@alvestrand.no>
 <CALiegfndBhod6Hoq6h63795x8f=ew28rDys=Fx8ScwVpVJwp1Q@mail.gmail.com>
 <CABcZeBOoF6MNSpATG2+_e99iRq7Jf9OoWWNCa=qRGW_v+maoHA@mail.gmail.com>
 <CAD5OKxubnxLAqybCgnBXpKR9S0rBEsoDg9enCaverjVWYad7Ew@mail.gmail.com>
 <CABcZeBPoQSM=L0-Er3j-ak2M6YfCbJkThbYuR_+=xUmcsxQz9Q@mail.gmail.com>
 <CAD5OKxsVE+LwKEcpe+hf+=i87Ucga0_VpkUGJkH5=HixV5Xkmw@mail.gmail.com>
 <CABcZeBM+FD5y7WenD=d_7jM1Fu+OrFyFgtsd1iGMpGfMe_gOKQ@mail.gmail.com>
 <CAD5OKxte2DYbgtFpF2jQGq_thYCyb1Li2ih5J6gpzamhJvRyTA@mail.gmail.com>
 <4E82678E.6060304@skype.net>
 <CAD5OKxv2UjmCmdDGo2ECbFr3b0-WUnUWhpdDreQYqP9yJUKR=A@mail.gmail.com>
In-Reply-To: <CAD5OKxv2UjmCmdDGo2ECbFr3b0-WUnUWhpdDreQYqP9yJUKR=A@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------060403020406030300070603"
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Solutions sought for non-ICE RTC calls,
 not +1 (Re: Requiring ICE for RTC calls)
Precedence: list

This is a multi-part message in MIME format.
--------------060403020406030300070603
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 9/27/2011 5:39 PM, Roman Shpount wrote:
>
> On Tue, Sep 27, 2011 at 8:17 PM, Matthew Kaufman 
> <matthew.kaufman@skype.net <mailto:matthew.kaufman@skype.net>> wrote:
>
>     No. This is not a correct description of the problem.
>
>     ICE isn't about "trusting the site to not do something malicious
>     with your media". ICE is about "trusting your browser to not
>     attack other devices on your local network or the Internet".
>
>     The browser must, without asking the user, be able to prove that
>     the far end wishes to receive a stream of media. The standard we
>     have available for that is a STUN connectivity check with
>     short-term credentials, using a transaction ID that can neither be
>     set from Javascript nor inspected from Javascript (to prevent
>     spoofing of the reply). This is basically how ICE tests connectivity.
>
>     Note that the consent must use the same protocol and port you will
>     be sending media on. So for RTP or SRTP over UDP, the consent
>     request must be sent and received over that same UDP port.
>
>     Matthew Kaufman
>
>
> You just repeated the same thing that I said, just a bit more clearly.

If you say so.

>
> I guess we are making a conscientious not to be able to communicate 
> with any of the existing VoIP infrastructure including IP phones and 
> SIP trunking providers and expect them to implement ICE support.

Unfortunately that appears to be necessary.

> Until this happens RTC end points will have to rely on some sort of 
> media proxy to communicate with existing infrastructure. Is this correct?

Yes. Of course there's numerous examples of this working well already.

>
> Do we have anybody in this list who has real life experience with 
> deploying large scale ICE based solutions over public internet? I just 
> want to make sure that we are not putting all of our eggs in the 
> basket that no one ever used.

Good question, but I believe Google has a fair bit of ICE experience.

Matthew Kaufman


--------------060403020406030300070603
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 9/27/2011 5:39 PM, Roman Shpount wrote:
    <blockquote
cite="mid:CAD5OKxv2UjmCmdDGo2ECbFr3b0-WUnUWhpdDreQYqP9yJUKR=A@mail.gmail.com"
      type="cite"><br clear="all">
      <div class="gmail_quote">On Tue, Sep 27, 2011 at 8:17 PM, Matthew
        Kaufman <span dir="ltr">&lt;<a moz-do-not-send="true"
            href="mailto:matthew.kaufman@skype.net">matthew.kaufman@skype.net</a>&gt;</span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex;">
          <div bgcolor="#FFFFFF" text="#000000"> No. This is not a
            correct description of the problem.<br>
            <br>
            ICE isn't about "trusting the site to not do something
            malicious with your media". ICE is about "trusting your
            browser to not attack other devices on your local network or
            the Internet".<br>
            <br>
            The browser must, without asking the user, be able to prove
            that the far end wishes to receive a stream of media. The
            standard we have available for that is a STUN connectivity
            check with short-term credentials, using a transaction ID
            that can neither be set from Javascript nor inspected from
            Javascript (to prevent spoofing of the reply). This is
            basically how ICE tests connectivity.<br>
            <br>
            Note that the consent must use the same protocol and port
            you will be sending media on. So for RTP or SRTP over UDP,
            the consent request must be sent and received over that same
            UDP port.<br>
            <font color="#888888"> <br>
              Matthew Kaufman<br>
              <br>
            </font></div>
        </blockquote>
      </div>
      <br>
      You just repeated the same thing that I said, just a bit more
      clearly. <br>
    </blockquote>
    <br>
    If you say so.<br>
    <br>
    <blockquote
cite="mid:CAD5OKxv2UjmCmdDGo2ECbFr3b0-WUnUWhpdDreQYqP9yJUKR=A@mail.gmail.com"
      type="cite"><br>
      I guess we are making a conscientious not to be able to
      communicate with any of the existing VoIP infrastructure including
      IP phones and SIP trunking providers and expect them to implement
      ICE support.</blockquote>
    <br>
    Unfortunately that appears to be necessary.<br>
    <br>
    <blockquote
cite="mid:CAD5OKxv2UjmCmdDGo2ECbFr3b0-WUnUWhpdDreQYqP9yJUKR=A@mail.gmail.com"
      type="cite"> Until this happens RTC end points will have to rely
      on some sort of media proxy to communicate with existing
      infrastructure. Is this correct?<br>
    </blockquote>
    <br>
    Yes. Of course there's numerous examples of this working well
    already.<br>
    <br>
    <blockquote
cite="mid:CAD5OKxv2UjmCmdDGo2ECbFr3b0-WUnUWhpdDreQYqP9yJUKR=A@mail.gmail.com"
      type="cite">
      <br>
      Do we have anybody in this list who has real life experience with
      deploying large scale ICE based solutions over public internet? I
      just want to make sure that we are not putting all of our eggs in
      the basket that no one ever used.<br>
    </blockquote>
    <br>
    Good question, but I believe Google has a fair bit of ICE
    experience.<br>
    <br>
    Matthew Kaufman<br>
    <br>
  </body>
</html>

--------------060403020406030300070603--