[Home]

Summary:ASTERISK-04088: [request] Call Transfer no getting variables
Reporter:Dave Ryan (newsole2)Labels:
Date Opened:2005-05-05 20:06:56Date Closed:2011-06-07 14:05:05
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/Configuration
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I call in using Zap card
and I make a call

in extens
I have

PEERNAME = masternetwork

"IAX2/${ACCOUNTCODE}@${PEERNAME}/${EXTEN}@${CONTEXT}|100|rT"

PEERNAME is in Globals


whe it tries to Dial out though Transfer I get This




****** ADDITIONAL INFORMATION ******

   -- Executing GotoIf("IAX2/masternetwork-16384", "1 ? 3 : 4") in new stack
   -- Goto (call-ottawa,5550000,3)
   -- Executing Dial("IAX2/masternetwork-16384", "IAX2/@masternetwork/5550000@|100|rT") in new stack
   -- Called @masternetwork/5550000@
May  5 20:08:24 WARNING[17792]: chan_iax2.c:6756 socket_read: Call rejected by 38.112.88.39: No authority found
   -- Hungup 'IAX2/masternetwork-16588'
 == No one is available to answer at this time (1:0/0/0)
   -- Executing GotoIf("IAX2/masternetwork-16384", "1 ? 3 : 4") in new stack
   -- Goto (call-ottawa,5550000,3)
   -- Executing Dial("IAX2/masternetwork-16384", "IAX2/@masternetwork/5550000@|100|rT") in new stack
   -- Called @masternetwork/5550000@
May  5 20:08:24 WARNING[17792]: chan_iax2.c:6756 socket_read: Call rejected by 38.112.88.39: No authority found
   -- Hungup 'IAX2/masternetwork-16589'
 == No one is available to answer at this time (1:0/0/0)
   -- Executing GotoIf("IAX2/masternetwork-16384", "1 ? 3 : 4") in new stack
   -- Goto (call-ottawa,5550000,3)
   -- Executing Dial("IAX2/masternetwork-16384", "IAX2/@masternetwork/5550000@|100|rT") in new stack
Comments:By: Dave Ryan (newsole2) 2005-05-05 21:05:35

Also When it fails like whon above it keeps repeating till it floods the server for like over 100 times
By: Clod Patry (junky) 2005-05-05 21:56:52

reporter's version is: CVS-HEAD-04/30/05-19:43:37

for me, it seems to be okay.

   -- Executing Dial("SIP/100-0199", "IAX2/@asterisk.junky.com/5540@test_sip|100|rT") in new stack


where asterisk.junky.com is my PEERNAME set in globals too.
so no trouble retrieving the ${CONTEXT} for me.
${ACCOUNTCODE} is empty, so it's normal.


By: Dave Ryan (newsole2) 2005-05-05 22:14:09

for more info look at this

http://pastebin.ca/11097

and I am using
CVS-HEAD-05/05/05-22:59:59
By: Dave Ryan (newsole2) 2005-05-05 22:17:05

and my Extenions is

[call-ottawa]
exten = _X.,1,NoOp(Calling Ottawa Number 1${EXTEN})
exten = _X.,2,GotoIf($[${masternetwork} = YES ] ? 3 : 4)
exten = _X.,3,Dial(IAX2/${USERACCOUNTNUM}@masternetwork/1${EXTEN}@${USERCONTEXT},100,rT)
exten = _X.,4,GotoIf($[${servicenetwork} = YES ] ? 5 : 6)
exten = _X.,5,Dial(IAX2/${USERACCOUNTNUM}@servicenetwork/1${EXTEN}@${USERCONTEXT},100,rT)
exten = _X.,6,Hangup()

exten = h,1,NoOp(Calling Ottawa Has HungUp)
By: Kevin P. Fleming (kpfleming) 2005-05-15 00:52:03

This behavior is as-designed; when you hit the transfer feature sequence, a new channel is created, which does not have any special channel variables associated with it. Variables set in either of the channels that are part of the original conversation are not involved in the new channel.

It would be possible to make channel variables inherit from the transferer's channel using the _NAME syntax already available in other parts of Asterisk, but that is not currently in place.
By: Kevin P. Fleming (kpfleming) 2005-05-15 20:07:34

Changing severity, since Asterisk is not documented to behave in this way, this cannot be 'major'.
By: twisted (twisted) 2005-05-25 00:58:32

I would think the variables for the transferee's channel should be the ones passed along, since they are the ones that will be traveling the dialplan, not the transferer.

Scenario:

Caller A calls into system, gets MYORIGIN variable set to "outside".  Someone answers this call, and goes to transfer it to someone else in the system.  Now, for each extension we check for the variable MYORIGIN to determine how to process the call (wether or not to monitor, wether it should have a distinctive ring, etc).  At this point, that caller, who is still the same person, on the same call, no longer has MYORIGIN set, and thus the check fails, and our monitor and distinctive ring also fail.

This could prove fatal in a multi-system call center type of environment, where we must pass variables with the call in order to determine which company the call is for and answer appropriately.
By: Michael Jerris (mikej) 2005-06-27 23:11:00

Noting that this is a feature request.
By: Michael Jerris (mikej) 2005-06-27 23:13:21

This has been sitting for over a month with no update.  I am going to suspend this one and suggest that if you are not able to produce code for the desired result, that you post a bounty on the wiki, or contract a consultant to produce a patch for the desired result.