Inbound and Outbound SIP trunk help

The control panel on their website says that the inbound calls to that caller ID number is being sent to

sip:[email protected]_of_my_pbx

So how do i get my PBX to answer calls sent to it like that?

My firewall is configured with a 1 to 1 NAT for the PBX meaning the IP address configured with Gradwell is what my firewall should be showing when my pbx sends data to the provider. I’m just wondering, do I need to put my public IP anywhere in the settings even though technically if i browse the internet on that PBX system and lookup my IP online the websites detect me as the correct IP. But not sure for PBX does the PBX also have to send my public IP?

OK so I got it working. It’s actually very simple. The reason it wasn’t working is because in Asterisk settings I had to change IP to static and define the local IP and the public IP. As soon as I did that, it started working :slight_smile:

OK, so now that i’ve got the incoming calls working. Can’t seem to get outbound calls working. Keep getting a busy tone. Below is a screenshot of the trunk settings. What could I be doing wrong now? :frowning_face:

You don’t need separate incoming and outgoing settings, in this case.

type=friend makes no sense as they are not identifying themselves as “Gradwell-in”, or by any other name.

insecure=invite makes no sense as you don’t have a secret set, so you can’t try to authenticate them. I doubt insecure=port is needed.

There is no such keyword as “conext”.

Setting context=from-internal is an invitation for toll fraud, although it is not well defined whether incoming calls will use the outgoing or incoming definition.

Having different sets of codecs for incoming and outgoing doesn’t make sense.

Specifying only ulaw doesn’t make sense for a UK based service provider, as the UK uses A-law in its PSTN.

Having different contexts for incoming and outgoing sections doesn’t make sense.

You should not be using chan_sip for any new system except in exceptional cases, which don’t apply here.

Also issue the Asterisk CLI command “sip set debug on”.

Please provide logs as text, from the log file, via Paste the last part of the URL, if the forum doesn’t allow you to post full URL.

Thank you. I’ve removed the second incoming setting as i was just copying and pasting things i come across online lol. So now it looks like this:

I will try out the debugging and report back. Never attempted it before

@david55 surprisingly as soon as I made the changes to the settings in the trunk as pictured above based on your feedback, the outgoing call has started to work. So I assuming the insecure setting could have been the only thing that was causing outbound to give busy tone?

Actually, if your other thread ( Lots of unrecognised calls showing in User Panel / Call Monitor ) is correct, incoming shouldn’t work. If they are correct, you should not be able to make chan_sip work for incoming without using guest mode. The fact that it does work suggests that there is only really one valid address for the firewall.

My answer on the other thread assumed you were using the, supported, chan_pjsip driver, which does allow for large numbers of addresses to be matched by IP,

Lol now I am confused lol. The other thread I opened the firewall ports pointing the external IP to the required ports but I limited it to only allow gradwells IP ranges. I also turned off allowguest. I tried each one by itself and both ways prevents the junk attempts in the logs.

So then I created the first pictured sip trunk. When I call my did number, gradwell forwads that call to [email protected]_public_ip I then created a inbound route for that DID to go to a IVR. initially it wasn’t working until I went to the asterisk settings and turned IP to static and specified my local IP network and the public IP address which matches the one approved by gradwell. As soon as I did that, the incoming calls started working.

Now problem was with outbound calls giving busy tone. Then looking at your feedback about certain settings not making sense on first picture, I revised the sip trunk settings to the second picture, and as soon as I did that the outbound calls started working.

So it’s all working now, is something still wrong? Gradwell will be assigning multiple DID numbers to the same trunk

If incoming calls are working for you, they can’t be using any more than and as source addresses, and I’m not sure that chan_sip will actually match both of those. That’s just not consistent with the claim that they could use a wide range of addresses, and that you should not filter by address.

Ok let me see if I’m understanding this correctly. Please pardon my lack of knowledge. I’m a dummy user lol

So by keeping allowguest on, any IP forwarding a call as long as my firewall allows it then the freepbx will take that call and try to deal with it. But I would assume you still need to create trunk to route it. But with this setup it wasn’t working anyway. So then I turned off allowguest and in the firewall only allowed all gradwell IP address ranges. And created the sip trunk. The main thing that made incoming work was me setting the static IP.

So the question is, when gradwell sends a call to [email protected] how comes freepbx isn’t seeing it as a guest and denying it but it’s actually seeing it as an approved trunk. I assume it has something to do with the trunk pictured above. Because without that trunk the incoming calls don’t come.

Because the source IP address matches (the first) IP address returned by DNS lookup on the host= setting for a peer in the right context.

If you had a type=friend section it could also match based on the from user name but Gradwell, like most ITSPs, is using that for the caller ID, or on the authentication user name, but ITSP never, in practice, provide authentication, and in any case, authentication isn’t sent on the first INVITE, but only when challenged. With type=user, the IP address is not used.

chan_pjsip, which you should be using, has a type=identify section, which can list many addresses, and those addresses can be whole networks, not just single, 32 bit, addresses.

So I need to enable chan_pjsip? So currently it could just be working by chance and could stop? chan_pjsip will be the correct way? How do I go about enabling that? Never heard of it lol

Just thinking… if currently I am only allowing the IP ranges that belong to gradwell to come through my firewall to the PBX server on those ports, then technically I could just leave AllowGuest setting ON because with that setting left to ON and my firewall restricted, none of those junk calls turn up on my PBX. So i’m just thinking if what you are saying about the IP addresses and by luck if it’s working now then it may not work at some point because it’s forwarded from a different IP. then is it not easier to just leave AllowGuest on and restrict at firewall level.

That way if it passes the firewall level then it makes it to the PBX because of the allowGuest.

Let me see if in understanding this correctly. Currently with firewall only allowing gradwell IP addresses and allowguest turned off on freepbx. The only reason the gradwell incoming call is getting through is because in my gradwell sip trunk settings as pictured originally few posts above, the hostname is set to “” and when freepbx is receiving this sip call it’s identifying the connecting IP to resolve to the same Ip configured in the host and hence letting it through? So if gradwell were to use different ip addresses to forward that call, if it didn’t match the connecting hostname IP then it won’t let it through? Is that correct?

So keeping inbound traffic restricted to only gradwell IP addresses at firewall level and turning in allowguest might be the safer option as I dont want it to be working now and then randomly stop if gradwell were to forward the call from different ip

This is becoming even bigger mystery how it’s even working. So I have two firewall rules. One for the outbound ports and one for the inbound port forwarding to the PBX local IP address. Even if i disable the inbound port completely, the external gradwell calls still seem to come through. It’s only by disabling outbound on those ports that it stops coming through. So this has got me thinking regarding my other thread, whitelisting their IP addresses for internal traffic doesn’t seem to be making any difference anyway. It is blocking all the other unwanted sip attempts though.

The question is, how is this even working? How are the calls able to make it through? The one thing that makes a difference and makes incoming and outgoing calls completely stop is if i change Asterisk Sip Settings IP address from Static to Public. It only works on Static with the external IP defined. So this has something to do with it too.

I think we need the logs with the protocol logging enabled, to understand what is happening.

Which log files should I be sharing? there’s fail1ban, full, queue and debug but debug seems to be empty.

It definately isn’t using the inbound firewall rule because if I disable the outbound firewall rule allowing outbound traffic then the calls stop coming through. The inbound one isn’t making any difference to it. It’s making me wonder, could it be registering with gradwell sip and somehow able to know how to receive the call?

I remember having a sipgate account on here a while back and that didn’t need any inbound ports, it just needed outbound 5060 tcp and udp and it would just work. So this is reminding of that

Just had a look at the SIP peers section where all my voip phones are showing registered. At the bottom on the page I see Gradwell with these details:

Forcerport: YES
Comedia: YES
Port: 5060

So it seems like gradwell is registering.

Full log, with “sip set debug on” issued to the CLI.

Gradwell doesn’t use registration.

I just locked myself out of remote access accidently on the firewall :blush: and i’m back to work in a week lol. Going to have to report back with the logs when i return lol.

In theory, if i left AllowGuest ON and inbound firewall rule is only allowing the Gradwell IP’s for the following ports:

5060 TCP
5060-5061 UDP
10000-20000 (UDP)

When i tested this, none of the junk requests were making it to the PBX on the User Panel logs so essentially the firewall is doing what the AllowGuests off was doing. So that’s why i’m thinking leaving it on may just be the safer option to make sure the gradwell routing always works.

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