Asterisk REGISTERs but outbound calls returning 404[SOLVED]

roadknightlabs · January 26, 2015, 10:26am

I’m stuck on what I think is a registration issue with an Asterisk<->MiTel setup that I’m working on for a client at the moment and could use some help.

This is an Asterisk 11 install on Ubuntu 14.04 talking to a MiTel 3300. The Asterisk Server is able to register & authenticate successfully to the MiTel, but all my calls are getting a “404 - Not Found” response.

Connected to Asterisk 11.7.0~dfsg-1ubuntu1 currently running on astsrvr (pid = 23571)
astsrvr*CLI> sip show peers 
Name/username             Host                                    Dyn Forcerport ACL Port     Status      Description          
1234                      10.123.45.67                                                5060     OK (21 ms)                      
1 sip peers [Monitored: 1 online, 0 offline Unmonitored: 0 online, 0 offline]
astsrvr*CLI> sip show registry
Host                                    dnsmgr Username       Refresh State                Reg.Time
10.123.45.67:5060                        N      1234               285 Registered           Mon, 26 Jan 2015 00:40:50
1 SIP registrations.
astsrvr*CLI>

I am able to place calls through the MiTel using the same username,extension,secret, etc. from X-Lite with the “Register with Domain” box checked. (If I uncheck that, I get a 404 error again).
X-Lite includes the proper Auth header in the INVITE response to the 401 challenge from the MiTel, but I can’t seem to figure out how to get Asterisk to do the same thing when sending calls even though the two servers successfully complete a REGISTER conversation.

I’m kicking off the calls on the Asterisk server with a call file that looks like this:

Channel: SIP/5678@10.0.123.45
MaxRetries: 2
RetryTime: 60
WaitTime: 30
Context: wakeup
Extension: 1234

via this sip.conf context:

[code]
[1234]
type=peer
regexten=1234
secret=1234
fromuser=1234
callerid=“wakeup” <1234>
host=10.0.123.45
port=5060
directomedia=no
disallow=all
allow=gsm
allow=ulaw
allow=alaw
mailbox=1234@default
;nat=yes
nat=no
qualify=yes
registertrying=yes
context=default
register => 1234:1234@10.0.123.45

The “wakeup” context is:

[1234]
type=peer
regexten=1234
secret=1234
fromuser=1234
callerid=“wakeup” <1234>
host=10.0.123.45
port=5060
directomedia=no
disallow=all
allow=gsm
allow=ulaw
allow=alaw
mailbox=1234@default
;nat=yes
nat=no
qualify=yes
registertrying=yes
context=default
register => 1234:1234@10.0.123.45

[wakeup]
exten => s,1,Answer()
exten => s,n,Wait(2)
exten => s,n,Playback(helloworld)
exten => s,n,Wait(2)
exten => s,n,Hangup()

Thanks for any help or hints you can provide. I feel like this should be pretty simple and I’m probably a config option or two away from getting this to work, but I’m pretty stumped right now.

david55 · January 26, 2015, 3:08pm

Registration is about incoming calls (although it might be used to set IP security for outgoing ones).

404 means not found. On the surface, that is not a registration problem, but the use of an invalid number.

roadknightlabs · January 26, 2015, 5:51pm

[quote=“david55”]Registration is about incoming calls (although it might be used to set IP security for outgoing ones).

404 means not found. On the surface, that is not a registration problem, but the use of an invalid number.[/quote]

Which is why I’m puzzled about this. This is being used only for outbound calls and I can get the same credentials to succeed with a SIP client on another system(laptop)

The conversation between X-Lite and the MiTel goes like this(taken from a Wireshark dump):

| X-LITE_IP | | | MITEL_IP
INVITE SDP (opus
 ------------------> 
                  100 Trying
 <------------------         

                  401 Unauthorized 
<------------------ 

ACK ------------------> 
INVITE SDP 
   ------------------->  
                  100 Trying
<------------------ 
                  180 Ringing 
<------------------ 
                  183 Session Progress
<------------------ 
RTP (g711U) 
.
.
.
.

But the conversation between Asterisk and the MiTel is much shorter:

| ASTERISK_IP        | MITEL_IP
INVITE SDP (GSM
 ------------------> 
                     100 Trying
<------------------         
                     404 Not Found
<------------------
ACK | |SIP
------------------>

Could the 404 actually be on the Asterisk end ? Like there’s no destination for the MiTel to deliver the 401 for the Auth challenge to ?
I thought having exten=>1234 defined in the [wakeup] context would be enough.

david55 · January 26, 2015, 6:17pm

The 404 is coming from the Mitel.

Normally I wouldn’t expect to get a 404 before a 401, but maybe it is a 403 in disguise.

roadknightlabs · January 26, 2015, 6:57pm

[quote=“david55”]The 404 is coming from the Mitel.

Normally I wouldn’t expect to get a 404 before a 401, but maybe it is a 403 in disguise.[/quote]

I’ll look into that. I’m guessing the 404/403 instead of the 401 is what’s killing this. Asterisk isn’t even getting a chance to respond w/ the proper auth.

This was one of the first hits I got when researching 403 http://forums.digium.com/viewtopic.php?f=1&t=79957

but I’ve already got directmedia=no.

roadknightlabs · January 27, 2015, 6:13am

I was looking at the INVITE headers again this afternoon and noticed that the X-Lite client calls are using the Opus codec. If that’s required by the MiTel switch and Asterisk doesn’t support it, would that cause the 404/403 ?

Do I need to pass the authentication along in the call file that I’m using to generate the call ?

david55 · January 27, 2015, 8:13am

It should cause “not acceptable here”. I would say the Mitel is giving an inappropriate status code, so you need to attack this from the Mitel end, not the Asterisk one.

roadknightlabs · January 29, 2015, 6:15pm

I’m still working on this.
Another data point:
When I successfully register the Asterisk server to the MiTel, the REGISTER looks like this:

<--- SIP read from UDP:10.123.45.67:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.67.0.89:5060;branch=z9hG4bK037fe648
From: <sip:1234@mitel>;tag=as63fdbe50
To: <sip:1234@mitel>;tag=0_3863659952-107524423
Call-ID: 1396e12e1cad9d7c30c2c33f6b6b30fd@127.0.1.1
CSeq: 107 REGISTER
Content-Length: 0

The outbound call INVITE from Asterisk is including the “asterisk” user though, not my extension/username:

INVITE sip:3034@MiTel SIP/2.0
Via: SIP/2.0/UDP 10.67.0.89:5060;branch=z9hG4bK49151f6c
Max-Forwards: 70
From: "asterisk" <sip:asterisk@10.67.0.89>;tag=as5e4c7f30
To: <sip:3034@MiTel>
Contact: <sip:asterisk@10.67.0.89:5060>
Call-ID: 5e790b3556d6b91071de36e6418d554b@10.67.0.89:5060
CSeq: 102 INVITE
User-Agent: Asterisk PBX 11.7.0~dfsg-1ubuntu1
Date: Thu, 29 Jan 2015 17:35:54 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 292

The INVITE from X-Lite is using the proper username:

INVITE sip:3032@10.123.45.67 SIP/2.0
Via: SIP/2.0/UDP 10.67.0.89:55410;branch=z9hG4bK-d8754z-4c932a720178ae17-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:1234@10.67.0.89:55410>
To: <sip:3032@10.123.45.67>
From: "osprey"<sip:1234@10.123.45.67>;tag=d4b0bf71
Call-ID: OTI4NzA4MWQxYTQ2NTczNTJhOGE1ZWQ4OWVhMjNiYTc
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
Supported: replaces
User-Agent: X-Lite 4.7.1 74250-c862766f-M9.5
Content-Length: 296

I thought I had this taken care of in my sip.conf entry.

[1234]
type=peer                        ; we only want to call out, not be called
remotesecret=1234             ; Our password to their service
defaultuser=1234         ; Authentication user for outbound proxies
fromuser=1234            ; Many SIP providers require this!
fromdomain=mitel
host=10.123.45.67
transport=udp,tcp
port=5060
directmedia=no
disallow=all
allow=ilbc
allow=law
allow=alaw
allow=gsm
nat=yes
qualify=yes
registertrying=yes
context=default

I’d appreciate any pointers about what stray parameter might still be using “asterisk” rather than the username.

roadknightlabs · January 30, 2015, 9:24pm

I fixed this.
I started out w/ fresh, minimalist sip.conf and extensions.conf.
The real fix was realizing that everything in the .call file is implicit.
Using this as a Channel line works:
Channel: SIP/1234/5678

with a sip.conf entry of:
[1234]
type=peer
context=wakeup
host=mitel
username=1234
fromuser=1234
callerid=1234
secret=23925
insecure=invite

(I also added callerid because I’ve had username,user and fromuser in that context to no avail.)
This presents the INVITE as From: “asterisk” 1234@mitel instead of From: “asterisk” asterisk@mitel, which causes the MiTel to respond w/ a 401 and then we’re off to the races from there

I hope this helps somebody else out there…