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

From: Harald Alvestrand <[email-masked]>
Date: Mon, 23 Nov 2020 12:00:55 +0100

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 :-)

Harald

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 23 Nov 2020 11:11:39 +0000

The annual how-does-PT-works question :)

I would have to do some research in order to figure out whether it is explicitly forbidden. If legal, I guess everyone would agree that it is inadvisable, but that doesn't mean initiators can choose whether to support it or not :)

Regards,

Christer

-----Original Message-----
From: mmusic <[email-masked]> On Behalf Of Harald Alvestrand
Sent: maanantai 23. marraskuuta 2020 13.01
To: [email-masked]
Subject: [MMUSIC] Query: When rejecting a PT, can I reuse the PT number?

<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.

- Illegal?

Harald

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Nov 2020 14:39:51 -0500

Harald,

My take, at end.

> 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.

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Tue, 24 Nov 2020 02:16:48 +0000

Harald,

RFC 3264 is somewhat ambiguous on this specific example. But the intent of asymmetric payload types is precisely to allow such flexibility, allowing separate number spaces specific to each side. The only thing which is clearly illegal is for either side, offerer or answerer, to remap a payload type number to a different format in *different SDP they emit*. Unfortunately, the text is not very clear on this, but it is definitely the intent. So each side can't remap its own declared numbers, but it can generally disregard the peer number mappings. (Technically, the answer SHOULD honor the offer mappings unless it has "good reason" not to.)

A common issue at interop events is:
Alice offers 96 G.711 and 97 Opus
Bob answers 97 G.711 and 96 Opus
Alice should receive G.711 as 96 and send G.711 as 97
Bob should receive G.711 as 97 and send G.711 as 96
Alice should receive Opus as 97 and send Opus as 96
Bob should receive Opus as 96 and send Opus as 97

Middleboxes (especially 3pcc) are the main reason this oddity is sometimes necessary. And it always trips up some implementers at every single interop event.

Your example is a simpler case of this general issue with asymmetric payload types. I assume your example was simplified, and there were other codecs in the answer which did match the offer (in format but not necessarily number). If there were literally no matching codecs, the answer must reject the entire m-line with a zero port. But I don't think that technicality was the point of your question.

Mo

-----Original Message-----
From: mmusic <[email-masked]> on behalf of Harald Alvestrand <[email-masked]>
Date: Monday, November 23, 2020 at 6:02 AM
To: "[email-masked]" <[email-masked]>
Subject: [MMUSIC] Query: When rejecting a PT, can I reuse the PT number?

<incoming offer>

a=rtpmap:127 unicorn

<outgoing answer>

a=rtpmap:127 opus/48000

- Illegal?

Harald

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Tue, 24 Nov 2020 03:46:35 +0000

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 <[email-masked]> on behalf of Paul Kyzivat <[email-masked]>
Date: Monday, November 23, 2020 at 2:40 PM
To: "[email-masked]" <[email-masked]>
Subject: Re: [MMUSIC] Query: When rejecting a PT, can I reuse the PT number?

Harald,

My take, at end.

 From section 5.1:

    ... For sendrecv RTP

 From section 6.1:

 From section 8.3.2:

    ... However, in the

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 27 Nov 2020 01:02:45 +0100

Mo,

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

    ... For sendrecv RTP

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.