Support A2Billing :

provided by Star2Billing S.L.

Support A2Billing :
It is currently Sat Apr 27, 2024 6:56 pm
Voice Broadcast System


All times are UTC




Post new topic Reply to topic  [ 12 posts ] 
Author Message
 Post subject: cdr for callback
PostPosted: Thu Oct 25, 2007 8:54 am 
Offline

Joined: Wed Oct 24, 2007 11:23 am
Posts: 9
Hi All,
where can i find cdr for callbacks? Call Report table shows oly one leg billed...


Top
 Profile  
 
 Post subject:
PostPosted: Thu Oct 25, 2007 2:21 pm 
Offline
Moderator
User avatar

Joined: Thu Jun 22, 2006 2:19 pm
Posts: 2890
Location: Devon, UK
Not for me; it bills a callback leg and a standard leg both with the same start date and uniqueid.
This is using branches/1.3 as it stands in SVN currently (r398).


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jan 25, 2008 5:38 pm 
Offline
User avatar

Joined: Mon Apr 30, 2007 6:43 am
Posts: 1060
Location: Canada
We have just started having the same problem. Just one leg billed. It only happen when the called hangs up before the callee. No Call Report in A2Billing but Asterisk cdr-csv shows the calls as well as the same duration and the information about the 2 second leg.

Also, but this may not be a related issue, there is a 1 hour time shift between what you see in A2Billing's CDR and what you get in Asterisk's cdr-csv.


Last edited by asiby on Fri Mar 07, 2008 1:14 am, edited 2 times in total.

Top
 Profile  
 
 Post subject:
PostPosted: Sun Jan 27, 2008 6:35 am 
Offline
User avatar

Joined: Mon Apr 30, 2007 6:43 am
Posts: 1060
Location: Canada
Problem solved. I have simply overlooked the contexts that came with the new A2Billing 1.3.2

They were all using AGI instead or DeadAGI. Using DeadAGI solved the problem instantly. Here is what I am using now

Code:
exten => _X.,1,Set(AGISIGHUP=no)
exten => _X.,n,DeadAGI(a2billing.php|1|callback)
exten => _X.,n,Hangup


Top
 Profile  
 
 Post subject: CALLBACK IT SAY GOODBYEE
PostPosted: Sat Feb 02, 2008 12:26 am 
Offline

Joined: Tue Jan 22, 2008 8:42 pm
Posts: 9
== Parsing '/etc/asterisk/manager.conf': Found
== Parsing '/etc/asterisk/manager_additional.conf': Found
== Parsing '/etc/asterisk/manager_custom.conf': Found
== Manager 'myasterisk' logged on from 127.0.0.1
> Channel SIP/1207811919-0a0bbd88 was answered.
== Starting SIP/1207811919-0a0bbd88 at 1207811919,4167544616,1 failed so falling back to exten 's'
== Starting SIP/1207811919-0a0bbd88 at 1207811919,s,1 still failed so falling back to context 'default'
-- Executing [s@default:1] Playback("SIP/1207811919-0a0bbd88", "vm-goodbye") in new stack
== Manager 'myasterisk' logged off from 127.0.0.1
-- <SIP/1207811919-0a0bbd88> Playing 'vm-goodbye' (language 'en')
-- Executing [s@default:2] Macro("SIP/1207811919-0a0bbd88", "hangupcall") in new stack
-- Executing [s@macro-hangupcall:1] ResetCDR("SIP/1207811919-0a0bbd88", "w") in new stack
-- Executing [s@macro-hangupcall:2] NoCDR("SIP/1207811919-0a0bbd88", "") in new stack
-- Executing [s@macro-hangupcall:3] GotoIf("SIP/1207811919-0a0bbd88", "1?skiprg") in new stack
-- Goto (macro-hangupcall,s,6)
-- Executing [s@macro-hangupcall:6] GotoIf("SIP/1207811919-0a0bbd88", "1?skipblkvm") in new stack
-- Goto (macro-hangupcall,s,9)
-- Executing [s@macro-hangupcall:9] GotoIf("SIP/1207811919-0a0bbd88", "1?theend") in new stack
-- Goto (macro-hangupcall,s,11)
-- Executing [s@macro-hangupcall:11] Hangup("SIP/1207811919-0a0bbd88", "") in new stack
== Spawn extension (macro-hangupcall, s, 11) exited non-zero on 'SIP/1207811919-0a0bbd88' in macro 'hangupcall'
== Spawn extension (macro-hangupcall, s, 11) exited non-zero on 'SIP/1207811919-0a0bbd88'
trixbox1*CLI> exit
Executing last minute cleanups
Asterisk cleanly ending (0).
[trixbox1.localdomain asterisk]# tail -f /tmp/a2billing_agi.log
[01/02/2008 06:15:48]:[file:Class.RateEngine.php - line:917]:[CallerID:4167544616]:[CN:7574614397]:[[CC_asterisk_stop 1.1: SQL: DONE : result=1]]
[01/02/2008 06:15:48]:[file:a2billing.php - line:310]:[CallerID:4167544616]:[CN:7574614397]:[[a2billing account stop]]
[01/02/2008 06:15:48]:[file:a2billing.php - line:170]:[CallerID:4167544616]:[CN:7574614397]:[[CHANNEL STATUS : 6 = Line is up]]
[01/02/2008 06:15:48]:[file:a2billing.php - line:171]:[CallerID:4167544616]:[CN:7574614397]:[[CREDIT : 5.00000][CREDIT MIN_CREDIT_2CALL : 0]]
[01/02/2008 06:15:48]:[file:Class.A2Billing.php - line:671]:[CallerID:4167544616]:[CN:7574614397]:[0 && && 10&& 2]
[01/02/2008 06:15:48]:[file:Class.A2Billing.php - line:678]:[CallerID:4167544616]:[CN:7574614397]:[RES DTMF : -1]
[01/02/2008 06:15:48]:[file:Class.A2Billing.php - line:696]:[CallerID:4167544616]:[CN:7574614397]:[DESTINATION ::> -1]
[01/02/2008 06:15:48]:[file:Class.A2Billing.php - line:698]:[CallerID:4167544616]:[CN:7574614397]:[RULES APPLY ON DESTINATION ::> -1]
[01/02/2008 06:15:48]:[file:Class.A2Billing.php - line:649]:[CallerID:4167544616]:[CN:7574614397]:[[CARD STATUS UPDATE : UPDATE cc_card SET inuse=inuse-1 WHERE username='7574614397']]
[01/02/2008 06:15:48]:[CallerID:4167544616]:[CN:7574614397]:[[exit]]


any one know this when i do callback i'm getting this please help me out


Top
 Profile  
 
 Post subject:
PostPosted: Sat Feb 02, 2008 12:59 am 
Offline
User avatar

Joined: Mon Apr 30, 2007 6:43 am
Posts: 1060
Location: Canada
As far as I know, A2Billing will certainly never say Goodbye. There is a default context in extension.conf where the dialplan will fall back when it cannot find it's way in your dialplan. Check these lines. They clearly suggest that after answering the 1st leg, something failed and it failed back to extension s, which also failed, and so on.

Code:
Channel SIP/1207811919-0a0bbd88 was answered.
== Starting SIP/1207811919-0a0bbd88 at 1207811919,4167544616,1 failed so falling back to exten 's'
== Starting SIP/1207811919-0a0bbd88 at 1207811919,s,1 still failed so falling back to context 'default'
-- Executing [s@default:1] Playback("SIP/1207811919-0a0bbd88", "vm-goodbye") in new stack


Can you check if your callback is well configured in a2billing.conf? For example, under the [callback] section, check for context_callback and extension. If the following case, I have context_callback = a2billing-callback, and extension = 1000

Code:
; CALL-BACK
[callback]
; When web call-back is enabled this is the context to sent the call.
context_callback = a2billing-callback

; this is the Extension to redirect the call when the web callback is returned
extension = 1000


And make sure that in extensions.conf, under [a2billing-callback], you use _X., ...

That will help match the extension 1000 and any extensions sent through the web-callback.

Good luck


Top
 Profile  
 
 Post subject:
PostPosted: Sat Feb 02, 2008 10:24 am 
Offline

Joined: Tue Jan 22, 2008 8:42 pm
Posts: 9
i check there ! same trunck i can make out going thru sip phone and callingcard i tested both working fine but callback only i'm getting this message Please help to do that


Top
 Profile  
 
 Post subject:
PostPosted: Sun Feb 03, 2008 1:06 pm 
Offline
Moderator
User avatar

Joined: Thu Jun 22, 2006 2:19 pm
Posts: 2890
Location: Devon, UK
You need to follow asiby's advice more carefully. He's explained exactly what your problem is, and suggested several avenues to explore. Replying simply "I check there" doesn't convince me you've understood your problem. In simple language: your dialplan is faulty as it is not calling A2B when you dial the callback trigger number.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Mar 07, 2008 12:48 am 
Offline

Joined: Fri Feb 15, 2008 2:43 pm
Posts: 58
asiby wrote:
Problem solved. I have simply overlooked the contexts that came with the new A2Billing 1.3.2

They were all using AGI instead or DeadAGI. Using DeadAGI solved the problem instantly. Here is what I am using now

Code:
exten => _X.,1,Set(AGISIGHUP=no)
exten => _X.,n,DeadAGI(a2billing.php|1|callback)
exten => _X.,n,Hangup


Ugh... so this is my problem, lol.


Top
 Profile  
 
 Post subject: cdr for callback
PostPosted: Fri Mar 21, 2008 7:44 am 
Offline

Joined: Sun Nov 25, 2007 2:53 pm
Posts: 6
Hi to all.

In my environment, callback is working as expected.
But upon checking the CDR Report in admin web interface, without selecting the period (specific month or date), all ANSWERED callback from the previous dates are also being displayed.

I'm not doing codings but I think it might be the logic in call-log-customers.php.

Code:
//To select just terminatecause=ANSWER
if (!isset($terminatecause)){
        $terminatecause="ANSWER";
}
if ($terminatecause=="ANSWER") {
        if (strlen($FG_TABLE_CLAUSE)>0) $FG_TABLE_CLAUSE.=" AND ";
        $FG_TABLE_CLAUSE .= " t1.terminatecause='ANSWER' OR t1.terminatecause='ANSWERED' ";


Would it be possible to make the status of the following call type be the same?

Current implementation:
STANDARD = ANSWER
CALLBACK = ANSWERED


Top
 Profile  
 
 Post subject: Re: cdr for callback
PostPosted: Fri Mar 21, 2008 5:59 pm 
Offline
Moderator
User avatar

Joined: Thu Jun 22, 2006 2:19 pm
Posts: 2890
Location: Devon, UK
voipnoy wrote:
But upon checking the CDR Report in admin web interface, without selecting the period (specific month or date), all ANSWERED callback from the previous dates are also being displayed.
That's the intended behaviour. I think it shows all ANSWERED or ANSWER calls so far this month when you first load the page.
Quote:
I'm not doing codings but I think it might be the logic in call-log-customers.php.
That code looks fine; if the UI selects $terminatecause='ANSWER' it will match either 'ANSWER' or 'ANSWERED'.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Mar 22, 2008 5:48 am 
Offline

Joined: Sun Nov 25, 2007 2:53 pm
Posts: 6
Hi Stavros.

Quote:
That's the intended behaviour. I think it shows all ANSWERED or ANSWER calls so far this month when you first load the page.


I agree on you. It should display all ANSWERED or ANSWER calls when you first load the page but I believe that it should only display the current date.

Before, without enabling the callback, when you first load the page, it will only display the current date's successful STANDARD (ANSWER) call since the code will select or focus on the "Answered call" radio button in the OPTIONS - SHOW of the Web UI if not set.

Code:
//To select just terminatecause=ANSWER
if (!isset($terminatecause)){
        $terminatecause="ANSWER";


After enabling the callback and during the first day of callback, it will display ANSWER and ANSWERED status for successful STANDARD and CALLBACK call respectively. When you make a successful callback on the following day and reload the CDR (without selecting any option), it will show the current date's successful STANDARD and CALLBACK call as well as the previous date's ANSWERED CALLBACK and not displaying the previous date's ANSWER STANDARD call anymore. I believe that the code would only display the current date's successful call and not the current month's successful call.

Quote:
That code looks fine; if the UI selects $terminatecause='ANSWER' it will match either 'ANSWER' or 'ANSWERED'.


Code:
$FG_TABLE_CLAUSE .= " t1.terminatecause='ANSWER' OR t1.terminatecause='ANSWERED' ";


After changing all ANSWERED to ANSWER in the database for the CALLBACK call, and reloading the CDR, it is now displaying only current date's successful STANDARD and CALLBACK calls.

And therefore I conclude that the OR statement is not functioning as expected because if the status have both ANSWER and ANSWERED in the database, it will not only filter ANSWER STANDARD and ANSWERED CALLBACK call of the current date but also ANSWERED CALLBACK call from the previous date.

To fix this problem, I have changed the ANSWERED to ANSWER in the a2billing.php.

BEFORE:
Code:
// SET CORRECTLY THE CALLTIME FOR THE 1st LEG
$RateEngine -> answeredtime  = time() - $G_startime;
$RateEngine -> dialstatus = 'ANSWERED';


AFTER:
Code:
// SET CORRECTLY THE CALLTIME FOR THE 1st LEG
$RateEngine -> answeredtime  = time() - $G_startime;
$RateEngine -> dialstatus = 'ANSWER';


After doing so, all successful CALLBACK will now have ANSWER as the status in the CDR thus reloading the CDR Report will only display the current date's successful call.

I hope this would help.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 
Predictive Dialer


All times are UTC


Who is online

Users browsing this forum: No registered users and 21 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group