Re: How to end a consultation call and reconnect to held party

Hi Dean,

i do not now if i am right, but if you try to transfer a call, your
problem should be solved "automatically" cause
the phone reacts at it would do, if you would manually transfer a call.
But i am not quit sure about that.

You may try this example:
http://www.i-netsource.de/content/view/8/11/

greetings Joerg Wiesmann

Dean Jesson schrieb:
> Hi,
>
> I would like to know how in Jtapi one is supposed to end a consultation call and reconnect to the held party. The use case is as follows.
>
> I have an application which creates a consultation call via Jtapi and then wants to end it:
> - terminal A is in a normal call with B and they are talking;
> - then terminal A makes a consultation call to C and B goes on hold;
> - because C does not answer, terminal A would now like to reconnect to B, meaning that the consultation call should end and the call to B should be taken off hold so that A and B are once again connected in a normal call.
>
> How can one achieve the reconnect in Jtapi? The required function is a transition from a consultation call to a normal call with the party which was on hold during the consultation.
>
> Is it sufficient to call disconnect() on A's Connection to the call to C? or will this leave B still on hold? If B does get left on hold, can I simply take B explicitly off hold by calling unhold() on the CallControlTerminalConnection on A's Connection to the A/B call?
>
> I have my doubts about this disconnect()+unhold() combination for the following reason. If I do try disconnect() then unhold() my Jtapi implementation will send a CSTA-ClearConnection request to the switch followed by a CSTA-RetrieveCall. I have already tested the effect of this on the switch and it does not lead to the desired behaviour. The desired switch behaviour can only be triggered by sending a CSTA-ReconnectCall (to replace both CSTA-ClearConnection and CSTA-RetrieveCall).
>
> I conclude then that for my switch, reconnect cannot be brought about by disconnect()+unhold(), because a special protocol command has to be sent to the switch as early as the disconnect() stage. If any implementation of Jtapi can be written which can work with this switch, the sequence of Jtapi commands required must therefore be different. Instead, I see two alternatives:
> 1. disconnect() must be sufficient to perform the entire reconnect operation, and that the Jtapi implementation will have to be intelligent enough to recognise that disconnect() is being called on a consultation connection and in this case send a CSTA-ReconnectCall to the switch instead of a CSTA-ClearConnection;
> 2. some other Jtapi interface function should be used, which explicitly requests a reconnect.
>
> The problem with (1) is that the function does more than the user has asked for. This may mean a loss of functionality with other switch types which do support two-stage reconnect. The problem with (2) is that it - so far as I know - is not part of the Jtapi standard.
>
> So, does anyone know what the intended sequence of Jtapi commands is for performing the reconnect?
>
> Thanks,
> Dean
>
> ===========================================================================
> To unsubscribe, send email to [email protected] and include in the body
> of the message "signoff JTAPI-INTEREST".  For general help, send email to
> [email protected] and include in the body of the message "help".
>

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff JTAPI-INTEREST".  For general help, send email to
[email protected] and include in the body of the message "help".