Multiple DIDs on a SIP Trunk

Asterisk Asterisk Support
1

We have got a SIP trunk from over SIP provider and we are using 5 DIDs. I want each DID to route to a different extension but i don’t know how to do it.

Our SIP provider told us that are routing the call on user id basis and i should change the dialplan and context to route calls to different extensions. I did all the steps but whenever an incoming call comes in it is routed to only one extension all the time or to none of the extensions.

This is what our SIP provider is sending us in header.

Via: SIP/2.0/UDP 101.50.64.12:5060;branch=z9hG4bK1636b2ec;rport
From: “0919693544” sip:0512293544@11.20.64.79;tag=as39de4115
To: sip:s@172.21.9.9:5060
Contact: sip:0919693544@11.20.64.79
Call-ID: 4c4817eb47c786bb70af1e1f6dfcea30@11.20.64.79
CSeq: 102 INVITE
User-Agent: Asterisk
Max-Forwards: 70
Date: Wed, 20 Feb 2013 10:32:10 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Content-Type: application/sdp
Content-Length: 213

I have been working on this issue for more than two weeks i have searched so many communities but without any luck. Any help will be greatly appreciated.

Thanks.
Imran

2

You want one DID trunk, not multiple simple trunks. DID is misused in the Asterisk world. Real direct in dialing means that you get part or all of the dialled number forwarded to you.

If you can’t get them to provide that, try using a callback extension on your register line, to try and recreate the original dialled number.

The ITSP clearly doesn’t understand Asterisk, and, in particular, that it can only use the source IP address and port for discriminating between trunks - actually that is a characteristic of SIP, itself.

3

Dear David,

Thanks for you reply.
I am using only one SIP trunk and for this trunk we acquired 5 DIDs.

And i am not able to differentiate that the incoming call was for which DID.

Can you kindly explain or give an example when you said this " try using a callback extension on your register line".

Thanks.
Imran

4

I no longer understand what you mean by DID and SIP trunk. Most people misuse DID to mean a number in the direct in dialing range at the ITSP, which is fowarded on a dedicated trunk to the customer, often on the assumption that they are not running a PABX.

If you really have only one trunk and it is not a proper direct in dialling one, with different extensions for each of your PSTN numbers, there is probably not enough information for anything to distinguish between the PSTN numbers.

Assuming for the moment, you have the more common problem where there are multiple accounts with the same remote IP and port, but on which the dialled number is not being forwarded, the parameters of register are explained in the sample configuration file, and as this is a common problem examples can be found by searching the archives.

5

Dear David,

Sorry for not making myself clear enough. By 5 DIDs i mean 5 different numbers that a caller dials for incoming calls these numbers are 9898980, 9898981,9898982, 9898983, 9898984

So what i want is when a call comes on 9898980 should be routed to extension 100, 9898981 to 101, 9898982 to 102, 9898983 to 103 and 9898984 to 104.

Thanks.
Imran

6

exten => 9898981,1,Goto(100,1)

etc.

7

Dear David,

Now the system doesn’t know how to go to 9898981 as in the header i only receive “s” from the provider and if i explicitly set 9898981 then even if the other 4 numbers are dialed i still get the call came to 9898981. :cry:

Thanks

8

Find a better provider.

At the very least, you are going to need to provide the contents of the incoming INVITE messages for each of these PSTN numbers, so that we can see if there is any information at all that would allow Asterisk to distinguish between them (sip set debug on). Please make sure you have the INVITEs and please remove other requests, and post the result in-line in the forum, not on a binaries site.

9

Dear David,

This is what i am getting after sip set debug on:

<— SIP read from UDP:11.20.64.79:5060 —>
INVITE sip:s@172.21.9.9:5060 SIP/2.0
Via: SIP/2.0/UDP 11.20.64.79:5060;branch=z9hG4bK60fc3f58;rport
From: “0919693544” sip:0919693544@11.20.64.79;tag=as6f4d4c29
To: sip:s@172.21.9.9:5060
Contact: sip:0919693544@11.20.64.79
Call-ID: 05fa074473430f8a1896c847246e7a33@11.20.64.79
CSeq: 102 INVITE
User-Agent: Asterisk
Max-Forwards: 70
Date: Thu, 21 Feb 2013 04:55:53 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Content-Type: application/sdp
Content-Length: 213

v=0
o=root 27242 27242 IN IP4 11.20.64.79
s=session
c=IN IP4 11.20.64.79
t=0 0
m=audio 12718 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
<------------->
— (14 headers 11 lines) —
Sending to 11.20.64.79:5060 (NAT)
Using INVITE request as basis request - 05fa074473430f8a1896c847246e7a33@11.20.64.79
Found peer ‘Nayatel’ for ‘0919693544’ from 11.20.64.79:5060
== Using SIP RTP CoS mark 5
Found RTP audio format 8
Found RTP audio format 101
Found audio description format PCMA for ID 8
Found audio description format telephone-event for ID 101
Capabilities: us - 0x80000008000e (gsm|ulaw|alaw|h263|testlaw), peer - audio=0x8 (alaw)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x8 (alaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
Peer audio RTP is at port 11.20.64.79:12718
Looking for s in incoming (domain 172.21.9.9)
list_route: hop: sip:0919693544@11.20.64.79

<— Transmitting (NAT) to 11.20.64.79:5060 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 11.20.64.79:5060;branch=z9hG4bK60fc3f58;received=11.20.64.79;rport=5060
From: “0919693544” sip:0919693544@11.20.64.79;tag=as6f4d4c29
To: sip:s@172.21.9.9:5060
Call-ID: 05fa074473430f8a1896c847246e7a33@11.20.64.79
CSeq: 102 INVITE
Server: Asterisk PBX 1.8.18.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: sip:s@172.21.9.9:5060
Content-Length: 0

<— Reliably Transmitting (NAT) to 11.20.64.79:5060 —>
SIP/2.0 603 Declined
Via: SIP/2.0/UDP 11.20.64.79:5060;branch=z9hG4bK60fc3f58;received=11.20.64.79;rport=5060
From: “0919693544” sip:0919693544@11.20.64.79;tag=as6f4d4c29
To: sip:s@172.21.9.9:5060;tag=as10c217bb
Call-ID: 05fa074473430f8a1896c847246e7a33@11.20.64.79
CSeq: 102 INVITE
Server: Asterisk PBX 1.8.18.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0

<------------>

<— SIP read from UDP:11.20.64.79:5060 —>
ACK sip:s@172.21.9.9:5060 SIP/2.0
Via: SIP/2.0/UDP 11.20.64.79:5060;branch=z9hG4bK60fc3f58;rport
From: “0919693544” sip:0919693544@11.20.64.79;tag=as6f4d4c29
To: sip:s@172.21.9.9:5060;tag=as10c217bb
Contact: sip:0919693544@11.20.64.79
Call-ID: 05fa074473430f8a1896c847246e7a33@11.20.64.79
CSeq: 102 ACK
User-Agent: Asterisk
Max-Forwards: 70
Content-Length: 0

<------------->
— (10 headers 0 lines) —

<— SIP read from UDP:109.189.164.12:60720 —>

<------------->

10

They are using an obsolete version of Asterisk. Currently supported versions and versions supported within the last few years, include the version in the user agent string.

There is no information in their header which would allow you to identify the original alled number (assuming that the From address is the true from address.

It does sound as though they are sending you single trunk with no called number information, given you say that setting the callback extension affects all of the PSTN numbers.

If there is anything I have missed in the headers that would allow one to distinguish between called numbers, point it out.

All they have to do is to replace SIP/your-account with SIP/your-account/${EXTEN} (possibly using a variable into which they have captured the original extension, but if they don’t send the information, you can’t act on it.

11

Your problem is that your provider is sending you INVITE messages addressing SIP:s@your-ip-address. If the caller dials 123456, your provider should pass the call to you by sending their INVITE message to SIP:123456@your-ip-address.

If they can do that, the 123456 part of that string becomes the extension that is matched against the exten = 123456,1,… line in your extensions.conf file. You then place a line like that for each of the expected extensions. Right now, they’re only using extension s for all inbound calls, so you cannot route based on the dialed number. This is not DID!