I'm experiencing a very interesting problem within my CUCM cluster. Imagine that we have a simpe internal call between two IP phones within a single cluster. This is a single site deployment, so the call setup is pretty simple: no trunks, no gateways, just two IP phones (7965) that are successfully registered with the same CUCM server (publisher).
So, the call is being established from Phone 1 to Phone 2 and there's nothing wrong with it. Phone 2 answers, and we have an RTP media stream between the phones (no media resources involved). Now imagine that Phone 1 powers off: for example, we suddenly unplug the Ethernet cable. Phone 2 "thinks" that the call is still ok, and the active call timer on the screen keeps going. The problem is that this situation seems permanent. I mean, Phone 2 just keeps "thinking" that connection is still present, and it stays in the same operational state for a really long time. I've been waiting more than 30 minutes for call disconnect and nothing really changed: the conversation timer keeps ticking. It seems really odd, because CUCM can obviously detect that Phone is not reachable during this period. If you try to check the phone state in the CUCM, you can find that Phone 2 is still registered, but Phone 1is unregistered (which is expected). Seems that the CUCM does not notify Phone 2 about the Phone 1 outage.
I'm using CUCM 8.0 but the same situation is present on the CUCM 10.
I was expecting to find some timer or service parameter that regulates this situation, but with no luck. But I believe, someone has already leveraged this. Any thoughts and suggestions will be highly appretiated.
The only timer / parameter that i can see related to this is "Maximum Call Duration Timer" . This parameter specifies the minutes that a call can remain active before Cisco CallManager clears it. A value of zero disables the timer. Default value is 720 minutes.
Regarding the call staying up after a phone is powered off, i believe its because the CUCM is already out of the picture at that point of time since RTP is flowing directly between the endpoints.
I am also looking forward to thoughts from others on this interesting topic.
I also was thinking about the "Maximum Call Duration Timer". But it does not leverage this problem in a correct manner. Of course, we can specify something like 5 minutes, but this will also affect all active calls established in this cluster.
I totally agree with you: the CUCM is out of the picture after the call was established and RTP flow started. But I would expect CUCM to notice that Phone 1 is no longer registered (according to keepalive timeout) and clear all active calls, in which this phone was involved. Obviously CUCM does not do that and I would like to know how to fix this.
Once a call has been established, the rtp will be between two endpoints,in your case we have the two IP phones. When you disconnect the IP Phone, check if the stream is still active by pressing the "?" button twice. If it is still sending and receiving, than we have some other equipment in the flow, keeping the stream active. if you can, collect captures from one phone and disconnect the other one during the call.
After you power off the Phone 1 and press ? button twice on Phone 2 you will notice that Phone 2 does not receive packets anymore. The RecvPackets counter just freezes, while SenderPackets counter keeps increasing. I'm sure this means that Phone 2 proceeds generating RTP streem without really receiving anything.
There's no way to disable SIP call preservation that I know of. CUCM keeps the call up in case the phone just lost connection to CallManager but still has a connection to the other phone for the RTP stream. Usually you would want this feature for cases like this where CallManager goes down and you don't want the active calls to fail. Usually the phone will print "CM Down" when the other phone unregisters on the same cluster.
Some devices that fork media through them such as CUBE, hardware MTPs, conference bridges, etc. will have a media inactivity timer you can enable to drop the calls since they are part of the media path.
Some phones should be able to use RTCP data streamed between them to drop the calls as well but not sure if they all support that or if it actually functions properly as I haven't tested it.
Usually a call preservation scenario will always require both sides of the call to disconnect the call individually.
IntroductionCUCM Routing RulesDial String implementation PolicyCUCM Routing LogicSIP URI Call Routing Analysis+++ Case Study: 1 ++++++ Case Study: 2 +++Conclusion
Over the last few months, I have had the privilege of working on SI...
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...