currently i´m trying to set up a CUCM/CUPS (10.5) BE6000 Cluster, thought all is working fine, now i finally try to "attach" the Jabber-Client (10.5) to my deskphone, all should be configured correctly.
Since i need to use CTI for control of the deskphone, in my case a Cisco 8961, i tried to follow the Jabber deployment guide...for sure also the 10.5 one.
Thats what they write HERE (http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/10_5/CJAB_BK_D6497E98_00_deployment-installation-guide-ciscojabber/CJAB_BK_D6497E98_00_deployment-installation-guide-ciscojabber_chapter_0110.html#JABW_TK_SACF3253_00):
The first step in setting up a CTI gateway is to add a CTI gateway server on Cisco Unified Presence.
|Step 1||Open the Cisco Unified Presence Administration interface.|
|Step 2||Select Application > Cisco Jabber > CTI Gateway Server.|
The Find and List CTI Gateway Servers window opens.
|Step 3||Select Add New.|
The CTI Gateway Server Configuration window opens.
|Step 4||Specify the required details on the CTI Gateway Server Configuration window.|
|Step 5||Select Save.|
THERES NO OPTION LIKE THIS!!!! on that presence server...did i miss something?
Thanks for any input regarding that. The Jabberclient itself as well as the Softphoneregistration work, i just cannot control my deskphone...and thats a keyfeature wanted from this installation.
Solved! Go to Solution.
That documentation must be pretty old.. You define your cti servers on the UC service profile in cucm now.. You should define all your other services such a LDAP, tftp, IM and P etc here..and then assing them to a service profile.
Navigate to User Management > User Settings > UC Service, and then click Add New.
In the UC Service Configuration page, in the UC Service Type list, select CTI, and then click Next.
SIn the Add a UC Service section, enter the following information, and then click Save:
• Name—CTI Service for Jabber
• Description—CTI Service for Jabber Clients
• Host Name/IP Address—10.4.48.111 (Subscriber 1)
Thanks for ur input :)
But thats what i did exactly also. And the user i was used for trying out was added to that profile...or to be more precise, i made this the default profile for the system. Because all will use the same here.
To be able to control the phone you should add this to the access group for the user
Standard CTI Allow Control of Phones supporting Connected Xfer and conf"
So what is the issue you have now..
What is the status of your CTI connection on jabber..Go to help>connection status..post the screen shot here..Is there a server ip address displayed for CTI?
Have you selected the primary phone DN on the user page for the user? Which phone model are you trying to control.. Please check the ff:
Associate the user to the ff groups:
• Access Control Group—Standard CCM End users (existing)
• Access Control Group—Standard CTI Enabled
If you are using one of the following phone models, select the appropriate additional control group:
• Cisco Unified IP Phone 9900 Series—Standard CTI Allow Control of Phones supporting Connected
Xfer and conf
• Cisco Unified IP Phone 6900 Series—Standard CTI Allow Control of Phones supporting Rollover
THANKS!...i cannot believe that...tried with three clients...it worked. It was JUST the port i had to change. And thats strange, because no firewall or anything like that in between...
Anyways, maaaaaany thanks. Was meanwhile a bit pissed about that strange problem. :)
we learn everyday..no need to be pissed! I didn't even know that could cause the issue..I never knew because I always use port 3268 for ldap..but now I know even better!
George why does AD port affect phone control?
Especially i was wondering about this, ONLY affecting deskphone control...because everything besides that works with standard 389...the reason i thought, ok, makes no sense, i always used 389, but, give it a try.
Thanks again for that hint, George!
Hi we use open LDAP and got this problem too. I can login to client but cti/deskphone does not work, just if the user are local user. Are there any news to this timing probleme? We use Jabber 11and CUCM/IM Presence 10.5.
Hi we found it. I do not know why but it seems that cucm holds conection to the ldap server very long time. But after 30 minutes our firewall closes the sessions automatically. Perhaps a keep alive function fails or is not implemented?!? After our firewall closes the connection cucm still sends packets but these are discarded. And after additional one hour the ldap server has answered to the high numbered port used 1 1/2 hours before ;)
To handle this issue we configured this flow stateless. And now it works, switching between cti- or softphonemode is now like i had a local user.
Do we missed something?
Based on MS Information:
· 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.
Additionally found this yesterday evening...
Ya, its a timing problem. Port 389 is slower for LDAP searches. CUCM does a recursive search in LDAP for the user who is trying to control and if its slow, phone control is broken.
I am having a similar problem, I have a few people that like to use the phone control feature in jabber but after I deployed a cisco expressway (work in progress), for some reason it broke my CTI from the Jabber 10.5.1 clients. It works fine for softphone but the deskphone shows as "not connected", for kicks I did check my LDAP and its on the 389 port instead of the 3268 (havent changed it yet). I even tried to set the client back to force the ip address instead of pulling it down automaticly (which works fine since the cisco expressway is put in).
Do you think just changing the port in LDAP from 389 to 3268 should correct the issue? I cant just willy nilly change ports without going thru our internal change control board, otherwise I would just give it a quick shot and see :)
What do you have under Applications -> Legacy Clients -> Settings. Do you use cisco-uds to discover services or cuplogin?