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

[Paul Kyzivat <[e-mail]>]

On 2/29/16 8:28 AM, Christer Holmberg wrote:
> Hi,
>
> SDP Offer/Answer causes lots of problem. When I read all this it seems
> like we want to complicate things – which very likely will cause any
> more problems.
>
> Two endpoints use SDP Offer/Answer to negotiate an “SDP session”. Can’t
> we try to define what rules apply within that “SDP session”? Why do we
> have to talk about RTP sessions etc?

I've been trying to understand this since I first started working on sip 
(in 2002). I'm *finally* starting to understand some of the motivations 
for the words in 3264. Unfortunately those words fell far short of 
covering the concerns.

I agree that 3264 seems to have a notion of an "SDP session", that is 
different from an RTP session.

But when using RTP a consequence is that RTP sessions are being 
established and updated. Those do have rules of their own. It is 
presumably as hard or harder to change those as it is to change the O/A 
rules.

While 3264 phrases its PT rules in the context of an SDP session, they 
are pretty much scoped to an RTP session. (There is no interaction 
between the PTs of different m-lines.) AFAICT the only thing considering 
the SDP session can bring to this is to impose a rule that the PT 
bindings be retained for an m-line even when the RTP session for that 
m-line changes. I can see no downside in removing that restriction.

	Thanks,
	Paul

> Regards,
>
> Christer
>
> *From:*Roman Shpount [mailto:[e-mail]]
> *Sent:* 29. helmikuuta 2016 7:30
> *To:* Paul Kyzivat
> *Cc:* Christer Holmberg; [e-mail]
> *Subject:* Re: [MMUSIC] Offer/Answer PT Questions - text proposal
>
> On Sat, Feb 27, 2016 at 11:10 AM, Paul Kyzivat <[e-mail]
> <mailto:[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
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>