cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1408
Views
0
Helpful
8
Replies

3rd Party SIP Endpoints - CUCME v7.1

twfredericks
Level 1
Level 1

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

8 Replies 8

paolo bevilacqua
Hall of Fame
Hall of Fame

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.

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?

I've never seen a conclusive, proven explanation, so I can't tell what is wrong and why.

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.

-- Jorge Armijo Please remember to rate helpful responses and identify helpful or correct answers.

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

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..

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.....

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.

-- Jorge Armijo Please remember to rate helpful responses and identify helpful or correct answers.
Getting Started

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: