Multiple IP routed trunks on Elastix 2.0

garrywadams

Joined
Jul 1, 2010
Messages
37
Likes
0
Points
0
#1
I have a very strange issue and I'm hoping someone here can shed some light on it.

I'm running Elastix 2.0 (Asterisk 1.6 and FreePBX 2.7) and I upgraded FreePBX to the latest 2.8 build. (although, this issue was occuring on 2.7 as well so I don't think that is related, just FYI) I have 2 VOIP carriers trunked into the system. I have a Bandwidth.com trunk set up using IP routing (NOT registrations). I have also started working with vitelity, which also uses IP routing and NOT registrations. (The service can be set up to use registrations, but with the volume we plan on putting through the system IP routing is the preferred method.)

Here's the problem... When I installed the Vitelity trunks, oudbound calls work just fine, but inbound calls fail every time. SIP Notify messages are getting to my PBX, but the carrier isn't getting a response. I spoke to vitelity support and we have been working on this for several days. Finally their engineer suggested that our system may have a problem using 2 different trunks that utilize IP routing. We deleted the Bandwidth.com trunks and left only the vitelity trunks and calls started coming in just fine. I rely on the bandwidth.com trunks for my primary number so we didn't leave it that way for long, but it told us what we needed to know. For some reason the system isn't working with 2 IP routed trunks. We changed the vitelity trunk to use registrations and I can receive calls from both just fine.

Does anybody have any ideas? I'm more than willing to post any configuration information that may help diagnose the problem. Any light that we can shed on this issue would be a great help. We really want to get both systems working in tandem. Thanks!
 

ashir24

Joined
Sep 1, 2009
Messages
75
Likes
0
Points
0
#2
strange.
i have multiple voip trunks. and they all works fine. i mean both inbound and outbound.
are you behind a firewall, if you post your trunk config here it might help to trace.
have you checked the log when you were having trouble receiving calls.
have you forwarded SIP requests to your elastix box (if you are behind a firewall).
have you tried with different SIP ports??
 

garrywadams

Joined
Jul 1, 2010
Messages
37
Likes
0
Points
0
#3
Yes, very strange.

It is natted behind a SonicWall NSA 2400. I have forwarded the typical ports (UDP 5060 and 10000-20000) to the private IP. I'm pretty sure it isn't a firewall issue since the BW.com trunk is running off of the same public IP behind the same firewall on the same ports just fine.

Here's the trunk information as listed on the Vitelity website for IP authentication (They have 2 separate trunks, one for inbound calls and one separate trunk for outbound calls):

[vitel-inbound]
type=friend
dtmfmode=auto
host=inbound24.vitelity.net
context=from-trunk
allow=all
insecure=very
canreinvite=no

[vitel-outbound]
type=friend
dtmfmode=auto
host=64.2.142.93
allow=all
canreinvite=no
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#4
Sonic-walls are pretty well brain-dead when it comes to SIP and rtp, at least when you need more than one inbound connection, their so called "SIP helper" application is about as helpful as a deaf, dumb and blind museum guide, it will arbitrarily rewrite your connections for some incomprehensible reason to places that are equally incomprehensible, some later software loads apparently allow you to (something like) allow permanent connections or some such gibberish (duh, who would have thought of that necessity in a firewall/NAT box?) if you don't have that software load, then good luck my friend. My answer has always been to replace them, it will save you time and frustration in the long run.

dicko (who has been there and done that, their support is IMHO both arrogant and un-knowledgeable)
 

alang

Joined
Mar 19, 2008
Messages
47
Likes
0
Points
0
#5
Try this:

[vitel-outbound]
type=peer
dtmfmode=auto
host=64.2.142.93
allow=all
canreinvite=no
insecure=very

[vitel-inbound]
type=user
dtmfmode=auto
host=inbound24.vitelity.net
context=from-trunk
allow=all
insecure=very
canreinvite=no
 

garrywadams

Joined
Jul 1, 2010
Messages
37
Likes
0
Points
0
#6
@dicko
I know SonicWalls aren't ideal for SIP. We do have the latest official firmware on there. There is a newer "pre-release" version with some specific enhancements for SIP. Maybe we'll see if that helps.

We are an IT services provider and happen to be a SonicWall Silver partner so we have access to their "better than average" support. I'll also ping their engineers and see if their they have any info on multiple SIP trunks. We work with them quite often since we have about 30 appliances deployed out at our customers' locations. I don't see the device going away any time soon. It's a pretty pricey box and we have it set up with a redundant High Availability unit for Hardware failover. It's in our Data Center and we're using it for more than just VOIP. Thanks for the input, though. Maybe for our roadmap down the road we'll look at something else for our VOIP network. Any suggestions from someone who's "been there, done that"?

@alang
I'll give those changes a shot and see what happens. You're suggesting I change the outbound trunk to type=peer and add insecure=very, and change the inbound trunk to type=user?

Just curious, (as I'm still digesting all of this info) in what way will that change how Asterisk treats those trunks?
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#7
On possible layer 2 solution might be to tag all voip traffic by ip range on the edge router and just transparently pass that vlan, Cisco have mad 512 pretty well a convention, to the voip server's added vlan interface and let it sort it out itself. Many hardware sip phones will allow the voice port to be similarly tagged for QOS/TOS purposes as an added advantage.
 

garrywadams

Joined
Jul 1, 2010
Messages
37
Likes
0
Points
0
#8
I changed the type=peer on the outobund trunk and type=user on the inbound trunk and calls are coming in on both Vitelity and BW.com now. It looks like that may have been the trick.

I did some reading on type=peer, vs user, and friend. If I understand it correctly type=friend is both a peer and a user, so it should have technically worked. Type=user is a much better fit, though, since that trunk DOESN'T route any outbound calls. It is used ONLY for receiving inbound calls. Likewise, the Outbound trunk really is a better fit with type=peer as it does not receive calls, it is just used to route outbound calls.

Let's hope this fix sticks. As of now I have tested inbound calling on both BW.com and Vitelity and they are routing just fine. I'll keep everyone posted on the progress if that happens to change.

Thanks for all of the help!
 

garrywadams

Joined
Jul 1, 2010
Messages
37
Likes
0
Points
0
#9
So maybe I spoke too soon. Shortly after changing the trunk, Vitelity was working for inbound calling, but at the expense of our BW.com trunk. Calls from both providers are still not working as they are supposed to.

For now, we have set the vitelity trunk up as a registered trunk, rather than using IP Authentication. Hopefully we can find a solution to this issue.
 

Members online

No members online now.

Latest posts

Forum statistics

Threads
30,901
Messages
130,885
Members
17,561
Latest member
marouen
Top