[asterisk-users] IAX problem through intermediate asterisk box

Andrew Hakman andrew.hakman at gmail.com
Fri Mar 27 00:34:55 CDT 2009


I'll have to get some VPN's setup, but I will give it a try with SIP.

Thanks for the input - you saved me building 2 more asterisk servers
for testing this issue locally (rather than across 3 networks).

Andrew

On Thu, Mar 26, 2009 at 11:12 PM, Steve Totaro
<stotaro at asteriskhelpdesk.com> wrote:
> On Fri, Mar 27, 2009 at 12:50 AM, Andrew Hakman <andrew.hakman at gmail.com> wrote:
>> So no one else has a problem routing IAX traffic through an
>> intermediate Asterisk server? Does anyone else use Asterisk in such a
>> configuration?
>>
>> On Thu, Mar 26, 2009 at 2:45 AM, Andrew Hakman <andrew.hakman at gmail.com> wrote:
>>> I'm having a problem with IAX running through an intermediate asterisk
>>> box. Perhaps a small diagram will explain the situation better:
>>>
>>> *A ------- [cloud (public internet)] ------- *B --------[cloud
>>> (private network)]----------- *C
>>>
>>> Asterisk server's A, B, and C, are all connected together with IAX
>>> All asterisk servers are 1.6.0.6
>>> Server A and B are geographically close, but connected over the public internet.
>>> Server B and C are geographically far, but connected over a private network.
>>> (the latency between A and B, and B and C are roughly equal)
>>>
>>> Each server has at least 1 phone hanging off of it, with A and C
>>> having most of the phones (B only has a couple).
>>> A's extensions are all 1XXX, B's are 2XXX, and C's are 3XXX
>>>
>>> Phoning from A to B (or vice versa) works well, as does phoning from B
>>> to C (and vice versa). Calls can be placed for an indefinite amount of
>>> time and everything works great.
>>>
>>> The problem arises when phoning from A through B to C (or vice versa).
>>> For the first small amount of time (which can vary on a call to call
>>> basis, and lasts from 0 seconds to 3 minutes or so) everything is
>>> fine. After this, the audio in both directions gets garbled, and
>>> starts arriving in spurts. Once this happens, it continues forever.
>>> The audio never returns to normal no matter how long you wait.
>>>
>>> A to B uses IAX with trunking. B to C is not using trunking
>>> (dahdi_dummy is not working well on C for some reason - the module
>>> loads, but no /dev/dahdi is ever created). The same behavior happens
>>> when A to B is not using trunking either.
>>>
>>> Usually only 1 call is being placed at a time. An interesting thing
>>> happens when 2 testcalls are in progress at the same time though. If
>>> there's a call from A to B, and a call from A to C is made, once the
>>> call from A to C becomes garbled, so does the A to B call. When the A
>>> to C call is ended, the A to B call clears up. Ending the A to B call
>>> first does not improve the A to C call.
>>>
>>> The dialplans are setup so each server passes all non-local extensions
>>> to it's neighbor.
>>>
>>> Hence, for A, the relevant part of the dialplan is
>>>
>>> exten => _2XXX,1,Verbose(1|Extension 2xxx)
>>> exten => _2XXX,n,Dial(IAX2/asterisk_B/${EXTEN})
>>> exten => _2XXX,n,Hangup()
>>>
>>> exten => _3XXX,1,Verbose(1|Extension 3xxx)
>>> exten => _3xxx,n,Dial(IAX2/asterisk_B/${EXTEN})
>>> exten => _3xxx,n,Hangup()
>>>
>>> For B:
>>>
>>> exten => _1XXX,1,NoOp()
>>> exten => _1XXX,n,Dial(IAX2/asterisk_A/${EXTEN})
>>> exten => _1XXX,n,Hangup()
>>>
>>> exten => _3xxx,1,NoOp()
>>> exten => _3xxx,n,Dial(IAX2/asterisk_C/${EXTEN})
>>> exten => _3xxx,n,Hangup()
>>>
>>>
>>> For C:
>>> exten => _2XXX,1,Verbose(1|Extension 2xxx)
>>> exten => _2XXX,n,Dial(IAX2/asterisk_B/${EXTEN})
>>> exten => _2XXX,n,Hangup()
>>>
>>> exten => _1XXX,1,Verbose(1|Extension 1xxx)
>>> exten => _1XXX,n,Dial(IAX2/asterisk_B/${EXTEN})
>>> exten => _1XXX,n,Hangup()
>>>
>>> Is this the proper way to set such a configuration up? Is there a
>>> better way to call from A through B to C that would work better?
>>> Anyone else experience total audio breakup after a while with a
>>> similar arrangement? Why does it work initially for up to about 3
>>> minutes, then completely fall apart?
>>>
>>> Thanks,
>>> Andrew
>>>
>>
>> _______________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>
> I have had, seen, or fixed this problem more times than I can count.
>
> Use SIP.
>
> IAX2 has been a common problem that I have fixed many many times for
> people over the years.
>
> OR, "The latest version should fix it", which is the Digium tagline on IAX2.
>
> Please report back your results if you do use SIP.
>
> --
> Thanks,
> Steve Totaro
> +18887771888 (Toll Free)
> +12409381212 (Cell)
>
> _______________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>



More information about the asterisk-users mailing list