Thanks for the response Bert.
This leads onto my next thing. It is regarding the offer/answer model (in "draft-ietf-mmusic-sdp-offer-answer-02.txt"). If someone sends an offer of: m=audio 10016 RTP/AVP 4 8 97 a=rtpmap:4 G723/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 according to the offer/answer model: >> The answer >> MUST contain exactly the same number of "m=" lines >> as the offer. So a valid answer could be something like this: m=audio 10234 RTP/AVP 4 101 a=rtpmap:4 G723/8000 a=rtpmap:101 telephone-event/8000 BUT... What if you want to have the telephone-events sent to a DIFFERENT port to the G723? That is, say you want to respond with something like this: m=audio 10234 RTP/AVP 4 a=rtpmap:4 G723/8000 m=audio 10236 RTP/AVP 101 a=rtpmap:101 telephone-event/8000 In a way, the above answer seems reasonable because you are simply stating that you want the different media sent to different ports. However, this would be illegal according to the offer/answer model because there are more "m=" lines in the answer than in the offer. Are there any workarounds? Thanks again, Attila > -----Original Message----- > From: Bert Culpepper [mailto:[EMAIL PROTECTED]] > Sent: 10 May 2002 16:42 > To: 'Attila Sipos'; [EMAIL PROTECTED] > Subject: RE: [Sip-implementors] offer/answer model - one of N > codec selection for RFC2833 operation > > > response inline... > > Attila Sipos wrote: > > > > ref: draft-ietf-mmusic-sdp-offer-answer-02.txt > > > > I'm looking at section "10.2 One of N Codec Selection". > > > > At the end, there is the sentence: > > > > The protocol which > > carries offers and answers has to provide a means to > resolve these > > glare conditions, so that only one offer will be used. > > > > > > This seems to me that: > > if an offer has multiple codecs then, eventually, you MUST be > > left with JUST ONE selected codec. > > Only if that is the desired result of the negotiation. > > > > > Is my above statement correct? > > Or can you actually select two codecs if you want to. > > > > You may negotiate any number of codecs, even add them. > > > > > The reason I ask is that I'm trying to understand the > > interoperability issues associated with RFC2833. > > > > Some vendors might "offer" an SDP like this: > > m=audio 10016 RTP/AVP 4 8 97 > > a=rtpmap:4 G723/8000 > > a=rtpmap:8 PCMA/8000 > > a=rtpmap:97 telephone-event/8000 > > > > Seeing as they've offered a "telephone-event" codec AND > > some "normal audio" codecs, I believe their intention is to do > > BOTH "telephone-event" and "normal audio". > > > > yes, and any of the three encodings can be present in the RTP > stream sent to > the single address & port pair. > > > However, I also believe that with this offer they will > > only be allowed to do ONE of these! Is this correct? > > > > It depends on the capabilties of your RTP and DSP/codec HW/SW. > > > > > So, I believe that any endpoint that wishes to do > > BOTH "normal audio" AND "telephone-event" media > > MUST use separate "m=" lines. > > > > i.e. the offer should be: > > m=audio 10016 RTP/AVP 4 8 > > a=rtpmap:4 G723/8000 > > a=rtpmap:8 PCMA/8000 > > m=audio 10018 RTP/AVP 97 > > a=rtpmap:97 telephone-event/8000 > > > > Is this correct? > > > > It is for the RTP and DSP/codec HW/SW that I'm familiar with > (I'll admit my > familiarity is limited). In fact, the two audio encodings > would have to be > sent to a different port. > > Regards, > Bert > > > Any help is much appreciated. > > > > Regards, > > > > Attila > > > > Attila Sipos > > Software Engineer > > > > <mailto:[EMAIL PROTECTED]> > > <http://www.vegastream.com> > > ______________________________________________________________ > > ______________ > > ______ > > > > > > VegaStream : A World of difference for your Integrated > Communications > > > > EMEA Office (UK) > > Tel + 44 - 1344 784900 Fax + 44 - 1344 784901 > > USA Office > > Tel + 1 - 561-995-2300 Fax + 1 - 561-995-2600 > > > > This e-mail and any attachments hereto are strictly confidential and > > intended solely for the addressee. If you are not the > > intended addressee > > please notify the sender by return and delete the message. > > You must not > > disclose, forward or copy this e-mail or attachments to any > > third party > > without the prior consent of the sender. > > > > > > > > > > > > > > > > _______________________________________________ > > 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
