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

Hi Dean,

i guess thats the way the transfer works, it creates a new call, then
connects the call and keeps the line  ( a to b ) in the background.
If now the call from a to c quits, you automatically talk again to b.
I am pretty sure it works that way. Or did you allready check it?
Greetz Joerg


Dean Jesson schrieb:
> Hi Joerg,
>
> Thanks for the tip. But actually I do not want to transfer. A just wants to ask C a quick question and then return to B. It is a consultation call without transfer and without conference.
>
> Regards,
> Dean
>
> Joerg Wiesmann wrote:
>
>> 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".
>>
>
> ===========================================================================
> 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".