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

[Paul Kyzivat <[e-mail]>]

On 3/2/16 5:28 PM, Colin Perkins wrote:
>
>> On 2 Mar 2016, at 22:23, Christer Holmberg <[e-mail]> wrote:
>>
>> Hi,
>>
>>>> *If* it is really the case that there is no relationship between O/A and the lifetime of RTP sessions, then we have
>>>> some work to do to sort out what the relationship is between what is in the O/A and what is in the RTP session.
>>>>
>>>> IIUC, in the case where the is no RTP session prior an offer, the O/A must at least establish some initial PT bindings for the session-to-be.
>>>>
>>>> (I have a feeling that what we are discussing is quite fundamental, and I find it shocking if it hasn't been considered in the past.)
>>>>
>>>> Colin - your insight would be helpful here.
>>>
>>> I don’t have good insights here. I’ve long had the impression there are conflicts between the o/a rules and the RTP rules, but I’m insufficiently familiar with o/a to identify or resolve them.
>>
>> What started this discussion was the uncertainty whether the same PT could be used for *different* codecs, per direction. The answer to that seem to be no: you can use different PTs for the same codec, but you cannot use the same PT for different codecs.
>
> I agree with that answer.
>
>> Also, I have also heard that a new RTP session does NOT require new PT bindings.
>
> Again, I agree. The PT binding as per RTP session: if you start a new RTP session, you can use different PT values, but you’re not required to do so (and generally don’t, since the static PT assignments are re-used).
>
>> So, I may have missed something, but I fail to see any conflicts...

I think I agree with all of the above. As long as the RTP session change 
is to a *new* one.

But suppose you are switched to another preexisting RTP session. It is 
new to you, but it isn't new, and has existing RTP bindings. And those 
might conflict with ones you had in your old RTP session.

If you knew this was a new RTP session you could forget your old 
bindings, and start over.

This sort of thing could happen if you are connecting to a conference 
server. First you are connected to an IVR to authenticate. That is your 
first RTP session. After that you are transferred into the conference. 
That is your 2nd RTP session.

If this is done via REFER, then you will see it as a new SIP and O/A 
session, and so will start out with an empty set of PT bindings.

But if this is done via 3pcc, or a media relay, then we have the problem.

	Thanks,
	Paul