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

[Paul Kyzivat <[e-mail]>]

On 3/3/16 11:19 AM, Roman Shpount wrote:

>     But then, is it a good idea to say that the PT binding is for the
>     whole O/A session? What preventing us from saying that it is per
>     direction? The fact that it would conflict with the RTP session
>     definition?
>
>
> If there are more then two parties in the RTP session, i.e. if one of
> the parties in O/A is an RTP forwarder, the same PT cannot possibly be
> assigned to different codecs in different directions. This is why PT
> binding is per O/A session.

Based on our earlier discussions in this thread there seems to be an 
intermediate position. There can be separate *requested* bindings by 
each participant, as long as they don't conflict. So this can result in 
PTa and PTb bound to codec1, with participant A requesting PTa and 
participant B requesting PTb.

So then this serves to say that each participant is requesting which of 
the bindings are to be used when sending toward it.

This can work for unicast, but not for multicast. And for unicast 
conferences it might be slightly inefficient in that when packets are 
being sent to multiple participants the PT may need to be rewritten in each.

Then there is the question of whether this will help anything. Will 
those that want to use differing PTs be able to comply with the 
uniqueness requirement?

Maybe we need to investigate the root cause. Precisely why is it that 
some answerers feel a need to use a different PT than that found in the 
offer? What else is going on in their implementation? Is it still a real 
problem? Or is it just a historical artifact?

(Obviously some implementations still request this. Do they *need* to, 
or do they simply want to?)

	Thanks,
	Paul