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-0600 | Date Closed: | 2011-06-07 14:10:12 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | 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 |