Unable to leave a voicemail on (some) outbound calls


This one is pretty weird.

Calling outbound from the UCM on a GXW2170 or DP750, if the call rings through to the recipients voicemail, the caller hears the voicemail greeting start, but then the call just dies.

Luckily, one of the numbers that this happens to is one of the users’ own cell phones, so I can test it. It happens every time this cell phone is called, but it’s also happening when users call out to their customers and they’re unable to leave a voice message.

If I call out to my own cell phone, I get my greeting and then I can leave a message.

If I call out to the client’s troublesome cell phone and he answers it, we have audio in both directions and the call does not die.

They are not reporting any difficulty on regular outbound calls where the recipient answers - only on some calls when they reach a voicemail box. Other voicemail boxes are fine.

The troublesome cell phone that we know of is a Verizon Wireless cell phone. My cell phone is T-Mobile. I suppose it’s possible that all of the problematic voicemail boxes are Verizon Wireless devices . . . but there’s no real way to know that.

It’s a UCM 6202 with firmware

Any ideas?


Is RTP keep-alive enabled? What is rtp timeout period?


Is this via PSTN or SIP ?


It’s SIP.


RTP Keep-alive is set at zero, presently, which means there is none.

RTP timeout is set to 90.

The thing is - there is audio coming from the cell phone’s voicemail greeting to the GXP-2170 right up until the call dies.


Try adding all codecs to the SIP trunk and extension then try making a call again


audio from the cell would be rtp timeout. audio from the ucm is keep-alive. set the keep-alive for 30 secs and see if a difference.


Good afternoon.

I tried both solutions - I set more of the common codecs on the trunk and extension - but not all of them. Previously it was just PCMU on the trunk.

I also set the keep-alive at 30 seconds, then lowered it to 10, then 5. (PBX Settings -> SIP settings -> ToS -> RTP Keep Alive.)

I finally got the client to test it today - still not working.

They tested calls to the voicemail of three VZW devices today, same results for all three. While this is by no means definitive proof that the problem is isolated to VZW devices, it is curious. The problem does not occur on calls to my T-Mobile device.

Any other ideas? Do I need to get the carrier involved?


Is it possible the number has been associated as spam and VZW does their thing to the call?


It’s possible, I suppose. Nothing like that pops up on the screen when the caller ID is displayed. And the VZW user can pick up the call and talk as normal. The call doesn’t die when the callee answers the call. Only when they let it go to voicemail on the cellular device. The caller gets the audio of the first 5 or 10 seconds of the voicemail greeting, then the call just goes dead.

A little more information. On the UCM CDR, the call shows as 48 seconds of call time, but 0 seconds of talk time. The symbol next to the call is orange - which I believe means the call was not successful.

On the carrier’s CDR, it shows the calls, lists the status as “answered” and lists the call length as 12 seconds.

Don’t know if that additional info is helpful or not.

And more information - I just mirrored this client’s setup to a spare system I have in my office and I’m encountering the very same behavior.


Then a capture is in order. Need to see who/what is sending the BYE.


Hopefully this file will show what’s going on. I believe that the UCM is sending the BYE, but that’s as far as my experience can take me at present. What I can’t determine is “Why?”

If you listen to the audio RTP stream, you hear the ringing and the first few seconds of the VM greeting. I did not hear the first few seconds of the greeting on the handset. The audio to the handset was cut off after the last ring.

capture-C074AD14671B.zip (358.1 KB)


First get rid of some of the extraneous codecs (make them the same) and extra headers in the 2170.

The INVITE is too long and the packet is being fragmented.

The phone is ending the call - image

It takes approx 31 seconds for the VZ mailbox to answer the call (200OK). The phone then sends a BYE some 417ms following the 200 OK and following some 12ms following the ACK. Very strange indeed.

As the traces are from the UCM, I do not know if the GXP saw them differently .

It would be interesting to see the same call to T-Mobile (working) for comparison.


Thanks, Larry.

Here is a capture of a successful call to my T-mobile cell’s voicemail box:

capture-C074AD14671B-2.zip (396.3 KB)

And here is a call from the GXP’s point of view to the problem VZW cell’s voicemail. However, this one was actually successful. I think the timeout (wherever it is occurring) is right on the edge of the length of time it takes for a call to a default-set-up VZW cell voicemail.

captures (1).tar (577.5 KB)

I’m off to look for timeout settings at the phone level.



I found a setting on the GXP under Account x -> SIP Settings -> Basic Settings -> SIP T2. I increased this from 4 seconds (default) to 8 seconds. Testing on the system in my office appears to work.

We’ll see how it goes “in the wild” for my client going forward.

I did also take out all of the codecs except for PCMU. Is there some other setting that is cluttering up the header?


Rats. I spoke too soon. Client tested and it timed out again. I’ll keep looking for other ways to keep the phone from timing out and sending the BYE signal . . . any suggestions welcome!


Update - I’m finding things in the manual that are over my head. In the area on th GXP Account -> SIP Settings -> Basic Settings there are SIP T1 Timeout (default .5 seconds), SIP T2 Timeout (default 4 seconds). I changed SIP T2 from 4 to 8, and that seemed to work on my test system. Not working for the client.

On the DP750’s, (my client’s test device) there are more settings: SIP Timer D, Enable OPTIONS Keep Alive, OPTIONS Keep Alive Interval, OPTIONS Keep Alive Max Lost . . .

Am I barking up the wrong tree, here?


Good morning.

Still looking for help in preventing the phones from timing out in the long wait for VZW cell phone voicemail to pick up - any ideas?

Or should I open a ticket with Grandstream?


I saw one other using Asterisk 13 claiming the same issue and using Vitelity. They claimed that enablimg qualify (heartbeat) solved the issue, but did not mention how they had the router setup.

Are you forwarding the ports?


Where would I find the “qualify (heartbeat)” setting?

I think we determined that the phone is sending the BYE signal, so I’ve been focusing my attention on the phone’s settings . . . but perhaps I’m looking in the wrong place?

Yes, the ports are forwarding from the router to the UCM - 5000-5100 and 10000-20000, both UDP. The router is pulling the public IP directly from the ISP, no double-NATing.


It is on the second page (Advanced Settings) of your VoIP Trunk.