11-12-2015 02:10 PM
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.
Solved! Go to Solution.
11-23-2015 02:34 PM
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.
11-12-2015 02:23 PM
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.
11-12-2015 02:29 PM
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).
11-13-2015 07:04 AM
I attached a zip of a better example (CiscoJtapi_ANZ_WGN_CTSrv_Prim_1_0959.zip).
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
11-23-2015 02:34 PM
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.
11-24-2015 05:32 AM
Thanks again Smita.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide