Page History

This

section describes several call routing mechanisms:

Username/SIP URI Routing

Username/SIP URI routing allows routing of requests based on the username and/or domain name in the SIP Request-URI. The username may be digits or an actual username. In either case, routing tries to find the most specific match for the (full) username and domain name, followed by less specific matches on suffixes of the domain name.

By default, the

Standard Destination-Based Routing

The Standard destination based routing supports route lookups based on following parameters:

• Carrier based routing
• Trunk group based routing
• Calling number based routing
• Called number based routing

Enhanced 911 Emergency Routing

In a VoIP environment, subscribers can take their phone numbers outside of their original geographic location (local number portability) or use a VoIP adapter to make calls from a remote location. To make emergency services available to subscribers not tied to fixed geographic locations, Enhanced 911 tracks caller location and the Public Services Answering Point nearest to them by means of a VoIP Positioning Center (VPC).

The

Leading Digit Routing

Spacevars
0 product

 standard routing performs a leading digits prefix match to determine the best route available. Routes are defined based on either the entire called number or the leading digits of the number.

Route Simulation

The

Spacevars
0 product

 supports the capability to configure test routes for routes simulation using the ‘routingLabelRoute’ parameter and ‘testing’ sub-parameter of global call routing feature.

CLI command example:

Code Block
% set global callRouting routingLabel 1 routingLabelRoute 2 testing test

Where testing parameter has three options:

• nonTest – When selected, the ERE does not return the route when the CPC value in a policy request is Test Call. When the CPC value is not a Test Call or is not present in the policy request, the ERE returns the route. Select this option to identify routes not to be returned during testing.
• normal – After testing and verifying a route, select this option to use the route for live calls. When selected, the ERE returns the route regardless of the calling party category (CPC) value, or absence of a CPC value, received in the policy request. (Default setting).
• test – When the CPC value in a policy request is Test Call, the ERE returns the route. When the CPC value is not Test Call or is not present in the policy request, the ERE does not return the route.

Route Prioritization

The

Spacevars
0 product

 supports route prioritization in a routing label based on the methods:

• Sequence

• —The

  Spacevars
  0 product

   allocates the routes in the order of the values provided in the route Sequence field.
• Proportion

• —The

  Spacevars
  0 product

   uses the Proportion method to determine the first route on a call-by-call basis.

For example, if the Route Label contains three routes with assigned proportions of 80, 50, and 30, the system generates a random number (in this case between 0 and 159), and if the number is between 0 and 79 the system sets the route with the 80 proportion as the first route. If the random number is between 80 and 129, the system sets the route with the 50 proportion as the first route. If the random number is between 130 and 159, the system sets the route with the 30 proportion as the first route.

• Round Robin—The

• Spacevars
  0 product

   distributes call traffic equally across the routes in a Routing Label. For each call, the routes are cyclically rotated by one position.

For example, call 1 receives routes 1-10, call 2 receives routes 2-11, call 3 receives routes 3-12, etc.

• Route cost—The

• Spacevars
  0 product

   determines the routes by cost, the least (lowest) cost route being the first priority route selected. In the case of equal cost routes, use the Route Prioritization Type for Equal Cost Routes parameter to select a secondary route prioritization type.

HD Codec Based Routing

The HD codec based prioritization method is invoked after executing the existing route prioritization methods.

Prerequisites

HD codec based prioritization is an end-to-end routing feature on the ingress offer. To configure the codec priority to remain constant throughout

• Honor Remote Precedence—Select this option in the ingress route PSP so that the priority specified by the ingress peer in the offer is unchanged when sent to the egress.
• Send Route PSP Precedence—Clear this option in the ingress route PSP so that the priority specified by the ingress peer in the offer is unchanged when sent to the egress.

Prioritizing routes based on HD codec

In Codec based prioritization, the PSX prioritizes the egress routes for the following High Definition (HD) codecs:

• G.722
• G.722.1
• G.722.2 (AMR-WB)
• G729.1
• SILK
• MSRT

The PSX receives the list of HD codecs and their sampling rates in the policy request sent by

the

• Routes with first priority egress codecs are placed on top
• Routes with the second priority egress codecs are placed next
• All the remaining routes are placed at the bottom

If the ingress PSP does not contain any of the above mentioned codecs, then the PSX configures the routes normally based on the existing logic.

TGRP/Trunk-Context Based Routing

A SIP-to-PSTN gateway can have trunks connected to different carriers. Plus, a SIP proxy may choose (based on proprietary routing logic) a carrier in which a call is sent when it proxies a session setup request to the gateway. Since, multiple carriers can transport a call to a particular phone number, a phone number by itself is not sufficient to identify the carrier at the gateway. To overcome this, the ERE routing logic uses “tgrp” and “trunk-context” parameters in the Request URI header as described below.

The

processing Destination Trunk Group (DTG) and Originating Trunk Group (OTG) parameters received in Contact and Request-URI messages, and transparently passing this information or inserting it in response messages or egress INVITE headers. When configured this way, even if OTG or DTG values are included in the received messages they are not used in processing of trunk group values for response and egress.

If the PES receives destination trunk group parameters (tgrp and trunk-context) in the policy request and if “Process Destination Tgrp” and “Process Destination Trunk Context” flags are enabled for the ingress trunk group, PES performs a light policy lookup and skips full policy dip. In this scenario, the ERE uses the trunk group name received in the tgrp parameter (similar to the dtg parameter). Also, the trunk-context parameter value is ignored. If DTG is present, it is also ignored.

The IP address is unique within a zone. To perform a reverse lookup against an IP peer, the IP address and zone are required. When trunk-context contains an IP address, use a default zone to look up the IP peer.

Two options are available to identify the zone name:

1. Use the same zone on which incoming call is received.
2. Use address context to look up the IP peer based on assumption that ingress peer and IP address in trunk-context belong to the same address context. The following details are sent in the policy response:

• • SBC name that is processing the request
  • Zone name
  • IP peers IP Address/ FQDN

Since the local trunk group is not returned in the policy response, the local trunk group in the zone is determined by

the

After determining IP peer based on the trunk-context, the zone name to which this IP peer belongs is determined by fetching IP peer table. The ERE can send back the egress zone information in the policy response by populating zone ID in the zoneIndex attribute in the route4Attributes table.

A CLI configuration example is shown below.

• Allow processing of “tgrp” and “trunk-context” for feature control profile “DEFAULT_IP”:

  Code Block
  language none
  % set profiles featureControlProfile DEFAULT_IP processDestinationTrunkGroupAndTrunkContext enable

• Associate the profile with a SIP trunk group:

  Code Block
  language none
  % set addressContext default zone defaultSigZone sipTrunkGroup DEFAULT_TG policy featureControlProfile DEFAULT_IP

Routing Calls to ASX or SIP Server Using defaultSigZone

The 

When the

Example:

SIP Trunk Group

% set addressContext default zone defaultSigZone sipTrunkGroup defaultSipTrunkGroup ingressIpPrefix 10.7.6.40 32
% set addressContext default zone defaultSigZone sipTrunkGroup defaultSipTrunkGroup media mediaIpInterfaceGroupName DLIG
% set addressContext default zone defaultSigZone sipTrunkGroup defaultSipTrunkGroup state enabled mode inService

SIP Signaling Port

% set addressContext default zone defaultSigZone sipSigPort 1 ipAddressV4 10.7.15.146 portNumber 5060 transportProtocolsAllowed sip-udp
% set addressContext default zone defaultSigZone sipSigPort 1 ipInterfaceGroupName DLIG
% set addressContext default zone defaultSigZone sipSigPort 1 mode inService state enabled

Refer to Zone - SIP Trunk Group - CLI for command syntax and parameter descriptions.

Multiple Named Non-Routable IPTGs in defaultSigZone

The

GW-GW Routing

Routing to SIP Servers/ASX

(SIP hop-by-hop routing and SIP core optimized routing)

Routing to H.323 Servers