Inbound and Outbound SIP trunk help

I need some help setting up our new sip trunks that we got from company called Gradwell. They say that they authorise calls based on the originating IP address and to add outbound calls to go through my trunk with them I need to add the following in “extensions.conf”

exten => _0.,1,SetCallerID(YOUR_NUMBER)
exten => _0.,2,Dial(SIP/[email protected])

Then for incoming calls they say to add the following line:

exten => [your_phone_number},1,Dial(SIP/201)

The problem is i’m not quite sure I understand that because currently I have a SIP trunk set under the SIP trunks section in freepbx. After that I then go to the Inbound Routes section and configure anything that matchs a DID incoming and send it to certain destination. So this method i’m not sure how it’s working and how do I route different DID’s to different destinations (e.g. time group)

The other problem is I don’t understand the outbound setting. Because right now I have outbound routes set up and I create a pattern that I send through a trunk. But with the above method, I don’t see how am i supposed to link outbound routes matching dial patterns to go through a trunk?

Any help would be much appreciated.

Thanks

You haven’t marked up your dialplan as pre-formatted text (forum </> button). Please edit it.

“your phone number” is the DID, and that is all you need to know. Their example, which, incidentally uses a deprecated channel driver, is for a very simple, raw Asterisk configuration, which associates the DID with a single local phone.

I’m guessing that:

exten => _0.,2,Dial(SIP/[email protected])

should have been

exten => _0.,2,Dial(SIP/${EXTEN:1}@sip.trunk.prod.gradwell.com)

which is slightly strange for a UK company, as, traditionally “level” 9 has been used for outgoing calls. Maybe they are assuming you always dial the full number, complete with 0 or 00 prefixes, in which case you meant to write:

exten => _0.,2,Dial(SIP/${EXTEN}@sip.trunk.prod.gradwell.com)

In any case it just amounts to understanding how they expect numbers to be presented, and deciding how you will identify outbound numbers locally, and defining an outbound route and trunk which obey those rules.

As a raw Asterisk users, I find this strange. I’d expect to specify this with from user in the trunk configuration, which is basically what they are asking you do, although I notice that FreePBX users often do something closer to a l literal interpretation of this, using the caller ID manipulation features in FreePBX. That is probably a bad idea if they do allow you to set the caller ID (using P-Asserted-Identity or Remote-Party-ID headers.

Basically, you need to understand what they want to happen at the SIP level, and implement that in FreePBX terms, rather than trying to literally follow what they are saying. It seems to me that they don’t have a very good understanding of Asterisk, which I find a bit strange, since they have been around a long time and seem to attract the sort of person that hand crafts Asterisk systems.

Looking at Gradwell’s document, their example for the outbound DIal line is simply broken.

I assumed they were using caller ID as an account code, but they are actually using it as caller ID, with the IP address identifying the account. However they do require that you agree which caller IDs you can present (presumably to prevent spoofing). There is a lot of documentation on setting caller IDs in FreePBX, including this case of presenting a limited range of caller IDs. (If you only have one caller ID registered with them, from user is still an option.)

It looks like a very straightforward authenticate by IP configuration, with a reasonable constraint on presented caller IDs.

I am even more lost lol. The caller ID and IP address has already been agreed with them. I have a few inbound DID numbers associated to the trunk and i’ assuming I can use any of those DID’s. But i just cannot make sense of how to translate this into freePBX settings :frowning_face:

Using the right command might help. SETCALLERID(NXXNXXXXXX) aint gonna work. It is CALLERID(all) or set them on their own CALLERID(name) and CALLERID(num). SetCallerID isnt an existing Asterisk function.

Also, stop using chan_sip. It is unsupported.

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.

https://wiki.freepbx.org/display/SUP/Providing+Great+Debug

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

Please provide logs as text, from the log file, via pastebin.freepbx.org. 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 195.74.60.179 and 195.74.60.150 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 “sip.trunk.prod.gradwell.com” 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