Summary:	ASTERISK-06231: [patch] AccountCode not available when called transferred (SIP REFER)
Reporter:	Nabeel Jafferali (nabeelj)	Labels:
Date Opened:	2006-02-01 13:32:28.000-0600	Date Closed:	2011-06-07 14:10:19
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Transfers
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 6393.1.2.patch ( 1) 6393.trunk.patch ( 2) log.txt
Description:	I have a snom 320 connected to an Asterisk server. I do some weird things using the AccountCode as an identifier. When the snom makes a call, the AccountCode is used successfully in the dialplan as a variable ${ACCOUNTCODE}. When that same call is transferred using the button on the snom, I see a SIP REFER message being received on the * server and the call is transferred - however, this "new" call, when going through the steps of the dialplan, has a blank AccountCode. The transferred call is initiated in the correct context, meaning Asterisk is treating it as a call from the correct user, however it seems to forget the user's AccountCode (which is set in sip.conf).
Comments:	By: Juan Pablo Abuyeres (jpabuyer) 2006-02-04 06:36:52.000-0600 I think we hit this bug too a couple of days ago using 1.2.3 .. we're developing a billing system and ended up using dcontext to know from which customer calls come from. Just one thing.. I think the problem is not with 'transfer', but with 'blind transfer'. By: Serge Vecher (serge-v) 2006-02-04 09:10:20.000-0600 nabeelj: in order to address this problem, please set verbose 4, set debug 4, sip debug. Capture the full transaction and attach it here as an attachment. Thanks! By: Tilghman Lesher (tilghman) 2006-02-05 10:37:34.000-0600 Also, please note that ${ACCOUNTCODE} is deprecated.  The new variable you should be using is ${CDR(accountcode)}.  This should additionally make it clear that this variable is associated with the CDR. By: Nabeel Jafferali (nabeelj) 2006-02-05 11:20:36.000-0600 jpabuyer is correct - this issue is with blind-transfer. I apologize for not being clear on that. I am attaching the information mentioned by vechers. Note that this is the extensions.conf that the phone is going through: [test] exten => _1416NXXXXXX,1,Goto(pri-out,${EXTEN:1},1) ... and other local prefixes ... [pri-out] exten => _NXXNXXXXXX,1,Set(GROUP=${ACCOUNTCODE}) exten => _NXXNXXXXXX,2,GotoIf($[${GROUP_COUNT(${ACCOUNTCODE})} > ${CHANNELS_${ACCOUNTCODE}}]?BLOCK) exten => _NXXNXXXXXX,3,Dial(ZAP/g1/${EXTEN}) exten => _NXXNXXXXXX,104,Busy exten => _NXXNXXXXXX,n(BLOCK),Busy If you go through the attached log, you will notice on the inital call, you see the Set(GROUP=1000). However, on the blind-transferred call, you see a Set(GROUP=). There's also two WARNINGs referring to the fact that the variable being set is empty. By: Nabeel Jafferali (nabeelj) 2006-02-20 09:08:47.000-0600 By: Olle Johansson (oej) 2006-03-10 06:46:12.000-0600 Is the SNOM phone caller or callee? Does it make any difference in regards to the accountcode being transferred? Please test and verify. THanks. By: Nabeel Jafferali (nabeelj) 2006-03-13 19:37:43.000-0600 I no longer have the snom 320 in my lab, but the Cisco 7960 in my lab exhibits the same behaviour and I am now using it for the purposes of this test. The lack of AccountCode is only when the 7960 is the caller and the call is blind-transferred. When the 7960 is the callee and the call is blind-transferred, the AccountCode *is* present for the new leg of the call. By: Elton Machado (eltonmachado) 2006-04-01 08:33:09.000-0600 I happens with any sip client in all refer requests :( Does anybody has a tun around for it? I really need account code for billing procedures. By: Russell Bryant (russell) 2006-05-03 21:19:02 I have uploaded patches for both the 1.2 branch and the trunk which I believe to be the cause of this problem.  However, I have not been able to test this to verify it.  Please give this a try and let me know if it fixes your problem. By: Juan Pablo Abuyeres (jpabuyer) 2006-05-08 10:54:17 I tried your patch, and it works, but not as I would expect it to work. Let's say A and B are SIP customers of mine with accountcodes 'AccountcodeA' and 'AccountcodeB', and C is a remote destination. The behaivor with your patch when A calls B and then B blindtransfers the call to C is that both calls have accountcode 'AccountcodeA'. Two scenarios where this is not wanted: First: 1.- A calls B. 2.- B answers and talks to A... than B says "ok, I'll transfer you to the person who can help you". 3.- B BlindTransfers the call to C, who is on a cellular phone in cuba. 4.- C answers and they talk for an hour. Mr. 'A' will be charged for the local call ($0 cost maybe) and also the internacional cellular phone call (likely to be very expensive) when mr. 'A' may have not even knew where he was talking to. He didn't dial anything else than the local number.. why should he pay for something he didn't dial? He can't even know the final destination. So I would expect the first call to have AccountcodeA and the second call to have AccountCodeB. Second scenario (which is a variation of the same): 1.- B forwards calls from his phone to his cellular phone. 2.- A calls B. 3.- A ends paying for a cellular call when he dialed a local internal number, and he didn't even knew. So here I would again expect the first call to get logged with AccountcodeA and the blindtransfered call to have the accountcode of the SIP account who is efectively performing the blindtransfer, AccountcodeB. By: Juan Pablo Abuyeres (jpabuyer) 2006-05-09 16:46:33 well.. I am trying 1.2.7.1 now, without the patch, and the accountcode thing seems "ok". It's not lost after blindtransfering the call. I don't know what difference makes the patch.. I applied it and didn't notice any difference. The problem I see now is that when I ForkCDR, both calls have the same accountcode. If I ForkCDR before the new Dial (in the middle of the blindtransfer), I would expect the new cdr to have accountcode of the account that's making the transfer, not the original caller. How can I do that? By: Serge Vecher (serge-v) 2006-05-10 14:23:21 jpabuyer: can you please also test the trunk and see if it needs russel's patch? Also, with AccountCode being the same after ForkCDR while doing blind transfer -> please file that as a separate bug. Thanks. By: Juan Pablo Abuyeres (jpabuyer) 2006-05-10 16:48:16 Revision: 26655 of trunk doesn't need the patch. After blindtransfer the original accountcode remains. I'll file the forkCDR issue on another bug. By: Serge Vecher (serge-v) 2006-05-10 19:37:21 Ok, closing the issue then. Thanks. Fixed in trunk and 1.2.