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

On Mar 3, 2014, at 9:33 AM, Colin Perkins <csp@csperkins.org<mailto:csp@csperkins.org>> 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.

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.

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<mailto: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<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic

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

_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic