Jabber calls not clearing correctly (lingers forever on MCU) if call is interrupted
Scenario: An H.323 MCU contains a jabber.com client (SIP) in the conference. If the jabber.com client gets its network connection disconnected, a frozen picture remains forever on the conference.
Other sites connected to the same conference see a frozen image from the jabber.com client and then after a few minutes later black video. Call signalling and media are still active on both VCS and MCU. Have VCS Expressway and VCS Control, Control is doing the interworking.
Am on VCS X8.1.1, at first I thought it was Bug CSCtz35304 cropping up again, but it was found that other SIP clients (Movi, Lync, SIP endpoints) are not affected. On other SIP clients, if there is abnormal disconnection and the call 'lingers' it does clear at a time matching the SIP Session refresh interval set on the VCS, am set to 1800 so those calls clear after 30minutes.
TAC have advised I should raise the issue in this forum
(TAC REF : SR 630974193)
The issue is easily reproducible:
From a jabber.com client, connect to a H.323 MCU conference.
Whilst in call, remove the network connection from the jabber.com client. (disconnect the RJ45 connector or disable wireless adapter) The jabber.com client appears to disconnect from the user perspective, but the call lingers on the VCS and MCU.
Jabber.com calls in this scenario need to be manually disconnected from the MCU by an administrator, or the call sits there forever consuming bandwidth and MCU video ports.
I'm not sure this would help in your situation, but if the MCU isn't receiving any media from the Jabber Video client, than the MCU can automatically disconnect the endpoint after 30 seconds to 1 minute if you're running MCU 4.5 software.
I have this issue too, a bit different because it's with cucilync clients connected through a SIP trunk with CUCM and VCS, but it's the same cause I guess.
The calls last forever. I cannot upgrade the MCU to 4.5 because of another bug in 4.5 which is not resolved yet.
But for me, the root cause is more located in the VCS than in the MCU. In the VCS Call history I can see the call durations being 1 or 2 days. It means the VCS itself maintains the call, even if the remote endpoint is not there.
Should not be a SIP timer exist to monitor the remote endpoint and release the associated active call after a defined time? If the SIP endpoint (cucilync in that case) is no more present, then the VCS should clear the call, and the in the MCU as well of course.
In the CUCM I see the call duration normal, corresponding to the real disconnection of the SIP endpoint, with original cause code 41 (temp failure). So I guess it's sent to the VCS, but the calls is not disconnected.
Cisco Jabber for iPad enables you to make and receive video calls to and
from business contacts or join telepresence meetings from your iPad. You
can enjoy video calling with standards-based video devices and bridges
including deployments of Cisco TelePre...
The first time you open Cisco Jabber Video for TelePresence, you can
test your computer’s microphone, speakers, and camera to ensure the best
video calling experience.Do any of the following: To test the
microphone: Select the microphone you want to test....
You can get Cisco Jabber Video for TelePresence in one of two ways:If an
existing Cisco TelePresence customer sends you an email invitation to
get Jabber Video, click the link in the email to download the
application.Go to http://ciscojabbervideo.com and ...