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

[Paul Kyzivat <[e-mail]>]

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.