Voxbeam issues, No inbound

Hey guys,
Still having problems. Ugh. I can call outbound just fine. Inbound was working when for a specific trunk when I only had one inbound route assigned. I’ve attached my settings on the trunk.

I tried to setup inbound routes per did and now inbound is not working at all. I deleted everything and inbound is still not working. I want it set so that when a specific DID is called, a specific extension rings. Can anyone help please and thank you.

i have never used voxbeam. what do they recommend as a trunk definition? most ITSP’s will give you basic parameters.
your inbound route did must match what voxbeam is sending you or what comes out of the context you are using in the trunk. try changing the context to be “from-trunk”

Hi Bob,
Thank you for your reply. I asked about the Voxbeam trunk definition and here is the reply that I received:

Hi Sean,

We can just provide the general parameters to configure the DID trunk in Asterisk config file named “extensions.conf” . You will have to define your incoming context, like the parameters below:

[inbound] <-------- must be the context name defined on your sip peers
exten => 14805038553,1,Answer
exten => 14805038553,2,Dial(SIP/1000,25,Ttr) ; incoming calls are redirected to SIP telephone with number 1000
exten => 14805038553,3,Hangup

note: 14805038553 is the sample DID

Where does this context name go in the freepbx gui for the screenshots above? I’m assuming this goes on the user details tab. Would this replace where i have ‘from-pstn’ ? What do you think?

Check your Asterisk for incoming INVITE, then check what is in.

OK. Slow down. This is a three step process, and it doesn’t pay to try to skip steps. Also do not, under any circumstances, try to do what the knuckleheads at VoxBeam told you to do.

First, set up an “any/any” inbound route. This will do two things

  1. It will get your incoming calls flowing.
  2. It will give you the actual incoming numbers they are sending you. Look in /var/log/asterisk/full for a message about “you should set up a specific DID for this.”

Next, get your inbound trunk working. Chances are the only thing you’d actually need to do is set your outbound trunk to be a “type=friend” instead of “type=peer” or “type=user”, assuming they are using the same server for inbound and outbound traffic.

Next, get your inbound routes set up.

You already have an inbound route with no DID and no CID matching set up, so you should have incoming calls. Dial each of your DIDs in order and look in the /var/log/asterisk/full log and see what number is actually getting sent to you.

If the number is coming in with extra crap at the beginning (+, for example), you can set up the inbound context to be “from-pstn-e164-us” context to strip the extra stuff off and make the inbound DIDs more like what you are expecting.

Hi Dave,
Thank you for your help here. A couple of problems that stalled me working through your steps. One: Voxbeam has different inbound and outbound servers. Inbound is: Outbound is: sbc.voxbeam.com
I could not get the inbound to connect - again, outbound is working fine.
Also, I did get a call to connect using contex=from-pstn. that is no longer working. Here is the call record from that call that did connect (see attached). is there anything here that can help us?

Not a problem. Set up a second trunk for your inbound. Are they using username/password or IP-based authentication? If user/pass, then the port should be able to support either PJ-SIP or Chan-SIP. If IP-based (they want to know your IP address), then you need to use Chan-SIP for the trunk.

I don’t think we’ve talked about your network. If you server inside the network (does it have a single interface on a non-routable address) or do you have a dual-homed (one routable address, one not) server?

At this point, there are about four different paths, each with reasonable involved setup instructions. Here’s the synopsis:

  1. If your PBX address is non routable, you will need to set up all of the Chan-SIP stuff for the trunk. You will also need to set up NAT and set both the local address and External IP addresses in the GUI. If you are using usernames and passwords, your server should be able to get incoming traffic from the server through the firewall port that’s open from the authentication. If you are using IP-based authentication, you will need to open up port forwarding rules in your firewall to allow all traffic from the provider’s IP address through your firewall into the PBX.

  2. If your PBX address is routable, you need to make sure the integrated firewall is set up correctly. Put the IP address of your TISP into the server as a trusted network so that they aren’t blocked.

  3. Double check what address and port they are sending your traffic too. Different SIP implementations use different SIP ports. Make sure the one you want to use is listening on the right port for your TISP. I don’t know about Voxbeam, but most TISPs will let you specify the port on your server they will be using. If they do not, make sure that the SIP port the service provider is sending to is the one your chosen SIP module is listening on.

  4. Set up a trunk for each of the TISP servers. Set the “peer” details in the inbound one and the “user” details in the outbound. The outbound is the only one that will need a password. Don’t set a password on the inbound unless Voxbeam told you they will be authenticating. Do set the IP address (don’t use names - DNS resolution can cause your system to go catatonic for up to 30 seconds, causing all of your in-profress calls to drop).

To double check they TISP’s work, you should use Wireshark or tcpdump to listen to the traffic from your provider.

An example: log in to your PBX through the console (log in as root) and (assuming you are using eth0 for your inbound PBX connection) run the following program:

tcpdump -I eth0 host sbc.voxbeam.com
– or –
tcpdump -I eth0 host

The output will show you every packet that is coming in from your provider and the ports they are sending to. Remember that your inbound should be their outbound, so it’s important to read what they are saying about the direction of the ports.

There are lots of places for an inbound call to fail. These are just the most obvious ones.