AGI Variables Being Wrong

Home » Asterisk Users » AGI Variables Being Wrong
Asterisk Users 4 Comments

Greetings!

I have the following line in features.conf:

parse => *9,peer/both,AGI,/etc/asterisk/agi/map.pl

What that script does is parsing AGI variables and doing some things based on them, nothing special.

During outgoing call, those variables get messed up. Let’s look at an example: number 404 calls 2010000, it is being routed over PRI line. When ‘agi debug’ is active, one can see what parameters are being fed to script:

AGI Tx >> agi_request:/etc/asterisk/agi/map.pl
AGI Tx >> agi_channel: Zap/63-1
AGI Tx >>agi_language: en
AGI Tx >> agi_type: Zap
AGI Tx >> agi_uniqueid: 1322049810.4307
AGI Tx >> agi_callerid: 0442010000
AGI Tx >>agi_calleridname: unknown
AGI Tx >>agi_callingpres: 3
AGI Tx >>agi_callingani2: 0
AGI Tx >>agi_callington: 0
AGI Tx >>agi_callingtns: 0
AGI Tx >> agi_dnid: 481
AGI Tx >>agi_rdnis: unknown
AGI Tx >>agi_context: from_pstn
AGI Tx >> agi_extension:
AGI Tx >>agi_priority:1
AGI Tx >> agi_enhanced: 0.0
AGI Tx >> agi_accountcode:

Looking at the callerid and dnid being swapped, one can say that for some reason Asterisk sees this call as incoming from PRI (context kind of approves this). I gave it lots of thinking, and the only conclusion I could come to was – it’s because I run my application on ‘peer’. But it’s not a problem, as I could just swap them back in my script. The problem is, as you can see, our dnid is 481, however we are calling from 404. And moreover – each time I try to call, I get different dnid, like 401, 408 and so on. I thought that it could be last called number on PRI – but it is not.

If the call is really incoming (comes from PSTN) – all variables  get passed correctly, and my script is happy. When I issue ‘show channel’ command during active call, I see that variables  are incorrect in Asterisk on A-leg (i.e. SIP/404-someid), and variables are correct on B-leg (i.e. ZAP/63-1 in our example).

Is that some bug, or misconfiguration, or maybe wrong programming?

4 thoughts on - AGI Variables Being Wrong

  • I’ve never invoked an AGI from ‘features,’ but I’ll assume it’s ‘the same’
    as executing an AGI from the dialplan.

    Usual ‘fails’ in AGIs are:

    1) Not using an established AGI library. While the AGI protocol is simple,
    nobody gets it right the first time.

    2) Forgetting that your AGI’s STDIN and STDOUT ‘belong’ to Asterisk and
    printing a debugging message or something similar.

    3) Not reading the AGI environment from STDIN before requesting an AGI
    command.

  • On Thu, Mar 29, 2012 at 10:10 AM, Steve Edwards
    wrote:

    Neither have I. I’d be really curious to see the entire CLI log of the
    call, with verbose set to 6 and AGI debug enabled, from when the call first
    comes in to when it’s hung up, including the execution of the *9 feature
    code. Also, knowing which version of Asterisk and DAHDI we’re dealing with
    here couldn’t hurt

    While I would normally completely agree with you on this, he showed in his
    original example the AGI environment that is being sent to the script is
    what is “wrong”, not the script’s handling of said environment. To be more
    specific, the agi_callerid: and the agi_dnid: variables appear to have
    incorrect values for an outbound call. My guess would be that this has to
    do with calling the AGI from a features.conf feature code, and not from
    within dialplan itself.

    To the OP – just trying to think outside the box here, but what if instead
    of calling the AGI directly from the features.conf feature code, you wrote
    a Macro or GoSub that you could then use as your application, and within
    the Macro / GoSub you executed your AGI?

  • Warren Selby писал 29.03.2012 20:20:

    to see the entire CLI log of the call, with verbose set to 6 and AGI
    debug enabled, from when the call first comes in to when it’s hung up,
    including the execution of the *9 feature code. Also, knowing which
    version of Asterisk and DAHDI we’re dealing with here couldn’t hurt

    The
    output is pretty same. I can enable DTMF debugging, but can’t imagine
    how could it help us:

  • Warren Selby wrote 29.03.2012 22:46:

    change your features.conf setting like so:
    *9,peer/both,Macro,Parse

    The same result when I changed to Macro. I
    believe that it’s true that callerid on outgoing call is “crap shoot”.
    Here is output: