Subject: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Jun 2013 11:25:29 +0000

Hi,

In Q1, I asked whether we can agree that a PT value can only be used for a single codec configuration. Eventhough the question is still open, the feedback received so far seem to indicate that people agree to that.

We have also discussed whether it should, within a BUNDLE group, be allowed to use the same PT value in multiple m- lines - if used for the same codec configuration. I will now put forward a question on that :)

Q7: Within a BUNDLE group, do we allow the usage of the same PT value in multiple RTP m- lines, for the SAME codec configuration?

Note: This of course prevents the mapping to m- line purely based on PT, and based on the outcome of that discussion we may have to add restrictions on when the same PT value can be used etc. But, this question is whether we generally want to allow the usage of the same PT value in multiple m- lines :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Jun 2013 11:42:19 -0400

On 6/28/13 7:25 AM, Christer Holmberg wrote:
> Hi,
>
> In Q1, I asked whether we can agree that a PT value can only be used for
> a single codec configuration. Eventhough the question is still open, the
> feedback received so far seem to indicate that people agree to that.
>
> We have also discussed whether it should, within a BUNDLE group, be
> allowed to use the *same PT value in multiple m- lines* – if used for
> the same codec configuration. I will now put forward a question on that :)
>
> *Q7*: Within a BUNDLE group, do we allow the usage of the same PT value
> in multiple RTP m- lines, for the SAME codec configuration?

Q7: YES

But it may be necessary to clarify both Q1 and Q7:

This technically applies to a SDP offer or answer. While the values are 
normally preserved between offer and answer, that isn't required.

Also, PTs can change in a subsequent O/A, though it could be disruptive 
if they do, and I have never seen any discussion of how the transition 
is to be handled.

	Thanks,
	Paul

> Note: This of course prevents the mapping to m- line purely based on PT,
> and based on the outcome of that discussion we may have to add
> restrictions on when the same PT value can be used etc. But, this
> question is whether we *generally* want to allow the usage of the same
> PT value in multiple m- lines :)
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Emil Ivov <[email-masked]>
Date: Fri, 28 Jun 2013 18:41:44 +0200

On Fri, Jun 28, 2013 at 1:25 PM, Christer Holmberg
<[email-masked]> wrote:

> Q7: Within a BUNDLE group, do we allow the usage of the same PT value in
> multiple RTP m- lines, for the SAME codec configuration?

Generally yes.

> Note: This of course prevents the mapping to m- line purely based on PT,

You mean, only in case its actually used and not as a general BUNDLE
rule, right?

Emil

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Jun 2013 12:57:19 -0400

> You mean, only in case its actually used and not as a general BUNDLE

I'm not sure I understand the distinction you are drawing.

The point is that when a packet with this PT is received, you won't be 
able to use the PT to determine which m-line in the bundle the packet 
should be associated with.

There must have been *some* reason that two m-lines were used, with the 
same PT, rather than just one. Each m-line heads a media section of the 
SDP that contains a bunch of declarations. Some of those are part of the 
payload description and so are the same. Something else must be 
different in those two media sections, or else a single media section 
would have been enough. Presumably whatever it is that is different is 
intended to affect how received packets are processed or interpreted. If 
you can't associate the packet with the m-line, then you don't know 
which of the multiple interpretations to apply to the packet.

	Thanks,
	Paul

---

From: Emil Ivov <[email-masked]>
Date: Fri, 28 Jun 2013 22:12:14 +0200

Hey Paul,

> I'm not sure I understand the distinction you are drawing.

What I meant was that if one doesn't reuse PTs on multiple m- lines in 
the SDP, they could continue relying solely on PT for demuxing.

Or in other words, I wanted to confirm that we weren't about to make an 
alternative demuxing mechanism mandatory for use of BUNDLE.

Emil

-- 
https://jitsi.org

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Jun 2013 17:01:15 -0400

> the SDP, they could continue relying solely on PT for demuxing.

Yes, I intend that to be true. Christer and I are only talking about the 
situation when the same PT *is* used on multiple m-lines.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Jun 2013 22:07:21 +0000

Hi,

>> In Q1, I asked whether we can agree that a PT value can only be used 
>> for a single codec configuration. Eventhough the question is still 
>> open, the feedback received so far seem to indicate that people agree to that.
>>
>> allowed to use the *same PT value in multiple m- lines* - if used for 
>> *Q7*: Within a BUNDLE group, do we allow the usage of the same PT 
>> value in multiple RTP m- lines, for the SAME codec configuration?
>
> Q7: YES
>
> This technically applies to a SDP offer or answer. While the values are normally preserved between offer and answer, that isn't required.

Correct.

> Also, PTs can change in a subsequent O/A, 

Correct.

So, to clarify, I am referring to any given Offer, or any given Answer.

> though it could be disruptive if they do, and I have never seen any discussion of how the transition is to be handled.

True. But, that is not BUNDLE specific, is it?

Regards,

Chrsiter

> Note: This of course prevents the mapping to m- line purely based on 
> PT, and based on the outcome of that discussion we may have to add

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Jun 2013 22:11:11 +0000

Hi,

>> Q7: Within a BUNDLE group, do we allow the usage of the same PT value 
>> PT,
> You mean, only in case its actually used and not as a general BUNDLE rule, right?

I mean what I said: this of course prevents the mapping to m- line purely based on PT.

Whether mapping based on PT is going to de defined as a "default" rule, and/or whether we are going to mandate entities to always be able to map to m- line, is part of another discussion :)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Jun 2013 22:17:30 +0000

Hi,

>>>>> Q7: Within a BUNDLE group, do we allow the usage of the same PT 
> Yes, I intend that to be true. Christer and I are only talking about the situation when the same PT *is* used on multiple m-lines.

Correct.

> Or in other words, I wanted to confirm that we weren't about to make an alternative demuxing mechanism mandatory for use of BUNDLE.

We are still discussing whether we are going to have a mandatory RTP demuxing mechanism to begin with (Q3), and, if so, what mechanism it should be (Q4) :)

Regards,

Christer

> Or in other words, I wanted to confirm that we weren't about to make 
> an alternative demuxing mechanism mandatory for use of BUNDLE.
>
> Emil
>
>

---

From: "Roni Even" <[email-masked]>
Date: Sat, 29 Jun 2013 10:30:19 +0300

Q7:

I am not sure how you define the same configuration. Do you mean that all
the attributes are the same so the m-lines are identical.

For example same a=imageattr or b= a=content and so on. In this case I do
not understand the use case for it. 

I see no problem if each of the m-line will have an a=ssrc to define the RTP
stream but if not the mapping will be problematic. 

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christer Holmberg
Sent: 28 June, 2013 2:25 PM
To: [email-masked]
Subject: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for
SAME codec configuration

Hi,

In Q1, I asked whether we can agree that a PT value can only be used for a
single codec configuration. Eventhough the question is still open, the
feedback received so far seem to indicate that people agree to that.

We have also discussed whether it should, within a BUNDLE group, be allowed
to use the same PT value in multiple m- lines - if used for the same codec
configuration. I will now put forward a question on that :)

Note: This of course prevents the mapping to m- line purely based on PT, and
based on the outcome of that discussion we may have to add restrictions on
when the same PT value can be used etc. But, this question is whether we
generally want to allow the usage of the same PT value in multiple m- lines
:)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 29 Jun 2013 07:44:50 +0000

Hi,

> Q7:
>I am not sure how you define the same configuration. Do you mean that all the attributes are the same so the m-lines are identical.

Something like that - this is the opportunity for you media plane people to be creative and come up with good wording :)

>For example same a=imageattr or b= a=content and so on. In this case I do not understand the use case for it.
>I see no problem if each of the m-line will have an a=ssrc to define the RTP stream but if not the mapping will be problematic.

Are you saying that, if a=ssrc is used, PT value X could be used for DIFFERENT codec configurations? If so, you should answer "no" to Q1 :)

Regards,

Christer

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 28 June, 2013 2:25 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration

Hi,

Regards,

Christer

---

From: "Roni Even" <[email-masked]>
Date: Sat, 29 Jun 2013 13:44:36 +0300

Hi Christer,

I am not sure how to answer this question without knowing what is the
multiplexing decision.

If we multiplex only based on PT than unique PT numbers are needed and the
answer to Q7 is NO

If we are using a combination of PT and SSRC for multiplexing we should
recommend using unique PT but allow non-unique if can be identified in an
m-line or multiple BUNDLED m-line (single RTP session) based on SSRC

Roni

From: Christer Holmberg [mailto:[email-masked]] 
Sent: 29 June, 2013 10:45 AM
To: Roni Even; [email-masked]
Subject: VS: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines
for SAME codec configuration

Hi,

Something like that - this is the opportunity for you media plane people to
be creative and come up with good wording :)

>I see no problem if each of the m-line will have an a=ssrc to define the
RTP stream but if not the mapping will be problematic. 

Are you saying that, if a=ssrc is used, PT value X could be used for
DIFFERENT codec configurations? If so, you should answer "no" to Q1 :)

Regards,

Christer

Hi,

 

Regards,

Christer

---

From: "Roni Even" <[email-masked]>
Date: Sat, 29 Jun 2013 13:48:52 +0300

Hi,

Jonathan Lennox, Qin and I submitted a draft about mapping the PT from the
SDP m-line to the application semantics.

It allows for having the same PT numbers in different m-lines since each
m-line will have different application IDs that can be used to map to an
SSRC using RTCP SDES or RTP header extension.

Roni

Hi,

 

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 30 Jun 2013 17:01:27 +0000

Hi,

> Jonathan Lennox, Qin and I submitted a draft about mapping the PT from the SDP m-line to the application semantics.
> It allows for having the same PT numbers in different m-lines since each m-line will have different application IDs that can be used to map to an SSRC using RTCP SDES or RTP header extension.

And, the same PT numbers could, in different m- lines, even be used for different codecs/codec configurations?

Regards,

Christer

Hi,

Regards,

Christer