Dialogic SIP-I Profiler User guide

Brand: Dialogic

Model: SIP-I Profiler

Type: User guide

SIP-I Profiler User GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 1/35

SIP-I Profiler User Guide

Dialogic® BorderNet™ Session Border Controller (SBC)

Release 3.8.1

May 2019

SIP-I Profiler User GuideDialogic Session Border Controller
Dialogic Inc. Proprietary Page 2/35
Table of Contents
Introduction
1 Purpose of this Document
2 Glossary
3 Contact Us
About the SIP-I Profiler
1 About SIP
2 SIP Profiler Document Hierarchy
2.1 Profiler Document Creation and Loading
2.2 Profiler Document Structure
2.3 Profiler Variables
3 Supported Combinations of SIP and SIP-I
4 Licensing
5 Basic Features of the SIP-I Profiler
6 Advanced Features of the SIP-I Profiler
7 SIP-I Configuration
8 ISUP Profiler
9 SIP-I Support
10 Routing
10.1 Routing Modes
10.2 Routing Precedence
10.3 Re-Routing
Actions Supported
1 Modify a parameter
2 Modify a Parameter for a Given ISUP Message
3 Retrieving & Modifying SIP Header/Parameter Values
3.1 Retrieve a Header Field
3.2 Modify a Header Field
3.3 Retrieve a Header Parameter
4 Adding New SIP Headers
4.1 Insert a New Known SIP Header
4.2 Insert a New Unknown SIP Header
5 Deleting SIP Headers
5.1 Delete a SIP Header
5.2 Delete all SIP Headers of One Type
6 Adding New SIP Header Parameter
6.1 Insert a new parameter
7 Deleting SIP Header Parameter
7.1 Delete a SIP Header Parameter
8 Retrieving/Storing Data from/to Variables
8.1 Store a String in a Transaction Variable
8.2 Retrieve a String from a Session Variable
9 Retrieving Data from Configuration Tables

SIP-I Profiler User GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 3/35

3.10 Retrieving Data from IP Layer fields

3.11 Table C-3 in Standard Q.767.

SIP-I Profiler User GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 4/35

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 3300 Boulevard de la Côte-Vertu, Suite 112, Montreal, Quebec,

Canada H4R 1P8. 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, Veraz, Brooktrout, Diva, BorderNet, PowerMedia, PowerVille, PowerNova, MSaaS, ControlSwitch, I-Gate,

Cantata, TruFax, SwitchKit, Eiconcard, NMS Communications, SIPcontrol, Exnet, EXS, Vision, inCloud9, and NaturalAccess, 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 3300 Boulevard de la Côte-Vertu, Suite 112, Montreal, Quebec, Canada H4R 1P8. 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.

SIP-I Profiler User GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 5/35

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.

Document History

Revision Release Date Notes

1.0 July 2018 Initial version

2.0 May 2019 Release 3.8.1

SIP-I Profiler User GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 6/35

1. Introduction

1.1 Purpose of this Document

This document is intended to familiarize the reader with the BorderNet SBC, SIP-I Profiler feature.

1.2 Glossary

For the purposes of this document the following abbreviations apply:

Term Abbreviation

IP Internet Protocol

SBC Session Border Controller

SCS SIP Control Server

SIP Session Initiation Protocol

XML Extensible Markup Language

XSD XML Schema Definition Language

1.3 Contact Us

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

SIP-I Profiler User GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 7/35

2. About the SIP-I Profiler

2.1 About SIP

Session Initiation Protocol (SIP) is the Internet Engineering Task Force's (IETF's) standard for multimedia conferencing over IP.

SIP is an ASCII-based, application-layer control protocol (defined in RFC 2543) that can be used to establish, maintain, and

terminate calls between two or more end points. Like other VoIP protocols, SIP is designed to address the functions of signaling

and session management within a packet telephony network.

Signaling allows call information to be carried across network boundaries.

Session management provides the ability to control the attributes of an end-to-end call whereby an IMG can be used as a

Media Gateway to allow two separate networks to connect.

The IMG supports SS7 to SIP, ISDN to SIP, CAS to SIP, SIP to SIP, and H.323 to SIP.

The Dialogic® BorderNet™ 4000 Session Border Controller (SBC) and Dialogic® BorderNet™ Virtualized Session Border Controller

(SBC) provide a SIP-I solution for encoding and decoding the encapsulated ISUP body, if and when present in a SIP Message.

The BorderNet SBC complies with the Profile-C requirements in the ITU spec Q.1912.5 in cases of an encapsulated message

available in the SIP Message.

2.2 SIP Profiler Document Hierarchy

The SCS Profiler consists of one or more SipProfiler documents, which are individual XML files. Each XML file contains

rules

with

associated

actions

that are used to manipulate SIP headers and parameters. Multiple files can be linked together logically for

enhanced organizational benefit and high eiciency.

For example, one XML file can be designed as a common building block that can be written once and called over and over on

dierent SIP interfaces as part of more complex header manipulations that may vary only slightly from one another.

When a SIP message enters on a SIP interface with a configured SipProfiler document the Profiler execution begins at the

invocation of the configured XML document called the

root document

. The outgoing SIP message on the same interface may have

a dierent XML document assigned to complete the desired header manipulation.

More complex SipProfiles may be defined by nesting multiple XML files in a pre-defined order to the root document. Each nested

XML documents is executed in order. The Profiler execution begins at the invocation of the root document associated with the SIP

interface. During root document execution, the root document may call other SipProfiler XML documents, as in the figure below

showing SCS Profiler nested documents.

SIP-I Profiler User GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 8/35

Any number of SipProfiler XML documents can be called during Profiler execution as long as the total hierarchy levels do not

exceed 5. The figure above illustrates a SipProfiler that executes 5 XML files within 3 hierarchy levels.

The order of execution begins with

Root Document-1

, moves to

Document-1.1

, then

Document-1.1.1

before returning to

Root

Document-1

and then traversing

Document-1.2

and

Document

1.2.1

2.2.1 Profiler Document Creation and Loading

Profiler documents are 'rules' written in XML that are created oline and then loaded on the SCS through the View Manager. Once

loaded, the XML file can then be selected via a dropdown box in the configuration GUI and applied to either an incoming SIP

message or an outgoing SIP message on a particular SIP interface.

XML syntax is automatically validated when each document is uploaded to the SCS using XSD (XML Schema Definition language).

2.2.2 Profiler Document Structure

Each SipProfiler XML document consists of one or more

elements. Each

element consists of a

and

element and is of the form:

If (condition) Then (statement).

There is no limit to the number of elements that may be contained within one SipProfiler XML document.

The

element contains the

conditions

and the

element contains the

statements

to be executed if all conditions

inside the

element return true. The figure below shows the SCS Profiler document structure.

SIP-I Profiler User GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 9/35

Profiler execution begins with the execution of the first

element in the root document and continues execution from

this rule to the next rule until one of the following conditions is met:

All the

elements in the document are executed.

element states to stop execution.

A SIP message is rejected by the Profiler.

The Profiler enables an operator to reject a SIP message based on precisely defined criteria. For example, a call may be released

early with a specific release code returned to the customer if a predefined mandatory SIP parameter is missing from an incoming

message.

element inside a

element may state to jump to another XML document as illustrated in the figure below

which shows the rule processing flow in Nested SipProfiler documents. In such a scenario all

elements in the child

XML document are executed before the rest of the

elements are executed in the parent XML document.

2.2.3 Profiler Variables

During header manipulation operations it may be advantageous to store certain header data from one operation and then call that

data during another operation.

The Profiler supports data value storage into dierent types of temporary variables each with a dierent lifetime.

The following types of variables are supported:

Local variables

Transaction variables

Note also the following:

Variable values: A variable can be assigned an initial value using the

tag and can be re-assigned a data value any

number of times using this same tag.

Variable scope: A child SipProfiler document can access a variable defined by the parent document and vice versa.

Variable quantities: The Profiler supports a limited number of variables of each type. While storing a data value inside a

variable, an index for that variable is assigned. An index number cannot exceed the maximum number of variables of each

type and can be used to access the variable during its lifetime.

Variable names: A variable can be given a name that is used to access the variable value during the variable's lifetime. The

variable name can be assigned in the same statement that is used to assign the variable value.

SIP-I Profiler User GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 10/35

An example of a local variable is shown here below:

<!-Stores Sip Request Method name inside a Local variable stored at index 1, named Method -->

</Assign>

Local Variables

Lifetime: A local variable is accessible throughout one single Profiler execution. Once a SIP message leaves the Profiler

(execution is complete) all local variables are destroyed.

Maximum quantities: ten (10) local variables per Profiler execution.

Note: One single Profiler execution is the timeline between execution of the first and the last

element inside one

SipProfiler (including the root and all child SipProfiler documents).

Transaction Variables

Lifetime: A transaction variable is accessible throughout the entire SIP transaction lifetime. For example, a transaction

variable created when an initial INVITE message is received can be accessed in 180 Ringing or 200 OK for that INVITE.

A transaction variable created inside an incoming interface can be accessed from SipProfiler assigned to an outgoing interface

for the same transaction.

Maximum quantities: five (5) transaction variables per transaction.

2.3 Supported Combinations of SIP and SIP-I

The following combinations for ingress and egress SIP messages are supported:

Ingress Protocol Ingress ISUP Body Egress Protocol Egress ISUP Body

SIP Present SIP Present

SIP NA SIP Present

SIP Present SIP NA

SIP-I Profiler User GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 11/35

Ingress Protocol Ingress ISUP Body Egress Protocol Egress ISUP Body

SIP NA SIP NA

The Dialogic BorderNet SBC supports sending and receiving encapsulated ISUP messages in SIP messages.

The BorderNet SBC encodes and decodes the encapsulated ISUP messages using the ETSI variant.

The ISUP body is handled as part of the multi-part or as a single body in the SIP message.

The ISUP body can also be handled with trailing /r/n or without trailing /r/n.

2.4 Licensing

SIP-I is a licensed feature. SIP-I calls are supported up to the maximum license limit. On unlicensed systems, SIP-I messages pass

transparently, unless the operator opts to reject or strip the message.

2.5 Basic Features of the SIP-I Profiler

The SIP-I Profiler features ISUP Body encode and decode.

The following basic features are pertinent to the SIP-I Profiler:

SIP-I Transparency - [Pass through and Encode/Decode modes].

SIP to SIP-I Call [Forcing Encapsulated Body].

SIP-I to SIP Call.

Reports to indicate SIP-I Call.

CDR/SDR to report SIP-I Call.

2.6 Advanced Features of the SIP-I Profiler

The following advanced features are pertinent to the SIP-I Profiler:

ISUP Parameter Modification [DA Rule Framework] - Introducing converged profilers for both SIP Message and ISUP Message

parameters.

Access to ISUP Parameters for Routing.

Internationalization framework where the Encode/Decode Supports all ISUP flavors which are supported by ControlSwitch.

2.7 SIP-I Configuration

SIP-I is configured via a web-based GUI.

SIP-I Profiler User GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 12/35

To configure SIP-I, it is necessary to configure it in the Service Profile, create a routing policy with the SIPICall parameter, and then

optionally upload an ISUP profiler.

→ To configure SIP-I in the Service Profile:

1. From the Application menu, select Application > Common > Service Profiles.

2. Select Edit from the notepad icon located next to the desired Service Profile.

3. From the Edit Service Profile screen, select the SIP-I tab.

4. Select the desired profile from the Incoming ISUP Treatment drop-down list. This is applicable to the incoming INVITE and

determines the leg behavior aerwards.

can be rejected

Possible values are:

Transparent-allows the current behavior to be retained while passing the SIP-I encapsulated body transparently to the next

leg. This is the default value. There will be no encoding/decoding of the ISUP part. The ISUP profiler cannot be used with this

setting

Reject-rejects the Incoming INVITE command with the internal cause code ISUPMessageBodyNotSupported

regardless of

whether the content handling is required or optional in the SIP Headers.

SIP Only-removes the ISUP encapsulated body from the SIP message and continues with the normal forwarding on the

Ingress.

SIP-I if available-decodes the ISUP body using the ETSI protocol for the received INVITE with the IAM. It also allows

modifications using the ISUP Profiler.

Select the desired profile from the Outgoing ISUP Treatment drop-down list. This is applicable to the outgoing INVITE and

determines the leg behavior aerwards.

SIP-I Profiler User GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 13/35

Possible values are:

Transparent-passes the SIP-I encapsulated body transparently to the network. There will be no encoding/decoding of the

ISUP part. The ISUP profiler cannot be used with this setting.

Reject-rejects the call from the Egress leg if it contains a SIP body.

SIP Only-removes the ISUP encapsulated body before sending the SIP message to the network. Subsequent messages shall

have ISUP messages that are force created on the Ingress.

SIP-I if available- performs decode of the incoming messages and allows modifications using the ISUP Profiler.

Always SIP-I-forces the ISUP body in the SIP message and forms the body based on the SIP Header. The operator can insert

more parameters using the ISUP Profiler to provide more ISUP specific behavior.

Click Save.

NOTE:

Incoming and Outgoing ISUP Treatments are determined by the interfaces or peers that make up a session and their

associated Service Profile SIP-I configuration.

The SIP-I interworking combinations with their associated ISUP treatments are shown in this table:

Ingress

Protocol

Ingress

ISUP Body Incoming ISUP Treatment Egress

Protocol

Egress

ISUP Body Outgoing ISUP Treatment

SIP Present Transparent, SIP-I if available SIP Present Transparent, SIP-I if

available

SIP NA Transparent, SIP-I if available SIP Present Always SIP-I

SIP Present SIP Only SIP NA SIP Only

SIP NA Transparent, SIP-I if available,

SIP Only SIP NA Transparent, SIP-I if

available, SIP Only

SIP Present Transparent, SIP-I if available,

SIP Only, Reject None None Reject

Routing Policy with the SIP-I Call Parameter

SIP-I Profiler User GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 14/35

A SIP-I call can be rejected at either the incoming interface/peer or the outgoing interface/peer. It can also be rejected within

routing itself using the SIPICall routing parameter.

Advanced Routing policy is a distinct area of code. It is also a dierent menu item from both the service profile information above

and the ISUP profiler information below it.

The Routing Policy contains a Rule Parameter called SIPICall.

This is an optional enhancement to routing to allow for advanced call routing based on whether the INVITE contained an

encapsulated ISUP IAM.

Values for this are Yes or No, with Yes as the default value.

→ To upload an ISUP Profiler:

1. From the Application menu, select Application > Common > ISUP Profiler.

2. Click Upload Profiler.

The Upload ISUP Profiler screen appears.

SIP-I Profiler User GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 15/35

3. Use the Browse button to select the desired ISUP Profiler file.

4. Enter the Name of the ISUP Profiler. The name must be unique to the BorderNet SBC.

5. Click Save.

The ISUP Profiler is added to the Summary screen.

2.8 ISUP Profiler

The SIP Profiler will call the ISUP Profiler, through an Action command. The ISUP Profiler acts on the ISUP part of the SIP-I

message. The SIP profiler has various SIPRule conditions to match before the Action of Execute for the ISUP Profiler is triggered.

There are three places where the SIP Profiler is used for a given SIP message:

As incoming profiler.

As mid-call profiler called from the Advanced Policy route.

As outgoing profiler.

The SIP Profiler will therefore be able to limit the calling of an ISUP profiler, for example to only work on INVITE messages. Much of

the target refinement can be at the SIP Profiler level before the ISUP Profiler is even invoked.

The ISUP Profiler allows the operator to add, delete or modify any parameter of a given ISUP message. It executes parameter

modification rules based on the message type.

XML rule files can be uploaded via the web-based GUI. An ISUP Profiler can only be executed as an Action within a SIP Profiler.

Note

the following:

ISUP Profilers are XML Rule files similar to SIP Profilers that provide mechanisms to perform operations on the ISUP Body

aer Decode and before Encode.

SIP-I Profiler User GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 16/35

The ISUP Profiler allows the operator to add, delete, or modify any parameter of a given ISUP message.

The ISUP Profiler is executed from within the SIP Profiler that is configured on the Service Profile.

XML rule files can be uploaded via the web-based GUI. The GUI doesn't allow creating or configuring the ISUP Profilers.

ISUP Profilers can act upon every ISUP Message similar to DA/MTR rules in ControlSwitch.

2.9 SIP-I Support

SIP-I Support is a licensed feature but is not limited to the number of sessions performed.

The following features are pertinent to SIP-I Support:

Any INVITE Message with ISUP Body shall be marked as a SIP-I Call in the SDR.

SIP-I Present is the only routing parameter available as part of this feature.

The BN4000 can act upon the encapsulated ISUP body by encode/decode, strip or reject.

The encode/decode of the ISUP Body shall be done for ETSI-ISUP only.

BN4000 has the ability to force the ISUP Body even when it hasn't received it from the Ingress.

Transparency options are still available to ensure backward compatibility.

Session Detail Records (SDR) contains a field under the Signaling item for the indication that the call had an encapsulated

ISUP body.

2.10 Routing

As a voice interworking device, an SBC plays several important roles. One of them is to act as a session router to redirect the calls

according to pre-established rules or policies.

Routing can be as simple as following the destination indicated in a SIP message or as complex as going through a tree to make a

routing decision based on a variety of parameters including ISUP as carried by SIP-I or SIP-T. An SBC behaves like a class 4 switch

and shares many common traits.

One of the first distinctions that must be made is that routing deals with the SIP messaging routing (signaling), not with the actual

media routing which comes much later during the SDP negotiating phase. This is a major dierence with SS7 where routing deals

mostly with media routing (CICs, TGs).

SIP-I Profiler User GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 17/35

It is necessary to understand the various paths that a SIP message can take. The diagram below depicts the relationship between

ETH interfaces, VLANs, IP addresses, SIP Interfaces and peers.

SIP Interfaces are a key concept and define a SIP Domain to which properties sets can be attached (profiles) to control media,

security, routing etc. Routes (advanced policies) can be assigned to SIP interfaces or peers.

SIP interfaces are defined by two key parameters: IP address and UDP/TCP/TLS ports. In the case of overlapping IPs, the VLAN

name is also added for dierentiation.

IP interfaces are defined for VLANs and there can be multiple IP addresses. If one IP address is to be used with more than one

SIP interface, then UDP/TCP/TLS ports need to be uniquely defined so the SIP interfaces can be uniquely identified.

VLANs are defined per interface and their ID has to be unique within the domain of an ETH interface.

Peers are simply endpoints to which traic is sent and/or received. Types of peers include the following:

Interconnect indicates a network, usually for Tandem or Class 4S SIP traic from other operators. A public network is

usually open to the Internet which is the Access-Public.

Local indicates a private network.

Access-Public indicates a public network towards UEs.

Access-Local indicates home access network.

Access-Interconnect indicates visiting access network.

In the context of the BN4000 a peer is just an entity with which the SBC and devices the SBC protects/serves exchange traic. It

provides features and functionality that can be defined specifically as part of the associated service, security, media and parameter

profiler, including the profiler rules.

SIP interfaces are associated to peers creating a binding that could serve as a trunk (interconnect), an access pipe connecting to

subscribers, or an IPPBX.

2.10.1 Routing Modes

SIP-I Profiler User GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 18/35

It is very important to understand the various modes of routing that exist in the BN4000 and how they relate to each other as well

as to understand the various settings that control routing.

The routing modes available are:

Static Routing - An association between a source pair Peer-SIP Interface and a destination pair. A very simple form of

directing traic. Interface to Interface Routing is all that is required. Peers are optional but can be defined for more

granularity.

SIP Message Routing - The SIP message contains a request for a destination in the form of a URL containing an IP address or

an FQDN. It requires the information of the Interfaces to route the call. For

ControlSwitchIntegration

there is a model of

Message Hop Routing where the Interfaces are available as part of the Route Headers.

External Routing - an external routing engine is part of the Policy Routing as a redirection service (3XX)

Policy Routing - the most complex of the routing mechanisms which involves creating policies that implement rules for

testing specific conditions on Headers, Field, responses, ISUP parameters etc.

It applies a treatment when the conditions are met. Policies are created and organized in a sequential/hierarchical tree.

If the policy returns a route which points to an external server then BN4000 will attempt the call to the external route

server (i.e. send INV to SIP redirect sever). There is a configuration on the service profile Redirect Response Handling

which, if set to Redirect will ensure that BN4000 will route based on the 3xx received from the SIP redirect server. This

will include two steps but ultimately external routing will be followed assuming that redirect response handling has been

set up to do this.

The policy routing process is further depicted in the next figure:

SIP-I Profiler User GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 19/35

One interesting aspect of the BN 4000 is the extensive capability to parse and modify SIP messages including responses, very much

like a TDM switch does with translations/number manipulations.

The SIP-I profiler is capable of analyzing the various signaling components and assigning a value to Generic Parameters that can

be used further down the routing process to make decisions.

Also Global Variables can be created within the routing engine that can be used by other routing policies to make more routing

decisions. If the route selected contains an FQDN then one additional step is added which is to dip a DNS server for an IP address.

This provides the opportunity to perform load distribution by provisioning the DNS server with multiple IP addresses that are

hunted cyclically.

2.10.2 Routing Precedence

The Routing which applies when several routing methods are applicable will conform to one of the following cases:

Case 1: Only static routing is configured without any policies.

In this case BN4000 configures static routing as the default routing for calls originating from the said peer/interface combination.

Case 2: Static routing is configured and some policy is defined.

The assumption here is that policy configuration performs some operation but does not result in return of a route. This case works

similarly to case 1 where BN4000 performs actions according to the configured policy (e.g. add +1 to the number, remove certain

codecs from SDP, strip a proprietary header, etc) and then uses the static routing instructions to complete the call. In other words,

policies are used to clean up/tweak certain things in the signaling.

Case 3: Static routing is defined, policy is also defined, policy produces a route.

This diers from case 2, in that performing the actions in the policy yields a "route". This could be time of day routing, or call

routing based on some SIP header/parameter, etc. In this case BN4000 abandons the static routing rules and follows the route

returned by the policy. Further, if the call to the route provided by the policy fails then there is no returning to the static route.

Case 4: Same as case 3 except an external routing agent is consulted.

This case works similarly to case 3. BN4000 abandons configured static routing instructions in favor of the result obtained from

querying an external routing agent (3xx or DNS or ENUM in future). BN4000 simply follows the route returned by the external

routing agent. As in the previous case, should a call attempt fail there is no falling back to the static routes. If a policy returns a

route which points to an external server then BN4000 will attempt the call to the external route server (i.e. send INV to SIP redirect

sever).

Case 5: No static routing but advanced policies defined.

Here assuming a configured policy returns a route, then BN4000 follows that route. If a policy returns a route which points to an

external server then BN4000 will attempt the call to the external route server (i.e. send INV to SIP redirect sever).

Case 6: SIP Message Routing.

SIP routes can be included in the incoming SIP message via the Route Header or SIP Request-URI. SIP routing can be configured

to use pre-determined routes in the SIP message. When this configuration is enabled, SIP routing overrides the destination given

SIP-I Profiler User GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 20/35

from a Point-to-Point (P2P) routing lookup.

When SIP message routing is selected from a Service Profile, the BorderNet 4000 SBC performs only SIP message routing. Static

routing is necessary to determine an outgoing interface for the session and could return a destination peer, but in this case, SIP

message routing determines the destination by the contents of the SIP message.

2.10.3 Re-Routing

Re-Routing is implemented in the BN4000 as follows:

SCS shall attempt the first route if connectivity is proper.

SCS receives 5xx Responses.

Since there are more routes from the initial dip, SCS shall reroute to the next route.

SCS decrements the Max Routing Attempts Count.

Until the routes are exhausted or the attempts are exhausted, rerouting continues.

Page is loading ...

Dialogic SIP-I Profiler User guide

Dialogic SIP-I Profiler User guide

Dialogic SIP-I Profiler User guide

Related papers

Other documents