Page History
Add_workflow_for_techpubs | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Panel | ||||
---|---|---|---|---|
In this section:
|
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
Spacevars | ||
---|---|---|
|
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 an 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
Spacevars | ||
---|---|---|
|
Leading Digit Routing
Spacevars | ||
---|---|---|
|
Route Simulation
The
Spacevars | ||
---|---|---|
|
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 | ||
---|---|---|
|
- Sequence—The
allocates the routes in the order of the values provided in the route Sequence field.Spacevars 0 product - Proportion—The
uses the Proportion method to determine the first route on a call-by-call basis.Spacevars 0 product
- Round Robin—The
distributes call traffic equally across the routes in a Routing Label. For each call, the routes are cyclically rotated by one position.Spacevars 0 product
- Route cost—The
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.Spacevars 0 product
HD Codec Based Routing
The HD codec based prioritization method is invoked after executing the existing route prioritization methods.
Info | ||
---|---|---|
| ||
The HD Codec Based Routing works only with a centralized PSX. |
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
Spacevars | ||
---|---|---|
|
- 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.
Use a wideband codec with Ingress Route PSP to facilitate end-to-end wideband calls. Any deviation from the above settings may not prioritize the route appropriately.
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
- EVS
The PSX receives the list of HD codecs and their sampling rates in the policy request sent by the
Spacevars | ||
---|---|---|
|
- 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
Spacevars | ||
---|---|---|
|
Include Page | ||||
---|---|---|---|---|
|
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:
- Use the same zone on which incoming call is received.
- 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:
- The name of the
that is processing the requestSpacevars 0 product - Zone name
- IP peers IP Address/ FQDN
- The name of the
Since the local trunk group is not returned in the policy response, the local trunk group in the zone is determined by the
Spacevars | ||
---|---|---|
|
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
tgrp and trunk-context Parameter Taken into Account Together
Trunk Groups are identified by two parameters: tgrp and trunk-context
.
The trunk-context
establishes the scope of the trunk group specified in the tgrp
parameter and determines if it is for a single gateway, a set of gateways, or an entire domain managed by the service provider.
The value in the trunk-context
identifies a gateway.
When the remote party sends the invite with both tgrp =
egress_tg, trunk_context
= Egress IP / Egress IP + Port / FQDN
, the
Spacevars | ||
---|---|---|
|
tgrp
parameter in the Request-URI (R-URI). The Spacevars | ||
---|---|---|
|
The SBC does not provision the IP peer when the remote IP address is already provisioned in some other system and the user does not want duplicate provisioning, or when the user does not know the remote IP address.
Info |
---|
A zone cannot have two trunk groups with the same ingress prefix information, but two different trunk group can be used towards the same destination. |
You can use a trunk group for multiple destinations without having the IP address in its list of ingress prefixes.
How it works
When you disable processTgrpContext
at the
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
tgrp
and trunk-context
to the PSX.In this case, when you enable the processDestinationTgrp
in Feature Control Profile, the PSX does light policy lookup and skips all the SSG-based services, number translation, and routing functions.
If you configure the ipSignalingPeerGroup
in the Trunk Group, the
Spacevars | ||
---|---|---|
|
ipSignalingPeerGroup
.If you do not configure the ipSignalingPeerGroup/ipPeer
in the Trunk Group and the trunk-context
is available, then the
routes the request to Spacevars 0 product trunk-context.
Process tgrp/trunk-context in R-URI On Light Dip
Prior to SBC 8.0, the
Spacevars | ||
---|---|---|
|
tgrp/trunk-context
functionality in R-URI for INVITE only. The Spacevars | ||
---|---|---|
|
tgrp/trunk-context
functionality in R-URI for NON-INVITE messages (same as DTG).The light dip principle instructs the Diameter+ PSX to skip most of the services and return a single route for the specified trunk group. This is useful for networks where an upstream SIP device (for example, the PSX Proxy which anchors the SIP session) performs crank back / route advance and sends the profile.
For more information, refer to the following PSX documents:
- Dynamic Routing and Policy Selection Based on D+
- OTG and DTG Parameter Processing
- Processing Trunk Group and Trunk-Context Parameters in SIP Messages
- Provisioning Trunk Context and R-URI in Trunk Group
- PSX as Proxy Server
The
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
tgrp
parameter for INVITE and NON-INVITE transactions ( the same as if it received the DTG parameter) allowing a light dip at the D+ PSX, for all INVITE and NON-INVITE out-of-dialog SIP transactions.The following figure depicts the example of NON-INVITE OOD transaction.
Figure 1: NON-INVITE OOD transaction
Include Page | ||||
---|---|---|---|---|
|
Routing Calls to SIP Server Using defaultSigZone
The
Spacevars | ||
---|---|---|
|
When the
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
defaultSigZone
, and use customer-provisioned named sipTrunkGroup (the ingress IP Prefix of which matches the SIP Server IP address) and customer-provisioned sipSigPort in the defaultSigZone for routing the call.Figure 2: SBC - SIP Server Network Diagram
Example:
SIP Trunk Group
Code Block | ||
---|---|---|
| ||
% 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
Code Block | ||
---|---|---|
| ||
% 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
Spacevars | ||
---|---|---|
|
GW-GW Routing
Table 1: GW-GW Routing
Parameter | Atttribute |
---|---|
gwSigPort | Local GW IP address |
defaultGwIptg (Used towards GW core to reach any Gateway not specified below | prefix-0.0.0.0 |
namedGwIptg | prefix-10.1.x.x |
Routing to SIP Servers
(SIP hop-by-hop routing and SIP core optimized routing)
Table 2: Routing to SIP Servers
Parameter | Attribute | ||||
---|---|---|---|---|---|
sipSigPort | Local SIP IP address | ||||
defaultSipIptg (Used towards any SIP Server and also used for SIP core) | prefix-0.0.0.0 (Wildcard IP to reach any SIP server/ Gateway not specified below) | ||||
namedSipCoreIptg (Used towards SIP core) | prefix-10.2.x.x (Peer
| ||||
namedSipIptg1 (Used towards SIP Server-1) | prefix-10.3.x.x (SIP Server-1 contact address) | ||||
namedSipIptg2 (Used towards SIP Server-2) | prefix-10.4.x.x (SIP Server-1 contact address) |
Routing to H.323 Servers
Table 3: Routing to H.323 Servers
Parameter | Attribute |
---|---|
h323SigPort | Local H.323 IP address |
defaultH323Iptg (Used towards any H.323 Server) | prefix-0.0.0.0 (Wildcard IP to reach any H.323 Server) |
namedH323Iptg (Used H.323 Server) | prefix-10.2.x.x (H.323 Server-1 contact address) |
Figure 3: Using Multiple Named Non-Routable IPTGs in defaultSigZone for Calls