[Home]

Summary:ASTERISK-12798: blindxfer doesn't work!
Reporter:Daniel Wagner (dwagner)Labels:
Date Opened:2008-09-29 09:50:41Date Closed:2008-10-03 12:02:54
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Resources/res_features
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:after revision 142675 res_features.c the blindxfer doesn't work anymore.
if you make a call from ext A to B, B answeres and transfer the call to C the call will be dropped without any message. if you use r142575 it works!
Comments:By: Steve Murphy (murf) 2008-10-01 13:18:07

Hmmm. I tried this with A=dahdi; B=dahdi; C=dahdi, and no problems.

I try it with A=dahdi; B=SIP; C=dahdi, still works fine.

I need more info to reproduce this!
By: Daniel Wagner (dwagner) 2008-10-01 14:14:28

hi murf, thanks for the answer!

I tried it with

A=SIP, B=SIP, C=SIP
or
A=mISDN, B=SIP, C=SIP

I use snom devices and the transfer button. I tested also the *8 blindxfer.
please try the possibilities above.

thanx!
By: Steve Murphy (murf) 2008-10-01 15:22:40

Uh, putnopvut found a problem in the ***TRUNK*** version that loused up
blind xfers-- could it be that you misreported the version?
By: Steve Murphy (murf) 2008-10-01 15:25:42

One more question: do you have the 'h' exten defined for your context?
By: Daniel Wagner (dwagner) 2008-10-01 15:35:43

i used the http://svn.digium.com/svn/asterisk/branches/1.4 version.
not the trunk one. yes, i've defined the h exten. i see that, after the drop, the hangup sequence is started.
By: Digium Subversion (svnbot) 2008-10-01 15:56:29

Repository: asterisk
Revision: 145553

U   trunk/main/features.c

------------------------------------------------------------------------
r145553 | mmichelson | 2008-10-01 15:56:28 -0500 (Wed, 01 Oct 2008) | 13 lines

The logic surrounding the return value of ast_spawn_extension
within ast_bridge_call was reversed.

This problem was observed when a blind transfer placed from
the callee channel of a test call failed.

While the problem I am solving here is exactly the same
as what was reported in issue ASTERISK-12798, the difference is
that this fix I am applying is trunk-only. Issue ASTERISK-12798
was reported against the 1.4 branch, and my tests
of 1.4's blind transfers appear to work fine.


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=145553
By: Mark Michelson (mmichelson) 2008-10-02 10:05:44

As murf pointed out, I found and fixed a problem in Asterisk trunk which was causing the same symptoms you are experiencing in 1.4. The common issue between the two is that there is new logic added so that when a bridge between channels is broken, the 'h' extension is executed. In my case, I found that there was some incorrect logic being used when spawning the 'h' extension. This flawed logic is not present in 1.4 as far as I can tell.

Something being run in your 'h' extension is being interpreted as an "error" condition for some reason. If you don't mind, could you please post the contents of your h extension? Also, if you have debug or verbose set to 2 or higher, you should see a message on the console that says something to the effect of 'Spawn h extension (default,h,2) exited non-zero on SIP/blah-823ad3e'. If you could either copy and paste that line or just upload a console trace of when this occurs, that would be very helpful in pinpointing which application being run in the 'h' extension is causing the problem.
By: Mark Michelson (mmichelson) 2008-10-02 11:27:38

An update, I reproduced the problem in 1.4 by adding the Hangup application as one of the priorities in my 'h' extension.
By: Mark Michelson (mmichelson) 2008-10-02 11:42:58

Another update. After finding a way to reproduce the problem in 1.4, I tried the same method with trunk. Not surprisingly, the blind transfer failed there as well. This is because my fix to trunk was to make the logic the same as what is currently in 1.4.

The point of all of this is that when this gets fixed in 1.4, a similar fix will need to be merged up for trunk and 1.6.0/1.6.1
By: Steve Murphy (murf) 2008-10-02 17:53:49

I'm just not seeing it... I can't believe it!

I call from a zoiper sip softphone to snom360, snom360 xfers to a polycom430, Hangup() in 'h' exten is executed, no problems. Call goes just fine.

I tried zap -> snom, snom forwards to another zap, worked fine.

I tried zap -> snom, snom forwards to polycom, no prob.

I tried... a few others and still no hangups. How can it be so easy for you guys and I can't make it happen?
By: Mark Michelson (mmichelson) 2008-10-02 17:59:37

If it helps, here is the contents of my h extension:

exten => h,1,NoOp(Hello)
exten => h,2,NoOP(World)
exten => h,3,Hangup

If I comment out priority 3, the transfer will succeed in 1.4. If I leave priority 3 there, then the transfer fails.
By: Mark Michelson (mmichelson) 2008-10-02 18:15:30

By the way, in all my scenarios, the calls are all SIP. Typically, I initiate the call from a Polycom and both other phones involved in the transfer are Aastras. The Polycom dials Aastra A with the following dialplan extension:

exten => 2001,1,Dial(SIP/2001,,tT); yes there really is nothing else in this extension

Aastra A presses my blind transfer feature code (I have it set as 51 in features.conf). The "transfer" sound is played. Then, Aastra A dials the extension of Aastra B (I'm not going to list it here since this never gets executed on a failure anyway). As soon as I have pressed the last digit of Aastra B's extension, the h extension is executed for the Polycom. It's during this time that a transfer may or may not fail. I listed my 'h' extension contents above so that you may be able to reproduce.

By the way, to anyone who is watching this issue, I have two workarounds for this, but neither may be exactly desirable. One is to remove the h extension from the dialplan if it is causing problems. The other is that if you are using the Dial application in order to make the initial call, then you can specify the 'g' option for Dial and the 'h' extension will not be executed when a blind transfer happens. Keep in mind though that this will still implement all side effects, intended or unintended, of using the 'g' option with Dial.
By: Steve Murphy (murf) 2008-10-02 18:46:14

I am definitely a doofus. I was using the "Transfer" button on the snom.

If I try to use the # key to initiate a transfer, well, I can't make that
work. That's a good sign.

So, I'll explore that route.
By: Digium Subversion (svnbot) 2008-10-03 12:02:51

Repository: asterisk
Revision: 146026

U   branches/1.4/res/res_features.c

------------------------------------------------------------------------
r146026 | murf | 2008-10-03 12:02:48 -0500 (Fri, 03 Oct 2008) | 18 lines

(closes issue ASTERISK-12794)
Reported by: dwagner

(closes issue ASTERISK-12798)
Reported by: dwagner
Tested by: murf, putnopvut

The thought occurred to me that the res= from the extension spawn
was ending up being returned from the bridge.

"Thou shalt not poison the return value". Made the change
and it appears to allow blind xfers to work as normal.

If I'm wrong, reopen the bugs. But it looks good to me!

Many thanks to putnopvut for helping me reproduce this!


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=146026