[asterisk-bugs] [Asterisk 0013606]: variables set in sip.conf using "setvar=VARIABLE_NAME=xxxx" are not honoured when doing a blind transfer
Asterisk Bug Tracker
noreply at bugs.digium.com
Fri Oct 3 14:30:58 CDT 2008
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=13606
======================================================================
Reported By: crjw
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 13606
Category: PBX/General
Reproducibility: always
Severity: minor
Priority: normal
Status: feedback
Asterisk Version: 1.6.0-rc6
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-10-03 00:23 CDT
Last Modified: 2008-10-03 14:30 CDT
======================================================================
Summary: variables set in sip.conf using
"setvar=VARIABLE_NAME=xxxx" are not honoured when doing a blind transfer
Description:
sip.conf allows variables to be defined for each phone using the format:
setvar=VARIABLE_NAME=xxxx where "xxxx" is some arbitrary value.
Such variables can generally be accessed inside the dialplan.
e.g. in sip.conf
########################
[A](polycom)
setvar=OTHER_EXTENSIONS="SIP/B&SIP/C"
[B](polycom)
setvar=OTHER_EXTENSIONS="SIP/A&SIP/C"
[C](polycom)
setvar=OTHER_EXTENSIONS="SIP/A&SIP/B"
#######################################
In my dial plan I have an extension (900) which dials
"${OTHER_EXTENSIONS}". All the extensions except the one I am dialing from
will ring. It works well for regular dialing or for attended transfers.
But, If I attempt a blind transfer to extension 900 the value of
$OTHER_EXTENSIONS is NULL and the transfer fails.
It gets a little more complicated:
If I do a blind transfer after doing any number of attended transfers, the
$OTHER_EXTENSIONS variable is non-null; but it does not contain the proper
settings for the phone doing the blind transfer; it contains the settings
for the last phone that did an attended transfer.
======================================================================
----------------------------------------------------------------------
(0093125) crjw (reporter) - 2008-10-03 14:30
http://bugs.digium.com/view.php?id=13606#c93125
----------------------------------------------------------------------
Adding underscores made a difference.
But I did not get the results I was hoping for.
It seems that miscellaneous variables defined in sip.conf are set at the
beginning of the call; the values of such variables remain unchanged when a
blind transfer takes place.
e.g. assume I have the following entries in sip.conf:
########################
[A](polycom)
setvar=_X="AAA"
[B](polycom)
setvar=_X="BBB"
[C](polycom)
setvar=_X="CCC"
#######################################
If I make a call from A to B, $X is assigned a value of "AAA" as
expected.
If I start repeatedly blind transferring the call back and forth between
A, B, and C, the value of $X will always remain set to "AAA"; this was not
expected.
i.e. it does not matter where the blind transfers are initiated, what
matters is where the original call was placed.
However, if I do an attended transfer instead of a blind transfer, the
value will be set for the phone where the transfer is initiated.
e.g. If I initiate an attended transfer on B, the value of $X will be set
to "BBB". I can then start blind transferring again and the value of $X
will stay as "BBB".
Bottom line is that I can not rely on variables defined in sip.conf
because the behavior for blind transfers and attended transfers is not the
same.
I can work around this problem... it just means a longer and more
convoluted dialplan.
Issue History
Date Modified Username Field Change
======================================================================
2008-10-03 14:30 crjw Note Added: 0093125
======================================================================
More information about the asterisk-bugs
mailing list