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

[Roman Shpount <[e-mail]>]

On Sat, Feb 27, 2016 at 11:10 AM, 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.
>

PT collisions are already a quite complicated for the conference focus.
Conference focus needs to deal with situations when multiple inbound
callers (in case of meet-me conference) use the same PT in incompatible
way. When outbound calls are placed from the focus, end points can add PT
to the answer which can also produce PT collisions. With my proposal these
collisions can be resolved using a re-INVITE from the focus which will
force new RTP sessions to be created on the clients.

>From implementation experience PT collisions do not present a real problem
in practice. All practical implementations of RTP mux that I had dealt with
either worked with specially pre-provisioned end points which all used the
same PT for the same codec profiles or conference focus implemented PT
re-mapping on each of the call legs.

Regards,
_____________
Roman Shpount