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

[Justin Uberti <[e-mail]>]

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

> On Mon, Mar 23, 2015 at 6:17 PM, Justin Uberti <[e-mail]> wrote:
>
>>
>>
>> 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.
>>
>
> How would you deal with multiple DTLS handshakes for DTLS-SRTP?
>

Unclear; as you have pointed out, it's not clear whether a given DTLS
packet belongs to the old session or the new session.


>
> My understanding was that in case of bundled channels, all channels go
> over the same "virtual" ICE channel, get decoded by the single DTLS-SRTP
> session, and then get demuxed using mid header, payload type, SSRC, or some
> other RTP level field. In any case, all these bundled m= lines share the
> same "virtual" transport channel. There can be, one data channel which
> shares this single "virtual" transport with all those RTP streams. In any
> case, mid header extensions, SSRC, and payload are irrelevant to binding
> packets to the "virtual" transport, since in case of DTLS-SRTP encoded
> media, packets would need to be de-muxed before any of those fields can be
> determined.
>

This is true. But demux is not an issue; we know which 5-tuples are part of
the ICE channel. I think we are simply searching for a convenient handle
that we can apply for this virtual channel.



> _____________
> Roman Shpount
>
>