Need some dial-peer assistance (I think).

[johnk]

We had a CME - CUE integration that was working well.  All pieces appear to be online.

I need assistance with when we dial the automated attendant as well as the voicemail pilot number, we get dead air, then a ring and then a busy.

We are getting some disconnect cause 41 messages and some SIP2.0/500 internal server error messages.

What can I generate and post that will be most helpful in isolating the issue?

Attached is my running config but it is long.

[R0g22]

Do a "show trace buffer tail" on the CUE CLI, make a test call and collect the logs once done.

[johnk]

Ok here it is. 

Thanks!

[johnk · Accepted solution]

No clue why but reloading the module with

service-module inte 0/0 reload

fixed the issues - I can now put some hair back in my head.

Thanks All.

[R0g22]

Was there a power outage or some sorts ?

[johnk]

I'm unsure if there was a power outage other than the system was moved (powered off - moved - powered on) and perhaps it never booted properly. 

I'm happy though as it is working and was a bad day when it wasn't.

John

[R0g22]

Indeed. Out of curiosity I took a look at the logs that you added and saw the following -

4987 04/23 11:32:21.799 ACCN LMED 0 EXCEPTION:java.io.IOException: Broken pipe
4987 04/23 11:32:21.800 ACCN LMED 0 EXCEPTION:at sun.nio.ch.FileDispatcher.writev0(Native Method)
4987 04/23 11:32:21.801 ACCN LMED 0 EXCEPTION:at sun.nio.ch.SocketDispatcher.writev(SocketDispatcher.java:33)
4987 04/23 11:32:21.880 ACCN LMED 0 EXCEPTION:at com.cisco.executor.impl.ExecutorStubImpl$RequestImpl.run(ExecutorStubImpl.java:486)
3930 04/23 11:32:22.638 ACCN SIPS 0 EXCEPTION:com.cisco.util.msgq.MsgQTimeoutException
3930 04/23 11:32:22.687 ACCN ENGN 0 com.cisco.wfapi.WFExecutionException: Task:23000000616 AcceptStep: Could not answer call. ; nested exception is:
java.lang.NullPointerException
at com.cisco.wf.steps.ivr.AcceptStep.execute(AcceptStep.java:154)
at com.cisco.wfframework.obj.WFBeanStep.executeImpl(WFBeanStep.java:166)
at com.cisco.wfframework.obj.WFStep.execute(WFStep.java:175)
at com.cisco.wfframework.obj.WFWorkflowTask.executeStep(WFWorkflowTask.java:494)
at com.cisco.wfframework.engine.core.WFEngineWorkflowTask.executeStep(WFEngineWorkflowTask.java:124)
at com.cisco.app.impl.WFWorkflowAppDebugTaskWrapper.executeStep(WFWorkflowAppDebugTaskWrapper.java:382)
at com.cisco.wfframework.obj.WFWorkflowTask.execute(WFWorkflowTask.java:360)
at com.cisco.wfframework.engine.core.WFEngineWorkflowTask.execute(WFEngineWorkflowTask.java:79)
at com.cisco.app.impl.WFWorkflowAppDebugTaskWrapper.execute(WFWorkflowAppDebugTaskWrapper.java:702)
at com.cisco.wfframework.engine.core.TaskManager.runTaskNormally(TaskManager.java:421)
at com.cisco.wfframework.engine.core.TaskManager.runTask(TaskManager.java:376)

Seems like the SIP stack could not come up properly on the CUE. In java, the exception that we see occurs when we declare a variable but did not create an object. If you attempt to dereference the variable defined BEFORE creating the object you get a error. Obviously this is not the case here and it recovered with a reboot.

[johnk]

The really weird part is I issued a reload from within the SRE and it didn't repair the issue. I don't know why it worked as I assume the service-module int 0/0 reload is the same command.

[R0g22]

That's weird. Reload from within the CUE cli and/or from IOS cli does the same thing. The "reset" keyword however is a hardware reset.