Subject: [SIP] subset of media codecs

From: Baniel Uri-CUB001 <[email-masked]>
Date: Sun, 14 Jan 2001 19:25:15 -0600

RFC2543bis-02:

15.3

Note that Watson's list of codecs may or may not be a subset 
of the one offered by Bell, as each party indicates the data 
types it is willing to receive.

B2.
If the
   media stream is listed as both send and receive, the callee lists
   those codecs it is capable of sending or receiving among the ones
   listed by the caller in the INVITE. 
   If caller and callee have no media formats in common for a particular
   stream, the callee MUST return a session description containing the
   particular "m=" line, but with the port number set to zero. 

Which one is the correct one? I tend to go with B2...

Uri

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Billy Biggs <[email-masked]>
Date: Sun, 14 Jan 2001 21:32:54 -0500

Baniel Uri-CUB001 ([email-masked]):

> RFC2543bis-02:
> 15.3
>   Note that Watson's list of codecs may or may not be a subset of the
>   one offered by Bell, as each party indicates the data types it is
>   willing to receive.
> 
> B2.
>   If the media stream is listed as both send and receive, the callee
>   lists those codecs it is capable of sending or receiving among the
>   ones listed by the caller in the INVITE.  If caller and callee have
>   no media formats in common for a particular stream, the callee MUST
>   return a session description containing the particular "m=" line,
>   but with the port number set to zero. 
> 

  You always return all of the codecs you can receive.

  This came up at the bakeoff with RFC2833 RTP DTMF digits.  Most phones
can send these types of RTP digits, but not receive them.  If a gateway
receives an INVITE that only lists G.711 audio, should it advertise that
it supports RFC2833 tones?  If you only send a subset of what you
receive, then only G.711 gets listed.  Clearly, this is broken.

  Another example is with a back-to-back UA.  It may first answer with a
token audio format, say G.711, then later update with a full codec
listing from whomever it subsequently connects with.  The roles of who
should send a subset of what are now completely meaningless.

  Best to always advertise all the codecs you can receive, thus avoiding
all problems.

-- 
Billy Biggs                     [email-masked]
http://www.billybiggs.com/      [email-masked]