Re: [MMUSIC] Offer/Answer PT Questions - text proposal

[Roman Shpount <[e-mail]>]

On Wed, Mar 2, 2016 at 10:43 AM, Paul Kyzivat <[e-mail]> wrote:

> On 3/2/16 9:47 AM, Christer Holmberg wrote:
>
>> *If* it is really the case that there is no relationship between O/A and
>>> the lifetime of RTP sessions, then
>>> we have some work to do to sort out what the relationship is between
>>> what is in the O/A and what is in the RTP session.
>>>
>>> IIUC, in the case where the is no RTP session prior an offer, the O/A
>>> must at least establish some initial PT bindings for the session-to-be.
>>>
>>> (I have a feeling that what we are discussing is quite fundamental, and
>>> I find it shocking if it hasn't been considered in the past.)
>>>
>>
>> I still don't get it... :)
>>
>> When you negotiate an SDP session, unless you use BUNDLE, each m- line is
>> associated with a different RTP session. You negotiate what PT bindings you
>> are going to use within that SDP session.
>>
>> If some SDP properties change - due to a RTP session change or whatever
>> else - then a new O/A exchange is obviously needed. Nothing new about that.
>>
>> But, as has been indicated, the change of RTP session does not
>> automatically mandate new PT bindings, so I don't see why we need to
>> consider RTP sessions when we talk about PT bindings.
>>
>
> The problem is that we have two goals that in some cases seem to conflict.
>
> On one hand you want to manage O/A state. For the most part that includes
> the results of the most recent successful O/A exchange (the resulting local
> and remote SDP), and possibly another offer that is in progress. But based
> on 3264 it also seems to include, for each m-line, all the PT bindings ever
> made for the duration of this O/A session.
>
> OTOH, it seems to be necessary for the PT bindings for an m-line to be
> consistent with the PT bindings of the RTP session currently in effect for
> that m-line. If that RTP session can change arbitrarily, then it
> potentially can be replaced by one that is inconsistent with the PT
> bindings of the O/A session.
>
> Somehow that inconsistency needs to be resolved.
>

The problem is that if you have multiple O/A exchanges happening in rapid
succession, you can get RTP packets for any of the previous O/A exchanges.
This means you can have a new RTP session being set up for any of the
recent O/A exchanges. Unless you have an additional way to demultiplex,
such as using a different local transport, ssrc or mid, you will need to
map the received RTP packet to a particular O/A exchange. The only way left
is PT.

In reality this means you need to track last successful O/A, O/A in
progress, and all the successful O/A exchanges that completed recently for
which it is still possible to receive RTP packets. In most cases, O/A
exchange typically takes a lot longer then media flow setup, so that you
can limit the history to  last successful O/A and O/A in progress. On the
other hand, if ICE with TURN and DTLS are used, you can have multiple RTP
session setups in progress when corresponding O/A exchanges have already
completed.
_____________
Roman Shpount