Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT?

I guess if you want to call this a "default" MTI mechanism *for RTP*, 
then I won't object. But doing so is mostly stating the obvious.

The reason it can be the default is because there is no way to have an 
RTP m-line without a PT. So if you are bundling RTP m-lines, then you 
have PT available on every m-line to use for associating packets with 
m-lines.

But that is only sufficient if a given PT only appears on a single 
m-line. Its also insufficient if there are non-RTP m-lines.

If you choose to have non-RTP m-lines in the bundle, or multiple RTP 
m-lines with the same PT, then you are obligated to support some other 
mechanism, and for it to be signaled in such a way that both sides will 
understand what it is.

	Thanks,
	Paul

On 6/25/13 7:34 AM, Christer Holmberg wrote:
> Hi,
>
> Emil suggested that the default, “MTI”, mechanism for mapping RTP data
> to m- lines should be based on PT. Applications are allowed to use
> whatever other mechanisms, but usage of such mechanisms must be
> negotiated (or, applications need to have some other means knowing that
> the other endpoint support such mechanisms).
>
> *Q3*: Do we need to specify a default, MTI, mechanism for mapping RTP
> data to m- lines?
>
> *Q4*: If Q3, do we mandate applications to support, and use (unless
> applications are made aware of other mechanisms supported by all
> endpoints) PT for mapping received RTP media?
>
> This means that, when mapping RTP to m- lines is required (whether it is
> always mandated is discussed in another thread), within a BUNDLE group
> each PT value must be unique to an individual m- line.
>
> NOTE: If your answer to Q3 is “yes”, but your answer to Q4 is “no”,
> please indicate which mechanism you prefer J
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>