Re: [MMUSIC] Offer/Answer PT Questions

[[e-mail] (Dale R. Worley)]

Roman Shpount <[e-mail]> writes:
> As far as I can see there are 3 question/clarifications that are required:
>
> 1. PT is allocated per codec profile (codec and all associated parameters),
> not codec. For instance, if end point uses PT=100 for SILK/8000, it cannot
> reuse it for SILK/16000
>
> 2. Is PT blocked from each direction independently or both directions at
> the same time. For instance if A sent an offer with PT=100, but B never
> sent an offer or an answer with PT=100, can B sent an offer with PT=100?
>
> 3. PT reuse in sessions such as one triggered by 3pcc where it would be
> impossible to enforce PT from ever being reused.

Thanks for writing a clear list of the issues!  I think it is important
that we provide a formal clarification of these points, as they've been
discussed again and again, though people have a general consensus on
the correct answers.

My understanding is that the answer to 1 has always been understood to
be that the PT identifies the entire codec profile.

My understanding is that the answer to 2 has always been understood to
be that the PT number spaces in each direction are independent.  For
instance, RFC 3264 section 5.1 notes

      Different payload type numbers may be needed in each direction
      because of interoperability concerns with H.323.

My understanding is that PT reuse has always been formally forbidden but
that implementations should tolerate PT reuse by the other endpoint and
should process reused PTs "as you'd expect" as long as all packets
containing the old use of the PT were gone from "the system" before the
reuse is specified.  And it has been understood that this limitation is
not well defined.

Personally, I'd like to see a clean solution to this problem, as I had
to wrestle with it when I wrote RFC 7088 section 2.8 (music-on-hold),
which discusses the problem.

One amelioration is that the sender uses the PTs specified in the SDP
that was sent to it by the receiver, and that SDP also includes the
address to which the RTP is to be sent.  So in simple cases, as long as
the sender updates the PTs it is sending at the same time as it updates
the destination address of the RTP, then the receiver can never be
confused regarding the meaning of PTs it receives. -- Any packets using
the old PT definition have been sent to a different address.

This may break down if there is an RTP gateway in the middle, and while
the ultimate destination of the RTP is different, the sender is always
given the same destination address in the rewritten SDP that it is sent.
But such a gateway has problems knowing which destination to forward the
RTP to.

What do people at sip-implementors say about this?

Dale