[Home]

Summary:ASTERISK-07476: Variables not passed to AGI script on call forward
Reporter:Douglas Garstang (dgarstang)Labels:
Date Opened:2006-10-02 14:20:04Date Closed:2011-06-07 14:02:40
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_local
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Following config:

Extension 3254101 is registered to pbx1
Extension 3254103 is registered to pbx2
Extension 9220370 is registered to pbx1
Extension 9220371 is registered to pbx1

3254103 calls 3254101. Dialplan first does a local lookup to determine if 3254101 is available locally. If not, it does a DUNDi lookup and calls 3254103 at the supplied DUNDi path, which is IAX.

This logic is:

   exten => _X.,1,NoOp(*** Originated call ${CALLERID} -> ${EXTEN})
   exten => _X.,n,ChanIsAvail(SIP/${EXTEN})
   exten => _X.,n,GotoIf($["${${AVAILCHAN}}" = ""]?remote:local)
   exten => _X.,n(local),NoOp(LOCAL)
   exten => _X.,n,Dial(SIP/${EXTEN})
   exten => _X.,n,Hangup()
   exten => _X.,n(remote),NoOp(REMOTE)
   exten => _X.,n,Set(PATH=${DUNDILOOKUP(${EXTEN},DUNDIRegistr)})
   exten => _X.,n,Dial(${PATH})
   exten => _X.,n,Hangup()

Pretty standard stuff, and no surprises there.

Now, lets say 3254101 has their phone forwarded to 9220370. 3254103 calls 3254101 and the call is automatically forwarded to 9220370. That works fine.

HOWEVER.

It has become apparent that in such cases, -not all variables are passed to IAX-. In the case where forwarding or transferring is done, eventhough everything works fine internally within Asterisk, as soon as you start handing off call processing to AGI scripts, some variables, namely rdnis and dnid do not get set when they are passed to the AGI script.

I went and placed a call to a FastAGI script in the logic above, right after the call to ChanIsAvail, like this:

exten => _X.,n,AGI(agi://xxx.187.140.167:5001)

Here are the variables passed to that FastAGI script when the dialplan was processing the first call, from 3254103 to 3254101.

agi_network: yes
agi_request: agi://xxx.187.140.167:5001
agi_channel: SIP/3254103-0821a2b8
agi_language: en
agi_type: SIP
agi_uniqueid: 1159794954.42
agi_callerid: 3254103
agi_calleridname: Fairy Godmother
agi_callingpres: 0
agi_callingani2: 0
agi_callington: 0
agi_callingtns: 0
agi_dnid: 3254101
agi_rdnis: unknown
agi_context: btck_CallStart
agi_extension: 3254101
agi_priority: 2
agi_enhanced: 0.0
agi_accountcode: 3254103

And here are the variables, after the forwarding has begun, and asterisk has re-entered the dialplan to process the new call from 3254101 to 9220370. As you can quite clearly see, the dnid and rdnis variables where NOT set when passed to the AGI script, eventhough call processing worked. They SHOULD have been set! Even the dnid is missing this time!

agi_network: yes
agi_request: agi://xxx.187.140.167:5001?from_number=1&to_number=2
agi_channel: Local/9220370@btck_CallStart-8357,2
agi_language: en
agi_type: Local
agi_uniqueid: 1159794956.70
agi_callerid: 3254103
agi_calleridname: Fairy Godmother
agi_callingpres: 0
agi_callingani2: 0
agi_callington: 0
agi_callingtns: 0
agi_dnid: unknown
agi_rdnis: 3254101
agi_context: btck_CallStart

Comments:By: Douglas Garstang (dgarstang) 2006-10-02 14:20:45

Dang it. Can someone with access edit that IP address out there. I forgot to modify it. Thanks.
By: Douglas Garstang (dgarstang) 2006-10-02 14:28:51

Ok, I am an idiot. There is rdnis. However, there is no dnid. The dnid is not set when forwarding or doing a blind transfer. The only time it is correctly set is when doing an attended transfer. These are Polycom phones.
By: jmls (jmls) 2006-11-02 12:19:09.000-0600

anyone ? Is this a polycom or * issue ?
By: Tilghman Lesher (tilghman) 2007-01-07 10:31:10.000-0600

I don't know that not passing DNID is really a bug.  DNID is the number that was dialled, and since you're forwarding, the previous number that was dialled is no longer relevant.

Can you make a case for why it should be passed?
By: Serge Vecher (serge-v) 2007-02-21 14:52:37.000-0600

since there has been no response since October, as per Corydon76 no change is required.