We are seeing another strange behavior with JTAPI (3.1(2.7)) in CUCM 5.1.2.

Setup:

Cluster with two Call manager server.

Pub: xx,xx,xx,xx

Sub: yy.yy.yy.yy

CUCM Group:

Primary: yy.yy.yy.yy

Secondary: xx,xx,xx,xx


Device: SEP00075027B3FA

Directory Number: 3955

Partition: Local_PT

Now I changed the partition on the DN to a new partition Internal_PT and made a call using makecall tool available with JTAPITools. If you look at the logs from that tool, it shows that terminal connection with this device is still using old partition Local_PT. Shouldn’t it reflect new partition Internal_PT in this terminal connection?

I tried few things to get the updated terminal connection.

1. Reset the device,didn’t work

2. Restart CTI Manager on both the nodes and tried connecting provider with both,didn’t work

3. Registered the phone to secondary CUCM in the CUCM group.,WORKED.


Now even if I move it back to the primary CUCM it works. It almost seems like that this new partition didn’t get updated in the CUCM memory till we registered the device to a new Call manager server.

Is this a known issue? Please find the jatpi logs in attachment.

Logs from call made using MakeCall utility from JTAPITools.

Adding Call observer to address 3953

Adding Adddress Observer to address 3953

Received CiscoAddrOutOfServiceEvfor 3953

Received CiscoTermInServiceEvfor SEP0006281B854C

Received CiscoAddrInServiceEvfor 3953

Adding Call observer to address 3953

Adding Adddress Observer to address 3953

Received CiscoAddrOutOfServiceEvfor 3953

Adding Terminal Observer to TerminalSEP0006281B854C

Adding Call observer to address 3955

Adding Adddress Observer to address 3955

Adding Terminal Observer to TerminalSEP00075027B3FA

Adding Call observer to address 3955

Adding Adddress Observer to address 3955

Adding Terminal Observer to TerminalSEP00075027B3FA

Received CiscoAddrOutOfServiceEvfor 3955

Received CiscoTermOutOfServiceEvfor SEP00075027B3FA

Received CiscoTermInServiceEvfor SEP00075027B3FA

Received CiscoAddrInServiceEvfor 3955

Received CiscoAddrInServiceEvfor 3955

Pausing 1000 milliseconds before making call

Making call #1 from 3953 to 3955 ActionThread

Done making call

Done making callDone making callPausing 1000 milliseconds before answering

Answering TerminalConnection [SEP00075027B3FA/3955:Local_PT/(P1-clarustestuser) GCID=(1,220168)->ACTIVE]->ALERTING->RINGING

Pausing 1000 milliseconds before disconnecting

Edited by: Gitansh Chadha on Jan 29, 2009 1:55 PM

Hi David,

We have seen this issue with CUCM 6.1.2 as well.

We will try to work with our customer to collect the required logs.

Thanks.

A workaround would depend somewhat on what the root cause turns out to be, but based on the things you've tried listed above, I'm not too hopeful there will be an easy one.

Can you describe the nature of the problem?  Perhaps the app hangs here..?

If so it may be helpful to have the JTAPI logs (detailed level, all types).  Also ensure the JVM is a supported version.

Without looking at the JTAPI logs, it appears from your trace window that one of the devices may be a CTI port.  CTI ports require additional steps to initialize (i.e. media type registration), which aren't present in the makecall sample app.  Probably the sample code is stalled waiting for the CTI port in-service event to come.

Please give this a try using two phones or IP Communicator soft phone.

Apologies for not being able to go into more detail, but you should be able to learn the extra operations required in the section of the JTAPI Dev Guide which discusses CTI ports - the main step is to register media capabilities.

Note that if the app/CTI port does not actively send audio to a phone endpoint (i.e. if you don't implement an RTP audio stack), the phone will automatically end the call after awhile...

Unfortunately we don't have sample code for RTP media termination, as that tends to be fairly OS/implementation specific.  Some discussion around using JMF to send RTP media here: https://developer.cisco.com/web/jtapi/forums/-/message_boards/view_message/5198988

Yes it works, the phone rings but never stop and when i pick up i can't hear anything