This document was generated from CDN thread
Created by: Gabor Fenyvesi on 04-05-2010 09:59:19 AM
Hi All,
We have discovered the following interesting behaviour of a CUCM 6.1.5 cluster. There are 2 servers in the cluster, the CTIManagers are enabled on both. We are connecting to the CTIManager(s) in a redundant way by providing both CTIManager IP addresses. When the monitored phones are registered into the Subscriber and our application is connected to the Publisher's CTIManager, our application does not receive events from the monitored phones. If we force our application to use the CTIManager on the Subscriber, everything seems to be ok. Is it a normal behaviour? According to the JTAPI documentation, CTI Manager should provide events for both of the servers regardless of which one we connect to.
Subject: RE: CTI Manager Redundancy and JTAPI Events
Replied by: Gabor Fenyvesi on 04-05-2010 01:22:37 PM
Thanks for your fast reply.
The JTAPI logs show nothing, those are empty.
We have to receive callChangedEvents (our class implements CallControlCallObserver).
Briefly the situation: there are Publisher and Subscriber Call Managers. All of the devices registered to the Subscriber.
We have tried these scenarios:
1. Connect to the Publisher: everything seems to be ok (we can register the extensions), but we do not receive the events
2. Connect to the Subscriber: everyhing is ok
3. Connect to Publisher, Subscriber: it takes 5 minutes to establish the connection, and we do not receive the events
4. Connect to Subscriber, Publisher: everyhing is ok
Any idea?
Thanks,
Gabor
Subject: RE: CTI Manager Redundancy and JTAPI Events
Replied by: Abhishek Malhotra on 04-05-2010 10:19:45 AM
Irrespective of which CTI Manage node (Publisher or Subscriber) JTAPI connects to, JTAPI application should receive the events.
Can you please tell exactly what events are not received and will it be possible for you to share the JTAPI logs?
Subject: RE: CTI Manager Redundancy and JTAPI Events
Replied by: Abhishek Malhotra on 04-05-2010 01:30:58 PM
Few Questions:
- How many devices are there in user's control list?
- Are pub and Sub connected over WAN? If we connect to Publisher, are we actually connecting over WAN?
Once the connection is established, and you add address and call observer to the devices, do you see AddressInServiceEv? This will be delivered to addressChangedEvents. Can you call getState() method on CiscoTerminal and corresponding CiscoAddress and tell what does it return?
JTAPI logs by default are not enabled, you will have to enable those using JTAPI Preferences or tracing APIs available on interface CiscoJtapiProperties
Subject: RE: CTI Manager Redundancy and JTAPI Events
Replied by: Gabor Fenyvesi on 05-05-2010 03:30:07 PM
Hi,
There are about 100 devices in the user's control list.
Publisher and Subscriber are connected via LAN, also we connect to them via LAN.
Here is the log when we are using the Publisher (the wrong case):
Address is 8636
CTI URL: 10.45.6.10;login=MyJTAPIUser;passwd=passwd
providerChangedEvents: 1
events[0]: (P1-MyJTAPIUser) ProvOutOfServiceEv [#0] Cause:100 CallCtlCause:0 CiscoFeatureReason:12
providerChangedEvents: 1
events[0]: (P1-MyJTAPIUser) ProvInServiceEv [#1] Cause:100 CallCtlCause:0 CiscoFeatureReason:12
Jtapi Provider [10.45.6.10] created
State of address 8636 before the observers added is 0: OUT_OF_SERVICE
Removing observers from address: 8636...
Adding Call Observer to 8636...
Call Observer added to 8636...
Adding Address Observer to 8636...
Address Observer added to 8636...
State of terminal SEP002290BAACA8 is 0: OUT_OF_SERVICE
State of address 8636 is 0: OUT_OF_SERVICE
Observing Address 8636
Ready.
AddressObserver: (P1-MyJTAPIUser) [8636
T_Internal] CiscoAddrOutOfServiceEv [#3] Cause:100 CallCtlCause:0 CiscoFeatureReason:12 for Address[8636]...
AddressObserver: (P1-MyJTAPIUser) [8636T_Internal] CiscoAddrInServiceEv [#5] Cause:100 CallCtlCause:0 CiscoFeatureReason:12 for Address[8636]...
Shutdown.
Here is the log when we are using the Subscriber (works properly):
CTI URL: 10.45.6.11;login=MyJTAPIUser;passwd=passwd
providerChangedEvents: 1
events[0]: (P1-MyJTAPIUser) ProvOutOfServiceEv [#0] Cause:100 CallCtlCause:0 CiscoFeatureReason:12
providerChangedEvents: 1
events[0]: (P1-MyJTAPIUser) ProvInServiceEv [#1] Cause:100 CallCtlCause:0 CiscoFeatureReason:12
Jtapi Provider [10.45.6.11] created
Address is 8636
State of address 8636 before the observers added is 0: OUT_OF_SERVICE
Removing observers from address: 8636...
Adding Call Observer to 8636...
Call Observer added to 8636...
Adding Address Observer to 8636...
Address Observer added to 8636...
State of terminal SEP002290BAACA8 is 1: IN_SERVICE
State of address 8636 is 1: IN_SERVICE
Observing Address 8636
Ready.
AddressObserver: (P1-MyJTAPIUser) [8636T_Internal] CiscoAddrInServiceEv [#5] Cause:100 CallCtlCause:0 CiscoFeatureReason:12 for Address[8636]...
AddressObserver: (P1-MyJTAPIUser) [8636T_Internal] CiscoAddrInServiceEv [#4] Cause:100 CallCtlCause:0 CiscoFeatureReason:12 for Address[8636]...
Shutdown.
I have some additional information: we have stopped and restarted the Subscriber (all of the phones were registered to it), but the phones had not registered themselves to the Publisher but were waiting for the Subscriber to stand up again and registered to that. Is it normal?
Thanks
Created by: Gabor Fenyvesi on 04-05-2010 09:59:19 AM
Hi All,
We have discovered the following interesting behaviour of a CUCM 6.1.5 cluster. There are 2 servers in the cluster, the CTIManagers are enabled on both. We are connecting to the CTIManager(s) in a redundant way by providing both CTIManager IP addresses. When the monitored phones are registered into the Subscriber and our application is connected to the Publisher's CTIManager, our application does not receive events from the monitored phones. If we force our application to use the CTIManager on the Subscriber, everything seems to be ok. Is it a normal behaviour? According to the JTAPI documentation, CTI Manager should provide events for both of the servers regardless of which one we connect to.
Subject: RE: CTI Manager Redundancy and JTAPI Events
Replied by: Gabor Fenyvesi on 04-05-2010 01:22:37 PM
Thanks for your fast reply.
The JTAPI logs show nothing, those are empty.
We have to receive callChangedEvents (our class implements CallControlCallObserver).
Briefly the situation: there are Publisher and Subscriber Call Managers. All of the devices registered to the Subscriber.
We have tried these scenarios:
1. Connect to the Publisher: everything seems to be ok (we can register the extensions), but we do not receive the events
2. Connect to the Subscriber: everyhing is ok
3. Connect to Publisher, Subscriber: it takes 5 minutes to establish the connection, and we do not receive the events
4. Connect to Subscriber, Publisher: everyhing is ok
Any idea?
Thanks,
Gabor
Subject: RE: CTI Manager Redundancy and JTAPI Events
Replied by: Abhishek Malhotra on 04-05-2010 10:19:45 AM
Irrespective of which CTI Manage node (Publisher or Subscriber) JTAPI connects to, JTAPI application should receive the events.
Can you please tell exactly what events are not received and will it be possible for you to share the JTAPI logs?
Subject: RE: CTI Manager Redundancy and JTAPI Events
Replied by: Abhishek Malhotra on 04-05-2010 01:30:58 PM
Few Questions:
- How many devices are there in user's control list?
- Are pub and Sub connected over WAN? If we connect to Publisher, are we actually connecting over WAN?
Once the connection is established, and you add address and call observer to the devices, do you see AddressInServiceEv? This will be delivered to addressChangedEvents. Can you call getState() method on CiscoTerminal and corresponding CiscoAddress and tell what does it return?
JTAPI logs by default are not enabled, you will have to enable those using JTAPI Preferences or tracing APIs available on interface CiscoJtapiProperties
Subject: RE: CTI Manager Redundancy and JTAPI Events
Replied by: Gabor Fenyvesi on 05-05-2010 03:30:07 PM
Hi,
There are about 100 devices in the user's control list.
Publisher and Subscriber are connected via LAN, also we connect to them via LAN.
Here is the log when we are using the Publisher (the wrong case):
Address is 8636
CTI URL: 10.45.6.10;login=MyJTAPIUser;passwd=passwd
providerChangedEvents: 1
events[0]: (P1-MyJTAPIUser) ProvOutOfServiceEv [#0] Cause:100 CallCtlCause:0 CiscoFeatureReason:12
providerChangedEvents: 1
events[0]: (P1-MyJTAPIUser) ProvInServiceEv [#1] Cause:100 CallCtlCause:0 CiscoFeatureReason:12
Jtapi Provider [10.45.6.10] created
State of address 8636 before the observers added is 0: OUT_OF_SERVICE
Removing observers from address: 8636...
Adding Call Observer to 8636...
Call Observer added to 8636...
Adding Address Observer to 8636...
Address Observer added to 8636...
State of terminal SEP002290BAACA8 is 0: OUT_OF_SERVICE
State of address 8636 is 0: OUT_OF_SERVICE
Observing Address 8636
Ready.
AddressObserver: (P1-MyJTAPIUser) [8636
T_Internal] CiscoAddrOutOfServiceEv [#3] Cause:100 CallCtlCause:0 CiscoFeatureReason:12 for Address[8636]...AddressObserver: (P1-MyJTAPIUser) [8636
T_Internal] CiscoAddrInServiceEv [#5] Cause:100 CallCtlCause:0 CiscoFeatureReason:12 for Address[8636]...Shutdown.
Here is the log when we are using the Subscriber (works properly):
CTI URL: 10.45.6.11;login=MyJTAPIUser;passwd=passwd
providerChangedEvents: 1
events[0]: (P1-MyJTAPIUser) ProvOutOfServiceEv [#0] Cause:100 CallCtlCause:0 CiscoFeatureReason:12
providerChangedEvents: 1
events[0]: (P1-MyJTAPIUser) ProvInServiceEv [#1] Cause:100 CallCtlCause:0 CiscoFeatureReason:12
Jtapi Provider [10.45.6.11] created
Address is 8636
State of address 8636 before the observers added is 0: OUT_OF_SERVICE
Removing observers from address: 8636...
Adding Call Observer to 8636...
Call Observer added to 8636...
Adding Address Observer to 8636...
Address Observer added to 8636...
State of terminal SEP002290BAACA8 is 1: IN_SERVICE
State of address 8636 is 1: IN_SERVICE
Observing Address 8636
Ready.
AddressObserver: (P1-MyJTAPIUser) [8636
T_Internal] CiscoAddrInServiceEv [#5] Cause:100 CallCtlCause:0 CiscoFeatureReason:12 for Address[8636]...AddressObserver: (P1-MyJTAPIUser) [8636
T_Internal] CiscoAddrInServiceEv [#4] Cause:100 CallCtlCause:0 CiscoFeatureReason:12 for Address[8636]...Shutdown.
I have some additional information: we have stopped and restarted the Subscriber (all of the phones were registered to it), but the phones had not registered themselves to the Publisher but were waiting for the Subscriber to stand up again and registered to that. Is it normal?
Thanks