provided by Star2Billing S.L.

Using Trixbox 2.2 & a2billing 1.2.3,

When I dial-out through the Analogue Zap trunk (Sangoma A200D) billing starts as soon as the call is passed through to the Zap Trunk even if the call is not picked up.

CLI:

-- Called g0/5550000
-- Zap/1-1 answered SIP/6001-0990dfd0

a2billing CDR Report:
1. 2007-05-24 13:33:56 6001 5550000 Local 00:31

Master.CSV
"","6001","5550000","from-internal","6001","SIP/6001-0990dfd0","Zap/1-1","ResetCDR","w","2007-05-24 13:33:43","2007-05-24 13:33:46","2007-05-24 13:33:58",45,41,"ANSWERED","DOCUMENTATION"

The above is an example of a call placed from 6001 to 5550000 that isn't answered at the far end. a2billing starts calc once Zap/1-1 takes the call. Asterisk CDR starts earlier (45,41).

Whilst this doesn't seem to be an a2billing problem specifically I was wondering what can be done &/or what workarounds people are using.

Unfortunately we can't get and digital lines where we are (only analogue or expensive satellite Internet) to work around this.

Many thanks.

Your problem is that the asterisk cannot safely know when the call is being answered on the analog line. There is some experimental support for detecting progress of the call over an analog line.
see: http://www.voip-info.org/wiki/index.php ... nkFeatures

and the 'callprogress' parameter.
You would have to tweak the zapata.conf and try to match your local settings.

Still, anything in the range >70% of correct detection (on a line with modest levels of noise) would be good.
If you were that lucky, your analog provider could be doing polarity reversal on call establishment. In that case, your chance of detecting that would be near absolute (in case your Sangoma card also supports polarity detection).

Analog sucks big time!

xrg, many thanks for your reply. yep, is analog has definately been troublesome. At least with the Sangoma card I don't get the echo drama

I added "callprogress=yes" to zapata.conf & thought I got somewhere as an unanswered call now shows:

-- Called g0/5550000
-- Nobody picked up in 30000 ms
-- Hungup 'Zap/1-1'

ie. minus the -- Zap/1-1 answered

Unfortunately it does the same for a call that is answered
Tried busydetect=yes & busycount=5 as well but same result as above.

Other zapata tweaks that you mentioned, are these to do with echo (eg. echotraining, tx/rxgain) &/or other?

Is it possible to not start billing until after the first X secs of a call? Not very accurate I know but is less troublesome than billing for unanswered calls.

Busy tone and disconnect signaling is pretty much similar across the countries. That's why it works. Answering, dialtone etc varies much from country to country. As the voip-info wiki suggests, the implementation now in * is for US. If you have different frequencies (tones), it won't work.

ok thanks again. Until (if ever) I get this working correctly...

Is it possible to delay the start of billing for the ZAP trunk(s)?
An "Additional Parameter" perhaps?

there is this parameter in the agi-conf section of a2billing.conf maybe you can use it to get around your problem until you come up with a proper fix