|Summary:||ASTERISK-02471: Transferring Calls|
|Date Opened:||2004-09-26 11:47:51||Date Closed:||2011-06-07 14:05:04|
|Description:||I've the same problem as followed here, but Alex has |
described it very well:
We have set up an IP telephoney system hosted by Asterisk and its working pretty well. We primarily use SIP and hardware IP phones.
We have the ability to transfer calls to another SIP phone using either the "Transfer" button on the phone (these phones are Grandstream BudgeTone 100s) or using the "#" key (the T/t flag must be set in the Dial command in asterisk for this way to work).
Both methods seem similar; you enter the number and it transfers.
The problems arise when the phone that it is transfered to is Busy or there is no answer: Asterisk just hangs up. Instead of this behaviour, we would like it to return the call to the person that transfered it.
Alternativley, it could just do a 3 way call or something until the original person hangs up?
I can't believe there is no way to achieve this. I have looked all over the internet but I can't find anything about this.
From an Asterisk context point of view, the transfered call looks like a new call, and as far as i can see there is no way to differentiate between a new call and a transferred one. I know asterisk can tell the difference because the phone sends a "REFER" datagram to initate the transfer.
Any help would be really appreciated
|Comments:||By: Mark Spencer (markster) 2004-09-26 12:02:14|
That's what "supervised" or "attended" transfer is for. Supervised transfer is supported by Asterisk and a variety of SIP phones including the Cisco 7960. Bug 2460 also includes support for attended transfers with '#'.
By: paradise (paradise) 2004-09-26 12:30:38
I know what a "supervised transfer" do.
but in a high load environment it's prefered that the operator just do a "blind" transfer (instead of wasting her time waiting for the called party to pickup the call) and just catch back the transfered call when it has not completed. (something like parkandannounce app.)
that's why i've added this note as a "feature request".
By: rwjblue (rwjblue) 2004-09-26 14:55:05
With some dialplan logic you can get the transferred call to go to voicemail on busy/no answer. You could even setup a campon type of feature via dialplan. Having attended # transfers is addressed pretty well in bug 2460, and SIP based attended transfer is supported very well with the Cisco 79xx's.
By: paradise (paradise) 2004-09-26 15:31:58
just consider this scenario:
- you are the operator. you answer a call from outside and you want to
transfer(blind transfer is prefered) it to one of the extensions. after you transfer, if the person you transferred the call to, doesn't pick up or if his line is busy, the call is transfered back to you, you can speak to the caller and tell him, for example, that the person you want to talk to is not in, and ask if he would like to talk to leave a message or talk to another person
instead. now in asterisk, it seems to me that after you transfer a call
to an extension, there's no way to have the caller transfered back to
yourself if the called extension doesn't answer or if it's busy.
unless you use the supervised transfer which takes much time of operator.
as i told before in a high load PBX with many incoming calls it's prefered that the operator just do a "blind" transfer (instead of wasting her time waiting for the called party to pickup the call) and just be able to have that call on unsuccessful conditions.
this feature exists on all PBXs that i know.
By: Mark Spencer (markster) 2004-09-26 16:17:58
You can already do this with extension logic, consider the following simplified example:
exten => 4000,1,Dial(Zap/1,20)
exten => 4000,2,Voicemail(u4000)
exten => 74000,1,Dial(Zap/1,20)
exten => 74000,2,Goto(o,1)
In this example, she could transfer to 4000 if the person wanted voicemail or 74000 for the call to bounce back to her.
By: rwjblue (rwjblue) 2004-09-26 16:47:16
Please read my recent reply to the original post on the asterisk-users list for some idea's on solving this with Dialplan logic and saving your receptionist from having to handle the same call more than once. I really don't think we need to add any code to get the kind of functionality that you need.