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. _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
