How to get the DID of a SIP trunk when the provider doesn't send it (and why some incoming SIP calls fail)

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 can get the call to go to 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 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:
So there the DID number is, 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. First, create a context in extensions_custom.conf that looks like this:
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:
(And speaking of naftali5, if you are using his Dialplan Injections module, 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:
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:
(Or for Dialplan Injection users, just use
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:
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:
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:
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:
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:
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:
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).

Additional Reference:

Asterisk SIP channels