[asterisk-dev] Regarding SIP performance

[Brian Candler]

On Mon, Oct 16, 2006 at 02:11:09PM +0100, Brian Candler wrote:
> * Make the INVITE to the second phone only offer codecs which the first
> phone offered. Then if the call is rejected due to no compatible codec
> (606?), try again using the normal two-leg setup, with SDP pointing at the
> Asterisk server. This to me seems the cleanest way.

Aside: I think this would also give a very clean solution to the
codec-selection problem discussed previously. As I understand it, you can
get situations where phone1 and phone2 share a common codec, but transcoding
still ends up taking place because phone1's preferred codec was chosen
first, and phone2 doesn't support it.

So the suggested algorithm is:

- pass on an INVITE with the same codecs as the incoming INVITE
  (filtered against those codecs which you wish to disallow, of course),
  with SDP pointing to incoming peer if canreinvite=yes, or SDP
  pointing to Asterisk if canreinvite=no.

- if you get a 606 then INVITE again, this time listing all the codecs you
  are prepared to transcode for, with SDP pointing at Asterisk.

Given a chain of SIP calls, e.g. phone1 -> astx1 -> astx2 -> phone2, this
will push the transcoding down the chain as far as possible, and if there is
any common end-to-end codec it will be used (as long as it's not disallowed
by any intervening device)

Or have I overlooked a problem?

Regards,

Brian.