WARNING: this is an automatic post retrieved from the Asterisk-Users Mailing List, not an authored post
March 29, 2012
Tags: active call, AGI variables, call, callerid, dnid, outgoing call, PRI, pri line, priority 1, zap
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?