[asterisk-users] IAX trunking stopped working

Tue Jul 3 14:15:08 CDT 2012

> -----Original Message-----
> From: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-
> bounces at lists.digium.com] On Behalf Of Matthew Jordan
> Sent: Tuesday, July 03, 2012 2:27 PM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: Re: [asterisk-users] IAX trunking stopped working
> 
> 
> ----- Original Message -----
> 
> > From: "Noah Engelberth" <Noah at directlinkcomputers.com>
> > To: "Asterisk Users Mailing List - Non-Commercial Discussion"
> > <asterisk-users at lists.digium.com>
> > Sent: Tuesday, July 3, 2012 10:56:10 AM
> > Subject: [asterisk-users] IAX trunking stopped working
> 
> > I administer a group of Asterisk servers running a mix of 10.3, 10.4,
> > and 1.8.8.1 (mostly 10.4). One of those servers is a call
> > concentrator/relay for E911 service. All of the other servers make an
> > IAX connection to the relay server, which then hands off to a SIP
> > trunk to my E911 provider. It all worked as recently as 2 weeks ago,
> > but I discovered that sometime between then and now it stopped working
> > without any explanation. Last modified time on the config files is
> > over 2 months ago.
> 
> > The setup is as follows:
> 
> > On the call relay (IAX “receiver”)
> > [my-remote-server]
> > type=user
> > host=dynamic
> > username=my-remote-username
> > encryption=yes
> > secret=my-remote-secret
> > context=my-call-context
> > deny=0.0.0.0/0.0.0.0
> > permit=remote.server.ip.address/255.255.255.255
> 
> > On the VoIP servers (IAX “sender”)
> > - One of the servers is set to register: register =>
> > my-remote-username:my-remote-secret at call.relay.server.ip
> > - Another is set to just use the peer definition as below without
> > trying to register [my-remote-server] type=peer
> > host=call.relay.server.ip username=my-remote-username
> > secret=my-remote-secret qualify=no
> 
> > Dialplan on the VoIP servers:
> > exten => 911,1,Verbose()
> > same => n,Dial(IAX2/my-remote-server/911)
> 
> > Dialplan on the relay server:
> > [my-call-context]
> > exten => 911,1,Verbose()
> > same => n,Dial(Relay to E911)
> 
> > The issue I’m seeing is this:
> > - On the servers that are set to register, the relay server is
> > rejecting the registration (I’ve confirmed the
> > username/peername/secrets are an exact match on both sides, and
> > nothing has changed from when they were working). IAX debug on the
> > relay server shows the auths come in and the relay server send REGREJ
> > – Registration Refused, Cause Code 29. IAX debug on the server
> > attempting to register shows sending the REGAUTH packets and receiving
> > the REGREJ packets. The IP address shown in the IAX debug packets
> > matches the IP address in the permit rule for each peer that’s
> > supposed to register.
> 
> Can you set authdebug and iaxdebug to true in your iax2 configuration -
> preferably on both ends, but in particular on the server that is servicing the
> registration attempt - and post the portion of the DEBUG logs that shows it
> rejecting the registration?
> 
> Something is failing authentication, and authdebug should tell us at least why
> the server thinks it should reject the attempt.
> 

After some more messing around, I think it's my configuration error on the registration.  I have the peers on the "receiving" server set up as users, not friends, since the calls will only be one-way from the VoIP servers to the relay server.  With the debugs on, the error on registration is [Jul  3 14:52:40] NOTICE[1447]: chan_iax2.c:8100 register_verify: No registration for peer 'my-remote-peer' (from remote.peer.ip.address).  Changing the "receiving" server's definition to a friend and putting in a host=dynamic line makes the errors go away and registration work as expected.  So I guess that was legacy cruft configuration causing me confusion there, sorry.

> > - On the server that is set to just send the calls, an attempt to dial
> > 911 just hangs for 60 seconds and eventually times out without sending
> > the call. IAX debug on the relay server shows the call start frame get
> > RX’d, shows the relay server try to TX a CTOKEN frame, and nothing
> > further (other than retransmissions of the call start frame). IAX
> > debug on the server trying to send the call to the relay server shows
> > the TX for the call start frame, but no RX for the CTOKEN frames.
> 
> Is this the same server that failed to register?  If so, it may be best to focus
> on that problem first.
> 

No, different server.  Also, after doing some further investigation, it looks like my problem of no-calls may be network related -- if I change what vlan the "receiving" server uses to connect to the network so it is internal to my LAN, the IAX connections start mostly working (though I break my trunk connection to my E911 provider, and the one server that connects has a NAT issue, but that's definitely a network problem).   When the server is connected to my Public IP VLAN, the SIP trunk to the E911 provider works, but the IAX connections don't.

> > Ultimately, this has gone from working to totally broken without any
> > apparent change to my configuration. I need help to try to
> > troubleshoot it further, I’ve tried everything I can think of
> > (including transferring the backed-up working config files to a brand
> > new clean-load server, upgrading Asterisk, and recreating the
> > configurations by hand), and nothing seems to be helping.
> 
> Since you have a number of different servers running different versions of
> Asterisk, can you provide which server in your scenario is running which
> version?

"Receiving" server - 10.4.0
VoIP server I was trying to register from - 10.4.0
VoIP server that I was getting the hanging calls from - 10.4.0

I have a couple others running 10.3.0 or 1.8.8.1 that connect through this that show "UNREACHABLE" when they try to qualify the "Receiving" server peer via IAX if the "receiving" server is connected to my Public IP VLAN, but can complete qualify checks if the "receiving" server is in the Private LAN network.  I don't have access to phones on those systems to place test calls with, unfortunately.

Aaaaand, after about fifteen more minutes of flipping things this, that, and the other way while trying to compile the information for this reply, everything's working again.  Augh, I hate technology!

Thanks for your help.  Looks like this was some sort of network issue on my end, wish I had a better grasp of what happened so I can prevent it in the future.

> 
> > Thank you,
> 
> > Noah Engelberth
> > MetaLINK Technologies
> 
> 
> 
> --
> Matthew Jordan
> Digium, Inc. | Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at:
> http://digium.com & http://asterisk.org
> 
> --
> __________________________________________________________
> ___________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New
> to Asterisk? Join us for a live introductory webinar every Thurs:
>                http://www.asterisk.org/hello
> 
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users