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

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 <christer.holmberg@ericsson.com> 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
>  
> From: Colin Perkins [mailto:csp@csperkins.org] 
> Sent: 03 March 2014 12:36
> To: Christer Holmberg
> Cc: mmusic@ietf.org
> 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 <christer.holmberg@ericsson.com> 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 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.
>  
> I don’t think the method works with RTP. The payload type number space is per RTP session, not per SSRC.
>  
> Colin
>  
>  
> 
> 
> 
> 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 <christer.holmberg@ericsson.com> 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
>  
> From: Colin Perkins [mailto:csp@csperkins.org] 
> Sent: 03 March 2014 11:34
> To: Christer Holmberg
> Cc: mmusic@ietf.org
> 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 <christer.holmberg@ericsson.com> 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
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>  
>  
> 
> -- 
> Colin Perkins
> http://csperkins.org/
>  
>  
>  
>  
>  
> 
> -- 
> Colin Perkins
> http://csperkins.org/
>  
>  
>  
>  
>  
> 
> -- 
> Colin Perkins
> http://csperkins.org/
>  
>  
>  

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