Hi All! I'm having a serious issue with this client's box. They have FPBX 2.9 with Asterisk 1.6.2 and cannot upgrade these versions, it is not an option. After about 15 minutes, outbound calls drop. Below are my configurations and versions. I Googled and thought that is would be a session timers issue, but as you can see, I've added the session timers into the trunk details, as well as in sip_custom.conf (since we are using FPBX, cannot put it directly into sip.conf, but sip_custom.conf is referenced in that file).
Where else should I be looking to fix this issue? It can be replicated multiple times from different devices (phones, ATAs, softphone etc.) as well as from different networks. I also use Fail2Ban with IPTables. All help would be appreciated!
Is your client paying you to fix it? Why should I help you for free? Why do you even mention the client part? I believe people do it to underscore urgency without realizing they are alienating the community (at least this member, I don’t speak for the body public).
Anyway, nothing in the config indicates a problem. I see you only posted a small amount of the trunk config.
I also assume this is a trixbox based on the versions, am I correct?
What is the disconnect cause for the call? Does it happen on both incoming and outgoing? What about if you try a different carrier (that would isolate network down to carrier issue)
Updating is not an option because there are custom modules created for the church. The client is a charity (http://tvineministries.org, my local church) who I don’t charge and are not paying me.
It is not a trixbox install, a straight FreePBX and Asterisk. That is the entire trunk config. This doesn’t happen on incoming calls, just on outgoing. I’ve tried this with 3 different carriers, and the problem is still the same. Their billing solution comes up with a disconnect cause of 127 (have NO idea what that is!) Here’s what happens at the end of the call from the SIP debug:
I’m very puzzled by this trace. I assume it was provided by the carrier – what they sent you is labeled “sent” and what you (presumably) sent them is labeled “received”. But in that case, if the call dropped because of a timer issue, you should have seen their attempted re-invite, even if your Asterisk didn’t get it, e.g. because of a firewall or iptables issue.
Also, the “received” timestamp is the same as sent. For that to be plausible, your Asterisk would also have to be in Toronto on 3z fiber. Is that true?
Finally, there is a response to BYE for what appears to be an unrelated call.
Perhaps this all makes sense to another reader, who will chime in. Otherwise, you might try placing a test call with that carrier and account from another system or device, to confirm that the failing PBX is at fault. If it does work with the other system, you’ll have “good” and “bad” to compare.
Getting a SIP trace from the Asterisk side may show something unexpected. If you are not re-inviting the audio, a tcpdump of the entire call might show if something went wrong with the RTP; the carrier may have dropped the call because RTP stopped coming in, or because your Asterisk returned ICMP errors to RTP they were sending.
Alcazar Networks, one of the providers I use, does timer re-invites every 150 seconds. If you have them, or sign up with them (there is a 24-hour free trial), it would be interesting to see whether your call drops at 150 seconds, at 15 minutes, or not at all.
Thank you Stewart for your help. I checked this thread, applied what the OP suggested but to no avail. I am currently running a tcpdump right now to see what is going on. What should I be looking out for? Thank you for your help thus far.
Copy the capture file to your workstation and open it in Wireshark. First, look at the SIP. After the 200 OK response to INVITE (when the call was answered), you should see an ACK. Is there anything else before the BYE, other than OPTIONS and its replies (caused by qualify)? If so, report what you see.
You should also look at (and perhaps play) the RTP stream. Up until the BYE, was Asterisk still getting RTP from the extension and forwarding it to the carrier? And, getting RTP from the carrier and forwarding it to the extension? Without any ICMP or other errors?
Possibly, the “normal” BYE occurred because the called party stopped hearing the caller for some reason and hung up. It would be useful to listen to the conversation to see if there was trouble communicating just before the BYE.
Hi Stewart, thank you so much for all your help thus far. I am learning so much!
I have opened up the dump file in Wireshark and checked the using the VoIP Calls > Flowchart. Here is what I have found.
For one call, I see two entries: one from the carrier to FreePBX, and then the FreePBX to the desk phone. First, lets start with the carrier to FreePBX.
At around the 14 min mark, the carrier sends the error message: 488 Unacceptable Media. After that it sends several 200 OK messages (on this call it sent 5). Then it sent out the BYE message approx. 4 seconds after the last 200 OK message. After the BYE message was sent, FreePBX sent the carrier server an OK message.
From FreePBX to the Deskphone:
At around the same 14 minute mark, FreePBX sends out a BYE message to the deskphone, the deskphone then sends out an OK message.
From the looks of things, it seems like it is the carrier’s Cisco that is send out the disconnect message. My concern would be the 488 Unacceptable Media message. I have G729A. installed on my FreePBX and the carrier only accepts G729 what they didn’t specify which type. Could this be the problem?
Any input would be most welcome. From looking at the trace, I very strongly think that it is a carrier problem with the G729 codec I have installed, but I could be wrong.
G.729A uses a reduced complexity encoder, compared with G.729. (Speech quality is a little worse, in exchange for using less computational horsepower on whatever is encoding it, so it can handle more concurrent calls.) They are compatible and work with the same decoder. Nonetheless, the codec names are often an issue and can cause trouble. Possibly, there is a bug in the old code you are using.
However, most likely that shouldn’t be an issue. The first question is why are you using any form of G.729 at all? If you’ve got enough bandwidth, you shouldn’t need it and you’ll get better voice quality without it. Turn it off and it will fix (cover up) your trouble.
If you have a reason to use G.729 with some extensions, e.g. they are connected by satellite or by 3G cellular data, then you could let Asterisk transcode for those extensions; the carrier would only see G.711 (ulaw or alaw) and this would also cover up the trouble. Your deskphone would be using G.711 anyhow and this wouldn’t be an issue.
If you really need G.729 on the carrier side, e.g. your ISP has a very small “cap” on bandwidth and they charge you a lot for overage, then we’ll need to look in detail at what is happening. Does the call start out G.729? If not, why? If it does, is the SDP in the original invite specifying a different codec name than that in the response to the (presumed) re-invite? If so, it should be possible to track down the discrepancy and fix the offending configuration or patch the buggy code.
BTW, your description of the capture seems to be for an incoming call, but your original post implied that only outbound calls have the 14 minute drop issue.
I just wanted to first of all say a big thanks to your for all your help with this thread. It was a great eye opener as I learned and brushed up on some things that I hadn’t used in a while and I appreciate it.
Unfortunately, this problem has yet to be resolved as the power failed on the server, causing it to crash When I get a new power, I shall see if the same problem persists. Thank you so much for all your help!
When I get a new power, I shall see if the same problem persists. Thank you so much for all your help!