Re: [MMUSIC] Offer/Answer PT Questions

[Christer Holmberg <[e-mail]>]

Hi,

I had a talk with Martin about this, suggesting we put this in front of the collective wisdom of MMUSIC, so I'll jump in.

>> Section 8.3.2 of RFC 3264 says the following:
>>
>>     "However, in the case of RTP, the mapping from a particular 
>>     dynamic payload type number to a particular codec within that media stream MUST NOT 
>>     change for the duration of a session.  For example, if A generates an offer
>>     with G.711 assigned to dynamic payload type number 46, payload type
>>     number 46 MUST refer to G.711 from that point forward in any offers
>>    or answers for that media stream within the session."
>
> As you know, this area is not well defined.
>
>> Now, assume the following case:
>>
>> 1.Alice sends an Offer, with the following PT values:
>>
>> PT 100: AMR-WB(mode-set=2)
>>
>> PT 111: AMR-WB(mode-set=2, OA)
>>
>> PT 0: PCMU
>>
>> 2.Bob sends the associated Answer:
>>
>> PT 100: AMR-WB (mode-set=2)
>>
>> PT 0: PCMU
>
> At this point, I think there is an open question of whether the "must not change" even applies for a PT that was offered but not accepted in the answer.

Correct. That is one issue. If it *does* apply, the answerer would have to remember everything that has been offered by the remote endpoint within the session, even if it was not accepted in the answer.

(Now, once could claim that there is no such thing as "accepting" a codec, and that technically the answerer is allowed to send whatever was offered, eventhough it most of the time wouldn't work in reality: endpoint will reserve resources for the codecs both parties indicate support for.)

> One might argue that the real point of the requirement is that it can't be reused once there might be packets in flight using it. But that isn't true in this case. So IMO it is uncharted territory.

And it is not even a special case: offers including more codecs than the corresponding answer is more or less the norm, at least when we take codec configurations into consideration :)


>> 3.Later Bob sends the following subsequent Offer:
>>
>> PT 111: AMR(mode-set=0,2,5,7)
>
> You mean the new offer no longer mentions 0 and 100, only 111 with this new mapping? (Though I don't think the answer to that affects your
> questions.)

The new offer may have included 0 and 100 too, I don't remember. But, as you say, it does not affect the question. The question is whether Bob can use 111 for something else than Alice previously used it for.

>> QUESTION 1: Is it allowed for Bob to offer PT 111 for AMR in the 
>> subsequent Offer, as Alice used PT 111 for AMR-WG in the initial Offer?
>> In other words, does the
>> pt-value-must-only-refer-to-a-specific-payload-for-the-stream-within-t
>> he-session text in section 8.3.2 apply to user A only, or to **all** 
>> users within the session?
>
> While it is *recommended* that the answer use the same PT as the offer for a given codec configuration, that isn't *required*. The answer may accept the codec from the offer using a different PT.

Assuming Bob is allowed to offer 111, then I assume Alice would not be allowed to answer with 111, as Alice previously offered 111 for something else - eventhough Bob did not "accept" it.

> So, in the first answer Bob *could* have accepted the offer for AMR-WB(mode-set=2, OA) using some other PT (say 112). If so, when 
> Bob subsequently sent an offer reusing the same codecs it would have used 100, 112, and 0. (111 would not have been used.) In that case 
> it seems like Bob would be free to use 111 for something else. Alice, in her answer, would be free to map it to a different PT in order to avoid a clash with 111 on her end.
> 
> All of that seems equally applicable in your example, where Bob never accepted AMR-WB(mode-set=2, OA).

Correct. 


>> QUESTION 2:   Assuming the text applies to all users, is it allowed to
>> re-use a PT value for the same codec, but for a different CODEC 
>> CONFIGURATION? The text only talks about codec.
>
> I think use of "codec" was just sloppy, and that it always meant codec configuration.

I would probably agree with that, but it should be clarified.

>> Now, I agree that the easiest way to avoid trouble is simply to make 
>> sure PT values aren't re-used by any party. But, the text still needs 
>> to be clear, because this is causing problems in real deployments.
>
> Agree.
>
> The spec is far from clear on this subject. A starting point for clarifying it to ascertain as best we can the original
> intent. 

What is the original intent? :)

> But then we also need to try to understand common practice. Where this has been unclear there may well 
> be conflicting interpretations in the wild. 
> *Somebody* is likely to be negatively affected by whatever decision we come to.

It is always much easier to get things fixed when the specification is clear on who is wrong and who is right :)

Regards,

Christer