Brent/Steve, Thanks for the answer. Point here is that asterisk already knows about first leg and the codec so shouldn't it select the best codec for second leg to match first leg. Instead asterisk is selecting first codec in order.
To illustrate, if the first leg was ilbc and second leg supports both g729/ilbc, I will assume that asterisk will select ilbc but that does not seems to be the case. Jim On 8/23/08, Brent Davidson <[EMAIL PROTECTED]> wrote: > > Steve Totaro wrote: > On Tue, Aug 19, 2008 at 7:10 AM, Jim Boykin <[EMAIL PROTECTED]> wrote: > We run asterisk to handle incoming DIDs and we have observed inefficient > Codec Translation. Here is the scenario [DID Vendor] > ---------------------------> [Asterisk ] ------------------------> External > GW [G729] | |-------------------> External GW [iLBC] Our DID vendor and > asterisk box supports both ilbc & g729. However, our external gateway > termination supports either ilbc or g729 (and not both) and depending on > users location, we terminate it on either gateway. Since DID and asterisk > box supports both the codecs, we assumed that asterisk will appropriately > select codecs depending on where we terminate the call so that no codec > translation happens. However, this seems to be an incorrect assumption and > we see that different codecs get selected on two legs which leads to quality > drop and extra CPU cycles. May be we are doing something wrong. Pls suggest > what we are doing wrong. Below is asterisk > configuration. [did] type=friend host=xxx canreinvite=yes disallow=all allow=g729 allow=ilbc [gw1] type=friend host=xxx canreinvite=yes disallow=all allow=g729 [gw2] type=friend host=xxx canreinvite=yes disallow=all allow=ilbc Thanks Jim > Why don't you allow=g729 only on all entries. Maybe I have misread your > email but I interpret what you wrote to mean that all endpoints support > g729 > > I may be wrong but I understood the situation as the DID supplier supports > either g.729 or ilibc, but the user has 2 locations that calls are routed > to. One location supports iLibc only, the other supports g.729 only. What > they seem to be trying to accomplish is to get the DID <-> Asterisk leg to > use the same codec as the Asterisk <-> Remote Location leg. I think the > problem is going to be that the call has to be established to the Asterisk > box before a destination can be selected. The DID and Asterisk Box are > going to negotiate the first available common codec before doing anything > else, including setting a destination. Since you can't change a codec once > a call has been established you're always going to end up with calls to one > of the 2 remote locations being transcoded. > > The only solution I could think of would be if there was some way to > identify which incoming calls were going to be routed to which location and > set the codec accordingly. To do that, you'd either have to have 2 > different DID's or some other massively more complicated mechanism. > > Forcing a reinvite (Is that even possible?) would be the only other > long-shot I could think of. > > Good luck, > Brent > > > _______________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > AstriCon 2008 - September 22 - 25 Phoenix, Arizona > Register Now: http://www.astricon.net > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > > http://lists.digium.com/mailman/listinfo/asterisk-users > _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
