Im sorry, corrections below... Bert Culpepper wrote: > > Response inline... > > Attila Sipos wrote: > > > > 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? > > Yes, one way is to respond with a single codec then send an > UPDATE to add a > media stream. See draft-ietf-sip-update-01.txt.
The correct reference is http://www.ietf.org/internet-drafts/draft-ietf-sip-update-02.txt. But you'd actually do a reINVITE for this, not UPDATE. > > Regards, > Bert > > > > > 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 > > _______________________________________________ > 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
