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

[Justin Uberti <[e-mail]>]

On Mon, Mar 23, 2015 at 5:04 PM, Roman Shpount <[e-mail]> wrote:

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

This would only be an issue if multiple DTLS connections were multiplexed
over a single ICE transport. I'm not aware of any need for this, compared
to the clear need for muxing multiple RTP streams.