Re: Failure of <transfer> with blind transfer

This is correct behavior for blind transfer as it implies that you are transferring 'blind' irrespective of any call progress. When you do a blind transfer on a phone handset behind a switch you typically hit hook-flash, dial the number and then put the phone down irrespective of whether the far end answers or not. It is the switch that is handling the transfer. 

This is what should happen through the telephony platform when implementing blind transfer. In effect it does a hook flash, dials the number, and disconnects. It is switch's responsibility to complete the call not the telephony implementation platform. 


>>> "Sharma, Ranjan (Ranjan)" <ranjansharma@lucent.com> 02/20/02 11:29AM >>>
Hi,

For the blind call transfers, the specification says:
"No resumption is possible; as soon as the call connects, the platform
throws a telephone.disconnect.transfer. The interpreter disconnects from the
session and continues execution (if anything remains to execute) but cannot
regain control of the call. The caller and callee remain connected in a
conversation."
The "as soon as the call connects" raises the question - what if the call
does not connect (network congestion, called party does not answer, called
party is busy etc.)?
Since session resumption is not possible, is the original call then simply
dropped? What should be the expected (ideally graceful) behavior of the
implementation platform 
if a blind transfer does not connect? One could play an announcement, for
instance.

Thanks,
Ranjan