Can not seem to route incoming IAX call

Asterisk Asterisk General
#1

I am using Asterisk 13 on Raspberry Pi 3. I am trying to route and internal call from VoIP.ms (not a DID Call) using the VoIP.ms sub account calling feature for extension to extension calling in their portal. I want to forward the incoming IAX call from VoIP.ms to a working and tested localphone SIP trunk. I can see the IAX call coming in to my asterisk, and the destination appears to be “s”. This destination does not seem to change with putting “/destination” after the registration however.

Furthermore I can set up a SIP client and put it in the same context and dial most anything and get to the voice mail on localphone, so the problem seems to be specific to IAX. I need to stick with the IAX protocol for this purpose however as I had very delayed media with SIP going from Localphone to VoIP.ms over SIP

I get

CAUSE : No authority found
CAUSE CODE : 50 as you can see below

I have pretty much followed voip.ms configuration example, but their inbound routing shows a DID , not internal calls. Asterisk IAX2 - VoIP.ms Wiki

Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: NEW
   Timestamp: 00007ms  SCall: 02075  DCall: 00000 208.100.60.43:4569
   VERSION         : 2
   CALLED NUMBER   : s
   CODEC_PREFS     : (ulaw|g729)
   CALLING NUMBER  : 6173071111
   CALLING PRESNTN : 1
   CALLING TYPEOFN : 0
   CALLING TRANSIT : 0
   CALLING NAME    :
   LANGUAGE        : en
   USERNAME        : 102000_000
   FORMAT          : 4
   FORMAT2         : ulaw
   CAPABILITY      : 260
   CAPABILITY2     : Unknown
   ADSICPE         : 2
   DATE TIME       : 2022-08-30  06:03:42

Tx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 001 Type: IAX     Subclass: CTOKEN
   Timestamp: 00007ms  SCall: 00001  DCall: 02075 208.100.60.43:4569
   CALLTOKEN       : 51 bytes

Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: NEW
   Timestamp: 00035ms  SCall: 02075  DCall: 00000 208.100.60.43:4569
   VERSION         : 2
   CALLED NUMBER   : s
   CODEC_PREFS     : (ulaw|g729)
   CALLING NUMBER  : 6173071111
   CALLING PRESNTN : 1
   CALLING TYPEOFN : 0
   CALLING TRANSIT : 0
   CALLING NAME    :
   LANGUAGE        : en
   USERNAME        : 102000_000
   FORMAT          : 4
   FORMAT2         : ulaw
   CAPABILITY      : 260
   CAPABILITY2     : Unknown
   ADSICPE         : 2
   DATE TIME       : 2022-08-30  06:03:42
   CALLTOKEN       : 51 bytes

Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 001 Type: IAX     Subclass: AUTHREQ
   Timestamp: 00006ms  SCall: 15619  DCall: 02075 208.100.60.43:4569
   AUTHMETHODS     : 3
   CHALLENGE       : \x34\x36\x37\x35\x38\x32\x30\x38\x38
   USERNAME        : 102096_000

Rx-Frame Retry[ No] -- OSeqno: 001 ISeqno: 001 Type: IAX     Subclass: AUTHREP
   Timestamp: 00053ms  SCall: 02075  DCall: 15619 208.100.60.43:4569
   MD5 RESULT      : c12d68ad117b8b12f38582234408f542

Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 002 Type: IAX     Subclass: ACK
   Timestamp: 00053ms  SCall: 15619  DCall: 02075 208.100.60.43:4569
Tx-Frame Retry[000] -- OSeqno: 001 ISeqno: 002 Type: IAX     Subclass: REJECT
   Timestamp: 00024ms  SCall: 15619  DCall: 02075 208.100.60.43:4569
   CAUSE           : No authority found
   CAUSE CODE      : 50

Here is what I have in iax.conf

[general]
register => 102000_000:Password@seattle2.voip.ms:4569/102000_000

[voipmsiax]
type=friend
username=102000_000
secret=Password 
context=16173071111-vm
host=seattle2.voip.ms 
disallow=all
allow=ulaw
; allow=g729 ; uncomment if you support it
insecure=port,invite
requirecalltoken=yes

I have the following set up in extensions.conf

[16173071111-vm]
exten =>  102000_000,1,Dial(SIP/*1571@localphone)
exten =>  102000_000,2,Hangup()

exten => 1097,1,Dial(SIP/*1571@localphone)
exten => 1097,2,Hangup()

exten => _X.,1,Dial(SIP/*1571@localphone)
exten => _X.,2,Hangup()

exten => _.,1,Dial(SIP/*1571@localphone)
exten => _.,2,Hangup()

exten => !,1,Dial(SIP/*1571@localphone)
exten => !,2,Hangup()

exten => s,1,Dial(SIP/*1571@localphone)
exten => s,2,Hangup()
#2

I have a voip.ms line configured using IAX, though I have mine as type=user rather than type=friend. Honestly not sure if that’s correct… I don’t have a 100% solid intuition of when friend/peer/user is appropriate for different scenarios. I also have never used it for outbound calls, just inbound, with multiple DID numbers coming in on the same registration.

No authority found is common for authentication errors. It means that your server rejected the call because the incoming call couldn’t authenticate. This could be due to the wrong password, or wrong encryption settings, etc.

I might try type=user first just for kicks, since that works for me. It could be, since you have a password specified, that chan_iax2 is trying to have the provider send it the password on incoming calls, which it is certainly not going to do.

I see you have enabled IAX2 debug, but also enable authdebug in iax.conf, if you haven’t already, as sometimes that exposes additional things.

#3

type user does not help and authdeug does not yield any more info. from what I read elsewhere, this has to do with incoming route context but nowhere do I see a solution for it just other have had the same issue. The DIDs are different as they will always come in (as I recall) routable by the DID number.

#4

I get the DID number on my voip.ms calls, not “s”.

This destination does not seem to change with putting “/destination” after the registration however.

I don’t manually specify /destination for any of my registrations, so I would maybe remove that.

Try removing the username and password from the sections (not from the registrations). I don’t specify them there, only in the registration. That could be why your system is asking for credentials improperly.

#5

The OP has a bogus insecure=port,iinvite, the invite part of which addresses this problem in chan_sip, but insecure appears to have no meaning to chan_iax2.c.

(For chan_sip, the correct type, here, would be peer. I don’t know enough about IAX to be sure the same applies.)

#6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.