Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)

[Harald Alvestrand <[e-mail]>]

On 06/19/2013 03:06 PM, Christer Holmberg wrote:
> Hi,
>   
>>>>> I put together some text regarding the de-muxing for BUNDLE.
>>>>>
>>>>> Note that there is yet no text on HOW the de-muxing is performed.
>>>>>> The text only cover the SCOPE of what will be specified in the
>>>>> BUNDLE spec. I want us to agree on that first :)
>>>> I think you should be careful about this. You risk duplicating material from other specs.
>>> That's why I am eager to hear your input on what shall be covered in
>>> the BUNDLE spec regarding de-muxing :)
>>>
>>> For example, are you saying BUNDLE shouldn't specify HOW the de-muxing is done?
>> Absolutely, I'm saying that BUNDLE should not specify a procedure for de-muxing.
>> Instead, it should point to the specs that already specify how the de-muxing is done.
>>
>> See my comments below as to what I think it should say.
> I didn't see your comments in the previous mail. Sorry for that.
>
> But, as Thomas said, we also need to cover STUN packets.

This is also covered in RFC 5764 section 5.1.2.

>
> Regards,
>
> Christer
>
>
>
>
>
>> 9.  Transport Protocol De-Multiplexing
>>    
>> 9.1.  General
>>    
>>      Endpoints can assign "m=" lines representing different transport
>>      protocols [RFC4566], identified using the "m=" line proto value
>>      [RFC4566].
>>    
>>      As each "m=" line in a BUNDLE group share the BUNDLE address, an
>>      endpoint MUST be able to de-multiplex data received on the BUNDLE
>>      address, meaning it MUST be able to associate the received with one
>>      of the transport protocols assigned to the BUNDLE group.  Endpoints
>>      MUST NOT assign a transport protocols to a BUNDLE group, unless it is
>>      able to separate received data from data associated with other
>>      transport protocols assigned to the BUNDLE group.
>>    
>>      In addition, if an endpoint assigns multiple "m=" lines representing
>>      the same transport protocol to a BUNDLE group, the endpoint MUST be
>>      able to, in addition to associating received data to its transport
>>      protocol, also associate the received data with a specific "m=" line
>>      representing that transport protocol.
>>    
>>      This specification defines how to de-multiplex received media
>>      associated with the following transport protocols:
>>    
>>      o  "RTP/AVP" [RFC4566];
>>    
>>      o  "RTP/AVPF" [RFC4585];
>>    
>>      o  "RTP/SAVP" [RFC3711];
>>    
>>      o  "RTP/SAVPF" [RFC5124];and
>>    
>>      o  "SCTP/DTLS" [ref-to-be added].
>>
>> This is somewhat incomprehensible to me; the most logical description I can make is that it means that you can separate packets into one heap containing all the RTP variants and another heap containing SCTP/DTLS - but that is not obvious. Suggest instead:
>>
>>
>> This specification defines how to de-multiplex protocols carried over RTP (which include RTP/AVP [], RTP/AVPF [], RTP/SAVP[] and RTP/SAVPF [] from protocols carried over DTLS (which include SCTP/DTLS []).
>>
>> And that makes the specification of the demultiplexing very simple:
>>
>> "See RFC 5764 section 5.1.2"
>>
>>
>>    
>>      This specification also specifies how RTP packats are separated from
>>      RTCP packets.
>>
>> Again, the specification of how to do this separation is very simple:
>>
>> "See RFC 5761 section 4"
>>
>>    
>>      If an endpoint assigns multiple "m=" lines representing RTP/RTCP
>>      media to a BUNDLE group, it is outside the scope of this
>>      specification how the endpoint associates received RTP/RTCP packets
>>      with a specific RTP/RTCP "m=" line (endpoints might use payload type
>>      values, or SSRC values, for the association).
>>    
>>      If endpoints want to assign "m=" lines representing other transport
>>      protocols to a BUNDLE group, it MUST be documented how the de-
>>      multiplexing is performed.  There might also be a need for signalling
>>      extensions in order for endpoints to exchange data needed for the de-
>>      multiplexing.
>>
>> I agree with the sense of these paragraphs.
>>
>>
>>    
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>