SIP Trunk ( incoming ) remains in an "unknown" state

Hey all,

I’m currently using FreePBX v15.0.16.49 and am running into an issue where my incoming chan SIP trunk status remains “unknown” between to PBX servers. I’m fairly new and have been trying to find documentation on the configurable parameters & their meaning, but am currently at a loss.

The outbound Trunk group remains online from both servers and my current configurations are as follows:

PBX server 1 = 172.154.10.20

( outbound trunk name= server1

username=server1
fromuser=server1
type=peer
secret=joy444
qualify=yes
nat=no
host=172.54.20.20
dtmfmode=2833
context=from-trunk
allow=ulaw&alaw&g729outgoing

( incoming trunk name= server2)

type=user
secret=joy444
qualify=yes
port=5060
nat=no
insecure=very
host=172.154.20.30
dtmfmode=2833
context=from-trunk
allow=ulaw&alaw&g729

PBX server 2 = 172.154.20.20

( outbound trunk name= server2)

username=server2
fromuser=server2
type=peer
secret=joy444
qualify=yes
nat=no
host=172.54.10.20
dtmfmode=2833
context=from-trunk
allow=ulaw&alaw&g729outgoing

( incoming trunk name= server1)
type=user
secret=joy444
qualify=yes
port=5060
nat=no
insecure=very
host=172.154.10.30
dtmfmode=2833
context=from-trunk
allow=ulaw&alaw&g729

Any assistance would be greatly appreciated and a any information or user guides regarding trunk configuration parameters would be helpful.

Thanks

I don’t know that you’ll even get the state to be anything but “unknown”. Most of my connections show “unknown” and work just fine, but I’m also using IP authentication, so there’s a significant difference. Even without that caveat, there are a couple of things that could use some TLC:

  1. You have your “nat=no” setting on the peer side of the connection. NAT is for outgoing (USER or FRIEND) so that the system knows to set up your connection correctly and so that the remote end knows what ROUTABLE address to send your traffic. You don’t need to tell the inbound trunk whether the remote end is NAT - it will figure it out.
  2. Unless your equipment is in the rack with your ITSP service provider’s equipment, “nat=no” is almost certainly wrong. Your 172.x.x.x address is not likely to be routable outside your LAN. There is probably an external address that needs to be sent, and the nat= setting is how you do that.
  3. You might want to consider switching this trunk to a PJ-SIP connection type. Chan-SIP (which is what your config is saying you are using) is deprecated in new versions of Asterisk and will become unsupported in the near future. It’s included now largely as a “in case of emergency” configuration item.

Thank you very much for the advice Dave. I should have just tested it out since the outbound trunks in either direction are online. I was concerned about the incoming trunk status because they were showing as “online” with the use my previous trunk configuration ( below). However, I decided to use password authentication for the trunks but wasn’t sure what configurations settings would work. I’ll be sure to take your advice, but is there a trunk group configurations guide/tutorial available? Thanks again for the assist. - GPB1

APEX-DC-NY_OUT ( outgoing )

type=friend
qualify=yes <- I’m not sure what this means
port=5060
nat=no
insecure=very <- nor this
host=174.5.4.4
dtmfmode=2833
context=from-internal <-nor this
allow=ulaw&alaw&g729

APEX-NY-DC_IN ( incoming )

type=friend
qualify=yes
nat=no
host=174.5.4.4
dtmfmode=rfc2833
disallow=all
context=from-trunk
canreinvite=no
allow=ulaw&alaw&g729

This option means that all of the options specified are applied to both the PEER and the USER options. In other words, you don’t need to specify the outbound options if they are all the same as the inbound. It allows for some short-hand on a typical trunk config. Note that there are times when “type=friend” will not work (i.e., if you are setting up multiple trunks to the same provider and need to do user matching) but I think your setup is pretty straightforward.

The host= is the routable address of the remote server. The only way these could be the same is if both machines are set up to talk to a third server. Even then, your nat= may meed some review, since it’s unlikely that you servers are set up with a direct address on the Internet.

This is the context (program in Asterisk) that’s going to answer your incoming calls. Asterisk is a back-to-back User Agent, so all calls are actually handled by and answered by Asterisk. If an extension needs to be added to the mix, Asterisk will initiate a different call to the phone and bridge the two calls together. In essence, this is how “operators” used to connect calls before automated telephone switches. The ‘from-internal’ context is generally a good starting point. If you need to pre-process your calls, there are other contexts that you can create or use to make other things happen.

Unless you are both within and outside of North America, you should pick one of ulaw and alaw (since they are never used at the same time). If you are in the US or Canada, I’d go with uLaw “Cuz 'Murica” otherwise stick with alaw. Remove (for now) the G729 codec for testing. You can re-add it later and troubleshoot the problems it’s going to cause after you get the basic configuration working.

Almost every provider has a setup guide for Asterisk. You should look for the PJ-SIP configuration (Chan-SIP is deprecated and will lose support in the near future) but having the setup guide for Chan-SIP can help you with getting PJ-SIP set up.

I re-read your original message, and one thing that I missed was that these were setups for a pair of your own servers. I recommend you set them up exactly the same and just set the remote addresses for each and use IP Authentication. Username/Password is less secure the IP Auth since it’s easy to fake credentials, but it’s really challenging to fake an IP Address. The ‘host=’ setting should be the IP address of the remote server.

@cynjut - Thank you very much for your time and assistance. I’ll definitely take these things into consideration. Initially I was using IP authentication but encountered an issue when I tied an analog SIP gateway to the equation( the additional lines wouldn’t register until I used username & pwd authentication). I’ll also need to configure a few servers for HA, but will take things one step @ a time. If I run into any issues, I’ll definitely post them, but thanks once again, for the assist!

GDPB1

Please keep in mind that true HA probably isn’t achievable with FreePBX. There is an HA module, but it only works with FreePBX 13, which is sadly out of date. With true HA, you’d be able to move a conversation from a failing PBX to a different one without a system failure. There are structures that allow for that, but they are expensive and complicated.

There are warm spare configurations available that provide ‘PHA’ (Pretty High Availability) in that you can cut over from a failed PBX to a warm spare without a lot of grief and get your enterprise back up and running in minutes.

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