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 [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
