Summary:ASTERISK-15283: [patch] New option setvarout which sets channel variable for outbound channels to a peer
Reporter:fhackenberger (fhackenberger)Labels:
Date Opened:2009-12-07 04:46:55.000-0600Date Closed:2011-06-07 14:01:00
Versions:Frequency of
Environment:Attachments:( 0) setvar-outbound-calls
( 1) setvar-outbound-calls_2
Description:The setvar option in sip.conf sets channel variables for inbound channels (calls from a peer to *), but not for outbound channels (calls to a peer). This patch adds support for a new option "setvarout" which adds that capability.

The automon feature writes the recording to a file which contains the channel name. It is currently not possible to reliably parse the name of the peer from the channel. Setting the channel variable TOUCH_MONITOR_PREFIX before executing the Dial(...,10,wW) app does not work, because you cannot discriminate whether the caller or the callee hit the record button. Using setvarout it is possible to have a easily parsable automon file, by setting the TOUCH_MONITOR_PREFIX to the name of the peer for inbound and outbound channels.


Please note that this feature was coded and tested on and then ported to trunk without another test run. It applies and compiles cleanly. Entries in the sample sip.conf file are missing as well.
Comments:By: fhackenberger (fhackenberger) 2009-12-07 04:57:07.000-0600

Is there a way to set the reviewboard link after posting the bug?

By: Elazar Broad (ebroad) 2009-12-07 11:29:19.000-0600

Not that I know of. With that said, please include a patch for sip.conf sample as well.

By: fhackenberger (fhackenberger) 2009-12-09 02:48:04.000-0600

The second patch includes the sip.conf changes. The documentation in there was wrong IMHO, as it stated that the variables specified in setvar will be set for all calls TO and from the respective device. I corrected that.

By: Leif Madsen (lmadsen) 2010-05-18 13:17:12

We're not entirely clear or convinced that doing something like this adds any advantage over executing this type of thing in the dialplan.

Can you provide a clearer case for why this is necessary? The level of confusion for why this is necessary appears to be high.

By: fhackenberger (fhackenberger) 2010-05-19 03:46:10

As far as I can remember, you can't solve the use case with a 'Set' in the dialplan, because you need different values for TOUCH_MONITOR_PREFIX in the two legs of the call. Otherwise you cannot differentiate a recording which was initiated by the caller from a recoding initiated by the callee. A differentiation is useful if you e-mail the recordings.

Still confusing, or did that clear it up?

By: Leif Madsen (lmadsen) 2010-05-19 10:44:20

I think that certainly helps, thanks! I'll let you know if we need anything further.

By: Leif Madsen (lmadsen) 2010-05-19 10:57:24

OK, so here is a suggestion from Russell that I think might work.

Use the M() flag to Dial() to set two different values as that will be executed on the called channel and not the calling channel. Perhaps something like this:

exten => _X.,1,Set(TOUCH_MONITOR_PREFIX=caller)
exten => _X.,n,Dial(SIP/callee,,M(setMonitorPrefixCallee^callee)

exten => s,1,Set(TOUCH_MONITOR_PREFIX=${ARG1})

Does that work?

By: Leif Madsen (lmadsen) 2010-05-25 15:12:35


By: fhackenberger (fhackenberger) 2010-05-26 03:10:27

A viable option if it works (I'm currently very busy, can't try it before the weekend), although it would still require you to do that on every single Dial. I still reckon the patch is useful, as it completes the functionality which was previously documented for setvar and make the dialplan a bit cleaner for certain use cases.

By: Leif Madsen (lmadsen) 2010-06-23 12:04:50

Pinging the reporter one last time after testing the above option. If that does work, yes it would require you to add it to Dial() options, but that can be done via a Macro() or GoSub() routine.

Typically if something can be done in the dialplan, that is the preferred method.

By: Paul Belanger (pabelanger) 2010-06-30 15:24:10

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.

Further information can be found at http://www.asterisk.org/developers/bug-guidelines