I've read through all the posts I can find here and the docs and I know I'm close but close isn't enough. Elastix/Asterisk isn't seeing the inbound calls. I get "the number you dialed not in service", the call never makes it to my pbx to be routed. If I reboot my old Asterisk server calls work fine. It appears I am messing up uje registration with Broadvoice but I can't figure out how. Registry String = 480xxxxxxxassword@sip.broadvoice.com/480xxxxxxx User Context = 480xxxxxxx username=480xxxxxxx user=480xxxxxxx type=user secret=password nat=yes insecure=very host=sip.broadvoice.com fromdomain=sip.broadvoice.com allow=ulaw&alaw Am real confused. As some others have found outgoing is fine. In monitoring asterisk with "asterisk -rvvvvvvvv" I get nothing on inbound which makes me think my registration is buggered
"the number you dialed not in service" is almost certainly coming from your elastix box and probably because you don't have an inbound route set to handle it, I suggest you set up a catchall inbound route before you go further.
That helps narrow it down. I thought I did have a catch all route but I need to recheck with that in mind. Would the Asterisk console see anything in that case ? As it didn't I assumed the message from from the telecom.
You'll get the most information by set verbosity 99 set debug 99 from CLI lot's of stuff and it goes fast, sometimes it's easier to examine /var/log/asterisk/full (post partum)
absolutely, or tail -1000 /var/log/asterisk/full|less for the last 1000 lines in a search-able fashion. (I believe you still need to set the verbosity and debug level in the CLI first though) add sip debug ip sip.broadvoice.com at the CLI for even more detail and I hate those idiotic smileys too!!
Yep I know tail, been working on Linux boxes for years. However the debug out was shall we say a tad confusing, might as well have been written in Greek. Try to create a new catch all route this morning
Ok I 'think' this confirms the call is getting through but not being routed. Now I need to figure out why, I added a few lines around the relevant one in case there was usful info there
Okay, let's start from scratch. What do you have in you PEER settings? In most cases where people have trouble with incoming calls, we find that the USER settings aren't necessary and aren't even being used. I would suggest you start over from scratch with your trunk configuration, and this time concentrate on your PEER details, but make sure there is a context=from-trunk statement in there. Your registry string looks fine, but make sure you have an Inbound Route for DID 480xxxxxxx and no CID. Also you probably want a disallow=all ABOVE your allow= statement (and if the CLI keeps showing strange messages about codecs, try making a separate line for each allowed codec, e.g. disallow=all followed by allow=ulaw and allow=alaw (not saying the way you did it is wrong, just trying to eliminate possibilities of problems here). One other thing, the insecure statement has changed in Asterisk 1.4, you should now use insecure=port,invite instead of insecure=very. One thing is for sure, you can work on this for weeks and it will never work without a proper context= statement, which in this case will probably need to be in the PEER settings (since they are probably treating you as an extension rather than a trunk, in which case only the peer settings are used).
wiseoldowl wrote: context=from-trunk [/quote] Ok I know this is dumb question but exactly what do you mean. In my existing Asterisk setup [done by long gone buddy] "context=from-broadvoice" is in the peer setup, are you saying I need that ? I assumed it was a custom named context in Asterisk, I don't understand what the 'from-broadvoice" means. Does it have to be a name of the provider or the name of the trunk or .... ? I know this sounds dumb but I am clearly lacking some contextual knowledge [if you pardon the pun]
Okay, try this in your PEER settings (and fill in the xxx's appropriately): user=480xxxxxxx username=480xxxxxxx type=peer secret=xxxxx qualify=yes nat=yes insecure=port,invite host=sip.broadvoice.com fromuser=480xxxxxxx fromdomain=sip.broadvoice.com disallow=all allow=ulaw&alaw context=from-trunk Temporarily remove everything from your USER context and USER settings. The context= statement tells Asterisk where to send incoming calls. You will understand this better as you get more familiar with Elastix, FreePBX and Asterisk, but for now all you need to know is that in FreePBX incoming calls almost always go to the from-trunk context. Of course if you are using raw Asterisk then you can name contexts whatever you want, but in FreePBX and Elastix it's from-trunk (unless for some reason you need to insert some "shim code" in extensions_custom.conf, and you don't need to worry about that yet).
I also found the following. If I put "context=from-broadvoice" into the peer definition, Broadvoice rejects the call and transfers it to my alternate phone #. Peer [outgoing] is named 'broadvoice'. All other combination of that have the same # not in service result
And the crowd goes wild. Thank you sir, you are a lifesaver. The trick is nothing in the user context. I was fooled by my old raw asterisk setup, I didn't do it but have been using it for a couple of years. Now I can ditch it. Thanks once again
One other hint, if you have any problem with incoming or outgoing touch tones, try adding: dtmf=auto dtmfmode=inband You may have to play around with those a bit but the main thing is that when you dial out you want to be able to control other IVR's and when people call you they need to be able to control your IVR (if you use one). But those two settings have worked well with other providers.
