[asterisk-bugs] [Asterisk 0014818]: [patch] "setvar" configuration option for mgcp

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=14818 
====================================================================== 
Reported By:                alea-soluciones
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   14818
Category:                   Channels/chan_mgcp
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     new
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 186228 
Request Review:              
====================================================================== 
Date Submitted:             2009-04-02 21:29 CDT
Last Modified:              2009-07-09 13:19 CDT
====================================================================== 
Summary:                    [patch] "setvar" configuration option for mgcp
Description: 
Support for add "setvar" conf options for outgoing calls created from mgcp
endpoint.
The defined vars/values will be created as channel vars when the
corresponding user create a new channel.

The format for this option is (same as setvar at sip.conf):
setvar[space]=[space]<name>=<value>

(spaces are optional)

Only the servar for lines are accepted, the setvar options set for wild
char endpoint will be discarded....
So if we define a mta with the following data:

[mta285.lab.voip]
setvar = WRONG1=value1
setvar = WRONG2=value2
wcardep = aaln/*
host = dynamic
context = pbx4-from-ext-vm
callerid = "" <918298119>
setvar = PBX=main_pbx
line = aaln/1
context = pbx4-from-ext
callerid = "" <4119>
setvar = PBX=main_pbx
setvar = PBXSERV=gold
line = aaln/2

WRONG1 and WRONG2 will be discarded, only are correct "PBX" at aaln/1 line
and "PBX" and "PBXSERV" at aaln/2
====================================================================== 

---------------------------------------------------------------------- 
 (0107521) tilghman (administrator) - 2009-07-09 13:19
 https://issues.asterisk.org/view.php?id=14818#c107521 
---------------------------------------------------------------------- 
The way that this works is kind of odd and potentially buggy.  Of course,
the way that the MGCP config file is parsed is likewise odd.  Basically,
the configfile is parsed the same way as zapata.conf, with endpoint
declarations being instantiations of previous values. So, the current
method is:

[gateway]
foo=1
bar=2
line=line1
line=line2

So both lines get the values of both foo and bar, set to their respective
values.  Enter in setvar, as you have here, and it gets really wonky:

[gateway]
setvar=foo=1
setvar=bar=2
line=line1
line=line2

In your code, the first line would get the variables set, but the second
would not.  I think that's not really expected.  That you have implicitly
cleared the variables between the 2 lines is problematic.  Even stranger is
what happens if you have a wcardep declaration in there.

[gateway]
setvar=foo=1
setvar=bar=2
wcardep=aaln/*
line=line1
line=line2

Now, nothing gets variables, which looks very wrong, as well.  I would
suggest that for a reasonable interpretation, you do the following:

1) Allow wildcard endpoints to obtain variables.  It may not serve your
purposes, but it's reasonable to expect that it would work.

2) Upon instantiating variables, COPY the list of variables (with a deep
copy), instead of just appending it to the current list.

3) Create a new option to clear previous variables under a definition, if
that's really what the administrator wants. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-07-09 13:19 tilghman       Note Added: 0107521                          
======================================================================