Thanks for your response Siddharth,
And thanks for pointing me to the correct draft. As you quoted, "that same payload type number SHOULD be used for that codec in the answer". However, it does not mean that it MUST be the same payload type number. So, if someone DOES use a DIFFERENT payload type number as in this scenario: > endpoint A sends SDP containing "m=" and "a=" lines > like this: > > m=audio 10036 RTP/AVP 8 119 > a=rtpmap:8 PCMA/8000 > a=rtpmap:119 telephone-event/8000 > > the replying endpoint B, send an SDP with the > following "m=" and "a=" lines: > > m=audio 10022 RTP/AVP 8 97 > a=rtpmap:8 pcma/8000 > a=rtpmap:97 telephone-event/8000 Then, given that the draft says (end of section "6.1 Unicast Streams"): "In the case of RTP, it MUST use the payload type numbers from the offer, even if they differ from those in the answer." I believe "it" is referring to the answerer. So, therefore, from the example scenario, endpoint B (the answerer) must send to port 10036 using an RTP payload of 119. And, though not explicitly stated, I believe endpoint A (the offerer) must send to port 10022 using an RTP payload of 97. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: 22 May 2002 09:58 > To: Bert Culpepper > Cc: 'Attila Sipos'; [EMAIL PROTECTED] > Subject: RE: [Sip-implementors] Quick SDP dynamic payload question > > > > > > Hi folks, > > * As I understand it the endpoint B is getting an offer of > 2 codecs (8 and 119) and must respond from choosing one > or more of these 2 codecs that were present in the offer. > > Giving a third codec (97) in the answer is not allowed. > If the endpoint B understands that 97 and 119 are dynamic > payload numbers for the same codec (as in this case > telephone-event/8000), it should respond with 119 in the > answer. If endpoint B understands that they are different > codecs (with the help of the rtpmap line), then it should > reject 119. Quoting from page 10 of the offer/answer-02 > draft: > > "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. Even if the same payload type number is used, the > answer MUST contain rtpmap attributes to define the payload > type mappings for dynamic payload types, and SHOULD contain > mappings for static payload types." > > So, the correct SDP answer from the endpoint B would be: > m=audio 10022 RTP/AVP 8 119 > a=rtpmap:8 pcma/8000 > a=rtpmap:119 telephone-event/8000 > > and both parties SHOULD use the offerer's payload type. > > * Secondly, the SDP default direction attribute is 'sendrecv' > and both parties should be explicit only if they don't > support bi-directional transfer for the media they are > describing in the SDP. So, this is not really a deficiency > of SDP, right? Or I missed something here? > > Regards, > Siddharth. > > ---------------- > Siddharth Toshniwal @ Hughes Software Systems > http://www.hssworld.com > > > > > > > "Bert Culpepper" <[EMAIL PROTECTED]> on 05/21/2002 > 09:03:49 PM > > To: "'Attila Sipos'" <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > cc: (bcc: Siddharth J Toshniwal/HSSBLR) > > Subject: RE: [Sip-implementors] Quick SDP dynamic payload question > > > > > comment below... > > Attila Sipos wrote: > > > > > > Hi, > > > > If an endpoint A sends SDP containing "m=" and "a=" lines > > like this: > > > > m=audio 10036 RTP/AVP 8 119 > > a=rtpmap:8 PCMA/8000 > > a=rtpmap:119 telephone-event/8000 > > > > I understand this to mean that the sender of this SDP > > wishes to receive DTMF in an RFC2833 RTP stream with > > an RTP payload of 119. > > > > > > If the replying endpoint B, send an SDP with the > > following "m=" and "a=" lines: > > > > m=audio 10022 RTP/AVP 8 97 > > a=rtpmap:8 pcma/8000 > > a=rtpmap:97 telephone-event/8000 > > > > Then I understand this to mean that this person wishes > > to receive an RFC2833 RTP stream with an RTP payload > > of 97. > > > > So, if I am right, endpoint A should send RFC2833 RTP > > with an RTP payload of 97. > > > > And endpoint B should send RFC2833 RTP with an > > RTP payload of 119. > > > > Is my understanding correct? > > IMO, this is one main "deficiency" with SDP (RFC 2327) in > SIP. Since there > are no direction attributes in the above, it would seem that neither > endpoint will "communicate" telephone-events to the other. Neither > endpoint > has agreed on the payload type that they will both send and > receive with. > If the endpoints want to use a different payload type for a specific > encoding, they need to be explicit IMHO about which value > they'll use in > each direction. > > Regards, > Bert > > > > > Any help is greatly appreciated. > > > > Thanks, > > > > Attila > > > > > > > > Attila Sipos > > Software Engineer > > > > <mailto:[EMAIL PROTECTED]> > > <http://www.vegastream.com> > > > > _______________________________________________ > 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
