Re: [MMUSIC] draft-uberti-mmusic-nombis and (D)TLS

[Justin Uberti <[e-mail]>]

On Mon, Mar 23, 2015 at 8:24 AM, Roman Shpount <[e-mail]> wrote:

> On Sun, Mar 22, 2015 at 11:56 PM, Justin Uberti <[e-mail]>
> wrote:
>
>> Alas, an ICE ufrag doesn't uniquely identify an ICE virtual connection;
>> with ICE forking you can have N virtual connections from the same ufrag.
>>
>> A lfrag:rfrag tuple is closer, but even this does not work, because a) an
>> ICE restart changes lfrag/rfrag without invalidating the connection, and b)
>> because a ufrag can be shared across multiple m= lines (and thereby ICE
>> connections).
>>
>> The closest thing is m-line, keeping in mind that bundled m-lines use the
>> virtual connection of the m-line onto which they are bundled.
>>
>>
> Would ICE restart cause new DTLS handshake? If it does not, what is the
> appropriate transport parameter change that will cause the new DTLS
> handshake?
>

No, ICE restart does not rehandshake (it's orthogonal). There is currently
no SDP parameter defined that allows for a rehandshake, except for offering
a new fingerprint; use of the a=connection attribute is explicitly
forbidden by 5763.

>
> When you say m= line, how would the end point associate received packets
> with the specific m= line? To handle forks this has to be local m= line and
> remote m=line pair, but what does this translate into on the RTP/DTLS
> transport layer? Do you propose to associate based on remote ufrag, local
> ufrag and the set of local candidates associated with this m= line? Would
> it not be simpler to prohibit ufrag reuse?
>

For unbundled cases this is non-ambiguous. For bundled cases, there is the
mid header extension.

>
> P.S. If ICE restart would cause the new DTLS connection to be established
> this would either mean the same candidates cannot be used after ICE restart
> or that an end point can receive packets for several unrelated DTLS
> connections over the same 5-tuple. Same old mess all over again.
> _____________
> Roman Shpount
>
>