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

[Roman Shpount <[e-mail]>]

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?

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?

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