[Home]

Summary:ASTERISK-23549: Intermittent Blind Transfer faliure when using AGI
Reporter:Maciej Krajewski (jamicque)Labels:
Date Opened:2014-03-27 11:22:49Date Closed:
Priority:MajorRegression?Yes
Status:Open/NewComponents:Resources/res_agi
Versions:SVN 11.8.1 12.1.1 13.18.4 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Attachments:( 0) asterisk.sh
( 1) full_failing.txt
( 2) full_working.txt
( 3) full.gz
Description:Blind Transfers fails when it is  done by B side and you are using AGI in dialplan.
I've made some additional tests, the problem occurs only if AGI hangups the connection (EXEC HANGUP) at the end.

The problem did not occur in Asterisk 1.8.19.1 (I haven't checked in later versions).

I've attached the logs and made a simple AGI in bash to recreate this situation.
The dialplan should look like this:

{noformat}
exten => h,1,NoOP("po AGI ===================="${EXTEN}" "${ORGDEST}");

exten => h,2,Hangup
exten => t,1,Hangup(18)

exten => T,1,Hangup(18)

exten => 12,1,Dial(SIP/test002,45,Tt)
exten => 12,n,Hangup()

exten => 13,1,Dial(SIP/test003,45,Tt)
exten => 13,n,Hangup()

exten => 14,1,Dial(SIP/test004,45,Tt)
exten => 14,2,Hangup()

exten => 1,1,AGI(/root/asterisk.sh)
same => n,Hangup()
{noformat}

The problem does not occur if transfer is made by side A.
The problem does not occur if AGI does not send HANGUP at the end.

Call Scenario in log:
test003 dials 1 (calls to test004), test004 BT to test002 (dials 12). All calls are disconnected.
Comments:By: Maciej Krajewski (jamicque) 2014-03-27 11:47:21.326-0500

I've noticed that sometimes even with this AGI script the transfer succeeds - 30%. Maybe there is a race condition?
By: Rusty Newton (rnewton) 2014-04-08 16:08:56.164-0500

Because I had it easily available, I tried to reproduce, using your instructions, but with chan_sip in the latest SVN of 12. I was in fact able to reproduce it there as well. I'm not sure what is going on here.

Attaching logs of reproduction in 12. full_working.txt and full_failing.txt for an example of instance where the described transfer works fine, and an instance where it "fails" by a hang up right after the transfer completes.
By: Rusty Newton (rnewton) 2014-04-08 16:14:06.130-0500

I noticed, just comparing verbose messages between an instance where the scenario works and where it fails the following:

In a working scenario we see:

{noformat}
   -- Channel SIP/6004-00000019 left 'native_rtp' basic-bridge <e0cac3f7-6699-4885-a5b3-6975e1fb40b8>
<SIP/6001-00000018>AGI Tx >> 200 result=0
   -- <SIP/6001-00000018>AGI Script /root/asterisk.sh completed, returning 4
 == Spawn extension (agi-test-context, 12, 1) exited non-zero on 'SIP/6001-00000018'
   -- Executing [12@agi-test-context:1] Dial("SIP/6001-00000018", "SIP/6002,45,Tt") in new stack
{noformat}

In the failing scenario we see:

{noformat}
   -- Channel SIP/6004-0000001c left 'native_rtp' basic-bridge <d2e652ed-2565-4201-a479-7a0c356d9bbf>
<SIP/6001-0000001b>AGI Tx >> 200 result=0
<SIP/6001-0000001b>AGI Rx << EXEC Hangup
   -- AGI Script Executing Application: (Hangup) Options: ()
<SIP/6001-0000001b>AGI Tx >> 200 result=-1
[Apr  8 16:05:27] ERROR[20234][C-00000009]: utils.c:1329 ast_carefulwrite: write() returned error: Broken pipe
   -- <SIP/6001-0000001b>AGI Script /root/asterisk.sh completed, returning 4
 == Spawn extension (agi-test-context, 12, 1) exited non-zero on 'SIP/6001-0000001b'
   -- Executing [12@agi-test-context:1] Dial("SIP/6001-0000001b", "SIP/6002,45,Tt") in new stack
{noformat}

Does look like something is jumping the gun, resulting in unpredictable behavior.
By: Cezary Siwek (csiwek) 2017-06-14 07:01:01.309-0500

Same issue with  Asterisk certified/13.13-cert3  and it is 100% reproducible. It does not matter whether  chan_sip or pjsip is being used.