Asterisk perl AGI confusing variables

Home » Asterisk Users » Asterisk perl AGI confusing variables
Asterisk Users 7 Comments

Hello all,

I’m struck with a very strange problem today. I’ve an AGI with some code
subroutine snippet as follows:

sub enable_sbc($) {
my $carrier = shift;
my $tmp = substr($carrier,1);
my $jkh = $tmp;
$server_port = $ast_agi->get_variable(“SIPPEER($jkh,port)”);
$ser_ip = $ast_agi->get_variable(“SIPPEER($tmp,ip)”);
$ast_agi->exec(“SIPAddHeader”,”P-PORT: $server_port”);
$ast_agi->exec(“SIPAddHeader”,”P-IPADDRESS: $ser_ip”);
return 0;
}

Where $carrier resolves to “@my-carrier”

Strangely and very weird get variable is returning correct values on
console as given below but the variables containing the values gets lost or
confused with each other !

AGI Rx < < GET VARIABLE SIPPEER(my-carrier,port)
AGI Tx >> 200 result=1 (5060)
AGI Rx < < GET VARIABLE SIPPEER(my-carrier,ip)
AGI Tx >> 200 result=1 (192.168.2.19)
AGI Rx << EXEC SIPAddHeader "P-PORT: "

7 thoughts on - Asterisk perl AGI confusing variables

  • Sammy Govind wrote:

    Did you copy/paste the code in the email posting, or did you retype it?

    Is it possible that you have multiple versions of the script and the wrong
    one is being executed?

    First step I’d suggest, after checking the above possibility, is to remove
    the prototype. It is almost never needed/wanted and can introduce bugs if
    not used correctly.
    http://www.modernperlbooks.com/mt/2009/08/the-problem-with-prototypes.html

    Next, are you using the strict and warnings pragmas? If not, you should
    add them and fix the problems that they point out.

    Next, declare $server_port and $ser_ip as lexical vars in the sub.

    Finally, add a couple debugging statements after the get_variable
    statements to verify/dump the vars.

  • Hey Ron,
    Thanks for taking out time for this weird issue. No this is the only code
    thats running and I simply copy pasted it here. I’ll go through the artivle
    you mentioned and other advices you gave may hopefully resolve this issue.
    But in general its beyond my logic to see whats actually going on here.
    Simply mind blowing trick for me 🙂

    Just to add here, even changing the arrangement of verbose statement above
    or below the Addheader statement changes the variables as well.

    Additional Details:
    I tested the code without enclosing it in a sub , in a very small agi just
    for this and this same code was giving me 100% results. So that means that
    the production AGI/perl code has something in it thats causing the issue !?

    Regards,
    Sammy

  • Hi again,
    Just to update I fixed the issue. I read through your reply and the URL in
    it and tried alot to make things working but in vain- then I took the tough
    way and started looking at the production AGI from the first line
    and amended all the warning and unwanted stuff, finally I figured out that
    the agi->verbose() function just a few lines above the problematic code was
    having a warning and once that was fixed all the code started working fine.

    I still wonder what do variable assignments has to do with verbose function
    warning, but its all working fine now.
    Thanks for the help.

    Regards,
    Sammy

  • It’s a good idea to track down all warnings and errors even when they seem
    unrelated to the problem at hand.

    Keep in mind executing an AGI completely external from Asterisk can be a
    valuable debugging aid. Just create a text file containing all the proper
    responses and feed it to the AGI’s STDIN. I do this frequently with the
    AGIs I write in C so I can use GDB to step through my code and figure out
    what’s going on.

    Doing any I/O on STDIN or STDOUT will violate the AGI protocol.

  • Thanks for good advice, will definitely keep these in mind while doing
    coding – starting from now 🙂

    On Mon, Feb 13, 2012 at 12:30 PM, Steve Edwards
    wrote:

  • Steve Edwards wrote:
    That is correct. I forgot to clarify that by saying to dump it out to a
    file or STDERR

  • My ‘best practice’ is using syslog(). You can leave the statements in
    place and enable or disable them using setlogmask().

    I also add ‘–debug’ and ‘–verbose’ to my getopt_long() longopts so I can
    control the AGIs verbosity with options in my dialplan.