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

[Christer Holmberg <[e-mail]>]

Hi,

>> Agree with Emil that "default" makes more sense for use of PT for mapping to an m line. If a=SSRC is specified on an m line then that should take precedence over PT.
>
> I don't think "takes precedence" is quite the right way to think about it.
>
> You support some number of mechanisms: PT only, or PT & SSRC, or ...
>
> For the set of mechanisms you support, for each m-line you have some values for some of the mechanisms. When you receive a packet, attempt to match it 
> to each m-line based on the the values it contains and those specified for each m-line. If a packet matches more than one m-line, then choose the m-line '
> that matches the most values. If that still matches multiple m-lines, then there is an error.
>
> You can statically analyze an offer and a candidate answer and determine if there can be any non-unique matches. If so, then you should not send 
> that answer. Instead, send one that is more unique, or else reject some of the m-lines, or refuse to bundle some of them.
>
> You can also statically analyze the O/A and determine a precedence for applying the mechanisms that minimizes the checking required for doing the matching. 
> When using PT & SSRC, depending on the details it may be favorable to check one or the other first.

I don't think we should specify which mechanism "takes precedence". My suggestion is to define the "default" one, and then people can use whatever other mechanisms if they want. One question is whether we should even mention other mechanisms.

(If BUNDLE would, for RTP, mandate the usage of a=ssrc, we could of course also specify that as "default", but currently BUNDLE does not mandate the usage of a=ssrc).

Regards,

Christer




> On Jun 25, 2013, at 10:03 AM, "Emil Ivov" <[e-mail]> wrote:
>
>>
>>
>> On 25.06.13, 13:34, Christer Holmberg wrote:
>>> Hi,
>>>
>>> Emil suggested that the default, “MTI”, mechanism for mapping RTP 
>>> data to m- lines should be based on PT.
>>
>> Actually, what I thought was important was having it as the "default" mechanism. Personally I don't mind having it as MTI might but it might be a tad too strong: implementations that deem PT demux insufficient and wouldn't want to use bundle without it, don't need implement it.
>>
>> We should probably also agree on how an answerer can determine whether or not it is expected to provide additional demuxing information (e.g. SSRCs) or if the offerer is using the default mechanism.
>>
>> One way would be for the answerer to inspect all m= lines and try to detect duplicating PTs. This could be a bit clumsy though. The offerer could expect SSRCs but its first offer may not yet contain PT reuse.
>>
>> With that in mind ... (more below)
>>
>>> 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 am in favour of having a "default" one.
>>
>> Without this BUNDLE would have to be an abstract spec and I don't see why we would want to leave it that way.
>>
>>> *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?
>>
>> In favour.
>>
>> Cheers,
>> Emil
>>
>>>
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>> --
>> https://jitsi.org
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>

_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic