Re: Signaling & peerconnection API questions

at bottom ...

On Jul 25, 2011, at 22:50 , Ian Hickson wrote:

> On Wed, 20 Jul 2011, Stefan Håkansson LK wrote:
>> On 2011-07-20 00:40, Cullen Jennings wrote:
>>> On Jul 19, 2011, at 12:21 , Matthew Kaufman wrote:
>>>> On 7/19/2011 10:49 AM, Ian Hickson wrote:
>>>>> On Tue, 19 Jul 2011, Stefan Håkansson LK wrote:
>>>>>> 
>>>>>> So basically the web app could fake an SDP offer (indicating no 
>>>>>> support of ICE) locally, feed it to a PeerConnection object and 
>>>>>> then use 'send' to have the browser send data to an IP address 
>>>>>> and port of its choice (the address/port in the fake SDP).
>>>>>> 
>>>>>> This is not at all my area, so apologies up front if I got 
>>>>>> things wrong.
>>>>> 
>>>>> I don't know about the audio and video streams, but at least in 
>>>>> the case of the data streams, this is the kind of thing we avoid 
>>>>> having to worry about by having the data stream be 
>>>>> indistinguishable from line noise.
>>>> 
>>>> I think an SDP offer that indicates no support of ICE MUST be 
>>>> rejected as failing to comply with the security model. No handshake, 
>>>> no sending audio, video, or data to them.
>>> 
>>> +1 - seriously, I can't see any alternative to this
>> 
>> My conclusion was the same. This means as far as I understand it that 
>> the spec should be updated. Today it just references rfc5245, I think a 
>> clause saying something like "that an SDP offer indicating that ICE is 
>> not supported must be rejected" should be added. Alternative it could 
>> say that no sending of audio, video or data is allowed if there has not 
>> been an ICE handshake. (I guess others will be able to phrase this much 
>> better).
> 
> I tried to add something to this effect to the spec, but I couldn't find 
> where in the ICE spec it would ever cause any processing to occur in a 
> manner that didn't involve a probe which would fail if the other side 
> wasn't expecting a connection. Can someone more familiar with ICE 
> elaborate on what behaviour exactly it is that I should be blocking here?

I think the important thing to say is that the browser must not send any data other than the stun packets until after it has had an success stun response from the address/port pair it is going to send the data to. The implications of this are that if you get SDP with no ICE candidates in it, the STUN probes will never be successfully and you will never be able to set up any of the audio video connections in the SDP. So if the API gets some SDP with no ice candidates, it is not going to work and could be handled right away as an error.

Received on Tuesday, 26 July 2011 10:37:48 UTC