Summary:ASTERISK-12675: After retrieved the parked call from SIP phone unable to bilnd transfer or atttend transfer
Reporter:Ramaseshi Reddy Kolli (ramaseshi)Labels:
Date Opened:2008-09-02 12:03:14Date Closed:2011-06-07 14:03:02
Versions:Frequency of
I made a call from 9000 ip phone to 9001 and i parked 9000 at 701 and retrieved the call from other 9002 ip phone. Now again trying to do blind transfer by dialing *84 (according to features.conf) it plays transfer wave file and after that i tried to enter some digits but it is taking only one and plays failure sound wave file.

Please help in this regard
Comments:By: Ramaseshi Reddy Kolli (ramaseshi) 2008-09-02 12:08:43

transferdigittimeout => 3      ; Number of seconds to wait between digits when transferring a call
courtesytone = beep            ; Sound file to play to the parked caller
                                ; when someone dials a parked call
xfersound = beep               ; to indicate an attended transfer is complete
xferfailsound = beeperr        ; to indicate a failed transfer
;adsipark = yes                 ; if you want ADSI parking announcements
pickupexten = *8               ; Configure the pickup extension.  Default is *8
featuredigittimeout = 300      ; Max time (ms) between digits for
                                ; feature activation.  Default is 500

blindxfer => *84                ; Blind transfer, default is #
;disconnect => *0               ; Disconnect (for attended transfer)
;automon => *1                  ; One Touch Record
atxfer => *85                 ; Attended transfer

By: Mark Michelson (mmichelson) 2008-09-09 04:25:41

I have a suspicion about why this is happening. It could be that once 9000 gets parked, the channel's context gets changed to the "parkedcalls" context. Because of that, when you attempt a transfer, the extension to which you are attempting to transfer the call does not exist in the parkedcalls context, so the transfer fails.

If this is the case, it should be easily reproducible. I'll try this when I get into work later today.

By: Ramaseshi Reddy Kolli (ramaseshi) 2008-09-09 04:46:33

I resolved the problem.It is dialplan pattern matching problem. All are working fine.


By: David Woolley (davidw) 2008-09-09 04:53:12

I think putnopvut is probably right.

There is a channel variable which, if set on either side of the bridge that is being broken in the transfer, will force the choice of context.  You may want to try setting TRANSFER_CONTEXT on your incoming calls.

By: Mark Michelson (mmichelson) 2008-09-09 14:15:14

Hmm, I'm going to interpret the timestamps of the two notes after mine to indicate that davidw was probably writing his reply as ramaseshi was posting his. Having said that, I am going to close this at the request of the reporter since this is apparently solved now.