Hi Henry, When you hit the TRANSFER-button on the GXP-2000, it can do an attended or blind transfer (a.k.a. SIP REFER). If you dial the number without hitting another line button, it will do a blind transfer.
BLIND TRANSFER scenario: A calls B (B is the GXP-2000) B answers the call B hit "TRANSFER", and dial C directly B now blind transfers the call to C B is now disconnected from the call In this scenario, in the call to C, B is replaced by A as the caller, and B is removed from the call all together. This is the nature of how (SIP) REFER works, and does not allow for any announcement by B (to C). However, * will populate the variable "BLIND_TRANSFER" when the call is being transferred (A rings B). This can be used to at least perform a fixed event, such as modifying the callerid to show "Transferred:..." or playing a soundfile to C when the call is picked up. What you need to consider is that the transferred call will be using the same context as the call originally came in on. If the call from A to B came in through "from-pstn", the transferred call from A to C will also try to use this context. Instead of doing a blind transfer you can do an attended transfer like this. ATTENDED TRANSFER scenario: A calls B (B is the GXP-2000) B answers the call on "Line 1" B hits "Line 2" (putting A on hold, probably with MOH), and calls C C answers the call from B (asking if C wants the call from A, and we'll assume YES) B hits "Line 1" again (and tell A that the call will be transferred to C) B hits "TRANSFER" and then "Line 2" The call from A is now transferred to C, and B is out of the call All this assumes that Line 2 is not configured to be used as a separate extension, and Line 1 is used as the primary account (with the same system/provider). For billing purposes an attended transfer is much easier to deal with. A blind transfer requires some hack in order to bill the call correctly, assuming that B should be charged for the transferred call to C. -- Bjorn -----Original Message----- From: Apache [mailto:[EMAIL PROTECTED] On Behalf Of Henry.Coleman Sent: Saturday, April 29, 2006 6:44 PM To: [email protected] Subject: [on-asterisk] blind vs. announced transfer I have a client who would be very happy with * but for one thing. Actually its not asterisk per-sec, it's that he used to have a key system and * is a PBX. For those who enjoy a challenge here it is: A PBX is superb at the blind transfer of calls: Answer the ringing line hit the TRANSFER button, dial the extension number and hit SEND and the call is off the "board" and it's on to the next call. The problem comes when you need to "Announce" the call to the extension before you send it. On a Key System the attendant can refer to incoming call as being on "Line (x)" and the person can simply select "Line (x)" Obviously with a pbx you can't do this. The challenge then is to be able to announce and transfer a call in one step. This would add a significant feature to *. As far as I am aware no PBX can do this without using a two step process. Here is how I think it should work- Answer the ringing line, select TRANSFER, dial the extension number, announce the call and press the SEND button connecting the incoming call with the extension. Sounds like the first definition but is light years different in functionality. Before you go ahead and solve this don't forget that sometimes the person at the extension will say "no I don't want to talk to this caller" so there must be a way to send the call to VM or reconnect to the caller. I'm using 12 x GXP 2000's in this system Please substitute the codes for "TRANSFER" and "SEND" The customery beer at Tobys awaits the first person to solve this. wait!... make that two beers. Henry -- Henry Coleman [VoIP-PBX.ca] -- Henry Coleman [VoIP-PBX.ca] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
