06-18-2013 09:32 AM - edited 03-16-2019 05:56 PM
Hello Cisco Gurus! I seek your assistance again with a weird issue I cannot seem to pinpoint myself.
I have a customer that has 3 Biamp VoIP-2 Cards that are using SIP to register to my CUCME system. Thanks to one of you already, they are registering and able to make and receive calls with good quality. The issue arises when a call has been established for about 25-30 minutes it suddenly disconnects with no warning. The 3rd party device seems to stay registered to the CUCME but the call drops. I was able to collect some debug and show sip-ua commands that are hopefully helpful in diagnosing this issue. I appreciate any lead or suggestion as I've met the end of my rope and my customer is quickly losing their patience.....
Some SIP config info and debugs are attached. Thanks again!
Tom Fredericks
06-18-2013 09:38 AM
I've seen this already many times without finite answer yet.
I can only recomment your customer to use all Cisco phones, or try a TAC case, and have a lot of patience.
06-18-2013 12:15 PM
Some research I've done indicates the CUCM might be sending a duplicate INVITE message to the SIP endpoint causing the active call to be dropped. If this is the case there must be a place in CUCME to configure timers or something and control how often these messages are sent....do you agree?
06-18-2013 01:10 PM
I've never seen a conclusive, proven explanation, so I can't tell what is wrong and why.
06-18-2013 05:11 PM
You may capture:
deb voice ccapi inout
deb ccsip all
For all the call. A BYE message tell us nothing.
From the TAC perspective, there is a best effort with 3rd Party SIP Endpoints, since there has not been any compatibility testing to ensure that that device will work correctly with CME. TAC only checks if the issue is not related to CME.
--
Jorge A.
--
Jorge Armijo
Please remember to rate helpful responses and identify helpful or correct answers.
06-19-2013 04:02 AM
Thanks Jorge -
While I'm not a SIP expert, I was under the impression that I provided more than just a BYE message. The debug I have attached provides a disconnect cause code of 86 and I was hoping that someone on the forum might have seen this before and recognize a possible root cause. Some of my research indicates that a adjusting a SIP timer might prevent duplicate INVITE messages being sent, which might be causing the disconnect.
Thanks for your suggestions.
Tom
06-19-2013 04:28 AM
While I'm not a SIP expert, I was under the impression that I provided more than just a BYE message. The debug I have attached provides a disconnect cause code of 86 and I was hoping that someone on the forum might have seen this before and recognize a possible root cause. Some of my research indicates that a adjusting a SIP timer might prevent duplicate INVITE messages being sent, which might be causing the disconnect.
You said that already but you did not prove that duplicate INVITES were sent and/or what is the consequence.
You can take the required traces and work technically, or keep formulating theories, and not getting anywhere..
06-19-2013 04:38 AM
Sheesh...I didn't realize that asking a question about a disconnect code was formulating a theory and not working technically. In fact it wasn't my theory at all. I was asking the technical experts if they knew if the SIP timers in CUCM were configurable. I'm in New York and my customer is in Paris. As you can imagine there are some challenges in coordinating test calls for traces to be collected. I'm in the process of getting that set up now.....
06-19-2013 07:11 PM
Please look at:
http://www.cisco.com/en/US/docs/ios/voice/monitor/configuration/guide/vt_ccodes_debug.pdf
Call having the
requested call
identity has been
cleared
Typical scenarios include:
•
Network timeout
•
Call cleared by remote user.
86 Indicates that the network has received a
call identity information element
indicating a suspended call that has in
the meantime been cleared wile
suspended.
Perhaps there is an "update" missing and CME decides to terminate the call, that's why is so important to see the whole signaling.
HTH
--
Jorge Armijo
Please remember to rate helpful responses and identify helpful or correct answers.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: