Re: [MMUSIC] IETF#89: BUNDLE: Q12: Scope of non-RTP media de-mux procedures in BUNDLE?

[Christer Holmberg <[e-mail]>]

Hi,

>> One of the open issues is what we, in the BUNDLE spec, are going to 
>> say about de-multiplexing about different media types, and for which 
>> (if any) media types we are going to specify how the de-multiplexing is done.
>>
>> We have previously agreed that we are NOT going to describe all 
>> different possibilities in BUNDLE, and that separate specifications 
>> how to perform (and, indicate support of) de-multiplexing will have to 
>> be written. However, we haven't really agreed on the details.
>>
>> I intend to suggest the following in London.
>>
>> In the BUNDLE spec we:
>>
>> 1)Reference to RFC 5764 for how to de-multiplex DTLS/SRTP/STUN; and
>>
>> 2)Separate specifications are required to describe how to de-mulitplex 
>> other media types, and any type of information that needs to be 
>> exchanged between peers in order to perform the de-multiplexing.
>>
>> I think that DTLS/SRTP/STUN is going to be the main use-case (not only 
>> for WebRTC) in the near future, so I think it's a good approach.
>
> Note that 5764 is sufficient to demux SRTP traffic from DTLS payload messages. It doesn't say 
> anything about what those payload messages are used for.
>
> It will take another reference to specify that when using proto DTLS/SCTP those payload messages > are used exclusively for SCTP.

I am fully aware of that. But, my proposal remains :)

If you want to transport different things (e.g. data channel and something else) over DTLS, you need a specification that describes how the separation is done.

Regards,

Christer