vicidial.org

I am using Accela as a SIP carrier because I use them with Teleblock they do not have a user name or password. they only provide 2 IP'S and have no idea how to set up with vicidial. Can anyone help me out? I have searched the board and saw one other thread where someone used this carrier.

I need to figure out a registration string

Here is what Accela has provided

sip.conf

69.xx.xxx.xxx
66.xxx.x.x


[AccelaSansay1]
type=friend
host=69.xx.xxx.xxx
canreinvite=no
disallow=all
allow=g729
allow=ulaw
dtmfmode=rfc2833

[AccelaSansay2]
type=friend
host=66.xxx.x.x
canreinvite=no
disallow=all
allow=g729
allow=ulaw
dtmfmode=rfc2833

Any Thoughts?

Model Intel(R) Core(TM)2 Duo CPU E4600 @ 2.40GHz
CPU Speed 2.4 GHz
Cache Size 2.00 MB
Kernel Version 2.6.18-194.8.1.el5.goPAE (SMP)
Distro Name GoAutoDial CE 2.0

Vicidial 2.2.1 | VERSION: 2.2.1-237 BUILD: 100510-2015 | Asterisk 1.4.27.1-vici | Single Server | No Extra Software After Installation | Dahdi 2.3 | VtigerCRM 5.1.0 |Sangoma 3.5.14 | CentOS 5.5 as base (modified kernel as usual)

their setup should be fairly standard then, almost any previously supplied example will likely work. The differences: NO registration string at all. And in the "Account Entry" ... no username= or secret= entries.

Otherwise, all the rules and standard methods should work. There have been hundreds of posts with standard dialplan entries. There are also semi-standard samples on your server if it has been set up (although they may have "999" where "NXX" belongs in the sample SIP carrier to avoid conficting with a real dialplan and/or allow use of special testing scenarios).

Use a given example WITH a global string and the standard 3 line dialplan (all three lines are required, the first and last should not be altered, and if properly set up the 2nd line may never need to be altered at all as well, since the only change would actually be in the global string).

Also: If you have not purchased and/or installed g729 ... it's not there. Do not include the "allow=g729" line. g729 does not come pre-installed on any asterisk/vicidial solution (to do so would be to violate the licensing of g729).

Hi William here is what I have

the registration string is blank and then I have this

[AccelaSansay1]
type=friend
host=xx.94.xxx.1xx
canreinvite=no
disallow=all
allow=ulaw
dtmfmode=rfc2833

[AccelaSansay2]
type=friend
host=xx.1xx.x.2
canreinvite=no
disallow=all
allow=ulaw
dtmfmode=rfc2833

[domestic]
exten => _91NXXNXXXXXX,1,Dial(SIP/${EXTEN}@AccelaSansay1)
exten => _91NXXNXXXXXX,2,Dial(SIP/${EXTEN}@AccelaSansay2)
exten => _91NXXNXXXXXX,3,Congestion
exten => _91NXXNXXXXXX,103,Congestion

[international]
exten => _011.,1,Dial(SIP/${EXTEN}@AccelaSansay1)
exten => _011.,2,Dial(SIP/${EXTEN}@AccelaSansay2)
exten => _011.,3,Congestion
exten => _011.,103,Congestion

and its not registering



server*CLI> sip show peers
Name/username Host Dyn Nat ACL Port Status
900/900 (Unspecified) D N 0 Unmonitored
203/203 148.240.233.39 D N 30060 Unmonitored
201/201 (Unspecified) D N 0 Unmonitored
goautodial/6134387000 64.120.98.178 N 5060 OK (5 ms)
4 sip peers [Monitored: 1 online, 0 offline Unmonitored: 1 online, 2 offline]

of course it's not registering. there's no registration string. because one does not use registration with IP based authentication. you give them your IP, they give you theirs. registration is redundant.

you have not grabbed a "standard VICIDIAL dialplan". Grab the manual and/or use samples and/or google the vicidial dialplan.

and use the globals string when you do it.

I'd post something now, but honestly I'm tired (just got back from the land of the mouse, been carrying a 7-year-old for a few hours ....).

Ok Ill give it a whirl Manana Im beat myself.. Thanks!

William,

It worked! I can NOW DIAL FROM MY SYSTEM!!

There is a delay but not CHOPPY..

testing all day today went well..

Maybe I can get you to do a TUNEUP and we are in business!

Thanks for all your help!

there is a slight delay in voip of course

My system was using Goautodial SIP and not Accela ... I am getting an error

Call Rejected: CONGESTION Cause: 21 - Call rejected.

which im sure is Accela rejecting my call


exten => _91XXXXXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _91XXXXXXXXXX,2,Dial(${SIPAccelaSansay1}{EXTEN:1},,tTo)
exten => _91XXXXXXXXXX,3,Hangup

Asterisk CLI


SIP/13102729703@AccelaSansay1||tTo") in new stack
-- Called 13102729703@AccelaSansay1
[Apr 4 06:44:11] WARNING[11274]: channel.c:3573 ast_channel_make_compatible: No path to translate from SIP/AccelaSansay1-00000014(256) to Local/8600051@default-5350,1(64)
[Apr 4 06:44:11] WARNING[11274]: chan_sip.c:3887 sip_write: Asked to transmit frame type 64, while native formats is 0x100 (g729)(256) read/write = 0x100 (g729)(256)/0x100 (g729)(256)

if you have not installed g729, you cannot USE g729 (like trying to pour diesel fuel in a chevy volt)

Bill

I can appreciate what you are saying but I did do some troubleshooting before posting.. I eliminated the line for that codec and it gave me the same message with Ulaw..

I talked to Accela and they actually see my call coming thru ... he says its because of my caller ID .. I have the caller ID set on the softphone and on the admin phone section and its still coming up 0000000000

any idea on how to set this?

LOL, but you posted a g729 version

while native formats is 0x100 (g729)(256)

and without g729, that was doomed to fail.

try sip debug and see if you can find the exact issue/format

does your provider list their codecs? did you choose g729 on their control panel so THEIR system is insisting on g729? (some systems allow creation of a "connection device" which will have the codec hard-coded, requiring the deletion of the device and creation of a new one to get rid of the codec requirement or change to a different codec).

but this would all be spelled out in a sip debug (long read, but informative).

callerid is set per campaign, other callerids are ignored pretty much

Ok Bill I have Installed g729.. and PAID MY 10 BUCKS PER CHANNEL to DIGIUM I now hear a recording from my carrier that says contact them ... he says its the caller id coming up all 00000000


Channel Local/8600051@default-56e6,1 was answered.
-- Executing [913102729703@default:1] AGI("Local/8600051@default-56e6,1", "agi://127.0.0.1:4577/call_log") in new stack
-- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
-- Executing [913102729703@default:2] Dial("Local/8600051@default-56e6,1", "SIP/13102729703@AccelaSansay1||tTo") in new stack
-- Called 13102729703@AccelaSansay1
-- SIP/AccelaSansay1-00000019 is making progress passing it to Local/8600051@default-56e6,1
== Manager 'sendcron' logged off from 127.0.0.1
[Apr 4 08:25:21] WARNING[21504]: chan_sip.c:13075 handle_response_invite: Received response: "Forbidden" from '"M0404082515000000803" <sip:0000000000@67.210.114.124>;tag=as45e96ef3'
-- SIP/AccelaSansay1-00000019 is circuit-busy
== Everyone is busy/congested at this time (1:0/1/0)
-- Executing [913102729703@default:3] Hangup("Local/8600051@default-56e6,1", "") in new stack
== Spawn extension (default, 913102729703, 3) exited non-zero on 'Local/8600051@default-56e6,1'
-- Executing [h@default:1] DeadAGI("Local/8600051@default-56e6,1", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----21-----CONGESTION----------") in new stack
-- AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ---------- completed, returning 0
== Spawn extension (default, 8600051, 1) exited non-zero on 'Local/8600051@default-56e6,2'
-- Executing [h@default:1] DeadAGI("Local/8600051@default-56e6,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0---------------") in new stack

callerid is set per campaign, other callerids are ignored pretty much

have you set the callerid for the campaign?

DOH!

beware the digium g729s ... when you run out of channels, your dialer will fail. be sure to have enough channels OR implement a "use this many g729 then switch" dialplan.

Hello...

i am facing the same problem.. the sip show peers keeps on saying that the Accela is unreachable.. any thoughts on how i can resolve this? Thanks much for the help..

-Newbie Here..

1) Welcome to the Party!

2) As you are obviously new here, I have some suggestions to help us all help you:

When you post, please post your entire configuration including (but not limited to) your installation method and vicidial version with build.

This IS a requirement for posting along with reading the stickies (at the top of each forum) and the manager's manual (available on EFLO.net, both free and paid versions)

You should also post: Asterisk version, telephony hardware (model number is helpful here), cluster information if you have one, and whether any other software is installed in the box. If your installation method is "from scratch" you must post your operating system and should also post the .iso version from which you installed your original operating system. If your installation is "Hosted" list the site name of the host.

If this is a "Cloud" or "Virtual" server, please note the technology involved along with the version of that techology (ie: VMware Server Version 2.0.2). If it is not, merely stating the Motherboard model # and CPU would be helpful.

Similar to This:

Vicibox X.X from .iso | Vicidial X.X.X-XXX Build XXXXXX-XXXX | Asterisk X.X.X | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation | Intel DG35EC | Core2Quad Q6600
_______________________


Unreachable is possible for two reasons:

1) The "qualify" packet sent to the carrier takes too long to return (if qualify=yes or qualify="some number", yes=1000=1 second and "some number" will be the number of nanoseconds it must get back before). If the packet takes too long, it is marked unreachable and asterisk will DISQUALIFY this sip account and refuse to use it for outbound calling.

2) Same as #1, except the packet NEVER returns (which can be due to non-response or due to a firewall blocking the response).

Solution: Change "qualify=no" instead of yes. This will remove qualify as your possible problem. Then the asterisk system will send the call without checking. If there is a firewall problem, the call will now "just fail" because of the firewall problem. If there was a "slow response" problem, the calls will suck. If there was a "we don't reply to qualify packets" problem, the calls will just work (some carriers refuse qualify packets).

IF your vicidial server has a private IP (ie: the IP of the server is 192.168.x.x or 10.x.x.x family of IP addresses), then the problem is 95% of the time ... firewall.