Re: [MMUSIC] Query: When rejecting a PT, can I reuse the PT number?

[Harald Alvestrand <[e-mail]>]

Mo,

the huge hole in the "independent payload number spaces" is the sendrecv 
description:

    ... For sendrecv RTP
    streams, the payload type numbers indicate the value of the payload
    type field the offerer expects to receive, and would prefer to send.

Here we have a clear expectation that the offerer is assigning a meaning 
to payload types in the *forward* direction based on what he's sending 
in the *offer*.

(The reason why this suddenly became a more urgent issue is that we've 
run out of payload types; we have legitimate offers containing 
assignments for every single payload type from 96 to 127. If the 
answerer can offer a different interpretation of one of the PT numbers 
from the offer that he doesn't want to use, that would allow us a way 
out of the trap where you can't find a new PT to use if you want to add 
codecs to the answer).

But in my mind, independent number spaces play hell with the idea of 
negotiating codec parameters:

offer:

a=rtpmap:96 h264
a=fmtp:profile-level-id=<high>

answer:

a=rtpmap:96 h264
a=fmtp:96 profile-level-id=<constrained>

(note absence of profile-asymmetry-allowed)
would mean that one was negotiating 96 to mean constrained-baseline

But if the number spaces are independent, then

offer:

a=rtpmap:96 h264

answer:

a=rtpmap:96 vp8

is completely legal and has a reasonable interpretation (reject offered 
H.264, claim the PT for VP8)

but

offer:

a=rtpmap:96 h264
a=fmtp:96 profile-level-id=<constrained>

answer:

a=rtpmap:96 h264
a=fmtp:96 profile-level-id=<high>

does NOT mean "I'm rejecting your 96 and claiming it for my 96", it 
means "I'm breaking the negotiation rules".

I'm not happy.

On 11/24/20 4:46 AM, Mo Zanaty (mzanaty) wrote:
> Paul,
>
> 8.3.2 is under 8 Modifying the Session, so it applies to different SDP emitted by a given party when modifying an existing session. The restriction against remapping payload type numbers in 8.3.2 therefore applies within the narrow scope of 8. I agree the text in 8.3.2 is unclear from a direct read with no context, and it requires backtracking to the context in 8, 7 and 6 overall to realize this restriction would conflict with the general intent of asymmetric payload types if interpreted as applying to both sides collectively instead of each side individually. From a practical point of view, payload number asymmetry is unavoidable in many interop scenarios, and the intent of 3264 is to allow this asymmetry by effectively allowing independent payload number spaces at each receiver. So ambiguous text should be interpreted in that light.
>
> Mo
>
>
> -----Original Message-----
> From: mmusic <[e-mail]> on behalf of Paul Kyzivat <[e-mail]>
> Date: Monday, November 23, 2020 at 2:40 PM
> To: "[e-mail]" <[e-mail]>
> Subject: Re: [MMUSIC] Query: When rejecting a PT, can I reuse the PT number?
>
> Harald,
>
> My take, at end.
>
> On 11/23/20 6:00 AM, Harald Alvestrand wrote:
>> I recently encountered this situation (names changed to protect the
>> guilty):
>>
>>
>> <incoming offer>
>>
>> a=rtpmap:127 unicorn
>>
>> <outgoing answer>
>>
>> a=rtpmap:127 opus/48000
>>
>>
>> That is - the respondent was rejecting the payload type, but then
>> recycling the payload type number for a different codec.
>>
>> This seems fragile to me.
>>
>> Question for the WG: Is this:
>>
>> - Illegal?
>>
>> - Legal, but inadvisable?
>>
>> - Legal, and MUST be handled gracefully by all initiators?
>>
>> Inquiring minds want to know :-)
> First, you didn't specify if this media stream is sendrecv or
> sendonly/recvonly. For now I'll assume sendrecv. (I'm not certain if it
> makes a difference, but it opens additional cans of worms.)
>
> The answers are dictated by RFC3264. However it is at times unclear and
> ambiguous.
>
> Two different constraints interact in a confusing way:
>
>   From section 5.1:
>
>      ... For sendrecv RTP
>      streams, the payload type numbers indicate the value of the payload
>      type field the offerer expects to receive, and would prefer to send.
>      However, for sendonly and sendrecv streams, the answer might indicate
>      different payload type numbers for the same codecs, in which case,
>      the offerer MUST send with the payload type numbers from the answer.
>
>         Different payload type numbers may be needed in each direction
>         because of interoperability concerns with H.323.
>
>   From section 6.1:
>
>      ... For streams marked as sendrecv in the answer,
>      the "m=" line MUST contain at least one codec the answerer is willing
>      to both send and receive, from amongst those listed in the offer.
>      The stream MAY indicate additional media formats, not listed in the
>      corresponding stream in the offer, that the answerer is willing to
>      send or receive (of course, it will not be able to send them at this
>      time, since it was not listed in the offer).
>      ...
>      In the case of RTP, if a particular codec was referenced with a
>      specific payload type number in the offer, that same payload type
>      number SHOULD be used for that codec in the answer.
>
>   From section 8.3.2:
>
>      ... 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.
>      ...
>         The mappings need to remain fixed for the duration of the session
>         because of the loose synchronization between signaling exchanges
>         of SDP and the media stream.
>
>
> Now, applying that to your case:
>
> You don't show the m-lines from the offer and answer. Was 127 the only
> PT in each? If so, then this violates the requirement that there be a
> codec in common between the offer and answer. In that case this would
> violate 3264.
>
> OTOH, if there was *some* codec in common between the offer and answer
> (even with differing PTs) then that rule wouldn't be violated. But then
> section 8,3.2 becomes an issue.
>
> By the letter of 8.3.2 a PT can only be mapped on one codec for the
> duration of the session. It says nothing about direction. But PTs can be
> different in each direction for a given codec, and the rationale for why
> they must not change only applies in a given direction. Applying this
> restriction collectively to both ends seems illogical and excessively
> restrictive.
>
> Hence it is unclear to me whether it is valid for a PT to be assigned to
> a different codec on each end.
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic