Louis, You didn't address the issue of the meaning of different payload type numbers: If the Offer side receives a different number from the Answer side - what number should it use for the transmitted packets? What number should the Answer use?
-----Original Message----- From: Louis Alexander [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 01, 2005 9:59 PM To: Meir Leshem; 'Gellatly, Anna'; 'Matthew Gardiner'; [email protected] Subject: RE: [Sip-implementors] Negotiation of dynamic payloads using SDP I think the bottom line is that Anna's interpretation is correct. If we examine 3264, section 6.1: 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. I interpret the SHOULD here to be a "strong recommendation to use the same payload type as the offerer, but it is legal not to" Louis -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Meir Leshem Sent: Tuesday, March 01, 2005 3:00 PM To: Gellatly, Anna; Matthew Gardiner; [email protected] Subject: RE: [Sip-implementors] Negotiation of dynamic payloads using SDP Matthew and Anna, We have the same debate in my company too! I took traces from some SIP IADs and observed different behavior! Meir Leshem Veraz Networks -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gellatly, Anna Sent: Tuesday, March 01, 2005 9:24 PM To: Matthew Gardiner; [email protected] Subject: RE: [Sip-implementors] Negotiation of dynamic payloads using SDP Matthew, Our company ran into the same question. We decided when negotiating dynamic payload the SDP actually represents your capability set. It is not a true "negotiation" in the fact you are not trying to come to a conclusion of what payload number to use. Therefore in your example, party A, in their offer, presents a capability set of out of band DTMF on payload 96. The answer from party B is that they too have the capability to do out of band DTMF, yet they want to see the payload tagged with 101. Therefore, when party A sends a DTMF packet to party B they will tag the payload with 101 and party B will send DTMF packets to party A tagged with payload type 96. If anyone has a different idea of how this is done, or can point to a place in the RFC that suggests this is not the correct approach please let Matt and myself know! Thanks, Anna. -----Original Message----- From: Matthew Gardiner [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 01, 2005 9:04 AM To: [email protected] Subject: [Sip-implementors] Negotiation of dynamic payloads using SDP Hi, I am a little bit puzzled as to what exactly is being negotiated when dynamic payload types are present in an SDP offer-answer exchange. For instance, suppose I send an offer of:- INVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0 ... ...etc. etc.. ... v=0 o=2222 0 0 IN IP4 192.168.2.9 s=SIP Call c=IN IP4 81.73.187.109 t=0 0 m=audio 5006 RTP/AVP 8 96 a=rtpmap:8 PCMA/8000 a=rtpmap:96 telephone-event/8000 and then receive an answer of:- SIP/2.0 200 Ok ... ...etc. etc.. ... v=0 o=call-31058C01 13454 13454 IN IP4 213.215.180.165 s=SDP Media Session c=IN IP4 213.215.180.166 t=0 0 m=audio 1046 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 Clearly we have "negotiated" PCMA and telephone-event (the IP addresses and ports being irrelevant in this debate). What I am unclear about is the fact that the offer suggests using 96 as the payload number for telephone-event, but the answer suggests 101. Does this mean that the offerer should send telephone-events using 96 but expect to receive them as 101 and vice-versa for the answerer? Or does it mean that both parties should both send and receive telephone-event using payload type 96? I cannot find the answer to this question in either RFC2833 or RFC3264, so if anyone could answer it for me, or refer me to a document where the topic has been discussed that would be greatly appreciated. Thanks, Matthew Gardiner _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
