[Home]

Summary:ASTERISK-11975: During a blind transfer BLINDTRANSFER is set incorrectly
Reporter:Kevin Stewart (skavin)Labels:
Date Opened:2008-05-05 17:28:15Date Closed:2008-07-18 10:27:25
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Resources/res_features
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:During a blind transfer BLINDTRANSFER is set incorrectly

builtin_blindtransfer is setting BLINDTRANSFER to the transferee name

should this not be the transferer name?

the result is that ${BLINDTRANSFER} is the same as ${CHANNEL} both being the person that was transfered not the person to be billed!
Comments:By: Kevin Stewart (skavin) 2008-05-05 18:35:14

A calls B
A initiates blind transfer
BLINDTRANSFER = B


A calls B
B initiates blind transfer
BLINDTRANSFER = B

looks like BLINDTRANSFER will always be set to the B party
By: Jason Parker (jparker) 2008-05-07 16:53:21

If you are checking the BLINDTRANSFER on channel A, it will always be B.  The variable shows the channel other side of the blind transfer, and not, as it appears you assume, the initiator of the transfer.
By: Kevin Stewart (skavin) 2008-05-07 18:49:09

I take "the other side" to mean the side that is not being transfered to the new number. or the channel about to be disconnected.
Then ${BLINDTRANSFER} should never equal to ${CHANNEL} but is is if A initiates the transfer.

it seems to be behaving as old B party

       exten => _X.,1,NoOp(${BLINDTRANSFER})
       exten => _X.,2,NoOp(${CHANNEL})

for A -> B
A transfers B -> C

   -- Executing [56565@default:1] NoOp("SIP/44000-082708e8", "SIP/44000-082708e8") in new stack
   -- Executing [56565@default:2] NoOp("SIP/44000-082708e8", "SIP/44000-082708e8") in new stack        

for A -> B
B transfers A -> C

   -- Executing [56565@default:1] NoOp("SIP/44496-08269d00", "SIP/44000-082708e8") in new stack
   -- Executing [56565@default:2] NoOp("SIP/44496-08269d00", "SIP/44496-08269d00") in new stack
By: Brett Bryant (bbryant) 2008-07-17 14:07:01

Shavin, in your dialplan what channel is printing out the NoOp information? Can you upload a dialplan that shows this problem?
By: Rafael Prado Rocchi (prado) 2008-07-17 19:05:03

Yes, I got this situation in version 1.4.21.1 (latest version). My dialplan was not working as it should.

According to as I know (and to as I read everywhere), ${BLINDTRANSFER} should return the channel that dialed the number when doing a blind transfer, ok?

Specifically, this means who pressed the # key, ok?
(assuming the default asterisk configuration where # initiates a blindtransfer)

Please correct me if I am wrong.


I have a typical administrative assistent situation:

In my dialplan I needed to use this variable in this situation:

A calls B
A initiate blindtransfer
A transfer B to a conference room.

A calls C
A initiate blindtransfer
A transfer C to a conference room.

A calls "N"
A initiate blindtransfer
A transfer "N" to a conference room.

A enters the conference room.
Everybody shoud be in the same room.


${BLINDTRANSFER} here is used as a reference to dinamically create the room, so everybody transfered stays in the same room (the room created by number A)

It was not working as it shoud because it was creating B room, C room, and so..
I made some tests and thought it was my dialplan, but it was not.


Then I found that there is possibly a typo in "features.c" in line 706!

Original line 706:
pbx_builtin_setvar_helper(peer, "BLINDTRANSFER", transferee->name);

It should be:
pbx_builtin_setvar_helper(peer, "BLINDTRANSFER", transferer->name);


Changed "transferee" to "transferer" solved my problem!


As I told, this is the way I understand ${BLINDTRANSFER} should be.
But now qwell answer is making me think twice....

Any comments?
By: Digium Subversion (svnbot) 2008-07-18 10:27:05

Repository: asterisk
Revision: 131915

U   branches/1.4/res/res_features.c

------------------------------------------------------------------------
r131915 | bbryant | 2008-07-18 10:26:59 -0500 (Fri, 18 Jul 2008) | 4 lines

Fix a bug in blind transfers where the BLINDTRANSFER variable isn't always set to the other end of the blind transfer.

(closes issue ASTERISK-11975)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=131915