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

[Paul Kyzivat <[e-mail]>]

On 3/2/16 11:02 AM, Roman Shpount wrote:
> On Wed, Mar 2, 2016 at 10:43 AM, Paul Kyzivat <[e-mail]
> <mailto:[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.

I agree with you, at least in principle.

The question is: how much of this do we need to deal with in a normative 
way? At some point we may want to simply expect the implementer to avoid 
shooting himself in the foot.

	Thanks,
	Paul