[Home]

Summary:ASTERISK-19633: Having any h extension in peer's context breaks unaccepted attended feature transfers
Reporter:Andrey Solovyev (corruptor)Labels:
Date Opened:2012-04-04 05:21:52Date Closed:2012-04-27 13:13:44
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Features
Versions:1.8.11.0 Frequency of
Occurrence
Constant
Related
Issues:
is the original version of this clone:ASTERISK-19734 Having any h extension in peer's context breaks unaccepted attended feature transfers
is related toASTERISK-19717 Attended transfer hangup
Environment:Attachments:( 0) atxtrf.bug
( 1) atxtrf.bug.debug.txt
( 2) atxtrf.bug.pcap
( 3) atxtrf.work
( 4) jira_asterisk_19633_v1.8.patch
Description:I've noticed that after upgrade to late asterisk version users have started to lose calls with unaccepted attended transfer.
I mean this scenario. A calls B. B tries to do feature attended transfer and calls C, A is on hold. C answers and talks to B but C do not want take the transfer and hangs up. Now B has to be bridged back to A and continue talking but asterisk hangs up the call.
This has been broken somewhere between 1.8.8.2 and 1.8.9.0.
It was quite hard to find but I've found out that you can reproduce this behaviour if you have ANY h exten (it can be just Noop) in the peer context. If you remove it the call will be bridged back as it should.
I attach the full log with broken transfer (atxtrf.bug).
I have thee sip friends with context=test10: 1_1102, 1_1103, 1_1105.
Context test10 is following:
[test10]
exten => _X.,1,Dial(SIP/1_${EXTEN},60,t)
exten => h,1,Noop()

SIP/1_1103 calls SIP/1_1102. SIP/1_1102 tried attended transfer and calls SIP/1_1105. SIP/1_1105 answers and talks to SIP/1_1102. Then SIP/1_1105 hangs up. Then we see that both SIP/1_1103 and SIP/1_1102 are hanged up. Asterisk throws warnings:
WARNING[16852]: file.c:766 ast_readaudio_callback: Failed to write frame
WARNING[16852]: features.c:2591 builtin_atxfer: Failed to play transfer sound!

I definitely have that sound.
I've removed exten => h,1,Noop() and reproduced the same scenarios. Everything is ok. You may see that in the attached atxtrf.work file.
Also the same scenario works with h exten on 1.8.8.2

I've tested latest SVN 1.8 branch and this is still broken.
Comments:By: Matt Jordan (mjordan) 2012-04-10 08:57:18.026-0500

Andrey:

Can you get a SIP pcap demonstrating the 'bug' situation?  If you can't, a DEBUG log with 'sip set debug on' would also work.

Thanks

Matt

By: Andrey Solovyev (corruptor) 2012-04-11 02:26:19.836-0500

I attach both pcap capture and debug log with sip debug enabled.

By: Andrey Solovyev (corruptor) 2012-04-13 04:20:47.859-0500

I've attached files.

By: Steven Davis (davissteve80) 2012-04-16 16:32:19.822-0500

We are also experianceing this issue. I've confirmed in our build environment that contexts that do not contain 'h' extensions behave as they have for years. Adding even a NoOp in 'h' creates a reproduceable occurance of this issue.

We use #6 for attended transfer, and anything other than a normal transfer results in a lost call. (just clarify it is a features transfer)

This is especially noticeable for us, as we use 'h' when a call is transferred out of a queue to reset the devastate of the agent to NOT_INUSE (this is a dual primary HA setup).

I have opened a case with Digium Support (we do have a support agreement). Hoping that this gets a little extra attention as it really is an issue that causes us headaches.

EDIT: Worth noting, that the problem appeared when we moved from 1.8.6 to 1.8.10.1 on 4/6/12. I cannot comment on what in-between version first displayed the event.

By: Etienne Lessard (hexanol) 2012-04-17 11:57:23.170-0500

We also have this issue on our asterisk 1.8.11.0.

Thank you.

By: Richard Mudgett (rmudgett) 2012-04-24 20:33:46.196-0500

[^jira_asterisk_19633_v1.8.patch] should fix the problem.  It fixed it for me.

By: Andrey Solovyev (corruptor) 2012-04-26 09:09:59.785-0500

I've tested the patch. I's fixed the problem.

By: Steven Davis (davissteve80) 2012-04-27 12:52:28.011-0500

I can also confirm that this patch resolves the issue.