I have an interesting problem that has started as soon as I configured pager notification.<br><br>Once a list of pagers goes out for notification (notification is limited to 3 ports of 16) the first error shows in the event log:<br><br>Component Miu: Thread 0x00000E44 had a Failure on Port 9 in Method CAvMiuTapiLine::MakeCall()<br><br>DESCRIPTION: TAPI lineMakeCall() failed with 0x80000048 (LINEERR_OPERATIONFAILED).<br>DETAILS: <br> DestAddress: 917705536963<br> TAPI DeviceID: 14<br> Service Provider: SelsiusTSP.TSP.<br>CALL SEQUENCE:<br><br><br>Followed by:<br>Component Miu: Thread 0x00000BA4 had a Failure on Port 12 in Method CAvMiuTapiMonitor::GetCallStatus()<br><br>DESCRIPTION: TAPI lineGetCallStatus() failed with 0x80000050 (LINEERR_UNINITIALIZED).<br>DETAILS: <br> HCALL: 0x000108C8<br> TAPI DeviceID: 17<br> Service Provider: SelsiusTSP.TSP.<br>CALL SEQUENCE:<br><br>Followed by:<br>Component Miu: Thread 0x00000BA8 had a Failure on Port 13 in Method CAvMiuLine::DropByMonitor()<br><br>DESCRIPTION: DropByMonitor() called lineDrop() 1 times with result UNDEFINED HRESULT..<br>DETAILS: <br> HCALL: 0x00010ADB<br> CallState: LINECALLSTATE_UNKNOWN<br> Monitor HCALL: 0x00010413<br> Monitor CallState: LINECALLSTATE_UNKNOWN.<br>CALL SEQUENCE:<br><br>Then:<br>Component Miu: Thread 0x00000E44 had a Failure on Port 9 in Method CAvMiuTapiLine::MakeCall()<br><br>DESCRIPTION: TAPI lineMakeCall() failed with 0x80000050 (LINEERR_UNINITIALIZED).<br>DETAILS: <br> DestAddress: 917705536963<br> TAPI DeviceID: 14<br> Service Provider: SelsiusTSP.TSP.<br>CALL SEQUENCE:<br><br>After it repeats this for every pager that is being hailed six times, the server wanders off to never-never land. You can still reach the server, and the services are all still happy and running, but it's not taking any calls.<br><br>As soon as the calls to pagers begin failing, the telephony service takes a nosedive.<br><br>The Telephony service terminated unexpectedly. It has done this 1 time(s). The following corrective action will be taken in 0 milliseconds: No action. <br><br>I have tried setting the service to try to restart itself but I doubt that will work as the dependency list is quite long for this service.<br><br>Any ideas? Need more info?<br><br>Matt Slaga <img src="/images/icons/wink.gif"><br>Dimension Data US<br><font color=red>MCNE</font color=red>, <font color=blue>MCSE2k</font color=blue>, <font color=purple>CCIE #8629 Unity Systems Engineer</font color=purple>
Just a word of advice, from the event log errors that were posted, it looks like MIUGeneral 0-4 traces have been turned off. We usually recommend that these stay turned on. These flags never write anything unless there are hard failures like these, and when they do write, they provide a little history of what is happening in the code previous to when things go bad. They can be re-enabled via Maestro.
These were probably turned off due to another problem that the system was experiencing. During this other problem (that is still occuring) TAC asked for specific flags to be set in Maestro. I will turn them on again.
Matt Slaga Dimension Data US MCNE, MCSE2k, CCIE #8629 Unity Systems Engineer
Good deal. I took a closer look at things. The MIUGeneral 0-4 flags will provide a little more context on the calls that are choking up the system. However, the real answer will most likely come from TSP traces and debugging. There's an exception being thrown in lineMakeCall ( the main function called during pager and/or message notification ). I'd continue to work with TAC on gathering TSP traces on this issue. It would also be worthwhile to check to see if there was any DrWatson logging corresponding to TAPISRV taking a dive.
Just to set expectations, this is probably an issue that TAC will have to escalate to development. There's a similar lineMakeCall issue that I am currently working on, but it happens under a very specific condition: a lineMakeCall when the connection to CCM has gone down. From the error messages generated, it looks quite similar to this, but is indeed quite different.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...