If A says 97 and B says 101, B must send using payload 97 A must send using payload 101 They work like ports: If A says port 10000 and B says port 20000 B must send to port 10000 A must send to port 20000 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.
The paragraph I quoted is a SHOULD and SHOULDs should always be adhered to unless there is a really good reason for not doing so. It is risky to not comply with SHOULD. For best interop, always implement "SHOULD" requirements. So if A says 97, B should also say 97 but if it doesn't, A must use the PT specified by B. ________________________________ From: Socaciu, Vlad [mailto:[email protected]] Sent: 14 September 2009 01:39 To: Attila Sipos; Stefan Sayer Cc: [email protected] Subject: RE: [Sip-implementors] RFC 2833 Telephone-Event RTP Payload Type Gentlemen, Thank you very much for your comments! You saved me the effort to study this intricate RFC. I am just a user trying to debug a problem which arose between Avaya and a Radvision SIP stack. I am using Radvision (indirectly, through Dialogic) and the customer is using an Avaya SIP PBX. I tried to summarize the statements from RFC 3264 in the following table. "x" and "y" are payload type numbers. Mode Offerer (A) Answerer (B) RTP-Direction PT-number-in-RTP =============================================================== sendonly x y from A to B y recvonly x y from B to A x sendrecv x x from A to B x sendrecv x x from B to A x There are two points which are unclear to me: 1. For "recvonly" I showed in the table that the answerer advertised a different payload type number. Is this legal or the answerer should advertise the same payload type as the offerer ("x" in this case)? What should the offerer do, if the answerer specified "y" in its SDP but then sent the RTP messages correctly using "x" for the PT? Of course, I am trying to play the devil's advocate. 2. For "sendrecv" the spec seems a little ambiguous or even contradictory. The paragraph quoted by Attila (page 10) states very clearly that the answerer should advertise the same payload type number as the offerer. The table above is based on this assumption. However, the paragraph quoted by Stefan (page 7) states that "for... sendrecv streams, the answer might indicate different payload type numbers for the same codecs". which seems to contradict the rule at page 10. It continues: "...in which case, the offerer MUST send with the payload type numbers from the answer" (same as for "sendonly"). But the RFC does not say what should the answerer do. Should it use the PT number that it advertised or the one advertised by the offerer? In fact this is my problem. Avaya sends PT number 127 in the INVITE and Radvision answers with PT number 101 in "200 OK". Unfortunately, the RTP streams do not reach their destinations because of a firewall obstacle and the customers do not have the chance to exchange DTMF signals. Thanks a lot and best regards! ________________________________ From: Attila Sipos [mailto:[email protected]] Sent: Sunday, September 13, 2009 6:59 AM To: Stefan Sayer; Socaciu, Vlad Cc: [email protected] Subject: RE: [Sip-implementors] RFC 2833 Telephone-Event RTP Payload Type Note also this (also from RFC3264): 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. This means, as an example, that if 97 was used for telephone-events in the offer, then 97 should be used in the answer. For best interoperability, comply with the above MUST. Regards Attila -----Original Message----- From: [email protected] on behalf of Stefan Sayer Sent: Fri 9/11/2009 3:26 PM To: Socaciu, Vlad Cc: [email protected] Subject: Re: [Sip-implementors] RFC 2833 Telephone-Event RTP Payload Type o Socaciu, Vlad [09/11/09 01:35]: > I found the following question raised by Mr. Greg Dykes on Sun Sep 28: > > My question really is about the actual usage of a numeric payload type > indicator. The assumption with my question is that both SIP UAs are > negotiating the same "telephone-event' RTP payload. As I understand > each SIP UA can specify their own payload type indicator (96-127) > which represents a specific, static "telephone-event" RFC 2833 RTP > payload. In other words, they don't have to make use of the same > value. So am I correct in saying that each SIP UA can indeed make use > of a different payload type indicator in the dynamic range of 96-127? > And if so does this value represent the UA's intended RTP payload type > for SENDING or RECEIVING RTP? > > Thanks, > > - Greg > > It seems to be a very clear and pertinent question. But there are no other messages on this thread. I am facing the same dilemma. Can someone provide a resolution? Have a look at SDP offer/answer RFC, http://www.ietf.org/rfc/rfc3264.txt, 5.1 Unicast Streams; what is said there applies to telephone-event payload as with any other dynamic payload. Here about the offerer: 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. Best Regards Stefan > > Thanks. > > Vlad Socaciu > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors . _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
