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

Hi,

> I guess if you want to call this a "default" MTI mechanism *for RTP*, then I won't object.

Yes, I should have clarified that it was for RTP.

> But doing so is mostly stating the obvious.

We should be careful to make such assumptions :)

> 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. 

Correct, and I think it is good to point that out, eventhough it may seem obvious to many.

> 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.

The mechanism to find the right "type" of m- line is a separate issue :)

Regards,

Christer

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
>

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