Blogs

Check out the new content on the Cisco Developer Network reflecting the New & Enhanced features in Cisco Unified Communication Manager 9.1.
See the new 9.1 JTAPI Documentation ...Read More

 

The Unified Communications 9.0 Partner Bundle packages Cisco’s Collaboration application software for our Collaboration partner community to leverage for their internal lab or demonstration systems. The 9.0 version is now available for order. Learn More >> ...Read More

 

Developer Partners,

Cisco announces the availability of our 2012 Developer Partner presentations shared at CiscoLive San Diego.

Please log into the Cisco Developer Network using your Partner UserID to download this content.

Access these presentations here: http://developer.cisco.com/web/cdc/devforumpreso PARTNER LOGIN REQUIRED
...Read More

 

Developer Partners,

Cisco announces the availability of our 2012 Developer Partner presentations shared at CiscoLive London.

Please log into the Cisco Developer Network using your Partner UserID to download this content.

Access these presentations here: http://developer.cisco.com/web/cdc/devforumpreso PARTNER LOGIN REQUIRED
...Read More

 

Cisco Technology Developer Partners,

Cisco is proud to announce the availability of our Cisco Unified Communications System Release 8.6 Not-For-Resale software bundle on Cisco Marketplace (Partner Login Required).

To purchase the latest Unified Communications NFR Software bundle
- Navigate to Cisco Marketplace
- Login using your Cisco.com UserID ...Read More

 

Showing 1 - 5 of 30 results.
Items per Page 5
of 6

Forums

« Back to Cisco JTAPI Questions

RE: Error transferring calls from CTI Port to IPPhone via SIP Trunk

Combination View Flat View Tree View
Threads [ Previous | Next ]
Hi to all, I have a problem transferring calls frrom CTI ports.
Scenario is the following:
- Asterisk connected to CUCM (8.6) via a SIP Trunk.
- Incoming calls from Asterisk are answered and then held on CTI Ports on CUCM.
- Then we make a second call to an IPPhone from the CTI Port where the incoming call is Held.
- When the operator answers the call from the CTI Port, we merge the two calls via a transfer method, so the original incoming call is transferred to the IPPhone, and after this operation comunication is between Asterisk'phone and IPPhone on CUCM.
Sometimes, the last operation (transfer) fails so the two calls aren't merged.
What may it be ?
 
- We 
 
 

Any specific details about the nature of the failure may be helpful, especially interested in:
- JTAPI API errors
- SIP errors or unexpected messages at the Asterisk
- Errors or problem symptoms at the phone
For full troubleshooting (log analysis, etc.), I would recommend the CDN Developer Support program and opening a case:
http://developer.cisco.com/web/devservices

We caught a Timeout Exception via JTapi. while it seems that CUCM sends an Internal Server Error to the Asterisk.
On the phone we see only the call from the CTI Port.
I've Attached  SIP trace log captured with rtmt tool.
Thank.
Attachments:

If the call from the Asterisk lands on an IP phone instead, and a user manually performs the hold/transfer, does the transfer succeed?

We are going to test connection between two phones. 
Our customer has a very complex infrastructure: there are 2 firewalls between CUCM and Asterisk, so I'm not sure  there isn't network problems. I've asked to the customer to verify his infrastructure.
By the way, I post you a trace where we have tracked a SIP/2.0 500 Internal Server Error. It seems that sometimes CUCM answers with this error.
Thanks for your help. Any ideas is appreciated.
Attachments:

My customer said, he has corrected network problems, but this bug still remains.
Any help is appreciated.

From the pcap, the error UCM returns is Q.850 cause 100:
 
Cause No. 100 - Invalid information element contents [Q.850]
This cause indicates that the equipment sending this cause has received and information element which it has implemented; however, one or more Gelds in the I.E. are coded in such a way which has not been implemented by the equipment sending this cause.
There is an initial invite from Asterisk from 11130151004951@10.129.18.11 to UCM (CTI port?) 110010301@10.120.4.10 which sets up fine, but then there is a re-INVITE from Asterisk for the same call, changing media endpoints and adding PCM a-law media type.  I'm not sure why the Asterisk is doing this, or the exact reason why UCM doesn't like this, but it seems to be problematic.
It would probably take some detailed analysis of the UC Manager call processing logs to determine the exact cause, which I think means we would direct you to open a case with the CDN Developer Services group: http://developer.cisco.com/web/devservices

Collateral


No files available