SIP Sorcery dial plans are what control how calls are processed. A dial plan is required for outgoing calls to be processed, without it the SIP Sorcery server would not know how you wanted your calls to be forwarded. A dial plan is optional for incoming calls. If a SIP account does not have an incoming dial plan specified then the default behaviour is to forward the call to all registered bindings for that account.
The SIP Sorcery dial plans are written as Ruby scripts. The SIP Sorcery application server exposes a wide range of functions that can be called in dial plan scripts to place calls, send emails, send instant messages, retrieve and set values from a database and many more.
Usage:
Description:
The most important dial plan function. Initiates a call to one or more SIP end points and when the first call is answered will bridge it with the SIP user agent that initiated the application. The Dial command takes a dial string as a parameter and it controls the order, delay and other types of behaviours for the forwarded call requests. The syntax of the dial string is best demonstrated by an example:
If at any point one of the forwards answered all other forwards are cancelled and the dialplan execution terminates. The additional options that can be used on each call leg are:
Addtional examples of using the sys.Dial with various dial string options are shown below.
Usage:
Description:
This dial plan function is used to send a SIP response back to the caller. If the response is a informational or 1xx response the dial plan will continue execution after the function. If the response is a final response, which is a status code of 200 or greater, than the dial plan will terminate after the function. The statusCode parameter must be set to a valid SIP status code (see RFC 3261 Response Codes). The reason parameter for this function is optional and if it is ommitted or set to nil then the default reason for the SIP status code will be used. The customHeaders parameter is also optional and can contain a list of headers delimited by the pipe or '|' character which the server will attempt to append to the SIP response, certain critical headers cannot be overwritten and if they are in the list they will be ignored.
A special case is redirect or 3xx response. In that case the sys.Respond function will treat the first header item in the customHeaders list as a SIP URI and place it in the Contact header of the response. An example of using sys.Respond to send a redirect response is shown below.
Usage:
Description:
Logs a message that will be displayed on the console and email traces. This is an essential function to provide troubleshooting or general information about the state of a dial plan as it processes a call.
Usage:
Description:
Sends an HTTP GET request and returns the result to the dialplan.
Usage:
Description:
The dbType parameter in the following functions indicates the type of the external database and the options supported are: MSSQL, Postgresql and MySQL. The connection string should be the same as one that would be used with the .Net framework of which examples can be found here: MSSQL, Postgresql and MySQL.
The external databasse functions do NOT allow arbitrary queries to be executed. They operate the same manner as the SIPSorcery specific functions and rely on a table called dialplandata with the specific schema shown below.
Usage:
Description:
The SetFromHeader method is the most useful of the above methods as the SIP From header is what typically translates to caller ID on a SIP call. By customising the SIP From header the caller ID displayed on the callee's phone can be modified. However most SIP Providers use the SIP From header for authentication and modifying it, and in particular the fromUser parameter can cause the call to fail. When caller ID manipulation is required it's recommended to start by only modifying the fromName parameter and only if that doesn't have the desired effect look at modifying the fromUser parameter; the fromHost should only need to be set in rare circumstances.
Usage:
Description:
Sends an email the address specified in the to parameter.
Usage:
Description:
Usage:
Description:
sys.GetTimezone returns a string representation of the timezone that has been set in the owner's web settings.
sys.GetTimezoneOffsetMinutes returns the number of minutes offset from Coordinated Universal Time (UTC) the dial plan owner's timezone is.
Usage:
Description:
sys.GoogleContactLookup attempts a lookup with the Google Contacts API.
The oAuthToken MUST be acquired by using the Google Authorisation process to grant permission to the SIPSorcery-DialPlan application, this allows contact lookups on your behalf. The authorisation is initiated by logging into your SIPSorcery account and going to the Settings page. Click on the "Get Google OAuth Token" button and at the end of the process copy and paste the token into your SIPSorcery dialplan. This should only need to be done once. If you invalidate the token from within your Google account in which it will need to be re-done.
The lookup value can be anything but typically some part of an incoming caller's ID would be used such as req.Header.From.FromURI.User or req.Header.From.FromName. The function will only return the top result from the lookup and will return nil if there are no results found.
Usage:
Description:
The Callback application is used to create a call between two separate parties rather than one between the original caller and a single forwarded destination.
The Callback application works by dialling the first call leg and if the leg is answered a call will be placed to the second leg and then if the second leg is answered the two calls will be bridged together. One weakness with this approach is that the first call leg can left listening to dead air while the second call leg is placed. Typically the first call leg should be to a party who is aware they are pariticpating in a callback and knows to hang on the line.
The additional parameters that can be used with the Callback application can control the timing or tailor the requests that are sent to each of the call legs: