Dale,
Yes, this has come up before. It is as you say - the sender must use the
values specified by the receiver. If all the SHOULDs are followed, then
the sender and the receiver will have said the same thing and the point
is moot, but the SHOULDs can't always be followed.
Also note the requirement that once you have associated a payload type
with a number, you can't ever use that number to mean a different type
within the same session. (One type can have multiple numbers, but a
number can have only one type.)
It turns out that when you have this constraint, and then combine it
with 3pcc call control you can get into a situation that is intolerable.
It comes up when the 3pcc controller does a transfer. In that case one
side remains unchanged and expects all those number assignments to
remain fixed. On the other side you have a new UA that doesn't know what
those fixed assignments are, and so can't obey them.
Jonathan and I agreed on the list that the constraint on the fixed
assignment of numbers needs to be relaxed. I'm not sure if this made it
into bugzilla or not.
Paul
[EMAIL PROTECTED] wrote:
> On another SIP mailing list, someone asked about the handling of
> asymmetric RTP payload types. That is, where a particular codec's
> data is labeled with one payload type number going in one direction
> and a different one going in the other direction. I went to look up
> exactly what the rules are.
>
> The governing document is RFC 3264. It notes (page 7) "Different
> payload type numbers may be needed in each direction because of
> interoperability concerns with H.323." In addition:
>
> For recvonly RTP streams, the payload type numbers indicate the
> value of the payload type field in RTP packets the offerer is
> expecting to receive for that codec. For sendonly RTP streams, the
> payload type numbers indicate the value of the payload type field
> in RTP packets the offerer is planning to send for that codec. 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.
>
> The language isn't as definitive as I'd like, but as far as I can
> tell, the payload types used in an RTP packet *must* be those
> presented by the recipient in its SDP; the SDP presented by the sender
> is only advisory in regard to payload types.
>
> (Unfortunately, this isn't stated succinctly anywhere in the RFC.)
>
> What I'd like is to confirm this reading with the people on this list.
>
> Dale
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
