Summary:ASTERISK-19734: Having any h extension in peer's context breaks unaccepted attended feature transfers
Reporter:Andrey Solovyev (corruptor)Labels:
Date Opened:2012-04-17 08:39:06Date Closed:2012-04-17 09:19:50
Versions: Frequency of
is a clone ofASTERISK-19633 Having any h extension in peer's context breaks unaccepted attended feature transfers
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 and
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:
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

I've tested latest SVN 1.8 branch and this is still broken.