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

[Christer Holmberg <[e-mail]>]

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.

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
>