[asterisk-users] Inefficient Codec Translation

[Brent Davidson]

Steve Totaro wrote:
> On Tue, Aug 19, 2008 at 7:10 AM, Jim Boykin <boykinjim at gmail.com> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080822/ccefd59b/attachment.htm