Inbound DID's not working

[shallenbeck]

Hello, very new to this although I have been using outbound campaigns for a while.

Using GOAUTODIAL
VERSION: 2.2.1-237
BUILD: 100510-2015

I have used this rather successfully for strictly outbound campaigns in the past, but now I am faced with a new client who wants to use it for inbound/outbound blended campaigns.

I have 2 providers, 1 SIP trunk provider for the outbound calls as they allow autodialers on their service, but they provide no DID's. (although they have told me they could route my DID's if I get my provider to point them to their IP's, I am not sure if this would help though).

I have a small account with Voip.ms for another client with a small PBX running through their trunks so I decided to purchase DID's from them and use their trunk for inbound.

Although my outbound trunk seems to be working well, my issues is that I cannot get any of the DID's to work from my voip.ms inbound trunk. The trunk is configured as follows:

[voipms]
canreinvite=no
host=xxxxxxx.voip.ms
secret=xxxxxx
type=friend
username=xxxxxx
disallow=all
allow=ulaw
fromuser=xxxxxxx
trustrpid=yes
sendrpid=yes
insecure=port,invite
context=trunkinbound

a 'sip show peers' displays:
voipms/xxxxxxx xx.xx.xx.xx N 5060 OK (18 ms)

indicating there is a connection.

I have gone through the manual for creating an inbound group, and adding DID's and pointing them to the group. I have even just tried pointing the DID straight into a voice mailbox. But it seems no matter what I do, when I call the number, all I get back from asterisk is:

NOTICE[31404]: chan_sip.c:15147 handle_request_invite: Call from '' to extension 'XXXXXXXXXX' rejected because extension not found.

I have tried this for several DID's with no difference in results.

I have changed file/directory permissions

/usr/share/astguiclient
/var/log/astguiclient
/var/lib/asterisk/agi-bin
/var/lib/asterisk/sounds
/var/spool/asterisk/monitor
/var/spool/asterisk/monitorDONE

chown -R asterisk:asterisk folder/filepath
chmod -R 755 folder/file path

to match what was posted in the forum here named: "[Resolved] Vicibox inbound setup challenges" (can't link to it because I am new and this is my first post) thinking that might be the issue, but seemed to have no effect

I am at the end of my rope, and I have to demo this tomorrow....

I love the product, and I think it is AWESOME something so powerful is open source and available to everyone. I just wish I understood more of whats under the hood and how to resolve this issue.

ANY help would be appreciated. I have a lot of experience with FreePBX, and have been trying to teach myself dial plan programming in my spare time, but I think would still be considered a novice at this by most, so please consider this if/when responding.

Thanks in advance!!

[williamconley]

it's not about permissions. it's about "pathway".

you DO have it close to working, congratulations. (rejected because extension not found is GOOD, because you GOT the call, now you just have to send it to the appropriate agi script in vicidial and you're done).

before we start: Please remember you are NOT using "GoAutoDial 2.2.1", you are likely using GoAutoDial CE 2.0 which installed Vicidial 2.2.1 (the actual software we are all talking about, vs the installer .iso that gardo made to install the Vicidial dialer).

Next:

So you understand what is happening ...

The call is made and eventually lands at your VOIP company. Based on your settings with them, they send the call to your server with coding specifying the number that they dialed and their callerid information.

Your system "authenticates" the inbound call (based on user/pass and/or IP address). It matches the ip address to a sip context's "host=" setting, then checks the user/pass if it's set up to do so (in most cases, just the IP does the trick, but because there are a LOT of settings this can go awry and end up authenticating to the WRONG sip account, more on that later!).

WHICHEVER sip account it ultimately authenticates to, it will acquire the "context=" setting. Then it will go to THAT context in "extensions.conf" (or an included file of that top level file) and attempt to dial the "number they dialed" (DID!) inside that context. If there is no such number or context, the call will fail.

So: since the call comes in, and there IS a catch-all in the "trunkinbound" context ... somehow it isn't getting to trunkinbound. Perhaps it is authenticating to a sip account with a different context=?

Set ALL your carriers SIP account to have "context=trunkinbound". The setting is ONLY used for inbound calls anyway, so that's how it should always be set unless you want to disable calls from a specific provider. (But beware that an unusual situation, causing another provider to authenticate to that sip account could cause that call to fail unexpectedly!)

For troubleshooting purposes:

In asterisk use sip debug (later sip no debug to turn it off) to single out a call and see if you can acquire the context actually being used. This can often be used to find the sip account being used, and then you can try to figure out how it got THERE.

If the call is being sent to extension "s" instead of a number, you CAN set extension "s" to go to the same place that extension "_X." goes to (copy all the lines) and *poof* in it goes and vicidial will deal with it. Unfortunately, you will not know what number was dialed.

However: if the DID was included, but not in a way the present dialplan understood, the dialplan can be altered to catch it. As long as the DID is somewhere in the SIP debug.

[shallenbeck]

Thank you williamconley
This gives me something to chew on.

Unfortunately my demo did not go well today as for some reason when I started an outbound campaign, even though I was getting the call on my phone (for testing purposes) it never seemed to bridge with the conference I had open as a logged in agent. The call would disconnect and the dialer would proceed to the next number.

In all the outbound calling I have done, I have never seen this happen. I have heard of a script the sets all settings back to default installation settings, and I am thinking seriously about running that as currently only 'test' agents and campaigns are setup anyway.

[williamconley]

Never fear starting over. It's educational.

And remember to run the server ip change script if you change the ip address of the server.