[Home]

Summary:ASTERISK-05569: When a blind transfer is initiated if an invalid extension is dialed the caller being transferred is played the invalid message.
Reporter:Larry Shields (larrys)Labels:
Date Opened:2005-11-11 10:58:07.000-0600Date Closed:2011-06-07 14:10:12
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_transfer
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:When a blind transfer is initiated if an invalid extension is dialed the caller being transferred is played the invalid extension message and then disconnected (not good).  The person initiating the transfer should not be able to release the call unless they have dialed a valid transfer destination.  

****** ADDITIONAL INFORMATION ******

The way this usually works on other PBX systems is that when an invalid extension is dialed the person initiating the transfer receives reorder tone and then are reconnected to the caller.  If they were to try to blind transfer to an invalid destination and then hang-up, the system would initiate a recall (ring back) to connect the caller back to the station / terminal that initiated the invalid transfer.
Comments:By: Serge Vecher (serge-v) 2005-11-11 11:25:03.000-0600

There is a mechanism to handle this by using an "i" extension in the respective section of your dialplan. You can catch the call to invalid extension there and transfer back to extension that dialed it. See http://www.voip-info.org/wiki-Asterisk+variables for variables you need to choose.
By: Larry Shields (larrys) 2005-11-11 14:07:31.000-0600

I agree that there is a mechanism by which we can handle this problem. In my opinion this seems like a work around to add some additional logic to trap a users mistake after the fact. In what scenario do we want a system user to blind transfer a caller to an invalid destination, leaving the caller with hearing an error message or being disconnected from the system.

From the perspective of the caller I don't think this or any error message makes much sense, "I am sorry that is not a valid extension, please try again" (then the caller is disconnected).  I feel it would be appropriate to play this to the person initiating the blind transfer, which is what they would hear if they were initiating an attended transfer to an invalid destination.

It seems to me that the callers channel that is on MOH awaiting transfer should be protected from this erronious uglyness and given the utmost care to be properly switched through the system to a valid destination.  Leave the error indications to the channel of the person making the errors.


By: Kevin P. Fleming (kpfleming) 2005-11-11 16:20:53.000-0600

First of all, app_transfer is not involved here, unless you are using the Transfer() dialplan application to perform the transfer.

Second, you did not tell us how you are performing the transfer... is this via flash-hook on a Zap channel, using a feature key transfer, or using a SIP phone's 'transfer' key? The behavior will vary quite a bit based on the method of transfer used.

We really can't try to address your issue without a proper example (console trace) showing the failing transfer attempt, and enough configuration information to understand why it is working that way.
By: BJ Weschke (bweschke) 2005-11-11 17:50:02.000-0600

and if this via a SIP phone's 'transfer' key, there isn't much we can do about this in code. you might want to actually remove the 'i' extension in this case so the phone gets a 404 and it doesn't try to bridge the extension?
with respect to the feature key transfer, we do check to make sure the extension is valid before we try and transfer there (I just checked).
with regard to zap transfers, not sure.....haven't checked.
By: BJ Weschke (bweschke) 2005-11-14 07:56:38.000-0600

I will close this bug out tomorrow if we don't have any additional feedback about a bug with a particular transfer approach.
/Housekeeping
By: Larry Shields (larrys) 2005-11-14 08:16:54.000-0600

I will update this morning with more detail. -- thanks.
By: Larry Shields (larrys) 2005-11-14 09:07:30.000-0600

Sorry for the lack of detail in my original post.   I have three SIP devices all connected to the same Asterisk server.  Extensions 200, 204 and 210 are valid SIP devices located in the "internal" context.  Extension 219 is not valid and does not exist.  I am using the feature key transfer and have listed various sections from my configs below, followed by the console trace during failure.

I am not using the "transfer" button on any of the units.  Scenario 1 works correctly and scenario 2 is where the call is released during a "feature key" blind xfer to an invalid extension.  Please let me know what other information I can provide to assist further.  - Thanks Larry.

Scenario 1:

Exten 204 dials 200
Exten 200 answers
Exten 204 initiates blind xfer by feature code ##1
Exten 204 dials 210 as xfer destination (valid extension)
Exten 204 is disconnected
Exten 210 rings
Exten 210 answers
Exten 200 and 210 are now connected

Scenario 2:

Exten 204 dials 200
Exten 200 answers
Exten 204 initiates blind xfer by feature code ##1
Exten 204 dials 219 as xfer destination (not valid)
Exten 204 is disconnected
Exten 200 hears the invalid message
Exten 200 is disconnected


-- sip.conf --

[200]
type=friend
host=dynamic
username=200
secret=200
dtmfmode=rfc2833  ; Choices are inband, rfc2833, or info
mailbox=200       ; Mailbox for message waiting indicator
context=internal
disallow=all
allow=ulaw
nat=no
qualify=3000
canreinvite=no
callerid="Sipura" <200>

[204]
type=friend
host=dynamic
username=204
secret=204
dtmfmode=rfc2833  ; Choices are inband, rfc2833, or info
mailbox=204       ; Mailbox for message waiting indicator
context=internal
disallow=all
allow=ulaw
nat=no
qualify=3000
canreinvite=no
callerid="Grandstream" <204>

[210]
type=friend
host=dynamic
username=210
secret=
dtmfmode=rfc2833  ; Choices are inband, rfc2833, or info
mailbox=210       ; Mailbox for message waiting indicator
context=internal
disallow=all
allow=ulaw
nat=no
qualify=no
canreinvite=yes
callerid="Blackberry" <210>


-- extensions.conf --

; 200 is a Sipura SIP phone

exten => 200,1,Dial(SIP/200,20,Tt)
exten => 200,2,Voicemail(b200)
exten => 200,102,Voicemail(u200)
exten => 200,103,Hangup

; 204 is a Grandstream SIP Phone

exten => 204,1,Dial(SIP/204,20,Tt)
exten => 204,2,Voicemail(b204)
exten => 204,102,Voicemail(u204)
exten => 204,103,Hangup

; 210 is a SIP Blackberry 7270

exten => 210,1,Dial(SIP/210,20,Tt)
exten => 210,2,Voicemail(b210)
exten => 210,102,Voicemail(u210)
exten => 210,103,Hangup


-- features.conf --


[featuremap]
blindxfer => ##1     ; Blind transfer
atxfer => ##3        ; Attended transfer


-- Console verbose set 3 --

PMDASTERISK*CLI>
   -- Executing Dial("SIP/204-b9e3", "SIP/200|20|Tt") in new stack
   -- Called 200
   -- SIP/200-16b4 is ringing
   -- SIP/200-16b4 answered SIP/204-b9e3
   -- Attempting native bridge of SIP/204-b9e3 and SIP/200-16b4
   -- Attempting native bridge of SIP/204-b9e3 and SIP/200-16b4
   -- Attempting native bridge of SIP/204-b9e3 and SIP/200-16b4
   -- Attempting native bridge of SIP/204-b9e3 and SIP/200-16b4
   -- Started music on hold, class 'default', on SIP/200-16b4
   -- Playing 'pbx-transfer' (language 'en')
Nov 14 09:37:59 WARNING[30441]: interface.c:215 decodeMP3: Junk at the beginning of frame 49443303
   -- Stopped music on hold on SIP/200-16b4
   -- Transferring SIP/200-16b4 to '219' (context internal) priority 1
 == Spawn extension (internal, 200, 1) exited non-zero on 'SIP/204-b9e3'
   -- Executing Hangup("SIP/204-b9e3", "") in new stack
 == Spawn extension (internal, h, 1) exited non-zero on 'SIP/204-b9e3'
   -- Executing Playback("SIP/200-16b4", "invalid") in new stack
   -- Playing 'invalid' (language 'en')
   -- Executing Hangup("SIP/200-16b4", "") in new stack
 == Spawn extension (internal, 219, 2) exited non-zero on 'SIP/200-16b4'
   -- Executing Hangup("SIP/200-16b4", "") in new stack
 == Spawn extension (internal, h, 1) exited non-zero on 'SIP/200-16b4'
PMDASTERISK*CLI> set verbose 0


By: BJ Weschke (bweschke) 2005-11-14 09:11:23.000-0600

I will try and lab up the scenario you've provided. That code is supposed to be checking for the validity of the extension before it sends someone there so I will need to dbl check what is happening.
By: BJ Weschke (bweschke) 2005-11-14 21:48:16.000-0600

I tested this and it's consistently playing xferfailsound for me every time I put in an invalid extension. I did test with the rc2 code instead of rc1. It shouldn't matter because I don't think that code changed, but I'm not sure why else it wouldn't be working.
By: Larry Shields (larrys) 2005-11-15 08:46:05.000-0600

After reading that you were not able to reproduce this, I began looking again for what else could be the cause.  I found the answer, I had an include in my main context that was catching anything in the dialplan that was not a match.  This appears to override the xferfailsound that would normally be played for an invalid destination when using feature key blind xfer.  When I commented out the following include, blind xfer works as would be expected. I don't know how I did not come across this sooner. -- thanks for looking into this but it appears it's a case of user error.


[nomatch]

exten => _X.,1,Playback(invalid)       ;play no match anouncment
exten => _X.,2,Hangup                  ;disconnect caller
By: Tilghman Lesher (tilghman) 2005-11-15 09:59:51.000-0600

Closed by user request