Asterisk error on hangup during dial in FastAGI application

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Execute a Dial in script handler
2. Hangup the call
3. Asterisk throws an error.

What is the expected output? What do you see instead?
Don´t throw an error

What version of the product are you using? On what operating system?
CentOS 6.4 (2.6.32-358.14.1.el6.x86_64)
Asterisk 11.5.0
Python 2.6.6
Pystrix lastest

Please provide any additional information below.
Asterisk console:
    -- Executing [97153654@router2:1] Progress("SIP/444444-00067a21", "") in new stack
    -- Executing [97153654@router2:2] Set("SIP/444444-00067a21", "LANGUAGE=es") in new stack
    -- Executing [97153654@router2:3] AGI("SIP/444444-00067a21", "agi://127.0.0.1/router") in new stack
    -- AGI Script Executing Application: (SetAMAFlags) Options: (billing)
    -- AGI Script Executing Application: (Dial) Options: (SIP/GatewayGSMXX/0097153654,60,S(7200),T,W)
    -- Setting call duration limit to 7200.000 seconds.
  == Using SIP RTP CoS mark 5
    -- Called SIP/GatewayGSMXX/0097153654
       > 0x7f3ffbfb8350 -- Probation passed - setting RTP source address to 192.168.1.104:5080
    -- SIP/GatewayGSMXX-00067a22 is making progress passing it to SIP/444444-00067a21
       > 0x7f4000031fb0 -- Probation passed - setting RTP source address to 192.168.1.233:8000
    -- SIP/GatewayGSMXX-00067a22 answered SIP/444444-00067a21
    -- Locally bridging SIP/444444-00067a21 and SIP/GatewayGSMXX-00067a22
       > 0x7f4000031fb0 -- Probation passed - setting RTP source address to 192.168.1.233:8000
       > 0x7f4000031fb0 -- Probation passed - setting RTP source address to 192.168.1.233:8000
    -- Executing [h@router2:1] NoOp("SIP/444444-00067a21", "16") in new stack
    -- <SIP/444444-00067a21>AGI Script agi://127.0.0.1/router completed, returning 4
[Aug  2 19:18:22] ERROR[16981][C-00067a0b]: utils.c:1252 ast_carefulwrite: 
write() returned error: Broken pipe
  == Spawn extension (router2, 97153654, 3) exited non-zero on 'SIP/444444-00067a21'

Original issue reported on code.google.com by chrispe...@gmail.com on 2 Aug 2013 at 11:29