cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
354
Views
0
Helpful
1
Replies

Intermittent loss of CTI control with Jabber 10.6 Will changing CTI manager ports help?

Sean Grubb
Level 1
Level 1

It doesn't happen all the time and it doesn't happen to just one person, it is kind of all across the board. Every now and then when a user signs into Jabber client, they get the infamous red "x" on their phone icon at the bottom of the hub window. Normally clicking on the icon and choosing "use my phone for calls" will reconnect the phone but sometimes it won't. They may have to sign out and back in, restart the application, etc. Every now and then it just doesn't want to reconnect no matter what. After doing some research on the matter it seems the port we use for CTI Manager, 389, can be a little slow when connecting and that is what can cause this particular issue. An alternative port can be used: 3268.

Granted we haven't deployed Jabber to all of our departments and users yet (we have around 600 employees), but the ones that do have it have all experienced this at some point. Well not every single one but you get the idea. We also have Cisco Agent/Supervisor for some of these users, and a couple of users that use Attendant Console as well. If I change this port, how will this affect them? Will it even be affected? I assumed it would be affected since those applications have a form of phone control as well. I read about the differences in the ports here:

           Port 3268. This port is used for queries specifically targeted for the global catalog. LDAP requests sent to port 3268 can be used to search for objects in the entire forest. However, only the attributes marked for replication to the global catalog can be returned. For example, a user’s department could not be returned using port 3268 since this attribute is not replicated to the global catalog.

·         Port 389. This port is used for requesting information from the local domain controller. LDAP requests sent to port 389 can be used to search for objects only within the global catalog’s home domain. However, the requesting application can obtain all of the attributes for those objects. For example, a request to port 389 could be used to obtain a user’s department.

 

Does this mean when a user searches for someone in the directory they will no longer be able to see certain information about them? Currently our CUCM and UCCX is 10.5. Jabber ver. 10.6. I know this is a lot of stuff, but really I guess I need to know if I change this port if I can expect certain functions or features to no longer work/be unavailable and if I should also expect some issues with our other Cisco applications.

 

Thank you for your help and time.

1 Accepted Solution

Accepted Solutions

Jakub Stroinski
Level 4
Level 4

It seems that by using the port 3268 (GC) is faster at responding than the regular 389 for LDAP. We had a similar issue but with our AD LDS deployment but it turned out it was a weird issue with the SSL certificates; everything would authenticate aside from CTI.

 

At the end of the day, it is a LDAP response issue. You can run some LDAP traces to try to find out where it is failing. That will give you a better idea.

 

Just changing the port should not affect anyone as long as your GC is configured to listen on that port (default)

View solution in original post

1 Reply 1

Jakub Stroinski
Level 4
Level 4

It seems that by using the port 3268 (GC) is faster at responding than the regular 389 for LDAP. We had a similar issue but with our AD LDS deployment but it turned out it was a weird issue with the SSL certificates; everything would authenticate aside from CTI.

 

At the end of the day, it is a LDAP response issue. You can run some LDAP traces to try to find out where it is failing. That will give you a better idea.

 

Just changing the port should not affect anyone as long as your GC is configured to listen on that port (default)