This document was generated from CDN thread
Created by: Stewart Ponsford on 26-02-2013 09:59:54 AM
I have found that if I allow a call to flow from Unity to my Route point (unity set to supervised transfer), as long as I let the transfer from Unity complete I can then redirect the call to a phone of my choice.
If I attempt the redirect as soon as the call arrives at the RP, not only does my redirect not work - which may be fair enough as I may have supplied callid/connection details that are out of date as the transfer is occurring but I can it appears stuff up the JTapi call model.
I say this because I get a platform exception in jtapi (attempt to redirect a call that does not exist), I get a CiscoTransferStartEv but not CiscoTransferEndEv and Jtapi from then on reports both the transfer call and final call in the model even after I have cleared the external call down.
The Jtapi test tool also shows the 2 hanging calls.
Any ideas? This is on CUCM 7.1
Subject: RE: Problem handling calls on RP after Unity transfer
Replied by: Stewart Ponsford on 27-02-2013 04:27:58 AM
Ok I think I have solved this. It appears my app was a bit too quick to issue the redirect command.
I am using the RP as a route terminal, I must set the RTP up before doing the redirect. Even so it seems a little too easy to stuff up jtapi!
Subject: RE: Problem handling calls on RP after Unity transfer
Replied by: David Staudt on 27-02-2013 10:07:54 AM
It is important to wait for media to setup before the Redirect, and there have been some fixed issues in this area in past JTAPI/UCM releases. However I would not expect recent versions to exhibit any confused/unrecoverable behaviour with persistant state-machine discrepencies, such as you describe, even if the Redirect comes early.
If you are on a recent UCM version and would like us to investigate the problematic scenario, please open a case with CDN Developer Support and we'll take a look.
Subject: RE: Problem handling calls on RP after Unity transfer
Replied by: Stewart Ponsford on 27-02-2013 10:16:58 AM
Thanks David.
This is on CUCM 7.1 and we are getting a 9.1 setup tomorrow to do more testing with. Hopefully I will avoid this issue anyway with a better behaved application, if I find anything like this on the newer release I will raise it.
