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

[Paul Kyzivat <[e-mail]>]

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

Colin - your insight would be helpful here.

	Thanks,
	Paul

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
>