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.

Is my above statement correct?
Or can you actually select two codecs if you want to.


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".

However, I also believe that with this offer they will
only be allowed to do ONE of these!   Is this correct?


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?

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

Reply via email to