The symptom: On a SIP trunk, you can’t get an inbound route to work – it just doesn’t seem to recognize the number. You might be able to get the call to come in on your any DID/any CID route, or maybe the call doesn’t get answered at all. When you type sip debug from the CLI, you can see (when you scroll back to the point where the call came in) that a sip INVITE packet arrived, and perhaps it contained the DID number in the sip To: header (in the form To: <sip:NUMBER@IP ADDRESS>), but you also see that the FROM_DID was set to s. In other words, you see a line that looks like this:

  -- Executing Set("SIP/9995552368-09876543", "FROM_DID=s") in new stack

EDIT: The most common reasons this happens are one or both of two things. Either you are not specifying the number of your DID in the format your provider is sending it (for example, they are sending 11 digits including a leading “1”, but you are only using ten digits in your inbound route), or they are sending the number in the SIP “To:” header. In the latter case, FreePBX has a much easier way to deal with this now. Before you do anything else, try changing the trunk context from from-trunk or from-pstn to from-pstn-toheader. This works for both SIP and PJSIP trunks, but only if the provider really is sending the number in the SIP “To:” header.

Only continue with this article if you have tried the above and it doesn’t work, as much of what is below simply shows an older and less intuitive way of doing the same thing. If the above did not work, don’t forget to change your trunk context back to whatever it was previously. (End of edit.)

Before you attempt anything else, you may want to try this suggestion by Dan Swartz: Check the registration string (in the trunk settings for the provider), and if it’s not already there, try putting the DID at the end of the registration string, prefixed by a ‘/’. It may (or may not) require a leading ‘1’ too. e.g. ‘/18005551212’ (or your country code if you are not in the U.S./Canada, etc.). So, your registration string would take this format:

accountid:password@your.provider/yourDIDnumber

Remember to try your DID both with and without the country code prefix. If this doesn’t work, it’s time to try a workaround (however, you may want to read the addendum at the bottom of this article first!). Perhaps you can see the DID number in the sip INVITE packet’s To: header, but the CLI reveals that Asterisk isn’t picking it up, and therefore it goes to your default inbound route.

(Oh, and for anyone who’s still trying to figure out how to turn off sip debugging, the CLI command is sip no debug)

Fortunately this isn’t a hard thing to work around, as long as the DID number really is in the sip To: header.

NOTE: In the following examples, we now use the s extension rather than _. – this is considered better practice (and safer) but the disadvantage is that the context will fail if the provider is sending any type of DID, even if it’s incorrect or incomplete. If the code doesn’t seem to work, try replacing the s extension with _X! (the extension is to the right of the => and space characters).

First, create a context in extensions_custom.conf that looks like this:

EDIT: Really, don’t do this next part, unless you are running an old version of FreePBX! Just change your trunk context to from-pstn-toheader and be done with it! (End of edit.)

[custom-get-did-from-sip]
exten => s,1,Noop(Fixing DID using information from SIP TO header)
exten => s,n,Set(pseudodid=${SIP_HEADER(To)})
exten => s,n,Set(pseudodid=${CUT(pseudodid,@,1)})
exten => s,n,Set(pseudodid=${CUT(pseudodid,:,2)})
exten => s,n,Goto(from-trunk,${pseudodid},1)

Or, thanks to naftali5, you can cut the above down to one line of code that does the same thing, but is a bit less obvious to the casual reader:

[custom-get-did-from-sip]
exten => s,1,Goto(from-trunk,${CUT(CUT(SIP_HEADER(To),@,1),:,2)},1)

(And speaking of naftali5, if you are using his Dialplan Injection module – which may not work with the most recent versions of FreePBX, so don’t run out and get it if you aren’t already using it unless you are sure it has been updated to work with the version of FreePBX that you are using – and want to put the above line in the Destination section, then you will need to use a slightly different syntax, changing the commas to bar characters, so it looks like this:

* Custom App: from-trunk,${CUT(CUT(SIP_HEADER(To)|@|1)|:|2)},1

The part after Custom App: is what you paste into the text box. This ONLY applies to Dialplan Injection users)

Then, in the trunk associated with the provider, change the trunk context statement (which should read context=from-trunk) to:

context=custom-get-did-from-sip

(Or for Dialplan Injection users, just use

context=injection-n

but replace n with the actual injection number, which will appear next to the injection name in the right-hand column menu of injections.)

And note that with such providers, you may have to move that context statement from the USER details to the PEER details section. This is why calls from some SIP providers sometimes fail to come in at all – they effectively never "see" the User context and details, therefore they don’t see the context statement there and have nowhere to go. It’s also why you sometimes see instructions for sip providers that leave the User context and User details sections totally blank, but include a context statement in the peer details – in most such cases it’s because the provider is treating the customer as an end user (like someone using a softphone or a VoiP adapter) rather than as a peer, and they aren’t sending DID information.

The above instructions may also solve the problem where you have two (or more) trunks from the same provider, but Asterisk always treats it as if all calls are coming in on one of the two trunks, therefore again not allowing you to set up separate inbound routes for each trunk. As long as the provider sends the number in the sip To header, the above code should set the DID properly.

If the first part of the To: statement is something other than a DID number (a user name, for example), then you may have to add a line just before the final Goto statement. For example, let’s say the provider is sending To: <sip:Fred@IP ADDRESS> and your DID number (or at least, the number you want to use to denote your inbound route) is really 5551212. You’d then use code similar to this:

[custom-get-did-from-sip]
exten => s,1,Noop(Fixing DID using information from SIP TO header)
exten => s,n,Set(pseudodid=${CUT(CUT(SIP_HEADER(To),@,1),:,2)})
exten => s,n,Set(pseudodid=${IF($["${pseudodid}"="Fred"]?5551212:${pseudodid})})
exten => s,n,Goto(from-trunk,${pseudodid},1)

Or, as long as you only have ONE trunk from that provider, you could always just cheat a little and hardcode the desired DID in a separate custom context, like this:

[custom-stupid-provider]
exten => s,1,Noop(Fixing DID to 5551212)
exten => s,n,Goto(from-trunk,5551212,1)

And use the name of this context in the trunk settings. I hear you asking, why not just do it this way on all trunks with this issue? Well, because if you add a second trunk from the same provider, this won’t work correctly for both trunks, and if you ever change your number and then forget what you’ve done and just try to set your inbound route to the new number, it won’t work. And besides all that, if you have more than one SIP provider that doesn’t send proper DID, you’d have to create a separate custom context for each of them, instead of having one custom context that works for all of them.

One final note for Free World Dialup users, you may find that sip calls will still not come in until you put the following statement in sip.conf:

insecure=invite

I have no idea why that works, but it seems to make a difference.

What if the provider doesn’t send the number in the sip To: header?

There is at least one provider that actually sends a s character instead of a number in the sip To: header. What can you do with a provider like that? Well, all may not be lost. If you only have a single trunk from that provider, you can just use the "cheat" shown above, since it doesn’t rely on the contents of the sip headers. If, however, you have TWO or more trunks from the same provider, you can do a sip debug from the CLI and watch as calls come in on each trunk and note whether there are any consistent differences.

For example, if you have two lines on the same account, the provider will often assume that you are using a VoIP adapter (such as a Sipura or Linksys) and will use port 5060 for line 1, and port 5061 for line 2. That difference might show up in the headers of the sip INVITE packet, for example:

Via: SIP/2.0/UDP 111.222.333.444:5060;branch=z9hQ4bK67sc0a8e;rport

In this case, you see that there is a colon (:) before the port number and a semicolon following, and that there are actually TWO colons on the line before the port number, so maybe this would work:

[custom-really-stupid-provider]
exten => s,1,Noop(Fixing DID using port from SIP VIA header)
exten => s,n,Set(pseudodid=${CUT(CUT(SIP_HEADER(Via),;,1),:,3)})
exten => s,n,Set(pseudodid=${IF($["${pseudodid}"="5060"]?5551111:${pseudodid})})
exten => s,n,Set(pseudodid=${IF($["${pseudodid}"="5061"]?5552222:${pseudodid})})
exten => s,n,Goto(from-trunk,${pseudodid},1)

Or, if you only have two trunks from this provider, you probably could just condense the two test lines into one, by testing for one port number and assuming the other if the conditional test fails, like this:

exten => s,n,Set(pseudodid=${IF($["${pseudodid}"="5060"]?5551111:5552222)})

Note that the code in this section is untested, it’s just to give you some ideas about how to possibly handle the really oddball situation were you have two (or more) lines from the same provider, and cannot find any other way to differentiate them. And, don’t automatically assume you have a bigger problem than you actually have – for example, it may well be that having different port numbers on the different trunks would allow Asterisk to distinguish them enough that the simple "cheat" method would work (you’d have to make one for each trunk, of course).

Again, if a particular piece of code doesn’t seem to work at all, try replacing
exten => s, . . . . .
with
exten => _X!, . . . . .
in all lines of the context (just in case the provider is sending some unknown number). But if that works, you should consider using whatever the provider is actually sending as the DID for your Inbound Route, which would eliminate the need for this extra code altogether.

Addendum

There are a few other reasons that incoming calls may fail that have nothing to do with the main topic of this How-To, but are common enough that they should be mentioned anyway. The first is that in every trunk configuration, there must be a statement that reads:
context=from-trunk
Some providers will tell you to set the context statement to something else – don’t do it (unless you have a valid reason, such as following the instructions above). Providers are generally more familiar with Asterisk than FreePBX, and often don’t realize that you can’t just use any context name you like in FreePBX unless you also create that context somewhere (usually extensions_custom.conf).

Also the placement of that context= statement can be important. If a provider is treating you as an extension (which would likely be the case if most of their customers use VoIP adapters and/or you are a “Bring Your Own Device” customer) then in most cases you will not need to have a USER context or USER details at all in your trunk, but you still need to have a context=from-trunk statement (or another context= statement if you are following instructions elsewhere on this page) and in this case it will need to be in your PEER details, not your user details. So, if incoming calls aren’t working, try putting context=from-trunk in your trunk PEER details, and if that works, then totally remove the USER context and USER settings from your trunk configuration, since they aren’t doing any good anyway.

To further complicate matters, I have noted that with a couple of providers, nothing seems to work until you do the following. The symptom typically is that you have no problem connecting with other providers, and (if you have tried this) you have no problem connecting with the provider in question if you are using an external hardware device (such as an ATA), but no matter what you do you can’t receive calls from the provider. I hate recommending this because I don’t know exactly why it works, but it’s a trick I’ve used for a couple years now to resolve issues with a couple of specific providers. Don’t try this until you’ve first tried adding the DID at the end of the registration string, prefixed by a ‘/’, as shown near the top of this page.

Open the file /etc/asterisk/sip_general_custom.conf in any text editor and check to see if the following lines are in there:

bindport = 5060 ; Port to bind to (SIP is 5060)
bindaddr = 0.0.0.0 ; Address to bind to (all addresses on machine)
insecure=invite
tos=0x68
srvlookup=no

If any of the above lines are missing, add them to the file. In my experience these lines will not cause problems with other providers but they do magically get things working with a select few providers that are more used to serving customers using an ATA than through a trunk into an Asterisk box. If this gets things working you can try removing lines one at a time to find out which are actually doing the trick, or you can just leave them all in place – as I say, in my experience they don’t seem to cause problems with other providers, although obviously your experience might be different.

Yet another issue that you may encounter, especially if you are upgrading from an earlier version of FreePBX, is that if you have disallow= and allow= statements in your trunk configuration (to specify the use of particular codecs), starting with Asterisk 1.4 the disallow= statement(s) (particularly if it’s disallow=all) must be placed above the allow= statements. This is one of many cases where Asterisk upgrades have broken existing functionality for no good reason whatsoever, other than that the Asterisk developers could not be bothered to ensure backward compatibility.

One other note: There is an obscure bug in Asterisk that can cause incoming calls to fail. If Asterisk ever receives a Caller ID NAME that contains only one quotation mark (usually a name with a quotation mark at the start of the string but not at the end) it will not handle the call properly, and may ignore the incoming call completely.

Additional Reference:

Asterisk SIP channels