Re: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls)

[Roman Shpount <[e-mail]>]

On Tue, Sep 27, 2011 at 8:17 PM, Matthew Kaufman
<[e-mail]>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.

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. Until this happens RTC
end points will have to rely on some sort of media proxy to communicate with
existing infrastructure. Is this correct?

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.
_____________
Roman Shpount