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

[Colin Perkins <[e-mail]>]

> On 27 Feb 2016, at 16:10, Paul Kyzivat <[e-mail]> wrote:
> 
> On 2/27/16 4:29 AM, Roman Shpount wrote:
>> One potential solution is to generate any offer in such a way that it
>> will be compatible with all the completed O/A exchanges for this end
>> point. If an end point receives an offer which is not compatible with
>> existing state, i.e. an offer which is reusing one of the PT for a
>> different codec profile similar, this end point must allocate new
>> transport (use new local address/port or new local set of candidates in
>> case of ICE) for the answer and consider this a start of the new session
>> (discard all the PT use history). If new transport cannot be allocated,
>> for instance if responding to an offer with ICE and existing ufrag, then
>> offer must be refused with 488 or m line with port 0. This way end point
>> can always uniquely map the PT to the codec profile based on PT and
>> local transport where the packet is received. In case of 3pcc, an end
>> point might get an offer which is incompatible with its PT use history;
>> allocate new local transport, and handle it as a new RTP session.
>> 
>> What do you think?
> 
> While there are probably a lot of details to work out, I like it as the outline of a direction to pursue.
> 
> It could get complicated for a focus. It might require the focus to change mixing policies for the offending participant.

I expect it depends on the RTP topology in use. Some of the options in RFC 7667 treat different call legs as separate RTP sessions, whereas others treat them as a single session. That makes a difference, since PT is session scoped. 

-- 
Colin Perkins
https://csperkins.org/