Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

any trixbox/asterisk experts out there?

I have a trixbox installation that refuses to accept incoming calls via IAX2 from a certain VoIP provider. Initially, I thought it was a firewall problem but I think I've established now that is not the case. I've tried everything I can think of (and I'm no expert in this area) without success. Here's what I've established:

Another TrixBox at a separate site can communicate (over IAX2) to this installation. This is one way I know it's not a firewall problem and this seems to suggest a problem with the VoIP provider, but...

The VoIP provider is able to work successfully with a SwitchVox installation, suggesting the problem isn't entirely with the VoIP provider, either. But...

That same SwitchVox installation can also communicate with the my 'problem' Trixbox - suggesting again that there's nothing inherently wrong with the Trixbox.

In the face of conflicting results, I turned to the asterisk debug, turning on IAX2 debugging reveals that the connection attempt is being received - here's an example of a NEW message coming in from the provider:

 Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: NEW
   Timestamp: 00004ms  SCall: 00043  DCall: 00000 [x.x.x.x:4569]
   VERSION         : 2
   CALLED NUMBER   : 0845[obfuscated]
   CODEC_PREFS     : ()
   CALLING NUMBER  : anonymous
   LANGUAGE        : en
   USERNAME        : [obfuscated]
   FORMAT          : 8
   CAPABILITY      : 65407
   ADSICPE         : 2
   DATE TIME       : 2010-12-03  12:18:58

Here's where the difference occurs. On a successful call, I next see an authentication handshake, an AUTHREQ is sent followed by an AUTHREP reply. For the connections that are not working, I never see this authentication handshake (neither the AUTHREQ nor the AUTHREP).

The fact that the NEW message is getting through the firewall and being correctly received by the Trixbox confirms my thinking that this isn't a firewall issue. So I think the crux of the problem is that, for some reason, my Trixbox is deciding that it doesn't like the incoming call and is not even asking the remote box to authenticate. What would cause this? How can I troubleshoot this further? Any suggestions gratefully received at this point, because I have hit a brick wall.

share|improve this question
What does the Asterisk console log show when the failing call comes in? – Peter Grace Dec 3 '10 at 16:14

OK I just had this happen between an older PiaF (1.4) box and a new one running asterisk 1.6.

Turns out newer asterisk has added some security features that need to be turned off to be intercompatible. It actually turned out the messages were in the asterisk log file, though I wasted 2 hours before seeing them:

[2011-01-18 02:39:01] ERROR[15257] chan_iax2.c: Call rejected, CallToken Support required. If unexpected, resolve by placing address XXXXXXX in the calltokenoptional list or setting user XYZ requirecalltoken=no

So I added requirecalltoken=no to the USER DETAILS section on the asterisk 1.6 server and all was fixed. Hmm, I see I had a requirecalltoken=auto in the Outgoing section of the other side, but I do not believe that is necessary. I'll have to schedule downtime to see about that.

There is a pdf on this at:

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.