[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