Dialogic External Route Server User guide

Brand: Dialogic

Model: External Route Server

Type: User guide

Route Server Start GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 1/31



External Route ServerGuide

Dialogic® BorderNet™ Session Border Controller (SBC)

Release 3.8.1

July 2019

Route Server Start GuideDialogic Session Border Controller
Dialogic Inc. Proprietary Page 2/31
Table of Contents
 Introduction
1 Purpose of this Document
2 Glossary
3 Contact Us
 Overview
1 About the External Route Server
2 External Route Server Call Flow
3 Exceptions
 Routing Options
1 Rerouting
1.1 REJECT Treatment
1.2 SKIP-CARRIER Treatment
1.3 CONTINUE NEXT ROUTE Treatment
1.4 REDIRECT Treatment
1.5 TRY WITH TRANSCODING Treatment
2 External Routing
3 Local Number Portability (LNP)
4 Directory Lookup
5 Criteria Set
6 Matrix (Table Lookup)
7 ENUM Feature
7.1 ENUM Routing Functionality
7.2 ENUM Query and Answer
 Accessing the External Route Server
1 Configuring an External Server
2 Enable Connectivity
3 Multiple External Route Servers

Route Server Start GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 3/31

Route Server Start GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 4/31

without permission in writing from Dialogic Corporation at the address provided below.

All contents of this document are furnished for informational use only and are subject to change without notice and do not

represent a commitment on the part of Dialogic Corporation and its ailiates or subsidiaries ("Dialogic"). Reasonable eort is

made to ensure the accuracy of the information contained in the document. However, Dialogic does not warrant the accuracy of

this information and cannot accept responsibility for errors, inaccuracies or omissions that may be contained in this document.

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH DIALOGIC® PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED,

BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED

IN A SIGNED AGREEMENT BETWEEN YOU AND DIALOGIC, DIALOGIC ASSUMES NO LIABILITY WHATSOEVER, AND DIALOGIC DISCLAIMS

ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF DIALOGIC PRODUCTS INCLUDING LIABILITY OR

WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY INTELLECTUAL

PROPERTY RIGHT OF A THIRD PARTY.

Dialogic products are not intended for use in certain safety-aecting situations.

Please see http://www.dialogic.com/company/terms-of-use.aspx for more details.

Due to diering national regulations and approval requirements, certain Dialogic products may be suitable for use only in specific

countries, and thus may not function properly in other countries. You are responsible for ensuring that your use of such products

occurs only in the countries where such use is suitable. For information on specific products, contact Dialogic Corporation at the

address indicated below or on the web at www.dialogic.com.

It is possible that the use or implementation of any one of the concepts, applications, or ideas described in this document, in

marketing collateral produced by or on web pages maintained by Dialogic may infringe one or more patents or other intellectual

property rights owned by third parties. Dialogic does not provide any intellectual property licenses with the sale of Dialogic

products other than a license to use such product in accordance with intellectual property owned or validly licensed by Dialogic

and no such licenses are provided except pursuant to a signed agreement with Dialogic. More detailed information about such

intellectual property is available from Dialogic's legal department at 6700 Cote-de-Liesse Road, Suite 100, Borough of Saint-

Laurent, Montreal, Quebec, Canada H4T 2B5. Dialogic encourages all users of its products to procure all necessary intellectual

property licenses required to implement any concepts or applications and does not condone or encourage any intellectual

property infringement and disclaims any responsibility related thereto. These intellectual property licenses may dier from

country to country and it is the responsibility of those who develop the concepts or applications to be aware of and comply

with dierent national license requirements.

Dialogic, Dialogic Pro, Dialogic Blue, Veraz, Brooktrout, Diva, BorderNet, PowerMedia, PowerVille, PowerNova, MSaaS,

ControlSwitch, I-Gate, Mobile Experience Matters, Network Fuel, Video is the New Voice, Making Innovation Thrive, Diastar, Cantata,

TruFax, SwitchKit, Eiconcard, NMS Communications, SIPcontrol, Exnet, EXS, Vision, inCloud9, NaturalAccess and Shiva, among

others as well as related logos, are either registered trademarks or trademarks of Dialogic Corporation and its ailiates or

subsidiaries. Dialogic's trademarks may be used publicly only with permission from Dialogic. Such permission may only be granted

by Dialogic's legal department at 6700 Cote-de-Liesse Road, Suite 100, Borough of Saint-Laurent, Montreal, Quebec, Canada H4T

2B5. Any authorized use of Dialogic's trademarks will be subject to full respect of the trademark guidelines published by Dialogic

from time to time and any use of Dialogic's trademarks requires proper acknowledgement.

The names of actual companies and products mentioned herein are the trademarks of their respective owners.

Route Server Start GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 5/31

This document discusses one or more open source products, systems and/or releases. Dialogic is not responsible for your decision

to use open source in connection with Dialogic products (including without limitation those referred to herein), nor is Dialogic

responsible for any present or future eects such usage might have, including without limitation eects on your products, your

business, or your intellectual property rights.

Revision History

Version # Date Description

1.0 September 2012 Initial Release

2.0 May 2017 Release 3.6.0 - Terminology and formatting

2.1 October 2017 Release 3.7.0

2.2 March 2018 Release 3.7.5

2.3 July 2018 Release 3.7.6

2.4 July 2019 Release 3.8.1

Route Server Start GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 6/31

1. Introduction

1.1 Purpose of this Document

This document is intended to familiarize the reader with the Dialogic BorderNet SBC's interconnection to an External Route Server.

1.2 Glossary

For the purposes of this document the following abbreviations apply:

Abbreviation Meaning

DNS Domain Name System

LNP Local Number Portability

NAPTR Name Authority Pointer

OTG Originating Trunk Group

SBC Session Border Controller

SCS Session Control Service

1.3 Contact Us

For a list of Dialogic locations and oices, please visit: https://www.dialogic.com/contact.aspx.

Route Server Start GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 7/31

2. Overview

2.1 About the External Route Server

Interconnection to an External Route Server is available. With this feature, operators can configure the BorderNet SBC to consult

an external routing engine via the SIP INV/3xx method to receive call routing instructions in the form of route lists.

The ExternalRoutes treatment provides information about routing the call towards the External Route Server, which itself provides

the routes. These External Routing severs are SIP-based and in response to a request on INVITE provide routes in the form of a 302

response.

Additional features available include the following, which are applicable for the entire release and not just for the specific External

Route Server:

Ability to control rerouting based on Cause Codes.

Ability to lookup into the External Route Server for routes/destinations.

Ability to identify a group of peers as carriers.

Ability to skip peers for a given carrier.

Ability to lookup into the External Route Server for Local Number Portability (LNP).

Ability to lookup into an in-switch LNP.

Ability to define routing templates for a large data of rules (Matrix Feature).

Policy control to reattempt a destination with transcoding.

A failback mechanism for External Route Server failures.

To support this feature, the BorderNet SBC WebUI enables the modification of SIP Profiler entries and parameters to provide

access and route traic to the External Route Server.

The BorderNet SBC also supports routing using trunk group parameters as part of this feature.

This indicates the action which needs to be taken aer an ExternalRoute lookup can be configured by the operator based on the

ExternalRouteLookupStatus field.

The External Routing process is illustrated in the following diagram.

Route Server Start GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 8/31

2.2 External Route Server Call Flow

BorderNet SBC determines the routing destinations based on the internal configuration of the Advanced Policy.

Some operators request that routes from an external Routing Server should provide the destinations to route. These External

Routing Servers are SIP-based and operate in response to INVITE requests to provide routes for a 302 response. The 302 Response

contains a Contact header with an FQDN that represents a list of IP addresses the External Route Server wants the BorderNet SBC

to use when attempting to terminate a call.

The following diagram shows an example of a call flow using a Third-Party External Route Server:

In the diagram above:

Route Server Start GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 9/31

The BorderNet SBC receives the INVITE and routes it to the third-party External Route Server.

The External Route Server responds with a 302 Moved Temporarily message with a Contact header, which contains a number

that represents a trunk group.

Note:

The SIP Profiler manipulates this information to enable the BorderNet SBC to interpret it

The BorderNet SBC interprets the Contact header information and determines a list of one or more outgoing Peers and

Interfaces to which the call can be sent. In the example above, the new destination does not accept the call and responds

with a 4XX message.

The BorderNet SBC obtains the next route in the IP address list based on the 302 message's Contact information.

Using this IP address, the BorderNet SBC derives a related Peer and tries the call again to a new destination. In the example

above, the destination accepts the call, and the call continues normally.

2.3 Exceptions

The External Route Server responds with a customer-defined SIP Trunk Group number in the 302 response, shown in the following

example:

Contact: sip:526142143004@21084

The BorderNet SBC cannot interpret an FQDN in a pure numerical format. In this case, the SIP Profiler takes the 21084 portion of

the response above and converts it to a specific new FQDN with an initial alphabetical identifier. Using the above example, 21084

will be converted to rl21084 where rl stands for route list.

This conversion allows the entry to be read by the BorderNet SBC DNS mapping table.

Route Server Start GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 10/31

3. Routing Options

3.1 Rerouting

Rerouting a session means trying a new destination when the session initialization attempt towards an existing server fails.

Currently BorderNet retries all existing Egress servers when there is a failure, except for 486.

This enables operators to control this behavior and provide alternate actions such as REJECT, SKIP_CARRIER, CONTINUE NEXT

ROUTE, REDIRECT, TRY WITH TRANSCODING.

The table below outlines these alternate actions.

Treatment Functionality Data

REJECT Rejects the call and stops attempting further routes. An optional

cause value can also be set. SIP status codes

SKIP-CARRIER Skips the carrier associated to the current Egress point and jumps to

the next. N/A

CONTINUE

NEXT ROUTE Continues to attempt the next route identified previously. N/A

REDIRECT Redirects to a dierent number, dropping already available routes.

This redirection can be to a number or peer.

E.164 number or SIP username

and optional SIP hostname.

TRY WITH

TRANSCODING

For a failed call, based on the release code, the operator can decide

to retry the same route by introducing transcoding. N/A

Note also the following elements:

The reroute plan can be created from the Advance profile, i.e. another policy similar to the Advanced Policy with the

treatments outlined in the table above.

The service profile contains a dropdown list of policies (similar to the Advanced Policy), but with the heading Reroute Policy.

The Session Control Service (SCS) will invoke the reroute policy on session initialization attempt failures. The cause value

received from the network will be available for the PE to ensure eective decision making in the reroute plan.

The SCS will provide the SIP Status Code to the PE through the data provider interface. The PE can use this value when any

reroute policy contains it in the rule parameters

The PE will lookup the Reroute Policy based on the interface PerformPolicyBasedRouting, where the SCS continues to

provide the correct Reroute Policy.

Re-Route treatment can be modified directly from the Advanced Policy Configuration window.

Route Server Start GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 11/31

Note:

The Try With Transcoding treatment option will only be triggered if that peer has a transcoding profile with the transcoding

mode of 4xxMediaUnsupported. This allows the user to choose to try additional routes before resorting to the (more expensive)

transcoding profile.

3.1.1 REJECT Treatment

When processing a REJECT treatment, the SCS will release the call. While releasing the call, the SCS if a new value is provided by

the PE through the reroute policy.

If any such value is configured in the policy, the same SIP cause code will be used to release the session.

If the optional status code is not provided in the REJECT treatment, the SCS will use the previously received SIP status code to

release the session.

Route Server Start GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 12/31

3.1.2 SKIP-CARRIER Treatment

When processing a SKIP-CARRIER treatment, the SCS will prune out the peers with the same classId as the Egress Peer from where

the INVITE received its failure response. It is the responsibility of the operator to configure the same classId for peers that belong

to the same carrier.

If SKIP_CARRIER is received on an Egress point that doesn't have a classId defined, no pruning is expected and the SCS will

continue the session initialization attempt towards the next route in the list.

If there are no Egress points available, then Ingress is released with the same cause value as that received from Egress.

Route Server Start GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 13/31

3.1.3 CONTINUE NEXT ROUTE Treatment

When processing a CONTINUE NEXT ROUTE treatment, the SCS will continue to attempt the next Egress point available. If there are

no Egress points available, then an Ingress point is released with the same cause value received from Egress.

3.1.4 REDIRECT Treatment

When processing a REDIRECT treatment, the SCS will drop all the existing routes and redo the Advanced Policy lookup by replacing

the request URI to the value provided in the REDIRECT treatment.

The use case is for a response scenario such as remote returned 402 (payment required) or 486 (busy here) to direct a call to an

external announcement server.

Route Server Start GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 14/31

3.1.5 TRY WITH TRANSCODING Treatment

When processing a TRY WITH TRANSCODING treatment, the SCS will reattempt the same route by introducing transcoding

resources.

There is no change in how transcoding is configured in the system. The default behavior of introducing transcoding will be

honored if there is no reroute plan.

Route Server Start GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 15/31

3.2 External Routing

In the Advanced Policy, the treatment EXTERNAL_ROUTES is defined where one or more peers are configured.

The External Route Server is expected to respond with routes that will eventually be used for routing the call. The External Routes

treatment can have options to configure multiple destinations for multiple servers.

The status of the lookup can be checked in the ExternalRouteLookupStatus routable parameter. The same policy can be relooked

aer an external dip.

The possible values of ExternalRouteLookupStatus are:

DipNotDone (default)

Failure

NoRoutes

RoutesAvailable

The SCS receives the EXTERNAL_ROUTES treatment, and initiates a session towards the External Routing Server.

The SCS will handle the 302 response with multiple Contact headers. Each of the addresses provided in the Contact headers is

treated as an external route.

With the routes received in the 302 response, the SCS will then attempt to initiate INVITEs towards the new routes, and it will

append the external routes to any routes received in the ROUTE treatment.

When the EXTERNAL_ROUTE lookup isn't successful (for either a timeout reason or the External Route Server is not reachable by

OPTIONS),the SCS will use the routes from the ROUTE treatment (only for the case where EXTERNAL_ROUTES is combined with a

ROUTE treatment).

Route Server Start GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 16/31

If there are no ROUTES from the PE and no external routes (external route lookup failure), the SCS will redip into the PE. If the

external route lookup status is Routes Available, the call will pass to the treatment of ContinueToNextRoute.

External Routes treatment can be modified directly from the Advanced Policy Configuration window.

Multiple Advanced Policy lookups are possible.

The following are cases when Advanced Policy lookup is performed:

Initially when the INVITE is received

When External lookup succeeds

When External lookup fails

When External LNP Lookup succeeds

When External LNP Lookup fails

Any call related parameters when modified

When there are multiple External Route Servers, a failure from one server will lead to a lookup into the next configured External

Route Server.

This eectively means that for either External Routes treatment or LNP Treatment, further Advanced Policy lookup is possible only

when all External Route Servers have been attempted.

There is no limit for the number of times that an Advanced Policy lookup can be made.

When there are multiple external servers, a failure from one server will lead to a lookup into the next external server configured.

When multiple routes are configured as part of the 'External Routes', the service will go to the next available route when a timeout

occurs or when a 4xx/5xx/6xx response is received.

When all routes configured in the 'external routes' are exhausted and failure is received, the status Failure will be set. Before any

external lookup, the default value of the ExternalRouteLookupStatus is DipNotDone.

3.3 Local Number Portability (LNP)

Route Server Start GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 17/31

Local Number Portability (LNP) is a service that allows subscribers to switch local or wireless carriers and still retain the same

telephone number.

The purpose of the LNP feature is to check with an external LNP server whether a given phone number is ported or not. The

Advanced Policy needs to be configured to have Local Number Portability treatment and routes and it should be configured to

indicate which remote SIP server needs to be dipped.

BorderNet performs external lookups for LNP and one or more peers can be configured as LNP servers. If one server times out

them the lookup is referred to another server. When all external servers are exhausted, the system will lookup into the advanced

policy with the parameter LNP lookup failed.

In the case of a 302 response where the LNP Dip is performed and the number is not translated, aer a response from the LNP

Server (even on timeout), an additional advanced policy is performed. Based on the value of the LNPLookupStatus parameter

value, the operator can decide on any action. The default value of LNPLookupStatus is DipNotDone.

Where the LNP lookup leads to a new translated number, then an advanced policy lookup is performed to 're-analyze' the new

data and any treatment if present, will be discarded.

Each numbers table can contain up to 100,000 records, and a maximum of 30 tables can be provisioned to the system.

Number translation is configurable as an action of a rule in the Advanced Policy (presented in a dropdown list), for the following

parameters:

CalledPartyUserId - the searched number is extracted from the user part of the Request-URI (request line). The headers to be

modified if the number is translated include the Request-URI and the TO headers.

CallingPartyUserId - the searched number is extracted from the user part of the P-Asserted-Identity header. If the P-Asserted-

Identity is not available then it extracts the number from the user part of the FROM header. The headers to be modified if the

number is translated include the P-Asserted-Identity and FROM headers.

From - the searched number is extracted from the user part of the FROM header. The headers to be modified if the number is

translated include only the FROM header.

A rule parameter: Number Portability Dip Indicator (NPDI) is available with the action 'isPresent'. The value can be set to 'yes' or

'no'.

Route Server Start GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 18/31

This rule parameter provides control to operators to decide the treatment of a call when the LNP dip has already been performed.

The NPDI policy parameter can help operators decide whether an incoming call is already dipped or not. When an incoming call is

dipped and has NPDI, the IncomingRN field is accessible to the policy to decide which destinations the call needs to be routed to.

The LNP Lookup process is illustrated in the following diagram.

The parameter LNP Lookup Status helps decide whether to use the same policy for multiple iterations. It is configurable as an

action of a rule in the Advanced Policy (presented in a dropdown list), for the parameters IsEqualTo and IsNotEqualTo.

The possible values of the LNP Lookup Status parameter are:

DipNotDone (default)

Failure

DipDoneNotTranslated

DipDoneTranslated

LNP treatment can be modified directly from the Advanced Policy Configuration window.

Route Server Start GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 19/31

In the case of a 302 response where the LNP dip is done and the number is not translated, if there are any further treatments, no

Advanced Policy lookup is performed and the call will continue to execute the next treatment. If there are no further treatments,

then an Advanced Policy lookup is performed.

The LNP Lookup Status value will be set to DipDoneNotTranslated.

For a scenario where the LNP lookup comes with a new translated number, an Advanced Policy lookup is done to 're-analyze' new

data and any treatment present will be discarded.

The LNP Lookup Status value in this case will be set to DipDoneTranslated.

The SCS will insert the NPDI parameters when an external lookup is performed so that servers downstream will not need to relook

into the LNP server for Number Portability.

Another available configurable parameter is the IncomingRN and the RN. If there is an RN field in the incoming INVITE, the value is

accessible to the Advanced Policy so that the routing decision can be made on the RN if required. The RN routable parameter is

available with the value received from the LNP server.

Route Server Start GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 20/31

3.4 Directory Lookup

Directory Lookup is a service enabling the parameters of the call to be matched/looked up with data in a directory list to

determine if the call parameter belongs to that group.

This lookup is performed as part of the policy execution. It is extremely useful in the implementation of logic for functions such as

subscriber checking, screening, whitelist, blacklist etc. These functions oen require lookup of call parameters in a directory list.

Directory Lookup tables are imported to BorderNet SBC from CSV files. Once inside the BorderNet, tables can be modified by

editing, deleting or adding new entries.

The policy lookup provides tools for the operator to look up any call parameters into the directory list data, that would enable

operators to reject the call, reject calls with announcements/tones, pick alternative routes, or in general for any policy decision.

The requirements for Directory Lookup are as follows:

Every directory list shall be identified by a unique name.

Each directory list/table shall allow data that shall be stored in a persistent memory (regular XML configuration files or an

internal database), and shall also be loaded to the BorderNet's memory (RAM) for runtime processing.

Each Directory Lookup table shall be limited to a maximum of 100,000 records.

The total number of lookup tables shall be limited to 100.

Two Routable parameters, BelongsToList and NotBelongsToList allow the policy to check if a given number belongs to a given

directory list. The directory list is evaluated by checking to see if the given routable parameters are contained in the directory.

Each database should be limited to:

max 200 tables per database.

max 100,000 records per table.

max 4,000,000 records per database.

Page is loading ...

Dialogic External Route Server User guide

Dialogic External Route Server User guide

Dialogic External Route Server User guide

Related papers

Other documents