Incorrect CallCtlCause:-1 for Conference

[derrickgunter]

We have a customer who is receiving CallCtlConnDisconnectedEv with an incorrect CallCtlCause of -1 during a simple conference call.  It is expected to be 207.  See line 4119848 in the attached jtapi log:

4119848: Nov 07 22:17:11.461 NZDT %JTAPI-JTAPI-7-UNK:(P1-nzcc_sth_cti) 9836/2 CallCtlConnDisconnectedEv 45295::2 [#537369] Cause:100 CallCtlCause:-1 CiscoCause:31 FeatReason:12

This is shortly followed by a similar CallCtlConnDisconnectedEv with the correct CallCtlCause of 207:

4119958: Nov 07 22:17:11.492 NZDT %JTAPI-JTAPI-7-UNK:(P1-nzcc_sth_cti) 9836/2 CallCtlConnDisconnectedEv 43023::2 [#537376] Cause:100 CallCtlCause:207 CiscoCause:0 FeatReason:9

In our own test environment the correct CallCtlCause of 207 is always received.

This looks like a bug in the JTAPI/CUCM.

[mpotluri]

A quick look indicates that the call scenario is different. In the second case the call is going to idle state due to conference feature and hence we see a cause.

In the first case an external party is changing without any particular reason and that is the reason why we don't see any specific cause.

[derrickgunter]

Thanks Mohan...

Both are the result of the same conference call.  GCID 9836.  The reason for the state change should be known in both cases. In my tests this behavior is definitely different (both have expected 207).

[derrickgunter]

I attached a zip of a better example (CiscoJtapi_ANZ_WGN_CTSrv_Prim_1_0959.zip).

• An inbound call (GCID 16169) arrives at 54008
• 54008 initiates conference (GCID 9856) to external party 45294
• 54008 completes conference
• We get CallCtlConnDisconnectedEv for 45294 on GCID 9865 with wrong CallCtlCause -1
• CallCtlCause is expected to be 207

See here:

4257821: Nov 08 04:34:21.110 NZDT %JTAPI-JTAPI-7-UNK:(P1-nzcc_sth_cti) 9856/2 CallCtlConnDisconnectedEv 45294::2 [#555627] Cause:100 CallCtlCause:-1 CiscoCause:31 FeatReason:12

[smupadhy · Accepted solution]

Update: This issue was looked into via a DevNet ticket.

Investigation showed that, called party is getting changed in the middle of the conference, which in turn caused the disconnect event. The change in called party occurred outside the cluster, and was not part of the conference. And so, the cause is not 207.

[derrickgunter]

Thanks again Smita.