Guest

Preview Tool

Cisco Bug: CSCuk33294 - Odd message timings / orderings with inter-cluster calls

Last Modified

Nov 28, 2017

Products (1)

  • Cisco Unified Communications Manager (CallManager)

Known Affected Releases

3.2(0.150)

Description (partial)

Symptom:

Odd message timings / orderings with inter-cluster calls


Conditions:
We ran into a problem during development of the VG248 to do with inter-cluster
 calls; this was originally submitted as CSCuk31078 but I now believe this is an
 issue with CallManager (my specific test used 3.2(0.150) but this effect has
 been seen on other versions too).
 
 Fundamentally, the sequence of operations which causes the problem is this:
 1) Dial out to a extension on a different cluster
 2) After extablishment, put this inter-cluster call on hold
 3) Hit "NewCall" and establish another call (this time on the same cluster)
 4) Put the intra-cluster call on hold
 5) Resume the inter-cluster call
 6) Hit "EndCall" for the inter-cluster call
 7) Resume the intra-cluster call
 
 Now, because the VG248 is faster than a human, the gap between stages 6 and 7
 is minimal; the Resume soft key is pressed very soon after the "TsOnHook" state
 message arrives for the inter-cluster call. What seems to be happening is that
 the resumption of the intra-cluster call happens very quickly, and afterwards
 we receive a CloseReceiveChannel and a StopMediaTransmission message (presumably
 as part of the teardown for the inter-cluster call). There's also a
 StartMediaTransmission which appears for the old call, containing the
 inter-cluster callee's IP address.
 
 To my mind, it seems like an error if CallManager can send any messages
 (CloseReceiveChannel, StartMediaTransmission or whatever) for a call which it
 has previously sent a TsOnHook state message. I guess the root of the problem
 is the lack of a call reference and line instance in the media messages.
 
 So, how should we handle this? Is it wrong to assume CallManager has finished
 with a call when it's sent a TsOnHook state message? Should we always wait for
 a StopMediaTransmission message before assuming a call has been torn down? Is
 there a reason for the extra delay between the TsOnHook and the
 StopMediaTransmission in the inter-cluster case compared to the intra-cluster
 one? We've also seen a StopTone message similarly delayed for inter-cluster
 calls, as reported in CSCuk31097....
 
 Network Sniffer trace available on request; I believe this would be easy to
 reproduce with an automated program such as SimClient which would be capable of
 reducing the gap between stages 6 and 7 above.
 
 Andy
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.