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

[Harald Alvestrand <[e-mail]>]

On 06/19/2013 01:53 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.

> 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