Simple incoming trunk routing

FreePBX
1

Hi all

I am in UK and have quite a simple setup with 1 PSTN line and 1 SIPgate Basic account. I am using the latest version of FreePBX on asterisk 13.

I have set up CLI routing successfully so that incoming calls go to different ring groups depending on who is calling.

What I haven’t been able to get my head around is “hotlining” calls that arrive on my SIP trunk to a dedicated extension.

I understand I should do this based on DID, but as it is a SIPgate basic account, I don’t think I am getting any DID info coming in with the call.

It seems like it should be quite simple to route based simply on which trunk received the call, but unfortunately I’m not seeing how to at the moment.

Hoping someone can point me in the right direction.

Thanks

2

You meant CID routing, right?

When you set up an incoming route, you have “1 + 1 + both” choices for routing incoming calls based on DID and CID.

When you get a SIP call from Voip.MS, you should get both the DID (your number) and the CID (the number that called you). On DAHDI, you don’t get the DID directly (you have to manage it yourself).

So, in the GUI, if you set the DID information on the inbound route, anything that comes in for that DID will be routed to whatever destination you want (Queue, Ring-group, Extension, Voicemail, Announcement, etc.).

This is all good until you add in DAHDI. My experience with DAHDI is that you get Caller ID (if you wait for it) but not DID. With POTS services in the States, the Caller ID information is sent between the first and second ring. In the UK, your mileage may vary.

So, if your contention that you don’t get DID information from Voip.ms is true, you shouldn’t be getting any DID information. That doesn’t really sound right, but I’m willing to accept it.

The way I handled this lack of DID on incoming DAHDI trunks was to set up a custom context that simply set the DID information for the trunk. The trunk config uses the custom trunk context to set the DID for that trunk.

Once you do that, you should be able to route calls as you want.

The special “both” case is when you have a DID and a CID set. This particularly tight configuration isn’t really as useful as one might hope, but can be used if you absolutely need it.

3

Hi Dave

Thanks for your timely response and advice. I am sorted out now, as follows:

Yes, I did mean CID.

I was getting a DID with the voip call, but due to a typo in my registration string, it didn’t make sense, so didn’t work. For the benefit of anyone else requiring help with this, the registration string for my provider is username:password@voipproviderdomain/usernameagain and then the usernameagain is sent as DID with incoming calls (at least that is what I gleaned from a google search on the subject.

The problem is that my providers username is alpha-numeric, so cannot be entered into the DID field on the GUI.

Two ways around this. 1) Use a pattern match in the DID field e.g.: _123456. Or better yet 2) It seems whatever you put in the usernameagain part of the string is what is sent back to you as the DID, so just put the phone number in there and all works as expected.

4

Good that things are working, but you’ve got an imperfect solution. What happens when you order another DID from this provider?

5

Hi Jim,

I also use sipgate, here in the UK - and had the same problem as you - the solution is to change the registration string, under the inbound section of the trunk config slighty to -

username:password@voipproviderdomain/ddinumber

That way, you can have the ddi correct in your incoming rule.

:slight_smile:

6

I think this is probably specific to their “basic” account which is one channel one DID. I don’t know how it would change the registration string but I would hope that with more than one DID it would send that info along.

7

In your sip trunk there should be a registration string field. Change there the string as @dailand said and try again.

8

Their Basic account, is currently limited to one number - but i’m told that will be upgradeable shorlty.

As a test - I’ve signed up for a second sipgate account, and configured it as a seperate trunk - and made a second incoming route with the new DID details - and the call routes correctly.