Subject: [MMUSIC] BUNDLE: Q9/Q13: Payload type value re-usage and associating RTP packets with m- line

From: Christer Holmberg <[email-masked]>
Date: Tue, 11 Mar 2014 08:56:29 +0000

Hi,

Based on the discussion/decision in London, I've drafted the following text regarding the usage of identical PT values, and the usage of the "receiver-id" value in order to be able to associate received RTP packets with the correct m- line (when the same payload type value is used inside multiple m- lines within the BUNDLE group).

I may change some words later, in order to align with the rest of the document, but please take a look and see whether you are ok with the content, and whether you think it reflects the decisions in the meeting.
Regards,

Christer

---------------------------------------

X.X         RTP Considerations

X.X.1      Multiple Usage Of Identical Payload Type (PT) Value Within A BUNDLE Group

A BUNDLE group can contain multiple m- lines associated with RTP media. As all RTP media associated with those m- lines belong to the same RTP session [insert-reference], in order for a payload type value to used inside more than one m- line, all codecs associated with the payload type numbers MUST share an identical codec configuration. This means that the codecs MUST share the same media type, encoding name, clock rate and any parameter that can affect the codec configuration and packetizsation. [ID.draft-ietf-mmusic-sdp-mux-attributes] lists SDP attribute values that must be identical for all codecs using the same payload type value.

X.X.2      Associating RTP Packets With Correct SDP Media Description Within A BUNDLE Group

In general, there are multiple mechanisms that can be used by an endpoint in order to associate received RTP packets with the m- line associated with the RTP packets. Such mechanisms include using the local address:port on which the RTP packets are received, the payload type value carried inside the RTP packets, the SSRC values carried inside the RTP packets, and other m- line specific information carried inside the RTP packets.

Within a BUNDLE group, as all RTP packets are transported using the same 5-tuple, the local address:port cannot be used to associate received RTP packets with the correct m- line.

As described in section X.X.1, the same payload type value might be used inside RTP packets associated with multiple m- lines. In such cases, the payload type value cannot be used to associate received RTP packets with the correct m- line.

Endpoints can inform each other which SSRC values they will use inside sent RTP packets by, in SDP Offers and Answers, assigning an SDP 'ssrc' attribute [ref-to-be-added] to each m- line which contains a payload type value that is also used inside another m- line within the BUNDLE group. As the SSRC values will be carried inside the RTP packets, the endpoints can then use that information to associate received RTP packets with the correct m- line. However, an offerer will not know which SSRC values the answerer will use until it has received the SDP Answer providing that information. Due to this, before the offerer has received the SDP Answer, it will not be able to associate received RTP packets with the correct m- line using the SSRC values.

In order for endpoints to always be able to associate received RTP packets with the correct m- line they MUST, in SDP Offers and Answers, assign an SDP "receiver-id" attribute [receiver-id-reference-to-be-added] to each m- line which contains a payload type value that is also used inside another m- line within the BUNDLE group. If an endpoint accepts a BUNDLE group, it MUST insert the "receiver-id" value in the associated RTP packets, associated with the BUNDLE group, sent towards the remote endpoint, as described in [receiver-id-reference-to-be-added]. If the endpoint cannot, or is not willing to, insert the "receiver-id" value in sent RTP packets, it MUST NOT accept the BUNDLE group.

Editor's note: [receiver-id-reference-to-be-added] will describe in how many RTP packets the receiver-id value will be sent.

---

From: Justin Uberti <[email-masked]>
Date: Tue, 11 Mar 2014 21:43:35 -0700

As I understand it, the 'receiver-id' will not identify a BUNDLE group, but
rather a m= section or packet stream.

On Tue, Mar 11, 2014 at 1:56 AM, Christer Holmberg <
[email-masked]> wrote:

>  Hi,
>
>
>
> Based on the discussion/decision in London, I’ve drafted the following
> text regarding the usage of identical PT values, and the usage of the
> “receiver-id” value in order to be able to associate received RTP packets
> with the correct m- line (when the same payload type value is used inside
> multiple m- lines within the BUNDLE group).
>
>
>
> I may change some words later, in order to align with the rest of the
> document, but please take a look and see whether you are ok with the
> content, and whether you think it reflects the decisions in the meeting.
>
>  Regards,
>
>
>
> Christer
>
>
>
> A BUNDLE group can contain multiple m- lines associated with RTP media. As
> all RTP media associated with those m- lines belong to the same RTP session
> [insert-reference], in order for a payload type value to used inside more
> than one m- line, all codecs associated with the payload type numbers MUST
> share an identical codec configuration. This means that the codecs MUST
> share the same media type, encoding name, clock rate and any parameter that
> can affect the codec configuration and packetizsation. [ID.draft-ietf-mmusic-sdp-mux-attributes]
> lists SDP attribute values that must be identical for all codecs using the
> same payload type value.
>
>
>
> In general, there are multiple mechanisms that can be used by an endpoint
> in order to associate received RTP packets with the m- line associated with
> the RTP packets. Such mechanisms include using the local address:port on
> which the RTP packets are received, the payload type value carried inside
> the RTP packets, the SSRC values carried inside the RTP packets, and other
> m- line specific information carried inside the RTP packets.
>
>
>
> Within a BUNDLE group, as all RTP packets are transported using the same
> 5-tuple, the local address:port cannot be used to associate received RTP
> packets with the correct m- line.
>
>
>
> As described in section X.X.1, the same payload type value might be used
> inside RTP packets associated with multiple m- lines. In such cases, the
> payload type value cannot be used to associate received RTP packets with
> the correct m- line.
>
>
>
> Endpoints can inform each other which SSRC values they will use inside
> sent RTP packets by, in SDP Offers and Answers, assigning an SDP ‘ssrc’
> attribute [ref-to-be-added] to each m- line which contains a payload type
> value that is also used inside another m- line within the BUNDLE group. As
> the SSRC values will be carried inside the RTP packets, the endpoints can
> then use that information to associate received RTP packets with the
> correct m- line. However, an offerer will not know which SSRC values the
> answerer will use until it has received the SDP Answer providing that
> information. Due to this, before the offerer has received the SDP Answer,
> it will not be able to associate received RTP packets with the correct m-
> line using the SSRC values.
>
>
>
> In order for endpoints to always be able to associate received RTP packets
> with the correct m- line they MUST, in SDP Offers and Answers, assign an
> SDP “receiver-id” attribute [receiver-id-reference-to-be-added] to each m-
> line which contains a payload type value that is also used inside another
> m- line within the BUNDLE group. If an endpoint accepts a BUNDLE group, it
> MUST insert the “receiver-id” value in the associated RTP packets,
> associated with the BUNDLE group, sent towards the remote endpoint, as
> described in [receiver-id-reference-to-be-added]. If the endpoint cannot,
> or is not willing to, insert the “receiver-id” value in sent RTP packets,
> it MUST NOT accept the BUNDLE group.
>
>
>
> Editor’s note: [receiver-id-reference-to-be-added] will describe in how
> many RTP packets the receiver-id value will be sent.
>
>
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Mar 2014 07:55:06 +0000

Hi Justin,

>As I understand it, the 'receiver-id' will not identify a BUNDLE group, but rather a m= section or packet stream.

Correct. 

Do you think the text indicates otherwise?

Regards,

Christer

On Tue, Mar 11, 2014 at 1:56 AM, Christer Holmberg <[email-masked]> wrote:
Hi,
 
Based on the discussion/decision in London, I’ve drafted the following text regarding the usage of identical PT values, and the usage of the “receiver-id” value in order to be able to associate received RTP packets with the correct m- line (when the same payload type value is used inside multiple m- lines within the BUNDLE group).

Christer

X.X         RTP Considerations

 

 
 
Endpoints can inform each other which SSRC values they will use inside sent RTP packets by, in SDP Offers and Answers, assigning an SDP ‘ssrc’ attribute [ref-to-be-added] to each m- line which contains a payload type value that is also used inside another m- line within the BUNDLE group. As the SSRC values will be carried inside the RTP packets, the endpoints can then use that information to associate received RTP packets with the correct m- line. However, an offerer will not know which SSRC values the answerer will use until it has received the SDP Answer providing that information. Due to this, before the offerer has received the SDP Answer, it will not be able to associate received RTP packets with the correct m- line using the SSRC values.
 
In order for endpoints to always be able to associate received RTP packets with the correct m- line they MUST, in SDP Offers and Answers, assign an SDP “receiver-id” attribute [receiver-id-reference-to-be-added] to each m- line which contains a payload type value that is also used inside another m- line within the BUNDLE group. If an endpoint accepts a BUNDLE group, it MUST insert the “receiver-id” value in the associated RTP packets, associated with the BUNDLE group, sent towards the remote endpoint, as described in [receiver-id-reference-to-be-added]. If the endpoint cannot, or is not willing to, insert the “receiver-id” value in sent RTP packets, it MUST NOT accept the BUNDLE group.
 
Editor’s note: [receiver-id-reference-to-be-added] will describe in how many RTP packets the receiver-id value will be sent.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 12 Mar 2014 09:19:36 -0700

On Wed, Mar 12, 2014 at 12:55 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi Justin,
>
> >As I understand it, the 'receiver-id' will not identify a BUNDLE group,
> but rather a m= section or packet stream.
>
> Correct.
>

>From the text below, it appears that the receiver-id is associated with a
BUNDLE group.

*If an endpoint accepts a BUNDLE group, it MUST insert the “receiver-id”
value in the associated RTP packets, associated with the BUNDLE group, sent
towards the remote endpoint, as described in
[receiver-id-reference-to-be-added]. *

Since the receiver-id mechanism is independent of BUNDLE, it's not clear to
me that BUNDLE needs to say anything about this, other than that the
receiver-id mechanism MUST be used.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 13 Mar 2014 13:08:43 +0000

Hi Justin,

>From the text below, it appears that the receiver-id is associated with a BUNDLE group.
>
>If an endpoint accepts a BUNDLE group, it MUST insert the “receiver-id” value in the associated RTP packets, associated with the BUNDLE group, sent towards the remote endpoint, as described in [receiver-id-reference-to-be-added]. 
>
>Since the receiver-id mechanism is independent of BUNDLE, it's not clear to me that BUNDLE needs to say anything about this, other than that the receiver-id mechanism MUST be used.

Well, it MUST only be used with RTP packets associated with m- lines within a BUNDLE group. If an m- line is not within a BUNDLE group, I don't think BUNDLE needs to mandate usage of the receiver-id mechanism for RTP packets associated with that m- line.

But, I agree the text you referred to is a little unclear, so I'll try to improve it.

Regards,

Christer