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

[Christer Holmberg <[e-mail]>]

Hi Colin,

>> 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?
>
> I think the BUNDLE specification needs to define how RTP flows can be associated with m= lines, but ought not mandate that applications 
> do so. The document that describes how WebRTC uses BUNDLE might want to mandate that WebRTC applications use the mechanism. 

Note that there is a separate discussion, BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?, on whether BUNDLE shall mandate that the receiver must always be able to map received data to an m- line.

So far only Paul has commented on that discussion, but I assume it's just a question of hours before your input will be posted? :)

>> 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?
>
> I think we should specify how the combination of PT values and a=ssrc: lines can be used to associate RTP data with m= lines, for applications that want to do so. 
>
> I don't think just using PT values is sufficient, since the PT space is small (I can imagine applications that want to send lots of flows using 
> the same codec configuration, and it's more natural to give them all the same PT and use a=ssrc: lines to distinguish).

If you run out of PTs, and have to re-use the same PT in multiple m- lines (for the same codec configuration, though), you will obviously need something else for mapping RTP to m- lines, and we should probably state that.

But, my take from your reply is that you don't think we should specify a default mechanism. We CAN describe different mechanisms (PT, PT+SSRC etc), but it would be up to applications to decide what to use. Correct?

Regards,

Christer