Summary: | ASTERISK-07476: Variables not passed to AGI script on call forward | ||
Reporter: | Douglas Garstang (dgarstang) | Labels: | |
Date Opened: | 2006-10-02 14:20:04 | Date Closed: | 2011-06-07 14:02:40 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | 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. |