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

[Roman Shpount <[e-mail]>]

On Wed, Mar 2, 2016 at 5:24 PM, Paul Kyzivat <[e-mail]> wrote:

>
> I guess we need to find somebody fluent in both, or else keep talking till
> we understand each other. Maybe Roman fits the bill. I suspect that
> Jonathan Lennox does, but he seems to have been quiet recently, so I
> suspect he is busy.
>

I have some familiarity with both O/A and RTP, but mostly in context of
Audio/Video implementations. I have also dealt with couple of RTP
mixers/forwarders but I cannot claim I've seen all possible variations here.

The problem we are facing is that O/A provides no clear indication of when
RTP session starts and ends. It obviously starts after initial setup and
ends when call completes, but it is unclear if RTP session starts or ends
somewhere in the middle. It can also be ambiguous for the parties
participating in O/A, especially in cases of 3pcc. In case of 3pcc one
party might think that it is a completely new session and another think it
is a session update. I think now most end points try to be conservative and
assume that RTP session runs for the entire duration of the O/A session
with session updates not starting new sessions.

My suggestion is to state that RTP session starts with initial O/A exchange
and ends when the call ends. On top of this, if end point detects a PT
collision on an offer, it should forget the old PT assignment history,
allocate new local transport and start the new RTP session.

It is either this or special SDP attribute that states this is a new RTP
session. Or it can be both -- attribute to force the new RTP session or
automatically starting new RTP session on conflict. In fact this will be
very similar to dtls-connection attribute we just defined and tries to
solve the same problem (not sending ambiguous content over the same
transport).

_____________
Roman Shpount