Calls not going to Voicemail

Unanswered Question
Apr 5th, 2010

What would cause incoming external calls to stop going to voicemail, requiring a UC540 to be power-cycled to restore that functionality.  The UC540 is configured with inbound sip trunks which all are sent to a blast group with 30 second timeout and a no-answer forward to 401.  All phones in the blast group have a 35 second timeout.  This works fine for a while, often several days, but then unanswered inbound calls stop going to voicemail after 30 seconds and the caller just hears continued ringing.  The blast group phones stop showing the incoming call after 30 seconds, but it never gets routed to voicemail.   Voicemail is working, however, for internal calls, and there seems to be no communication issue with CME contacting CUE using the configured IP addresses.  So far, the only cure I've found for this issue is to power-cycle the UC540, which, needless to say, is very disruptive.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
David Trad Mon, 04/05/2010 - 15:15

Hi aapexisinc,

Taking a wild guess here, your issues does sound like it could be a transcoding issue. However we may need to see some debugs of when then problem is happening so we can see what is actually going on, so if possible can you please do the following debugs and post them when the issue arises again :)

  • debug ccsip all (Carefull not to run it too long, it may crash the system)
  • debug voip dialpeer all
  • debug voice ccapi inout (Not sure if you should do this one, given that there might be too much traffic already going on)

Make sure to "term mon" after you enter the debugs, and once you finished debugging, run the "un all" command and then "term no mon" to stop everything.

I am interested in seeing what is going on and to why it is happening.



aapexisinc Mon, 04/05/2010 - 16:46

Will do... I should be able to get debugs tonight, since the UC540 hasn't

been power-cycled yet.

aapexisinc Tue, 04/06/2010 - 08:38

Well, I thought the debugs were crashing the UC540, but in fact they are not.  What happens is, when the debugs are enabled, an incoming call locks up the UC540, it drops any in-progress calls, disconnects the VPN, then will not accept any new calls (the caller just hears dead air, no ringing).  After a couple of minutes, the UC540 relaxes and the VPN can be reconnected to disable the debugs.  This is true with or without the debug voice ccapi inout.  Any ideas how to proceed?

David Trad Tue, 04/06/2010 - 12:57

Hi aapexisinc,

Firstly can you please provide me with your running configuration, just make sure all sensitive information like usernames and passwords are either removed or blanked out.

Secondly, I would have suggested you get TAC on this imediatly but since these boxes are not covered under TAC, that would be fruitless :( I have no clue how the SBSC team can debug this problem using CCA, unless they have a hidden side to CCA that we do not have, then their visibility of the system is pretty much the same as yours, which pretty much ties their hands.

It sounds like the system is running out of resources, and locks up, but then after the process gets killed of it goes back to normal.

Is it possible to force all your outbound and inbound calls to use G711ulaw as the preferred Codec, will your ISP support this? If so this will be a good test to see if the system locks up or not.



David Trad Wed, 04/07/2010 - 02:13

Hi aapexisinc,

As far as I know, all calls use the G711ulaw codec.

From what I can see yes, you are forcing one single Codec via:

voice class codec 1
codec preference 1 g711ulaw

However I can see you have no transcoding setup at all, not even sure if your DSP's are registered, you would need to run the following command for me:

ROUTER# sh dspfarm all

I highly recommend you setup Transcoding on the box, and also setup the conferencing facility, even if you are not going to use the, you should allocate them anyway as you never know when they may need to be used, and you can always remove them from the equation when diagnosing any faults.

If you are not sure how to set this up, i can provide it to you in a TXT based format, and I may not be within the CCA OOB guide lines, but if you are ok with that, then I am happy to do this up for you and provide it to you with some basic instructions on how to apply them.

We could be heading down the wrong track here, but this is normally the first port of call I do, it is a good exercise and a good habit to get into in my books.

I think we can solve the problem, and you have two ways of doing this:

  1. Log a TAC case after we do some more preliminary work
  2. If you are comfortable with it, provide me with SSH acces with a temp username and password and I will debug it with you, or we can do this via a remote desktop application that i use so you can see exactly what is being done.

Either way i am sure it will get resolved for you, i dare say it is something quite simple and will be resolved with 1 command :)



aapexisinc Wed, 04/07/2010 - 11:56

Thanks for your reply, David.  Conferencing can be enabled with CCA, but I can't see any options for transcoding.  Shouldn't that have been set up by CCA to match the SIP provider (in this case, Cbeyond)?  And how could transcoding affect whether or not an unanswered call goes to voicemail?

The sh dspfarm all output is attached.

I don't believe I can open a TAC case with the UC540, since there is no SmartNet contract, only the SBCS maintenance.  We could debug using remote desktop, but it will have to be coordinated so that we don't disrupt their business.

Thanks, again.


David Trad Wed, 04/07/2010 - 19:24

Hi Richard,

The sh
dspfarm all output is attached.

So nothing is configured it would seem.

I don't believe I can open a TAC case with the UC540, since there is no
SmartNet contract, only the SBCS maintenance.

You just reminded me i have a bit of getting used to the new setup :( this is yet to be proven how sucessfull it would be pitted up against TAC's ability to respond and resole break-fix cases.

Conferencing can be enabled with CCA, but I can't see any options for
transcoding.  Shouldn't that have been set up by CCA to match the SIP
provider (in this case, Cbeyond)?

To be brutally honest I dont use CCA to do the SIP stuff, it has in the past created just too many complications for me, plus they do not support any Australia SIP providers (Maybe Engine not sure haven't looked at the latest version of 2.2.2), I just do things on the CLI, quick, easy and I have templates already in place.

I never ship a box out unelss transcoding and conferecning is setup, even if the client is not going to use it i still do it, you never know if it will be getting used as things 80% of the times change once the system is installed, nothing ever goes to the original plan.

And how could transcoding affect whether or not an unanswered call goes
to voicemail?

Well the CME talks to the CUE using SIP sine they are entirely different devices/appliances, so there is codec negoitiations (Or forced depending on the config) so there is that layer that needs to be taken into consideration. It is purely at the off chance that something is not right with the SIP trunk and the communication layers, i dont know what the final codec is that is being used even if you are forcing G-711uLaw, the carrier might still be trying to force G729 at their end, without debugs i can not confirm this. I have seen in the past that even when you force a codec on a SIP trunk that codec may not get used but yet calls still progress and work.

Happy to setup an RDP session with you, although I am not sure of the time zones, and I would assume you would want to do this after hours your time to it does not interfere with the business operation.

I have attached proposed config changes, the XXX's represent what you need you assign there, the rest is pretty straight forward. Keep in mind I do not believe this will comply with CCA OOB guide lines, so if you are not fussed about that, then feel free to implement it.

Again I point out that this is just what I am proposing, and I reiterate that this may be way of the beaten track to resolving your problem, but it is always the first place I start when looking at problems like this.

Let me know when would be a suitable time to do an RDP session with you, your local time is suffice i will work out it my end and try to organize it with you.



aapexisinc Thu, 04/08/2010 - 01:38

The debugs crashed the UC540, so I'll have to wait until the problem recurs

to try it again without the debug voice ccapi inout.


This Discussion