Topic: Adding multiple trunks for single DID in SAIL

[billym]

I have a configuration issue that I need assistance with. I have many did's associated with voicepulse service that provides a primary/backup sip trunk and a IAX2 trunk for each DID. How do I create a trunk(s) that will allow me to enter multiple registration strings or allow me to add multiple trunk entries for each DID?

Would it be possible to have a DID Pool Manager that can be associated with multiple trunks (like the agent/queue configuration). This way if managing many DID's with minimal trunks, there would be a way to implement primary and failover configurations?

[soprom]

Wouldn't it be better to create a trunk for each one of them ?

[SARK devs]

I have to agree with Sophie.

In any event, I don't believe you can have multiple registrations for the same trunk, although you could argue that you can because a trunk doesn't actually exist, except as a table entry in Trunks panel.

[billym]

Many providers offer a primary and secondary/backup registration server and I have routes manually configured to attempt to use the primary and if it fails to use secondary trunk providing a better QOS.

This is the model as I understand it for voicepulse as well as many others if I am correct:

There accounts are structured where you get a total of 4 ports with each trunk you purchase and then can purchase additional ports to allow for more incoming/outgoing calls on that account.

(incoming/outgoing calls)      (authenticated delivery method)      (phone system)    (ph numbers)
   Assigned # of ports      ->             registered trunk            ->         pbx         ->     did


Currently the system requires us to add a trunk for every did. In the case where you have a large number of did's for an office (20-30), having 20-30 registered trunks does not make any sense when in many cases the maximum you really need is a primary and a backup for each account.

the DID manager would allow you to put in each DID, assign an incoming route for that DID, and assign the DID to a group minimizing the number of trunk registrations required.

This would allow for the flexability of:
DID GROUP A = 20 DID's
DID GROUP B = 1 DID's
DID GROUP C = 4 DID's

1 PRIMARY TRUNK -> DID GROUP A
1 BACKUP TRUNK -> DID GROUP A

1 PRIMARY TRUNK -> DID GROUP B
1 BACKUP TRUNK -> DID GROUP B

1 PRIMARY TRUNK -> DID GROUP C
1 BACKUP TRUNK -> DID GROUP C


HERE IS AN EXAMPLE CONFIG FOR PRIMARY/BACKUP
-----------------------------------------------------------------------
sip.conf
-----------------------------------------------------------------------
register => username:password@jfk-primary.voicepulse.com
register => username:password@jfk-backup.voicepulse.com

[voicepulse-primary]
type=peer
context=voicepulse-in
host=jfk-primary.voicepulse.com
username=XXXXXXX
secret=XXXXXXX
qualify=yes
allow=all
canreinvite=no
dtmfmode=rfc2833
rfc2833compensate=yes
insecure=port,invite
trustrpid=yes

[voicepulse-backup]
type=peer
context=voicepulse-in
host=jfk-backup.voicepulse.com
username=XXXXXXXX
secret=XXXXXXXX
qualify=yes
allow=all
canreinvite=no
dtmfmode=rfc2833
rfc2833compensate=yes
insecure=port,invite
trustrpid=yes

[sipuser]
type=friend
host=dynamic
secret=sippassword
context=outgoing
canreinvite=no
allow=all

---------------------------------------------------------------
extensions.conf
---------------------------------------------------------------
VOICEPULSE_GATEWAY_OUT_A=voicepulse-primary
VOICEPULSE_GATEWAY_OUT_B=voicepulse-backup

exten => _1NXXNXXXXXX,n,Dial(SIP/+${EXTEN}@${VOICEPULSE_GATEWAY_OUT_A})
exten => _1NXXNXXXXXX,n,GotoIf($[${DIALSTATUS}=CHANUNAVAIL]?${EXTEN}|GatewayB)
exten => _1NXXNXXXXXX,n(GatewayB),Dial(SIP/+${EXTEN}@${VOICEPULSE_GATEWAY_OUT_B})

[SARK devs]

OK - I think I understand.

First of all, I don't think you need one trunk per DiD.   One trunk per account should be enough.  Your registration (particularly the way in which you have coded it) simply tells the Proxy where you are in cyberspace.   Once the proxy (carrier) knows where the account is it will send all DiDs for that account to the same IP address, so there is no need for multiple registrations on the same account.

So now you can create your DiDs using the PTT-DiD-Group trunk type (which create no SIP entries at all).

For outbound you can route through the available accounts you've created with the carrier...

Path1 -> account1
Path2 -> account2
..
..
etc. etc.

Inbound will just happen because Asterisk dosn't actually care where the DNID (DiD)  came from (primary or secondary account - does't matter) as long as there is a corresponding entry in extensions.conf.  Outbound will progressively choose carrier accounts based upon availability at the time of the dial.  This just leaves the issue of outbiund caller-id, which can  be resolved at the extension or trunk level (depending upon the level of granularity you wish to achieve).

Hope this helps

S

   

[billym]

So when I create a trunk in sail/sark how would I (using the gui) designate the assignment of an incoming did route for example (111-222-3333) directly to an extension, another did (222-333-4444) to hylafax, and the did (888-111-2222) and (444-555-6666) to go to an IVR without adding more than one trunk for this provider?

[SARK devs]

You add the trunk for the base DiD, or for the account number (doesn't really matter which) and then you simply create a PTT-DiD-Group entry for each DiD you expect to receive from the circuit, or carrier.  Here's a real example from a UK company...

Code: [Select]

     
270941 MainBTDDI's NO default PTT_DiD_Group LOCAL N/A N/A DiD None 941  941  
270942 MainBTDDI's NO default PTT_DiD_Group LOCAL N/A N/A DiD None 942  942  
270943 MainBTDDI's NO default PTT_DiD_Group LOCAL N/A N/A DiD None 943  943  
270944 MainBTDDI's NO default PTT_DiD_Group LOCAL N/A N/A DiD None 944  944  
270945 MainBTDDI's NO default PTT_DiD_Group LOCAL N/A N/A DiD None 945  945    
ZapGroup2 ZapGroup2 NO default ZapGroup   N/A   Zap None Operator Operator  

In the example, the 6-digit DiDs are coming in off of a PSTN PRI but the principle is the same.  Each DiD is routed to a different extension (in the example, they are based upon the last three digits of the DiD - 941, 942, 943 etc etc). Once the trunk creates the relationship, the DiDs only need to appear in extensions.conf in order to be processed.  Each Did can have its own destination(s) for open and closed, just like a normal trunk.  Indeed if the last n digits of the DiD match the extension number, SARK will even do the linking for you if you turn on smartlink when you create the DiD group.

Kind Regards

S