[cisco-voip] Stuck conferences on 2911

Brian Meade (brmeade) brmeade at cisco.com
Mon Feb 3 15:08:17 EST 2014


Eric,

The call should stay up if signaling is lost as long as RTP remains active.  There's a "timer receive-rtp" and "timer receive-rtcp" that controls those type of call clearings.  In a case like this though, it's most likely something about the SCCP communication with CUCM that is resulting in the connections on the gateway not being torn down 100%.

Brian

From: Eric Pedersen [mailto:PedersenE at bennettjones.com]
Sent: Monday, February 03, 2014 3:02 PM
To: Brian Meade (brmeade); cisco-voip at puck.nether.net
Subject: RE: Stuck conferences on 2911

Thanks Brian. I'll keep an eye on it. I enabled debugs for sccp events and errors so if it happens again hopefully I'll get some information from the router. I have no idea how long these calls have been there.

Do you know what normal behavior is if communication breaks between a bridge and its CUCM while calls are active? Does the call stay up like a phone to phone call or is it immediately dropped?

Thanks,
Eric

From: Brian Meade (brmeade) [mailto:brmeade at cisco.com]
Sent: 03 February 2014 12:29 PM
To: Eric Pedersen; cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: RE: Stuck conferences on 2911

Eric,

The way I've usually resolved these issues is running the show sccp conn hourly until I can identify a recent inactive resource and then pull the realted CUCM traces and search for those conn_id's until you can find the call that triggered the condition.  Last time I saw this issue, I was able to narrow it down to CSCtx65886 but you should have the fix for that in 9.1.2 so you're probably looking at a different issue.

Brian

From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Eric Pedersen
Sent: Monday, February 03, 2014 2:16 PM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] Stuck conferences on 2911

We're using 2911s for conferences bridges, and we've been having reports of conferences failing. I looked at one of the routers and it shows inactive connections that never clear:

BH-VOICE-GW1#show sccp conn
sess_id    conn_id      stype mode     codec   sport rport ripaddr conn_id_tx

145723183  134217789    conf  inactive UNKNOWN 23566 0     UNKNOWN
145913733  134269533    conf  inactive UNKNOWN 27940 0     UNKNOWN

Total number of active session(s) 2, and connection(s) 2

The CUCM performance counters show that this gateway has full conference resources available so it doesn't know about these connections. I don't know how long these have been on the router. I saw this on another router. no sccp/sccp cleared them but I'd like to know what the cause is.

Has anyone seen this?

CUCM 9.1(2)SU1 and IOS 15.1(4)M6

Eric

The contents of this message may contain confidential and/or privileged

subject matter. If this message has been received in error, please contact

the sender and delete all copies. Like other forms of communication,

e-mail communications may be vulnerable to interception by unauthorized

parties. If you do not wish us to communicate with you by e-mail, please

notify us at your earliest convenience. In the absence of such

notification, your consent is assumed. Should you choose to allow us to

communicate by e-mail, we will not take any additional security measures

(such as encryption) unless specifically requested.



The contents of this message may contain confidential and/or privileged

subject matter. If this message has been received in error, please contact

the sender and delete all copies. Like other forms of communication,

e-mail communications may be vulnerable to interception by unauthorized

parties. If you do not wish us to communicate with you by e-mail, please

notify us at your earliest convenience. In the absence of such

notification, your consent is assumed. Should you choose to allow us to

communicate by e-mail, we will not take any additional security measures

(such as encryption) unless specifically requested.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140203/4a283ac7/attachment.html>


More information about the cisco-voip mailing list