Trunk Configuration

1

We use voipinnovations as our provider and have been live now for a little over a month. We continue to have intermittent call problems and I received the following from them recently:

We do see there were some failures to where your network at IP address nn.nn.nn.nn was returning a 404 not found to our invites from IP addresses (209.166.128.200, 64.136.173.22, 192.240.151.100) as it appears you were sending calls from those IP addresses to your own network. We would advise to ensure that you are accepting calls from any of our IP addresses.

Here’s what they advise as required IP addresses:
Inbound / Origination:
Primary: 64.136.173.31
Secondary: 64.136.174.30
Tertiary: 64.136.174.20
Quaternary: 209.166.154.70
Quinary: 192.240.151.100

Outbound / Conversational:
Primary: 64.136.174.30
Secondary: 64.136.173.22
Tertiary: 209.166.128.200
Quaternary: 192.240.151.100
Quinary: N/A

My main question is: the IP addresses with the 404s errors mentioned above, are from the Outbound IP list - Should I also set these up as Inbound trunks? The system was set up for me by a consultant and I am just now digging into the details. Any comments about current configuration is welcomed.

Following are the outgoing sip settings for my inbound trunks. As an FYI, the inbound trunk’s incoming sip settings are blank.

Thanks, Karen

VI-TRUNK-IN-1
Outgoing:
type=friend
trustrpid=yes
sendrpid=yes
port=5060
host=64.136.173.31
dtmfmode=rfc2833
disallow=all
context=default
canreinvite=no
allow=ulaw,alaw
insecure=port,invite

VI-TRUNK-IN-2
Outgoing:
type=friend
trustrpid=yes
sendrpid=yes
port=5060
host=64.136.174.30
dtmfmode=rfc2833
disallow=all
context=from-trunk
canreinvite=no
allow=ulaw,alaw
insecure=port,invite

VI-TRUNK-IN-3
Outgoing:
type=friend
trustrpid=yes
sendrpid=yes
port=5060
host=64.136.174.20
dtmfmode=rfc2833
disallow=all
context=from-trunk
canreinvite=no
allow=ulaw,alaw
insecure=port,invite

VI-TRUNK-IN-4
Outgoing:
type=friend
trustrpid=yes
sendrpid=yes
port=5060
host=209.166.154.70
dtmfmode=rfc2833
disallow=all
context=from-trunk
canreinvite=no
allow=ulaw,alaw
insecure=port,invite

2

IMHO your trunks are not configured properly.

You should have an inbound and outbound SIP profile for each trunk with an IP that is both inbound and outbound (64.136.174.30 and 192.240.151.100) an inbound only trunk for 209.166.154.70, 64.136.174.20 and 64.136.173.31. Outbound only trunk for 209.166.128.200 and 64.136.173.22.

Change the context for inbound from “default” to “from-trunk”. Change the outbound context to “from-internal”

Or, you can eliminate the context parameter and FreePBX will figure it out.

You should find this post informative: https://wiki.freepbx.org/display/FPG/Trunk+Sample+Configurations

3

Thank you jerryriggin. What you said makes sense and I appreciate the link to the ‘Trunk Sample Configurations’ post.

4

Also, “type=friend” says “set up an inbound and outbound trunk for this server”.

For inbound-only trunks, set the type parameter to “type=peer” and for outbound-only trunks, set the type to “type=user”. This will help to not send calls to the VI outbound-only servers.

1 Like
5

Thanks cynjut, adding to my to-do list.

6

This is a bit of an oversimplification. A friend is a chan_sip endpoint that is both a user and a peer. Otherwise a SIP endpoint is defined as either a user or a peer. Both users and peers are capable of receiving an inbound SIP INVITE, but the difference comes from the order with which Asterisk looks for matches. When a SIP INVITE arrives at the PBX, Asterisk will first try to match the string in the SIP FROM header against the list of SIP users on the system. If there is no match, Asterisk will then attempt to match the host against a list of peers on the system.

For the majority of FreePBX use cases, the distinction is largely academic, as most sip endpoints have a single duty, they are either trunks or extensions. The use case where this is critical is in the case of a gateway, in which its possible that the gateway is considered both a trunk and an extension (i.e. a gateway with a mix of both FXO and FXS ports). In this case it is necessary to properly configure Asterisk such that an inbound SIP INVITE from the gateway is properly identified as either an inbound trunk call (peer) or a local extension call (user).

4 Likes
7

Yeah - it is.

1 Like
8

It is not over simplified for someone without a working knowledge of deeper workings of SIP and dial plan. I think Lorne’s example is the most accurate, understandable and useful explanation for a non-geek user than I have seen in any asterisk docs, and I have seen a few. Kudos.

1 Like
9

The cool thing about these forums is that there’s room for both “over-simplified” and technically accurate, more complete explanations. My explanation is a good starting point for many people and gets the gist of the discussion in a small bite. If they want to get more, the old explanation doesn’t get in the way of a more complete understanding. At least, that’s my hope.

10

I am just now digging into this and want to proceed with caution. I have 8 sip trunks set up. Four 'IN’s and Four ‘Outs’.

VI-Trunk-In-1 64.136.173.31
VI-Trunk-In-2 64.136.174.30
VI-Trunk-In-3 64.136.174.20
VI-Trunk-In-4 209.166.154.70
VI-Trunk-Out-1 64.136.174.30
VI-Trunk-Out-2 64.136.173.22
VI-Trunk-Out-3 209.166.128.200
VI-Trunk-Out-4 192.240.151.100

On all 8, in the ‘sip Settings’ tab, only the Outgoing section has been filled in, and slightly differently between the Inbound and Outbound ‘Outgoing’.

For an IP Address which is used in both directions, like 64.136.174.30, here’s what’s currently set up, in two different trunks.

VI-TRUNK-IN-2
Outgoing:
type=friend
trustrpid=yes
sendrpid=yes
port=5060
host=64.136.174.30
dtmfmode=rfc2833
disallow=all
context=from-trunk
canreinvite=no
allow=ulaw,alaw
insecure=port,invite

VI-Trunk-Out-1
Outgoing:
type=friend
host=64.136.174.30
context=default
insecure=port,invite
disallow=all
allow=ulaw
dtmfmode=rfc2833

If I’m following, I should have a single trunk, like so:

VI-TRUNK-Combined
Outgoing:
type=friend
host=64.136.174.30
trustrpid=yes
sendrpid=yes
port=5060
dtmfmode=rfc2833
disallow=all
context=from-internal
canreinvite=no
allow=ulaw,alaw
insecure=port,invite

Incoming:
type=friend
host=64.136.174.30
dtmfmode=rfc2833
disallow=all
context=from-trunk
allow=ulaw
insecure=port,invite

11

My main test system is down right now and I can’t get to any of my operational systems from here, so I might get a couple of thing backwards. Having said that - there are a few differences that you can “highlight”.

The inbound Trunks should be set up as “user” (or “peer”, the screen says which is which) type connections. They will have a context and should “trustrpid”. You don’t need a “port” setting on an inbound route - you already told VI how to get here. You also shouldn’t need “allow” or “disallow” since the SIP settings in your system are already doing that.

The Outbound trunks should be set up as “peer” type connections. They don’t need a context and should “sendrpid”.

I use VI for my primary provider and I have the same eight trunks set up. I didn’t bother with the “combined friend” trunk, just because I was afraid they were going to add or remove another address or server again. Also, depending on your account type, they will want you to use a specific IP address for your outbound traffic, so you’re going to want to set up the trunks in order.

1 Like
12

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.