vicidial and a2billing

[bghayad]

Hi All;

How can the IP Phones configured to be working with a2billing and at the same time to be used with vicidial because a2billing is using the file additional_a2billing_sip.conf and the vicidial is using sip-vicidial.conf, so how to avoid this conflict?

Is there a solution or work around to overcome this problem?

Can I let the a2billing and the vicidial use the same file? If yes, how the changing in vicidial or in the a2billing pages will not cause a troubles between vicidial and a2billing?

Thanks in advance.
Regards
Bilal

[williamconley]

they should not be on the same server.

[boybawang]

a2billing / asterisk should be on another server which the stand alone vicidial / asterisk would be connecting to the a2billing / asterisk server

[boybawang]

if installed on the same server it would work but it would be a resource hog since a2billing and vicidial both have databases so I/O would be high. There wouldnt be a conflict since vicidial writes sip entries under sip-vicidial.conf and extensions-vicidial.conf unless of course you have duplicate extensions

[ciacho]

Is there any workaround to prevent `Got SIP response 482 "Loop Detected" back from` on the same machine?
In a2billing I was added a customer and created SIP account.

Next I was register created SIP account on VICIdial Carriers - successfully.
When I try to make a call from phones (Vicidial Admin/Phones) via registered Carrier I got:

Code: Select all

[Jan  7 09:08:08]     -- Executing [111111111@default:1] AGI("IAX2/300-517", "agi://127.0.0.1:4577/call_log") in new stack
[Jan  7 09:08:08]     -- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
[Jan  7 09:08:08]     -- Executing [111111111@default:2] Dial("IAX2/300-517", "SIP/test/111111111||to") in new stack
[Jan  7 09:08:08]     -- Called test/111111111
[Jan  7 09:08:08]     -- Got SIP response 482 "Loop Detected" back from XX.XX.XX.XX
[Jan  7 09:08:08]     -- Now forwarding IAX2/300-517 to 'Local/111111111@a2billing-did' (thanks to SIP/test-00000003)
[Jan  7 09:08:08]     -- Executing [111111111@a2billing-did:1] DeadAGI("Local/111111111@a2billing-did-ac31,2", "a2billing.php|1|did") in new stack
[Jan  7 09:08:08] WARNING[30859]: res_agi.c:2212 deadagi_exec: Running DeadAGI on a live channel will cause problems, please use AGI
[Jan  7 09:08:08]     -- Launched AGI Script /var/lib/asterisk/agi-bin/a2billing.php
[Jan  7 09:08:08]     -- AGI Script a2billing.php completed, returning 0
[Jan  7 09:08:08]   == Everyone is busy/congested at this time (1:0/0/1)
[Jan  7 09:08:08]     -- Executing [111111111@default:3] NoOp("IAX2/300-517", "0") in new stack
[Jan  7 09:08:08]     -- Executing [111111111@default:4] Hangup("IAX2/300-517", "") in new stack
[Jan  7 09:08:08]   == Spawn extension (default, 111111111, 4) exited non-zero on 'IAX2/300-517'
[Jan  7 09:08:08]     -- Executing [h@default:1] DeadAGI("IAX2/300-517", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16-----CHANUNAVAIL----------") in new stack
[Jan  7 09:08:08]     -- AGI Script agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16-----CHANUNAVAIL---------- completed, returning 0
[Jan  7 09:08:08]     -- Hungup 'IAX2/300-517'


[williamconley]

Look at the Vicidial method for a loopback call (in extensions.conf)

[gardo]

They can be on the same server. They can be integrated together to play nicely and efficiently. A separate database server is recommended though if you're running more than 30 agents. Our GoAutoDial cloud platform (http://justgocloud.com) is currently built with Vicidial and A2Billing tightly integrated together (along with some other components of course).

[williamconley]

does a2billing hold up under serious stress? ie: 1000+ phone calls with multiple vicidial dialers hitting it?

[gardo]

It can. Spread across multiple servers just like a multi-server Vicidial system.

[williamconley]

So ... how many (max) channels per server?

[gardo]

The max we had was around 500+ (can be higher if pushed to the limits). The box was highly optimized. Though it's far better to spread them out across multiple servers.

[williamconley]

so it's good for lots of Small customers, but when you have a client using 700 channels ... you have to fire up 2 billing servers for that one client! ouch. LOL

[gardo]

Yep. It's good for lots of small clients. However, when you go with the big boys you need something else. A2billing wasn't designed to handle large volume of calls on a single server.

[williamconley]

See, I thought you were claiming that you'd managed to get it to work for the Big Boys. Thanks for the clarification!

[gardo]

Err.. what claim again? I was just stating that A2billing can be configured to do multi-server ala Vicidial cluster. This increases it's capacity to handle more calls. Same concept with a Vicidial multi-server cluster.

[williamconley]

Yep, but an app like opensips can be configured to ... significantly more channels on a single server. Still looking for a "robust" invoicing system for enterprise level call center traffic. After all, it is not reasonable to bring up two billing servers for each new Vicidial client who happens to have 500 channels, is it?

[joako]

Isn't there enough detail to bill your calls already in the Vici database? All you need to do is develop a way to use it, much more efficient than sending the calls through a 2nd system just to log the calls again.

[mflorell]

Vicihost uses OpenSIPs for billing, and it is very robust, handling thousands of calls inbound and outbound per gateway machine. With a central database server we are able to scale it to multiple gateways for redundancy and growth too.

[williamconley]

Isn't there enough detail to bill your calls already in the Vici database? All you need to do is develop a way to use it, much more efficient than sending the calls through a 2nd system just to log the calls again.

And if the client in question learns that you are using his DB to bill ... you don't think he'd start to make "subtle" changes to the DB to rip you off?

Of course, if you control root and DB on the machines it is "unlikely" that this will happen, but any possible method to rip off a VOIP provider is to be exploited these days. Better to require all traffic to go through a server that validates and bills that cannot be accessed in any way other than calls passing through. This is a matter of thousands of dollars to companies that can "disappear" in a matter of minutes and resurrect themselves the next day. Ripping someone off for $5k quickly or slowly is still $5k for that ripoff artist and believe me when I say they WILL try it.