How SARK UCS/MVP maps and switches your inbound calls.

Introduction

SARK/SAIL makes a potentially very large number of switching decisions every time it receives a call. In order to help users understand how the inbound trunk is defined and initialised, we offer this short essay. To begin, we will look at the logic flow through the inbound route processor in the HSLE.

Logic Flow

Here is the actual logic flow which SARK applies to each inbound call: -

1. If a prefix is specified in the trunk it is added to the CLID
2. If a CLID ( Caller ID) is present and the trunk has the SWOC ( Switch On CLID) checkbox set "ON" and a PTT_CLID trunk exists for this CLID and the PTT_CLID trunk is in the same cluster as the originating trunk, then switching will proceed according to the directions in the PTT_CLID Trunk. Otherwise, switching will proceed according to the directions in the originating Trunk.
3. If a TAG is present in the Trunk then it will be added to the SIP header
4. A ringback tone is put onto the calling line
5. If VOIP_RINGDELAY ( induced VoIP ring time in Globals) is none-zero and the originating call has arrived over SIP or IAX, then a delay of VOIP_RINGDELAY seconds is taken.
6. If FAXDETECT is set "ON" for this trunk then a delay of FAX_DETECT_DELAY seconds is taken while Asterisk sniffs for fax tones. If tones are detected then Asterisk restarts processing at the fax extension within the inbound context. The fax extension will route the call to the FAX Extension specified in globals and processing ends.
7. If Alert_Info is none zero, then it will be added to the SIP Header. "Alert-Info" is commonly used to request a distinctive ringtone at the phone.
8. If permanent call recording is set ON then begin recording
9. We are now ready to switch the call. We need to decide our state and then hand control to the correct onward processor.
10. State can be OPEN, CLOSED or AUTO. OPEN will load the OPEN Inbound Route destination. Closed will load the CLOSED Inbound Route destination. AUTO will check the time-of-day against the automation date segments and decide whether the system is OPEN or CLOSED. It will then process as above.
11. Load the destination value from the Open/Closed Route drop-down in the trunk (depending upon our state) and hand control to the correct onward processor. The destination can be any of...
    1. an extension
    2. a Voicemailbox
    3. a Queue
    4. an IVR
    5. an Alias or Alias Group
    6. a Custom Application
    7. a Hangup (in the case of a black-listed caller-id).
12. This is the end of initial inbound switching. However, switching may continue if, for example, an IVR or Alias has been called.

Defining a Trunk and how it maps to iax.conf and sip.conf.

SARK/SAIL Trunks panel maps your data input to iax.conf or sip.conf. Perhaps the best way to demonstrate what actually happens is to follow a worked example (thanks to soprom in Montreal for the inspiration for this exercise).

Creating a Trunk

SARK/SAIL is designed to require the minimum amount of input in order to define a basic trunk object. Here is an example of a SIP trunk being created (an IAX trunk would look pretty much the same).

SARK takes this minimal input and, using the carrier template which it already has, generates the necessary objects which asterisk needs to make and receive calls on this trunk. Looking at the edit panel for the trunk we see that SARK/SAIL has generated the following peer and user entries for the trunk.

The "peer stanza label" is highlighted at the top of the left hand window, in earlier releases you needed to enter this yourself but from -638 onwards, SARK/SAIL generates this for you. The value we entered in the "DiD Number" is highlighted above the right hand window. These are the same values which SARK/SAIL will use as the peer and user header entries when it generates iax.conf or sip.conf...

[unlimitel_out_1]
type=peer
host=iax01.unlimitel.ca
qualify=3000
canreinvite=no
username=username_sophie
fromuser=username_sophie
secret=password_sophie
disallow=all
allow=alaw
allow=ulaw

[5140000000]
type=user
context=mainmenu

Unlike many other generator/workbench products, SARK/SAIL also decides the context which will process your call. You must not change this if you want SARK to correctly process your inbound calls!. Finally, we show the entry in extensions.conf which SARK/SAIL generates to process this call...

[mainmenu] 
      include => extensions


      exten => ....
      exten => 5140000000,1,agi(selintra,Inbound,${EXTEN})
      exten => ....

If we have specified our input data correctly, then here is what happens when a call arrives...

Asterisk receives a call from the carrier. As part of the initial handshake, Asterisk is given the DNID (The Dialed Number ID), or DiD. Asterisk will look for the DiD in the mainmenu context and, if it finds it, begin processing from that entry. For SARK/SAIL, this will cause the C Code AGI to be invoked and given the data "Inbound" and the DNID (${EXTEN}) (see the example above). This instructs the AGI to switch this called number using the Inbound route through the system.

Registration and what it does.

In order to understand carriers you need to understand a little about registration and whether it is necessary or not. Registration is not necessary with a carrier; IF, the carrier knows where you are and how to reach you. Carriers such as Telappliant and Gradwell in the UK do not require you to register, however they DO require you to tell them (in an interactive browser panel) WHERE to deliver inbound calls. For most carriers, registration tells the carrier where you are and (optionally) how to deliver an inbound call to you. The general format for a registration string is

user-id:password@carrierURI/deliverytag

User-id, password & carrierURI are self-explanatory. deliverytag instructs the carrier which number or sipaddress to deliver the call to. In theory, a registration string of

selintra:selpass@sip.mycarrier.com/01924918076

registers with the carrier and requests that inbound calls be delivered with an inbound number of 01924918076.

However, many carriers ignore the delivery tag and deliver either against the dialled number or (rather stupidly) against the User-id (often called the account number). This has obvious implications for the value you enter into the "DID Number or IP Name:" field when you create the trunk because the DiD you enter MUST match the DNID which the carrier delivers or the call will fail.