Subject: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) - Late night version

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Jun 2013 18:38:30 +0000

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.

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

   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.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Jun 2013 14:18:09 -0400

Getting better.
More inline.

> - 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.

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.

>     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

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 Jun 2013 09:31:31 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 20. kesäkuuta 2013 21:18
To: [email-masked]
Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) - Late night version

Getting better.
More inline.

> - 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.

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.

>     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