Re: [MMUSIC] Offer/Answer PT Questions

On 2/22/16 5:43 PM, DOLLY, MARTIN C wrote:
> Paul,
>
> I agree with Christer, this needs to be fixed. We are doing interop testing with other carriers for VoIP interconnection, and this is  a major issue.

As I said, I also think fixing this would be a good thing. I'm not the 
chair, so it isn't my call. Key is to round up a critical mass to 
work-on/review this, and flush out any with concerns about such a change.

IMO this will at least require a work item and a draft.

	Thanks,
	Paul

> Fixing this would help accelerate VoIP interconnection.
>
> Regards,
>
> Martin
>
> -----Original Message-----
> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
> Sent: Monday, February 22, 2016 3:42 PM
> To: Paul Kyzivat <pkyzivat@alum.mit.edu>; mmusic@ietf.org
> Subject: Re: [MMUSIC] Offer/Answer PT Questions
>
> Hi,
>
>>> One thing that bothered me here is that PT cannot be reused for the
>>> duration of the session. It is probably safe to reuse the PT after
>>> session modification if PT is no longer used. I always felt that
>>> dynamic PT reuse criteria were much stricter then realistically possible or needed.
>> ...
>>> I think the most important criteria here is that there should be no
>>> ambiguity regarding how an RTP packet with particular PT should be
>>> decoded. If it is guaranteed that there are no packets sent between
>>> Alice and Bob with PT 111 over some reasonable time interval (couple
>>> of network round trip times), then PT 111 can be safely reused. If,
>>> in this scenario Bob's end point knows that it was not sending
>>> anything with payload 111 recently, then it can safely reuse this payload.
>>> Alice could not be sending anything with payload 111 since Bob did
>>> not accept it previously. On the other hand, Bob must not reuse PT
>>> 100 for, let's say, CN, since there are packets with this payload in
>>> flight and this will create decoding ambiguity. To conclude, an end
>>> point should be able to safely reuse any PT that it is not currently
>>> accepting or was not sending or accepting for at least a few network round trip intervals.
>>
>> I agree that this is how it *should* be. I don't know if we can change
>> this safely or not. It seems likely to me that some implementations might be freaked out by this. It is worth discussion.
>>
>> There are cases where it really isn't feasible to meet the current
>> requirement. In particular, when a transfer is done via 3pcc the transferee won't know the history of past PT usage. So I expect in cases such cases the rule is commonly broken.
>>
>> Coming up with clear rules for when PTs can be recycled could be a challenge.
>
> Well, I think we have to try, because these kind of issues keep causing problems.
>
> The fact that something may freak about because we fix it is not a reason for not fixing it :)
>
> Regards,
>
> Christer
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>