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

[Roman Shpount <[e-mail]>]

On Mon, Mar 23, 2015 at 5:54 PM, Justin Uberti <[e-mail]> wrote:

>
> 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.
>

I think this was changed in the latest data channel draft, where it is
specified that fingerprint must not change unless the underlying transport
changes as well. The problem is that you cannot start a new DTLS session
unless it can be de-muxed from the previous sessions based on the transport
parameters. This means a new "virtual" channel for each new DTLS setup.
Which in turn means that there should be a way to identify which "virtual"
channel each packet belongs to based on the 5-tuple, with information
received during ICE handshake used to associate each 5-tuple with the
specific "virtual" channel. More then one 5-tuple can form a single virtual
channels but each 5-tuple can belong to one "virtual" channel at any given
time.


>
>> 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.
>
>>
>>
How does the mid header extension helps with DTLS packet de-multiplexing in
cases of DTLS-SRTP handshake or data channel?
_____________
Roman Shpount