[Home]

Summary:ASTERISK-07770: blindxfer => ## is not working (broken by r38687)
Reporter:Michael Strelnikov (michaels)Labels:
Date Opened:2006-09-19 08:56:36Date Closed:2006-09-27 11:59:14
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Resources/res_features
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk_blind_transfer_bug.txt
( 1) debug1.2.10.txt
( 2) debug1.2.11.txt
( 3) log-excerpts.txt
Description:When I press # (once) during a bridged call it mutes/locks the call and I am unable to do anything on either end of the call.
I have "blindxfer => ##" in the "features.conf" file.

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

My confuguration is:
Softphone(SIP) -> asterisk(IAX) -> asterisk(IAX) -> ZAP

It was working for some previous versions but I don't remember which one.

The problem could be temporary solved by changing "blindxfer => ##" to "blindxfer => *#"
Comments:By: marvinhorst (marvinhorst) 2006-09-19 09:11:33

I'm experiencing the same problem with SVN-branch-1.2-r42783.

It worked with previous SVN-branch-1.2-r28257.

I would prefer not to retrain all my users to a different transfer sequence.
By: Serge Vecher (serge-v) 2006-09-19 09:12:03

alright, enable 'debug' logging for console in logger.conf, do 'iax debug' on cli  on both servers, reproduce the problem, and post the console output as an attachment to the bug ...
By: Michael Neuhauser (mneuhauser) 2006-09-20 02:41:28

I have observed the same problem and did some digging: the problem seems to be in the bridge timeout handling in ast_channel_bridge() and ast_generic_bridge(). After the first digit, ast_channel_bridge() sets a timeout (variable nexteventts) and calls ast_generic_bridge(). This function returns with AST_BRIDGE_RETRY when the timeout happens. Then ast_channel_bridge() calls ast_generic_bridge() again with the SAME nexteventts value (that seems to be the core prolem). Since the (old) timeout is already in the past, ast_generic_bridge() returns immediately with AST_BRIDGE_RETRY and so on until the call ends.
By: kuj (kuj) 2006-09-20 16:15:53

Similar behavior on my 2 boxes. Problem started with 1.2.11, 1.2.10 was still fine. I have uploaded 2 debug traces, one for each release. My setup is a little different here: Cisco 7960(SIP)->*(SIP)->CiscoCallMgr. On a different box, I have Polycom500(SIP)->*(ZAP)->Analog FXO.

My feature config here is:
Builtin Feature           Default Current
---------------           ------- -------
Pickup                    *8      *8    
Blind Transfer            #       #1    
Attended Transfer                 #2    
One Touch Monitor                 *1    
Disconnect Call           *       *0  

Pressing a single # now "mutes" the channel and renders it unusable. It should not. Multple # that are apart longer than "featuredigittimeout" (feature.comf) will do the same thing. Multiple # inside a "featuredigittimeout" do work and will not render the channel unusable. And lastly, I should mention that this occurs for me only when using "TW" dial options.
By: dimitripietro (dimitripietro) 2006-09-21 21:29:11

I'M experiencing this bugs too that make the # button unusable. We are then unable to long in the voicemail an everywhere we need the # key. Priority should be change to urgent !
By: Florian Hars (fhars) 2006-09-22 02:09:30

I see this behaviour in SVN-branch-1.2-r43314M, and I can choose which key will
kill the connection after featuredigittimeout: the first key of any two key combination for {blind,at}xfer in features.conf will do. Prerequisite is that the phone is allowed to transfer a call with option t or T in extensions.conf.
Then with

blindxfer => #
atxfer => *2

* is the killing key, with

blindxfer => #2
atxfer => *

# does it, with

blindxfer => 22

2 kills the call.

Workaround: set featuredigittimeout to 86400000

This happens on any type of call I tested (misdn -> SIP, misdn -> misdn, SIP -> misdn, SIP -> IAX2, misdn -> IAX2, IAX2 -> SIP)

If I call from mISDN to SIP, press the killing key on the SIP phone and then hang up the ISDN phone, I get
Sep 21 17:41:05 WARNING[15656]: res_features.c:1384 ast_bridge_call: Bridge failed on channels mISDN/1-1 and SIP/bt101-081c3830

If I hang up the SIP phone instead, I get
Sep 21 17:41:28 WARNING[15668]: indications.c:150 playtones_generator: Can't generate that much data!
Sep 21 17:41:28 WARNING[15668]: res_features.c:1384 ast_bridge_call: Bridge failed on channels mISDN/1-1 and SIP/bt101-081f4fb0

I attach some information from debug logs
By: kuj (kuj) 2006-09-24 19:41:58

Update: when I back out Kevin's changes to channel.c and res_features.c from trunk r38687, things work normally again for me. (IOW, 1.2.12.1 without r38687 works just dandy.) Can somebody please double-check that those changes (which I believe might have been made in the context of 0007289) are indeed a fix for that bug, and why they are causing this issue?


By: Russell Bryant (russell) 2006-09-27 11:59:13

This has been fixed in the 1.2 branch, 1.4 branch, and the trunk in revisions 43778, 43779, and 43780.  If you exeperience any further problems, please file a new report and please make sure that I see it.  Thanks!