I’ve recently switched to PJSIP trunks from SIP trunks. Flowroute is the provider. Since the change, some callers are unable to use the IVR. It just doesn’t acknowledge their keypresses.
This seems to be fairly random, but I think it’s affecting callers from other businesses more than anyone else. It also seems to affect some cell phone callers.
Before the change, I wasn’t seeing any of these issues. I’m wondering if it might be a codec issue? I have alaw, ulaw, and g729 enabled on the trunk. I don’t remember if these are the same as what was allowed on the SIP trunk, so I could be missing something.
Is there a typical codec that might be the culprit here? Any ideas of what else it might be?
PS. Is there a way to show in the logs which buttons a caller might be pressing?
Settings → Asterisk Logfile Settings → Log Files, turn on DTMF for ‘full’.
Flowroute does not use alaw, and g729 is problematic for DTMF, but with ulaw ahead of it in the list, all calls should be ulaw which works well with DTMF (as a fallback in case RFC4733 is not negotiated).
Is there a way to see which codec is/was being used for a particular call? I’m having trouble reproducing the behavior myself, but there’s definitely something happening. Contacts are telling me they keep hitting buttons at the IVR prompt and nothing is happening. When I try it, it works for me every time. Again, this only affects some callers. Others get through just fine.
Any other tips on how I might be able to troubleshoot this?
The Asterisk log should show which codecs were negotiated for each call. You can locate a call that was reported as problematic by timestamp and/or caller ID.
For more detail, you can capture all traffic at the PBX, locate the problematic call, look at whether RTP was coming in to the right port in the right format, and even listen to it if needed. For example, see
Another approach: Temporarily change your IVR settings to allow no retries and route timeouts to a receptionist. If they hear silence, you’ll know the RTP is missing or being misrouted (the problem is unrelated to DTMF or IVR). If they hear garbled or choppy voice, that’s another clue. If the voice is fine (the problem really is related to DTMF), the receptionist can connect the call and you’ll avoid annoying the customer.
I have “core set verbose 3” enabled, but I still don’t see log entries that show the negotiated codec. There’s lots of log data so I could just be overlooking it. Is there a string that I should search for? grep’ing “codec” or “ulaw” from the files in /var/log/asterisk has proven to be less than productive… lots of matching terms, but the results seem to be mostly status messages from loader.c, translate.c and file.c. The few from chan_sip.c don’t map to calls. My guess is they are from reloads of the configuration.
Audio quality is not an issue. All calls are crystal clear… even from the callers that report IVR response problems. If I temporarily bypass the IVR and allow a call to pass, the audio is clear in both directions. Does this rule out RTP problems since we don’t see any audio-related issues on any calls?
Routing to a receptionist would kinda defeat the purpose of this IVR. It’s job is to weed out robocalls by forcing an interactive response. No retries is already set and timeout (20s) results in Terminate Call/Hangup.
Wow. Using (for example) last Friday’s CDRs, about how many successful incoming calls did you have? How many presumed failures (IVR timeouts from known contacts)? How many presumed robocalls (IVR timeouts from unknown numbers)?
If you usually get at least one failure per day and no more than a few robocalls, it should not be a major cost to do this for one day.
Or, why don’t you use pjsip logger and/or capture all traffic so you’ll get useful info on the next failure? Also, if you have turned on DTMF logging, did it show no keypresses on the failed calls?
We don’t get a whole lot of calls overall. Last friday, we received 34 calls. 26 of them were trapped by the ivr robo-blocker. The other 9 went through successfully. The ivr response issue only happens some times and I only know it’s happened if I happen to examine the logs and see a local number that I recognise try to get through a couple of times and fail. I call them back and they tell me they kept hitting buttons but couldn’t get through.
I’ll have to wait until another instance before I’ll know more. I have DTMF logging enabled now, as suggested earlier and I can see user key presses… I just haven’t had a failed caller instance yet to compare to. I also have enabled “set verbose 3” and am catching a lot of logs that way.
The issue I’m having now with data collection is the pjsip debug logs. They are going to the “full” log, which intermixes them with the other logs and makes it hard to pull out just the sip sequences & data for a given call.
How can I set it so that “pjsip set logger on” sends logs to a specified logfile instead of to the console and the general “full” log file?
I still can’t find any mention of the codec being used. It unlikely that I’ll capture the failure in real time since I never know when a given caller will have trouble. Is there a specific string I should look for in the log files?
Since I’m dealing with pjsip, do I also need to enable sip debugging? And if so, how would I send that data to a specific file?
I’m a little familiar with the history function, but the lack of human-readable timestamps makes tying the events to a specific call tedious. It’s also risky to leave running indefinitely … ie. until a failed event occurs… given the logs could consume too much memory. Is there no way to direct the typical pjsip logger data to a specified file?
The continuous tcpdump setup that I linked earlier uses a known amount of disk, because new data overwrites the oldest. It’s 10 GB with the parameters shown, but you can adjust them if you don’t have that much to spare.
If you use pjsip logger (writing to the regular Asterisk log), since your call volume is small, most of the added space will be registrations and qualifies. Turn it on and see how fast the log fills up. Confirm that the logs are being properly rotated. With default settings, /var/log/asterisk/full gets rotated daily and files more than one week old are deleted. So, you can estimate how much additional space will be used if you let that run forever.
Well then logging everything with tcpdump won’t hurt, since it’s known in advance to use no more than 10 GB. With your call volume you will likely have several days after a ‘hit’ before the info gets overwritten. When you see an IVR hangup from a known number, you’ll know to investigate.
Does your system have any kind of phonebook or contact list? If so, you could set the IVR failure path to route to a live person if the caller is in the list.
Sure. Search for tcpdump filter and you’ll find lots of articles. However, what significant other traffic do you have? Listening to recordings by web or retrieving voicemails by email? Filtering on just udp is simple and will probably remove most of what you don’t want.
Just general other traffic … ie ssh, dns, mdns, arp, etc. noise as far as this exercise so I’ll try to weed it out. Using udp only is simple enough. Thanks