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

On 25 Jun 2013, at 12:34, 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?

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. 

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

> 

> 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

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