[Home]

Summary:ASTERISK-08590: accountcode variable is not passed forward on a transfer
Reporter:Richard Wilkinson (rickead2000)Labels:
Date Opened:2007-01-16 11:43:10.000-0600Date Closed:2007-06-22 11:54:58
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/Configuration
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Setting accountcode=myaccount in SIP.conf does not get passed forward on a call transfer

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

e.g.

sip.conf

[SIP1]
accountcode=sip1account

[SIP2]
accountcode=sip2account

extensions.conf
exten => 200,1,Answer
exten => 200,2,NoOP(${CDR(ACCOUNTCODE)})
exten => 200,3,Dial(SIP/SIP2,60,Ttr)

A call comes in and is answered by SIP1.  SIP1 initiates a transfer to extn 200.  NoOP reports an empty variable.  I believe that the accountcode from SIP1, sip1account should be in this variable.

This is present in 1.4.0 and also 1.2 releases
Comments:By: Joshua C. Colp (jcolp) 2007-01-16 12:11:09.000-0600

What kind of transfer are you doing and how is it being performed?
By: Richard Wilkinson (rickead2000) 2007-01-16 12:33:08.000-0600

It is an attended transfer using "*" as defined in features.conf

The issue also seems to be present for an unattended transfer
By: jmls (jmls) 2007-05-28 02:40:31

I think that this is a duplicate of ASTERISK-6518. For your health and safety, please check and confirm that it is.  ;)

Thanks.
By: Steve Murphy (murf) 2007-06-22 11:54:57

I'm truly sorry, but after experimentation, looking over the situation, considerable thought, and trepidation, I think I'm going to have to close this bug as "not fixable".

Let me explain why. acctcode is set in a channel from sip.conf when it
is created, and the sip channel is dialing out.

In this case, the channel is opened to Sip1 the other direction, so... the accountcode is not filled in.

The bridge formed from the transfer is not between sip1 and sip2, it's between
the incoming caller and sip2. So sip1, as far as the nuts and bolts of the connections go, is not involved in the 2nd conversation. It **is** responsible for the call, but there's no-where to express that right now.

Even in my CDRfix5 branch, which I'm eventually going to apply to trunk, to try and fix the problems with CDR's and transfers (to a degree), this doesn't change. You can infer, though, a transfer took place and that sip1 is responsible, from the fields in the 2 CDR's that result from this situation. (see team/murf/CDRfix5).

Sorry, but this is the best I can do, given the situation on-hand at the moment.