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

[Christer Holmberg <[e-mail]>]

Hi,

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

Regards,

Christer


On 3/1/16 2:16 PM, Roman Shpount wrote:
> On Tue, Mar 1, 2016 at 2:06 PM, Paul Kyzivat <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     On 3/1/16 1:23 PM, Roman Shpount wrote:
>
>         What really bugs me about this discussion is that it is extremely
>         difficult to determine when RTP session is started or stopped
>         based on
>         O/A exchanges. Because of this it is difficult to determine when
>         it is
>         safe to reuse PT for something else just by looking at O/A.
>
>
>     Well, can we assume that if the addr/port changes at one of the ends
>     then this is to be a new RTP session?
>
> I saw end points that will update the remote addr/port but will 
> continue using the same RTP SSRC and sequence numbers.
>
>     Are there cases where nothing in the SDP changes but a new RTP
>     session is established? (Or can we require signaling in this 
> case?)
>
> There are quite a few end points which will start a new RTP session 
> unsolicited.
>
>     Maybe we need to start using the a=connection attribute with RTP to
>     indicate change of RTP session. :-)
>
>
> This will not be backwards compatible and will break a lot of things.
>
> So far, there have been no relationship between O/A exchanges and RTP 
> sessions. Sometimes RTP sessions start without O/A exchange and 
> sometimes the same RTP session continues through O/A exchange. What we 
> need is a non-ambiguous way to decode RTP packets not the complete RTP 
> session life time management. This will mean we need to specify when 
> new RTP session MUST start (when conflict is detected). It does not 
> require anything more.
> _____________
> Roman Shpount
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>

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