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

Hi Paul,

I submitted the late night version text before you questioned whether referencing RFC 5764 is enough, so we obviously need to sort that out before moving ahead with the text :)

Regards,

Christer

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: 20. kesäkuuta 2013 21:18
To: mmusic@ietf.org
Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) - Late night version

Getting better.
More inline.

On 6/19/13 2:38 PM, Christer Holmberg wrote:
> Hi,
>
> I modified the text, based on the comments.
>
> - The text now refers to RFC 5764 for RTP, DTLS, STUN de-multiplexing.
> - I added an open note regarding how much we need to specify regarding "m= line de-muxing" for the same transport protocol.
> - I removed the MUST for having to be able to do "m= line de-muxing" for the same transport protocol, as there could be cases where it's not needed.
>
> Regards,
>
> Christer
>
> --------------------------------------------------
>
>
> 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 might
>     also have to be able to, in addition to associating received data to
>     its transport protocol, associate the received data with a specific
>     "m=" line representing that transport protocol.
>
>     OPEN ISSUE: We need to discuss how much, if anything, we need to say
>     about associating RTP packets with the correct "m=" line, in cases
>     where there are multiple "m=" lines for RTP media.

My position on this is well known - presumably the issue refers to my arguments. So I won't repeat them here.

*If* we can agree that associating packets to m-lines is a MUST, then the two paragraphs above the open issue can be collapsed into one. (If you can associate to an m-line, then of course you can associate to the protocol described by the m-line.

>     Section 5.1.2 of [RFC5764] specifies how to de-multiplex RTP, DTLS and
>     STUN [RFC5389] data packets.

Something special must be said about STUN, because it is indeed an exception to my point about associating to an m-line. It is also an exception to associating to a protocol mentioned in m-lines.

What is complex here is that we are dealing with layered protocols, but SDP syntax pretends they are not. To address this fully, I think it is necessary to identify the protocol *stack* for each m-line, and then figure out which of those layers are shared by multiple m-lines. STUN is a middle layer in the stack, presumably shared by all the m-lines.

	Thanks,
	Paul

>     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.
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic