[asterisk-bugs] [Asterisk 0011943]: Feature to write variables to existing channels other than your own (func chanvar)
noreply at bugs.digium.com
noreply at bugs.digium.com
Thu Feb 7 04:09:59 CST 2008
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=11943
======================================================================
Reported By: ramonpeek
Assigned To: russell
======================================================================
Project: Asterisk
Issue ID: 11943
Category: Functions/func_logic
Reproducibility: N/A
Severity: feature
Priority: normal
Status: assigned
Asterisk Version: SVN
SVN Branch (only for SVN checkouts, not tarball releases): trunk
SVN Revision (number only!):
Disclaimer on File?: N/A
Request Review:
======================================================================
Date Submitted: 02-06-2008 15:08 CST
Last Modified: 02-07-2008 04:09 CST
======================================================================
Summary: Feature to write variables to existing channels
other than your own (func chanvar)
Description:
Many, many times I ran into a dialplan issue where I wanted to set a
variable in the called channel whilst the dialplan was running in the
calling channel.
To my frustration an application like ImportVar() existed but something
like ExportVar() did not.
After bumping into the issue a bit too often I deciced to write it myself
:-)
It probably took me less time writing the patch than it took finding out
ways to realize this feature with the current set of applications &
functions :-(
Anyway...
I started out writing the patch for 1.4.17 and called it 'ExportVar'.
But after finding out it was deprecated in the svn-trunk and talking to
Digium (Qwell) about it,
I decided to create a new logical function in func_logic called
'CHANVAR'.
This feature includes read & write making function 'ImportVar' & 'IMPORT'
both obsolete.
Since function 'IMPORT' is only in teh svn-trunk perhaps it should be
removed or deprecated if this patch gets submitted.
This is how the new feature works;
To read a variable from another channel;
- Set(CHANVAR(channel,variable)=value)
To write a variable to another channel;
- Set(varname=${CHANVAR(channel,variable)})
PS:
For everyone that wants to add this feature (themselves) to Asterisk
1.4.17 a path to backport to 1.4.17 is also uploaded.
======================================================================
----------------------------------------------------------------------
ramonpeek - 02-07-08 04:09
----------------------------------------------------------------------
The page you are referring to is explaining ways to use channel inheritence
to set variables in child channels and the use of globalvars or a
databaseentry to pass information between channels.
In the many situations where I bumped into this issue, inheritence was not
an option so I too tried to go along the path of setting globalvars or
databaseentries.
This turned out to be a bad solution since you do not always have the
chance to remove the globalvar or databaseentry ending up with a lot of
waste in the variabele enviroment or database.
Besides this, realizing this is often a very long-winded process,
especially in larger and complex dialplans.
Generally what I wanted to do was to set a variable in the originating
channel containing information about the hangup of the called channel
gathered from the 'h' extension in that channel.
And to achieve this there is currently no 'good' solution.
I found a good and working solution for myself by creating this patch.
Which makes everything a lot easier and in my honest opinion more the
Asterisk way to go.
However, I don't work at Digium, so who am I to judge about that ;-)
But as an Asterisk enhousiast, I like to donate to the project too.
So to be sure I didn't create crap, I joined the IRC #asterisk-dev channel
yesterday to discuss this feature and how it would be best to apply this to
Asterisk.
I didn't not get any bad responses to the purposed feature and Qwell
suggested to but it into the bugtracker as a feature request.(sorry I don't
know who's behind the nickname).
Conclusion:
--------------------
If there are no real dangers involved with using this new feature I don't
see any point in not making it easier to those who are facing the same
issues I did.
Offcourse, I'll leave it up to Digium to decide...
Issue History
Date Modified Username Field Change
======================================================================
02-07-08 04:09 ramonpeek Note Added: 0081838
======================================================================
More information about the asterisk-bugs
mailing list