Need help in setup of SIP users and trunk

I worked with Asterisk a number of years ago and have now been given to set up a new system.

On a CentOS 7 box, I installed Asterisk and added a SIP trunk and users. My provider gave me a separate fiber line with an IP plan and said to use those IP’s. The info he gave me was:

P2P Pool:
Provider P2P IP:
My P2P IP:
External Pool:
Provider Signaling IP:
Provider Media IP:
My Signaling IP:

I connected the line to my router and forwarded the packets to my server The router has an Internet connection and I forwarded SIP and IAX ports from there also.

externip =
localnet =
externaddr =
externtcpport = 5060

And the extensions.conf:
exten => 100,1,Dial(SIP/100)
exten => 101,1,Dial(SIP/101)
exten =>1000,1,Answer()
same => n,Wait(1)
same => n,Playback(hello-world)
same => n,Hangup()
exten => _X.,1,Set(CALLERID(num)=)
same => n,Dial(SIP/${EXTEN}@provider-out)

exten => s,1,Dial(SIP/100)
exten => ,1,Dial(SIP/100)

I then installed Zoiper on two computers in the LAN and on my laptop at home.

From home, I just type a landline/call number and the call goes out just fine. I can dial 1000 and hear “Hello World”

From the LAN, if I dial an extension (e.g. from 100 I dial 101), that extension does not ring.

If I dial 1000, no sound is received although the console says that it is playing the sound file.

If I dial a landline/cell number, the landline rings, neither party can hear each other.


add also comedia to your nat settings, also verify on the SDP that the media is sent to the correct address, check the CONTACT address

chan_sip only has community support. New installations should use chan_pjsip.

What is the purpose of provider-in? It will be indeterminate whether incoming calls go there or to provider-out, unless the provider’s From headers literally contain “provider-in”.

chan_sip does not support local media addresses that differ from the local signalling address.

Please describe the routing used from your home phone, in particular the NAT involved.

Please provide logging of the failed calls.

Ok, I’ll change nat to comedia. Sorry, but I don’t understand the test of your suggestion. Kindly explain, if you will.

Yes, the provider-in section doesn’t seem to be doing anything. Incoming calls go to provider-out as far as I can determine.
On my router, I forwarded all packets for and to both on the Internet port as well as the dedicated trunk port.
On my home laptop, I didn’t specify any proxy or STUN; just entered my office router’s Internet IP.

From the office PC connected to the same LAN as the server, when I dial 1000, I hear no sound. This is what the server shows:

== Using SIP RTP CoS mark 5
– Executing [1000@test:1] Answer(“SIP/100-00000010”, “”) in new stack
– Executing [1000@test:2] Wait(“SIP/100-00000010”, “1”) in new stack
– Executing [1000@test:3] Playback(“SIP/100-00000010”, “hello-world”) in new stack
– <SIP/100-00000010> Playing ‘hello-world.gsm’ (language ‘en’)
– Executing [1000@test:4] Hangup(“SIP/100-00000010”, “”) in new stack

On the other hand, if I dial 101 (another PC running Zoiper), the call apparently gets routed to the provider’s trunk as shown here:

== Spawn extension (test, 1000, 4) exited non-zero on ‘SIP/100-00000010’
== Using SIP RTP CoS mark 5
– Executing [101@test:1] Dial(“SIP/100-00000011”, “SIP/101”) in new stack
[Apr 27 13:27:05] WARNING[37391][C-0000000d]: app_dial.c:2576 dial_exec_full: Unable to create channel of type ‘SIP’ (cause 20 - Subscriber absent)
– No devices or endpoints to dial (technology/resource)
– Executing [101@test:2] Dial(“SIP/100-00000011”, “SIP/101@provider-out”) in new stack
== Using SIP RTP CoS mark 5
– Called SIP/101@provider-out
== Everyone is busy/congested at this time (1:0/0/1)
– Auto fallthrough, channel ‘SIP/100-00000011’ status is ‘CHANUNAVAIL’

Update: Noticed something here. When a LAN user registers, the console shows:
Registered SIP ‘100’ at

This is wrong. Why is the IP showing as the router’s Internet IP instead of the PC’s LAN IP?

Update: On the Zoiper on the two LAN PC’s, I placed a check mark on “User rport” and now the registration shows their LAN IP’s. They can dial each other and me at home.

However, I can hear them but they can’t hear me. Nor can they hear each other.

Because the router is registering, or NATting the request. The question is why is the LAN phone going through the router at all. I think we definitely need much more complete details of your network structure.

Although I don’t know why the phones are configured to access Asterisk through the the router at all, you should disable any SIP ALG on the router, and replace it by appropriate port forwarding.

They aren’t. The address I gave is which is the LAN IP of the router. As I said, putting a check mark on the force rport fixed this. The phones can now call each other, though the LAN ones can’t hear anything.

And… with all this going on, I’ve somehow lost connection to the trunk. No idea what I’ve messed up there :frowning:

Trunk is back online thanks to another thread where @david551 said to disable qualify.

I’m almost there guys, if only I can get the LAN clients to get some sound.

As it turns out, the LAN clients are connecting using SIP while from home I connect via IAX2. Dunno why, it just says that that’s the only option available. Can I force LAN clients to connect using IAX also? how?

Indeed. When I reconfigured Zoiper on LAN to connect via IAX2 (and changed the dialplan) they can now get sound. I wonder why. Though am too far gone to spend time more on R&D for SIP. Shall just live with it.

It’s been many years since I’ve used IAX (I still have a ‘gen 2’ Iaxy somewhere…) but as I remember, one of it’s advantages was that it handled NAT issues better.

qualify=yes just means that the peer should be monitored, so, being a trunk, it should be. If I set this, the status changes to “unreachable” and I can’t make calls. OTOH, removing it sets the status to “unmonitored” and I can make calls.
That’s curious. If the firewall rules are making it unreachable then how are calls going through? Hmm…

Monitoring is done by sending OPTIONs requests. If the other side is broken and ignores them completely, it can appear to be down when it would still accept an INVITE.

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