CTI Ports do not register in CUCM

[mesarasimth1]

Hi

We have Cisco Call Manager 10.5 and integrate  it with UCCX 10.6. After applying UCCX configuration and defining call control group, the CTI ports did not register and were in None state.  We have restarted both CUCM CTI Manager service and Cisco Unified CCX Engine, but it did not work. How can we solve this problem?

Thank You

[Deepak Mehta]

Hi ,

Did you asscociate the CTI ports to Jtapi user's in Application user.

I believe also the unique device name has to be same as given in UCCX application name.

Also CTI manager services has to be activated on the nodes which are present in device pool of CTI route point.

Thanks

[mesarasimth1]

Hi

Thank you all for the hints that you mentioned, but our problem some how differs from what you said.

We have problem in registering CTI ports. We create CTI ports from UCCX console in Call Control Group section, so there is no need to manipulate the configuration because it creates the CTI ports automatically in the CUCM, but it does not register.

We have changed the IP addressing mode to IPV4 only  in CUCM>Device>Common Device Configuration as you said, but it did not work. Also we have applied data check in UCCX, but no error was found.

Thank You

[Aman Soi]

Hi, 

not sure whether this bug is related to problem being faced but have a look

CTI Port not registering with error LINEERROR_RESOURCEUNAVAILABLE.

CSCuq37363

Description

Symptom:
CTI Port not registering with error LINEERROR_RESOURCEUNAVAILABLE

Conditions:
CTIPort returns IpAddrMode as IPv4 when created with default mode, when CDC config for the CTI port is none, CTI was reporting the addressing mode as IPV4. But with this defect, CTI is reporting AddressMode as dual.
So, when a TSP Application registers CTI Port using Media Driver, it is getting failed when CDC configuration is none and enable IPV6 parameter in Enterprise parameters is set to False. CTI is sending address mode as dual by default, TSP using Media Driver allocates V4 and V6 and tries to register CTIport as dual. CTI fails the register request as it allows CTI ports to be registered Dual or IPV6 only when IPV6 is enabled on the cluster

Workaround:
Enable IPV6 parameter in Enterprise parameters to True

regds,

aman

[mesarasimth1]

Hi

As you said we changed ipv6 parameter in Enterprise parameters , but it did not work. Our problem solved by creating new CTI User in UCCX, then we reset engine and recreated call control group.

Thank You

[Deepak Rawat]

There is no need to associate the CTI ports and route Points manually to the Jtapi user since that happens automatically. It is only required to associate the phones or User Device profiles manually in case of RmCm user but not for Jtapi user. Also there are no such restrictions to keep the unique device name as given for application name. Can you please make sure that the IP Addressing Mode is set to use IPv4 only and not IPv4 and IPv6 both inside the Common Device Configuration that is being used for the registration of CTI ports.

Regards

Deepak

[Deepak Mehta]

Thanks for great info.

Usually it will create an CTI route point when you create a trigger associate to an application 

but if you change(unknowingly) the  unique device name on CTI route point  , it will not register  .

I have tested this in the LAB.

[Deepak Rawat]

Usually it will create an CTI route point when you create a trigger associate to an application 

CTI Route Point and Trigger is the same thing first of all to start with. You can create a trigger while you create a application and associate that way and even when you do it that way the Device Name for Route Point does not come pre populate, you need to fill that along with other settings as well. You can also create a trigger or an application separately and associate them later as well, there is no need to keep the name same and yet the registration will happen.

but if you change(unknowingly) the  unique device name on CTI route point  , it will not register  .

Once you have created the trigger/route point from UCCX, it will not allow to change the device name from UCCX anyways. If you are doing it from CM then it is a wrong practice anyways since creation / deletion / modification etc had to be done from UCCX only and then UCCX will push the same information to the CM DB over AXL. Hence it will always be from UCCX to CM and never be from CM to UCCX

Regards

Deepak

[Deepak Mehta]

.

[Deepak Rawat]

Even if you create reverse then also it works as i have tested this.We are not sure what method is being followed whatever it is if name is not same CTI port  will not register

I am assuming with this you mean that first create the route points / ports on CM, associate them to the Jtapi user and then create them on UCCX. If this is correct, then I don't see a point why someone will do like this which is more of a doing something twice first on CM and then on UCCX. Whereas if you will create the CTI Route Point and ports on UCCX the same will automatically get replicated over to the CM no need to create there or doing a manual association to the Jtapi user. Anyways, it is more of a personal thing and any one can play/do what they want, I will not go more into that but it is definitely not a supported thing to do.

to say "Also there are no such restrictions to keep the unique device name as given for application name." is incorrect.

Explain this statement of yours. What exactly you are trying to convey here, may be we are not on the same page.

Regards

Deepak

[Deepak Mehta]

.

[Deepak Rawat]

It looks like that you just do a recreate and then simply post what you found based on that irrespective of knowing how a particular thing works. What I am trying to say in simple words is that, when you create CTI Route Points/Ports on UCCX the same is replicated on CM that by default means the Device Name, description etc that you set on UCCX will remain same on CM as well until you change that intentionally on CM which will of course cause issues in registration.

Regards

Deepak

Regards

Deepak

[Deepak Mehta]

Yes, i try to test everything before i post and i believe it is good way to learn what is happening in backgroun.

I am not expert as you are* however i do appreciate you pitching in for  me.You are making me better.thanks

[Deepak Rawat]

I appreciate your efforts Deepak that you take time and reply on CSC that ultimately helps customers/partners out there and this is what we all want by the end of day. Secondly none of us are experts to be honest, all of us at some point had learned things and are still doing and without any doubt doing recreates help in that to a large extent. My only point is that a recreate should not be the final verdict to decide on anything especially when you have not done it from all the possible ways and hence reading the official documentation in such scenarios is always recommended and should be the last stance to ensure how to do and what to do since it is written in the guidance of people who had created that product in the first place and that too after extensive testing and keeping all pros and cons in mind.

That being said, keep doing the good work. I really appreciate what all you do and best of luck for the future endeavors :)

Regards

Deepak

[Aman Soi]

[+5] to Deepak R and Deepak M.

Can u go to Cisco Unified CM Telephony Data Syncronisation  under CCX Administration and do Data Check for created Call Control Group /Triggers /CM Telephony Users  and check if u could get any reason for the same ?

regds,

aman