Asterisk REGISTERs but outbound calls returning 404[SOLVED]

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.

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=“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.

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=“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.

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 ?

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.

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.

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 :smile:

I hope this helps somebody else out there…