External SIP Extension Rings but hangs up immediately when picked up

  • I’ve forwarded 5060 and 15000-15100 to my Asterisk server which has an internal address of 192.168.1.14
  • I’ve setup my asterisk SIP settings to know about its external address (it detected its public IP fine) as well as the local network. I also told it to use the non-standard port range mentioned above.
  • The remote extension is behind its own firewall. I’ve setup that phone to know it’s behind a NAT in its settings.
  • The extension shows up among the list of peers with its correct IP address (and with a larger qualified delay as expected)
  • When I use my internal extension to call the external extension, it rings a couple of times and than hangs up. The remote extension does indeed ring though.
  • When that remote extension dials my internal extension, it works beautifully.

Anyone know why the remote extension can make calls but not receive them?

What type of firewall on the remote end - That you can call remote -> internal tells me that the remote firewall is letting client traffic out (typical for a NAT firewall) but when you go inside -> outside it fails. This makes me suspect that the far-end router/firewall is being to smart for it’s own good.

Sorry, wasn’t clear. Remote end is behind a simple NAT router (Asus RT-N16U)

In Googling around, it looks like that router has a SIP ALG (Application Layer Gateway) - lots of stupid VoIP systems need these, but I have never found any SIP ALG that worked with Asterisk - if you can find it and turn it off and try again. If anyone else knows this router, they may be able to steer you to where it is if you can’t find it.

Thanks for your suggestion.

I just did the steps here

I was able to do steps 1 - 4 no problem. Unfortunately, the connection still drops as soon as the remote line answers.

That is a long procedure - did you upgrade the firmware and then disable the ALG? Also, have you updated the firmware on the phone?

Actually, the procedure went pretty fast. Didn’t upgrade the firmware though - didn’t notice that step. Will do.

In the meantime, here’s what the asterisk log looks like when the remote extension (510) is called. You’ll notice the ringing happens at 14:17:52 and then it is answered at 14:18:08 which is when it disconnects.

[2016-03-18 14:17:52] VERBOSE[5066][C-000091e1] app_dial.c: -- SIP/510-00000c2a is ringing
[2016-03-18 14:17:52] VERBOSE[5066][C-000091e1] app_dial.c: -- SIP/510-00000c2a is ringing
[2016-03-18 14:18:08] VERBOSE[5066][C-000091e1] app_dial.c: -- Connected line update to SIP/503-00000c29 prevented.
[2016-03-18 14:18:08] VERBOSE[5066][C-000091e1] app_dial.c: -- SIP/510-00000c2a answered SIP/503-00000c29
[2016-03-18 14:18:08] VERBOSE[5066][C-000091e1] pbx.c: -- Executing [[email protected]:1] Macro("SIP/503-00000c29", "hangupcall,") in new stack
[2016-03-18 14:18:08] VERBOSE[5066][C-000091e1] pbx.c: -- Executing [[email protected]:1] ExecIf("SIP/503-00000c29", "0?Set(CDR(recordingfile)=.wav)") in new stack
[2016-03-18 14:18:08] VERBOSE[5066][C-000091e1] pbx.c: -- Executing [[email protected]:2] GotoIf("SIP/503-00000c29", "1?theend") in new stack
[2016-03-18 14:18:08] VERBOSE[5066][C-000091e1] pbx.c: -- Goto (macro-hangupcall,s,4)
[2016-03-18 14:18:08] VERBOSE[5066][C-000091e1] pbx.c: -- Executing [[email protected]:4] Hangup("SIP/503-00000c29", "") in new stack
[2016-03-18 14:18:08] VERBOSE[5066][C-000091e1] app_macro.c: == Spawn extension (macro-hangupcall, s, 4) exited non-zero on 'SIP/503-00000c29' in macro 'hangupcall'
[2016-03-18 14:18:08] VERBOSE[5066][C-000091e1] pbx.c: == Spawn extension (macro-dial-one, h, 1) exited non-zero on 'SIP/503-00000c29'
[2016-03-18 14:18:08] VERBOSE[5066][C-000091e1] app_macro.c: == Spawn extension (macro-dial-one, s, 44) exited non-zero on 'SIP/503-00000c29' in macro 'dial-one'
[2016-03-18 14:18:08] VERBOSE[5066][C-000091e1] app_macro.c: == Spawn extension (macro-exten-vm, s, 16) exited non-zero on 'SIP/503-00000c29' in macro 'exten-vm'
[2016-03-18 14:18:08] VERBOSE[5066][C-000091e1] pbx.c: == Spawn extension (ext-local, 510, 2) exited non-zero on 'SIP/503-00000c29'

That’s weird - it executed a Hangup the instant it got back the answered - Probably need to do a SIP debug to catch what is actually happening, but I wouldn’t wast time checking anything before you have updated the firmware and turned off the ALG.

Could this be media handoff? I’ve seen this on propriety systems where the handset incorrectly tried to establish the direct path once the call is established, but gets it wrong and drops the call.
Check for reinvite settings.

Go with the SIP debug first the directmedia option should only attempt to redirect the SDP session, no guarantees there :wink: (asterisk is a back to back user agent). The SIP session must remain with Asterisk for it to work, if that drops as it looks like it does, then the SIP debug should expalin.

So I just had the remote extension guy replace his NAT router with a completely different unit (different make/model) and we had the same issue.

Is there a guide or a list of tips for how to do sip debugging? I enabled that mode and I see a lot of stuff. Not sure what to look for.

The packets all have a time stamp in /var/log/asterisk/full and are somewhat understandable if you read them, wireshark can decode much of sip in a GUI, but maybe just post a succinct trace of a call that failed.

Asterisk has “tab completion” functionality, from the asterisk CLI type SIP then tab, chase it down . . . :slight_smile:

Off the top of my head this sounds like a RTP port issue. Is there a reason you’re using the non standard range?
What type of phones are you using? My Yealinks by default have an audio port range that is relatively small but it falls within the 10,000-20,000 default asterisk range. If the phone is only allowed a range outside of the one that asterisk will allow you will have problems.
I would look and see if your phone has port settings. That wouldn’t completely explain why the internal extensions are working if you actually changes the asterisk SIP settings to the limited range.

I also had his issue, but it had nothing to do with the RTP or firewall. After upgrade to FBPX 13, some extensions had their recording set to NULL. That is to say the internal/External calls had no recording policy set. As soon as I indicated a value, things got fixed. Possibly this may be the issue?

I’m using these guys: http://www.amazon.com/Grandstream-GS-DP715-VoIP-Cordless-Phone/dp/B008MHQCA0

I don’t see a lot in the settings for RDP. I do see “Local RTP port” and it has the default value of 5004.

I see two recording options for this SIP extension:

  • On Demand Recording (set to “Disable”)
  • Record Priority Policy (Set to “10”)

I just wanted to minimize the number of ports. This is the only external SIP connection and I understand that a sip connection might use as many as 4 RDP ports. I figured giving it 100 to work with would be enough.

That looks fine, but you should look at the 4 lines above those two. That’s my issues were. The mix of inbound/outbound, and internal/external calls. They should have something selected. If none are, then pick any and try the call (after applying changes of course).

Additionally, a thought on the RTP path. Would that not cause a hangup after 30secs (by default anyhow). I’ve had that issue a couple of times, but never got an IMMEDIATE hangup. I saw the asterisk console telling me recording were being played, but no sound. It hung up only after a number of seconds elapsed. (Turns out I forgot to tell asterisk to activate NAT on the extension).

Personally I don’t see RTP being the issue… unless it was unable to negotiate a common CODEC… I image that would show up in the logs though.

The four of those before were set to “Don’t Care”. I’ve now set them to “None”.

I found this thread that says the RDP range is 5004-5024.

I did two things.

  1. I made my freepbx server’s general SIP settings match those ports and changed the firewall in front of freepbx to forward that range to it.
  2. I then noticed that I was supposed to do the same for the other end so I got the guy to forward that port range (UDP) to the grandstream phone’s internal IP address.

Absolutely no change. He can call my extension and all works great. If I call his extension, it immediately hangs up as soon as he answers.