Subject: [MMUSIC] IETF#89: BUNDLE: Q9: What are the criteria for allowing usage of the same PT value within multiple m- lines?

From: Christer Holmberg <[email-masked]>
Date: Sun, 2 Mar 2014 08:44:45 +0000

Hi,

One of the open issues we have in BUNDLE, is when it is allowed to use the same PT value within multiple m- lines.

We tried to come up with different criteria, including a "codec configuration" concept, but we never managed to agree on something.

So, in London, I intend to suggest that we simply say: if you offer the same PT value within multiple m- line, make sure you can handle the associated media when it arrives - period (keep in mind that you always indicate what you want to RECEIVE - the remote peer can still ask you to SEND using different PT values).

If you don't like this, please provide an alternative solution, because I want to close this issue in London. There is no idea to keep "taking the issue back to the list". We've done that for a few meetings already.

Regards,

Christer

---

From: Suhas Nandakumar <[email-masked]>
Date: Sun, 2 Mar 2014 10:34:06 +0000

+1 on closing this action item

I support either a clearly specified codec configuration definition or
something on the lines above

Cheers
Suhas

On Sunday, March 2, 2014, Christer Holmberg <[email-masked]>
wrote:

> We tried to come up with different criteria, including a "codec
> configuration" concept, but we never managed to agree on something.
>
>
>
> So, in London, I intend to suggest that we simply say: if you offer the
> same PT value within multiple m- line, make sure you can handle the
> associated media when it arrives - period (keep in mind that you always
> indicate what you want to RECEIVE - the remote peer can still ask you to
> SEND using different PT values).
>
>
>
> If you don't like this, please provide an alternative solution, because I
> want to close this issue in London. There is no idea to keep "taking the
> issue back to the list". We've done that for a few meetings already.
>
>
>
> Regards,
>
>
>
> Christer
>

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 2 Mar 2014 13:18:05 +0000

And, as we don't have any text for a clearly specified codec configuration, the choice is easy :)

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Suhas Nandakumar <[email-masked]> wrote:

I support either a clearly specified codec configuration definition or something on the lines above

Cheers
Suhas

On Sunday, March 2, 2014, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

We tried to come up with different criteria, including a “codec configuration” concept, but we never managed to agree on something.

So, in London, I intend to suggest that we simply say: if you offer the same PT value within multiple m- line, make sure you can handle the associated media when it arrives – period (keep in mind that you always indicate what you want to RECEIVE – the remote peer can still ask you to SEND using different PT values).

If you don’t like this, please provide an alternative solution, because I want to close this issue in London. There is no idea to keep “taking the issue back to the list”. We’ve done that for a few meetings already.

Regards,

Christer

---

From: Colin Perkins <[email-masked]>
Date: Mon, 3 Mar 2014 09:33:34 +0000

Christer,

The bundled m= lines form a single RTP session. That means that they share a single RTP payload number space. The rule therefore has to be that you can only reuse the payload type across bundled m= lines if it refers to the exact same configuration of the exact same codec in all cases, where “exact same configuration” means that the a=fmtp: line and all other SDP attributes that configure the codec and packetisation of the media are identical.

If that’s not specific enough, then MUST NOT reuse payload types across m= lines in a bundled group is the safe choice. I believe your propose that it’s okay if you can handle the media is too vague, and will cause us problems down the line.

Colin

On 2 Mar 2014, at 08:44, Christer Holmberg <[email-masked]> wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
Colin Perkins
http://csperkins.org/

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Mar 2014 10:08:19 +0000

Hi Colin,

We tried to define "codec configuration", but we never got text that people could agree to.

Personally I don't have any strong opinion which way we go (personally I am also ok forbidding re-usage of the same PT value). I just want to close the issue, and not once again "take it to the list".

Regards,

Christer

From: Colin Perkins [mailto:[email-masked]]
Sent: 03 March 2014 11:34
To: Christer Holmberg
Cc: [email-masked]
Subject: Re: [MMUSIC] IETF#89: BUNDLE: Q9: What are the criteria for allowing usage of the same PT value within multiple m- lines?

Christer,

The bundled m= lines form a single RTP session. That means that they share a single RTP payload number space. The rule therefore has to be that you can only reuse the payload type across bundled m= lines if it refers to the exact same configuration of the exact same codec in all cases, where "exact same configuration" means that the a=fmtp: line and all other SDP attributes that configure the codec and packetisation of the media are identical.

If that's not specific enough, then MUST NOT reuse payload types across m= lines in a bundled group is the safe choice. I believe your propose that it's okay if you can handle the media is too vague, and will cause us problems down the line.

Colin

On 2 Mar 2014, at 08:44, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

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

--
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Mon, 3 Mar 2014 10:20:36 +0000

Hi,

I did suggest a definition of “codec configuration” in my message. If that’s not acceptable, then I suggest forbidding payload number reuse across m= lines.

Colin

On 3 Mar 2014, at 10:08, Christer Holmberg <[email-masked]> wrote:
> Hi Colin,
>  
> We tried to define “codec configuration”, but we never got text that people could agree to.
>  
> Personally I don’t have any strong opinion which way we go (personally I am also ok forbidding re-usage of the same PT value). I just want to close the issue, and not once again “take it to the list”.
>  
> Regards,
>  
> Christer
>  

-- 
Colin Perkins
http://csperkins.org/

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Mar 2014 10:26:33 +0000

Hi,

>I did suggest a definition of "codec configuration" in my message. If that's not acceptable, then I >suggest forbidding payload number reuse across m= lines.

I was also told off-line that, in order to distinguish multiple media using the same PT value, the SSRC values that are going to be used needs to be signalled.

However, when the initial offer is sent, the offerer does not know what the answerer supports.

Regards,

Christer

On 3 Mar 2014, at 10:08, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi Colin,

Regards,

Christer

From: Colin Perkins [mailto:[email-masked]]
Sent: 03 March 2014 11:34
To: Christer Holmberg
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] IETF#89: BUNDLE: Q9: What are the criteria for allowing usage of the same PT value within multiple m- lines?

Christer,

Colin

Regards,

Christer

--
Colin Perkins
http://csperkins.org/

--
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Mon, 3 Mar 2014 10:36:24 +0000

On 3 Mar 2014, at 10:26, Christer Holmberg <[email-masked]> wrote:
> Hi,
>  
> >I did suggest a definition of “codec configuration” in my message. If that’s not acceptable, then I >suggest forbidding payload number reuse across m= lines.
>  

I don’t think the method works with RTP. The payload type number space is per RTP session, not per SSRC.

Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Mar 2014 10:48:42 +0000

Hi Colin,

Within an RTP session, if you receive two media streams, both using the same PT value (let's assume they use the same codec configuration), how will you separate the received media packets?

Regards,

Christer

From: Colin Perkins [mailto:[email-masked]]
Sent: 03 March 2014 12:36
To: Christer Holmberg
Cc: [email-masked]
Subject: Re: [MMUSIC] IETF#89: BUNDLE: Q9: What are the criteria for allowing usage of the same PT value within multiple m- lines?

On 3 Mar 2014, at 10:26, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

I don't think the method works with RTP. The payload type number space is per RTP session, not per SSRC.

Colin

Regards,

Christer

Regards,

Christer

Christer,

Colin

Regards,

Christer

--
Colin Perkins
http://csperkins.org/

--
Colin Perkins
http://csperkins.org/

--
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Mon, 3 Mar 2014 10:58:05 +0000

Christer,

The same way you separate every other stream: SSRC to identify the media source, then direct to the right decoder path based on the PT mapping table. 

Colin

On 3 Mar 2014, at 10:48, Christer Holmberg <[email-masked]> wrote:

> Hi Colin,
>  
> Within an RTP session, if you receive two media streams, both using the same PT value (let’s assume they use the same codec configuration), how will you separate the received media packets?
>  
> Regards,
>  
> Christer
>  

-- 
Colin Perkins
http://csperkins.org/

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Mar 2014 11:00:12 +0000

Hi,

>The same way you separate every other stream: SSRC to identify the media source, then direct to >the right decoder path based on the PT mapping table.

Yes, but then you need to know which SSRC(s) are going to be used for each media stream.

Regards,

Christer

On 3 Mar 2014, at 10:48, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi Colin,

Regards,

Christer

Colin

Regards,

Christer

Regards,

Christer

Christer,

Colin

Regards,

Christer

--
Colin Perkins
http://csperkins.org/

--
Colin Perkins
http://csperkins.org/

--
Colin Perkins
http://csperkins.org/

--
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Mon, 3 Mar 2014 11:01:36 +0000

> Yes, but then you need to know which SSRC(s) are going to be used for each media stream.

Huh? You may have to explain, because I don’t see that.

-- 
Colin Perkins
http://csperkins.org/

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Mar 2014 11:05:55 +0000

Hi,

Huh? You may have to explain, because I don't see that.

Assume you have two video m- lines.
On both m- lines, you indicate that you can receive a codec using PT value Y.
Then, you receive a video media packet, with PT value Y, and SSRC value 1234567. How do you know which of the two m- lines this media packet is associated with?
Regards,
Christer

--
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Mon, 3 Mar 2014 11:11:46 +0000

> Then, you receive a video media packet, with PT value Y, and SSRC value 1234567. How do you know which of the two m- lines this media packet is associated with?

We’ve discussed this multiple times before. If payload types numbers are unique across m= lines, then obviously you can use them to identify the m= line. If you reuse payload type values across m= lines, then you need some other way of identifying m= lines, if you care about doing so. Signalled SSRC values are one approach, something like AppID might be another.  

-- 
Colin Perkins
http://csperkins.org/

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Mar 2014 11:13:48 +0000

Hi,
Assume you have two video m- lines.
On both m- lines, you indicate that you can receive a codec using PT value Y.
Then, you receive a video media packet, with PT value Y, and SSRC value 1234567. How do you know which of the two m- lines this media packet is associated with?
We've discussed this multiple times before. If payload types numbers are unique across m= lines, then obviously you can use them to identify the m= line. If you reuse payload type values across m= lines, then you need some other way of identifying m= lines, if you care about doing so. Signalled SSRC values are one approach, something like AppID might be another.

...which takes us back to what I said in the beginning: when you send your initial offer, and assign the PT values you want to receive, you don't know whether the remote peer supports AppID, or whatever other mechanism that could be used.

Regards,

Christer

---

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 3 Mar 2014 11:14:44 +0000

On Monday, March 3, 2014, Colin Perkins <[email-masked]> wrote:

> On 3 Mar 2014, at 11:05, Christer Holmberg <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> wrote:
>
>  Hi,
>
>  >The same way you separate every other stream: SSRC to identify the
> media source, then direct to >the right decoder path based on the PT
> mapping table.
>
>
>
> Then, you receive a video media packet, with PT value Y, and SSRC value
> 1234567. How do you know which of the two m- lines this media packet is
> associated with?
>
> We've discussed this multiple times before. If payload types numbers are
> unique across m= lines, then obviously you can use them to identify the m=
> line. If you reuse payload type values across m= lines, then you need some
> other way of identifying m= lines, if you care about doing so. Signalled
> SSRC values are one approach, something like AppID might be another.
>
>
I agree with Colin. There needs to be a way to correlate incoming rtp
streams in this scenario and early media scenario

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 3 Mar 2014 11:14:51 +0000

On Mar 3, 2014, at 9:33 AM, Colin Perkins <[email-masked]<mailto:[email-masked]>> wrote:

Christer,

I agree with this, with the addition that "all other SDP attributes that configure the codec and packetisation of the media” is something that we’re going to need to specify in draft-ietf-mmusic-sdp-mux-attributes.

There will need to be a new category in that draft, to indicate which SDP attributes that specify configuration on a per-PT basis need to be IDENTICAL-PER-PT.

Colin

Regards,

Christer

--
Colin Perkins
http://csperkins.org/

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Mar 2014 11:17:38 +0000

Hi,

I agree with Colin. There needs to be a way to correlate incoming rtp streams in this scenario and early media scenario

I agree. The question is: when you send the first offer, and assign the PT values you want to receive, how do you know whether the remote peer supports "a way"?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 03 Mar 2014 14:05:03 +0000

The general case is that when the sender is sending a packet, it must 
have *one* particular m-line in the bundle that it intends the packet to 
be associated with. When the receiver receives a packet, it must, based 
on info received in the packet, or prior packets, be able associate the 
packet with *one* particular m-line. It is an error if the sender don't 
agree on which m-line is intended.

(There is an exception for RTCP, which doesn't have to be associated 
with particular m-lines.)

My thought has been that the O/A should only succeed if there is 
agreement between the two sides about how to classify packets, 
sufficient to ensure that all packets will be consistently classified.

	Thanks,
	Paul

On 3/3/14 9:33 AM, Colin Perkins wrote:
> Christer,
>
> The bundled m= lines form a single RTP session. That means that they
> share a single RTP payload number space. The rule therefore has to be
> that you can only reuse the payload type across bundled m= lines if it
> refers to the exact same configuration of the exact same codec in all
> cases, where “exact same configuration” means that the a=fmtp: line and
> all other SDP attributes that configure the codec and packetisation of
> the media are identical.
>
> If that’s not specific enough, then MUST NOT reuse payload types across
> m= lines in a bundled group is the safe choice. I believe your propose
> that it’s okay if you can handle the media is too vague, and will cause
> us problems down the line.
>
> Colin
>
>
>
>
> On 2 Mar 2014, at 08:44, Christer Holmberg
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>>
>> Hi,
>>
>> One of the open issues we have in BUNDLE, is when it is allowed to use
>> the same PT value within multiple m- lines.
>>
>> We tried to come up with different criteria, including a “codec
>> configuration” concept, but we never managed to agree on something.
>>
>> So, in London, I intend to suggest that we simply say: if you offer
>> the same PT value within multiple m- line, make sure you can handle
>> the associated media when it arrives – period (keep in mind that you
>> always indicate what you want to RECEIVE – the remote peer can still
>> ask you to SEND using different PT values).
>>
>> If you don’t like this, please provide an alternative solution,
>> because I want to close this issue in London. There is no idea to keep
>> “taking the issue back to the list”. We’ve done that for a few
>> meetings already.
>>
>> Regards,
>>
>> Christer
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Mar 2014 14:30:56 +0000

Hi,

>The general case is that when the sender is sending a packet, it must have *one* particular m-line in >the bundle that it intends the packet to be associated with. When the receiver receives a packet, it >must, based on info received in the packet, or prior packets, be able associate the packet with >*one* particular m-line. It is an error if the sender don't agree on which m-line is intended.
>
>(There is an exception for RTCP, which doesn't have to be associated with particular m-lines.)
>
>My thought has been that the O/A should only succeed if there is agreement between the two sides >about how to classify packets, sufficient to ensure that all packets will be consistently classified.

So, do you agree with the following: if the offerer wants to use the same PT value, but the answerer does not provide whatever information (SSRC, AppID...) that is needed for the offerer to associate a received packet with an m- line, the offerer should either send a new offer (with unique PT values), or terminate the session?

Regards,

Christer