Hangup Cause 44

[RealRuler2112 (Ruler2112)]

A customer called late last week to complain that they were hung up on after a transfer - they said that they heard the person pick up & about half a second of background noise, then were disconnected. Looking into the logs, I found that “HANGUP CAUSE: 44” was reported for their initial call.

According to https://wiki.freepbx.org/display/FOP/Hangup+Cause+Codes , code 44 means that the requested channel is not available. Another site (sorry, I didn’t save the URL) suggested that the upstream SIP provider was the culprit, so I contacted our SIP trunk provider. They just got back with me & provided a PCAP of the SIP traffic for this specific call showing the unexpected bye with X-Asterisk-HangupCause Code 44 coming from our PBX. Grepping the full log file revealed that we’ve been getting from 0 to 8 calls a day for at least the past 10 days with this hangup cause shown as the termination reason.

Unfortunately, I’ve been able to find very little online about this code 44 other than the simple description noted above. Is this something as simple as the customer having a crappy cell connection & dropping the call at a coincidental time or might it be caused by a mis-configuration on our server or even hardware issue? (I’ve seen faulty hangup switches cause this type of behavior, though the hangup has always happened the instant the person picks up the receiver. Looking in the logs, I can’t even see where the caller was taken off of hold by anyone in the ring group they were sent to, which makes me wonder how accurate their description of what happened is.) Any ideas of how I could go about troubleshooting further?

[sorvani (Jared Busch)]

If you have the disk space, you can use the new PCAP tool in Sysadmin. Run a pcap all day and then save it out and find those 0-8 calls.

Or you can setup something like this to run tcpdump continually.

Codec order for inbound and outbound calls

I agree with your proposed settings, but I’m confused about your ‘no-audio’ comment. On the failing calls, do you hear a typical choppy voice problem (gaps of a fraction of a second)? Or does audio stop for more than one second at a time? Or does it go completely silent? To start, the simplest test is to record the calls with the regular FreePBX record features and hear whether the recording has the problem. There is a relatively new tool for capturing the raw packets on a per-call basis, w…

[RealRuler2112 (Ruler2112)]

Thank you for the info.

We were sold the HA module with the system, so are stuck on version 13; there is no Packet Capture in there. However, the guy at our telco went above & beyond, digging into this much more extensively and provided me with a full packet capture of the SIP traffic on the call.

Our setup is to have 2 ISPs, one fiber (primary) and one cable (backup). The only time the cable is used is if the fiber goes down. We were having call quality issues when running traffic over the fiber - don’t know why & the fiber provider was unable to track it down - so I set up a flow preference in the meraki edge device to dump all traffic destined for telco’s sip server farm out the cable. The packet capture is showing that while it’s communicating with the IP of our cable, the packet capture shows that it’s telling telco to contact us back at the IP of the fiber. I’ve since put a network tap on the cable line & am running a continual capture to a laptop.

So the problem is inside the Meraki. Given the timing, I bet it’s related to the firmware upgrade which happened a few weeks ago.

Thank you for the input.

[RealRuler2112 (Ruler2112)]

After much hair pulling & gnashing of teeth, I believe I found the cause of this.

Remember how I said we have 2 ISPs? The Meraki dumps everything out the primary (fiber) line unless it’s down, in which case it uses the secondary (cable). In my case, there were unresolved issues running SIP over the fiber, so I created a custom flow preference to direct all traffic in the IP range of my telco’s SIP server farm out the cable line. This works perfectly.

Except.

Just before I left last night, the telco engineer found that while the SIP registration was coming in from the cable line, the IPs that it was saying to use for both the incoming & outgoing RTP streams was our fiber IP. Spent another several hours trying to track down what could be causing this, then gave up & went to bed. Figured I’d get some sleep & start over this morning fresh, disregard everything I’d done today, and go through everything screen-by-screen and line-by-line.

Meraki looks as good as I know how to make it. After a while, I ran across ‘Asterisk SIP Settings’ as an option in the PBX - I’d glossed right over it yesterday and nearly skipped it today. (When I purchased the system, the sales guy told me to never change anything in there or I’d break my system. FreePBX should handle everything in there.) I don’t know that I’d ever been in this screen before & know that I didn’t enter our public IP in it, so am guessing it must auto-detect somehow.

One of the first lines in that screen is ‘External IP Address’ and it was set to the IP of our fiber line. I changed this to the IP of our cable, forced the SIP trunk to re-register, and the RTP streams are now being sent back through our cable.
.

This leads into another question… if the PBX requires manual intervention when the external IP changes, is it not suitable for a corporate environment where you may have multiple ISPs and potentially changing public IP addresses? Or is it just that I had to override the interface traffic destined for our SIP provider goes that made the public IP not update automatically? (There’s a button saying ‘Detect Settings’, but pressing it puts our fiber IP in the external IP field, which I guess makes sense if it’s not detecting it based on traffic to the SIP server and instead using a random site somewhere on the internet. If that is how the public IP is detected, changing it to analyze the traffic going to/from the SIP server would be a good improvement. ) I did no testing with whether the IP listed here updated automatically when failing the Meraki over to use the cable instead of the fiber. It’s overridden to have our cable IP in it & there’s no setting or visible option to make it automatic, so I might be stuck changing it manually after I put an IP in the field & saved it earlier today. (???)

.

I also would like to give a quick shout-out to Telnet Worldwide (telnetww.com) - they’re our SIP provider and without the technician spending a good deal of time/effort working with me AFTER he determined the hangups/BYEs were coming from our network, I never would’ve even been able to find the real source of the problem or fix it. Kudos to their support people.