Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments - associated DTLS with m- line

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 Oct 2014 09:45:30 +0000

Hi,

>>>>>>>>> What would you like to mention about SCTP?
>>>>>>>>>
>>>>>>>>>> IIUC, DTLS/SRTP uses DTLS packets to do key exchange, but 
>>>>>>>>>> doesn't use DTLS payload packets. So *one* m-line with a 
>>>>>>>>>> protocol that uses DTLS payload packets (e.g., >DTLS/SCTP) can 
>>>>>>>>>> coexist with STUN and SRTP. If there is more than one such m-line then some other specification is required to associate those packets with m-lines.
>>>>>>>>>
>>>>>>>>> I think that is covered, as SRTP is distinguished from DTLS.
>>>>>>>>>
>>>>>>>>> But, if you think that needs to be more clear, maybe the following modified sentence:
>>>>>>>>>
>>>>>>>>> 	"[RFC5764] does not describe how to identify different protocols transported on DTLS (i.e. using DTLS payload packets), only how to..."
>>>>>>>>>
>>>>>>>> I think this document should bite the bullet and define how SCTP coexists with SRTP in a bundle.
>>>>>>>
>>>>>>> Personally, I would not want to do that at this stage. We decided 
>>>>>>> earlier that the draft will cover DTLS, SRTP and STUN, and that any other protocols/combinations have to be defined elsewhere.
>>>>>>
>>>>>> If it isn't here, then it needs to be somewhere else. Where?
>>>>>
>>>>> In a separate draft.
>>>>>
>>>>>> It shouldn't be hard.
>>>>>
>>>>> Who is asking for it? RTCWEB will not support SCTP transport (they will support SCTP over DTLS).
>>>>
>>>> I'll be satisfied if it covers SCTP over DTLS. That is the case where it needs to be able to coexist with RTP.
>>>
>>> The draft describes how you distinguish between DTLS and SRTP, so that also covers SCTP over DTLS (SCTP is the "application protocol" carried on DTLS).
>>>
>>> How you differentiate different protocols carried over DTLS need to be described elsewhere, but if you only have SCTP carried over DTLS nothing else is needed.
>>>
>>> In addition, if you want to define how to separate SCTP from something else, you would need to know what that something else is.
>>
>> The draft describes how to distinguish DTLS and SRTP packets. It doesn't describe how to associate the DTLS packets with m-lines.
>>
>> Rather than single SCTP over DTLS out as special, this draft could simply say that:
>>
>> - if the bundle contains *no* m-lines for protocols that utilize DTLS
>>   payload packets then DTLS payload packets are erroneous.
>>
>> - if the bundle contains *one* m-line for a protocol that utilizes
>>   DTLS payload packets then all the payload packets are to be
>>   associated with it.
>>
>> - if the bundle contains *more than one* m-line for protocols that
>>   utilize payload packets then some other specification is needed
>>   to define how the packets are associated with m-lines.
>
> Currently we have the following text in the draft:
>
>   "[RFC5764] does not describe how to identify different protocols
>   transported on DTLS, only how to identify the DTLS protocol itself.
>   If multiple protocols are transported on DTLS, there MUST exist a
>   specification describing a mechanism for identify each individual
>   protocol."
>
> I guess we could e.g. extend that by saying that the document does not describe how to associated 
> DTLS data with an m- lines, and that a separate specification is needed to define that (basically the third 
> bullet you suggest).

I realized that we have the existing text in section 9.1:

   	"In addition, if a received packet can be associated with more than
   	one bundled "m=" line, there MUST exist a publically available
   	specification which describes a mechanism for associating the
   	received packet with the correct "m=" line."

So, I think that covers the case where you would receive DTLS packets associated with multiple "m=" lines.

Regards,

Christer