EAGI: can't read file descriptor 3, any read blocks forever

I’m using python 3 but the problem may be unrelated to the language.
Here’s my dialplan:

    [general]
    
    [freeconet]
    exten => _X.,1,Ringing
    exten => _X.,n,Wait(1)
    exten => _X.,n,Answer()
    exten => _X.,n,EAGI(min.py)
    exten => _X.,n,Hangup()

And here’s min.py:

    #!/usr/bin/python
    import os
    import sys 
    
    with os.fdopen(3, "rb") as stream:
        sys.stderr.write("start reading")
        sys.stderr.flush()
        x = stream.read(1)
        sys.stderr.write("finish reading")
        sys.stderr.flush()
        sys.stderr.write(str(len(x)) + " bytes read")
        sys.stderr.flush()

When I call, here’s the asterisk log:

    *CLI>   == Using SIP RTP CoS mark 5
           > 0x7f6848024850 -- Strict RTP learning after remote address set to: 185.53.97.50:13964
        -- Executing [587764077@freeconet:1] Ringing("SIP/supervoip-0000000e", "") in new stack
        -- Executing [587764077@freeconet:2] Wait("SIP/supervoip-0000000e", "1") in new stack
        -- Executing [587764077@freeconet:3] Answer("SIP/supervoip-0000000e", "") in new stack
        -- Executing [587764077@freeconet:4] EAGI("SIP/supervoip-0000000e", "min.py") in new stack
        -- Launched AGI Script /var/lib/asterisk/agi-bin/min.py
    start reading 

At this point it hangs forever. When I stop the call (client hang up) here’s the rest:

     -- <SIP/supervoip-0000000e>AGI Script min.py completed, returning 4
          == Spawn extension (freeconet, 587764077, 4) exited non-zero on 'SIP/supervoip-0000000e'

I use stream.read(1) as a minimum approach, I also tried larger values, like stream.read(1024) and so on. There’s no difference.

Why can’t I read even one byte from file descriptor 3? Am I calling EAGI wrong? Does it need some kind of setup before EAGI() call in the dialplan? I can’t find anything in the docs or on Stackoverflow.

Also, this is Asterisk version 15:

    *CLI> core show version
    Asterisk 15.1.0 built by arch @ server-1 on a x86_64 running Linux on 2017-12-05 10:43:29 UTC

Many thanks for any hints…

1 Like