Guest

Preview Tool

Cisco Bug: CSCut45472 - Changing RCC device selection during calls may cause SIP Proxy to core

Last Modified

Jul 04, 2017

Products (6)

  • Cisco Unified Communications Manager IM & Presence Service
  • Cisco Unified Communications Manager IM and Presence Service Version 10.5
  • Cisco Unified Communications Manager IM and Presence Service Version 9.1
  • Cisco Unified Communications Manager IM and Presence Service Version 10.0
  • Cisco Unified Presence Version 8.6
  • Cisco Unified Communications Manager IM and Presence Service Version 11.0

Known Affected Releases

10.0(1) 10.5(1) 10.5(2) 11.0(1) 8.6(5) 9.1(1)

Description (partial)

Symptom:
Cisco SIP Proxy service cores shortly after a user changes the phone device which they are controlling from Microsoft Lync via Remote Call Control.

Conditions:
- A CUCM/Lync user has two or more phone devices which they can select to control via Remote Call Control from Lync.
 - One of the phone devices has its directory number configured to support a greater "Maximum Number of Calls" than the other phone device/s.
 - The Lync user is controlling the phone device which has the greater "Maximum Number of Calls" value.
 - By either making calls, receiving calls, or both, the user ends up with the maximum number of concurrent calls allowed on their device.
 - Using the Lync Remote Call Control plugin, the user now changes the device which they wish to control via Remote Call Control to a device which has a lower "Maximum Number of Calls" value than the currently selected device.
 - The user begins to resume calls on the newly select device, until it reaches its configured "Maximum Number of Calls".
 - As this device cannot support as many calls as the previously select RCC device, there will be some calls remaining on the previous device. The user decides to end these calls. This action will cause the Cisco SIP Proxy service to generate a core file.

For example, here a simplified sequence to illustrate the conditions:
1. User 'UserA' has 2 CUCM phone devices. Device1 and Device2.
2. Device1 can support a "Maximum number of calls" of 1, while Device2 can support a "Maximum number of calls" of 2. This can be configured from CUCM on the Directory Number for each phone device.
3. UserA has selected Device2 (using the Lync Remote Call Control plugin) as the device which they wish to control via Remote Call Control from Lync.
4. UserA either makes or receives a call on Device2.
5. While the first call is still up, UserA then either makes or receives another call on Device2. The first call will be put on hold and can be resumed from either Device2 or Device1.
6. UserA ends up with two calls on Device2.
7. While both calls are active (the first call will be on-hold) UserA decides to change the device that they are controlling via Remote Call Control. Using the  Lync Remote Call Control plugin, UserA selects Device1 as the device to control from Lync.
8. The change does not take effect as UserA has a call in progress on Device2. This is by design.
9. From Device1, UserA resumes the first call.
10. As Device1 can only support a maximum number of calls of 1, it is not offered the second call to resume. UserA ends the second call on Device2.
11. As Device2 is now no longer in a call, the Remote Call Control device selection change which was made earlier can now be executed. The Cisco SIP Proxy service generates a core file as a result.



Here is a example of what the core analysis would look like:

#0  0x005df430 in __kernel_vsyscall ()
#1  0x0046eb46 in kill () from /lib/libc.so.6
#2  0x0817114d in sig_coredump (sig=11) at mpm_common.c:1183
#3  <signal handler called>
#4  0x081b046e in ctigw_csta_callStateEvent_handler (call_dir=0, qbeCallStateEvent=1, cgPty=0xffdd164c "9102", cdPty=0xffdd1661 "9105", scb=0xe8e7d270, callIdx=1, reason=1, cause=16, bCallingPartyPi=-1,
    remoteInUse=0, cgDev=0xffdd167f "CIPCCAPTAMERICA") at mod_sip_ctigw.c:5748
#5  0x081b1f72 in ProcessQBECallStateEvent (cmID=1, lineID=2, callID=30825692, ciCmID=1, cState=1, cCause=16, cReason=1, cgPty=0xffdd164c "9102", cgPtySize=5, cdPty=0xffdd1661 "9105", cdPtySize=5,
    cgDev=0xffdd167f "CIPCCAPTAMERICA", cgDevSize=16, bCallingPartyPi=-1, remoteInUse=0) at mod_sip_ctigw.c:3662
#6  0x082c88ef in receiveQbe (Buffer=0xe865196e "U\005", MessageLength=1373, cm_node=0) at qbereceive.cpp:231
#7  0x081acc51 in ctigw_proc_non_sip (r=0x8e3f3f0) at mod_sip_ctigw.c:4612
#8  0x0822818a in sip_process_ipc_message (c=0x8e3eec8) at mod_sip.c:607
#9  0x0819a6d9 in child_main (child_num_arg=<value optimized out>) at prefork.c:900
#10 0x0819aa13 in make_child (s=0x8cce3c0, slot=17) at prefork.c:1041
#11 0x0819b40c in startup_children (_pconf=0x8cc63a0, plog=0x8d22510, s=0x8cce3c0) at prefork.c:1059
#12 ap_mpm_run (_pconf=0x8cc63a0, plog=0x8d22510, s=0x8cce3c0) at prefork.c:1419
#13 0x08154814 in main (argc=2, argv=0xffdd5f14) at main.c:717
Bug details contain sensitive information and therefore require a Cisco.com account to be viewed.

Bug Details Include

  • Full Description (including symptoms, conditions and workarounds)
  • Status
  • Severity
  • Known Fixed Releases
  • Related Community Discussions
  • Number of Related Support Cases
Bug information is viewable for customers and partners who have a service contract. Registered users can view up to 200 bugs per month without a service contract.