[asterisk-bugs] [Asterisk 0013565]: Calls originated from AMI do not have channel variables specified in sip.conf set

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13565 
====================================================================== 
Reported By:                ajohnson
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   13565
Category:                   Core/ManagerInterface
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.21.2 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-09-26 12:35 CDT
Last Modified:              2008-10-01 11:38 CDT
====================================================================== 
Summary:                    Calls originated from AMI do not have channel
variables specified in sip.conf set
Description: 
Console output:
Executing [s at macro-zap-out:2] NoOp("SIP/nottiano-0845a458", "User_ID: ")
in new stack

extensions.conf
exten => s,n,NoOp(User_ID: ${User_ID})

sip.conf
setvar=User_ID=nottiano

Calls originated through the AMI does not have the variable set.  Calls
originated from the SIP peer do have the variable set.
====================================================================== 

---------------------------------------------------------------------- 
 (0093027) blitzrage (administrator) - 2008-10-01 11:38
 http://bugs.digium.com/view.php?id=13565#c93027 
---------------------------------------------------------------------- 
I was able to reproduce this behaviour. However I'm not entirely sure this
isn't wrong (although not expected...)

The way I reproduced this was to configure 2 SIP channels; phone1 and
phone2.

Then via the Manager, I originated a call to phone1, and attached to a
simple diaplan to call phone2:

exten => 102,1,NoOp(${User_ID} value)
exten => 102,n,Dial(SIP/phone2)
exten => 102,n,Hangup()

If I call from phone1 to phone2 by dialing 102, then I get this:

    -- Executing [102 at testing:1] NoOp("SIP/phone1-08d48378", "phone2
value") in new stack
    -- Executing [102 at testing:2] Dial("SIP/phone1-08d48378", "SIP/phone2")
in new stack
    -- Called phone2


If however I originate the call from the Manager, I get the following:


    -- Executing [102 at testing:1] NoOp("SIP/phone1-08d48378", " value") in
new stack
    -- Executing [102 at testing:2] Dial("SIP/phone1-08d48378", "SIP/phone2")
in new stack
    -- Called phone2


(The value of ${User_ID} is either 'phone1' or 'phone2' respectively).



The reason I think this might not necessarily be wrong (although I agree
it might be nice to have that data), is because the Manager is Originating
a call to 'phone1'. Once that call is connected, then Asterisk is executing
the dialplan as passed to the Manager, and then bridges the two calls
together.

But it is not actually SIP/phone1 that is generating the call -- it is
Asterisk. So the code that needs to be executed prior to firing the call
off to phone2 I'm sure isn't being executed, and thus is the reason why
you're not getting your value.

Here is what I pass to the Manager:

Action: Originate
Channel: SIP/phone1
Exten: 102
Context: testing
Priority: 1


Hopefully a developer can take a look at this and determine if there is a
way to pass the variable, or at least explain why that is not possible.

Thanks! 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-01 11:38 blitzrage      Note Added: 0093027                          
======================================================================