Oracle® Communications Unified Session Manager

Oracle® Communications Unified Session
Manager
Configuration Guide
Release S-CZ7.2.5
Formerly Net-Net SIP Multimedia Xpress
December 2016
Notices
Copyright ©2015, 2013, Oracle and/or its affiliates. All rights reserved.
This software and related documentation are provided under a license agreement containing restrictions on use
and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license
agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit,
distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering,
disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you
find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on
behalf of the U.S. Government, then the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any
programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are
"commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific
supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs,
including any operating system, integrated software, any programs installed on the hardware, and/or
documentation, shall be subject to license terms and license restrictions applicable to the programs. No other
rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications. It is
not developed or intended for use in any inherently dangerous applications, including applications that may
create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be
responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use.
Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or
hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their
respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are
used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the
AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices.
UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information about content, products, and
services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all
warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an
applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for
any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services,
except as set forth in an applicable agreement between you and Oracle.
Contents
About This Guide......................................................................................................................................... 33
1 Oracle USM Basics......................................................................... 37
Oracle USM and IMS..........................................................................................................................................37
Oracle USM and OTT......................................................................................................................................... 39
Multiple Control Functions on a Single Device..................................................................................................39
Elements of Oracle USM Configuration ............................................................................................................ 39
High Availability................................................................................................................................................. 40
2 Getting Started with the Oracle USM............................................. 43
Oracle USM Installation and Startup.................................................................................................................. 43
Hardware Installation Process................................................................................................................. 43
Connecting to Your Oracle USM............................................................................................................ 44
System Boot............................................................................................................................................ 46
Oracle USM Boot Parameters............................................................................................................................. 46
Sample Oracle USM Boot Parameters.................................................................................................... 46
Boot Parameter Definitions..................................................................................................................... 46
Boot Parameter Changes......................................................................................................................... 48
Acme Packet 6000 Boot Parameters....................................................................................................... 49
Setting Up System Basics....................................................................................................................................51
New System Prompt................................................................................................................................51
Using the Oracle USM Image............................................................................................................................. 51
Software Images (USM/CSM)................................................................................................................ 51
Obtaining a New Image...........................................................................................................................51
Copy an Image to the Oracle USM using SFTP..................................................................................... 51
System Image Filename.......................................................................................................................... 52
Booting an Image on Your Oracle USM............................................................................................................. 52
Booting from Flash Memory...................................................................................................................52
Booting from an External Device............................................................................................................53
Provisioning Entitlements................................................................................................................................... 53
Entitlements Configuration..................................................................................................................... 55
Keyed Licenses and Provisioned Entitlements Compatibility................................................................ 55
High Availability (HA) Pair Licensing................................................................................................... 57
RADIUS Authentication..................................................................................................................................... 63
PAP Handshake....................................................................................................................................... 65
CHAP Handshake....................................................................................................................................65
MS-CHAP-v2 Handshake....................................................................................................................... 66
Management Protocol Behavior..............................................................................................................67
RADIUS Authentication Configuration..................................................................................................67
TACACS+ AAA..................................................................................................................................................69
TACACS+ Introduction.......................................................................................................................... 69
TACACS+ Authentication...................................................................................................................... 70
TACACS+ Authorization........................................................................................................................ 79
TACACS+ Accounting............................................................................................................................84
TACACS+ Configuration........................................................................................................................92
Customizing Your ACLI Settings....................................................................................................................... 95
Disabling the Second Login Prompt....................................................................................................... 95
Persistent ACLI more Parameter.............................................................................................................96
Customized Login Banner.......................................................................................................................96
Oracle® Communications Unified Session Manager
3
3 System Configuration.................................................................... 97
General System Information............................................................................................................................... 97
System Identification...............................................................................................................................97
Connection Timeouts...............................................................................................................................97
Configuring General System Information...........................................................................................................98
System Identification...............................................................................................................................98
Configuring Connection and Debug Logging Timeouts......................................................................... 99
Acme Packet 6300 Physical Interfaces............................................................................................................... 99
Acme Packet 4500 Physical Interfaces............................................................................................................. 100
Network Media Interfaces..................................................................................................................... 100
Network Management Interfaces.......................................................................................................... 101
Before You Configure....................................................................................................................................... 101
Physical Interface Configuration.......................................................................................................................102
Phy Link Redundancy (USM)...........................................................................................................................103
Caveats.................................................................................................................................................. 103
Phy Link Redundancy Configuration....................................................................................................103
Interface Utilization Graceful Call Control Monitoring and Fault Management..............................................104
Calculation Overview............................................................................................................................104
Alarms................................................................................................................................................... 104
Alarm Configuration............................................................................................................................. 105
Network Interfaces............................................................................................................................................ 106
IP Configuration.................................................................................................................................... 106
Network Interface Configuration.......................................................................................................... 107
Required SIP Configuration.............................................................................................................................. 109
Enabling SIP-Config............................................................................................................................. 110
SIP Interfaces.........................................................................................................................................110
Digest Authentication with SIP............................................................................................................. 118
IP Identification (ID) Field................................................................................................................................122
IP Identification Field Configuration.................................................................................................... 122
SNMP................................................................................................................................................................ 122
Overview............................................................................................................................................... 122
Configuring SNMP........................................................................................................................................... 123
SNMP Configuration Overview............................................................................................................123
SNMP Configuration.............................................................................................................................123
Media Supervision Traps.......................................................................................................................127
Syslog and Process Logs................................................................................................................................... 127
Overview............................................................................................................................................... 127
Syslog and Process Logs Configuration............................................................................................................127
Syslog Configuration.............................................................................................................................128
Process Log Configuration....................................................................................................................128
Host Routes....................................................................................................................................................... 129
Host Routes Example............................................................................................................................ 129
Host Route Configuration..................................................................................................................... 129
Source-based Routing........................................................................................................................................130
Source-based Routing Configuration.................................................................................................... 130
Setting Holidays in Local Policy.......................................................................................................................130
Holidays Configuration......................................................................................................................... 130
Enhanced Control of UDP and TCP Ports........................................................................................................ 131
Port 111 Configuration.......................................................................................................................... 131
Port 3000 and 3001 Configuration........................................................................................................ 132
DNS Transaction Timeout.................................................................................................................................132
Retransmission Logic............................................................................................................................ 132
DNS Transaction Timeout Configuration............................................................................................. 133
DNS Server Status via SNMP............................................................................................................... 133
4
Oracle® Communications Unified Session Manager
Persistent Protocol Tracing................................................................................................................................134
About Persistent Protocol Tracing.........................................................................................................134
About the Logs...................................................................................................................................... 134
Persistent Protocol Tracing Configuration............................................................................................ 135
System Access Control......................................................................................................................................135
Adding an ACL for the Management Interface.....................................................................................136
Notes on Deleting System ACLs...........................................................................................................136
System TCP Keepalive Settings........................................................................................................................136
System TCP Keepalive Configuration.................................................................................................. 137
Configurable TCP Timers................................................................................................................................. 137
Configuring TCP Connection Establishment........................................................................................ 138
Configuring TCP Data Retransmission.................................................................................................138
Timer for Idle Connections................................................................................................................... 139
Historical Data Recording (HDR).....................................................................................................................140
RAMdrive Log Cleaner.....................................................................................................................................140
Applicable Settings................................................................................................................................140
Clean-Up Procedure.............................................................................................................................. 140
Clean-Up Frequency..............................................................................................................................141
RAMdrive Log Cleaner Configuration................................................................................................. 141
Configurable Alarm Thresholds and Traps....................................................................................................... 142
SNMP Traps.......................................................................................................................................... 143
Alarm Thresholds Configuration...........................................................................................................144
Alarm Synchronization......................................................................................................................................144
Caveats.................................................................................................................................................. 145
Alarm Synchronization Configuration.................................................................................................. 145
Accounting Configuration.................................................................................................................................145
Stream Control Transfer Protocol Overview.....................................................................................................146
SCTP Packets........................................................................................................................................ 146
SCTP Terminology................................................................................................................................146
SCTP Message Flow............................................................................................................................. 147
Congestion Control................................................................................................................................148
Multi-Streaming.................................................................................................................................... 148
Delivery Modes..................................................................................................................................... 149
Multi-Homing........................................................................................................................................149
Multi-Homing and Path Diversity.........................................................................................................150
Monitoring Failure Detection and Recovery.........................................................................................150
Configuring SCTP Support for SIP...................................................................................................................151
Configuring an SCTP SIP Port..............................................................................................................151
Configuring the Realm.......................................................................................................................... 152
Configuring Session Agents..................................................................................................................152
Setting SCTP Timers and Counters.......................................................................................................153
Example Configurations........................................................................................................................158
IPV6 Address Configuration............................................................................................................................. 160
Access Control...................................................................................................................................... 161
Host Route.............................................................................................................................................161
Local Policy...........................................................................................................................................161
Network Interface..................................................................................................................................161
ENUM Server........................................................................................................................................162
Realm Configuration............................................................................................................................. 162
Session Agent........................................................................................................................................ 162
SIP Configuration..................................................................................................................................162
SIP Interface SIP Ports.......................................................................................................................... 162
Steering Pool......................................................................................................................................... 162
System Configuration............................................................................................................................162
IPv6 Support for Management and Telemetry.................................................................................................. 163
IPv6 Default Gateway....................................................................................................................................... 163
Oracle® Communications Unified Session Manager
5
IPv6 Link Local Addresses............................................................................................................................... 163
Network Interfaces and IPv6.............................................................................................................................164
IPv6 Reassembly and Fragmentation Support.................................................................................................. 164
Access Control List Support..............................................................................................................................165
Data Entry..............................................................................................................................................165
DNS Support..................................................................................................................................................... 165
Homogeneous Realms.......................................................................................................................................166
Parent-Child Network Interface Mismatch........................................................................................... 166
Address Prefix-Network Interface Mismatch........................................................................................166
RADIUS Support for IPv6................................................................................................................................ 166
Supporting RADIUS VSAs...................................................................................................................166
4 Realms and Nested Realms.......................................................... 169
Overview........................................................................................................................................................... 169
About Realms and Network Interfaces................................................................................................. 170
About the SIP Home Realm.................................................................................................................. 170
About Realms and Other Oracle USM Functions................................................................................. 170
Realms............................................................................................................................................................... 170
Before You Configure........................................................................................................................... 170
Realm Configuration............................................................................................................................. 171
QoS Measurement................................................................................................................................. 172
QoS Marking......................................................................................................................................... 173
Address Translation Profiles................................................................................................................. 173
DNS Servers.......................................................................................................................................... 173
DoS ACL Configuration....................................................................................................................... 173
Enabling RTP-RTCP UDP Checksum Generation................................................................................173
Aggregate Session Constraints Per Realm............................................................................................ 174
UDP Checksum Generation Configuration...........................................................................................174
Nested Realms...................................................................................................................................................174
Configuring Nested Realms.................................................................................................................. 176
Parent and Child Realm Configuration................................................................................................. 176
Aggregate Session Constraints Nested Realms.....................................................................................177
Realm-Based Packet Marking........................................................................................................................... 178
About TOS DiffServ..............................................................................................................................178
Packet Marking for Media.....................................................................................................................179
Configuring Packet Marking by Media Type........................................................................................179
Signaling Packet Marking Configuration..............................................................................................180
Using Class Profile for Packet Marking................................................................................................182
Differentiated Services for DNS and ENUM........................................................................................182
Differentiated Services for DNS and ENUM Configuration................................................................ 183
SIP-SDP DCSP Marking ToS Bit Manipulation...............................................................................................184
ToS Bit Manipulation Configuration.....................................................................................................184
DSCP Marking for MSRP and Media Over TCP..............................................................................................185
SDP Alternate Connectivity.............................................................................................................................. 186
SDP Alternate Connectivity Configuration...........................................................................................186
Steering Pools....................................................................................................................................................187
Configuration Overview........................................................................................................................187
Steering Pool Configuration..................................................................................................................188
Multiple Interface Realms................................................................................................................................. 189
Steering Pool Port Allocation................................................................................................................190
Network Interface Configuration.......................................................................................................... 191
Media over TCP................................................................................................................................................ 192
TCP Bearer Conditions......................................................................................................................... 192
TCP Port Selection................................................................................................................................ 193
TCP Port Configuration.........................................................................................................................197
6
Oracle® Communications Unified Session Manager
Restricted Media Latching................................................................................................................................ 198
About Latching......................................................................................................................................198
Restricted Latching Configuration........................................................................................................ 199
Media Release Across SIP Network Interfaces.................................................................................................200
Example.................................................................................................................................................200
Media Release Configuration................................................................................................................201
Media Release Behind the Same IP Address.................................................................................................... 202
Additional Media Management Options............................................................................................... 202
Configuring Media Release Behind the Same IP Address....................................................................202
Bandwidth CAC for Media Release..................................................................................................................203
Bandwidth CAC Configuration.............................................................................................................203
Media Release between Endpoints with the Same IP Address......................................................................... 203
Media Release Configuration................................................................................................................203
Media Release Behind the Same NAT IP Address............................................................................................204
Media Release Configuration................................................................................................................204
Codec Reordering..............................................................................................................................................205
Preferred Codec Precedence..................................................................................................................205
Codec Reordering Configuration.......................................................................................................... 205
Media Profiles Per Realm..................................................................................................................................207
Call Admission Control and Policing....................................................................................................207
Media Profile Configuration................................................................................................................. 208
Multiple Media Profiles.....................................................................................................................................209
Use Case 1............................................................................................................................................. 209
Use Case 2............................................................................................................................................. 209
Multiple Media Profiles Configuration................................................................................................. 209
SIP Disable Media Inactivity Timer for Calls Placed on Hold......................................................................... 210
Media Inactivity Timer Configuration.................................................................................................. 210
Peer-to-Peer MSRP TCP Stitching....................................................................................................................211
5 Oracle USM Supporting the IMS Core........................................... 213
General Description...........................................................................................................................................213
Message Authentication for SIP Requests........................................................................................................ 213
User Authorization............................................................................................................................................ 213
UAR/UAA Transaction......................................................................................................................... 214
SIP Digest User Authentication........................................................................................................................ 214
Authentication via MAR/MAA.............................................................................................................214
SIP Authentication Challenge............................................................................................................... 214
SIP Authentication Response................................................................................................................ 215
Oracle USM Authentication Check.......................................................................................................215
IMS-AKA Support............................................................................................................................................ 216
Authentication Sequence - Registration................................................................................................ 216
Outside the Core....................................................................................................................................217
Authentication Success..........................................................................................................................217
Authentication Failure...........................................................................................................................218
Synchronization.....................................................................................................................................218
Optional IMS-AKA Configuration....................................................................................................... 218
Oracle USM as Registrar...................................................................................................................................219
New Registration...................................................................................................................................219
Releasing Unregistered Users............................................................................................................... 219
Limiting AOR Contacts.....................................................................................................................................220
HSS Server Assignment.................................................................................................................................... 220
Server Assignment Messages................................................................................................................221
Register Refresh.................................................................................................................................... 221
Entry Unregistration.............................................................................................................................. 222
User Registration based on Reg-ID and Instance-ID (RFC 5626)....................................................................222
Oracle® Communications Unified Session Manager
7
reREGISTER Example..........................................................................................................................223
Outbound Registration Binding Processing.......................................................................................... 223
Wildcarded PUID Support.................................................................................................................... 223
ACLI Instructions..............................................................................................................................................224
home subscriber server..........................................................................................................................224
SIP Authentication Profile.....................................................................................................................224
SIP Interface.......................................................................................................................................... 225
SIP Registrar..........................................................................................................................................225
Maximum Number of Contacts.............................................................................................................226
Response to Exceeding Maximum Contacts......................................................................................... 226
SIP Registration Event Package Support.......................................................................................................... 227
SUBSCRIBE Processing.......................................................................................................................227
SUBSCRIBE REFRESH Requests....................................................................................................... 228
Reg Event NOTIFY Messages.............................................................................................................. 228
Reducing NOTIFY Traffic.................................................................................................................... 229
Configuring Registration Event Package.............................................................................................. 229
Registration Event Profile Configuration..............................................................................................229
Message Routing............................................................................................................................................... 230
Registrar Routing.................................................................................................................................. 231
Default Egress Realm............................................................................................................................231
RX Interface Features............................................................................................................................231
ACLI Instructions..................................................................................................................................231
Tel-URI Resolution........................................................................................................................................... 232
Number Lookup Triggers...................................................................................................................... 232
Actions Based on Lookup Results.........................................................................................................232
Primary and Secondary ENUM Configuration..................................................................................... 233
HSS Initiated User Profile Changes.................................................................................................................. 234
Licensing and Database Registration Limits.....................................................................................................234
Database Registration Limit Alarm.......................................................................................................234
3GPP Compliance............................................................................................................................................. 235
P-Asserted-Id in Requests and Dialogs................................................................................................. 235
P-Associated-URI in 200 OK................................................................................................................235
Other Diameter Cx Configuration.....................................................................................................................236
Host and Realm AVP Configuration for Cx.......................................................................................... 236
ACLI Instructions..................................................................................................................................236
Initial Filter Criteria (IFC).................................................................................................................................236
IFC Evaluation...................................................................................................................................... 236
SIP Registration.....................................................................................................................................237
SIP Call................................................................................................................................................. 237
Evaluating Session Case in the P-Served-User Header.........................................................................237
Supported Sessioncase and Registration State...................................................................................... 238
Additional Options................................................................................................................................ 238
IFC Support for Unregistered Users..................................................................................................................239
UE-terminating requests to an unregistered user.................................................................................. 239
Caching the Downloaded IFC............................................................................................................... 240
Optimizing IFC Updates....................................................................................................................... 240
Push Profile Request (PPR) updates..................................................................................................... 240
ACLI Instructions..............................................................................................................................................240
SIP Registrar..........................................................................................................................................240
SIP Registrar..........................................................................................................................................241
Shared and Default iFCs....................................................................................................................................241
SiFC Usage............................................................................................................................................242
DiFC Usage........................................................................................................................................... 242
SiFC/DiFC File Example...................................................................................................................... 242
iFC Execution Order............................................................................................................................. 243
Refreshing SiFC and DiFC Files...........................................................................................................243
8
Oracle® Communications Unified Session Manager
SiFC and DiFC Configuration...............................................................................................................243
Distinct and Wildcarded Public Service Identity (PSI) Support....................................................................... 244
Configuring SIP Ping OPTIONS Support.........................................................................................................244
Redundancy and Load Balancing with HSS Servers........................................................................................ 245
About HSS Groups................................................................................................................................245
Connection Failure Detection................................................................................................................246
6 Routing with Local Policy ............................................................ 249
Session Agents Session Groups and Local Policy............................................................................................ 249
About Session Agents....................................................................................................................................... 249
Session Agent Groups....................................................................................................................................... 250
Request URI Construction as Forwarded to SAG-member Session Agent.......................................... 251
SIP Session Agent Group Recursion.....................................................................................................251
SIP Session Agents............................................................................................................................................252
Session Agent Status Based on SIP Response...................................................................................... 252
SIP Session Agent Continuous Ping..................................................................................................... 253
About Local Policy............................................................................................................................................254
Routing Calls by Matching Digits.........................................................................................................254
Route Preference................................................................................................................................... 255
DTMF-Style URI Routing.................................................................................................................... 255
SIP Routing....................................................................................................................................................... 256
Limiting Route Selection Options for SIP............................................................................................ 256
About Loose Routing............................................................................................................................ 256
About the Ingress Realm....................................................................................................................... 256
About the Egress Realm........................................................................................................................ 256
About SIP Redirect................................................................................................................................258
SIP Method Matching and To Header Use for Local Policies.............................................................. 258
Load Balancing..................................................................................................................................................260
Configuring Routing..........................................................................................................................................261
Configuration Prerequisite.................................................................................................................... 261
Configuration Order.............................................................................................................................. 261
Routing Configuration...........................................................................................................................261
SIP Session Agent DNS-SRV Load Balancing................................................................................................. 274
Session Agent DNS-SRV Load Balancing Configuration.................................................................... 275
Answer to Seizure Ratio-Based Routing...........................................................................................................275
ASR Constraints Configuration.............................................................................................................276
ENUM Lookup..................................................................................................................................................277
How ENUM Works............................................................................................................................... 277
About the Oracle USM ENUM Functionality.......................................................................................278
Custom ENUM Service Type Support.................................................................................................. 279
ENUM Failover and Query Distribution...........................................................................................................279
ENUM Query Distribution....................................................................................................................279
Failover to New enum-config................................................................................................................279
ENUM Server Operation States............................................................................................................ 279
Server Availability Monitoring............................................................................................................. 280
ENUM Server IP Address and Port.......................................................................................................280
Unapplicable SNMP Traps and Objects................................................................................................280
IPv6 ENUM SNMP Traps and Objects.................................................................................................280
Caching ENUM Responses................................................................................................................... 282
Source URI Information in ENUM Requests........................................................................................282
Operation Modes................................................................................................................................... 282
ENUM Configuration............................................................................................................................284
Configuring the Local Policy Attribute.............................................................................................................286
Local Policy Example........................................................................................................................... 287
CNAM Subtype Support for ENUM Queries................................................................................................... 287
Oracle® Communications Unified Session Manager
9
CNAM Unavailable Response.............................................................................................................. 288
SIP Profile Inheritance.......................................................................................................................... 288
CNAM Subtype Support Configuration................................................................................................288
Using the Local Route Table (LRT) for Routing.............................................................................................. 288
Local Route Table (LRT) Performance................................................................................................. 289
Local Routing Configuration.................................................................................................................289
LRT Entry Matching............................................................................................................................. 290
LRT String Lookup........................................................................................................................................... 291
LRT String Lookup Configuration........................................................................................................ 291
Directed Egress Realm from LRT ENUM........................................................................................................ 292
Directed Egress Realm Configuration...................................................................................................292
SIP Embedded Route Header............................................................................................................................ 293
SIP Embedded Route Header Configuration.........................................................................................293
LRT Lookup Key Creation................................................................................................................................293
Arbitrary LRT Lookup Key...................................................................................................................293
Hidden Headers for HMR and LRT lookup.......................................................................................... 294
Compound Key LRT Lookup................................................................................................................294
Retargeting LRT ENUM-based Requests......................................................................................................... 294
Re-targeting LRT ENUM-based Requests Configuration.....................................................................295
Recursive ENUM Queries.................................................................................................................................295
Recursive ENUM Queries Configuration............................................................................................. 296
Multistage Local Policy Routing.......................................................................................................................296
Routing Stages.......................................................................................................................................296
Network Applications............................................................................................................................296
Multistage Routing Conceptual Example..............................................................................................297
Multistage Routing Example 2..............................................................................................................297
Customizing Lookup Keys....................................................................................................................299
Multistage Routing Lookup Termination.............................................................................................. 300
Multistage Local Policy Routing Configuration................................................................................... 300
Maintenance and Troubleshooting........................................................................................................ 301
Routing Based on UA Capabilities................................................................................................................... 301
UE Capabilities......................................................................................................................................302
Registering Capabilities at the Oracle USM......................................................................................... 302
Preferential Routing.............................................................................................................................. 302
Explicit Feature Preference................................................................................................................... 302
The “require” and explicit Feature Tag Parameters.............................................................................. 303
Implicit Feature Preference................................................................................................................... 303
Supporting Media Sessions Established via ICE.............................................................................................. 303
Configuring Support for ICE.............................................................................................................................304
Routing-based RN and CIC...............................................................................................................................305
Routing-based RN Configuration..........................................................................................................306
Codec Policies for SIP.......................................................................................................................................306
Relationship to Media Profiles.............................................................................................................. 307
Manipulation Modes..............................................................................................................................307
In-Realm Codec Manipulation.............................................................................................................. 308
Codec Policy Configuration.................................................................................................................. 308
QoS Based Routing........................................................................................................................................... 310
Management.......................................................................................................................................... 310
QoS Contraints Configuration...............................................................................................................311
7 ENUM Based Oracle USM.............................................................. 313
Message Authentication for SIP Requests........................................................................................................ 313
Credential Retrieval...........................................................................................................................................313
User Authentication Query....................................................................................................................314
SIP Digest User Authentication........................................................................................................................ 314
10
Oracle® Communications Unified Session Manager
SIP Authentication Challenge............................................................................................................... 314
Authentication Header Elements...........................................................................................................314
SIP Authentication Response................................................................................................................ 314
Oracle USM Authentication Check.......................................................................................................314
Oracle USM as Registrar...................................................................................................................................315
DDNS Update to User Subscriber Database......................................................................................... 315
ENUM Database Correlation................................................................................................................ 315
Register Refresh.................................................................................................................................... 316
Limiting AOR Contacts.....................................................................................................................................317
User Registration based on Reg-ID and Instance-ID (RFC 5626)....................................................................318
reREGISTER Example..........................................................................................................................318
Outbound Registration Binding Processing.......................................................................................... 318
ENUM Database Update....................................................................................................................... 318
NAPTR Update Format.........................................................................................................................319
Oracle USM Licensing......................................................................................................................................319
ACLI Instructions..............................................................................................................................................319
ENUM Configuration............................................................................................................................319
SIP Authentication Profile.....................................................................................................................320
SIP Registrar..........................................................................................................................................320
Maximum Number of Contacts.............................................................................................................321
Response to Exceeding Maximum Contacts......................................................................................... 321
Update to ENUM Database on Endpoint Connection Loss.............................................................................. 321
Connection Reuse..................................................................................................................................322
Unreachability Determination............................................................................................................... 322
Registration Cache and User Database Removal.................................................................................. 323
ACLI Instructions..................................................................................................................................323
OAuth 2.0 Support............................................................................................................................................ 325
OAuth Operation................................................................................................................................... 325
Configuring OAuth Support..................................................................................................................326
Enabling the SPL Plug-in...................................................................................................................... 326
Configuring the Plug-in Option.............................................................................................................327
Message Routing............................................................................................................................................... 328
Registrar Routing.................................................................................................................................. 328
Default Egress Realm............................................................................................................................328
Segmentation of ENUM Zones......................................................................................................................... 329
Configuring Support for DDNS Server Caching.................................................................................. 330
Tel-URI Resolution........................................................................................................................................... 331
Number Lookup Triggers...................................................................................................................... 331
Actions Based on Lookup Results.........................................................................................................331
Primary and Secondary ENUM Configs............................................................................................... 332
Licensing and Database Registration Limits.....................................................................................................333
Database Registration Limit Alarm.......................................................................................................333
Extended ENUM Record Length...................................................................................................................... 333
NAPTR and TXT Record Creation and Association............................................................................ 333
NAPTR Record Format.........................................................................................................................334
TXT Record Retrieval........................................................................................................................... 334
Requirements.........................................................................................................................................334
SIP User Parts - RFC 3261 Character Set Support........................................................................................... 334
Encoding Alpha-Numerics.................................................................................................................... 334
Multiple DNS Zone Support................................................................................................................. 335
Alpha-Numeric Name Support..............................................................................................................335
Configuring SIP Ping OPTIONS Support.........................................................................................................335
8 Local Subscriber Tables............................................................... 337
Local Subscriber Table...................................................................................................................................... 337
Oracle® Communications Unified Session Manager
11
LST Runtime Execution........................................................................................................................337
LST Configuration................................................................................................................................ 337
ACLI Instructions..............................................................................................................................................338
LST Table.............................................................................................................................................. 338
SIP authentication profile......................................................................................................................338
LST Redundancy for HA Systems........................................................................................................ 338
Reloading the LST.................................................................................................................................339
LST File Compression...........................................................................................................................339
LST File Format.................................................................................................................................... 339
LST Subscriber Hash and Encryption................................................................................................... 339
9 Third Party Registration...............................................................341
Third Party Registrations via iFCs.................................................................................................................... 342
Embedded REGISTER..........................................................................................................................342
ACLI Instructions - Third Party Registration via iFCs..................................................................................... 342
Session Agent........................................................................................................................................ 342
SIP Registrar..........................................................................................................................................343
Third Party Registration via ACLI Configuration............................................................................................ 343
Third Party Registration Server States.................................................................................................. 344
Third Party Registration Expiration...................................................................................................... 344
Defining Third Party Servers................................................................................................................ 345
ACLI Instructions - Third Party Server Configuration..................................................................................... 345
Third Party Registrar............................................................................................................................. 345
SIP Registrar..........................................................................................................................................345
10 Oracle USM Supporting the IMS Edge........................................ 347
Access Border Functions...................................................................................................................................347
P-CSCF Functions.................................................................................................................................347
A-BGF Functions.................................................................................................................................. 348
Resource and Admission Control (RACS) Functions...........................................................................348
IMS Interconnect Border Functions.................................................................................................................. 349
Oracle USM Access Interface Configuration....................................................................................................349
Wildcard PUI Introduction................................................................................................................................ 349
Wildcard PUI Message Flows............................................................................................................... 350
IMS Support for Private Header Extensions for 3GPP..................................................................................... 351
P-Associated-URI Header..................................................................................................................... 351
P-Asserted-Identity Header................................................................................................................... 351
P-Asserted-Identity Header Configuration............................................................................................352
P-Called-Party-ID Header..................................................................................................................... 353
P-Early-Media SIP Header Support...................................................................................................... 353
P-Visited-Network-ID Header...............................................................................................................360
P-Visited-Network-ID Header Handling for SIP Interfaces Configuration.......................................... 360
Second P-Asserted-Identity Header for Emergency Calls.................................................................... 360
Temporary Public User Identities and Multi-SIM Scenarios............................................................................ 362
Old Behavior......................................................................................................................................... 362
New Behavior........................................................................................................................................363
Configuring SIP Interface with reg-via-key and reg-via-match............................................................364
IMS-AKA..........................................................................................................................................................365
Requirements.........................................................................................................................................365
Monitoring.............................................................................................................................................365
ACLI Instructions and Examples.......................................................................................................... 365
IPSec IMS-AKA................................................................................................................................................368
Sample IMS-AKA Configuration......................................................................................................... 368
Sample Security Policy Configuration.................................................................................................. 368
12
Oracle® Communications Unified Session Manager
Sec-Agree.......................................................................................................................................................... 369
TLS Session Setup During Registration................................................................................................370
SEC-agree Configuration...................................................................................................................... 373
IMS AKA over TCP..........................................................................................................................................373
IMS-AKA Secure Call Registration over TCP..................................................................................... 373
IMS-AKA Call Establishment over TCP.............................................................................................. 375
SIP SUBSCRIBE and NOTIFY over TCP IMS-AKA......................................................................... 375
IMS-AKA Change Client Port.......................................................................................................................... 375
Protected Ports.......................................................................................................................................376
IMS-AKA Change Client Port Configuration.......................................................................................377
SIP IMS P-CSCF P-Asserted Identity in Responses.........................................................................................378
Important Notes.....................................................................................................................................378
SIP IMS P-CSCF P-Asserted Identity in Responses Configuration..................................................... 378
E-CSCF Support................................................................................................................................................378
Service URN Support............................................................................................................................379
E-CSCF Configuration Architecture..................................................................................................... 379
E-CSCF Configuration.......................................................................................................................... 380
Maintenance and Troubleshooting........................................................................................................ 381
2774 - Provisioning of SIP Signaling Flow Information.................................................................................. 381
Initial Registration.................................................................................................................................382
Register Refresh.................................................................................................................................... 383
De-Registration..................................................................................................................................... 383
Failure Response to Re-Register........................................................................................................... 383
Provisioning SIP Signaling Flows Configuration................................................................................. 383
Troubleshooting.....................................................................................................................................384
show ext-band-mgr................................................................................................................................384
RTP and RTCP Bandwidth Calculation and Reporting.....................................................................................385
Max-Requested-Bandwidth-UL & Max-Requested-Bandwidth-DL AVPs.......................................... 385
RR-Bandwidth & RS-Bandwidth AVPs................................................................................................385
Flow-status AVP....................................................................................................................................385
2629 - IR.92 Compliance via SIP 380 Response.............................................................................................. 386
380 Response Format............................................................................................................................ 386
IR.92 Compliance Configuration.......................................................................................................... 387
IR.94 Support.................................................................................................................................................... 387
IR.94 Loss Of Voice Bearer.................................................................................................................. 388
Pooled Transcoding........................................................................................................................................... 389
Supported Codecs..................................................................................................................................390
Implementation Details......................................................................................................................... 391
Application Scenarios............................................................................................................................391
Configuration Requirements and Verification.......................................................................................394
ACLI Configuration.............................................................................................................................. 395
Monitoring P-CSCF—T-SBC Dialogs.................................................................................................. 396
Notes on the DIAMETER Rx Interface................................................................................................ 397
Accounting............................................................................................................................................ 397
Dynamic Sessions Agents for Home-Remote S-CSCF Liveliness................................................................... 397
Discovery...............................................................................................................................................397
Creation................................................................................................................................................. 398
Deletion................................................................................................................................................. 398
How to Wildcard a Session Agent.........................................................................................................399
Enabling the Global SIP Configuration for Dynamic Session Agents..................................................399
Enhanced eSRVCC Call Continuity..................................................................................................................400
Handsets and Session Continuity.......................................................................................................... 400
Anchors for Signaling and Media......................................................................................................... 400
Architectural View................................................................................................................................ 401
IMS Registration Details....................................................................................................................... 401
Originating Sessions for SRVCC with ATCF....................................................................................... 404
Oracle® Communications Unified Session Manager
13
Terminating Sessions for SRVCC with ATCF...................................................................................... 406
TS 24.237 Proposed Changes................................................................................................................408
SRVCC PS-CS Access Transfer............................................................................................................411
Accounting............................................................................................................................................ 419
External Bandwidth Management......................................................................................................... 419
ATCF Configuration..............................................................................................................................419
Emergency Access Transfer Function...............................................................................................................420
Enabling EATF Capability.................................................................................................................... 421
Monitoring EATF ATCF Sessions.........................................................................................................421
11 SIP Signaling Services............................................................... 423
About the Oracle USM and SIP........................................................................................................................ 423
Recurse 305 Only Redirect Action....................................................................................................................423
Redirect Action Process........................................................................................................................ 423
Redirect-Action Set to Proxy................................................................................................................ 424
Redirect-Action Set to Recurse............................................................................................................. 424
Redirect-Action Set to Recurse-305-Only............................................................................................ 425
Embedded Routes in Redirect Responses......................................................................................................... 426
SIP PRACK Interworking................................................................................................................................. 426
UAC-Side PRACK Interworking..........................................................................................................427
UAS-Side PRACK Interworking.......................................................................................................... 427
PRACK Interworking Configuration.................................................................................................... 428
Global SIP Timers............................................................................................................................................. 428
Overview............................................................................................................................................... 429
Timers Configuration............................................................................................................................ 429
SIP Timers Discreet Configuration................................................................................................................... 430
Session Timer Support...................................................................................................................................... 431
Call Flow Example................................................................................................................................431
SIP Per-User CAC.............................................................................................................................................432
Per User CAC Modes............................................................................................................................ 433
Per User CAC Sessions......................................................................................................................... 433
Per User CAC Bandwidth..................................................................................................................... 433
Notes on HA Nodes...............................................................................................................................433
SIP per User CAC Configuration..........................................................................................................433
SIP Per-Realm CAC.......................................................................................................................................... 434
SIP per Realm CAC Configuration....................................................................................................... 435
SIP Options Tag Handling.................................................................................................................................435
Overview............................................................................................................................................... 436
Configuration Overview........................................................................................................................436
SIP Option Tag Handling Configuration...............................................................................................436
Replaces Header Support.................................................................................................................................. 438
New SDP Parameters in INVITE with Replaces.................................................................................. 438
Early Dialog Replacement.....................................................................................................................439
INVITE with Replaces in Early Dialog Server Side.............................................................................439
Replace Header Configuration.............................................................................................................. 439
Debugging............................................................................................................................................. 440
SIP Options....................................................................................................................................................... 440
Overview............................................................................................................................................... 440
Global SIP Options................................................................................................................................440
SIP Interface Options............................................................................................................................ 447
SIP Session Agent Options................................................................................................................... 448
SIP Realm Options................................................................................................................................ 448
SIP Realm Options Configuration.........................................................................................................449
SIP Security.......................................................................................................................................................449
Denial of Service Protection..................................................................................................................450
14
Oracle® Communications Unified Session Manager
Configuration Overview........................................................................................................................450
SIP Unauthorized Endpoint Call Routing............................................................................................. 450
SIP NAT Function............................................................................................................................................. 451
Overview............................................................................................................................................... 451
About Headers.......................................................................................................................................453
SIP NAT Function Cookies................................................................................................................... 453
Configuration Overview........................................................................................................................455
SIP NAT Function Configuration..........................................................................................................457
SIP Realm Bridging...........................................................................................................................................460
About SIP NAT Bridging...................................................................................................................... 460
SIP NAT Bridge Configuration Scenarios.............................................................................................461
SIP NAT Bridge Configuration............................................................................................................. 462
Shared Session Agent............................................................................................................................464
SIP Hosted NAT Traversal (HNT).................................................................................................................... 464
About SIP HNT..................................................................................................................................... 464
Working with Multiple Domains...........................................................................................................468
HNT Configuration Overview...............................................................................................................468
HNT Configuration............................................................................................................................... 469
Endpoint-Initiated Keep-Alives........................................................................................................................ 472
Endpoint-Initiated Keep-Alive Negotiation.......................................................................................... 473
Connection Oriented Keep-Alives........................................................................................................ 474
Connectionless Keep-Alives................................................................................................................. 474
Enpoint-Initiated Keep-Alives Configuration....................................................................................... 476
SD-originated Keep-Alive Negotiation.............................................................................................................477
SD-Originated Keep-Alive Format....................................................................................................... 478
SD-Initiated Keep-Alives Configuration...............................................................................................478
Statistics.................................................................................................................................................479
SIP Registration Local Expiration.....................................................................................................................479
SIP Registration Local Expiration Configuration................................................................................. 479
Simultaneous TCP Connection and Registration Cache Deletion.................................................................... 480
Registration Cache Deletion Configuration.......................................................................................... 480
SIP HNT Forced Unregistration........................................................................................................................481
When to Use Forced Unregistration......................................................................................................481
Caution for Using Forced Unregistration..............................................................................................481
SIP HNT Forced Unregistration Configuration.................................................................................... 482
Adaptive HNT................................................................................................................................................... 482
Overview............................................................................................................................................... 482
Adaptive HNT Example........................................................................................................................482
Synchronize A-HNT Successful Timer to Standby...............................................................................483
Adaptive NHT Configuration................................................................................................................483
SIP IP Address Hiding and NATing in XML....................................................................................................484
Sample SIP NOTIFY with NATed XML.............................................................................................. 484
SIP Server Redundancy.....................................................................................................................................485
Overview............................................................................................................................................... 485
Configuration Overview........................................................................................................................485
SIP Server Redundancy Configuration................................................................................................. 486
Administratively Disabling a SIP Registrar...................................................................................................... 486
Considerations for Implicit Service Route Use.....................................................................................487
Manual Trigger Configuration.............................................................................................................. 487
Manual Trigger Confirmation............................................................................................................... 487
Surrogate Agent Refresh on Invalidate............................................................................................................. 488
Invalidate Registrations.........................................................................................................................488
Media Inactivity Timer Configuration.................................................................................................. 489
SIP Distributed Media Release..........................................................................................................................489
Overview............................................................................................................................................... 489
Overview of SIP DMR Configuration...................................................................................................491
Oracle® Communications Unified Session Manager
15
SIP DMR Configuration........................................................................................................................491
Add-On Conferencing....................................................................................................................................... 492
Overview............................................................................................................................................... 492
Add-on Conferencing Configuration.....................................................................................................494
SIP REFER Method Call Transfer.................................................................................................................... 494
Unsuccessful Transfer Scenarios...........................................................................................................495
Call Flows............................................................................................................................................. 495
SIP REFER Method Configuration.......................................................................................................497
REFER-Initiated Call Transfer..........................................................................................................................499
Supported Scenarios.............................................................................................................................. 499
REFER Source Routing.........................................................................................................................502
REFER Source Routing Configuration................................................................................................. 502
180 & 100 NOTIFY in REFER Call Transfers................................................................................................. 503
Sample Messages.................................................................................................................................. 505
180 and 100 NOTIFY Configuration.................................................................................................... 506
SIP REFER Re-Invite for Call Leg SDP Renegotiation................................................................................... 507
Scenario................................................................................................................................................. 507
Alterations to SIP REFER.................................................................................................................................507
Implementation Details......................................................................................................................... 507
SIP REFER with Replaces................................................................................................................................ 508
SIP REFER with Replaces Configuration.............................................................................................508
SIP REFER-to-BYE.......................................................................................................................................... 509
SIP Roaming..................................................................................................................................................... 509
Overview............................................................................................................................................... 509
Process Overview.................................................................................................................................. 510
SIP Roaming Configuration.................................................................................................................. 511
Embedded Header Support................................................................................................................................512
Embedded Header Support Configuration............................................................................................ 512
Static SIP Header and Parameter Manipulation................................................................................................ 512
Header Manipulation Rules...................................................................................................................513
Header Element Rules........................................................................................................................... 513
About SIP Header and Parameter Manipulation................................................................................... 513
HMR $LOCAL_PORT for Port Mapping.............................................................................................513
SIP Header and Parameter Manipulation Configuration.......................................................................513
SIP HMR (Header Manipulation Rules)........................................................................................................... 519
Guidelines for Header and Element Rules............................................................................................ 520
Precedence.............................................................................................................................................521
Duplicate Header Names.......................................................................................................................521
Performing HMR on a Specific Header................................................................................................ 521
Multiple SIP HMR Sets.........................................................................................................................521
MIME Support...................................................................................................................................... 522
Find and Replace All.............................................................................................................................522
Escaped Characters................................................................................................................................523
New Reserved Word..............................................................................................................................523
About the MIME Value Type................................................................................................................ 523
Back Reference Syntax......................................................................................................................... 524
Notes on the Regular Expression Library............................................................................................. 524
SIP Message-Body Separator Normalization........................................................................................525
SIP Header Pre-Processing HMR..........................................................................................................525
Best Practices........................................................................................................................................ 526
About Regular Expressions................................................................................................................... 526
Expression Building Using Parentheses................................................................................................528
SIP Manipulation Configuration........................................................................................................... 528
Configuration Examples........................................................................................................................535
Dialog-Matching Header Manipulation............................................................................................................ 554
About Dialog-Matching Header Manipulations....................................................................................554
16
Oracle® Communications Unified Session Manager
Built-In SIP Manipulations................................................................................................................... 556
Testing SIP Manipulations.................................................................................................................... 557
HMR Import-Export..........................................................................................................................................557
Exporting............................................................................................................................................... 557
Importing............................................................................................................................................... 558
Displaying Imports................................................................................................................................ 558
Using FTP to Move Files...................................................................................................................... 558
Removing Files......................................................................................................................................559
Unique HMR Regex Patterns and Other Changes............................................................................................ 559
Manipulation Pattern Per Remote Entity...............................................................................................559
Reject Action.........................................................................................................................................559
Log Action.............................................................................................................................................561
Changes to Storing Pattern Rule Values................................................................................................562
Removal of Restrictions........................................................................................................................ 562
Name Restrictions for Manipulation Rules........................................................................................... 562
New Value Restrictions......................................................................................................................... 563
Header Manipulation Rules for SDP.................................................................................................................563
Platform Support................................................................................................................................... 563
SDP Manipulation................................................................................................................................. 563
Regular Expression Interpolation..........................................................................................................567
Regular Expressions as Boolean Expressions....................................................................................... 568
Moving Manipulation Rules..................................................................................................................569
Rule Nesting and Management............................................................................................................. 570
ACLI Configuration Examples............................................................................................................. 570
Dialog Transparency......................................................................................................................................... 575
Overview............................................................................................................................................... 575
Dialog Transparency Configuration...................................................................................................... 575
Route Header Removal..................................................................................................................................... 575
Route Header Removal Configuration.................................................................................................. 576
SIP Via Transparency........................................................................................................................................ 576
SIP Via Transparency Configuration.....................................................................................................576
Symmetric Latching.......................................................................................................................................... 577
Symmetric Latching Configuration.......................................................................................................577
SIP Number Normalization............................................................................................................................... 578
Terminology.......................................................................................................................................... 578
Calls from IP Endpoints........................................................................................................................ 579
Calls from IP Peer Network.................................................................................................................. 579
SIP Number Normalization Configuration............................................................................................579
SIP Port Mapping.............................................................................................................................................. 580
About SIP Port Mapping....................................................................................................................... 580
How SIP Port Mapping Works.............................................................................................................. 581
About NAT Table ACL Entries............................................................................................................. 582
SIP Port Mapping Configuration...........................................................................................................583
SIP Port Mapping for TCP and TLS..................................................................................................... 585
SIP Configurable Route Recursion................................................................................................................... 586
Example 1..............................................................................................................................................586
Example 2..............................................................................................................................................587
SIP Route Recursion Configuration...................................................................................................... 588
SIP Event Package Interoperability...................................................................................................................589
SIP Event Package Interoperability Configuration............................................................................... 589
SIP Proxy Subscriptions....................................................................................................................................590
Topology Hiding....................................................................................................................................590
SIP Proxy Subscription Configuration.................................................................................................. 591
SIP REGISTER Forwarding After Call-ID Change..........................................................................................591
SIP REGISTER Forwarding Configuration.......................................................................................... 591
SIP Local Response Code Mapping..................................................................................................................592
Oracle® Communications Unified Session Manager
17
SIP Local Response Code Mapping Configuration.............................................................................. 592
Session Agent Ping Message Formatting..........................................................................................................594
Session Agent Ping Message Formatting Configuration...................................................................... 594
SIP Statuses to Q.850 Reasons..........................................................................................................................595
SIP-SIP Calls.........................................................................................................................................595
SIP-SIP Calls Configuration................................................................................................................. 596
Adding the Reason Header....................................................................................................................597
SIP Status.............................................................................................................................................. 597
Trunk Group URIs.............................................................................................................................................598
Terminology.......................................................................................................................................... 599
Trunk Group URI Parameters............................................................................................................... 599
Trunk Group URI Configuration...........................................................................................................603
Emergency Session Handling............................................................................................................................607
Emergency Session Handling Configuration Procedures..................................................................... 607
Emergency Session Handling Configuration........................................................................................ 608
Fraud Prevention............................................................................................................................................... 609
Fraud Prevention Configuration............................................................................................................609
SIP Early Media Suppression............................................................................................................................609
Example.................................................................................................................................................610
Early Media Suppression Support.........................................................................................................610
Call Signaling........................................................................................................................................ 611
Suppression Duration............................................................................................................................ 611
About the Early Media Suppression Rule............................................................................................. 611
Selective Early Media Suppression....................................................................................................... 611
SDP-Response Early Media Suppression..........................................................................................................615
SIP-Based Addressing...........................................................................................................................615
SDP-Based Addressing......................................................................................................................... 615
Configuring SDP-Response Early Media Suppression......................................................................... 616
SIP Duplicate SDP Suppression........................................................................................................................619
SIP Duplicate SDP Suppression Configuration.................................................................................... 619
SIP SDP Address Correlation............................................................................................................................620
SIP SDP Address Correlation Configuration Address Checking..........................................................620
SIP SDP Address Correlation Configuration Mismatch Status Code...................................................620
SIP SDP Address Correlation Configuration Enforcement Profile.......................................................621
SDP Insertion for (Re)INVITEs........................................................................................................................621
SDP Insertion for SIP INVITES........................................................................................................... 621
SDP Insertion for SIP ReINVITEs........................................................................................................622
SDP Insertion Configuration................................................................................................................. 623
Configuring SDP Insertion for SIP INVITEs........................................................................................623
Configuring SDP Insertion for SIP ReINVITEs................................................................................... 623
SDP Version Change without SDP Body Change.............................................................................................623
SDP Version Change Configuration......................................................................................................624
Restricted Media Latching................................................................................................................................ 624
About Latching......................................................................................................................................624
Restricted Latching Configuration........................................................................................................ 626
Enhanced SIP Port Mapping............................................................................................................................. 627
Anonymous Requests............................................................................................................................ 627
SIP Registration Via Proxy................................................................................................................................628
Considerations for Reg-Via-Key and Port Mapping............................................................................. 628
Request Routing.................................................................................................................................... 628
Dynamic Transport Protocol Change................................................................................................................ 629
Dynamic Transport Protocol Change Configuration.............................................................................629
SIP Privacy Extensions..................................................................................................................................... 629
Privacy Types Supported.......................................................................................................................630
Examples............................................................................................................................................... 630
Configuring SIP Privacy Extensions.....................................................................................................631
18
Oracle® Communications Unified Session Manager
SIP Registration Cache Limiting.......................................................................................................................632
About Registration Cache Additions Modifications and Removals..................................................... 633
Registration Cache Alarm Threshold.................................................................................................... 633
Notes on Surrogate Registration............................................................................................................633
Monitoring Information.........................................................................................................................633
SIP Registration Cache Limiting Configuration................................................................................... 634
SIP Registration Overload Protection............................................................................................................... 634
SIP Registration Overload Protection Configuration............................................................................635
SIP Instance ID in Registration Cache.............................................................................................................. 636
SIP Instance ID and the Registration Cache......................................................................................... 636
SIP Instance ID Configuration.............................................................................................................. 636
SIP Request Method Throttling.........................................................................................................................637
About Counters and Statistics............................................................................................................... 637
SIP Request Method Throttling Configuration..................................................................................... 638
SIP Delayed Media Update............................................................................................................................... 640
Delayed Media Update Disabled...........................................................................................................640
Delayed Media Update Enabled............................................................................................................641
SIP Delayed Media Update Configuration............................................................................................641
Expedited Call Leg Release for Preempted Hairpin Calls................................................................................ 641
Accounting Considerations................................................................................................................... 642
SIPconnect.........................................................................................................................................................642
Modifications to Registration Caching Behavior..................................................................................642
Configuring SIP Connect Support.........................................................................................................643
SIP Connect Configuration................................................................................................................... 643
SIP Registration Event Package Support.......................................................................................................... 644
Updating Expiration Values...................................................................................................................644
Contact Cache Linger Configuration.................................................................................................... 645
SIP Event Package for Registrations.................................................................................................................645
Applicable Standards.............................................................................................................................645
Call Flow............................................................................................................................................... 646
Notification Bodies................................................................................................................................647
SIP Event Package for Registrations Configuration............................................................................. 648
SIP Transport Selection.....................................................................................................................................648
SIP Transport Selection Configuration................................................................................................. 648
uaCSTA NAT Support.......................................................................................................................................649
Overview............................................................................................................................................... 649
SIP Packet Cable Multi-Media..........................................................................................................................650
Details....................................................................................................................................................651
Core-Side SDP Insertion Configuration................................................................................................652
SIP Method-Transaction Statistic Enhancements............................................................................................. 652
SIP Method Tracking Enhancements Configuration.............................................................................653
National Security and Emergency Preparedness for SIP.................................................................................. 653
Licensing............................................................................................................................................... 654
Matching by NMC and by RPH............................................................................................................ 654
Call Treatment....................................................................................................................................... 654
Generating Egress RPH.........................................................................................................................655
Media Treatment................................................................................................................................... 655
RPH Configuration................................................................................................................................656
E-CSCF Emergency Setting Precedence for NMC........................................................................................... 659
E-CSCF Emergency Configuration.......................................................................................................660
SIP TCP Connection Reuse...............................................................................................................................660
SIP TCP Connection Reuse Configuration........................................................................................... 661
SIP TCP Keepalive............................................................................................................................................661
SIP TCP Keepalive Configuration for Session Agents......................................................................... 662
SIP TCP Keepalive Configuration for SIP Interfaces........................................................................... 662
SIP Enforcement Profile and Allowed Methods............................................................................................... 663
Oracle® Communications Unified Session Manager
19
SIP Enforcement Profile Configuration................................................................................................ 663
Local Policy Session Agent Matching for SIP..................................................................................................664
Local Policy Session Agent Matching Configuration...........................................................................668
About Wildcarding................................................................................................................................ 668
Enforcement Profile Configuration with subscribe-event.....................................................................669
STUN Server..................................................................................................................................................... 670
About STUN Messaging....................................................................................................................... 670
STUN Server Functions on the Oracle USM........................................................................................ 671
RFC 3489 Procedures............................................................................................................................672
Monitoring.............................................................................................................................................672
STUN Server Configuration..................................................................................................................673
SIP ISUP Features............................................................................................................................................. 673
SIP Diversion to SIP-ISUP Interworking..............................................................................................673
SIP-ISUP Format Version Interworking................................................................................................675
Details....................................................................................................................................................675
HMR for SIP-ISUP............................................................................................................................... 676
SIP Session Timer Feature................................................................................................................................ 686
How the Session Timer Feature Works................................................................................................. 686
SIP Session Timer Configuration..........................................................................................................688
DTMF Conversion Processing.......................................................................................................................... 688
SIP-KPML to RFC 2833 Conversion for DTMF Events.................................................................................. 690
SIP KPML to RFC 2833 Negotiation................................................................................................... 690
RFC 2833 to SIP KPML Negotiation................................................................................................... 690
KPML-2833 Interworking on a SIP Interface Configuration............................................................... 690
LMSD SIP Call Progress Tone Interworking....................................................................................................691
LMSD Interworking Configuration.......................................................................................................691
SIP re-INVITE Suppression..............................................................................................................................691
SIP re-INVITE Suppression Configuration.......................................................................................... 692
RFC 4028 Session Timers................................................................................................................................. 692
Ingress Call Leg.....................................................................................................................................693
Egress Call Leg..................................................................................................................................... 693
Session Refreshes.................................................................................................................................. 694
305 Response to Registrations on Secondary Interfaces...................................................................................701
ACLI Instructions and Examples.......................................................................................................... 702
notify sipd offload-users........................................................................................................................702
show registration................................................................................................................................... 702
show registration sipd............................................................................................................................703
show sipd endpoint-ip........................................................................................................................... 703
SNMP Configuration.............................................................................................................................703
SNMP................................................................................................................................................................ 704
12 Number Translation................................................................... 707
About Number Translation................................................................................................................................707
Number Translation Implementation.................................................................................................... 707
Number Translation in SIP URIs.......................................................................................................... 708
Number Translation Configuration Overview...................................................................................................708
Translation Rules...............................................................................................................................................708
Translation Rules for Deleting Strings.................................................................................................. 709
Translation Rules for Adding Strings....................................................................................................709
Translation Rules for Replacing Strings................................................................................................709
Session Translation............................................................................................................................................709
Applying Session Translations.......................................................................................................................... 710
Session Agent........................................................................................................................................ 710
Realm.....................................................................................................................................................710
Number Translation Configuration................................................................................................................... 710
20
Oracle® Communications Unified Session Manager
Translation Rules................................................................................................................................... 711
Session Translation................................................................................................................................711
Number Translation Application...........................................................................................................712
Other Translations............................................................................................................................................. 712
FQDN Mapping.....................................................................................................................................712
13 Admission Control and QoS........................................................713
About Call Admission Control..........................................................................................................................713
Bandwidth-Based Admission Control...................................................................................................713
Session Capacity- and Rate-based Admission Control......................................................................... 714
CAC Policing and Marking for non-Audio non-Video Media..............................................................715
Bandwidth CAC Fallback Based on ICMP Failure...............................................................................715
Bandwidth CAC for Aggregate Emergency Sessions........................................................................... 716
Admission Control for Session Agents............................................................................................................. 717
Session Agents Admission Control Configuration............................................................................... 717
Session Agent Minimum Reserved Bandwidth.................................................................................................721
Session Agent Minimum Reserved Bandwidth Configuration............................................................. 721
Aggregate Session Constraints for SIP............................................................................................................. 722
Aggregate Session Constraints Configuration...................................................................................... 722
Applying Session Constraints in a SIP Interfaces................................................................................. 724
Configuring CAC Policing and Marking for non-Audio non-Video Media......................................... 724
Offerless Bandwidth CAC for SIP.................................................................................................................... 726
Offerless Bandwidth CAC for SIP Configuration.................................................................................726
Shared CAC for SIP Forked Calls.....................................................................................................................727
Bandwidth Sharing Scenarios............................................................................................................... 727
Bandwidth Sharing Configuration.........................................................................................................728
RADIUS Accounting Support...............................................................................................................729
Monitoring.............................................................................................................................................729
Conditional Bandwidth CAC for Media Release.............................................................................................. 729
About Conditional Bandwidth CAC for Media Release....................................................................... 729
Details and Conditions.......................................................................................................................... 729
Conditional Bandwidth CAC Configuration.........................................................................................731
CAC Utilization Statistics via SNMP............................................................................................................... 733
CAC utilization threshold trap on a session agent configuration......................................................................735
Configuring the CAC Utilization Thresholds - realm....................................................................................... 735
About QoS Reporting........................................................................................................................................736
Overview............................................................................................................................................... 736
Configuring QoS............................................................................................................................................... 738
QoS Configuration................................................................................................................................ 738
Network Management Controls........................................................................................................................ 739
Matching a Call to a Control Rule.........................................................................................................739
Call Handling Determination................................................................................................................ 739
Treatment Methods................................................................................................................................740
Priority Call Exemption from Policy Server Approval......................................................................... 740
Enhanced Call Gapping.........................................................................................................................741
Network Management Control Configuration...................................................................................... 741
3147 - Emergency Call Fallback....................................................................................................................... 744
Emergency Call Fallback Configuration............................................................................................... 744
Accounting Configuration for QoS................................................................................................................... 744
QoS Accounting Configuration.............................................................................................................744
Whitelists for SIP.............................................................................................................................................. 748
What is a Whitelist................................................................................................................................ 748
Whitelists Configuration....................................................................................................................... 748
Configuration Exception....................................................................................................................... 751
Verify Whitelist Configuration..............................................................................................................751
Oracle® Communications Unified Session Manager
21
How Whitelists Work............................................................................................................................ 751
Whitelist Learning.............................................................................................................................................752
Whitelist Learning Configuration......................................................................................................... 752
Rejected Messages Monitoring......................................................................................................................... 754
14 Static Flows............................................................................... 755
About Static Flows............................................................................................................................................ 755
IPv6 / IPv4 Translations.................................................................................................................................... 756
About Network Address Translation ALG........................................................................................................756
NAPT.....................................................................................................................................................756
TFTP......................................................................................................................................................757
Configuring Static Flows...................................................................................................................................757
Basic Static Flow Configuration Overview...........................................................................................757
Static Flow Configuration..................................................................................................................... 758
Example Configuration: Bidirectional Static Flows............................................................................. 760
15 High Availability Nodes.............................................................. 763
Overview........................................................................................................................................................... 763
Establishing Active and Standby Roles.................................................................................................764
Switchovers........................................................................................................................................... 764
State Transitions.................................................................................................................................... 765
HA Features...........................................................................................................................................765
Before Configuring a High Availability (HA) Pair........................................................................................... 767
HA Node Connections.......................................................................................................................................767
Virtual MAC Addresses........................................................................................................................ 770
Virtual MAC Address Configuration.................................................................................................... 770
HA Node Connections.......................................................................................................................................771
HA Node Connection Configuration.....................................................................................................771
HA Node Parameters.............................................................................................................................773
Synchronizing Configurations...........................................................................................................................776
Synchronize HA Peers...........................................................................................................................776
Using Configuration Checkpointing..................................................................................................... 777
Manually Checking Configuration Synchronization.............................................................................778
Media Interface Link Detection and Gateway Polling......................................................................................779
Media Interface Link Detection and Gateway Polling Configuration.................................................. 779
Media Interface Link Detection and Gateway Polling Configuration 2............................................... 780
Media State Checkpointing............................................................................................................................... 781
Media State Checkpointing Configuration............................................................................................781
HA Media Interface Keepalive..........................................................................................................................781
Impact to Boot-Up Behavior................................................................................................................. 782
HA Media Interface Keepalive Configuration...................................................................................... 782
RTC Notes......................................................................................................................................................... 782
HA......................................................................................................................................................... 782
Protocol-Specific Parameters and RTC.................................................................................................783
16 Security..................................................................................... 785
Security Overview.............................................................................................................................................785
Denial of Service Protection..............................................................................................................................786
Levels of DoS Protection...................................................................................................................... 787
About the Process..................................................................................................................................787
Trusted Path...........................................................................................................................................788
Untrusted Path....................................................................................................................................... 789
Static and Dynamic ACL Entry Limits................................................................................................. 790
22
Oracle® Communications Unified Session Manager
Dynamic Deny for HNT........................................................................................................................790
Host and Media Path Protection Process...............................................................................................790
Session Director Access Control...........................................................................................................790
Access Control Endpoint Classification Capacity and DoS..................................................................791
Media Access Control........................................................................................................................... 791
Host Path Traffic Management..............................................................................................................791
Traffic Promotion.................................................................................................................................. 791
Malicious Source Blocking................................................................................................................... 791
Blocking Actions...................................................................................................................................792
Protecting Against Session Agent Overloads........................................................................................792
ARP Flood Protection Enhancements................................................................................................... 792
Dynamic Demotion for NAT Devices................................................................................................... 792
Configuring DoS Security................................................................................................................................. 792
Configuration Overview........................................................................................................................793
Changing the Default Oracle USM Behavior........................................................................................793
Access Control List Configuration........................................................................................................794
Host Access Policing.............................................................................................................................796
Configuring ARP Flood Protection.......................................................................................................797
Access Control for a Realm...................................................................................................................797
Configuring Overload Protection for Session Agents...........................................................................799
DDoS Protection from Devices Behind a NAT.....................................................................................800
Media Policing.................................................................................................................................................. 802
Policing Methods...................................................................................................................................803
Configuration Notes.............................................................................................................................. 803
Media Policing Configuration for RTP Flows...................................................................................... 804
Media Policing Configuration for Static Flows.................................................................................... 805
RTP Payload Type Mapping..................................................................................................................805
ITU-T to IANA Codec Mapping...........................................................................................................806
SDP Anonymization..............................................................................................................................806
SDP Anonymization Configuration...................................................................................................... 806
Unique SDP Session ID........................................................................................................................ 807
Unique SDP Session ID Configuration................................................................................................. 807
TCP Synchronize Attack Prevention.................................................................................................................807
About SYN............................................................................................................................................ 807
Configuring TCP SYN Attack Prevention............................................................................................ 808
Transport Layer Security...................................................................................................................................808
The Oracle USM and TLS.....................................................................................................................809
TLS Features......................................................................................................................................... 809
Domestic and International Versions.....................................................................................................809
Supported Encryption............................................................................................................................810
TLS 1.1 and 1.2 Support....................................................................................................................... 810
4096 bit RSA Key Support....................................................................................................................811
Signaling Support.................................................................................................................................. 811
DoS Protection.......................................................................................................................................811
Endpoint Authentication........................................................................................................................812
Key Usage Control................................................................................................................................ 812
Configuring TLS............................................................................................................................................... 813
Process Overview.................................................................................................................................. 813
Configuring Certificates........................................................................................................................ 814
Configuring a TLS Profile.....................................................................................................................818
Applying a TLS Profile......................................................................................................................... 819
Reusing a TLS Connection....................................................................................................................819
Keeping Pinholes Open at the Endpoint................................................................................................819
Viewing Certificates.............................................................................................................................. 820
Host Certificate Retrieval via SNMP................................................................................................................ 821
Host Certificate Retrieval Configuration.............................................................................................. 821
Oracle® Communications Unified Session Manager
23
Denial of Service for TLS................................................................................................................................. 821
DoS for TLS Configuration...................................................................................................................822
TLS Session Caching........................................................................................................................................ 824
TLS Session Caching Configuration.....................................................................................................824
TLS Endpoint Certificate Data Caching........................................................................................................... 825
Inserting Customized SIP Headers in an Outgoing INVITE................................................................ 825
Validating the Request-URI Based on Certificate Information.............................................................827
TLS Endpoint Certificate Data Caching Configuration........................................................................ 828
Untrusted Connection Timeout for TCP and TLS............................................................................................ 829
Caveats.................................................................................................................................................. 829
Untrusted Connection Timeout Configuration for TCP and TLS......................................................... 829
Online Certificate Status Protocol.....................................................................................................................829
Caveats.................................................................................................................................................. 830
Online Certificate Status Protocol Configuration................................................................................. 830
Unreachable OCSR............................................................................................................................... 832
OCSR Access via FQDN...................................................................................................................... 833
Direct and Delegated Trust Models.......................................................................................................834
IPv6-IPv4 Internetworking................................................................................................................................836
TLS SRTP Decryption...........................................................................................................................837
SRTP MIKEY IPv6 Support................................................................................................................. 838
SRTP IPv4 IPv6 Internetworking..........................................................................................................838
Hardware Requirements........................................................................................................................ 839
Supported Topologies............................................................................................................................839
Configuration.........................................................................................................................................840
Key Exchange Protocols................................................................................................................................... 840
IKEv1 Protocol......................................................................................................................................840
IKEv1 Configuration.............................................................................................................................841
SDP Session Description Protocol........................................................................................................ 848
Licensing and Hardware Requirements................................................................................................ 849
Operational Modes................................................................................................................................ 850
SDES Configuration..............................................................................................................................851
ACLI Example Configurations............................................................................................................. 853
Modified ALCI Configuration Elements.............................................................................................. 858
Multimedia Internet KEYing Protocol.................................................................................................. 859
Protocol Overview.................................................................................................................................859
Licensing and Hardware Requirements................................................................................................ 861
Operational Modes................................................................................................................................ 861
MIKEY Configuration.......................................................................................................................... 862
ACLI Example Configurations............................................................................................................. 865
Modified ALCI Configuration Elements.............................................................................................. 870
Secure and Non-Secure Flows in the Same Realm........................................................................................... 871
Mode Settings in the Media Security Policy......................................................................................... 871
Security Associations for RTP and RTCP.............................................................................................875
Supporting UAs with Different SRTP Capabilities...............................................................................877
Refining Interoperability....................................................................................................................... 878
Multi-system Selective SRTP Pass-through......................................................................................................879
License Requirements........................................................................................................................... 879
Hardware Requirements........................................................................................................................ 879
Constraints.............................................................................................................................................879
Operational Overview........................................................................................................................... 880
Call Flows............................................................................................................................................. 880
Early Media........................................................................................................................................... 884
Multi-system Selective SRTP Pass-through with Media Release......................................................... 884
Multi-system Selective SRTP Pass-through Configuration.................................................................. 884
IPSec Support.................................................................................................................................................... 885
Supported Protocols.............................................................................................................................. 885
24
Oracle® Communications Unified Session Manager
IPSec Implementation........................................................................................................................... 886
Outbound Packet Processing................................................................................................................. 886
Inbound Packet Processing....................................................................................................................888
HA Considerations................................................................................................................................ 889
Packet Size Considerations................................................................................................................... 890
IPSec Application Example...................................................................................................................890
IPSec Configuration.............................................................................................................................. 891
Real-Time IPSec Process Control......................................................................................................... 894
Key Generation......................................................................................................................................894
IDS Reporting....................................................................................................................................................894
IDS Licensing........................................................................................................................................894
Basic Endpoint Demotion Behavior......................................................................................................895
Endpoint Demotion Reporting.............................................................................................................. 895
Endpoint Demotion SNMP Traps......................................................................................................... 896
Endpoint Demotion Syslog Message.................................................................................................... 897
Event Log Notification Demotion from Trusted to Untrusted.............................................................. 897
Endpoint Demotion Configuration........................................................................................................897
Endpoint Demotion due to CAC overage..............................................................................................898
Endpoint Demotion Configuration on CAC Failures............................................................................898
IDS Phase 2 (Advanced Reporting).................................................................................................................. 899
License Requirements........................................................................................................................... 899
Rejected SIP Calls................................................................................................................................. 899
CPU Load Limiting............................................................................................................................... 902
Denied Endpoints.................................................................................................................................. 902
Maintenance and Troubleshooting.................................................................................................................... 902
show sipd acls........................................................................................................................................902
17 Lawful Intercept........................................................................ 903
Recommendations............................................................................................................................................. 904
Interoperability Using X1 X2 X3......................................................................................................................904
18 External Policy Servers.............................................................. 905
Diameter-based External Policy Servers........................................................................................................... 905
Diameter Connection.............................................................................................................................905
HA Support............................................................................................................................................905
FQDN Support...................................................................................................................................... 905
IPv6 Support..........................................................................................................................................906
Diameter Heartbeat................................................................................................................................906
Diameter Failures.................................................................................................................................. 906
Application IDs and Modes...................................................................................................................906
IPv6 Support......................................................................................................................................................907
IPv6 Addresses in UTF-8 Format......................................................................................................... 907
Framed-IPv6-Prefix AVP...................................................................................................................... 907
Bandwidth Allocation Compensation for IPv6..................................................................................... 908
Diameter: RACF................................................................................................................................................908
Implementation Features....................................................................................................................... 908
Bandwidth Negotiation..........................................................................................................................909
Session Lifetime.................................................................................................................................... 909
Opening for RTCP Flows...................................................................................................................... 910
RACF-only AVPs.............................................................................................................................................. 910
Diameter AAR Query Post SDP Exchange...........................................................................................910
The Proxy Bit........................................................................................................................................ 910
Experimental-Result-Code AVP: RACF............................................................................................... 910
Transport-Class AVP............................................................................................................................. 910
Oracle® Communications Unified Session Manager
25
RACF and CLF AVPs....................................................................................................................................... 912
Frame-IP-Address AVP......................................................................................................................... 912
1637 - Diameter Destination Realm AVP............................................................................................. 912
Legacy Destination-Realm AVP Behavior............................................................................................913
Origin-Host AVP................................................................................................................................... 913
Wildcard Transport Protocol................................................................................................................. 913
Configuring Diameter-based RACF..................................................................................................................914
Diameter Support Realm Configuration................................................................................................914
External Bandwidth Manager Configuration........................................................................................ 915
Media Profile Configuration................................................................................................................. 916
CAC Debugging.................................................................................................................................... 917
2127 - Configurable Subscription ID Types......................................................................................................917
Subscriber Information AVP................................................................................................................. 917
Specific Action AVP support............................................................................................................................ 919
ACLI Examples - specific-action-subscription..................................................................................... 919
Diameter STR Timeouts....................................................................................................................................920
Diameter STR Timeouts Configuration................................................................................................ 920
Gq Interface Features........................................................................................................................................ 920
Rx Interface Features.........................................................................................................................................920
Non-Priority Call Handling................................................................................................................... 921
Priority Call Handling........................................................................................................................... 921
Rx bearer plane event............................................................................................................................ 921
2836 - Early Media Suppression for Rx................................................................................................922
Media-Component-Number and Flow-Number AVP Values................................................................923
Rx Interface Reason Header Usage.......................................................................................................925
Network Provided Location Information.......................................................................................................... 926
Basic Implementation............................................................................................................................927
Enhanced Implementation.....................................................................................................................927
3GPP-User-Location-Info Attribute......................................................................................................928
IP-CAN-Type AVP (Phase 2)................................................................................................................928
MSISDN AVP....................................................................................................................................... 929
RAT-Type Attribute............................................................................................................................... 929
NPLI Required-Access-Info AVP (Phase 2)......................................................................................... 930
NPLI Specific-Action AVP (Phase 2)................................................................................................... 930
NPLI Enabling NPLI Notifications.......................................................................................................930
P-Access-Network-Info SIP Header..................................................................................................... 931
P-Subscription-MSISDN SIP Header................................................................................................... 933
Handling User-Endpoint-Provided Location Information.................................................................... 933
User-Endpoint-Provided Location Information Configuration............................................................. 933
NPLI Emergency Call Processing......................................................................................................... 934
NPLI Emergency Call Configuration....................................................................................................934
Configuring Default PANI Contents..................................................................................................... 935
Caveats.................................................................................................................................................. 935
Rf Interface Features......................................................................................................................................... 935
Node-Functionality AVP Support......................................................................................................... 935
Node Functionality AVP Configuration................................................................................................ 936
Node Functionality Per Realm Configuration.......................................................................................936
2733 - Optimization of AAR Messages............................................................................................................ 937
AAR Message Configuration................................................................................................................ 939
AF-Application-Identifier AVP Generation...................................................................................................... 939
AVP Generation on Initial INVITE from UE........................................................................................939
AVP Generation on response to Initial INVITE from UE.....................................................................940
AVP generation on reINVITE from UE................................................................................................ 940
Examples............................................................................................................................................... 940
AVP Generation on Initial INVITE from core...................................................................................... 942
AVP Generation on response to initial INVITE from core................................................................... 943
26
Oracle® Communications Unified Session Manager
AVP generation on reINVITE from core.............................................................................................. 943
Diameter: CLF...................................................................................................................................................945
CLF Behavior........................................................................................................................................ 945
CLF Failures..........................................................................................................................................947
CLF Emergency Call Handling............................................................................................................. 947
CLF Diameter e2 Error Handling......................................................................................................................948
Result-Code AVP.................................................................................................................................. 948
Experimental-Result-Code AVP............................................................................................................948
Diameter CLF e2 Error Bypass............................................................................................................. 948
CLF-only AVPs................................................................................................................................................. 948
Globally-Unique-Address AVP............................................................................................................. 948
CLF e2 Interface User-Name AVP Support.......................................................................................... 949
HA Functionality...................................................................................................................................950
Configuring Diameter-based CLF.....................................................................................................................950
SIP Interface Configuration...................................................................................................................950
CLF Debugging.....................................................................................................................................952
E2 CLF Configurable Timeout..........................................................................................................................953
Activating a Configuration with the E2 CLF Timeout Defined............................................................953
E2 CLF Timeout Configuration............................................................................................................ 953
Diameter Policy Server High Availability.........................................................................................................953
External Policy Server HA Cluster....................................................................................................... 953
Standby Server Prioritization................................................................................................................ 954
Server States.......................................................................................................................................... 954
HA Cluster Refresh............................................................................................................................... 954
DNS Failure...........................................................................................................................................954
Policy Server Failover........................................................................................................................... 954
External Policy Server High Availability Configuration...................................................................... 955
Diameter Multi-tiered Policy Server Support................................................................................................... 955
Diameter Multi-tiered Policy Server Support....................................................................................... 956
Diameter Message Manipulations..................................................................................................................... 956
Manipulation Rule.................................................................................................................................957
AVP Search Value................................................................................................................................. 957
Actions on Found Match Value............................................................................................................. 958
AVP Header Manipulation.................................................................................................................... 960
Multi-instance AVP Manipulation.........................................................................................................962
ACLI Instructions..................................................................................................................................962
Diameter Manipulation Example - Supported Features AVP............................................................... 963
COPS-based External Policy Servers................................................................................................................965
COPS Connection................................................................................................................................. 965
COPS Failures....................................................................................................................................... 965
HA Support............................................................................................................................................966
Application Types..................................................................................................................................966
COPS: RACF.................................................................................................................................................... 966
Implementation Features....................................................................................................................... 967
Bandwidth Negotiation..........................................................................................................................968
COPS pkt-mm-3 Policy Control....................................................................................................................... 968
Relationship to the TCP Connection..................................................................................................... 968
COPS Gate-Set Timeout........................................................................................................................968
When a Gate-Set Times Out..................................................................................................................969
COPS Decision Gate-Set Message Rejected.........................................................................................969
About the Gate-Spec Mask....................................................................................................................970
COPS Debugging.............................................................................................................................................. 970
COPS-based RACF Configuration....................................................................................................................971
Realm Configuration............................................................................................................................. 971
External Bandwidth Manager Configuration........................................................................................ 971
Media Profile Configuration................................................................................................................. 972
Oracle® Communications Unified Session Manager
27
COPS: CLF....................................................................................................................................................... 973
CLF Behavior........................................................................................................................................ 973
CLF Failures..........................................................................................................................................974
CLF Emergency Call Handling............................................................................................................. 974
HA Functionality...................................................................................................................................975
CLF Debugging.....................................................................................................................................975
COPS-based CLF Configuration.......................................................................................................................976
SIP Interface Configuration...................................................................................................................976
Application Type / Interface Matrix Reference.................................................................................................977
Bandwidth Management Applications.................................................................................................. 977
Emergency Location Services............................................................................................................... 977
19 Transcoding............................................................................... 979
Introduction....................................................................................................................................................... 979
Transcoding Hardware.......................................................................................................................... 979
Transcoding Configuration................................................................................................................................981
Transcoding Processing Overview........................................................................................................ 981
Defining Codec Policies........................................................................................................................981
Codec Policy Definition.................................................................................................................................... 983
Syntax....................................................................................................................................................983
Answer Processing and Examples.....................................................................................................................984
Unoffered Codec Reordering................................................................................................................ 984
Non-transcoded Call..............................................................................................................................984
Transcoded Call.....................................................................................................................................985
Voice Transcoding................................................................................................................................. 985
RFC 2833 Transcoding..........................................................................................................................991
FAX Transcoding.................................................................................................................................. 995
Transrating...........................................................................................................................................1000
Default Media Profiles.................................................................................................................................... 1002
Transcodable Codecs...........................................................................................................................1002
Preferred Default Payload Type.......................................................................................................... 1003
Redefining Codec Packetization Time................................................................................................ 1003
mptime Support for Packet Cable....................................................................................................... 1003
EVRC Family of Codecs.................................................................................................................................1004
EVRC-A Codec for Transcoding........................................................................................................ 1004
EVRC-B Codec for Transcoding.........................................................................................................1006
Configuring Transcoding.................................................................................................................................1007
Codec Policy Configuration................................................................................................................ 1007
Media Profile Configuration............................................................................................................... 1009
Media Type Subnames.................................................................................................................................... 1010
SDP Parameter Matching.................................................................................................................... 1010
Using Subnames with Codec Policies................................................................................................. 1010
Media Type and Subname Configuration............................................................................................1011
Codec Policy Configuration with a Media Type with a Subname...................................................... 1012
Codec and Conditional Codec Policies for SIP...............................................................................................1012
Relationship to Media Profiles............................................................................................................ 1013
Manipulation Modes............................................................................................................................1013
In-Realm Codec Manipulation............................................................................................................ 1014
Conditional Codec Policies................................................................................................................. 1014
ACLI Instructions and Examples........................................................................................................ 1016
Transcoding Support for Asymmetric Dynamic Payload Types..................................................................... 1018
Configure Transcoding for Asymmetric Dynamic Payload Types..................................................... 1019
Asymmetric Payload Type Support for RFC2833 Interworking.....................................................................1019
DTMF Indication over HD Audio Codecs.......................................................................................... 1020
RFC2833 and KPML Interworking.................................................................................................................1021
28
Oracle® Communications Unified Session Manager
KPML-2833 Interworking on a SIP Interface Configuration............................................................. 1024
KPML-2833 Interworking on a Session Agent Configuration........................................................... 1024
Maintenance and Troubleshooting.................................................................................................................. 1025
show mbcd errors................................................................................................................................ 1025
Active and Period Statistics for EVRC and other Codecs...................................................................1026
show sipd codecs................................................................................................................................. 1026
Logs..................................................................................................................................................... 1032
Alarms................................................................................................................................................. 1032
Transcoding Capacity Traps............................................................................................................................ 1034
SNMP.............................................................................................................................................................. 1035
Generating RTCP............................................................................................................................................ 1035
RTCP Generation Platform Support....................................................................................................1036
Configuring RTCP Generation............................................................................................................1037
Obtaining System Information about RTCP Generation.....................................................................1037
AP6300 NIU Hotswap Guidelines.................................................................................................................. 1038
Network Interface Unit Removal/Replacement -- Standalone Node.................................................. 1038
NIU Removal/Replacement -- High Availability Deployment........................................................... 1038
20 DTMF Transfer and Support..................................................... 1041
DTMF Interworking........................................................................................................................................ 1041
DTMF Indication.................................................................................................................................1041
DTMF Transfer Processing Overview............................................................................................................ 1042
Capability Negotiation.................................................................................................................................... 1042
SDP Manipulated by Codec Policy..................................................................................................... 1042
SDP Manipulated by RFC 2833 Mode............................................................................................... 1044
RFC 2833 Payload Type Mapping...................................................................................................... 1045
Translation Evaluation.....................................................................................................................................1045
RFC 2833 Sent by Offerer...................................................................................................................1046
DTMF Audio Tones Sent by Offerer...................................................................................................1047
SIP INFO Sent By Offerer.................................................................................................................. 1049
Dual Mode.......................................................................................................................................................1050
P-Dual-Info Header............................................................................................................................. 1050
Identical Inband with Signaling DTMF Transfer Exception...........................................................................1051
Override Preferred RFC 2833............................................................................................................. 1051
Override Preferred DTMF Audio........................................................................................................1052
DTMF Transfer for Spiral Calls...................................................................................................................... 1052
P-Dual-Info Header............................................................................................................................. 1053
DTMF Transfer Hardware Processing............................................................................................................ 1053
DTMF Transfer Configuration........................................................................................................................ 1053
RFC 2833 Session Agent Configuration............................................................................................. 1053
ACLI Configuration and Instructions..................................................................................................1054
RFC 2833 Customization................................................................................................................................ 1056
RTP Timestamp................................................................................................................................... 1056
RFC 2833 telephone-event duration intervals.....................................................................................1056
RFC 2833 End Packets........................................................................................................................1057
ACLI Instructions and Examples........................................................................................................ 1057
21 RCS Services............................................................................ 1059
Message Session Relay Protocol.....................................................................................................................1059
MSRP Platform Requirements............................................................................................................ 1059
MSRP IP Address Family Support......................................................................................................1059
MSRP Operational Description...........................................................................................................1059
Secure MSRP Session Negotiation..................................................................................................... 1062
MSRP Session Setup........................................................................................................................... 1063
Oracle® Communications Unified Session Manager
29
MSRP Session Termination.................................................................................................................1064
Network Address Translation..............................................................................................................1065
Certificate Fingerprint......................................................................................................................... 1066
MSRP Configuration.......................................................................................................................................1066
msrp-config Configuration.................................................................................................................. 1066
tcp-media-profile Configuration..........................................................................................................1067
realm Configuration............................................................................................................................ 1069
tls-profile Configuration......................................................................................................................1069
MSRP Management Monitoring..................................................................................................................... 1070
RCSe TLS/TCP Re-Use Connections............................................................................................................. 1071
RCSE TLS/TCP Re-Use Connections Configuration......................................................................... 1071
22 Call Traffic Monitoring............................................................. 1073
SelectiveCall Recording SIPREC................................................................................................................... 1073
SIPREC Feature.............................................................................................................................................. 1073
Configuring SIPREC.......................................................................................................................................1074
Session Recording Server (SRS).........................................................................................................1074
Session Recording Group....................................................................................................................1074
Selective Recording.............................................................................................................................1075
High Availability (HA) Support.......................................................................................................... 1076
SIPREC Configuration Procedure.......................................................................................................1076
Metadata Contents...............................................................................................................................1082
Show Commands for Recording Sessions...........................................................................................1082
SIPREC Recording Session Refresh............................................................................................................... 1084
Timer_B...............................................................................................................................................1084
OPTIONS Request/Response..............................................................................................................1085
Recording Session Refresh Configuration.......................................................................................... 1085
Codec Negotiation...........................................................................................................................................1086
SIPREC Call Flows......................................................................................................................................... 1086
Selective Recording.............................................................................................................................1086
Oracle Communications Session Monitor Mediation Engine.........................................................................1094
IPFIX............................................................................................................................................................... 1095
Communications Monitor Configuration........................................................................................................ 1096
Communication Monitor..................................................................................................................... 1096
TSCF Rekey Profile Configuration.....................................................................................................1097
TLS Profile Configuration...................................................................................................................1098
Packet Trace.................................................................................................................................................... 1099
Packet Trace Remote...........................................................................................................................1099
Packet Trace Local.............................................................................................................................. 1100
Packet Trace Scenarios........................................................................................................................ 1101
Running Packet Trace..........................................................................................................................1103
23 References and Debugging...................................................... 1105
ACLI Configuration Elements........................................................................................................................ 1105
sip-registrar......................................................................................................................................................1105
Parameters........................................................................................................................................... 1105
Path...................................................................................................................................................... 1106
sip-authentication-profile................................................................................................................................ 1106
Parameters........................................................................................................................................... 1106
Path...................................................................................................................................................... 1107
home-subscriber-server................................................................................................................................... 1107
Parameters........................................................................................................................................... 1107
Path...................................................................................................................................................... 1108
third-party-regs................................................................................................................................................ 1108
30
Oracle® Communications Unified Session Manager
Parameters........................................................................................................................................... 1108
Path...................................................................................................................................................... 1108
local-subscriber-table.......................................................................................................................................1108
Parameters........................................................................................................................................... 1108
Path...................................................................................................................................................... 1109
enum-config.....................................................................................................................................................1109
Parameters........................................................................................................................................... 1109
Path...................................................................................................................................................... 1110
ifc-profile......................................................................................................................................................... 1110
Parameters........................................................................................................................................... 1110
Path...................................................................................................................................................... 1110
regevent-notification-profile............................................................................................................................1110
Parameters........................................................................................................................................... 1110
Path...................................................................................................................................................... 1111
hss-group..........................................................................................................................................................1111
Parameters............................................................................................................................................1111
SNMP MIBs and Traps....................................................................................................................................1111
Acme Packet License MIB (ap-license.mib)................................................................................................... 1111
Acme Packet System Management MIB (ap-smgmt.mib).............................................................................. 1112
Enterprise Traps...................................................................................................................................1112
Oracle USM Show Commands........................................................................................................................1112
show sipd endpoint-ip..........................................................................................................................1112
show sipd third-party........................................................................................................................... 1113
show sipd local-subscription............................................................................................................... 1113
show registration..................................................................................................................................1115
show home-subscriber-server.............................................................................................................. 1116
show http-server.................................................................................................................................. 1118
Session Load Balancer Support....................................................................................................................... 1119
Verify Config................................................................................................................................................... 1119
sip authentication profile (CX)............................................................................................................ 1119
sip authentication profile (ENUM)......................................................................................................1119
sip authentication profile (Local)........................................................................................................ 1120
sip-registrar..........................................................................................................................................1120
sip-registrar..........................................................................................................................................1120
Resource Utilization........................................................................................................................................ 1120
CPU Overload Protection.................................................................................................................... 1120
Heap Utilization...................................................................................................................................1121
A— RTC Support................................................................................................1123
B— USM Base Configuration Elements........................................................... 1127
USM Base Configuration Elements for Cx..................................................................................................... 1127
USM Base Configuration Elements for ENUM..............................................................................................1129
USM Base Configuration Elements for LST...................................................................................................1131
Oracle® Communications Unified Session Manager
31
32
Oracle® Communications Unified Session Manager
About This Guide
This ACLI Configuration Guide provides information about:
•
•
•
•
Basic concepts that apply to the key features and abilities of your Oracle USM
Information about how to load the Oracle USM system software image you want to use and establish basic
operating parameters
System-level functionality for the Oracle USM
Configuration of all components of the Oracle USM
Supported Platforms
Release Version S-CZ7.2.5 includes both the Oracle Core Session Manager (CSM) and Unified Session Manager
(USM) products. The Oracle USM is supported on the Acme Packet 4500, 4600, 6100, and 6300 series platforms.
The Oracle CSM is supplied as virtual machine software or as a software-only delivery suitable for operation on
server hardware. Refer to sales documentation updates for information further specifying hardware support.
Related Documentation
The following table lists the members that comprise the documentation set for this release:
Document Name
Document Description
Acme Packet 4500 Hardware
Installation Guide
Contains information about the components and installation of the Acme Packet
4500 system.
Acme Packet 4600 Hardware
Installation Guide
Contains information about the components and installation of the Acme Packet
4600 system.
Acme Packet 6100 Hardware
Installation Guide
Contains information about the components and installation of the Acme Packet
6100 system.
Acme Packet 6300 Hardware
Installation Guide
Contains information about the components and installation of the Acme Packet
6300 system.
Release Notes
Contains information about the current documentation set release, including new
features and management changes.
ACLI Configuration Guide
Contains information about the administration and software configuration of the
Oracle Communications Session Border Controller.
ACLI Reference Guide
Contains explanations of how to use the ACLI, as an alphabetical listings and
descriptions of all ACLI commands and configuration parameters.
Maintenance and
Troubleshooting Guide
Contains information about logs, performance announcements, system
management, inventory management, upgrades, working with configurations, and
managing backups and archives.
MIB Reference Guide
Contains information about Management Information Base (MIBs), Oracle
Communications Enterprise MIBs, general trap information, including specific
details about standard traps and enterprise traps, Simple Network Management
Protocol (SNMP) GET query information (including standard and enterprise
SNMP GET query names, object identifier names and numbers, and descriptions),
examples of scalar and table objects.
Accounting Guide
Contains information about accounting support, including details about RADIUS
accounting.
Oracle® Communications Unified Session Manager
33
About This Guide
Document Name
Document Description
HDR Resource Guide
Contains information about the Historical Data Recording (HDR) feature. This
guide includes HDR configuration and system-wide statistical information.
Administrative Security
Essentials
Contains information about Administrative Security license support.
Security Guide
Contains information about security considerations and best practices from a
network and application security perspective for the Oracle Communications
Session Border Controller family of products. The Oracle USM and the Oracle
CSM are members of the Oracle Communications Session Border Controller
family of products.
Call Monitoring Guide
Contains information on call monitoring.
Hardware documentation is relevant only to the Oracle USM. Refer to your hardware vendor's documentation for
information required for Oracle CSM operation.
Version SCZ725 software relies on version SCZ720 documentation for some documentation. This documentation
includes:
•
•
•
The ACLI Reference Guide
The Troubleshooting and Maintenance Guide
The Administrative Security Essentials Guide
Revision History
Date
Description
November 2014
•
Initial Release
February 2015
•
•
•
Updated trust-me references.
Updates documentation reference to include Acme Packet 4600 hardware.
Clarifies the infrastructure response to terminating requests to an unregistered
user.
June 2015
•
•
•
Adds descriptive information on HMR reserved variables.
Removes description of unsupported GRUU functionality.
Corrects spelling of psi-cache-expiry option.
February 2016
•
•
•
Corrects command arguments for p-early-media-header parameter.
Removes reference to unsupported SRR feature.
Corrects re-connection timing criteria for establishing connections to external
policy servers.
Removes ENUM from the "Compound Key LRT Lookup" topic because
ENUM does not support compound lookup keys.
Replaces parameter to enable IMS-AKA.
Updates the Transport Layer Security (TLS) version.
•
•
•
March 2016
•
•
•
34
Adds refreshRegForward option to the ims-aka-profile.
Corrects the description of the ext-policy-server parameter disconnect-ontimeout .
Corrects description of parameter for source realm selection in multi-stage
routing.
Oracle® Communications Unified Session Manager
About This Guide
Date
March 2016
Description
•
Adds the Request URI Construction as Forwarded to SAG-member Session
Agent feature description to the Session Routing and Load Balancing Chapter
•
Renames HIP section in Network Interfaces to Administrative Applications
Over Media Interfaces. Corrects description regarding firewalls and ports.
Adds gateway requirement and overlapping subnet advisory.
Minor edits to Network Interfaces conceptual and Configuration sections.
Updates HIP Address Configuration for clarity. Adds SSH parameter. Adds
gateway requirement and overlapping subnet advisory.
Removes Source-based Routing section from System Configuration chapter.
•
•
•
June 2016
•
•
•
•
Added a note in the section Tunnel mode vs Transport mode under IPSec
support
Edit description for IPSec support
Clarifies Static Flows as unidirectional
Corrects explanation of diameter manipulation
September 2016
•
Adds new scenario under Fax Transcoding topic
December 2016
•
Defect fix ACMECSBC-22254
Oracle® Communications Unified Session Manager
35
1
Oracle USM Basics
This chapter introduces key features and capabilities of the Oracle USM. As an integrated IP Multimedia Sub-system
(IMS) Call Session Control Function (CSCF), the Oracle USM performs CSCF roles on a single platform. This
configuration can simplify IMS deployment and operation scenarios. See product specification or Oracle consultative
services to understand applicable deployments. This document does not provide general instruction on IMS; review
the many generally-available IMS resources if you need introduction to its complex mechanisms.
The Oracle USM operates within the context of an IMS or over-the-top (OTT) deployment. Within IMS, the device
performs standard registration and call handling functions in compliance with 3GPP requirements. The presence of
multiple CSCF functions on a single platform can simplify IMS operations. For those who prefer an OTT
deployment, the Oracle USM supports registration and call management via an ENUM or local subscriber database.
The Oracle USM functions within IMS environments using Home Subscriber Server (HSS) deployments as
subscriber database. Operation with IMS HSS resources is described in the Diameter Based Oracle USM chapter. For
OTT, operation using ENUM resources is described in the ENUM Based Oracle USM chapter and operation with
local subscriber tables is described in the Local Subscriber Tables chapter.
By utilizing Oracle's Session Border Controller (SBC) product features, the Oracle USM is also capable of
performing a wide range of edge functions, separated along the following roles:
•
•
Access functions
Interconnect functions
This functionality and configuration is covered in the Oracle USM Supporting the IMS Edge chapter.
Oracle USM and IMS
The ETSI TISPAN NGN defines several subsystems that make up the NGN architecture. The model for the target
NGN architecture is depicted below.
The Oracle USM is designed to function as an integrated:
•
•
•
Proxy-Call Session Control Function (P-CSCF)
Interrogating-Call Session Control Function (I-CSCF)
Serving-Call Session Control Function (S-CSCF)
In addition, the Oracle USM performs many related functions. As such, the Oracle USM is typically deployed in
support of LTE and other IMS-based networks.
The functions performed by the Oracle USM are best understood as functions of standard IMS elements. The diagram
below depicts the interconnection of these elements across an IMS architecture.
Oracle® Communications Unified Session Manager
37
Oracle USM Basics
High level definitions of these functions include:
•
•
•
•
•
•
P-CSCF—The first point of contact within the IMS system for the endpoint. The P-CSCF determines whether and
how to pass the traffic to the appropriate S-CSCF.
I-CSCF—IMS passes traffic to the I-CSCF if the target S-CSCF is unknown.
S-CSCF—Interaction with the Home Subscriber Server (HSS) determines whether and how to provide service to
the endpoint.
BGCF—The breakout gateway control function provides signaling transit to network domains external to the
IMS.
IMS-AGW—Access gateway complimenting the P-CSCF function to broaden the range of devices that can access
the IMS.
Ancilliary Access Functions—As part of 3GPP Release 10, new interfaces and protocols have been defined to
improve mobility across LTE and 2G/3G networks and address the latency concern from previous architectures.
The enhancements to the SRVCC system defines two logical entities located in the access network:
•
•
ATCF—The (Access Transfer Control Function) is a signalling controller function complementing the
signalling and media control roles of the P-CSCF and IMS-AGW functions in the SBC.
ATGW—The Access Transfer Gateway is a media anchor point complementing the signalling and media
control roles of the P-CSCF and IMS-AGW functions.
Refer to 3GPP specifications for complete element definitions and explanations of the functions they can or must
perform. Key functions and considerations that introduce the Oracle USM's operation are briefly discussed below.
As P-CSCF, the Oracle USM adds traffic policing, UA functions for special SIP signaling handling, CDR generation,
topology hiding, policy enforcement, and hosted NAT traversal to the 3GPP-defined P-CSCF functions. As such, the
Oracle USM can reside at the network's edge performing functions that may otherwise be performed by an SBC.
As I-CSCF, the Oracle USM complies with 3GPP standards to perform the interrogating function and locate the
proper S-CSCF for a given session.
As S-CSCF, the near the subscriber that facilitate rapid and predictable handover from LTE to circuit 2G/3G networks
and update the VCC application server after the access transfer. They facilitate rapid and predictable handover from
LTE to circuit 2G/3G networks and update the VCC application server after the access transfer. The combination of
38
Oracle® Communications Unified Session Manager
Oracle USM Basics
these new functions and improved call flow reduces the signalling hops required to handover the active voice call to
the new access network complies with 3GPP standards and Oracle USM to manage sessions. It interacts with the HSS
to determine whether any given registration can reside locally, or be managed by another S-CSCF device. It also
interacts with the HSS and other infrastructure components to provide applicable services within the context of a
given session.
As ATCF and ATGW, Oracle USM provides services near the subscriber that facilitate rapid and predictable handover
from LTE to circuit 2G/3G networks and update the VCC application server after the access transfer. The combination
of these new functions and improved call flow reduces the signalling hops required to handover the active voice call
to the new access network
Oracle USM and OTT
The Oracle USM may be deployed as a SIP registrar in OTT environments. OTT environments may use ENUM
resources as subscriber database. Alternatively, they may use local subscriber tables (LST). Both ENUM and LST
deployment descriptions and configuration instructions are provided within this guide.
Multiple Control Functions on a Single Device
Most Oracle USM deployments are expected to be homogenous. That is, the Oracle USM would most commonly be
operating with other Oracle USMs. In addition, because individual Oracle USMs can perform all CSCF functions, the
network administrator can expect traffic patterns that are different from deployments that use discrete components to
perform CSCF functions.
For example, it would be common for the subscriber database to allow the S-CSCF within a given Oracle USM to
take ownership of a UE seeking services via that same device's P-CSCF. In these cases, the user can expect the
effective path and service route between a UE and an S-CSCF to be the same as the path between that UE and the PCSCF.
IMS design anticipates multiple devices performing CSCF functions. Therefore, the Oracle USM also supports
operation across multiple Oracle USMs.
Elements of Oracle USM Configuration
Oracle USM consists of multiple configuration elements. This guide presents these elements, separating them along
conceptual category with chapters roughly equating to configuration sequence. This section lists configuration
elements, providing the reader with a consolidated picture of overall product configuration.
See the Base Configuration Elements Appendix for minimal configuration setting examples that establish an operable
Oracle USM.
USM Configuration Elements
Required initial device configuration elements, explained in the Getting Started chapter, include:
•
•
•
•
•
Boot Parameters
Management Interfaces
Device Password
Default Gateway
Product licensing/entitlement
Required network and SIP service configuration components, explained in multiple chapters, include:
•
•
•
Enable SIP-Config—System Configuration Chapter
Service physical and network interface(s)—System Configuration Chapter
SIP Interfaces—System Configuration Chapter
Oracle® Communications Unified Session Manager
39
Oracle USM Basics
•
•
•
SIP Ports—System Configuration Chapter
Realms—Realms and Nested Realms Chapter
ENUM—Routing with Local Policy Chapter
Required IMS configuration elements, explained in the Oracle USM Supporting the IMS Core Chapter, include:
•
•
•
•
•
•
Subscriber Database
SIP Registrar
Authentication Profile
ENUM for e.164 Translation
Registration Event
IMS Access Interface
Common Configuration Elements
Common configuration that may be needed for your deployment includes:
•
•
•
•
•
•
•
•
•
Session Agents
ENUM Routing
Local Routing
Initial Filter Criteria (iFC)
3rd Party Registration Service
IMS Access Functions
IMS Interconnect Functions
Media manager
Media Steering pools
Common secondary management element configuration includes:
•
•
•
High Availability (HA)
CDR Accounting
SNMP Management
Other Configuration Elements
Configuration elements that are available, but may not be required for your deployment include:
•
•
•
•
•
•
•
•
•
Assorted SIP Configuration
Number Translation
Admission Control and QoS
DoS and other Security Configuration
Diameter Policy Configuration
Transcoding
Local Routing Configuration
Realm-based media policy and controls
Traffic Monitoring
See the Appendix on Base USM Configuration Elements for a list of configuration setting examples that bring your
system to a minimally operational state in an IMS environment. Change addressing and other infrastructuredependent setting examples to match that of your environment.
High Availability
Oracle USMs are deployed in pairs to deliver continuous high availability (HA) for interactive communication
services. The HA design guarantees that no stable calls are dropped in the event of any single point failure.
Furthermore, the Oracle USM HA design provides for full media, registration, call and service state to be shared
40
Oracle® Communications Unified Session Manager
Oracle USM Basics
across an HA node. The solution uses a VRRP-like design, where the two systems share a virtual MAC address and
virtual IPv4 address for seamless switchovers.
In the HA pair, one Oracle USM is the primary system, and is used to process signaling and media traffic. The backup
system remains fully synchronized with the primary system’s session status. The primary system continuously
monitors itself for connectivity and internal process health. If it detects service-disrupting conditions or degraded
service levels, it will alert the backup Oracle USM to become the active system.
Oracle® Communications Unified Session Manager
41
2
Getting Started with the Oracle USM
Prior to configuring your Oracle USM for service, we recommend that you review the information and procedures in
this chapter.
This chapter offers information that will help you:
•
•
•
•
•
•
•
•
Review hardware installation procedures
Connect to your Oracle USM using a console connection, Telnet, or SSH (secure shell)
Become familiar with the Oracle USM’s boot parameters and how to change them if needed
Understand and configure Oracle USM entitlements
Load and activate a Oracle USM software image
Choose a configuration mechanism: ALCI, external management application, or ACP/XML
Enable RADIUS authentication
Customize your login banner
Oracle CSM and Oracle USM product installation begin with the same software installation packages. The specific
product deployment is based on the hardware platform over which the software is installed.
Oracle USM is deployed on specific hardware platforms, not generic COTS computer hardware. The software detects
installation platform upon startup. If the hardware is on Acme Packet 4000 or 6000 series hardware, the software
configures itself as Oracle USM instead of Oracle CSM. From that point on, the user has access to only Oracle USM
commands and configuration elements. Oracle USM deployments require that the installation team refer to Acme
Packet hardware documentation for installation procedures.
Oracle USM Installation and Startup
After you have completed the hardware installation procedures outlined in the Acme Packet 4000 Hardware
Installation Guide or Acme Packet 6000 Hardware Installation Guide, you are ready to establish a connection to your
Oracle USM. Then you can load the Oracle USM software image you want to use and establish basic operating
parameters.
Hardware Installation Process
Installing the Oracle USM hardware in a rack requires the following process.
1. Unpack the Oracle USM hardware.
2. Install the Oracle USM hardware into the rack.
3. Install the power supplies.
Oracle® Communications Unified Session Manager
43
Getting Started with the Oracle USM
4. Install the fan modules.
5. Install the physical interface cards.
6. Cable the Oracle USM hardware.
Note: Complete installation procedures fully and note the safety warnings to prevent physical harm to
yourself and damage to the Oracle USM hardware.
For more information, see the hardware documentation.
Connecting to Your Oracle USM
You can connect to your Oracle USM either through a direct console connection, or by creating a remote Telnet or
SSH session. Both of these access methods provide you with the full range of configuration, monitoring, and
management options.
Note: By default, Telnet and SFTP connections to your Oracle USM are enabled.
Create a Console Connection
Using a serial connection, you can connect your laptop or PC directly to the Acme Packet hardware. If you use a
laptop, you must take appropriate steps to ensure grounding.
One end of the cable plugs into your terminal, and the other end plugs into the RJ-45 Console port on the NIU (or
management ports area on the Acme Packet 6300).
To make a console connection to your hardware:
1. Set the connection parameters for your terminal to the default boot settings:
• Baud rate: 115,200 bits/second
• Data bits: 8
• Parity: No
• Stop bit: 1
• Flow control: None
2. Connect a serial cable to between your PC and the hardware's console port.
3. Apply power to the hardware.
4. Enter the appropriate password information when prompted to log into User mode of the ACLI.
You can set the amount of time it takes for your console connection to time out by setting the console-timeout
parameter in the system configuration. If your connection times out, the login sequence appears again and prompts
you for your passwords. The default for this field is 0, which means that no time-out is being enforced.
Incoming Telnet Connections and Time-outs
You can Telnet to your Oracle USM. Using remote Telnet access, you can provision the Oracle USM remotely
through the management IP interface.
The Oracle USM, when running on Acme Packet platforms can support up to 5 concurrent Telnet sessions. When
running on other platform types, only 4 concurrent Telnet sessions are available. In both cases, only one Telnet
session may be in configuration mode at a time.
Note: Telnet does not offer a secure method of sending passwords. Using Telnet, passwords are sent in clear
text across the network.
To Telnet to your Oracle USM, you need to know the IP address of its administrative interface (wancom0/eth0). The
wancom0/eth0 IP address of your Oracle USM is found by checking the inet on ethernet value in the boot
parameters or visible from the front panel display.
You can manage incoming Telnet connections from the ACLI:
44
Oracle® Communications Unified Session Manager
Getting Started with the Oracle USM
•
•
•
•
To set a time-out due to inactivity, use the telnet-timeout parameter in the system configuration. You can set the
number of seconds that elapse before the Telnet connection or SSH connection is terminated. The default for this
field is 0, which means that no time-out is being enforced.
To view the users who are currently logged into the system, use the ACLI show users command. You can see the
ID, timestamp, connection source, and privilege level for active connections.
From Superuser mode in the ACLI, you can terminate the connections of other users in order to free up
connections. Use the kill user command with the corresponding connection ID.
From Superuser mode in the ACLI, you can globally enable and disable Telnet connections:
•
•
•
Telnet service is enabled by default unless explicitly disabled as shipped.
To disable Telnet, type the management disable telnet command at the Superuser prompt and reboot your
system. The Oracle USM then refuses any attempts at Telnet connections. If you want to restart Telnet service,
type management enable telnet.
If you reboot your Oracle USM from a Telnet session, you lose IP access and therefore your connection.
SSH Remote Connections
For increased security, you can connect to your Oracle USM using SSH. An SSH client is required for this type of
connection.
The Oracle USM supports five concurrent SSH and/or SFTP sessions.
There are two ways to use SSH to connect to your Oracle USM. The first works the way a Telnet connection works,
except that authentication takes place before the connection to the Oracle USM is made. The second requires that you
set an additional password.
1. To initiate an SSH connection to the Oracle USM without specifying users and SSH user passwords:
a) Open your SSH client (with an open source client, etc.).
b) At the prompt in the SSH client, type the ssh command, a Space, the IPv4 address of your Oracle USM, and
then press Enter.
The SSH client prompts you for a password before connecting to the Oracle USM. Enter the Oracle USM’s
User mode password. After it is authenticated, an SSH session is initiated and you can continue with tasks in
User mode or enable Superuser mode.
Note: You can also create connections to the Oracle USM using additional username and password
options.
2. To initiate an SSH connection to the Oracle USM with an SSH username and password:
a) In the ACLI at the Superuser prompt, type the ssh-password and press Enter. Enter the name of the user you
want to establish. Then enter a password for that user when prompted. Passwords do not appear on your
screen.
ORACLE# ssh-password
SSH username [saved]: MJones
Enter new password: 95X-SD
Enter new password again: 95X-SD
After you configure ssh-password, the SSH login accepts the username and password you set, as well as the
default SSH/SFTP usernames: User and admin.
b) Configure your SSH client to connect to your Oracle USM’s management IPv4 address using the username
you just created. The standard version of this command would be:
ssh -l MJones 10.0.1.57
c) Enter the SSH password you set in the ACLI.
MJones@10.0.2.54 password: 95X-SD
d) Enter your User password to work in User mode on the Oracle USM. Enable Superuser mode and enter your
password to work in Superuser mode.
e) A Telnet session window opens and you can enter your password to use the ACLI.
Oracle® Communications Unified Session Manager
45
Getting Started with the Oracle USM
System Boot
When your Oracle USM boots, the following information about the tasks and settings for the system appear in your
terminal window.
•
•
•
•
•
System boot parameters
From what location the software image is being loaded: an external device or internal flash memory
Requisite tasks that the system is starting
Log information: established levels and where logs are being sent
Any errors that might occur during the loading process
After the loading process is complete, the ACLI login prompt appears.
Oracle USM Boot Parameters
Boot parameters specify the information that your Oracle USM uses at boot time when it prepares to run applications.
The Oracle USM’s boot parameters:
•
•
•
•
Allow you to set the IP address for the management interface (wancom0).
Allow you to set a system prompt. The target name parameter also specifies the title name displayed in your web
browser and SNMP device name parameters.
Determine the software image to boot and from where the system boots that image.
Sets up the username and password for network booting from an external FTP server.
In addition to providing details about the Oracle USM’s boot parameters, this section explains how to view, edit, and
implement them.
When displaying the boot parameters, your screen shows a help menu and the first boot parameter (boot device).
Press Enter to continue down the list of boot parameters.
Sample Oracle USM Boot Parameters
The full set of Oracle USM boot parameters appears like the ones in this sample:
ORACLE(configure)# bootparam
'.' = clear field; '-' = go to previous field; ^D = quit
boot device
: eth0
processor number
: 0
host name
: acmepacket8
file name
: /boot/nnSC600.gz
inet on ethernet (e)
: 10.0.1.57:ffff0000
inet on backplane (b)
: 0.0.0.0
host inet (h)
: 10.0.1.5
gateway inet (g)
: 10.0.0.1
user (u)
: user
ftp password (pw)
: password
flags (f)
: 0x08
target name (tn)
: acmesystem
startup script (s)
: 0
other (o)
:
NOTE: These changed parameters will not go into effect until reboot. Also, be
aware that some boot parameters may also be changed through the PHY and
Network Interface Configurations.
Boot Parameter Definitions
The following table defines each of the Oracle USM’s boot parameters.
46
Oracle® Communications Unified Session Manager
Getting Started with the Oracle USM
Boot Parameter
Description
boot device
Management interface name and port number of the device from which an
image is downloaded (e.g., wancom0 or eth0) from an external device.
processor number
Processor number on the backplane.
host name
Name of the boot host used when booting from an external device.
file name
Name of the image file to be booted; can be entered with the filename path.
If you are booting from the flash memory, this filename must always match the
filename that you designate when you FTP the image from the source to the
Oracle USM.
When booting from internal flash memory, this filename must start with /boot);
for example, /boot/nnECZ710.bz.
inet on ethernet (e)
Internet address of the Oracle USM.
This field can have an optional subnet mask in the form
inet_adrs:subnet_mask. If DHCP is used to obtain the parameters, lease timing
information may also be present. This information takes the form of
lease_duration:lease_origin and is appended to the end of the field.
In this parameter, the subnet mask ffff0000 = 255.255.0.0.
When you use the ACLI acquire-config command, this is the IPv4 address of
the Oracle USM from which you will copy a configuration.
inet on backplane (b)
Internet address of the backplane interface, eth0.
This parameter can have an optional subnet mask and/or lease timing
information, such as e (inet on ethernet) does.
host inet (h)
Internet address of the boot host used when booting from an external device.
gateway inet (g)
Internet address of the gateway to the boot host.
Leave this parameter blank if the host is on the same network.
user (u)
FTP username on the boot host.
ftp password (pw)
FTP password for the FTP user on the boot host.
flags (f)
Codes that signal the Oracle USM from where to boot. Also signals the Oracle
USM about which file to use in the booting process. This sequence always
starts with 0x (these flags are hexadecimal). The most common codes are:
0x08: Means that the system looks at the filename defined in the boot
configuration parameters to determine where to boot from and what file to use.
If the file name parameter contains /tffsX/filename, then the system boots off
the flash memory (see options below). If the file name parameter just contains
a filename, then the Oracle USM boots off the external host defined and looks
for the filename in the /tftpboot directory on that host.
0x80008: Used for source routing.
If your requirements differ from what these flags allow, contact your Oracle
customer support representative for further codes.
target name (tn)
Name of the Oracle USM as it appears in the system prompt. For example,
ORACLE> or ORACLE#. You need to know the target name if you are setting
up an HA node.
Oracle® Communications Unified Session Manager
47
Getting Started with the Oracle USM
Boot Parameter
Description
This name is required to be unique among Oracle USMs in your network. This
name can be 64 characters or less.
startup script (s)
For Oracle use only.
other (o)
For Oracle use only.
Boot Parameter Changes
You can access and edit boot parameters by using either the ACLI or by interrupting the system boot process.
Note: Changes to boot parameters do not go into effect until you reboot the Oracle USM.
Oracle recommends that you use management port 0 (wancom0) as the boot interface, and that your management
network is either:
•
•
directly a part of your LAN for management port 0
accessible through management port 0
Otherwise, your management messages may use an incorrect source address.
Change Boot Parameters from the ACLI
To access and change boot parameters from the ACLI:
1. In Superuser mode, type configure terminal, and press Enter.
ORACLE# configure terminal
2. Type bootparam, and press Enter. The boot device parameters display.
ORACLE(configure)# bootparam
'.' = clear field; '-' = go to previous field;
boot device
: eth0
^D = quit
To navigate through the boot parameters, press Enter and the next parameter appears on the following line.
You can navigate through the entire list this way. To go back to a previous line, type a hyphen (-) and press Enter.
Any value that you enter entirely overwrites the existing value and does not append to it.
3. To change a boot parameter, type the new value that you want to use next to the old value. For example, if you
want to change the image you are using, type the new filename next to the old one. You can clear the contents of a
parameter by typing a period and then pressing Enter.
ORACLE(configure)# bootparam
'.' = clear field; '-' = go to previous field; ^D = quit
boot device
: eth0
processor number
: 0
host name
: goose
file name
: /boot/nnPCz100.gz /boot/nnPCz200.gz
When you have scrolled through all of the boot parameters, the system prompt for the configure terminal branch
displays.
ORACLE(configure)#
4. Exit the configure terminal branch.
5. Reboot the Oracle USM for the changes to take effect.
The ACLI reboot and reboot force commands initiate a reboot. With the reboot command, you must confirm that
you want to reboot. With the reboot force command, you do not have make this confirmation.
ORACLE# reboot force
48
Oracle® Communications Unified Session Manager
Getting Started with the Oracle USM
The Oracle USM completes the full booting sequence. If necessary, you can stop the auto-boot at countdown to fix
any boot parameters.
If you configured boot parameters correctly, the system prompt displays and you can go ahead with configuration,
management, or monitoring tasks.
Note: If you configured the boot parameters incorrectly, the Oracle USM goes into a booting loop and
displays an error message.
Error loading file: errno = 0x226.
Can't load boot file!!
Press the space bar to stop the loop. Correct the error in the boot parameter, and reboot the system.
Change Boot Parameters by Interrupting a Boot in Progress
To access and change boot parameters by interrupting a boot in progress:
1. When the Oracle USM is in the process of booting, you can press the space bar on your keyboard to interrupt
when you see the following message appear:
Press the space bar to stop auto-boot...
2. After you stop the booting process, you can enter the letter p to display the current parameters, the letter c to
change the boot parameters or the @ (at-sign) to continue booting.
[Acme Packet Boot]: c
'.' = clear field; '-' = go to previous field;
boot device
: wancom0
^D = quit
To navigate through the boot parameters, press Enter and the next parameter appears on the following line.
You can navigate through the entire list this way. To go back to a previous line, type a hyphen (-) and press Enter.
Any value that you enter entirely overwrites the existing value and does not append to it.
3. To change a boot parameter, type the new value that you want to use next to the old value. For example, if you
want to change the image you are using, type the new filename next to the old one.
ORACLE(configure)# bootparam
'.' = clear field; '-' = go to previous field; ^D = quit
boot device
: wancom0
processor number
: 0
host name
: goose
file name
: /code/nnPCz100.bz /code/nnPCz200.bz
4. After you have scrolled through the complete list of boot parameters, you return to the boot prompt. To reboot
with your changes taking effect, type @ (the at-sign), and press Enter.
[Acme Packet Boot]: @
The Oracle USM completes the full booting sequence, unless there is an error in the boot parameters.
If you have configured boot parameters correctly, the system prompt displays and you can go ahead with
configuration, management, or monitoring tasks.
Note: If you have configured the boot parameters incorrectly, the Oracle USM goes into a booting loop
and displays an error message.
Error loading file: errno = 0x226.
Can't load boot file!!
Press the space bar to stop the loop. Correct the error, and reboot your system.
Acme Packet 6000 Boot Parameters
The Acme Packet 6000’s boot parameters are slightly different than the Acme Packet 4500’s boot parameters. Boot
parameters specify the information your Acme Packet 6000 uses at boot time when it prepares to run the software
image. The boot parameters:
•
Show the Oracle USM’s IPv4 address for the management interface (wancom0)
Oracle® Communications Unified Session Manager
49
Getting Started with the Oracle USM
•
•
•
Allow you to set a system prompt
Determine the software image and its location
Configures the external (T)FTP server used for a net boot
Configuring boot parameters has repercussions for the Oracle USM’s physical and network interface configurations.
When you configure these interfaces, you can set values that might override the boot parameters.
The following is a screen capture of the bootparam configuration list:
[Acme Boot]: p
Boot File
IP Address
VLAN
Netmask
Gateway
Host IP
FTP username
FTP password
Flags
Target Name
Console Device
Console Baudrate
Other
[Acme Boot]: ?
?
@
p
c
v
r
s
:
:
:
:
:
:
:
:
:
:
:
:
:
/boot/bzImage-bones64
172.44.12.89
255.255.0.0
172.44.0.1
0x00000030
ACMEPACKET
COM1
115200
-
print this list
boot (load and go)
print boot params
change boot params
print boot logo with version
reboot
show license information
Boot flags:
0x02 - enable kernel debug
0x04 - disable crashdumps
0x08 - disable bootloader countdown
0x10 - enable debug login
0x40 - use DHCP for wancom0
0x80 - use TFTP instead of FTP
Boot File — The name and path of the software image you are booting. Include the absolute path for a local boot
from the local /boot volume and for a net boot when a path on the FTP server is needed.
IP Address — IP address of wancom0.
VLAN — VLAN of management network over which this address is accessed.
Note: VLANs over management interfaces are not supported on the Acme Packet 6000
Netmask — Netmask portion of the wancom0 IP Address.
Gateway — Network Gateway that this wancom0 interface uses.
Host IP — IP Address of FTP server to download and execute a software image from.
FTP Username — FTP Server Username.
FTP Password — FTP Server Password.
Flags — Available flags are printed at the end of the bootparam configuration. Only change this under the director of
Oracle personnel.
Target Name — Sets the text to display at every system prompt.
50
Oracle® Communications Unified Session Manager
Getting Started with the Oracle USM
Console Device — Set this to COM1
Console Baud Rate — The speed in bits per second which the console port operates at. It operates at 115200 BPS, 8
data bits, no stop bit, parity NONE.
Other — Unused.
Setting Up System Basics
Before configuring and deploying the Oracle USM, you might want to establish some basic attributes such as a
system prompt, new User and Superuser passwords, and NTP synchronization.
New System Prompt
The ACLI system prompt is set in the boot parameters. To change it, access the boot parameters and change the target
name value to make it meaningful within your network. The target name may be up to 38 characters. A value that
identifies the system in some way is often helpful.
Using the Oracle USM Image
The Oracle USM arrives with the most recent, manufacturing-approved run-time image installed on the flash memory.
If you want to use this image, you can install the Oracle USM as specified in the Acme Packet Hardware Installation
Guide , establish a connection to the Oracle USM, and begin to configure it. On boot up, the system displays
information about certain configurations not being present. You can dismiss these displays and begin configuring the
Oracle USM.
If you want to use an image other than the one installed on the Oracle USM when it arrives, you can use the
information in this section to obtain and install the image.
Software Images (USM/CSM)
USM/CSM software image filenames for S-CZ7.2.5 and higher end with the .bz extension. They should be placed in
the /boot volume.
Obtaining a New Image
You can download a software image onto the Oracle USM platform from the following sources.
•
•
Obtain an image from the SFTP site and directory where you or your Oracle customer support representative
placed the image. For example, this may be a special server that you use expressly for images and backups.
Obtain an image from your Oracle customer support representative, who will transfer it to your system.
Regardless of the source, use SFTP to copy the image from the source to the Oracle USM.
Copy an Image to the Oracle USM using SFTP
The /boot directory on the Oracle USM has 32mb available, and operating system files of approximately 9mb each.
Oracle recommends storing no more than two images at a time in this location. One of these should be the latest
version. The /boot directory is used for the on-board system flash memory. If you do not put the image in this
directory, the Oracle USM will not find it.
To copy an image on your Oracle USM using SFTP:
1. Go to the directory where the image is located.
2. Check the IP address of the Oracle USM’s management port (wancom0). (You might think of this as a
management address since it is used in the management of your Oracle USM.)
3. Create the connection to the Oracle USM.
Oracle® Communications Unified Session Manager
51
Getting Started with the Oracle USM
There is a wide variety of methods to establish SFTP access to your system. For example, Linux systems allow
SFTP operation from a terminal. For a windows system, there are many GUI applications that provide SFTP.
Using your SFTP application, start an SFTP session to the IPv4 address of the Oracle USM management port
(wancom0). An SFTP username and SFTP password is required to start the session. The username is always user,
and the password is the your User mode login password.
4. Set your SFTP application to copy the image to the /boot folder using binary transfer mode.
5. Invoke and confirm your SFTP file transfer to the device.
6. Boot the Oracle USM using the image you just transferred.
In the ACLI, change any boot configuration parameters that need to be changed. It is especially important to
change the filename boot parameter to the filename you used during the SFTP process. Otherwise, your system
will not boot properly.
Alternatively, from the console you can reboot to access the boot prompt and then configure boot parameters from
there.
7. In the ACLI, execute the save-config command in order to save your changes.
8. Reboot the Oracle USM.
9. The Oracle USM runs through its loading processes and returns you to the ACLI logon prompt.
System Image Filename
The system image filename is a name you set for the image. This is also the filename the boot parameters uses when
booting your system. This filename must match the filename specified in the boot parameters. When you use it in the
boot parameters, it should always start with /boot to signify that the Oracle USM is booting from the /boot directory.
If the filename set in the boot parameters does not point to the image you want sent to the Oracle USM via SFTP, then
you could not only fail to load the appropriate image, but you could also load an image from a different directory or
one that is obsolete for your purposes. This results in a boot loop condition that you can fix by stopping the
countdown, entering the appropriate filename, and rebooting the Oracle USM.
Booting an Image on Your Oracle USM
You can either boot your Oracle USM from the system’s local storage or from an external device. Both locations can
store images from which the system can boot. This section describes both booting methods.
For boot parameters to go into effect, you must reboot your Oracle USM. Since a reboot stops all call processing,
Oracle recommends performing tasks that call for a reboot during off-peak hours. If your Oracle USMs are set up in
an HA node, you can perform these tasks on the standby system first.
Booting from Flash Memory
Once you have installed an image, you can boot your Oracle USM from its flash memory. With the exception of
testing an image before you install it on the flash memory, this is generally the method you use for booting.
To boot from your Oracle USM flash memory:
1. Confirm that the boot parameters are set up correctly, and make any necessary changes.
You can check the boot configuration parameters by accessing the bootparam command from the configure
terminal menu.
ORACLE# configure terminal
ORACLE# bootparam
2. Change any boot configuration parameters that you need to change. It is especially important to change the file
name boot configuration parameter. The file name parameter needs to use the /boot value so that the Oracle USM
boots from the flash.
3. Reboot your Oracle USM.
52
Oracle® Communications Unified Session Manager
Getting Started with the Oracle USM
4. You are be returned to the ACLI login prompt. To continue with system operations, enter the required password
information.
Booting from an External Device
Booting from an external device means that your Oracle USM connects to a server to retrieve the boot image at boot
time. Rather than using an image stored on your system’s flash memory, it downloads the image from the external
device each time it reboots.
When you are testing a new image before putting it on your Oracle USM, you might want to boot from an external
device. Ordinarily, you would not want to boot an image on your Oracle USM this way.
To boot an image from an external device:
1. Confirm that the Oracle USM is cabled to the network from which you are booting. This is port 0 on the rear panel
of the Oracle USM chassis (wancom0). The image is loaded from the source using FTP.
2. Log into the system you want to mount.
3. On the Oracle USM, configure the information for the boot parameters and confirm the following:
•
boot device—device to which you will FTP
•
This parameter value must contain the name of the applicable management interface, and then the number of
the appropriate 10/100 port. Usually, this value is wancom0.
file name—name on the host of the file containing the image
The image file must exist in the home directory of the user on the image source.
host inet—IPv4 address of the device off of which you are booting
gateway inet—IPv4 address of the gateway to use if the device from which you are booting is not on the same
network as your Oracle USM
• user—username for the FTP account on the boot host
• password—password for the FTP account on the boot host
4. Reboot your Oracle USM.
5. You are returned to the ACLI login prompt. To continue with system operations, enter the required password
information.
•
•
Provisioning Entitlements
The Oracle USM may be self-licensed at the ACLI. Licensing a system for use consists of setting the system type,
then setting the desired entitlements.
Note: You may continue using the legacy licensing system or you may transition to self-provisioning
entitlements. In both cases, ensure that your system's functionality abides by your organization's contractual
obligations with Oracle.
Enabling functionality on the Oracle USM is based on installing feature and entitlements. These determine the feature
groups that are available for use.
For the Oracle USM, the system provisions a set of default entitlements. You can then choose the user-provisioned
entitlements for your deployment.
Entitlements and Entitlement Groups
The following features are entitlements that you may enable on your system:
•
•
•
•
•
Accounting
Administrative Security with ACP/NNC
IPv6
Load Balancing (Session Agent Groups)
Policy Server, which encompasses External BW Mgmt, External CLF Mgmt, and Ext Policy Server
Oracle® Communications Unified Session Manager
53
Getting Started with the Oracle USM
•
•
QoS
SIPREC
Note: If fewer than all of the features that comprise an entitlement group are licensed before setting up
entitlements for the first time, the full entitlement group will be enabled after switching to the entitlements
system.
Provisioning a New System
An uninitialized Oracle USM already has the product type set, and has a set of default entitlements installed. This
allows you to begin operation immediately. A system that has legacy keyed-licenses installed is still considered an
uninitialized system.
The setup entitlements command allows the user to provision further entitlements.
Note: The setup product command is visible, but not relevant to this release.
Provisioning a System with Existing Keyed Licenses
When changing your Oracle USM's licensing technique from the legacy keyed licenses method to the provisioned
entitlements method, be aware of the following:
•
•
•
•
After first running setup entitlements, your system will be "seeded" with the existing licenses' functionality.
Once your system has been seeded with its prior, keyed functionality to the provisioned entitlements system,
functionality may be changed with the setup entitlements command.
You may notice that there are fewer entitlements than there were keyed licenses; this is normal.
After setting up provisioned entitlements, the show features command will still function to display the previously
installed keyed entitlements.
Editing and Viewing Entitlements
If you are not changing the product type, and you are only changing the entitlements, you can edit the existing
entitlements with the setup entitlements command. Executing this command will first display existing entitlements
before giving you the option to modify their settings.
The show entitlements command is used to display the currently provisioned entitlements and keyed entitlements.
You may also use the setup entitlements command and type d to display the current entitlements. Additionally, upon
first executing the setup entitlements command, all provisioned entitlements (excluding keyed entitlements) are
displayed on the screen.
Keyed-only entitlements
Certain entitlements can only be enabled by entering a license key in the system > license configuration element, and
not through the setup entitlements command. Contact Oracle support about purchasing these licenses and receiving a
valid code to enter in your system.
The Keyed-only entitlements used in conjunction with provisioned entitlements:
•
•
•
Lawful Intercept
Codecs including EVRC family and AMR family
Software TLS
Note: not all of the above keyed only entitlements are available for all platforms.
Setting Entitlements on HA Pairs
When setting up an HA pair, you must provision the same product type and entitlements on each system.
54
Oracle® Communications Unified Session Manager
Getting Started with the Oracle USM
Entitlements Configuration
1. Type setup entitlements at the ACLI. Currently provisioned entitlements are printed on the screen.
2. Type the number of the entitlement you wish to configure followed by pressing the <Enter> Key. Some
entitlements are set as enabled/disabled (provisionable feature entitlement), and some entailments are provisioned
with a maximum capacity value (provisionable capacity entitlement). The command will let you provision these
values as appropriate.
3. Type enabled or disabled to set a provisionable feature entitlement, or type an integer value for a provisionable
capacity entitlement. Both input types are followed by pressing the <Enter> key.
4. Repeat steps 2 and 3 to configure additional entitlements.
5. Type d followed by the <Enter> key to review the full range of your choices. Note that disabled entitlements
display their state as blank.
6. Type s followed by the <Enter> key to commit your choice as an entitlement for your system. After saving the
value succeeds you will be returned to the ACLI.
7. Reboot your Oracle USM.
Keyed Licenses and Provisioned Entitlements Compatibility
The Oracle USM supports keyed licenses and the provisioned entitlements process for provisioning features on the
system. Know the following about how licensing mechanisms work with each other.
•
•
•
•
•
You are not required to begin using the provisioned entitlement system as of this release.
You may continue to obtain keyed licenses and install them as necessary.
Upon migrating to the provisioned entitlements system, the current range of your installed, keyed licenses will be
seeded to the provisioned entitlements system. The system's functionality will remain identical.
If you upgrade to the provisioned entitlements system, then downgrade the software to a version without the
provisioned entitlements system, the pre-existing keyed licenses will still function.
If you upgrade to the provisioned entitlements system, then change the functionality (such as, adding more SIP
sessions or removing a feature set), upon downgrade to a pre-provisioned entitlements image, the new
functionality will not be present.
Obtaining a License
If you choose to add functionality to your Oracle USM, each new feature will require its own key. To obtain
additional licenses for functions on your Oracle USM, contact your customer support or sales representative directly
or at support@acmepacket.com. You can request and purchase a license for the software you want, obtain a key for it,
and then activate it on your Oracle USM.
When you obtain licenses, you need to provide Oracle with the serial number of your Oracle USM. You can see the
system’s serial number by using the ACLI show version boot command.
Trial License
Oracle offers a trial license for software components to allow testing a feature before deployment.
A trial license is active for specified period of time. When the trial license expires, the feature stops responding and
the system removes the configuration selections. To continue using the feature you must obtain a license. For more
information about licensing, contact your Oracle sales representative or technical support representative.
Standalone System Licensing
This section shows you how to add licenses and delete them from standalone Oracle USMs. The process for two
systems making up an HA node is different, so follow the procedure relevant to your configuration.
Adding a License to a Standalone System
Once you have obtained a license key, you can add it to your Oracle USM and activate it.
Oracle® Communications Unified Session Manager
55
Getting Started with the Oracle USM
To add and activate a license on your Oracle USM:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
2. Type system and press Enter.
ORACLE(configure)# system
ORACLE(system)#
3. Type license and press Enter.
ORACLE(system)# license
ORACLE(license)#
4. Using the add command and the key generated by Oracle, add the license to your Oracle USM.
ORACLE(license)# add sl25o39pvtqhas4v2r2jc1oaen9e01o21b1dmh3
5. You can check that the license has been added by using the ACLI show command within the license configuration.
ORACLE(license)# show
1: MGCP
2: High Availability
3: Accounting
4: SIP
5: H323
6: 250 sessions, ACP
7: QOS
ORACLE(license)#
6. To activate your license, type the activate-config command and press Enter. The Oracle USM then enables any of
the processes that support associated features.
ORACLE# activate-config
Deleting a License from a Standalone System
You can delete a license from your Oracle USM, including licenses that have not expired. If you want to delete a
license that has not expired, you need to confirm the deletion.
To delete a license from the Oracle USM:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
2. Type system and press Enter.
ORACLE(configure)# system
ORACLE(system)#
3. Type license and press Enter.
ORACLE(system)# license
ORACLE(license)#
4. Type the no command and press Enter. A list of possible licenses to delete appears.
ORACLE(license)# no
feature:
1: MGCP
2: High Availability
3: Accounting
4: SIP
5: H323
6: 250 sessions, ACP
7: QOS
selection:
5. Type the number corresponding to the license you want to delete and press Enter.
56
Oracle® Communications Unified Session Manager
Getting Started with the Oracle USM
selection:7
6. If the license has not expired, you are be asked to confirm the deletion.
Delete unexpired license [y/n]?: y
ORACLE(license)#
When you show the licenses, the one you deleted should no longer appear on the list.
7. To clear the license from the system, type the activate-config command and press Enter. The Oracle USM then
disables any of the processes that support associated features.
ORACLE# activate-config
Viewing Licenses
There are two ways to view licenses in the ACLI.
•
You can use the show features command at the main ACLI user prompt.
•
ORACLE# show features
Total session capacity: 2250
Enabled protocols: SIP, MGCP, H.323, IWF
Enabled features: ACP
ORACLE#
Within the license menu, use the show command to see all licenses with detailed information.
ORACLE(license)# show
License #1: 2000 sessions, SIP, MGCP, ACP
no expiration
installed at 12:34:42 APR 01 2005
License #2: H323
expired at 23:59:59 APR 08 2005
installed at 12:35:43 APR 01 2005
License #3: 250 sessions, IWF
expires at 23:59:59 APR 28 2005
installed at 12:36:44 APR 01 2005
License #4: QOS
starts at 00:00:00 APR 08 2004
expires at 23:59:59 OCT 27 2005
installed at 12:37:45 APR 01 2005
Total session capacity: 2250
ORACLE(license)#
High Availability (HA) Pair Licensing
When adding and deleting licenses, you must perform the procedure across both members of an HA pair during the
same service window. The licenses on each peer must be identical. Peers with mismatched licenses may exhibit
unexpected behavior.
Adding a License to an HA Node
To add a license to both systems in an HA node, you add your licenses to both systems and reboot both systems when
they are in standby mode. The process requires that you carefully confirm system synchronization in between various
steps.
This procedure uses the designations Oracle USM1 as the original active and Oracle USM2 as the original standby.
To add a license on systems in an HA node:
1. Confirm that Oracle USM1 and Oracle USM2 are synchronized.
You must make sure that all of the running and current configurations on Oracle USM1 and Oracle USM2 have
the same number. In the examples below, all of the configuration versions are 5.
•
On Oracle USM1 and Oracle USM2, use the ACLI show health command to make sure that all processes are
synchronized.
Oracle® Communications Unified Session Manager
57
Getting Started with the Oracle USM
•
•
On Oracle USM1, show the current configuration version by using the ACLI display-current-cfg-version
command. Then use the same command on Oracle USM2 and be sure that its current configuration version is
the same as the one on Oracle USM1.
ORACLE1# display-current-cfg-version
Current configuration version is 5
ORACLE1#
ORACLE2# display-current-cfg-version
Current configuration version is 5
ORACLE2#
On Oracle USM1, show the running configuration version by using the ACLI display-running-cfg-version
command. Then use the same command on Oracle USM2 and be sure that its running configuration version is
the same as the one on Oracle USM1.
ORACLE1# display-running-cfg-version
Running configuration version is 5
ORACLE1#
ORACLE2# display-running-cfg-version
Running configuration version is 5
ORACLE2#
2. Now you can add a license to SBC1. To begin, type configure terminal and press Enter.
ORACLE1# configure terminal
ORACLE1(configure)#
3. Type system and press Enter.
ORACLE1(configure)# system
ORACLE1(system)#
4. Type license and press Enter.
ORACLE1(system)# license
ORACLE1(license)#
5. Using the add command and the key generated by Oracle, add the license to your Oracle USM.
ORACLE1(license)# add sjkl4i45987p43hh0938hnhjlaie10983
6. You can check that the license has been added by using the ACLI show command within the license configuration.
ORACLE1(license)# show
1: MGCP
2: High Availability
3: Accounting
4: SIP
5: H323
6: 250 sessions, ACP
7: QOS
ORACLE1(license)#
7. Repeat typing exit, pressing Enter after each entry, until you reach the main Superuser prompt.
ORACLE1(license)# exit
ORACLE1(system)# exit
ORACLE1(configure)# exit
ORACLE1#
8. Repeat steps 2 through 7 on SBC2.
ORACLE2(license)# add [License for SBC2]
At the end of this step, licenses are installed and verified on both SBC1 and SBC2.
9. Return to SBC1 and type the save-config command and press Enter.
ORACLE1# save-config
10. Type the activate-config command and press Enter. The Oracle USM then enables any of the processes that
support associated features.
ORACLE1# activate-config
58
Oracle® Communications Unified Session Manager
Getting Started with the Oracle USM
11. Confirm that Oracle USM1 and Oracle USM2 are synchronized.
You must make sure that all of the running and current configurations on Oracle USM1 and Oracle USM2 have
the same number. In the examples below, all of the configuration versions are 6.
•
•
•
On Oracle USM1 and Oracle USM2, use the ACLI show health command to make sure that all processes are
synchronized.
On Oracle USM1, show the current configuration version by using the ACLI display-current-cfg-version
command. Then use the same command on Oracle USM2 and be sure that its current configuration version is
the same as the one on Oracle USM1.
ORACLE1# display-current-cfg-version
Current configuration version is 6
ORACLE1#
ORACLE2# display-current-cfg-version
Current configuration version is 6
ORACLE2#
On Oracle USM1, show the running configuration version by using the ACLI display-running-cfg-version
command. Then use the same command on Oracle USM2 and be sure that its running configuration version is
the same as the one on Oracle USM1.
ORACLE1# display-running-cfg-version
Running configuration version is 6
ORACLE1#
ORACLE2# display-running-cfg-version
Running configuration version is 6
ORACLE2#
12. Execute the ACLI show health command to make sure that all processes are synchronized.
13. Return to SBC2 and execute the reboot command.
ORACLE2# reboot
14. Reconfirm that Oracle USM1 and Oracle USM2 are synchronized.
You must make sure that all of the running and current configurations on Oracle USM1 and Oracle USM2 have
the same number. In the examples below, all of the configuration versions are 6.
•
•
•
On Oracle USM1 and Oracle USM2, use the ACLI show health command to make sure that all processes are
synchronized.
On Oracle USM1, show the current configuration version by using the ACLI display-current-cfg-version
command. Then use the same command on Oracle USM2 and be sure that its current configuration version is
the same as the one on Oracle USM1.
ORACLE1# display-current-cfg-version
Current configuration version is 6
ORACLE1#
ORACLE2# display-current-cfg-version
Current configuration version is 6
ORACLE2#
On Oracle USM1, show the running configuration version by using the ACLI display-running-cfg-version
command. Then use the same command on Oracle USM2 and be sure that its running configuration version is
the same as the one on Oracle USM1.
ORACLE1# display-running-cfg-version
Running configuration version is 6
ORACLE1#
ORACLE2# display-running-cfg-version
Running configuration version is 6
ORACLE2#
15. Trigger a switchover between the two systems in the HA node so the originally standby system assumes the active
role. This means that the standby system will transition to active.
ORACLE1# notify berpd force
Oracle® Communications Unified Session Manager
59
Getting Started with the Oracle USM
16. Wait for Oracle USM2 to transition to the active state. Confirm that it is in the active state by using the ACLI
show health command.
17. Reconfirm that Oracle USM1 and Oracle USM2 are synchronized.
You must also make sure that all of the running and current configurations on Oracle USM1 and Oracle USM2
have the same number. In the examples below, all of the configuration versions are 6.
•
•
•
On Oracle USM1 and Oracle USM2, use the ACLI show health command to make sure that all processes are
synchronized.
On Oracle USM2, show the current configuration version by using the ACLI display-current-cfg-version
command. Then use the same command on Oracle USM1 and be sure that its current configuration version is
the same as the one on Oracle USM2.
ORACLE2# display-current-cfg-version
Current configuration version is 6
ORACLE2#
ORACLE1# display-current-cfg-version
Current configuration version is 6
ORACLE1#
On Oracle USM2, show the running configuration version by using the ACLI display-running-cfg-version
command. Then use the same command on Oracle USM1 and be sure that its running configuration version is
the same as the one on Oracle USM2.
ORACLE2# display-running-cfg-version
Running configuration version is 6
ORACLE2#
ORACLE1# display-running-cfg-version
Running configuration version is 6
ORACLE1#
18. Return to SBC1 and execute the reboot command.
ORACLE1# reboot
19. Wait for SBC1 to complete rebooting. When finished, execute the ACLI show health command to make sure that
all processes are synchronized.
At this point both SBCs should be synchronized and contain the same license configuration.
20. If desired, trigger a switchover between the two systems in the HA node so the originally active system (SBC1)
assumes the active role.
ORACLE2# notify berpd force
At this point both SBCs should be synchronized and contain the same license configuration.
Deleting a License from an HA Node
To delete a license from both systems in an HA node, you remove your licenses from both systems and reboot both
systems when they are in standby mode. The process requires that you carefully confirm system synchronization in
between various steps.
Note: Licenses should be deleted on both nodes during the same service window.
This procedure uses the designations Oracle USM1 as the original active and Oracle USM2 as the original standby.
To delete a license from systems in an HA node:
1. Confirm that Oracle USM1 and Oracle USM2 are synchronized.
You must make sure that all of the running and current configurations on Oracle USM1 and Oracle USM2 have
the same number. In the examples below, all of the configuration versions are 7.
•
60
On Oracle USM1 and Oracle USM2, use the ACLI show health command to make sure that all processes are
synchronized.
Oracle® Communications Unified Session Manager
Getting Started with the Oracle USM
•
•
On Oracle USM1, show the current configuration version by using the ACLI display-current-cfg-version
command. Then use the same command on Oracle USM2 and be sure that its current configuration version is
the same as the one on Oracle USM1.
ORACLE1# display-current-cfg-version
Current configuration version is 7
ORACLE1#
ORACLE2# display-current-cfg-version
Current configuration version is 7
ORACLE2#
On Oracle USM1, show the running configuration version by using the ACLI display-running-cfg-version
command. Then use the same command on Oracle USM2 and be sure that its running configuration version is
the same as the one on Oracle USM1.
ORACLE1# display-running-cfg-version
Running configuration version is 7
ORACLE1#
ORACLE2# display-running-cfg-version
Running configuration version is 7
ORACLE2#
2. Now you can delete a license from SBC1. To begin, type configure terminal and press Enter.
ORACLE1# configure terminal
ORACLE1(configure)#
3. Type system and press Enter.
ORACLE1(configure)# system
4. Type license and press Enter.
ORACLE1(system)# license
ORACLE1(license)#
5. Type the no command and press Enter. A list of possible license to delete appears.
ORACLE1(license)# no
feature:
1: MGCP
2: High Availability
3: Accounting
4: SIP
5: H323
6: 250 sessions, ACP
7: QOS
selection:
6. Type the number corresponding to the license you want to delete and press Enter.
selection:7
7. If the license has not expired, you are be asked to confirm the deletion.
Delete unexpired license [y/n]?: y
ORACLE1(license)#
When you show the licenses, the one you deleted should no longer appear on the list.
8. Repeat typing exit, pressing Enter after each entry, until you reach the main Superuser prompt.
ORACLE1(license)# exit
ORACLE1(system)# exit
ORACLE1(configure)# exit
ORACLE1#
9. Repeat steps 2 through 8 on SBC2.
ORACLE2(license)# no
feature:
1: MGCP
2: High Availability
Oracle® Communications Unified Session Manager
61
Getting Started with the Oracle USM
3: Accounting
4: SIP
5: H323
6: 250 sessions, ACP
7: QOS
selection:
At the end of this step, licenses are removed and verified on both SBC1 and SBC2.
10. Return to SBC1 and type the save-config command and press Enter.
ORACLE1# save-config
11. Type the activate-config command and press Enter.
ORACLE1# activate-config
12. Confirm that Oracle USM1 and Oracle USM2 are synchronized.
You must make sure that all of the running and current configurations on Oracle USM1 and Oracle USM2 have
the same number. In the examples below, all of the configuration versions are 5.
•
•
•
On Oracle USM1 and Oracle USM2, use the ACLI show health command to make sure that all processes are
synchronized.
On Oracle USM1, show the current configuration version by using the ACLI display-current-cfg-version
command. Then use the same command on Oracle USM2 and be sure that its current configuration version is
the same as the one on Oracle USM1.
ORACLE1# display-current-cfg-version
Current configuration version is 7
ORACLE1#
ORACLE2# display-current-cfg-version
Current configuration version is 7
ORACLE2#
On Oracle USM1, show the running configuration version by using the ACLI display-running-cfg-version
command. Then use the same command on Oracle USM2 and be sure that its running configuration version is
the same as the one on Oracle USM1.
ORACLE1# display-running-cfg-version
Running configuration version is 7
ORACLE1#
ORACLE2# display-running-cfg-version
Running configuration version is 7
ORACLE2#
13. Execute the ACLI show health command to make sure that all processes are synchronized.
14. Return to SBC2 and execute the reboot command.
ORACLE2# reboot
15. Reconfirm that Oracle USM1 and Oracle USM2 are synchronized.
You must make sure that all of the running and current configurations on Oracle USM1 and Oracle USM2 have
the same number. In the examples below, all of the configuration versions are 7.
•
•
On Oracle USM1 and Oracle USM2, use the ACLI show health command to make sure that all processes are
synchronized.
On Oracle USM1, show the current configuration version by using the ACLI display-current-cfg-version
command. Then use the same command on Oracle USM2 and be sure that its current configuration version is
the same as the one on Oracle USM1.
ORACLE1# display-current-cfg-version
Current configuration version is 7
ORACLE1#
ORACLE2# display-current-cfg-version
Current configuration version is 7
ORACLE2#
62
Oracle® Communications Unified Session Manager
Getting Started with the Oracle USM
•
On Oracle USM1, show the running configuration version by using the ACLI display-running-cfg-version
command. Then use the same command on Oracle USM2 and be sure that its running configuration version is
the same as the one on Oracle USM1.
ORACLE1# display-running-cfg-version
Running configuration version is 7
ORACLE1#
ORACLE2# display-running-cfg-version
Running configuration version is 7
ORACLE2#
16. Trigger a switchover between the two systems in the HA node so the originally standby system assumes the active
role. This means that the originally standby system will transition to active.
ORACLE1# notify berpd force
17. Wait for Oracle USM2 to transition to the active state. Confirm that it is in the active state by using the ACLI
show health command.
18. Reconfirm that Oracle USM1 and Oracle USM2 are synchronized.
You must also make sure that all of the running and current configurations on Oracle USM1 and Oracle USM2
have the same number. In the examples below, all of the configuration versions are 8.
•
•
•
On Oracle USM1 and Oracle USM2, use the ACLI show health command to make sure that all processes are
synchronized.
On Oracle USM2, show the current configuration version by using the ACLI display-current-cfg-version
command. Then use the same command on Oracle USM1 and be sure that its current configuration version is
the same as the one on Oracle USM2.
ORACLE2# display-current-cfg-version
Current configuration version is 7
ORACLE2#
ORACLE1# display-current-cfg-version
Current configuration version is 7
ORACLE1#
On Oracle USM2, show the running configuration version by using the ACLI display-running-cfg-version
command. Then use the same command on Oracle USM1 and be sure that its running configuration version is
the same as the one on Oracle USM2.
ORACLE2# display-current-cfg-version
Current configuration version is 7
ORACLE2#
ORACLE1# display-current-cfg-version
Current configuration version is 7
ORACLE1#
19. Return to SBC1 and execute the reboot command.
ORACLE1# reboot
20. Wait for SBC1 to complete rebooting. When finished, execute the ACLI show health command to make sure that
all processes are synchronized.
21. If desired, trigger a switchover between the two systems in the HA node so the originally active system (SBC1)
assumes the active role.
ORACLE2# notify berpd force
At this point both SBCs should be synchronized and contain the same license configuration.
RADIUS Authentication
A security feature that extends beyond the designation of ACLI User and Superuser privileges, the User
Authentication and Access control feature supports authentication using your RADIUS server(s). In addition, you can
set two levels of privilege, one for all privileges and more limited set that is read-only.
Oracle® Communications Unified Session Manager
63
Getting Started with the Oracle USM
User authentication configuration also allows you to use local authentication, localizing security to the Oracle USM
ACLI log-in modes. These modes are User and Superuser, each requiring a separate password.
The components involved in the RADIUS-based user authentication architecture are the Oracle USM and your
RADIUS server(s). In these roles:
•
•
The Oracle USM restricts access and requires authentication via the RADIUS server; the Oracle USM
communicates with the RADIUS server using either port 1812 or 1645, but does not know if the RADIUS server
listens on these ports
Your RADIUS server provides an alternative method for defining Oracle USM users and authenticating them via
RADIUS; the RADIUS server supports the VSA called ACME_USER_CLASS, which specifies what kind of user
is requesting authentication and what privileges should be granted.
The Oracle USM also supports the use of the Cisco Systems Inc.™ Cisco-AVPair vendor specific attribute (VSA).
This attribute allows for successful administrator login to servers that do not support the Oracle authorization
VSA. While using RADIUS-based authentication, the Oracle USM authorizes you to enter Superuser mode
locally even when your RADIUS server does not return the ACME_USER_CLASS VSA or the Cisco-AVPair
VSA. For this VSA, the Vendor-ID is 1 and the Vendor-Type is 9. The list below shows the values this attribute
can return, and the result of each:
•
•
•
shell:priv-lvl=15—User automatically logged in as an administrator
shell:priv-lvl=1—User logged in at the user level, and not allowed to become an administrator
Any other value—User rejected
When RADIUS user authentication is enabled, the Oracle USM communicates with one or more configured RADIUS
servers that validates the user and specifies privileges. On the Oracle USM, you configure:
•
•
•
What type of authentication you want to use on the Oracle USM
If you are using RADIUS authentication, you set the port from which you want the Oracle USM to send messages
If you are using RADIUS authentication, you also set the protocol type you want the Oracle USM and RADIUS
server to use for secure communication
Although most common set-ups use two RADIUS servers to support this feature, you are allowed to configure up to
six. Among other settings for the server, there is a class parameter that specifies whether the Oracle USM should
consider a specific server as primary or secondary. As implied by these designation, the primary servers are used first
for authentication, and the secondary servers are used as backups. If you configure more than one primary and one
secondary server, the Oracle USM will choose servers to which it sends traffic in a round-robin strategy. For example,
if you specify three servers are primary, the Oracle USM will round-robin to select a server until it finds an
appropriate one; it will do the same for secondary servers.
The VSA attribute assists with enforcement of access levels by containing one of the three following classes:
•
•
•
None—All access denied
User—Monitoring privileges are granted; your user prompt will resemble ORACLE>
Admin—All privileges are granted (monitoring, configuration, etc.); your user prompt will resemble ORACLE#
Once it has selected a RADIUS server, the Oracle USM initiates communication and proceeds with the authentication
process. The authentication process between the Oracle USM and the RADIUS server takes place uses one of three
methods, all of which are defined by RFCs:
Protocol
RFC
PAP (Password Authentication
Protocol)
B. Lloyd and W. Simpson, PPP Authentication Protocols, RFC 1334,
October 1992
CHAP (Challenge Handshake
Authentication Protocol)
B. Lloyd and W. Simpson, PPP Authentication Protocols, RFC 1334,
October 1992
W. Simpson, PPP Challenge Handshake Authentication Protocol (CHAP),
RFC 1994, August 1996
64
Oracle® Communications Unified Session Manager
Getting Started with the Oracle USM
Protocol
RFC
MS-CHAP-V2
G. Zorn, Microsoft PPP CHAP Extensions, Version 2, RFC 2759, January
2000
Note: MS-CHAP-V2 support includes authentication only; password exchange is not supported or allowed on
the Oracle USM.
PAP Handshake
For PAP, user credentials are sent to the RADIUS server include the user name and password attribute. The value of
the User-Password attribute is calculated as specified in RFC 2865.
PAP Client Request Example
Radius Protocol
Code: Access Request (1)
Packet identifier: 0x4 (4)
Length: 61
Authenticator: 0x0000708D00002C5900002EB600003F37
Attribute value pairs
t:User Name(1) l:11, value:”TESTUSER1”
User-Name: TESTUSER1
t:User Password (2) l:18, value:739B3A0F25094E4B3CDA18AB69EB9E4
t:NAS IP Address(4) l:6, value:168.192.68.8
Nas IP Address: 168.192.68.8(168.192.68.8)
t:NAS Port(5) l:6, value:118751232
PAP RADIUS Response
Radius Protocol
Code: Access Accept (2)
Packet identifier: 0x4 (4)
Length: 20
Authenticator: 0x36BD589C1577FD11E8C3B5BB223748
CHAP Handshake
When the authentication mode is CHAP, the user credentials sent to the RADIUS server include “username,” “CHAPPassword,” and “CHAP-Challenge.” The “CHAP-Password” credential uses MD-5 one way. This is calculated over
this series of the following values, in this order: challenge-id (which for the Oracle USM is always 0), followed by the
user password, and then the challenge (as specified in RFC 1994, section 4.1).
Oracle® Communications Unified Session Manager
65
Getting Started with the Oracle USM
CHAP Client Request Example
Radius Protocol
Code: Access Request (1)
Packet identifier: 0x5 (5)
Length: 80
Authenticator: 0x0000396C000079860000312A00006558
Attribute value pairs
t:User Name(1) l:11, value:”TESTUSER1”
User-Name: TESTUSER1
t:CHAP Password (3) l:19, value:003D4B1645554E881231ED7A137DD54FBF
t:CHAP Challenge (60) l:18, value: 000396C000079860000312A00006558
t:NAS IP Address(4) l:6, value:168.192.68.8
Nas IP Address: 168.192.68.8(168.192.68.8)
t:NAS Port(5) l:6, value:118751232
CHAP RADIUS Response
Radius Protocol
Code: Access Accept (2)
Packet identifier: 0x4 (4)
Length: 20
Authenticator: 0x3BE89EED1B43D91D80EB2562E9D65392
MS-CHAP-v2 Handshake
When the authentication method is MS-CHAP-v2, the user credentials sent to the RADIUS server in the AccessRequest packet are:
•
•
•
username
MS-CHAP2-Response—Specified in RFC 2548, Microsoft vendor-specific RADIUS attributes
MS-CHAP2-Challenge—Serves as a challenge to the RADIUS server
If the RADIUS authentication is successful, the Access-Accept packet from the RADIUS server must include an MSCHAP2-Success attribute calculated using the MS-CHAP-Challenge attribute included in the Access-Request. The
calculation of MS-CHAP2-Success must be carried out as specified in RFC 2759. The Oracle USM verifies that the
MS-CHAP2-Success attribute matches with the calculated value. If the values do not match, the authentication is
treated as a failure.
MS-CHAP-v2 Client Request Example
Some values have been abbreviated.
Radius Protocol
Code: Access Request (1)
Packet identifier: 0x5 (5)
Length: 80
Authenticator: 0x0000024C000046B30000339F00000B78
Attribute value pairs
t:User Name(1) l:11, value:”TESTUSER1”
User-Name: TESTUSER1
t:Vendor Specific(26) l:24, vendor:Microsoft(311)
t:MS CHAP Challenge(11) l:18, value:0000024C000046B30000339F00000B78
t:Vendor Specific(26) l:58, vendor:Microsoft(311)
t:MS CHAP2 Response(25) l:52, value:
00000000024C000046B30000339F00000B78...
t:NAS IP Address(4) l:6, value:168.192.68.8
Nas IP Address: 168.192.68.8(168.192.68.8)
t:NAS Port(5) l:6, value:118751232
MS-CHAP-v2 RADIUS Response
Radius Protocol
Code: Access Accept (2)
66
Oracle® Communications Unified Session Manager
Getting Started with the Oracle USM
Packet identifier: 0x6 (6)
Length: 179
Authenticator: 0xECB4E59515AD64A2D21FC6D5F14D0CC0
Attribute value pairs
t:Vendor Specific(26) l:51, vendor:Microsoft(311)
t:MS CHAP Success(11) l:45, value:003533s33d3845443532443135453846313...
t:Vendor Specific(26) l:42, vendor:Microsoft(311)
t:MS MPPE Recv Key(17) l:36, value:96C6325D22513CED178F770093F149CBBA...
t:Vendor Specific(26) l:42, vendor:Microsoft(311)
t:MS MPPE Send Key(16) l:36, value:9EC9316DBFA701FF0499D36A1032678143...
t:Vendor Specific(26) l:12, vendor:Microsoft(311)
t:MS MPPE Encryption Policy(7) l:6, value:00000001
t:Vendor Specific(26) l:12, vendor:Microsoft(311)
t:MS MPPE Encryption Type(8) l:6, value:00000006
Management Protocol Behavior
When you use local authentication, management protocols behave the same way that they do when you are not using
RADIUS servers. When you are using RADIUS servers for authentication, management protocols behave as
described in this section.
•
•
•
•
•
•
Telnet—The “user” or admin accounts are authenticated locally, not via the RADIUS server. For all other
accounts, the configured RADIUS servers are used for authentication. If authentication is successful, the user is
granted privileges depending on the ACME_USER_CLASS VSA attribute.
FTP—The “user” or admin accounts are authenticated locally, not via the RADIUS server. For all other accounts,
the configured RADIUS servers are used for authentication.
SSH in pass-through mode—When SSH is in pass through mode, the Oracle USM behave the same way that it
does for Telnet.
SSH in non-pass-through mode—When you create an SSH account on the Oracle USM, you are asked to supply a
user name and password. Once local authentication succeeds, you are prompted for the ACLI user name and
password. If your user ACLI name is user, then you are authenticated locally. Otherwise, you are authenticated
using the RADIUS server. If RADIUS authentication is successful, the privileges you are granted depend on the
ACME_USER_CLASS VSA attribute.
SFTP in pass-through mode—If you do not configure an SSH account on the Oracle USM, the RADIUS server is
contacted for authentication for any user that does not have the user name user. The Oracle USM uses local
authentication if the user name is user.
SFTP in non-pass-through mode—The “user” or admin accounts are authenticated locally, not via the RADIUS
server. For all other accounts, the configured RADIUS servers are used for authentication.
RADIUS Authentication Configuration
To enable RADIUS authentication and user access on your Oracle USM, you need to configure global parameters for
the feature and then configure the RADIUS servers that you want to use.
Global Authentication Settings
To configure the global authentication settings:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type security and press Enter.
ORACLE(configure)# security
3. Type authentication and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(security)# authentication
ORACLE(authentication)#
Oracle® Communications Unified Session Manager
67
Getting Started with the Oracle USM
From here, you can view the entire menu for the authentication configuration by typing a ?. You can set global
parameters for authentication. You can also configure individual RADIUS servers; instructions for configuring
RADIUS server appear in the next section.
4. type—Set the type of user authentication you want to use on this Oracle USM. The default value is local. The
valid values are:
• local | radius
5. protocol—If you are using RADIUS user authentication, set the protocol type to use with your RADIUS server(s).
The default is pap. The valid values are:
• pap | chap | mschapv2
6. source-port—Set the number of the port you want to use from message sent from the Oracle USM to the RADIUS
server. The default value is 1812. The valid values are:
• 1645 | 1812
7. allow-local-authorization—Set this parameter to enabled if you want the Oracle USM to authorize users to enter
Superuser (administrative) mode locally even when your RADIUS server does not return the
ACME_USER_CLASS VSA or the Cisco-AVPair VSA. The default for this parameter is disabled.
RADIUS Server Settings
The parameters you set for individual RADIUS servers identify the RADIUS server, establish a password common to
the Oracle USM and the server, and establish trying times.
Setting the class and the authentication methods for the RADIUS servers can determine how and when they are used
in the authentication process.
To configure a RADIUS server to use for authentication:
1. Access the RADIUS server submenu from the main authentication configuration:
ORACLE(authentication)# radius-servers
ORACLE(radius-servers)#
2. address—Set the remote IP address for the RADIUS server. There is no default value, and you are required to
configure this address.
3. port—Set the port at the remote IP address for the RADIUS server. The default port is set to 1812. The valid
values are:
• 1645 | 1812
4. state—Set the state of the RADIUS server. Enable this parameter to use this RADIUS server to authenticate users.
The default value is enabled. The valid values are:
• enabled | disabled
5. secret—Set the password that the RADIUS server and the Oracle USM share. This password is transmitted
between the two when the request for authentication is initiated; this ensures that the RADIUS server is
communicating with the correct client.
6. nas-id—Set the NAS ID for the RADIUS server. There is no default for this parameter.
7. retry-limit—Set the number of times that you want the Oracle USM to retry for authentication information from
this RADIUS server. The default value is 3. The valid range is:
•
•
Minimum—1
Maximum—5
If the RADIUS server does not respond within this number of tries, the Oracle USM marks is as dead.
8. retry-time—Set the amount of time (in seconds) that you want theOracle USM to wait before retrying for
authentication from this RADIUS server. The default value is 5. The valid range is:
•
•
68
Minimum—5
Maximum—10
Oracle® Communications Unified Session Manager
Getting Started with the Oracle USM
9. dead-time—Set the amount of time in seconds before the Oracle USM retries a RADIUS server that it has
designated as dead because that server did not respond within the maximum number of retries. The default is 10.
The valid range is:
• Minimum—10
• Maximum—10000
10. maximum-sessions—Set the maximum number of outstanding sessions for this RADIUS server. The default value
is 255. The valid range is:
• Minimum—1
• Maximum—255
11. class—Set the class of this RADIUS server as either primary or secondary. A connection to the primary server is
tried before a connection to the secondary server is tried. The default value is primary. Valid values are:
•
primary | secondary
The Oracle USM tries to initiate contact with primary RADIUS servers first, and then tries the secondary
servers if it cannot reach any of the primary ones.
If you configure more than one RADIUS server as primary, the Oracle USM chooses the one with which it
communicates using a round-robin strategy. The same strategy applies to the selection of secondary servers if
there is more than one.
12. authentication-methods—Set the authentication method you want the Oracle USM to use with this RADIUS
server. The default value is pap. Valid values are:
•
all | pap | chap | mschapv2
This parameter has a specific relationship to the global protocol parameter for the authentication configuration,
and you should exercise care when setting it. If the authentication method that you set for the RADIUS server
does not match the global authentication protocol, then the RADIUS server is not used. The Oracle USM
simply overlooks it and does not send authentication requests to it. You can enable use of the server by
changing the global authentication protocol so that it matches.
13. Save your work and activate your configuration.
TACACS+ AAA
TACACS+ (Terminal Access Controller Access Control System Plus) is a protocol originally developed by Cisco
Systems, and made available to the user community by a draft RFC, TACACS+ Protocol, Version 1.78 (draft-granttacacs-02.txt). TACACS+ provides AAA (Authentication, Authorization, and Accounting) services over a secure TCP
connection using Port 49.
TACACS+ Introduction
Like DIAMETER and RADIUS, TACACS+ uses a client/server model in which a Network Access Server (NAS) acts
in the client role and a TACACS+ equipped device (a daemon in TACACS+ nomenclature) assumes the server role.
For purposes of the current implementation, the Oracle Oracle USM functions as the TACACS+ client. Unlike
RADIUS, which combines authentication and authorization, TACACS+ provides three distinct applications to
provide finer grade access control.
Authentication is the process that confirms a user’s purported identity. Authentication is most often based on a simple
username/password association, but other, and more secure methods, are becoming more common. The following
authentication methods are support by the current implementation: simple password, PAP (Protocol Authentication
Protocol), and CHAP (Challenge Handshake Authentication Protocol).
Authorization is the process that confirms user privileges. TACACS+ can provide extremely precise control over
access to system resources. In the current implementation, TACACS+ controls access to system administrative
functions.
Oracle® Communications Unified Session Manager
69
Getting Started with the Oracle USM
TACACS+ provides secure communication between the client and daemon by encrypting all packets. Encryption is
based on a shared-secret, a string value known only to the client and daemon. Packets are encrypted in their entirety,
save for a common TACACS+ header.
The cleartext header contains, among other fields, a version number, a sequence number. and a session ID. Using a
methodology described in Section 5 of the TACACS+ draft RFC, the sender encrypts outbound cleartext messages by
repetitively running the MD5 hash algorithm over the concatenation of the session ID, shared-secret, version number,
and sequence number values, eventually deriving a virtual one-time-pad of the same length as the message body. The
sender encrypts the cleartext message with an XOR (Exclusive OR) operation, using the cleartext message and virtual
one-time-pad as inputs.
The message recipient, who possesses the shared-secret, can readily obtain the version number, sequence number,
session ID, and message length from the cleartext header. Consequently, the recipient employs the same methodology
to derive a virtual one-time-pad identical to that derived by the sender. The recipient decrypts the encrypted message
with an XOR operation, using the encrypted message and virtual one-time-pad as inputs.
Details on TACACS+ are available in the ACLI Configuration Guide.
The TACACS+ implementation is based upon the following internet draft.
draft-grant-tacacs-02.txt, The TACACS+ Protocol Version 1.78
Other relevant documents include
RFC 1321, The MD-5 Message Digest Algorithm
RFC 1334, PPP Authentication Protocols .
RFC 1994, PPP Challenge Handshake Authentication Protocol (CHAP)
TACACS+ Authentication
The Oracle USM uses TACACS+ authentication services solely for the authentication of user accounts.
Administrative users must be authenticated locally by the Oracle USM.
The current TACACS+ implementation supports three types of user authentication: simple password (referred to as
ascii by TACACS+), PAP, and CHAP.
ascii Login
ascii login is analogous to logging into a standard PC. The initiating peer is prompted for a username, and, after
responding, is then prompted for a password.
PAP Login
PAP is defined in RFC 1334, PPP Authentication Protocols. This protocol offers minimal security in that passwords
are transmitted as unprotected cleartext. PAP login differs from ascii login in that the username and password are
transmitted to the authenticating peer in a single authentication packet, as opposed to the two-step prompting process
used in ascii login.
CHAP Login
CHAP is defined in RFC 1994, PPP Challenge Handshake Authentication Protocol. CHAP is a more secure than
PAP in that it is based on a shared-secret (known only to the communicating peers), and therefore avoids the
transmission of cleartext authentication credentials. CHAP operations can be summarized as follows.
After a login attempt, the initiator is tested by the authenticator who responds with a packet containing a challenge
value — an octet stream with a recommended length of 16 octets or more. Receiving the challenge, the initiator
concatenates an 8-bit identifier (carried within the challenge packet header), the shared-secret, and the challenge
value, and uses the shared-secret to compute an MD-5 hash over the concatenated string. The initiator returns the hash
value to the authenticator, who performs the same hash calculation, and compares results. If the hash values match,
authentication succeeds; if hash values differ, authentication fails.
70
Oracle® Communications Unified Session Manager
Getting Started with the Oracle USM
Authentication Message Exchange
All TACACS+ authentication packets consist of a common header and a message body. Authentication packets are of
three types: START, CONTINUE, and REPLY.
START and CONTINUE packets are always sent by the Oracle USM, the TACACS+ client. START packets initiate
an authentication session, while CONTINUE packets provide authentication data requested by the TACACS+
daemon. In response to every client-originated START or CONTINUE, the daemon must respond with a REPLY
packet. The REPLY packet contains either a decision (pass or fail), which terminates the authentication session, or a
request for additional information needed by the authenticator.
TACACS+ Header
The TACACS+ header format is as follows.
+----+----+--------+--------+--------+
|maj |min | type
| seq_no | flags |
|ver |ver |
|
|
|
+----+----+--------+--------+--------+
| session_id
|
+------------------------------------+
| length
|
+------------------------------------+
maj ver
This 4-bit field identifies the TACACS+ major protocol version, and must contain a value of 0xC .
min ver
This 4-bit field identifies the TACACS+ minor protocol version, and must contain either a value of 0x0 (identifying
TACACS+ minor version 0) or a value of 0x1 . (identifying TACACS+ minor version 1). Minor versions 0 and 1
differ only in the processing of PAP and CHAP logins.
type
This 8-bit field identifies the TACACS+ AAA service as follows:
0x1 — TACACS+ Authentication
0x2 — TACACS+ Authorization
0x3 — TACACS+ Accounting
sequence-no
This 8-bit field contains the packet sequence for the current session.
The first packet of a TACACS+ session must contain the value 1; each following packet increments the sequence
count by 1. As TACACS+ sessions are always initiated by the client, all client-originated packets carry an odd
sequence number, and all daemon-originated packets carry an even sequence number. TACACS+ protocol strictures
do not allow the sequence_no field to wrap. If the sequence count reaches 255, the session must be stopped and
restarted with a new sequence number of 1.
flags
This 8-bit field contains flags as described in Section 3 of the draft RFC; flags are not under user control.
session_id
This 32-bit field contains a random number that identifies the current TACACS+ session — it is used by clients and
daemons to correlate TACACS+ requests and responses.
length
This 32-bit field contains the total length of the TACACS+ message, excluding the 12-octet header — in other words,
the length of the message body.
Oracle® Communications Unified Session Manager
71
Getting Started with the Oracle USM
Authentication START Packet
The Oracle USM, acting as a TACACS+ client, sends an authentication START packet to the TACACS+ daemon to
initiate an authentication session. The daemon must respond with a REPLY packet.
The authentication START packet format is as follows.
+-----------------------------------+
|
Common Header
|
|
|
|
type contains 0x1
|
+--------+--------+--------+--------+
|action |priv_lvl|authen_ |service |
|
|
|type
|
|
|--------+--------+--------+--------+
|user_len|port_len|rem_addr|data_len|
|
|
|_len
|
|
+--------+--------+--------+--------+
|
user ...
|
+-----------------------------------+
|
port ...
|
+-----------------------------------+
|
rem-addr ...
|
+-----------------------------------+
|
data ...
|
+-----------------------------------+
action
This 8-bit field contains an enumerated value that identifies the requested authentication action. For the current
TACACS+ implementation, this field always contains a value of 0x01 , indicating user login authentication.
priv_lvl
This 8-bit field contains an enumerated value that identifies the privilege level requested by an authenticating user.
For the current TACACS+ authentication implementation, this field always contains a value of 0x01 , indicating the
user level.
authen-type
This 8-bit field contains an enumerated value that identifies the authentication methodology. Supported values are as
follows:
0x01 ASCII — simple login, Oracle USM prompts for username and password
0x02 PAP — as specified in RFC 1334
0x03 CHAP — as specified in RFC 1994
service
This 8-bit field contains an enumerated value that identifies the service requesting the authentication. For the current
TACACS+ implementation, this field always contains a value of 0x01 , indicating user login authentication.
user_len
This 8-bit field contains the length of the user field in octets.
port_len
This 8-bit field contains the length of the port field in octets. As the port field is not used in the current TACACS+
authentication implementation, the port_len field always contains a value of 0 as specified in Section 4 of the
TACACS+ draft RFC.
rem_addr_len
72
Oracle® Communications Unified Session Manager
Getting Started with the Oracle USM
This 8-bit field contains the length of the rem_addr field in octets. As the rem_addr field is not used in the current
TACACS+ authentication implementation, the rem_addr_len field always contains a value of 0 as specified in Section
4 of the TACACS+ draft RFC.
data_len
This 8-bit field contains the length of the data field in octets.
user
This variable length field contains the login name of the user to be authenticated.
port
This variable length field contains the name of the Oracle USM port on which authentication is taking place.
Following Cisco Systems convention, this field contains the string tty10 .
rem_addr
This variable length field contains the location of the user to be authenticated. This field contains the localhost
address.
data
This optional variable length field contains miscellaneous data.
Authentication REPLY Packet
The TACACS+ daemon sends an authentication REPLY packet to the Oracle USM in response to a authentication
START or authentication CONTINUE packet. Depending on the contents of the status field, the authentication
REPLY packet either ends the authentication transaction, or continues the transaction by requesting addition
information needed by the authenticator.
The authentication REPLY packet format is as follows.
+-----------------------------------+
|
Common Header
|
|
|
|
type contains 0x1
|
+--------+--------+--------+--------+
|
(type field contains 0x1)
|
+--------+--------+-----------------+
| status | flags | server_msg_len |
|--------+--------+--------+--------+
|
data_len
| server_msg ... |
+-----------------+-----------------+
|
data ...
|
+-----------------------------------+
status
This 16-bit field contains an enumerated value that specifies the current state of the authentication process. Supported
values are as follows:
0x01 PASS — the user is authenticated, thus ending the session
0x02 FAIL — the user is rejected, thus ending the session
0x04 GETUSER — daemon request for the user name
0x05 GETPASS — daemon request for the user password
0x06 RESTART — restarts the transaction, possibly because the sequence number has wrapped, or possibly because
the requested authentication type is not supported by the daemon
0x07 ERROR — reports an unrecoverable error
flags
Oracle® Communications Unified Session Manager
73
Getting Started with the Oracle USM
This 8-bit field contains various flags that are not under user control.
server_msg_len
This 16-bit field contains the length of the server_msg field in octets. As the server_msg field is not used in REPLY
packets sent by the current TACACS+ authentication implementation, the server_msg_len field always contains a
value of 0 as specified in Section 4 of the TACACS+ draft RFC.
data_len
This 16-bit field contains the length of the data field in octets. As the data field is not used in REPLY packets sent by
the current TACACS+ authentication implementation, the data_len field always contains a value of 0 as specified in
Section 4 of the TACACS+ draft RFC.
server_msg
This optional variable length field contains a server message intended for display to the user. The current TACACS+
authentication implementation does not use this field.
data
This optional variable length field contains data pertinent to the authentication process. The current TACACS+
authentication implementation does not use this field.
Authentication CONTINUE Packet
The Oracle USM, acting as a TACACS+ client, sends an authentication CONTINUE packet to the TACACS+
daemon in response to a REPLY message which requested additional data required by the authenticator.
The authentication CONTINUE packet format is as follows.
+-----------------------------------+
|
Common Header
|
|
|
|
type contains 0x1
|
+--------+--------+-----------------+
|
user_msg_len |
data_len
|
|--------+--------+-----------------+
| flags |
user_msg ...
|
+--------+--------------------------+
|
data ...
|
+-----------------------------------+
user_msg_len
This 16-bit field contains the length of the user_msg field in octets.
data_len
This 16-bit field contains the length of the data field in octets. As the data field is not used in the current TACACS+
authentication implementation, the data field always contains a value of 0 as specified in Section 4 of the TACACS+
draft RFC.
flags
This 8-bit field contains various flags that are not under user control.
user_msg
This variable length field contains a string that responds to an information request contained in a REPLY message.
data
This optional variable length field contains miscellaneous data, often in response to a daemon request. The current
TACACS+ authentication implementation does not use the data field in Authentication CONTINUE packets.
Authentication Scenarios
Each of the supported user authentication scenarios is described in terms of packet flow in the following sections.
74
Oracle® Communications Unified Session Manager
Getting Started with the Oracle USM
ASCII Authentication
The Oracle USM initiates the authentication with an authentication START packet.
+-----------------------------------+
|
Common Header
|
|
minor_version contains 0x0
|
|
type contains 0x1
|
+--------+--------+--------+--------+
|action |priv_lvl|authen_ |service |
|
|
|type
|
|
| 0x01 | 0x01 | 0x01 | 0x01 |
|--------+--------+--------+--------+
|user_len|port_len|rem_addr|data_len|
|
|
|_len
|
|
|
0
|
N
|
N
|
0
|
+--------+--------+--------+--------+
|
port
|
|
tty10
|
+-----------------------------------+
|
rem_addr
|
|
localhost address
|
+-----------------------------------+
•
•
•
•
•
•
•
•
The action field specifies the requested authentication action — 0x01 for TAC_PLUSAUTHEN_LOGIN
(authentication of a user login).
The priv_lvl field specifies the privilege level requested by the user — 0x01 for TAC_PLUS_PRIV_LVL_USER.
The authen_type field specifies the authentication methodology — 0x01 for
TAC_PLUS_AUTHEN_TYPE_ASCII (simple login).
The service field specifies the requesting service — 0x01 for TAC_PLUS_AUTHEN_SVC_LOGIN (login
service).
The user_len and data_len fields contain a value of 0 , as required by the TACACS+ protocol.
The port_len and rem_addr_len fields contain the length, in octets, of the port and rem_addr fields.
The port field contains the name of the Oracle USM port on which authentication is taking place. Following Cisco
Systems convention, this field contains the string tty10 .
The rem_addr field specifies the location of the user to be authenticated. This field contains the localhost address.
The TCACS+ daemon returns an authentication REPLY requesting the username.
+-----------------------------------+
|
Common Header
|
|
minor_version contains 0x0
|
|
type contains 0x1
|
+--------+--------+-----------------+
| status | flags | server_msg_len |
| 0x04 |
|
0
|
|--------+--------+-----------------+
|
data_len
|
|
0
|
+-----------------+
•
•
The status field specifies a daemon request — 0x04 for TAC_PLUS_AUTH_STATUS_GETUSER (get
username).
The server_msg_len data_len fields both contain a value of 0 , as required by the TACACS+ protocol.
The Oracle USMresponds with an authentication CONTINUE packet.
+-----------------------------------+
|
Common Header
|
|
minor_version contains 0x0
|
|
type contains 0x1
|
+-----------------+-----------------+
|
user_msg_len |
data_len
|
Oracle® Communications Unified Session Manager
75
Getting Started with the Oracle USM
|
|
0
|
|--------+--------+-----------------+
| flags |
user_msg ...
|
+--------+--------------------------+
•
•
•
The user_msg_len field contains the length, in octets, of the user_msg field.
The data_len field contains a value of 0 , as required by the TACACS+ protocol.
The user_msg field contains the username to be authenticated.
The TCACS+ daemon returns a second authentication REPLY requesting the user password.
+-----------------------------------+
|
Common Header
|
|
minor_version contains 0x0
|
|
type contains 0x1
|
+--------+--------+--------+--------+
| status | flags | server_msg_len |
| 0x05 |
|
0
|
|--------+--------+--------+--------+
|
data_len
|
|
0
|
+-----------------+
•
•
The status field specifies a daemon request — 0x05 for TAC_PLUS_AUTH_STATUS_GETPASS (get user
password).
The server_msg_len and data_len fields both contain a value of 0 , as required by the TACACS+ protocol.
The Oracle USM responds with a second authentication CONTINUE packet.
+-----------------------------------+
|
Common Header
|
|
minor_version contains 0x0
|
|
type contains 0x1
|
+-----------------+-----------------+
|
user_msg_len |
data_len
|
|
|
0
|
|--------+--------+--------+--------+
| flags |
user_msg ...
|
+--------+--------------------------+
•
•
•
•
The user_msg_len field contains the length, in octets, of the user_msg field.
The data_len field contains a value of 0 , as required by the TACACS+ protocol.
The user_msg field contains the user password to be authenticated.
Other, optional fields are not used.
The TCACS+ daemon returns a third authentication REPLY reporting the authentication result, and terminating the
authentication session.
+-----------------------------------+
|
Common Header
|
|
minor_version contains 0x0
|
|
type contains 0x1
|
+--------+--------+-----------------+
| status | flags | server_msg_len |
| 0x01 |
|
0
|
|--------+--------+-----------------+
|
data_len
|
|
0
|
+-----------------+
•
•
76
The status field specifies the authentication result — 0x01 for TAC_PLUS_AUTH_STATUS_PASS (authorization
succeeds), or 0x02 for TAC_PLUS_AUTH_STATUS_FAIL (authorization fails).
The server_msg_len , and data_len fields both contain a value of 0 , as required by the TACACS+ protocol.
Oracle® Communications Unified Session Manager
Getting Started with the Oracle USM
PAP Authentication
The Oracle USM initiates the authentication with an authentication START packet.
+-----------------------------------+
|
Common Header
|
|
minor_version contains 0x1
|
|
type contains 0x1
|
+--------+--------+--------+--------+
|action |priv_lvl|authen_ |service |
|
|
|type
|
|
| 0x01 | 0x01 | 0x02 | 0x01 |
|--------+--------+--------+--------+
|user_len|port_len|rem_addr|data_len|
|
|
|_len
|
|
|
N
|
N
|
N
|
N
|
+--------+--------+--------+--------+
|
user
|
+-----------------------------------+
|
port
|
|
tty10
|
+-----------------------------------+
|
rem_addr
|
|
localhost address
|
+-----------------------------------+
|
data ...
|
+-----------------------------------+
•
•
•
•
•
•
•
•
•
•
•
•
The action field specifies the requested authentication action — 0x01 for TAC_PLUSAUTHEN_LOGIN
(authentication of a user login).
The priv_lvl field specifies the privilege level requested by the user — 0x01 for TAC_PLUS_PRIV_LVL_USER.
The authen_type field specifies the authentication methodology — 0x02 for TAC_PLUS_AUTHEN_TYPE_PAP
(PAP login).
The service field specifies the requesting service — 0x01 for TAC_PLUS_AUTHEN_SVC_LOGIN (login
service).
The user_len field contains the length, in octets, of the user field.
The port_len field contains the length, in octets, of the port field.
The rem_addr_len field contains the length, in octets, of the rem_addr field.
The data_len field contains the length, in octets, of the date field.
The user field contains the username to be authenticated.
The port field contains the name of the Oracle USM port on which authentication is taking place. Following Cisco
Systems convention, this field contains the string tty10 .
The rem_addr field specifies the location of the user to be authenticated. This field contains the localhost address.
The data field contains the password to be authenticated.
The TCACS+ daemon returns an authentication REPLY reporting the authentication result.
+-----------------------------------+
|
Common Header
|
|
minor_version contains 0x1
|
|
type contains 0x1
|
+--------+--------+-----------------+
| status | flags | server_msg_len |
| 0x01 |
|
0
|
|--------+--------+-----------------+
|
data_len
|
|
0
|
+-----------------+
•
•
The status field specifies the authentication result — 0x01 for TAC_PLUS_AUTH_STATUS_PASS (authorization
succeeds), or 0x02 for TAC_PLUS_AUTH_STATUS_FAIL (authorization fails).
The server_msg_len and data_len fields both contain a value of 0 , as required by the TACACS+ protocol.
Oracle® Communications Unified Session Manager
77
Getting Started with the Oracle USM
•
Other, optional fields are not used.
CHAP Authentication
The Oracle USM initiates the authentication with an authentication START packet.
+-----------------------------------+
|
Common Header
|
|
minor_version contains 0x1
|
|
type contains 0x1
|
+--------+--------+--------+--------+
|action |priv_lvl|authen_ |service |
|
|
|type
|
|
| 0x01 | 0x01 | 0x03 | 0x01 |
|--------+--------+--------+--------+
|user_len|port_len|rem_addr|data_len|
|
|
|_len
|
|
|
N
|
N
|
N
|
N
|
+--------+--------+--------+--------+
|
user
|
+-----------------------------------+
|
port
|
|
tty10
|
+-----------------------------------+
|
rem_addr
|
|
localhost address
|
+-----------------------------------+
|
data ...
|
+-----------------------------------+
•
•
•
•
•
•
•
•
•
•
•
•
The action field specifies the requested authentication action — 0x01 for TAC_PLUSAUTHEN_LOGIN
(authentication of a user login).
The priv_lvl field specifies the privilege level requested by the user — 0x01 for TAC_PLUS_PRIV_LVL_USER.
The authen_type field specifies the authentication methodology — 0x03 for
TAC_PLUS_AUTHEN_TYPE_CHAP (CHAP login).
The service field specifies the requesting service — 0x01 for TAC_PLUS_AUTHEN_SVC_LOGIN (login
service).
The user_len field contains the length, in octets, of the user field.
The port_len field contains the length, in octets, of the port field.
The rem_addr_len field contains the length, in octets, of the rem_addr field.
The data_len field contains the length, in octets, of the date field.
The user field contains the username to be authenticated.
The port field contains the name of the Oracle USM port on which authentication is taking place. Following Cisco
Systems convention, this field contains the string tty10 .
The rem_addr field specifies the location of the user to be authenticated. This field contains the localhost address.
The data field contains the password to be authenticated.
The TCACS+ daemon returns an authentication REPLY reporting the authentication result.
+-----------------------------------+
|
Common Header
|
|
minor_version contains 0x1
|
|
type contains 0x1
|
+--------+--------+-----------------+
| status | flags | server_msg_len |
| 0x01 |
|
0
|
|--------+--------+-----------------+
|
data_len
|
|
0
|
+-----------------+
78
Oracle® Communications Unified Session Manager
Getting Started with the Oracle USM
•
•
•
The status field specifies the authentication result — 0x01 for TAC_PLUS_AUTH_STATUS_PASS (authorization
succeeds), or 0x02 for TAC_PLUS_AUTH_STATUS_FAIL (authorization fails).
The server_msg_len and data_len fields both contain a value of 0 , as required by the TACACS+ protocol.
Other, optional fields are not used.
TACACS+ Authorization
The Oracle USM uses TACACS+ services to provide administrative authorization. With TACACS+ authorization
enabled, each individual ACLI command issued by an admin user is authorized by the TACACS+ authorization
service. The Oracle USM replicates each ACLI command in its entirety, sends the command string to the
authorization service, and suspends command execution until it receives an authorization response. If TACACS+
grants authorization, the pending command is executed; if authorization is not granted, the Oracle USM does not
execute the ACLI command, and displays an appropriate error message.
The daemon’s authorization decisions are based on a database lookup. Data base records use regular expressions to
associate specific command string with specific users. The construction of such records is beyond the scope of this
document.
Authorization Message Exchange
All TACACS+ authorization packets consist of a common header and a message body. Authorization packets are of
two types: REQUEST and RESPONSE.
The REQUEST packet, which initiates an authorization session, is always sent by the Oracle USM. Upon receipt of
every REQUEST, the daemon must answer with a RESPONSE packet. In the current TACACS+ implementation, the
RESPONSE packet must contain an authorization decision (pass or fail). The exchange of a single REQUEST and the
corresponding RESPONSE completes the authorization session.
Authorization REQUEST Packet
The Oracle USM, acting as a TACACS+ client, sends an authorization REQUEST packet to the TACACS+ daemon
to initiate an authorization session.
The authorization REQUEST packet format is as follows.
+-----------------------------------+
|
Common Header
|
|
|
|
type contains 0x2
|
+--------+--------+--------+--------+
|authen_ |priv_lvl|authen_ |authen- |
|method |
|type
|service |
|--------+--------+--------+--------+
|user_len|port_len|rem_addr|arg_cnt |
|
|
|_len
|
|
+----+---+--------+--------+--------+
|arg1_len|arg2_len| ...
|argN_len|
|
|
|
|
|
+--------+--------+--------+--------+
|
user ...
|
+-----------------------------------+
|
port ...
|
+-----------------------------------+
|
rem-addr ...
|
+-----------------------------------+
|
arg1 ...
|
+-----------------------------------+
|
arg2 ...
|
+-----------------------------------+
|
argN ...
|
+-----------------------------------+
authen_method
Oracle® Communications Unified Session Manager
79
Getting Started with the Oracle USM
This 8-bit field contains an enumerated value that identifies the method used to authenticate the authorization subject
— that is, an admin user. Because the admin user was authenticated locally by the Oracle USM, this field always
contains a value of 0x05 , indicating authentication by the requesting client.
priv_lvl
This 8-bit field contains an enumerated value that identifies the privilege level associated with the authorization
subject. For the current TACACS+ authorization implementation, this field always contains a value of 0x00 .
authen-type
This 8-bit field contains an enumerated value that identifies the methodology. used to authenticate the authorization
subject. Because the admin user was authenticated with a simple username/password exchange, this field always
contains a value of 0x01 , indicating ascii login.
authen_service
This 8-bit field contains an enumerated value that identifies the service that requested authentication. Because an
admin user is authenticated with a simple username/password exchange, this field always contains a value of 0x01 ,
the login service.
user_len
This 8-bit field contains an integer that specifies the length, in octets, of the user field.
port_len
This 8-bit field contains an integer that specifies the length, in octets, of the port field.
rem_addr_len
This 8-bit field contains an integer that specifies the length, in octets, of the rem_addr field.
arg_cnt
This 8-bit field contains an integer that specifies the number or arguments contained with the REQUEST. Given the
design of the current TACACS+ implementation, this field always contains a value of 0x02 .
arg1_len
This 8-bit field contains an integer that specifies the length, in octets, of the first argument.
Subsequent fields contain the length of each sequential argument.
user
This variable length field contains the login name of the user to be authorized.
port
This variable length field contains the name of the Oracle USM port on which authorization is taking place.
Following Cisco Systems convention, this field contains the string tty10 .
rem_addr
This variable length contains the location of the user to be authorized. This field contains the localhost address.
arg...
This variable length field contains a TACACS+ attribute value pair (AVP); each arg field holds a single AVP.
A TACACS+ AVP is an ASCII string with a maximum length of 255 octets. The string consists of the attribute name
and its assigned value separated by either an equal sign (=) or by an asterisk (*). The equal sign (=) identifies a
mandatory argument, one that must be understood and processed by the TACACS+ daemon; the asterisk (*) identifies
an optional argument that may be disregarded by either the client or daemon.
Administrative authorization requires the use of only two TACACS+ AVPs: service and cmd .
The service AVP identifies the function to be authorized. In the case of the current implementation, the attribute value
is always shell . Consequently the attribute takes the follow format:
80
Oracle® Communications Unified Session Manager
Getting Started with the Oracle USM
service=shell
The cmd AVP identifies the specific ACLI command to be authorized. The command is passed in its entirety, from
the administrative configuration root, configure terminal, through the final command argument. For example,
cmd=configure terminal security authentication type tacacsplus
Note the equal sign (=) used in the attribute examples, indicating that both are mandatory arguments.
Authorization RESPONSE Packet
The TACACS+ daemon sends an authorization RESPONSE packet to the Oracle USM to report authorization results.
The authorization RESPONSE packet format is as follows.
+-----------------------------------+
|
Common Header
|
|
|
|
type contains 0x2
|
+--------+--------+-----------------+
|status |arg_cnt | server_msg len |
|
|
|
|
|--------+--------+--------+--------+
|
data_len
|arg1_len|arg2_len|
|
|
|
|
+--------+--------+--------+--------+
|
... |argN_len|
server_msg
|
|
|
|
|
+--------+--------+-----------------+
|
data ...
|
+-----------------------------------+
|
arg1 ...
|
+-----------------------------------+
|
arg2 ...
|
+-----------------------------------+
|
argN ...
|
+-----------------------------------+
status
This 8-bit field contains an enumerated value that specifies the results of the authorization process. Supported values
are 0x01 (Pass), 0x10 (Fail), and 0x11 (Error). Fail indicates that the authorization service rejected the proposed
operation, while Error indicates the authorization service failed
If authorization succeeds (status=0x01), the ACLI command is executed; if authorization fails, for whatever the
reason (status=0x10 or 0x11), the ACLI command is not executed, and an appropriate error message is generated.
arg_cnt
This 8-bit field contains an integer that specifies the number or arguments contained with the RESPONSE. Given the
design of the current TACACS+ implementation, this field always contains a value of 0x02 .
server_msg_len
This 16-bit field contains an integer that specifies the length, in octets, of the server_msg field.
data_len
This 16-bit field contains an integer that specifies the length, in octets, of the data field.
arg1_len
This 8-bit field contains an integer that specifies the length, in octets, of the first argument.
Subsequent fields contain the length of each sequential argument.
server-msg
This optional variable length field contains a string that can be presented to the user.
Oracle® Communications Unified Session Manager
81
Getting Started with the Oracle USM
data
This optional variable length field contains a string that can be presented to an administrative display, console, or log.
arg...
This optional variable length field contains a TACACS+ attribute value pair (AVP); each arg field holds a single AVP.
No arguments are generated in RESPONSE packets within the current TACACS+ implementation.
Authorization Scenarios
Successful and failed administrative authorization is described in terms of packet flow in the following sections.
Authorization Pass
The Oracle USM initiates the authorization with an authorization REQUEST packet.
+-----------------------------------+
|
Common Header
|
|
|
|
type contains 0x2
|
+--------+--------+--------+--------+
|authen_ |priv_lvl|authen_ |authen_ |
|method |
|type
|service |
| 0x05 | 0x00 | 0x01 | 0x01 |
|--------+--------+--------+--------+
|user_len|port_len|rem_addr|arg_cnt |
|
|
|_len
|
|
|
N
|
N
|
N
|
2
|
+--------+--------+--------+--------+
|arg1_len|arg2_len|
user ...
|
|
|
|
|
|
N
|
N
|
login name
|
+--------+--------+-----------------+
|
port
|
|
tty10
|
+-----------------------------------+
|
rem_addr
|
|
localhost address
|
+-----------------------------------+
|
arg1
|
|
AVP
|
|
service=shell
|
+-----------------------------------+
|
arg2
|
|
AVP
|
| cmd=configure terminal security |
+-----------------------------------+
•
•
•
•
•
•
•
•
•
•
82
The authen_method field specifies the method used to authenticate the subject — 0x05 for
TAC_PLUS_AUTHEN_METHOD_LOCAL (authentication by the client).
The priv_lvl field specifies the privilege level requested by the user — 0x00 for TAC_PLUS_PRIV_LVL_MIN.
The authen_type field specifies the authentication methodology — 0x01 for
TAC_PLUS_AUTHEN_TYPE_ASCII (simple login).
The authen_ service field specifies the requesting service — 0x01 for TAC_PLUS_AUTHEN_SVC_LOGIN
(login service).
The user_len field contains the length, in octets, of the user field.
The port_len field contains the length, in octets, of the port field.
The rem_addr_len field contains the length, in octets, of the rem_addr field.
The arg_cnt field contains the number of arguments in the message body.
The arg1_len field contains the length, in octets, of the service AVP.
The arg2_len field contains the length, in octets, of the service AVP.
Oracle® Communications Unified Session Manager
Getting Started with the Oracle USM
•
•
•
•
•
The user field contains the login name of an admin user.
The port field contains the name of the Oracle USM port on which authentication is taking place. Following Cisco
Systems convention, this field contains the string tty10 .
The rem_addr field specifies the location of the user to be authenticated. This field contains the localhost address.
The arg1 field contains the mandatory service AVP.
The arg2 field contains the mandatory cmd AVP.
The TCACS+ daemon returns a authorization RESPONSE reporting the status, and terminating the authorization
session.
+-----------------------------------+
|
Common Header
|
|
|
|
type contains 0x2
|
+--------+--------+-----------------+
| status |arg_cnt | server_msg_len |
| 0x01 |
0
|
0
|
|--------+--------+-----------------+
|
data_len
|
|
0
|
+-----------------+
•
•
•
The status field specifies the authorization status — 0x01 for TAC_PLUS_AUTHOR_STATUS_PASS_ADD
(authorization approved).
The arg_cnt field contains a value of 0 — the authorization RESPONSE returns no arguments.
The server_msg_len and data_len fields both contain a value of 0, as required by the TACACS+ protocol.
Authorization Fail
The Oracle USM initiates the authorization with an authorization REQUEST packet.
+-----------------------------------+
|
Common Header
|
|
|
|
type contains 0x2
|
+--------+--------+--------+--------+
|authen_ |priv_lvl|authen_ |authen_ |
|method |
|type
|service |
| 0x05 | 0x00 | 0x01 | 0x01 |
|--------+--------+--------+--------+
|user_len|port_len|rem_addr|arg_cnt |
|
|
|_len
|
|
|
N
|
N
|
N
|
2
|
+--------+--------+--------+--------+
|arg1_len|arg2_len|
user ...
|
|
|
|
|
|
N
|
N
|
login name
|
+--------+--------+-----------------+
|
port
|
|
tty10
|
+-----------------------------------+
|
rem_addr
|
|
localhost address
|
+-----------------------------------+
|
arg1
|
|
AVP
|
|
service=shell
|
+-----------------------------------+
|
arg2
|
|
AVP
|
|
cmd=configure terminal scurity |
+-----------------------------------+
Oracle® Communications Unified Session Manager
83
Getting Started with the Oracle USM
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
The authen_method field specifies the method used to authenticate the administrative subject — 0x05 for
TAC_PLUS_AUTHEN_METHOD_LOCAL (authentication by the client).
The priv_lvl field specifies the privilege level requested by the user — 0x00 for TAC_PLUS_PRIV_LVL_MIN.
The authen_type field specifies the authentication methodology — 0x01 for
TAC_PLUS_AUTHEN_TYPE_ASCII (simple login).
The authen_ service field specifies the requesting service — 0x01 for TAC_PLUS_AUTHEN_SVC_LOGIN
(login service).
The user_len field contains the length, in octets, of the user field.
The port_len field contains the length, in octets, of the port field.
The rem_addr_len field contains the length, in octets, of the rem-addr field.
The arg_cnt field contains the number of arguments in the message body.
The arg1_len field contains the length, in octets, of the service AVP.
The arg2_len field contains the length, in octets, of the service AVP.
The user field contains the login name of an admin user.
The port field contains the name of the Oracle USM port on which authentication is taking place. Following Cisco
Systems convention, this field contains the string tty10 .
The rem_addr field specifies the location of the user to be authenticated. This field contains the localhost address.
The arg1 field contains the mandatory service AVP.
The arg2 field contains the mandatory cmd AVP.
The TCACS+ daemon returns an authorization RESPONSE reporting the status, and terminating the authorization
session.
+-----------------------------------+
|
Common Header
|
|
|
|
type contains 0x2
|
+--------+--------+--------+--------+
| status |arg_cnt | server_msg_len |
| 0x10 |
0
|
0
|
|--------+--------+--------+--------+
|
data_len
|
|
0
|
+-----------------+
•
•
•
The status field specifies the authorization status — 0x10 for TAC_PLUS_AUTHOR_STATUS_FAIL
(authorization rejected).
The arg_cnt field contains a value of 0 — the authorization RESPONSE returns no arguments.
The server_msg_len and data_len fields both contain a value of 0 , as required by the TACACS+ protocol.
TACACS+ Accounting
The Oracle USM uses TACACS+ accounting to log administrative actions. With accounting enabled, each individual
ACLI command executed by an admin user is logged by the accounting service.
Accounting Message Exchange
All TACACS+ accounting packets consist of a common header and a message body. Accounting packets are of two
types: REQUEST and REPLY.
The REQUEST packet has three variant forms. The START variant initiates an accounting session; the STOP variant
terminates an accounting session; the WATCHDOG variant updates the current accounting session. REQUEST
packets are always sent by the Oracle USM. Upon receipt of every REQUEST, the daemon must answer with a
REPLY packet.
A TACACS+ accounting session proceeds as follows.
1. Immediately following successful authorization of an admin user, the Oracle USM sends an accounting
REQUEST START packet.
84
Oracle® Communications Unified Session Manager
Getting Started with the Oracle USM
2. The daemon responds with an accounting REPLY packet, indicating that accounting has started.
3. For each ACLI command executed by an admin user, the Oracle USM sends an accounting REQUEST
WATCHDOG packet requesting accounting of the ACLI command. As the Oracle USM sends the WATCHDOG
only after an admin user’s access to the ACLI command is authorized, the accounting function records only those
commands executed by the user, not those commands for which authorization was not granted.
4. The daemon responds with an accounting REPLY packet, indicating that the ACLI operation has been recorded by
the accounting function.
5. Steps 3 and 4 are repeated for each authorized ACLI operation.
6. Immediately following logout (or timeout) of an admin user, the Oracle USM sends an accounting REQUEST
STOP packet.
7. The daemon responds with an accounting REPLY packet, indicating that accounting has stopped.
Accounting REQUEST Packet
The Oracle USM, acting as a TACACS+ client, sends an accounting REQUEST START variant to the TACACS+
daemon following the successful authorization of an admin user. It sends an accounting REQUEST WATCHDOG
variant to the daemon following the authorization of an admin user’s access to an ACLI command. It sends an
accounting REQUEST STOP variant to the daemon at the conclusion of the ACLI session.
The accounting REQUEST packet format is as follows.
+-----------------------------------+
|
Common Header
|
|
|
|
type contains 0x3
|
+--------+--------+--------+--------+
| flags |authen_ |priv_lvl|authen- |
|
|method |
|type
|
|--------+--------+--------+--------+
|authen_ |user_len|port_len|rem_addr|
|service |
|
|_len
|
+----+---+--------+--------+--------+
|arg_cnt |arg1_len|arg2_len|argN_len|
|
|
|
|
|
+--------+--------+--------+--------+
|argN_len|
user ...
|
+--------+--------------------------+
|
port ...
|
+-----------------------------------+
|
rem-addr ...
|
+-----------------------------------+
|
arg1 ...
|
+-----------------------------------+
|
arg2 ...
|
+-----------------------------------+
|
argN ...
|
+-----------------------------------+
flags
This 8-bit field contains an enumerated value that identifies the accounting REQUEST variant.
0x2 — START
0x4 — STOP
0x8 — WATCHDOG
authen_method
This 8-bit field contains an enumerated value that identifies the method used to authenticate the accounting subject —
that is, an admin user. Because an admin user is authenticated locally by the Oracle USM, this field always contains a
value of 0x05 , indicating authentication by the requesting client.
Oracle® Communications Unified Session Manager
85
Getting Started with the Oracle USM
priv_lvl
This 8-bit field contains an enumerated value that identifies the privilege level associated with the accounting subject.
For the current TACACS+ accounting implementation, this field always contains a value of 0x00 .
authen-type
This 8-bit field contains an enumerated value that identifies the methodology. used to authenticate the accounting
subject. Because an admin user is authenticated with a simple username/password exchange, this field always
contains a value of 0x01 , indicating ascii login.
authen_service
This 8-bit field contains an enumerated value that identifies the service that requested authentication. Because an
admin user is authenticated with a simple username/password exchange, this field always contains a value of 0x01 ,
the login service.
user_len
This 8-bit field contains an integer that specifies the length, in octets, of the user field.
port_len
This 8-bit field contains an integer that specifies the length, in octets, of the port field.
rem_addr_len
This 8-bit field contains an integer that specifies the length, in octets, of the rem_addr field.
arg_cnt
This 8-bit field contains an integer that specifies the number or arguments contained with the accounting REQUEST.
arg1_len
This 8-bit field contains an integer that specifies the length, in octets, of the first argument.
Subsequent fields contain the length of each sequential argument.
user
This variable length field contains the login name of the accounting subject.
port
This variable length field contains the name of the Oracle USM port on accounting is taking place. Following Cisco
System convention, this field always contains the string tty10 .
rem_addr
This variable length contains the location of the authorization subject. This field always contains the localhost
address.
arg...
This variable length field contains a TACACS+ attribute value pair (AVP); each arg field holds a single AVP.
A TACACS+ AVP is an ASCII string with a maximum length of 255 octets. The string consists of the attribute name
and its assigned value separated by either an equal sign (=) or by an asterisk (*). The equal sign (=) identifies a
mandatory argument, one that must be understood and processed by the TACACS+ daemon; the asterisk (*) identifies
an optional argument that may be disregarded by either the client or daemon.
Administrative accounting requires the use of five TACACS+ AVPs: service, task-id, start_time, and stop_time.
The task_id AVP, included in accounting REQUEST START, STOP, and WATCHDOG variants, correlates session
initiation, watchdog updates, and termination packets; each associated START, STOP, and WATCHDOG packet must
contain matching task-id AVPs.
task_id=13578642
86
Oracle® Communications Unified Session Manager
Getting Started with the Oracle USM
The start_time AVP, included in accounting REQUEST START and WATCHDOG variants, specifies the time at
which a specific accounting request was initiated. The start time is expressed as the number of seconds elapsed since
January 1, 1970 00:00:00 UTC.
start_time=1286790650
The stop_time AVP, included in accounting REQUEST STOP variants, specifies the time at which a specific
accounting session was terminated. The stop time is expressed as the number of seconds elapsed since January 1,
1970 00:00:00 UTC.
stop_time=1286794250
The service AVP, included in accounting REQUEST START, STOP, and WATCHDOG variants, identifies the
function subject to accounting. In the case of the current implementation, the attribute value is always shell .
Consequently the attribute takes the follow format:
service=shell
The cmd AVP, included in accounting REQUEST WATCHDOG variants, identifies the specific ACLI command to be
processed by the accounting service. The command is passed in its entirety, from the administrative configuration
root, configure terminal, through the final command argument. For example,
cmd=configure terminal security authentication type tacacsplus
Note the equal sign (=) used in the attribute examples, indicating that all are mandatory arguments.
Accounting REPLY Packet
The TACACS+ daemon sends an accounting REPLY packet to the Oracle USM to report accounting results.
The accounting REPLY packet format is as follows.
+-----------------------------------+
|
Common Header
|
|
|
|
type contains 0x3
|
+-----------------+--------+--------+
| server_msg_len |
data_len
|
|--------+--------+-----------------+
| status |
server_msg ...
|
+--------+--------------------------+
|
data ...
|
+-----------------------------------+
server_msg_len
This 16-bit field contains the length, in octets, of the server_msg field.
data_len
This 16-bit field contains the length, in octets, of the data field.
status
This 8-bit field contains the status of the previous accounting request. Supported values are:
0x1 — Success
0x2 — Error/Failure
server_msg
This optional variable length field can contain a message intended for display to the user. This field is unused in the
current TACACS+ implementation.
data
This optional variable length field can contain miscellaneous data. This field is unused in the current TACACS+
implementation.
Oracle® Communications Unified Session Manager
87
Getting Started with the Oracle USM
Accounting Scenario
The Oracle USM initiates the accounting session with an accounting REQUEST START.
+-----------------------------------+
|
Common Header
|
|
|
|
type contains 0x3
|
+--------+--------+--------+--------+
| flags |authen_ |priv_lvl|authen- |
|
|method |
|type
|
| 0x02 | 0x05 | 0x00 | 0x01 |
|--------+--------+--------+--------+
|authen_ |user_len|port_len|rem_addr|
|service |
|
|_len
|
| 0X01 |
N
|
N
|
N
|
+----+---+--------+--------+--------+
|arg_cnt |arg1_len|arg2_len|arg3_len|
|
3
|
N
|
N
|
N
|
+--------+--------+--------+--------+
|
user
|
|
login name of an admin user
|
+-----------------------------------+
|
port
|
|
tty10
|
+-----------------------------------+
|
rem_addr
|
|
localhost address
|
+-----------------------------------+
|
AVP
|
|
task-id=13578642
|
+-----------------------------------+
|
AVP
|
|
start_time=1286790650
|
+-----------------------------------+
|
AVP
|
|
service=shell
|
+-----------------------------------+
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
88
The flags field contains an enumerated value ( 0x02 ) that identifies an accounting REQUEST START.
The authen_method field specifies the method used to authenticate the ACCOUNTING subject — 0x05 for
TAC_PLUS_AUTHEN_METHOD_LOCAL (authentication by the client).
The priv_lvl field specifies the privilege level requested by the user — 0x00 for TAC_PLUS_PRIV_LVL_MIN.
The authen_type field specifies the authentication methodology — 0x01 for
TAC_PLUS_AUTHEN_TYPE_ASCII (simple login).
The authen_ service field specifies the requesting service — 0x01 for TAC_PLUS_AUTHEN_SVC_LOGIN
(login service).
The user_len field contains the length, in octets, of the user field.
The port_len field contains the length, in octets, of the port field.
The rem_addr_len field contains the length, in octets, of the rem_addr field.
The arg_cnt field contains the number of arguments in the message body.
The arg1_len field contains the length, in octets, of the task_id AVP.
The arg2_len field contains the length, in octets, of the start_time AVP.
The arg3_len field contains the length, in octets, of the service AVP.
The user field contains the login name of an admin user.
The port field contains the name of the Oracle USM port on which authentication is taking place. Following Cisco
Systems convention, this field contains the string tty10 .
The rem_addr field specifies the location of the user to be authenticated. This field contains the localhost address.
The arg1 field contains the mandatory task_id AVP.
The arg2 field contains the mandatory start_time AVP.
Oracle® Communications Unified Session Manager
Getting Started with the Oracle USM
•
The arg3 field contains the mandatory service AVP.
The TCACS+ daemon returns an accounting REPLY reporting the status, indicating that accounting has started.
+-----------------------------------+
|
Common Header
|
|
|
|
type contains 0x3
|
+-----------------+-----------------+
| server_msg_len |
data_len
|
|
0
|
0
|
|--------+--------+-----------------+
| status |
| 0x01 |
+--------+
•
•
The server_msg_len and data_len fields both contain a value of 0 , as required by the TACACS+ protocol.
The status field specifies the authorization status — 0x01 for TAC_PLUS_ACCT_STATUS_SUCCESS
(accounting processed).
The Oracle USM reports ACLI command execution with an accounting REQUEST WATCHDOG.
+-----------------------------------+
|
Common Header
|
|
|
|
type contains 0x3
|
+--------+--------+--------+--------+
| flags |authen_ |priv_lvl|authen- |
|
|method |
|type
|
| 0x08 | 0x05 | 0x00 | 0x01 |
|--------+--------+--------+--------+
|authen_ |user_len|port_len|rem_addr|
|service |
|
|_len
|
| 0X01 |
N
|
N
|
N
|
+----+---+--------+--------+--------+
|arg_cnt |arg1_len|arg2_len|arg3_len|
|
4
|
N
|
N
|
N
|
+--------+--------+--------+--------+
|arg4_len|
user
|
|
| login name of admin user |
+--------+--------------------------+
|
port
|
|
tty10
|
+-----------------------------------+
|
rem_addr
|
|
localhost address
|
+-----------------------------------+
|
AVP
|
|
task-id=13578642
|
+-----------------------------------+
|
AVP
|
|
start_time=1286790650
|
+-----------------------------------+
|
AVP
|
|
service=shell
|
+-----------------------------------+
|
AVP
|
| cmd=configure terminal security |
+-----------------------------------+
•
•
•
The flags field contains an enumerated value ( 0x08 ) that identifies an accounting REQUEST WATCHDOG.
The authen_method field specifies the method used to authenticate the ACCOUNTING subject — 0x05 for
TAC_PLUS_AUTHEN_METHOD_LOCAL (authentication by the client).
The priv_lvl field specifies the privilege level requested by the user — 0x00 for TAC_PLUS_PRIV_LVL_MIN.
Oracle® Communications Unified Session Manager
89
Getting Started with the Oracle USM
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
The authen_type field specifies the authentication methodology — 0x01 for
TAC_PLUS_AUTHEN_TYPE_ASCII (simple login).
The authen_ service field specifies the requesting service — 0x01 for TAC_PLUS_AUTHEN_SVC_LOGIN
(login service).
The user_len field contains the length, in octets, of the user field.
The port_len field contains the length, in octets, of the port field.
The rem_addr_len field contains the length, in octets, of the rem_addr field.
The arg_cnt field contains the number of arguments in the message body.
The arg1_len field contains the length, in octets, of the task_id AVP.
The arg2_len field contains the length, in octets, of the start_time AVP.
The arg3_len field contains the length, in octets, of the service AVP.
The arg4_len field contains the length, in octets, of the cmd AVP.
The user field contains the login name of an admin user.
The port field contains the name of the Oracle USM port on which authentication is taking place. Following Cisco
Systems convention, this field contains the string tty10 .
The rem_addr field specifies the location of the user to be authenticated. This field contains the localhost address.
The arg1 field contains the mandatory task_id AVP.
The arg2 field contains the mandatory start_time AVP.
The arg3 field contains the mandatory service AVP.
The arg4 field contains the mandatory cmd AVP.
The TCACS+ daemon returns an accounting REPLY reporting the status, indicating that the ACLI operation has been
processed.
+-----------------------------------+
|
Common Header
|
|
|
|
type contains 0x3
|
+-----------------+-----------------+
| server_msg_len |
data_len
|
|
0
|
0
|
|--------+--------+-----------------+
| status |
| 0x01 |
+--------+
•
•
The server_msg_len and data_len fields both contain a value of 0 , as required by the TACACS+ protocol.
The status field specifies the authorization status — 0x01 for TAC_PLUS_ACCT_STATUS_SUCCESS
(accounting processed).
The Oracle USM reports an admin user logout or timeout with an accounting REQUEST STOP.
+-----------------------------------+
|
Common Header
|
|
|
|
type contains 0x3
|
+--------+--------+--------+--------+
| flags |authen_ |priv_lvl|authen- |
|
|method |
|type
|
| 0x04 | 0x05 | 0x00 | 0x01 |
|--------+--------+--------+--------+
|authen_ |user_len|port_len|rem_addr|
|service |
|
|_len
|
| 0X01 |
N
|
N
|
N
|
+----+---+--------+--------+--------+
|arg_cnt |arg1_len|arg2_len|arg3_len|
|
3
|
N
|
N
|
N
|
+--------+--------+--------+--------+
|
user
|
|
login name of an admin user
|
90
Oracle® Communications Unified Session Manager
Getting Started with the Oracle USM
+-----------------------------------+
|
port
|
|
tty10
|
+-----------------------------------+
|
rem_addr
|
|
localhost address
|
+-----------------------------------+
|
AVP
|
|
task-id=13578642
|
+-----------------------------------+
|
AVP
|
|
stop_time=1286790650
|
+-----------------------------------+
|
AVP
|
|
service=shell
|
+-----------------------------------+
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
The flags field contains an enumerated value ( 0x04 ) that identifies an accounting REQUEST STOP.
The authen_method field specifies the method used to authenticate the ACCOUNTING subject — 0x05 for
TAC_PLUS_AUTHEN_METHOD_LOCAL (authentication by the client).
The priv_lvl field specifies the privilege level requested by the user — 0x00 for TAC_PLUS_PRIV_LVL_MIN.
The authen_type field specifies the authentication methodology — 0x01 for
TAC_PLUS_AUTHEN_TYPE_ASCII (simple login).
The authen_ service field specifies the requesting service — 0x01 for TAC_PLUS_AUTHEN_SVC_LOGIN
(login service).
The user_len field contains the length, in octets, of the user field.
The port_len field contains the length, in octets, of the port field.
The rem_addr_len field contains the length, in octets, of the rem_addr field.
The arg_cnt field contains the number of arguments in the message body.
The arg1_len field contains the length, in octets, of the task_id AVP.
The arg2_len field contains the length, in octets, of the start_time AVP.
The arg3_len field contains the length, in octets, of the service AVP.
The user field contains the login name of an admin user.
The port field contains the name of the Oracle USM port on which authentication is taking place. Following Cisco
Systems convention, this field contains the string tty10 .
The rem_addr field specifies the location of the user to be authenticated. This field contains the localhost address.
The arg1 field contains the mandatory task_id AVP.
The arg2 field contains the mandatory start_time AVP.
The arg3 field contains the mandatory service AVP.
The TCACS+ daemon returns an accounting REPLY reporting the status, indicating that accounting has terminated.
+-----------------------------------+
|
Common Header
|
|
|
|
type contains 0x3
|
+-----------------+-----------------+
| server_msg_len |
data_len
|
|
0
|
0
|
|--------+--------+-----------------+
| status |
| 0x01 |
+--------+
•
•
The server_msg_len and data_len fields both contain a value of 0 , as required by the TACACS+ protocol.
The status field specifies the authorization status — 0x01 for TAC_PLUS_ACCT_STATUS_SUCCESS
(accounting processed).
Oracle® Communications Unified Session Manager
91
Getting Started with the Oracle USM
TACACS+ Configuration
Configuration of TACACS+ consists of the following steps.
1. Enable TACACS+ client services
2. Specify one or more TACACS+ servers (daemons)
Note: TACACS servers must be reachable from the Oracle USM's media interfaces. Communications to
and from TACACS servers can not be from the management interfaces.
Enable TACACS+ Client Services
Use the following procedure to enable specific TACACS+ client AAA services.
1. Access the authentication configuration element.
ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# authentication
ORACLE(authentication)#
2. Use the required type attribute to specify the authentication protocol.
Supported values are diameter, local (the default, indicating that authentication determinations are referred to a
local database), radius, and tacacs.
Specify tacacs to enable the TACACS+ AAA protocol.
ORACLE(authentication)# type tacacs
ORACLE(authentication)#
3. Use tacacs-authorization to enable or disable command-based authorization of admin users. Assuming type is set
to tacacs , by default, authorization is enabled.
ORACLE(authentication)# tacacs-authorization enabled
ORACLE(authentication)#
4. Use tacacs-accounting to enable or disable accounting of admin ACLI operations. Assuming type is set to tacacs ,
by default, accounting is enabled.
ORACLE(authentication)# tacacs-accounting enabled
ORACLE(authentication)#
5. Use the server-assigned-privilege attribute to enable a proprietary TACACS+ variant that, after successful user
authentication, adds an additional TACACS+ request/reply exchange. During the exchange, the Security Gateway
requests the privilege level of the newly authenticated user. In response, the TACACS+ daemon returns the
assigned privilege level, either user or admin . user accounts are denied access to the enable command, thus
barring them from configuration level commands.
By default, this attribute is disabled — meaning that no privilege level information is exchanged.
Set this attribute to enabled to initiate the proprietary variant behavior.
ORACLE(authentication)# server-assigned-privilege enabled
ORACLE(authentication)#
6. Use the management-strategy attribute to identify the selection algorithm used to choose among multiple available
TACACS+ daemons.
Retain the default value (hunt) if only a single daemon is available.
Available algorithms are hunt and roundrobin .
•
92
hunt — for the first transaction the Security Gateway selects the initially configured TACACS+ daemon. As
long as that daemon is online and operational, the Security Gateway directs all AAA transactions to it.
Otherwise, the Security Gateway selects the second-configured daemon. If the first and second daemons are
offline or non-operational, the next-configured daemon is selected, and so on through the group of available
daemons.
Oracle® Communications Unified Session Manager
Getting Started with the Oracle USM
•
roundrobin — for the first transaction the Security Gateway selects the initially configured TACACS+
daemon. After completing the first transaction, selects each daemon in order of configuration — in theory,
evenly distributing AAA transactions to each daemon over time.
ORACLE(authentication)# management-strategy roundrobin
ORACLE(authentication)#
7. Type done to save your configuration.
Specify TACACS+ Servers
Use the following procedure to specify one or more TACACS+ servers (daemons).
1. Access the tacacs-serversconfiguration element.
ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# authentication
ORACLE(authentication)# tacacs-servers
ORACLE(tacacs-servers)#
2. Use the address attribute to specify the IP address of this TACACS+ daemon.
ORACLE(tacacs-servers)# address 172.30.0.6
ORACLE(tacacs-servers)#
Note: This address must be reachable from a media interface. The TACACs server should not be on the
management interface's network.
3. Use the port attribute to identify the daemon port that receives TACACS+ client requests.
Provide a port number within the range 1025 through 65535, or retain the default value, 49, the well-known
TACACS+ port.
ORACLE(tacacs-servers)# port 49
ORACLE(tacacs-servers)#
4. Use the state attribute to specify the availability of this TACACS+ daemon.
Select enabled (the default) or disabled.
Only TACACS+ daemons that are in the enabled state are considered when running the server-selection algorithm.
ORACLE(tacacs-servers)# state enabled
ORACLE(tacacs-servers)#
5. Use the realm-id attribute to identify the realm that provides access to this TACACS+ deamon.
ORACLE(tacacs-servers)# realm-id accounting
ORACLE(tacacs-servers)#
Note: This realm must be reachable from a media interface.
6. Retain the default value for the authentication-methods attribute to specify support for all TACACS+
authentication methods (pap, chap, and ascii).
•
•
•
ascii — simple login, the Session Director prompts user for username and password
pap — similar to ascii method, but username and password are encapsulated in a PAP header
chap — authentication based on a shared-secret, which is not passed during the authentication process
ORACLE(tacacs-servers)# authentication-methods all
ORACLE(tacacs-servers)#
7. Use the secret attribute to provide the shared-secret used by the TACACS+ client and the daemon to encrypt and
decrypt TACACS+ messages. The identical shared-secret must be configured on associated TACACS+ clients and
daemons.
Enter a 16-digit string, and ensure that the identical value is configured on the TACACS+ daemon.
ORACLE(tacacs-servers)# secret 1982100754609236
ORACLE(tacacs-servers)#
Oracle® Communications Unified Session Manager
93
Getting Started with the Oracle USM
8. Use the dead-time attribute to specify, in seconds, the quarantine period imposed upon TACACS+ daemons that
become unreachable. Quarrantined servers are not eligible to participate in the server-selection algorithm.
Supported values are integers within the range 10 through 10000 seconds, with a default value of 10 .
ORACLE(tacacs-servers)# dead-interval 120
ORACLE(tacacs-servers)#
9. Type done to save your configuration.
10. Repeat Steps 1 through 10 to configure additional TACACS+ daemons.
Note: After configuring TACACS+ daemons, complete TACACS+ configuration by compiling a list of
available deamons.
11. From superuser mode, use the following command sequence to access authentication configuration mode.
ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# authentication
ORACLE(authentication)#
12. Use the management-servers attribute to identify one or more TACACS+ daemons available to provide AAA
services.
Daemons are identified by IP address and must have been previously configured as described above.
The following example identifies three available TACACS+ daemons. Note that the list is delimited by left and
right parentheses, and list items are separated by space characters.
ORACLE(tacacs-servers)# management-servers (172.30.0.6 172.30.1.8
172.30.2.10)
ORACLE(tacacs-servers)#
The following example deletes the current list.
ORACLE(tacacs-servers)# management-servers ()
ORACLE(tacacs-servers)#
Managing TACACS+ Operations
TACACS+ management is supported by the following utilities.
TACACS+ MIB
An Oracle proprietary MIB provides external access to TACACS+ statistics.
MIB counters are contained in the apSecurityTacacsPlusStatsTable that is defined as follows.
SEQUENCE {
apSecurityTacacsPlusCliCommands
apSecurityTacacsPlusSuccess Authentications
apSecurityTacacsPlusFailureAuthentications
apSecurityTacacsPlusSuccess Authorizations
apSecurityTacacsPlusFailureAuthorizations
}
Counter32
Counter32
Counter32
Counter32
Counter32
apSecuritysTacacsPlusStats Table (1.3.6.1.4.1.9148.3.9.9.4)
94
Object Name
Object OID
Description
apSecurityTacacsCliCommands
1.3.6.1.4.1.9148.3.9.1.4.3
Global counter for ACLI
commands sent to TACACS+
Accounting
apSecurityTacacsSuccess
Authentications
1.3.6.1.4.1.9148.3.9.1.4.4
Global counter for the number of
successful TACACS+
authentications
Oracle® Communications Unified Session Manager
Getting Started with the Oracle USM
apSecuritysTacacsPlusStats Table (1.3.6.1.4.1.9148.3.9.9.4)
Object Name
Object OID
Description
apSecurityTacacsFailureAuthentication 1.3.6.1.4.1.9148.3.9.1.4.5
s
Global counter for the number of
unsuccessful TACACS+
authentications
apSecurityTacacsSuccess
Authorizations
1.3.6.1.4.1.9148.3.9.1.4.6
Global counter for the number of
successful TACACS+
authorizations
apSecurityTacacsFailure
Authorizations
1.3.6.1.4.1.9148.3.9.1.4.7
Global counter for the number of
unsuccessful TACACS+
authorizations
SNMP Trap
SNMP traps are issued when
•
•
•
•
a TACACS+ daemon becomes unreachable
an unreachable TACACS+ daemon becomes reachable
an authentication error occurs
an authorization error occurs
ACLI show Command
The show tacacs stats command displays the following statistics.
•
•
•
•
•
•
number of ACLI commands sent for TAGACS+ accounting
number of successful TACACS+ authentications
number of failed TACACS+ authentications
number of successful TACACS+ authorizations
number of failed TACACS+ authentications
the IP address of the TACACS+ daemon used for the last transaction
TACACS+ Logging
All messages between the Oracle USM and the TACACS+ daemon are logged in a cleartext format, allowing an
admin user to view all data exchange, except for password information.
Customizing Your ACLI Settings
This section describes several ways you can customize the way you log into the ACLI and the way the ACLI displays
information. Where applicable, these descriptions also contain instructions for configuration.
Disabling the Second Login Prompt
With this feature enabled, the Oracle logs you in as a Superuser (i.e., in administrative mode) regardless of your
configured privilege level for either a Telnet or an SSH session. However, if you log via SSH, you still need to enter
the password for local or RADIUS authentication.
Disabling the Second Login Prompt Configuration
You disable the second login prompt in the authentication configuration.
To disable the second login prompt:
1. In Superuser mode, type configure terminal and press Enter.
Oracle® Communications Unified Session Manager
95
Getting Started with the Oracle USM
ORACLE# configure terminal
ORACLE(configure)#
2. Type security and press Enter.
ORACLE(configure)# security
ORACLE(security)#
3. Type authentication and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(security)# authentication
ORACLE(authentication)#
4. login-as-admin—Set this parameter to enabled if you want users to be logged automatically in Superuser
(administrative) mode. The default for this parameter is disabled.
5. Save and activate your configuration.
Persistent ACLI more Parameter
To make using the ACLI easier, the Oracle USM provides a paging feature controlled through the ACLI cli more
command (which you can set to enabled or disabled). Disabled by default, this feature allows you to control how the
Oracle USM displays information on your screen during a console, Telnet, or SSH session. This command sets the
paging feature on a per session basis.
Customers who want to set the paging feature so that settings persist across sessions with the Oracle USM can set a
configuration parameter that controls the paging feature. Enabling this parameter lets you set your preferences once
rather than having to reset them each time you initiate a new session with the Oracle USM.
Persistent ACLI more Parameter Configuration
To set the persistent behavior of the ACLI more feature across sessions:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
2. Type system and press Enter.
ORACLE(configure)# system
ORACLE(system)#
3. Type system-config and press Enter.
ORACLE(system)# system-config
ORACLE(system-config)#
If you are adding this feature to an existing configuration, you need to select the configuration (using the ACLI
select command) before making your changes.
4. cli-more—Set this parameter to enabled if you want the ACLI more paging feature to work persistently across
console, Telnet, or SSH sessions with the Oracle USM. If you want to continue to set this feature on a per session
basis, leave this parameter set to disabled (default).
5. Save and activate your configuration.
Customized Login Banner
A text file can be put on the Oracle USM to be used as a banner to be printed before each login. The file must be
called /code/banners/banner.txt. The contents of this file will be printed before each User Access Verification login
sequence. The limits are that no more than 79 characters per line and no more than 20 lines from the banner.txt file
will be printed.
The banner.txt file used for the ACLI customized login banner has to be saved in the /code/banners directory. If that
directory does not already exist on your system, you do not have to create the directory prior to placing the banner file
because the Oracle USM will create it upon boot if it does not exist.
96
Oracle® Communications Unified Session Manager
3
System Configuration
This chapter explains how to configure system-level functionality for the Oracle USM. Both physical and network
interfaces as well as general system parameters are required to configure your Oracle USM for service. Accounting
functionality, SNMP configurations, trap configurations, and host routes are optional.
The following configurations are explained in this chapter:
•
•
•
•
•
•
General system parameters—used for operating and identification purposes. In general, the informational fields
have no specific effect on services, but are important to keep populated. The default gateway parameter is
included here. It requires special attention since its configuration is dependent on the type of traffic the Oracle
USM is servicing.
Physical and network interfaces—enables the Oracle USM to communicate with any network element. Interfaces
are one of the most basic configurations you need to create.
SIP Interfaces and Ports—creates an interface on the Oracle USM through which the system can send, receive and
process SIP messages.
SNMP—used for monitoring system health throughout a network.
Syslogs and Process logs—used to save a list of system events to a remote server for analysis and auditing
purposes.
Host routes—used to instruct the Oracle USM host how to reach a given network that is not directly connected to
a local network interface.
General System Information
This section explains the parameters that encompass the general system information on a Oracle USM.
System Identification
Global system identification is used primarily by the Oracle USM to identify itself to other systems and for general
identification purposes.
Connection Timeouts
It is important to set administrative session timeouts on the Oracle USM for security purposes. If you leave an active
configuration session unattended, reconfiguration access is left open to anyone. By setting a connection timeout, only
a short amount of time needs to elapse before the password is required for Oracle USM access.
Oracle® Communications Unified Session Manager
97
System Configuration
Timeouts determine the specified time period that must pass before an administrative connection is terminated. Any
subsequent configuration activity can only be performed after logging in again to the Oracle USM. The timeout
parameter can be individually specified for Telnet sessions and for console port sessions.
After the Telnet timeout passes, the Telnet session is disconnected. You must use your Telnet program to log in to the
Oracle USM once again to perform any further configuration activity.
After the console timeout passes, the console session is disconnected. The current session ends and you are returned
to the login prompt on the console connection into the Oracle USM.
Configuring General System Information
This section explains how to configure the general system parameters, timeouts, and the default gateway necessary to
configure your Oracle USM.
To configure general system information:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type system and press Enter to access the system-level configuration elements.
ORACLE(configure)# system
3. Type system-config and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(system)# system-config
ORACLE(system-config)#
The following is an example what a general system information configuration might look like. Parameters not
described in this section are omitted below.
ORACLE(system-config)# show
system-config
hostname
description
location
default-gateway
telnet-timeout
console-timeout
last-modified-date
test1
Example SD
Row 3, Rack 4, Slot 451
10.0.2.1
1000
1000
2004-12-08 20:15:43
When showing a single-instance configuration element such as system-config, you must first use the select
command to select the configuration element prior to viewing.
System Identification
You must specify identification parameters for this Oracle USM.
Set the following parameters to configure the system identification:
1. hostname—Set the primary hostname used to identify the system. This parameter is used by the software for
informational purposes.
2. description—Enter a textual description of thesystem. This parameter is used for informational purposes.
3. location—Set a location description field for your system. This parameter is used for informational purposes. For
example, you could include the site name and address of the location where the Oracle USM system chassis is
located.
4. default-gateway—Set the default gateway for this Oracle USM. This is the egress gateway for traffic without an
explicit destination. The application of your Oracle USM determines the configuration of this parameter.
98
Oracle® Communications Unified Session Manager
System Configuration
Configuring Connection and Debug Logging Timeouts
Configure the timeouts for terminal sessions on this Oracle USM. These parameters are optional.
Set the following parameters to configure the connection timeouts:
1. telnet-timeout—Set the Telnet timeout to the number of seconds you want the Oracle USM to wait before it
disconnects a Telnet session or an SSH session. The default value is 0. The valid range is:
• Minimum—0
• Maximum—65535
2. console-timeout—Set the console timeout to the number of seconds you want the Oracle USM to wait before it
ends the console session. The default value is 0. The valid range is:
• Minimum—0
• Maximum—65535
3. debug-timeout—Set the time in seconds you want to use for the debug timeout. This is the time allowed before the
Oracle USM times out log levels for system processes set to debug using the ACLI notify and debug commands.
This command does not affect log levels set in your configuration (using parameters such as systemconfig>process-log-level) or those set using the ACLI log-level command.
The valid range is:
•
•
Minimum—0
Maximum—65535
Acme Packet 6300 Physical Interfaces
Acme Packet 6300 Management Interfaces
The Acme Packet 6300 includes 3 x 10/100/1000 Ethernet interfaces, a console port, and an alarm port (“dry contact
alarms”). Network management interfaces are referred to as wancom0, wancom1, and wancom2. There is no front
facing console port. Maintenance and control ports are located on the left-rear of the chassis, above the power
supplies. See the following diagram:
1.
2.
3.
4.
5.
6.
Console port
Alarm port
wancom0
wancom1
wancom2
USB Port (for Acme Packet personnel access only)
Oracle® Communications Unified Session Manager
99
System Configuration
Acme Packet 6300 Media Interfaces
The Acme Packet 6300 has 3 PHY card slots. The bottom slot, slot0, and the middle slot, slot1, are network-facing
media interfaces. The top slot, slot2, is for special processing hardware such as transcoding and is referred to as the
“resource” slot. Standard Acme Packet 6300 PHY cards contain 2 x 10-gigabit Ethernet ports.
Ensure that the first 2x10Gig NIU in your system populates slot0. If you are using a second 2x10Gig NIU, it should
be inserted into slot1.
Note: Do not insert any 2x10Gig NIU in the resource slot (slot2).
The Acme Packet 6300 platform supports up to 4 x 10 gigabit media ports each running at full duplex line rate for all
packet sizes.
Ports on the Acme Packet 6300 are numbered from left to right starting at 0. For physical interface configuration, see
the following diagram
1.
2.
3.
4.
Slot 0, Port 0
Slot 0, Port 1
Slot 1, Port 0
Slot 1, Port 1
Acme Packet 4500 Physical Interfaces
There are two sets of physical interfaces on the network interface unit (NIU) used in the Acme Packet 4500. These
interfaces are located on the rear of the system chassis.
•
•
Media interfaces are on the network interface unit (NIU); they are also referred to as network media ports
Management interfaces are also on the NIU; they are also referred to as network management ports
The following picture of the NIU shows you how the network media and network management ports appear. These
designations are an important point of reference when you set up physical interface configurations. Note that the slot
parameter for network management ports will always be set to zero (0).
Network Media Interfaces
The NIU installed on your Acme Packet 4500 determines the number of interfaces, hardware protocol, and
connection speed available for media and signaling traffic.
•
The NIU offers either four ports , and can use single mode or multimode fiber with an LC connector.
•
•
•
•
•
•
100
4-port GigE copper (RJ45)
4-port GigE SFP (LX, SX, or Copper)
4-port GigE SFP with QoS and IPSec (LX, SX, or Copper)
4-port GigE SFP with IPSec (LX, SX, or Copper)
4-port GigE SFP with QoS (LX, SX, or Copper)
4-port GigE SFP ETC NIU (LX, SX, or Copper)
Oracle® Communications Unified Session Manager
System Configuration
Network Management Interfaces
The first management interface (labeled port 0 on the NIU’s group of management ports) is used to carry traffic such
as:
•
•
•
•
•
•
•
SNMP
Telnet
SSH
FTP
ACP/XML
Logs sent from the Oracle USM
Boot the Oracle USM from a remote file server
The other two rear interfaces (port 1 and port 2) are used for state replication for high availability (HA). For HA,
these interfaces on the Acme Packet 4500 are directly connected by a crossover cable.
The following table summarizes the physical interface configuration parameters, which interface they are applicable
to, and whether they are required.
Parameter
Network Media Interface
Network Management Interface
name
R
R
operation-type
R
R
port
R
R
slot
R
R
virtual-mac
O
I
admin-state
R
I
auto-negotiation
R
I
duplex-mode
R
I
speed
R
I
wancom-health-score
I
O
R = Required, O = Optional, I = Invalid
Before You Configure
This section describes steps you should take prior to configuring physical interfaces.
Oracle® Communications Unified Session Manager
101
System Configuration
Before you configure a physical interface:
1. Decide on the number and type of physical interfaces you need.
For example, you might have one media interface connecting to a private network and one connecting to the
public network. You might also need to configure maintenance interfaces for HA functionality.
2. Determine the slot and port numbering you will need to enter for the physical interfaces you want to configure.
The graphic above can serve as your slot and port numbering reference.
3. If you are configuring your Acme Packet 4500 for HA, refer to the HA Nodes documentation and follow the
instructions there for setting special parameters in the physical interface configuration.
Physical Interface Configuration
This section describes how to configure physical interfaces.
1. Access the phy-interface configuration element.
ORACLE# configure terminal
ORACLE(configure)# system
ORACLE(system)#phy-interface
ORACLE(phy-interface)#
2. name—Set a name for the interface using any combination of characters entered without spaces. For example:
s0p0.
3. admin-state—Leave the administrative state parameter set to enabled to receive and send traffic on this interface.
Select disabled to prevent media and signaling from being received and sent. The default for this parameter is
enabled.
4. operation-type—Select the type of physical interface connection to use. Refer to the appropriate platform section
to identify how this parameter corresponds to an external interface. The default value is control. The valid values
are:
•
•
media—Use this value for configuring the media interfaces which carry production traffic.
maintenance—Use this value for configuring the management physical interfaces, used for management
protocols or HA.
• control—This legacy parameter may also be used to configure the management physical interfaces.
5. slot—Set the slot number for this physical interface. Refer to the appropriate platform section to identify how this
parameter corresponds to an external interface.
6. port—Set the port number for this physical interface. Refer to the appropriate platform section to identify how
this parameter corresponds to an external interface.
7. auto-negotiation—Leave this parameter set to enabled so that the Oracle USM and the device to which it is
linked can automatically negotiate the duplex mode and speed for the link.
If auto-negotiation is enabled, the Oracle USM begins to negotiate the link to the connected device at the duplex
mode you configure. If auto-negotiation is disabled, then the Oracle USM will not engage in a negotiation of the
link and will operate only at the duplex mode and speed you set. The default is enabled. The valid values are:
• enabled | disabled
8. duplex-mode—Set the duplex mode. The default is full; this field is only used if the auto-negotiation field is set
to disabled.
Given an operating speed of 100 Mbps, full duplex mode lets both devices on a link send and receive packets
simultaneously using a total bandwidth of 200 Mbps. Given the same operating speed, half duplex mode limits the
devices to one channel with a total bandwidth of 100 Mbps. The valid values are:
• half | full
9. speed—Set the speed in Mbps of the physical interfaces; this field is only used if the auto-negotiation field is set
to disabled. 100 is the default. The valid values are:
•
102
10 | 100 | 1000
Oracle® Communications Unified Session Manager
System Configuration
10. virtual-mac—Refer to Oracle USM High Availability (HA) documentation to learn how to set this parameter on
an HA interface.
11. Type done to save your configuration.
Phy Link Redundancy (USM)
On your Net-Net 4500, you can configure any NIU for phy link redundancy. Each slot pair (SxP1 and SxP2) behaves
as though it has only a single port by only using one port as an active port at one time.
In this redundancy scheme, port 0 on slots 0 and 1 is the master port and port 1 is the backup port. The card receives
and sends all traffic on one port, while the other acts as a standby in the event of failure. In this way, the two-port
GigE card behaves as though it were a single-port card by only using one port as an active at one time.
Phy link redundancy is configured by setting the link-redundancy-state parameter to enabled in system-config. This
feature is enabled system-wide.
You can force a switchover from one port to its redundant port using the switchover-redundancy-link parameter.
The value of enabling this feature is that, in the event of a network or link failure, the Oracle USM will automatically
fail over to another physical link. The Oracle USM polls link state on a one-second basis, so the maximum outage you
might experience prior to link failure detection and switchover is one second. And if gateway heartbeats are enabled,
then gateway timeout alarms will also cause failovers.
If you are not using an HA node set-up with two Oracle USMs, then this feature can provide link-level redundancy.
Even if you are using two systems as an HA node, this feature can prevent the need for one Oracle USM in the node
to failover to the other by simply failing over its own link; the failure of one link does not cause health score
decrements that result in a system-to-system switchover. However, in the event that both the active and standby ports
fail on a single slot, the Oracle USMs will decrement its health score so that an active-to-standby switchover will
occur.
Please note the following:
•
•
•
•
Physical interface configuration for the standby port must not exist. You must configure a network interface for
the first port (port 0). The configured port becomes the preferred active port.
A critical level ALARM will be issued during operation if both the active and standby ports go LINK down.
Link redundancy is non-revertive. Thus, after switching over to the standby, if the formerly-active port recovers
link, the Oracle USM does not switch back.
The criteria for port swtichover are:
•
•
•
Link down event on active port
ARP timeout to the gateway configured on the media interface
Administratively-forced switchover
Caveats
•
•
Be aware that DoS protection and QoS metrics are not compatible with this feature. However, hostpath DoS
protection is still available when you enable phy link redundancy.
Link redundancy statistics are not mirrored between active and standby nodes in an HA pair.
Phy Link Redundancy Configuration
This section shows you how to enable phy link redundancy, how to force a switchover, and how to view information
about the redundancy links.
Only configure port 0, the redundant port 1 is automatically configured.
1. Access the system-config configuration element.
ORACLE# configure terminal
ORACLE(configure)# system
Oracle® Communications Unified Session Manager
103
System Configuration
ORACLE(system)# system-config
ORACLE(system-config)#
2. Type select to begin editing the system-config object.
ORACLE(system-config)# select
ACMEPACKET(system-config)#
3. link-redundancy-state—Set this parameter to enabled if you want to use phy link redundancy for your system
with two two-port GigE cards installed. A value of disabled turns this feature off. The default is disabled. The
valid values are:
• enabled | disabled
4. Type done to save your configuration.
To view link redundancy state, in Superuser mode, execute the show redundancy link command.
console# show redundancy link
Active port on Slot 0 is port: 1
Slot 0 Switchover Events: 1
Active port on Slot 1 is port: 0
Slot 1 Switchover Events: 0
To force a switchover, in Superuser mode, execute the switchover-redundancy-link and a Space and the slot number
(0 or 1). This change the roles of the active and the standby ports on the slot you specify. If the command is
successful, then no further information will be displayed.
ORACLE# switchover-redundancy-link 0
The system allows you to switch links only if the newly active link is up. If it is not, then the system displays
information that tells you why the operation could not be completed:
Switch From Slot 1 Port 1, to Port 0 was not completed
Due to the fact Link State for Slot 1 Port 0 is down
Interface Utilization Graceful Call Control Monitoring and Fault
Management
When you enable this feature, the Oracle USM monitors network utilization of its media interfaces and sends alarms
when configured thresholds are exceeded. You can also enable overload protection on a per-media interface basis,
where the Oracle USM will prevent call initializations during high traffic but still allow established calls to continue if
traffic passes the critical threshold you define.
Calculation Overview
When enabled to do so, the Oracle USM performs a network utilization calculation for each of its media ports. This
calculation takes into account rates of receiving and transmitting data, the speed at which each is taking place, and the
quality of data traversing the interface. The Oracle USM keeps statistics for each media port so it can compare
previously- and newly-retrieved data. For heightened accuracy, calculations are performed with milliseconds (rather
than with seconds).
Alarms
In the physical interface configuration, you can establish up to three alarms per media interface—one each for minor,
major, and critical alarm severities. These alarms do not have an impact on your system’s health score. You set the
threshold for an alarm as a percentage used for receiving and transmitting data.
For example, you might configure the following alarms:
•
•
•
104
Minor, set to 50%
Major, set to 70%
Critical, Set to 90%
Oracle® Communications Unified Session Manager
System Configuration
When the utilization percentage hits 50%, the system generates a minor alarm. At 70%, the system clears the minor
alarm and issues a major one. And at 90%, the system clears the major alarm and issues a critical one. At that point, if
you have overload protection enabled, the system will drop call initiations but allow in-progress calls to complete
normally.
To prevent alarm thrashing, utilization must remain under the current alarm threshold for 10 seconds before the
system clears the alarm and rechecks the state.
Alarm Configuration
This section shows you how to configure alarm thresholds and overload protection per media interface.
Configuring Utilization Thresholds for Media Interfaces
To configure utilization thresholds for media interfaces:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
2. Type system and press Enter.
ORACLE(configure)# system
ORACLE(system)#
3. Type phy-interface and press Enter. If you are adding this feature to an existing configuration, then remember you
must select the configuration you want to edit.
ORACLE(system)# phy-interface
ORACLE(phy-interface)#
4. Type network-alarm-threshold and press Enter.
ORACLE(phy-interface)# network-alarm-threshold
ORACLE(network-alarm-threshold)#
5. severity—Enter the severity for the alarm you want to fine for this interface: minor (default), major, or critical.
Since the parameter defaults to minor, you must change the value if you want to define a major or critical alarm.
6. value—Enter the percentage of utilization (transmitting and receiving) for this interface that you want to trigger
the alarm. For example, you might define a minor alarm with a utilization percentage of 50. Valid values are
between 0 and 100, where 0 is the default.
7. Save your work.
Configuring Graceful Call Control
You can enable the Oracle USM to stop receiving session-initiating traffic on a media interface when the traffic for
the interface exceeds the critical threshold you define for it.
To enable graceful call control:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
2. Type system and press Enter.
ORACLE(configure)# system
ORACLE(system)#
3. Type phy-interface and press Enter. If you are adding this feature to an existing configuration, then remember you
must select the configuration you want to edit.
ORACLE(system)# phy-interface
ORACLE(phy-interface)#
4. overload-protection—Change this parameter’s value to enabled if you want to turn graceful call control on. Leave
it set to disabled (default) if you do not want to use this feature.
Oracle® Communications Unified Session Manager
105
System Configuration
5. Save your work.
Network Interfaces
The network interface element specifies a logical network interface. In order to use a network port on a network
interface, you must configure both the physical interface and the corresponding network interface configuration
elements. If the network interface does not use VLANs tagging, ensure that the sub-port-id parameter is set to 0, the
default value. When VLAN tags are used on a network interface, the valid sub-port-id value can range from 1-4096.
The combination of the name parameter and the sub-port-id parameter must be unique in order to identify a discrete
network interface.
IP Configuration
A Oracle USM network interface has standard parameters common to nearly all IP network interfaces. There are a
few fields that are unique to the Oracle USM.
VLANs
VLANs are used to logically separate a single physical interface into multiple network interfaces. There are several
applications for this like MPLS VPNs (RFC 2547), MPLS LSPs, L2VPNs (IPSec, L2TP, ATM PVCs), reusing
address space, segmenting traffic, and maximizing the bandwidth into a switch or router. The range of services and
management capabilities you can implement with VPNs is huge.
The primary applications of VLANs on the Oracle USM are VPNs and peering. Several peering partners may
terminate their connections to a Oracle USM on a single physical interface. VLAN tags are used to segregate and
correctly route the terminated traffic. The Oracle USM can support a maximum of 1024 VLANs per physical
interface. Ingress packets that do not contain the correct VLAN tag will be dropped. All packets exiting on an egress
interface will have the VLAN tag appended to them.
The Oracle USM can be included in an MPLS network through its connectivity to a PE router, which maps a MPLS
VPN label to an 802.1q VLAN tag. Each Oracle USM can terminate different 802.1q VLANs into separate network
interfaces, each of which can represent a different customer VPN.
Overlapping Networks
Overlapping networks are when two or more private networks with the same addressing schemes terminate on one
physical interface. The problem this creates can easily be solved by using VLAN tagging. For example, two 10.x.x.x
networks terminating on one Oracle USM network interface will obviously not work. The Oracle USM includes the
IP Address, Subnet Mask, and 802.1q VLAN tag in its Network Interface determination. This allows Oracle USM to
directly interface to multiple VPNs with overlapping address space.
HIP
By default, the Oracle USM’s FTP, ICMP, SNMP, and Telnet services cannot be accessed via the media interfaces. In
order to enable these services, the Oracle USM includes four fields that enable administrative traffic over the media
interfaces. These are collectively known as the HIP, or host-in-path functions. The HIP parameters are effectively
firewall functions that open the well-known ports for specified services on media interfaces.
Configurable MTU Size
Configurable MTU on per network-interface basis enables the user to set a different MTU on each network interface.
It also enables the user to set a system wide default MTU for IPv6 and IPv4 network interfaces. System wide defaults
can be set in system-config configuration object by setting ipv6-signaling-mtu or ipv4-signaling-mtu. Defaults are
1500 for both IPv6 and IPv4.
These settings can be overwritten for each network interface by setting signaling-mtu in network-interface
configuration object. Default is 0 – meaning use the system wide MTU.
This feature applies to all Signaling packets generated by the Oracle USM. All UDP packets greater than the MTU
will be fragmented. For all TCP connections we advertise MSS (Maximum Segment Size) TCP option in accordance
106
Oracle® Communications Unified Session Manager
System Configuration
with the configured MTU. MSS option is sent in SYN and SYN/ACK packets to let the other side of the TCP
connection know what your maximum segment size is. This ensures that no TCP packet is greater than the configured
MTU.
1. MTU settings do not apply to media packets.
2. UDP: MTU settings apply only to packets sent by the Oracle USM. The Oracle USM will continue to process
received packets even if they exceed to the configured MTU.
3. Security Phy (IPsec) hardware only; We subtract 100 bytes from the configured MTU to allow for extra headers
added by security protocols. This happens even when Security Phy (IPsec) is in clear mode (no security is being
applied). Due to hardware limitations of the Security Phy (IPsec) it only allows one MTU per physical port. The
maximum MTU of all network interfaces on a given physical port will be used as the MTU for that physical port.
4. The Call Recording feature is where we make a copy of a packet, encapsulate it in an IP-in-IP header and send it
to a configured Call Recording Server (CRS). When Call Recording is enabled, to allow space for IP-in-IP
encapsulation we reduce the MTU of the original packets to be to be the lesser of the two options listed below.
•
•
Original Destination network MTU minus size of IP-in-IP header.
CRS network interface’s MTU minus size of IP-in-IP header.
Note: This will ensure that the traffic sent to the CRS will be within the MTU constraints of CRS’
network-interface.
Network Interface Configuration
This section explains how to access and configure network interface.
Special Considerations
Configuration changes to network interface parameters might have an impact on boot configuration parameters. After
configuring the network interface, you might receive a message indicating that you could be changing boot config
parameters under the following circumstances:
•
•
A physical interface or network interface element matches the boot interface (for example, the physical port is the
same as the boot port).
The boot configuration parameters are modified, because the IPv4 address, netmask, or gateway is different from
the corresponding boot configuration parameters.
You are asked if you want to continue. If you enter yes, the configuration will be saved and then the differing boot
configuration parameters will be changed. If you enter no, then the configuration is not saved and the boot
configuration parameters are not changed.
Configuring the physical and network interface elements for the first management interface is optional because that
interface, eth0, is implicitly created by a valid bootparam configuration that specifies the boot device, IPv4 address,
subnet, and gateway.
Network Interfaces Configuration
This section describes how to configure a network interface.
Access the network-interface configuration element.
ORACLE# configure terminal
ORACLE(configure)# system
ORACLE(system)# network-interface
ORACLE(network-interface)
IP Configuration and Identification
You must specify the identity and address for all network interfaces.
Set the following parameters to configure a network interface:
1. name—Set the name for the network interface. This must be the same name as the physical interface to which it
corresponds.
Oracle® Communications Unified Session Manager
107
System Configuration
2.
3.
4.
5.
6.
7.
8.
description—Enter a description of the network for easier identification.
hostname—Set the hostname (FQDN) of this network interface. This parameter is optional.
ip-address—Set the IP address of this network interface.
netmask—Set the netmask of this network interface in dotted decimal notation.
gateway—Set the gateway that this network interface uses to communicate with the next hop.
sec-gateway—Set an additional optional gateway for this network interface
dns-ip-primary—Set the DNS servers. You can set an additional two DNS servers by using the dns-ip-backup1
and dns-ip-backup2 parameters.
9. dns-domain—Set the default domain name.
10. signaling-mtu—Sets the MTU size for IPv4 or IPv6 transmission.
VLAN Configuration
One parameter is required to configure VLANs on a Oracle USM. The sub-port-id parameter located in the
network-interfaces element adds and masks for a specific VLAN tag.
sub-port-id—Enter the identification of a specific virtual interface in a physical interface (e.g., a VLAN tab). If
this network interface is not channelized, leave this field blank, and the value will correctly default to 0. The subport-id is only required if the operation type is Media. The valid range is:
•
•
Minimum—0
Maximum—4095.
HIP Addresses
To configure administrative service functionality on a media interface, you must define the IP addresses on the media
interfaces of your Oracle USM where you will receive administrative traffic. Adding HIP entries automatically opens
the well-known port associated with a service.
Set the following parameters to configure HIP functionality on a network interface:
1. add-hip-ip—Set all possible IP address(es) on which you want the Oracle USM to accept administrative traffic.
Entries in this element are IP addresses of media network interfaces. This parameter can accept multiple IP
addresses. You can later remove this entry by typing remove-hip-ip followed by the appropriate IP address.
2. add-ftp-ip—Set the IP address where ports 20 and 21 are opened. This allows standard FTP packets enter the
Oracle USM and reach the host. You can later remove this entry by typing remove-ftp-ip followed by the
appropriate IP address.
3. add-icmp-ip—Set the IP addresses to pass standard ping packets to the host; this parameter can accommodate
multiple ping IP addresses. You can later remove this entry by typing remove-icmp-ip followed by the
appropriate IP address.
When you configure multiple ICMP ping addresses in for a network interface, you must also configure the hostin-path addresses in the hip-ip-list for each IMCP address. For security, if the ICMP address and the hip-ip-list are
not added for an address, the Oracle USM hardware discards ICMP requests or responses for the address.
To remove multiple IP addresses at one time, type the remove-icmp-ip and a Space, open quotation mark (“), the
IP addresses you want removed from the list each separated by a space, close quotation mark (”), and then press
Enter.
ORACLE (network-interface)# remove-icmp-ip "142.214.5.34 124.8.67.3"
4. add-snmp-ip—Set the IP address where port 161 is opened. This lets SNMP traffic enter the Oracle USM and
reach the host. You can later remove this entry by typing remove-snmp-ip followed by the appropriate IP address.
5. add-telnet-ip—Set the IP address where port 23 is opened for telnet access. You can later remove this entry by
typing remove-telnet-ip followed by the appropriate IP address.
Configurable MTU Size
Configurable MTU on per network-interface basis enables the user to set a different MTU on each network interface.
It also enables the user to set a system wide default MTU for IPv6 and IPv4 network interfaces. System wide defaults
108
Oracle® Communications Unified Session Manager
System Configuration
can be set in system-config configuration object by setting ipv6-signaling-mtu or ipv4-signaling-mtu. Defaults are
1500 for both IPv6 and IPv4.
These settings can be overwritten for each network interface by setting signaling-mtu in network-interface
configuration object. Default is 0 – meaning use the system wide MTU.
This feature applies to all Signaling packets generated by the Oracle USM. All UDP packets greater than the MTU
will be fragmented. For all TCP connections we advertise MSS (Maximum Segment Size) TCP option in accordance
with the configured MTU. MSS option is sent in SYN and SYN/ACK packets to let the other side of the TCP
connection know what your maximum segment size is. This ensures that no TCP packet is greater than the configured
MTU.
1. MTU settings do not apply to media packets.
2. UDP: MTU settings apply only to packets sent by the Oracle USM. The Oracle USM will continue to process
received packets even if they exceed to the configured MTU.
3. Security Phy (IPsec) hardware only; We subtract 100 bytes from the configured MTU to allow for extra headers
added by security protocols. This happens even when Security Phy (IPsec) is in clear mode (no security is being
applied). Due to hardware limitations of the Security Phy (IPsec) it only allows one MTU per physical port. The
maximum MTU of all network interfaces on a given physical port will be used as the MTU for that physical port.
4. The Call Recording feature is where we make a copy of a packet, encapsulate it in an IP-in-IP header and send it
to a configured Call Recording Server (CRS). When Call Recording is enabled, to allow space for IP-in-IP
encapsulation we reduce the MTU of the original packets to be to be the lesser of the two options listed below.
•
•
Original Destination network MTU minus size of IP-in-IP header.
CRS network interface’s MTU minus size of IP-in-IP header.
Note: This will ensure that the traffic sent to the CRS will be within the MTU constraints of CRS’
network-interface.
System Wide MTU Size
To change system wide MTU settings:
1. Access the system-config configuration element.
ORACLE# configure terminal
ORACLE(configure)# system
ORACLE(system)# system-config
ORACLE(system-config)#
2. Type select to begin editing the system-config object.
ORACLE(system-config)# select
ACMEPACKET(system-config)#
3. ipv6-signaling-mtu or ipv4-signaling-mtu Configure MTU in the system config and optionally in the network
interface. Default will be 1500 bytes.
ORACLE(system-config)# ipv6-signaling-mtu 1500
ORACLE(system-config)# ipv4-signaling-mtu 1600
4. Type done to save your configuration.
Required SIP Configuration
TheOracle USM requires that SIP processing be operational to perform basic service. Required configuration,
discussed within this section, includes:
•
•
•
•
Enable SIP Config
Configure SIP Interfaces
Configure SIP Ports
Configure SIP Digest Authentication
Oracle® Communications Unified Session Manager
109
System Configuration
The Oracle USM provides a myriad of other SIP controls, which you may or may not need for your deployment. See
the Chapter on SIP Signaling Services for explanations of and configuration instructions to these SIP services.
Enabling SIP-Config
The Oracle USM cannot process SIP messaging if the sip-config is not enabled. To enable sip-config:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter to access the system-level configuration elements.
ORACLE(configure)# session-router
3. Type sip-config and press Enter to access the sip-config configuration elements.
ORACLE(session-router)# sip-config
4. Type select and press Enter to select the sip-config configuration element.
ORACLE(sip-config)# select
Selecting the sip-config is required, as is true of all single instance element.
5. Type enable and press Enter to enable the sip-config element.
ORACLE(sip-config)# enable
6. Type done to make this setting, then save and activate your configuration.
SIP Interfaces
This section explains how to configure a SIP interface. The SIP interface defines the transport addresses (IP address
and port) upon which theOracle USM receives and sends SIP messages.
Overview
The SIP interface defines the signaling interface. You can define a SIP interface for each network or realm to which
the Oracle USM is connected. SIP interfaces support both UDP and TCP transport, as well as multiple SIP ports
(transport addresses). The SIP interface also lets Hosted NAT Traversal (HNT) be used in any realm.
The SIP interface configuration process involves configuring the following features:
•
•
•
•
address and transport protocols (SIP ports)
redirect action
proxy mode
trust mode
About SIP Ports
A SIP port defines the transport address and protocol the Oracle USM will use for a SIP interface for the realm. A SIP
interface will have one or more SIP ports to define the IP address and port upon which the Oracle USM will send and
receive messages. For TCP, it defines the address and port upon which the Oracle USM will listen for inbound TCP
connections for a specific realm.
You need to define at least one SIP port, on which the SIP proxy will listen for connections. If using both UDP and
TCP, you must configure more than one port. For example, if a call is sent to the Oracle USM using TCP, which it
needs to send out as UDP, two SIP ports are needed.
Preferred SIP Port
When a SIP interface contains multiple SIP ports of the same transport protocol, a preferred SIP port for each
transport protocol is selected for outgoing requests when the specific SIP port cannot be determined. When
forwarding a request that matched a cached registration entry (HNT or normal registration caching), the SIP port upon
which the original REGISTER message arrived is used. Otherwise, the preferred SIP port for the selected transport
protocol is used. When selecting the preferred SIP port, the default SIP port of 5060 will be selected over other nondefault ports.
110
Oracle® Communications Unified Session Manager
System Configuration
For SIP interfaces using the SIP NAT function, the preferred SIP port address and port will take precedence over the
external address of the SIP NAT when they do not match. If both TCP and UDP SIP ports are defined, the address and
port of the preferred UDP port is used.
Proxy Mode
The Oracle USM’s proxy mode determines whether it forwards requests received on the SIP interface to target(s)
selected from local policy; or sends a send a redirect response to the previous hop. Sending the redirect response
causes the previous hop to contact the targets directly.
If the source of the request matches a session agent with a proxy mode already defined, that mode overrides the proxy
mode defined in the SIP interface.
You can configure the proxy mode to use the Record-Route option. Requests for stateless and transaction operation
modes are forwarded with a Record-Route header that has the Oracle USM’s addresses added. As a result, all
subsequent requests are routed through the Oracle USM.
Redirect Action
The redirect action is the action the SIP proxy takes when it receives a SIP Redirect (3xx) response on the SIP
interface. If the target of the request is a session agent with redirect action defined, its redirect action overrides the SIP
interface’s.
You can set the Oracle USM to perform a global redirect action in response to Redirect messages. Or you can retain
the default behavior where the Oracle USM sends SIP Redirect responses back to the previous hop (proxy back to the
UAC) when the UAS is not a session agent.
The default behavior of the Oracle USM is to recurse-305-only. If the Oracle USM receives a 305 SIP redirect
response (Use Proxy) on the SIP interface, it automatically redirects all requests to the Contact URI specified in the
305 response. All other 3xx responses are sent back to the previous hop.
When the redirect-action parameter is set to recurse, it does so on SIP Redirect responses received from the user agent
server (UAS) and sends a new request to the Contact headers contained in the SIP Redirect response.
Instead of this behavior, the Oracle USM can proxy the SIP Redirect response back to the user agent client (UAC)
using the value in the session agent’s redirect action field (when the UAS is a session agent). If there are too many
UASes to define as individual session agents or if the UASs are HNT endpoints, and SIP Redirect responses need to
be proxied for UASs that are not session agents; you can set the default behavior at the SIP Interface level.
SIP maddr Resolution
Release S-C6.2.0 provides enhanced resolution of addresses found in SIP contact headers, or in the maddr (multicast
address) parameter of SIP 3xx REDIRECT messages. Previous releases resolved these addresses as either a host
address or as a session agent name. With Release 6.2.0 these addresses can also be resolved as session agent group
(SAG) names.
Support for SAG-based resolution is provide by a new sip-config parameter, sag-lookup-on-redirect. By default, SAG
lookup is disabled, providing compatibility with prior releases.
The following sample SIP REDIRECT and ACLI configuration fragment illustrate enhanced processing.
Status-Line: SIP/2.0 302 Moved
Message Header
Via: SIP/2.0/UDP
192.168.200.224:5060;branch=z9hG4bKa0fs40009o90sc8oo780.1
From: <sip:1111@192.168.1.222:6000>;tag=1
To: sut <sip:2223@192.168.1.224:5060>;tag=11
Call-ID: 1-28515@192.168.1.222
CSeq: 1 INVITE
Contact: <sip:1111@192.168.1.223;maddr=test.acmepacket.com>
Privacy: user;id;critical;session
P-Preferred-Identity: sipp <sip:sipp@192.168.200.222:5060>
P-Asserted-Identity: abc.com
Subject: abc
Proxy-Require: privacy,prack,abc
Oracle® Communications Unified Session Manager
111
System Configuration
Content-Length: 0
session-group
group-name
description
state
app-protocol
strategy
dest
...
...
test.acmepacket.com
enabled
SIP
Hunt
192.168.200.222
192.168.200.223
In this case, when the Oracle USM receives the 302, it resolves the information from maddr to a SAG name. In the
above example, it will resolve to the configured SAG – test.acmepacket.com. The destinations configured in SAG
test.acmepacket.com will be used to route the call.
SAG-based address resolution is based on the following set of processing rules.
1. When the Contact URI does not have an maddr parameter, and the hostname is not an IP Address, the Oracle
USM will look for a SAG matching the hostname.
2. When the Contact URI has an maddr parameter that contains an IP address, the Oracle USM will not look for a
SAG; it will use the IP Address as the target/next-hop.
3. When the Contact URI has an maddr parameter that contains a non-IP-address value, the Oracle USM will look
for a SAG matching the maddr parameter value.
The above logic can be turned on by enabling sag-lookup-on-redirect in the sip-config object as shown below.
SIP maddr Resolution Configuration
To configure the Oracle USM to perform SAG-based maddr resolution:
1. From superuser mode, use the following command sequence to access sip-config configuration mode. While in
this mode, you configure SAG-based address resolution.
ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# sip-config
ORACLE(sip-config)#
2. Use the sag-lookup-on-redirect parameter to enable SAG-based maddr resolution.
3. Use done, exit, and verify-config to complete SAG-based address resolution.
Trust Mode
The Oracle USM supports the Calling Identity privacy requirements based on RFC 3323 and RFC 3325. The trust
mode in the SIP interface determines whether the source and destination of a request is a trusted entity. With the
implementation of this feature, the Oracle USM can understand and support the privacy headers and provide the
capability for anonymous packets
The Oracle USM, which acts as a boundary device between the trusted platform and the untrusted Internet,
understands the following headers:
•
•
•
Privacy Header
P-Asserted-Identity Header
P-Preferred-Identity Header
Depending on the value of these headers and the mode in which the Oracle USM is being operated (B2BUA or the
proxy), the appropriate actions are performed.
About the Process
On receiving a message, the Oracle USM checks whether the message source is trusted or not. It checks the SIP
interface’s trust mode value and, if the source is a session agent, the session agent’s trust me value. Depending on
112
Oracle® Communications Unified Session Manager
System Configuration
these values, the Oracle USM decides whether the request’s or response’s source is trusted. If it receives message
from a trusted source and the message contains the P-Asserted-Identity header field, the Oracle USM passes this
message to the outgoing side. The outgoing side then decides what needs to be done with this request or response.
If the request or the response is received from an untrusted source, the Privacy header value is id (privacy is
requested), and the P-Asserted-Identity header field is included, the Oracle USM strips the Privacy and the PAsserted-Identity headers and passes the request or the response to the outgoing side.
If the request or the response contains the P-Preferred-Identity header and the message source is untrusted, the Oracle
USM strips the P-Preferred-Identity header from the request or the response and passes the message to the outgoing
side.
If the source is trusted or privacy is not requested (the value of the Privacy Header is not id) and the request or the
response contains the P-Preferred-Identity header, the Oracle USM performs the following actions:
•
•
•
inserts the P-Asserted-Identity header field with the value taken from the P-Preferred-Identity header field
deletes the P-Preferred-Identity header value
passes this request or the response to the Outgoing side for the appropriate action, depending on the whether the
destination is trusted or not
After the Oracle USM passes the request or the response to the outgoing side, it checks whether the destination is
trusted by checking the SIP interface’s trust mode value and the session agent’s trust me value (if the destination is
configured as session agent).
•
The destination is trusted
•
The Oracle USM does nothing with the request or the response and passes it to the destination. If the
P_Asserted_Identity headers are present, they are passed to the session agent (if the destination is configured as
session agent).
The destination is untrusted
The Oracle USM looks at the value of the Privacy header. If set to id, the Oracle USM removes all the P-AssertedIdentity headers (if present). It strips the Proxy-Require header if it is set to privacy. The Oracle USM also sets the
From field of SIP header to Anonymous and strips the Privacy header.
If the Privacy header is set to none, the Oracle USM does not remove the P-Asserted-Identity header fields.
If there is no Privacy header field, the SD will not remove the P-Asserted-Identity headers.
To implement this feature, you need to configure the session agent’s trust me parameter to enabled (if the message
source is a session agent) and the SIP interface’s trust mode to the appropriate value.
Configurable Timers and Counters
SIP timers and counters can be set in the global SIP configuration, and two can be specific for individual SIP
interfaces.
You can set the expiration times for SIP messages, and you can set a counter that restricts the number of contacts that
the Oracle USM tries when it receives a REDIRECT. These are similar to two parameters in the global SIP
configuration, trans-expire and invite-expire. You can also set a parameter that defines how many contacts/routes the
Oracle USM will attempt on redirect.
SIP Interface Configuration
To configure a SIP interface:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter to access the system-level configuration elements.
ORACLE(configure)# session-router
3. Type sip-interface and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
Oracle® Communications Unified Session Manager
113
System Configuration
ORACLE(session-router)# sip-interface
ORACLE(sip-interface)#
From this point, you can configure SIP interface parameters. To view all sip-interface parameters, enter a ? at the
system prompt.
4. state—Enable or disable the SIP interface. The default is enabled. The valid values are:
• enabled | disabled
5. realm-id—Enter the name of the realm to which the SIP interface is connected.
6. sip-ports—Access the sip-ports subelement.
7. carriers—Enter the list of carriers related to the SIP interface.
Entries in this field can be from 1 to 24 characters in length and can consist of any alphabetical character (Aa-Zz),
numerical character (0-9), or punctuation mark (! ”$ % ^ & * ( ) + - = < > ? ‘ | { } [ ] @ / \ ‘ ~ , . _ : ; ) or any
combination of alphabetical characters, numerical characters, or punctuation marks. For example, both 1-0288 and
acme_carrier are valid carrier field formats
8. proxy-mode—Enter an option for the proxy mode parameter. Valid values are:
•
•
•
proxy—Forward all SIP requests to selected targets.
redirect—Send a SIP 3xx redirect response with the selected target(s) in the Contact header.
record-route—Forward requests to selected target(s) and insert a Record-Route header with the Oracle USM’s
address. For stateless and transaction mode only.
9. redirect-action—Enter the value for the redirect action. Valid values are:
•
•
•
recurse-305-only—(default) If the Oracle USM receives a 305 SIP redirect response (Use Proxy) on the SIP
interface, it automatically redirects all requests to the Contact URI specified in the 305 response. All other 3xx
responses are sent back to the previous hop.
proxy—Send the SIP request back to the previous hop.
recurse—Recurses on the Contacts in the response.
The designated proxy action will apply to SIP 3xx responses received from non-session agents and to 3xx
responses received from session agents without configured SIP Redirect message actions (for example, session
agents without values for the redirect action field).
10. contact-mode—Set the Contact header routing mode, which determines how the contact address from a private
network is formatted.
For example, whether a maddr parameter equal to the Oracle USM’s SIP proxy needs to be added to a URI present
in a Contact header.
The default is none. The valid values are:
•
•
•
•
none—The address portion of the header becomes the public address of that private realm.
maddr—The address portion of the header will be set to the IP address of the Oracle USM’s B2BUA.
strict—The contents of the Request-URI is destroyed when a Record-Route header is present.
loose—The Record-Route header is included in a Request, which means the destination of the request is
separated from the set of proxies that need to be visited along the way.
11. nat-traversal—Define the type of HNT enabled for SIP. The default is none. Valid values are:
•
•
none—HNT function is disabled for SIP.
rport—SIP HNT function only applies to endpoints that include the rport parameter in the Via header. HNT
applies when the sent-by of the topmost VIA matches the Contact-URI host address, both of which must be
different from the received Layer 3 address.
• always—SIP HNT applies to requests when the sent-by of the topmost VIA matches the Contact-URI host
address, both of which must be different from the received Layer 3 address. (Even when the rport parameter is
not present.)
12. nat-interval—Set the expiration time in seconds for the Oracle USM’s cached registration entry for an HNT
endpoint. The default is 30. The valid range is:
114
Oracle® Communications Unified Session Manager
System Configuration
•
•
Minimum—0
Maximum—999999999
Oracle recommends setting the NAT interval to one-third of the NAT binding lifetime. A NAT binding lifetime
is the network connection inactivity timeout. The value is configured (or hardwired) in the NAT device
(firewall). This timer is used to cause the UA to send REGISTER messages frequently enough to retain the
port binding in the NAT. Retaining the binding lets inbound requests to be sent through the NAT.
13. tcp-nat-interval—Set the registration cache expiration time in seconds to use for endpoints behind a NAT device
that register using TCP. On upgrade, the Oracle USM assigns this parameter the same value as the existing NAT
interval. The default is 90. The valid range is:
•
•
Minimum—0
Maximum—999999999
The Oracle USM uses the value you set for the TCP NAT interval as the expiration value passed back in SIP
REGISTER (200 OK) responses to endpoints behind a NAT that register over TCP. The NAT interval value
with which you are familiar from previous releases is used for endpoints behind a NAT that register over UDP.
Requiring endpoints that register over TCP to send refresh requests as frequently as those registering over
UDP puts unnecessary load on the Oracle USM. By adding a separate configuration for the TCP NAT interval,
the load is reduced.
For upgrade and backward compatibility with Oracle USM releases prior to Release 4.1, when the
tcpNatInterval is not present in the XML for a SIP interface configuration, the value of the NAT interval
(natInterval) is used for the TCP NAT interval as well.
14. registration-caching—Enable for use with all UAs, not just those that are behind NATs. The default is disabled.
The valid values are:
•
enabled | disabled
•
•
•
If enabled, the Oracle USM caches the Contact header in the UA’s REGISTER request when it is addressed to
one of the following:
Oracle USM
registrar domain value
registrar host value
The Oracle USM then generates a Contact header with the Oracle USM’s address as the host part of the URI
and sends the REGISTER to the destination defined by the registrar host value.
•
•
Whether or not SIP HNT functionality is enabled affects the value of the user part of the URI sent in the
Contact header:
HNT enabled: the Oracle USM takes the user part of the URI in the From header of the request and appends a
cookie to make the user unique. A cookie is information that the server stores on the client side of a clientserver communication so that the information can be used in the future.
HNT disabled: the user part of the Contact header is taken from the URI in the From header and no cookie is
appended. This is the default behavior of the Oracle USM.
When the registrar receives a request that matches the address-of-record (the To header in the REGISTER
message), it sends the matching request to the Oracle USM, which is the Contact address. Then, the Oracle
USM forwards the request to the Contact-URI it cached from the original REGISTER message.
15. min-reg-expire—Set the time in seconds for the SIP interface. The value you enter here sets the minimum
registration expiration time in seconds for HNT registration caching. The default is 300. The valid range is:
•
•
Minimum—0
Maximum—999999999
This value defines the minimum expiration value the Oracle USM places in each REGISTER message it sends
to the real registrar. In HNT, the Oracle USM caches the registration after receiving a response from the real
registrar and sets the expiration time to the NAT interval value.
Oracle® Communications Unified Session Manager
115
System Configuration
Some UAs might change the registration expiration value they use in subsequent requests to the value
specified in this field. This change causes the Oracle USM to send frequent registrations on to the real
registrar.
16. registration-interval—Set the Oracle USM’s cached registration entry interval for a non-HNT endpoint. Enter the
expiration time in seconds that you want the Oracle USM to use in the REGISTER response message sent back to
the UA. The UA then refreshes its registration by sending another REGISTER message before that time expires.
The default is 3600. The valid range is:
•
Minimum—0
•
A registration interval of zero causes the Oracle USM to pass back the expiration time set by and returned in
the registration response from the registrar.
Maximum—999999999
If the expiration time you set is less than the expiration time set by and returned from the real registrar, the
Oracle USM responds to the refresh request directly rather than forwarding it to the registrar.
Although the registration interval applies to non-HNT registration cache entries, and the loosely related NAT
interval applies to HNT registration cache entries, you can use the two in combination. Using a combination of
the two means you can implement HNT and non-HNT architectures on the same Oracle USM. You can then
define a longer interval time in the registration interval field to reduce the network traffic and load caused by
excess REGISTER messages because there is no NAT binding to maintain.
17. route-to-registrar—Enable routing to the registrar to send all requests that match a cached registration to the
destination defined for the registrar host; used when the Request-URI matches the registrar host value or the
registrar domain value, not the Oracle USM’s address. Because the registrar host is the real registrar, it should
send the requests back to the Oracle USM with the Oracle USM’s address in the Request-URI. The default is
disabled. The valid values are:
•
enabled | disabled
For example, you should enable routing to the registrar if your network uses a N Oracle USM and needs
requests to go through its service proxy, which is defined in the registrar host field.
18. teluri-scheme—Enable to convert SIP URIs to tel (resources identified by telephone numbers) URIs.
If enabled, the requests generated on this SIP interface by the Oracle USM will have a tel URI scheme instead of
the SIP URI scheme. Only the Request, From, and To URIs are changed to the tel scheme. After the dialog is
established, the URIs are not changed. The default is disabled. The valid values are:
• enabled | disabled
19. uri-fqdn-domain—Change the host part of the URIs to the FQDN value set here. If set to enabled, and used with
an FQDN domain/host, the requests generated by the Oracle USM on this SIP interface will have the host part of
the URI set to this FQDN value. Only the Request, To, and From URIs are changed. After the dialog is
established, the URIs are not changed.
20. trust-mode—Set the trust mode for the SIP interface, which is checked by the Oracle USM when it receives a
message to determine whether the message source is trusted. The default is all. Available options are:
•
•
all—Trust all SIP elements (sources and destinations) in the realm(s), except untrusted session agents.
Untrusted session agents are those that have the trust-me parameter set to disabled.
agents-only—Trust only trusted session agents. Trusted session agents are those that have the trust-me
parameter set to enabled.
realm-prefix—Trust only trusted session agents, and source and destination IP addresses that match the IP
interface’s realm (or subrealm) address prefix. Only realms with non-zero address prefixes are considered.
registered—Trust only trusted session agents and registered endpoints. Registered endpoints are those with an
entry in the Oracle USM’s registration cache.
none—Trust nothing.
•
•
Session agents must have one or more of the following:
global realm
same realm as the SIP interface
•
•
•
116
Oracle® Communications Unified Session Manager
System Configuration
• realm that is a subrealm of the SIP interface’s realm
21. trans-expire—Set the TTL expiration timer in seconds for SIP transactions. This timer controls the following
timers specified in RFC 3261:
•
•
•
•
Timer B—SIP INVITE transaction timeout
Timer F—non-INVITE transaction timeout
Timer H—Wait time for ACK receipt
Timer TEE—Used to transmit final responses before receiving an ACK
The default is 0. If you leave this parameter set to the default, then the Oracle USM uses the timer value from
the global SIP configuration. The valid range is:
• Minimum—0
• Maximum—999999999
22. invite-expire—Set the TTL expiration timer in seconds for a SIP client/server transaction after receiving a
provisional response.
You set this timer for the client and the sever by configuring it on the SIP interface corresponding to the core or
access side.
The default is 0. If you leave this parameter set to the default, then the Oracle USM uses the timer value from the
global SIP configuration. The valid range is:
• Minimum—0
• Maximum—999999999
23. max-redirect-contacts—Set the maximum number of contacts or routes for the Oracle USM to attempt in when it
receives a SIP Redirect (3xx Response). The default is 0. If you leave this parameter set to the default, then the
Oracle USMwill exercise no restrictions on the number of contacts or routes. The valid range is:
• Minimum—0
• Maximum—10
24. response-map—Enter the name of the SIP response map configuration that you want to apply to this SIP
interfaces for outgoing responses. This parameter is blank by default.
25. local-response-map—Enter the name of the SIP response map configuration that you want to apply to this SIP
interfaces for locally-generated SIP responses. This parameter is blank by default.
26. options—Optional.
Configuring SIP Ports
To configure SIP ports:
1. From sip-interface, type sip-ports and press Enter. The system prompt changes to let you know that you can begin
configuring individual parameters.
ORACLE(sip-interface)# sip-ports
ORACLE(sip-port)#
2. address—Enter the IP address of the host associated with the sip-port entry on which to listen. For example:
192.168.11.101
3. port—Enter the port number you want to use for this sip-port. The default is 5060. The valid range is:
• Minimum—1025
• Maximum—65535
4. transport-protocol—Indicate the transport protocol you want to associate with the SIP port. The default is UDP.
The valid values are:
•
•
TCP—Provides a reliable stream delivery and virtual connection service to applications through the use of
sequenced acknowledgment with the retransmission of packets when necessary.
UDP—Provides a simple message service for transaction-oriented services. Each UDP header carries both a
source port identifier and destination port identifier, allowing high-level protocols to target specific
applications and services among hosts.
Oracle® Communications Unified Session Manager
117
System Configuration
• TLS—See the Security chapter for more information about configuring TLS.
5. allow-anonymous—Define the allow anonymous criteria for accepting and processing a SIP request from another
SIP element.
The anonymous connection mode criteria includes admission control based on whether an endpoint has
successfully registered. Requests from an existing SIP dialog are always accepted and processed. The default is
all.
The following table lists the available options.
•
•
all—All requests from any SIP element are allowed.
agents-only—Only requests from configured session agents are allowed. The session agent must fit one of the
following criteria:
•
•
•
•
•
•
Have a global realm.
Have the same realm as the SIP interface
Be a sub-realm of the SIP interface’s realm.
When an agent that is not configured on the system sends an INVITE to a SIP interface, the Oracle USM:
• Refuses the connection in the case of TCP.
• Responds with a 403 Forbidden in the case of UDP.
realm-prefix—The source IP address of the request must fall within the realm’s address prefix or a SIP
interface sub-realm. A sub-realm is a realm that falls within a realm-group tree. The sub-realm is a child (or
grandchild, and so on) of the SIP interface realm.
Only realms with non-zero address prefixes are considered. Requests from session agents (as described in the
agents-only option) are also allowed.
registered—Only requests from user agents that have an entry in the registration cache (regular or HNT) are
allowed; with the exception of a REGISTER request. A REGISTER request is allowed from any user agent.
The registration cache entry is only added if the REGISTER is successful. Requests from configured session
agents (as described in the agents-only option) are also allowed.
register-prefix—Only requests from user agents that have an entry in the Registration Cache (regular or HNT)
are allowed; with the exception of a REGISTER request. A REGISTER request is allowed only when the
source IP address of the request falls within the realm address-prefix or a SIP interface sub-realm. Only realms
with non-zero address prefixes are considered.
The Registration Cache entry is only added if the REGISTER is successful. Requests from configured session
agents (as described in the agents-only option) are also allowed.
Digest Authentication with SIP
Digest authentication for Session Initiation Protocol (SIP) is a type of security feature on the Oracle USM that
provides a minimum level of security for basic Transport Control Protocol (TCP) and User Datagram Protocol (UDP)
connections. Digest authentication verifies that both parties on a connection (host and endpoint client) know a shared
secret (a password). This verification can be done without sending the password in the clear.
Digest authentication is disabled by default on the Oracle USM. When digest authentication is enabled, the Oracle
USM (host) responds to authentication challenges from SIP trunking Service Providers (endpoint client). The Oracle
USM performs authentication for each IP-PBX initiating the call. However, the authentication challenge process takes
place between the host and the client only since the IP-PBX cannot handle authentication challenges. The following
illustration shows the digest authentication process.
118
Oracle® Communications Unified Session Manager
System Configuration
The digest authentication scheme is based on a simple challenge-response paradigm. A valid response contains a
checksum (by default, the MD5 checksum) of the “username” and password. In this way, the password is never sent
in the clear.
By default, the Oracle USM uses cached credentials for all requests within the same dialog, once the authentication
session is established with a 200OK from the authenticating SIP element. If the in-dialog-methods attribute contains a
value, it specifies the requests that have challenge-responses inserted within a dialog.
In digest authentication with SIP, the following can happen:
•
•
•
More than one authenticating SIP element (IP-PBX) may be the destination of requests.
More than one authentication challenge can occur in a SIP message. This can occur when there are additional
authenticating SIP elements behind the first authenticating SIP element.
The Oracle USM distinguishes whether the IP-PBX is capable of handling the challenge. If Digest Authentication
is disabled (no auth-attributes configured) on the Session Agent, the challenge is passed back to the IP-PBX.
Oracle® Communications Unified Session Manager
119
System Configuration
Note: If there are multiple challenges in the request, and if the Oracle USM has only some of the cached
credentials configured, the Oracle USM adds challenge-responses for the requests it can handle, and does
not pass the challenge back to the IP-PBX.
Challenge-Responses in Requests not in the Dialog
A digest authentication session starts from the client response to a
www-authenticate/proxy-authenticate challenge and lasts until the client receives another challenge in the protection
space defined by the auth-realm. Credentials are not cached across dialogs; however, if a User Agent (UA) is
configured with the auth-realm of its outbound proxy, when one exists, the UA may cache credentials for that authrealm across dialogs.
Note: Existing Oracle USM behavior with surrogate-agents is that they cache credentials from REGISTER
for INVITE sessions only if the Oracle USM is considered a UA sending to its outbound proxy.
Surrogate Agents and the Oracle USM
In the case where a surrogate-agent is configured for the IP-PBX, you do not have to configure digest authentication
attributes in the session-agent object for the same IP-PBX. The surrogate-agent authentication configuration takes
precedence over the session-agent authentication configuration and so it is ignored.
The following illustration shows an example of a surrogate-agent with a session-agent in the network.
Configuring Digest Authentication
In the Oracle USM ACLI, you can access the Digest Authentication object at the path session-router->session-agent>auth-attribute. If enabled, the Digest Authentication process uses the attributes and values listed in this table.
Note: If enabling Digest Authentication, all attributes listed below are required except for the in-dialogmethods attribute which is optional.
The following table lists the digest authentication object
ORACLE(auth-attribute)# show
auth-attribute
auth-realm
username
password
in-dialog-methods
realm01
user
********
ACK INVITE SUBSCRIBE
To configure digest authentication on the Oracle USM:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter to access the session router-related objects.
ORACLE(configure)# session-router
ORACLE(session-router)#
3. Type session-agent and press Enter to access the session agent-related attributes.
ORACLE(session-router)# session-agent
ORACLE(session-agent)#
120
Oracle® Communications Unified Session Manager
System Configuration
4. Type auth-attribute and press Enter to access the digest authentication-related attributes.
ORACLE(session-agent)# auth-attribute
ORACLE(auth-attribute)#
5. auth-realm — Enter the name (realm ID) of the host realm initiating the authentication challenge. This value
defines the protected space in which the digest authentication is performed. Valid value is an alpha-numeric
character string. Default is blank.
ORACLE(auth-attribute)# auth-realm realm01
6. username — Enter the username of the client. Valid value is an alpha-numeric character string. Default is blank.
ORACLE(auth-attribute)# username user
7. password — Enter the password associated with the username of the client. This is required for all LOGIN
attempts. Password displays while typing but is saved in clear-text (i.e., *****). Valid value is an alpha-numeric
character string. Default is blank.
ORACLE(auth-attribute)# password *******
8. in-dialog-methods — Enter the in-dialog request method(s) that digest authentication uses from the cached
credentials. Specify request methods in a list form separated by a space enclosed in parentheses. Valid values are:
•
INVITE | BYE | ACK | CANCEL | OPTIONS | SUBSCRIBE | PRACK | NOTIFY | UPDATE | REFER
ORACLE(auth-attribute)# in-dialog-methods (ack invite subscribe)
Note: The methods not in this list are still resubmitted if a 401/407 response is received by the Oracle
USM.
If you do not specify any in-dialog-method value(s), digest authentication does not add challenge-responses to indialog requests within a dialog.
This attribute setting applies to in-dialog requests only.
Additional Notes
The following are additional notes that describe the digest authentication process:
•
•
•
The Oracle USM always challenges the first LOGIN request, and initial authentication begins with that request.
The recalculated authorization key — the credentials — are then included in every subsequent request.
If the Oracle USM does not receive any communication from the client within the expiration period, the Oracle
USM logs the client out and tears down the transport connection. Faced with interface loss, the Oracle USM
default behavior is to flush all warrant information from the target database. This response necessitates that the
client first login/re-register with the Oracle USM, and then repopulate the empty database using a series of ADD
requests. This behavior ensures that client and Oracle USM target databases are synchronized.
Alternatively, when faced with interface loss, the Oracle USM can retain all warrant information within the target
database. This response necessitates only that the client first login/re-register with the Oracle USM. After
successful registration the client should, but is not required to, use a series of GET, ADD, and DELETE requests
to ensure that the Oracle USM and client target databases are synchronized.
The Oracle USM ignores the Authentication-Info header that comes in the 200OK response after digest
authentication is complete. The Oracle USM receives a 401/407 response from the client. However, some
surrogate-agents may process the Authentication-Info header in a single challenge.
Digest Authentication and High Availability
The Oracle USM supports digest authentication in high availability (HA) environments. The session-agent
configuration, which includes the digest authentication parameters on the primary Oracle USM, are replicated on the
HA Oracle USM. However, cached credentials on the primary device are not replicated on the HA device.
Oracle® Communications Unified Session Manager
121
System Configuration
IP Identification (ID) Field
By default, non-fragmented UDP packets generated by media interfaces have the ID field set to 0. You can configure
the Oracle USM to populate this field with an incrementing value by adding the increment-ip-id option in the media
manager. Every non-fragmented packet sent will have its ID increased by one from the previous packet sent.
Using a packet trace application, egress packets from the Oracle USM will have an ID field that appears to be
incrementing. Enabling the ID field can help distinguish a retransmitted non-fragmented application layer packet from
a packet retransmitted by the network layer in monitoring or lab situations.
IP Identification Field Configuration
To enable ID field generation in media-manager:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
2. Type media-manager and press Enter.
ORACLE(configure)# media-manager
ORACLE(media-manager)#
3. options—Set the options parameter by typing options, a Space, the option name increment-ip-id with a plus sign
in front of it, and then press Enter.
ORACLE(media-manager)# options + increment-ip-id
If you type the option without the plus sign, you will overwrite any previously configured options. In order to
append the new options to the realm configuration’s options list, you must prepend the new option with a plus sign
as shown in the previous example.
4. Save and activate your configuration.
SNMP
This section explains how to configure Simple Network Management Protocol (SNMP), trap receivers, and syslog
servers. These features are not essential for baseline Oracle USM service, but they are necessary to use network
management systems to manage the Oracle USM. They provide important monitoring and system health information
that contribute to a robust deployment of the system.
Overview
SNMP is used to support monitoring of network-attached devices for conditions that warrant administrative attention.
SNMP is comprised of three groups of settings on a Oracle USM. These settings are system-wide configurations
including MIB contact information, SNMP community settings, and trap receivers.
Basic SNMP Parameters
The Oracle USM includes several parameters that control basic SNMP functionality. The MIB-related elements are
for informational purposes, and are helpful if set. The remainder of the parameters determines if certain Oracle USM
events are reported to the SNMP system.
SNMP Community
An SNMP community is a grouping of network devices and management stations used to define where information is
sent and accepted. An SNMP device or agent might belong to more than one SNMP community. SNMP communities
provide a type of password protection for viewing and setting management information within a community.
SNMP communities also include access level settings. They are used to define the access rights associated with a
specific SNMP community. The Oracle USM lets you define two types of access levels: read-only and read-write.
122
Oracle® Communications Unified Session Manager
System Configuration
You can define multiple SNMP communities on a Oracle USM to segregate access modes per community and NMS
host.
SNMP Trap Receiver Uses
A trap receiver is an application used to receive, log, and view SNMP traps for monitoring the Oracle USM (USM).
An SNMP trap is the notification sent from a network device, such as the USM, that declares a change in service.
Multiple trap receivers can be defined on an USM for either redundancy or to segregate alarms with different severity
levels to individual trap receivers.
Each Oracle Communications Session Delivery Manager which manages Oracle USMs should be configured on those
SBCs as trap receivers.
Configuring SNMP
This section describes how to configure your Oracle USM to work with external SNMP systems. Sample
configurations are also provided.
SNMP Configuration Overview
1. Configure the SNMP identification information. This step includes configuring the MIB system contact, name,
and location parameters.
2. Set the general SNMP parameters to enable or disable SNMP on the Oracle USM. This step includes setting the
switches that govern how the SNMP system responds to specified events.
3. Set the syslog events. This step includes setting the parameters for handling SNMP monitoring syslog events,
which can trigger SNMP syslog traps.
4. Set SNMP communities. Configuration is separated into a unique configuration element.
5. Set trap receivers. Configuration is separated into a unique configuration element.
SNMP Configuration
To configure SNMP:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type system and press Enter to access the system-level configuration elements.
ORACLE(configure)# system
3. Type system-config and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(system)# system-config
ORACLE(system-config)#
From this point, you can set SNMP parameters. The following is an example what an SNMP configuration might
look like. Parameters not described in this section are omitted below.
system-config
mib-system-contact
mib-system-name
mib-system-location
snmp-enabled
enable-snmp-auth-traps
enable-snmp-syslog-notify
enable-snmp-monitor-traps
enable-env-monitor-traps
snmp-syslog-his-table-length
snmp-syslog-level
Oracle® Communications Unified Session Manager
John Doe
Test System
Upstairs
enabled
disabled
disabled
disabled
disabled
1
WARNING
123
System Configuration
System Wide Configuration for SNMP
This section describes the system-wide SNMP parameters found in the System Configuration element. These
parameters set global SNMP information.
Set the following parameters to configure system wide SNMP functionality:
1. mib-system-contact—Set the contact information used within the system’s MIB transactions. The SNMP agent
sends this information to an NMS in response to an SNMP Get for the MIB-II sysContact MIB variable. This
parameter’s value can be a textual identification of your company’s contact person for the system and information
about how to contact that person.
2. mib-system-name—Set the identification of this Oracle USM presented within MIB transactions. This value,
along with the target name of the system (identified in the boot parameters) are the values reported for MIB-II
when an SNMP GET is issued by the NMS for the MIB-II sysName variable. This parameter has no direct relation
to the hostname parameter in the system configuration element.
By convention, this is the node’s FQDN. For SNMP MIB-II sysName GETs, the system returns SNMP
communications in the following format: <targetName>[.<mib-system-name>]
targetName is the value configured in the target name (tn) boot parameter and mib-system-name is the value
configured in this field.
3. mib-system-location—Set the physical location of this Oracle USM that is reported within MIB transactions.
This parameter is reported when an SNMP GET is issued by the NMS for the MIB-II sysLocation variable. This
parameter has no direct relation to the location field in the system configuration element.
4. snmp-enabled—Set the SNMP system on this Oracle USM to enabled or disabled. By default, this parameter is
set to enabled. The valid values are:
• enabled | disabled
5. enable-snmp-syslog-notify—Set whether SNMP traps are sent when the system generates an alarm message. The
SNMP agent sends a trap when an alarm is generated if the following conditions are met:
•
•
•
SNMP is enabled.
This field is enabled.
The syslog severity level is equal to or greater than the severity level configured in the SNMP Syslog Level
field.
The default is disabled. Valid values are:
• enabled | disabled
6. enable-snmp-monitor-traps—When this parameter is enabled, the Oracle USM generates traps with unique trapIDs for each syslog event. If this parameter is disabled , a single trap-ID is used for all events, with different
values in the description string. The default is disabled. The valid values are:
• enabled | disabled
7. enable-snmp-auth-traps—Set whether the SNMP authentication traps are enabled. If an SNMP request fails
authentication because of an IPv4 address and SNMP community mismatch, the SNMP request will be rejected.
This field determines if an SNMP trap will be sent in response to the authentication failure. The default is
disabled. Valid values for this parameter are:
• enabled | disabled
8. enable-env-monitor-traps—Set whether or not the SNMP environment monitor traps are enabled. Environment
traps include main board PROM temperature, CPU voltage, power supplies, fan speeds, etc. The default is
disabled. Valid values for this parameter are:
• enabled | disabled
9. snmp-syslog-his-table-length—Set the length of the syslog trap history table. When a syslog message that meets
the SNMP syslog level field criteria is generated and SNMP is enabled, the SNMP agent adds that message to a
history table. This parameter indicates the number of entries the table can contain. The default is 1. The valid
range is:
•
124
Minimum—1
Oracle® Communications Unified Session Manager
System Configuration
•
Maximum—500
Once the last table entry is filled, the oldest entry will be overwritten with a new entry.
10. snmp-syslog-level—Set the log severity level threshold that will cause the syslog trap to be sent to an NMS.
When this criteria is met and the appropriate SNMP trap is sent, an entry is written to the SNMP Syslog History
Table. The default is warning. The following are valid values:
•
emergency | critical | major | minor | warning | notice | info | trace | debug | detail
SNMP Community Configuration
To configure SNMP communities:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type system and press Enter to access the system-level configuration elements.
ORACLE(configure)# system
3. Type snmp-community and press Enter. The system prompt changes to let you know that you can begin
configuring individual parameters.
ORACLE(system)# snmp-community
ORACLE(snmp-community)#
From this point, you can set SNMP community parameters.
The following is an example what an SNMP Community configuration might look like. Parameters not described
in this section are omitted below.
snmp-community
community-name
access-mode
ip-addresses
public
READ-ONLY
10.0.1.42
4. community-name—Set the SNMP community name of an active community where this Oracle USM can send or
receive SNMP information. A community name value can also be used as a password to provide authentication,
thereby limiting the NMSs that have access to this system. With this field, the SNMP agent provides trivial
authentication based on the community name that is exchanged in plain text SNMP messages.
5. access-mode—Set the access level for all NMSs defined within this SNMP community. The access level
determines the permissions that other NMS hosts can wield over this Oracle USM. The default is read-only. The
valid values are:
• read-only—allows GET requests.
• read-write—allows both GET and SET requests.
6. ip-addresses—Set one or multiple IPv4 addresses that are valid within this SNMP community. These IPv4
addresses correspond with the IPv4 address of NMS applications that monitor or configure this Oracle USM.
Include the IPv4 addresses of all servers where Element Management System is installed.
Trap Receiver Configuration
To configure trap receivers:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type system and press Enter to access the system-level configuration elements.
ORACLE(configure)# system
3. Type trap-receiver and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(system)# trap-receiver
ORACLE(trap-receiver)#
Oracle® Communications Unified Session Manager
125
System Configuration
From this point, you can set trap receivers.
The following is an example what a trap receiver configuration might look like. Parameters not described in this
section are omitted below.
trap-receiver
ip-address
filter-level
community-name
10.0.1.42:162
All
public
4. ip-address—Set the IPv4 address of an authorized NMS. This parameter is the IPv4 address of an NMS where
traps are sent. If you do not specify a port number, the default SNMP trap port of 162 will be used.
5. filter-level—Set the filter level threshold that indicates the severity level at which a trap to be sent to this
particular trap receiver. The default for this parameter is critical.
Example: A trap with a severity level of Critical is generated, the SNMP agent will only send this trap to NMSs
that are configured in a trap-receiver element and have a filter-level parameter of Critical.
The following table maps Syslog and SNMP alarms to trap receiver filter levels.
Filter Level
Syslog Severity Level
(SNMP) Alarm Severity Level
Critical
Emergency (1)
Emergency
Critical (2)
Critical
Emergency (1)
Emergency
Critical (2)
Critical
Major (3)
Major
Emergency (1)
Emergency
Critical (2)
Critical
Major (3)
Major
Minor (4)
Minor
Emergency (1)
Emergency
Critical (2)
Critical
Major (3)
Major
Minor (4)
Minor
Warning (5)
Warning
Major
Minor
All
Notice (6)
Info (7)
Trace (8)
Debug (9)
When configuring the trap-receiver element for use with Net-Net EMS systems, Acme Packet recommends that
the filter-level parameter be set to All for that configuration element that includes Net-Net EMS servers.
6. community-name—Set the community name to which this trap receiver belongs. This community must be defined
in the SNMP community element.
126
Oracle® Communications Unified Session Manager
System Configuration
Media Supervision Traps
The Oracle USM, when functioning as a border gateway, will send the following trap when the media supervision
timer has expired. This behavior is disabled by default, but can be enabled by changing the media-supervision-traps
parameter to enabled in the media-manager configuration element.
apSysMgmtMediaSupervisionTimerExpTrap
NOTIFICATION-TYPE
OBJECTS
{ apSysMgmtCallId }
STATUS
current
DESCRIPTION
" The trap will be generated when a media supervision timer
has expired. This behavior is disabled by default but may
be enabled by changing the 'media-supervision-traps'
parameter of the 'media-manager' configuration element. The
included object is the call identifer for the call which had
the timer expire."
::= { apSystemManagementMonitors 34 }
The system does not send this trap when functioning as an integrated Oracle USM.
Syslog and Process Logs
Logging events is a critical part of diagnosing misconfigurations and optimizing operations. Oracle USMs can send
both syslog and process log data to appropriate hosts for storage and analysis.
Overview
The Oracle USM generates two types of logs, syslogs and process logs. Syslogs conform to the standard used for
logging servers and processes as defined in RFC 3164.
Process logs are Oracle proprietary logs. Process logs are generated on a per-task basis and are used mainly for
debugging purposes. Because process logs are more data inclusive than syslogs, their contents usually encompass
syslog log data.
Syslog and process log servers are both identified by an IPv4 address and port pair.
Process Log Messages
Process log messages are sent as UDP packets in the following format:
<file-name>:<log-message>
In this format, <filename> indicates the log filename and <log-message> indicates the full text of the log message as
it would appear if it were written to the normal log file.
Syslog and Process Logs Configuration
This section describes how to configure syslog and process log servers.
To configure syslogs and process logs:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type system and press Enter to access the system-level configuration elements.
ORACLE(configure)# system
3. Type system-config and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(system)# system-config
ORACLE(system-config)#
Oracle® Communications Unified Session Manager
127
System Configuration
From this point, you can set process log parameters. Skip to the following process log configuration section.
4. Type syslog-server and press Enter. The system prompt changes to let you know that you can begin configuring
individual syslog parameters
ORACLE(system-config)# syslog-server
ORACLE(syslog-server)#
From this point, you can set syslog parameters. The following is an example what an syslog and process log
configuration might look like. Parameters not described in this section are omitted below.
system-log-level
syslog-server
address
port
facility
process-log-level
process-log-ip-address
process-log-port
WARNING
NOTICE
0.0.0.0
0
172.15.44.12
514
4
Syslog Configuration
The Oracle USM supports multiple syslog servers. As the number of active syslog increases, the performance level of
the Oracle USM may decrease. Therefore, we recommend configuring no more than 8 syslog servers.
Set the following parameters to configure syslog servers:
1. address—Set the IPv4 address of a syslog server.
2. port—Set the port portion of the syslog server. The default is 514.
3. facility—Set an integer to identify a user-defined facility value sent in every syslog message from the Oracle USM
to the syslog server. This parameter is used only for identifying the source of this syslog message as coming from
the Oracle USM. It is not identifying an OS daemon or process. The default value for this parameter is 4. RFC
3164 specifies valid facility values.
In software release versions prior to Release 1.2, the Oracle USM would send all syslog messages with a facility
marker of 4.
4. system-log-level—Set which log severity levels write to the system log (filename: acmelog). The default is
WARNING. Valid values are:
•
EMERGENCY | CRITICAL | MAJOR | MINOR | WARNING | NOTICE | INFO | TRACE | DEBUG |
DETAIL
Process Log Configuration
Set the following parameters to configure the process log server:
1. process-log-level—Set the starting log level all processes running on the system use. Each individual process
running on the system has its own process log. The default is NOTICE. Valid values are:
•
EMERGENCY | CRITICAL | MAJOR | MINOR | WARNING | NOTICE | INFO | TRACE | DEBUG |
DETAIL
2. process-log-ip-address—Set the IPv4 address of the process log server. The default 0.0.0.0, which causes log
messages to be written to the normal log file.
3. process-log-port—Set the port number associated with the process log server. The default value for this parameter
is 0, which causes log messages to be written to the normal log file. The valid range is:
•
•
128
Minimum—0
Maximum—65535.
Oracle® Communications Unified Session Manager
System Configuration
Host Routes
Host routes let you insert entries into the Oracle USM's routing table. These routes affect traffic that originates at the
Oracle USM’s host process. Host routes are used primarily for steering management traffic to the correct network.
When traffic is destined for a network that is not explicitly defined on a Oracle USM, the default gateway (located in
the system config) is used. If you try to route traffic to a specific destination that is not accessible through the default
gateway, you need to add a host route. Host routes can be thought of as a default gateway override.
Certain SIP configurations require that the default gateway is located on a media interface. In this scenario, if
management applications are located on a network connected to an administrative network, you will need to add a
host route for management connectivity.
When source-based routing is used, the default gateway must exist on a media interface. Host routes might be needed
to reach management applications connected to a management port in this kind of situation as well.
Host Routes Example
Because SIP signaling over media interfaces is enabled, the default gateway uses an IPv4 address assigned to a media
interface. Maintenance services (SNMP and Radius) are located on a network connected to, but separate from, the
192.168.1.0/24 network on wancom0. In order to route Radius or SNMP traffic to an NMS (labeled as SNMP in the
following example), a host route entry must be a part of the Oracle USM configuration. The host route tells the host
how to reach the 172.16.0.0/16 network. The actual configuration is shown in the example in the next section of this
guide.
Host Route Configuration
To configure a host route:
1. Access the host-route configuration element.
ORACLE# configure terminal
ORACLE(configure)# system
ORACLE(system)# host-route
ORACLE(host-route)#
2. dest-network—Set the IP address of the destination network that this host route points toward.
3. netmask—Set the netmask portion of the destination network for the route you are creating. The netmask is in
dotted decimal notation.
4. gateway—Set the gateway that traffic destined for the address defined in the first two elements should use as its
first hop.
5. Type done to save your configuration.
Oracle® Communications Unified Session Manager
129
System Configuration
Source-based Routing
The source based routing (source routing) feature is used to route packets based on their source address, and not on
the system’s routing table. This feature is only used for management applications within the Oracle USM that utilitze
HIP interfaces.
Note: This feature only affects media-network interfaces.
Note: The bootparam flag (0x80008) does not work in C-Series 5.x and D-Series 5.x and up. You must use
the system-config source-routing parameter.
Source-based Routing Configuration
To configure source-based routing in the system-config:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type system and press Enter.
ORACLE(configure)# system
ORACLE(system)#
3. Type system-config and press Enter.
ORACLE(system)# system-config
ORACLE(system-config)#
The system prompt changes to let you know that you can begin configuring individual parameters.
4. source-routing—Set this parameter to enabled to use source-based routing.
5. Save and activate your configuration.
Note: The source-routing parameter is not RTC-supported. You must reboot after enabling it.
Setting Holidays in Local Policy
This section explains how to configure holidays on the Oracle USM.
You can define holidays that the Oracle USM recognizes. Holidays are used to identify a class of days on which a
local policy is enacted. All configured holidays are referenced in the local-policy-attributes configuration subelement
as an H in the days-of-week parameter. Because holidays are entered on a one-time basis per year, you must configure
a new set of holidays yearly.
Holidays Configuration
To configure holidays:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter to access the system-level configuration elements.
ORACLE(configure)# session-router
3. Type session-router-config and press Enter. The system prompt changes to let you know that you can begin
configuring individual parameters.
ORACLE(session-router)# session-router-config
ORACLE(session-router-config)#
4. Type holidays and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
130
Oracle® Communications Unified Session Manager
System Configuration
ORACLE(session-router-config)# holidays
ORACLE(session-router-holidays)#
From this point, you can configure the holidays subelement. To view all holidays parameters, enter a ? at the
system prompt.
holiday
date
description
2005-01-01
New Years Day
To configure a holiday, add an entry for the following parameters in the holidays element:
5. date—Enter the holiday’s date in YYYY-MM-DD format.
6. description—Enter a short description for the holiday you are configuring. If the description contains words
separated by spaces, enter the full description surrounded by quotation marks.
Enhanced Control of UDP and TCP Ports
This section explains how to configure the Oracle USM for finer control of the set of UDP and TCP ports that on
which the Oracle USM provides services. The settings you can configure have an impact on:
•
•
UDP/TCP port 111 (the RPC services port), which is disabled on Oracle USM startup but can be enabled in the
boot parameters
TCP ports 3000 (used when notify commands are issued remotely, i.e. via an element management system) and
3001 (used for remote configuration, i.e. via an element management system), which can now be enabled or
disabled in the system configuration
Neither configuration for these features is covered by RTC, so you must reboot your Oracle USM for changes to take
effect. Be aware that rebooting can cause system downtime, and plan accordingly.
Port 111 Configuration
To enable port 111 using Oracle USM boot parameters:
1. In Superuser mode, type configure terminal and press Enter
ORACLE# configure terminal
2. To enter the boot parameters so that you can configure them, type bootparam and press Enter.
ORACLE(configure)# bootparam
3. Press Enter to scroll through the list of boot parameters until you reach the setting for flags.
To set this value correctly, you need to add the value 0x200000 to your existing flag setting in the boot parameters.
In the example below, the existing flag value is 0x30008. When the value 0x200000 is added, the result is
0x230008. The result is the value that you need to set.
When you reach the flag setting, type the value representing the flags you need (0x230008 in the example below)
and press Enter. Continue to press Enter to finish scrolling through the rest of the boot parameters.
'.' = clear field; '-' = go to previous field;
boot device
: wancom0
processor number
: 0
host name
: acmepacket8
file name
: /tffs0/sd220p9.gz
inet on ethernet (e)
: 10.0.1.57:ffff0000
inet on backplane (b)
: 0.0.0.0
host inet (h)
: 10.0.1.5
gateway inet (g)
: 10.0.0.1
user (u)
: user
ftp password (pw)
: password
flags (f)
: 0x30008 0x230008
target name (tn)
: acmesystem
startup script (s)
: 0
Oracle® Communications Unified Session Manager
^D = quit
131
System Configuration
other (o)
:
NOTE: These changed parameters will not go into effect until reboot. Also,
be aware that some boot parameters may also be changed through the PHY and
Network Interface Configurations.
ORACLE(configure)#
4. Type exit to return to the main Superuser menu so that you can reboot your Oracle USM and apply the settings
you have entered.
ORACLE(configure)# exit
5. Reboot your Oracle USM. Type a y and press Enter to reboot.
ORACLE# reboot
----------------------------------------WARNING: you are about to reboot this SD!
----------------------------------------Reboot this SD [y/n]?:y
Port 3000 and 3001 Configuration
To control TCP ports 3000 and 3001 in the system configuration:
1. Access the security-config configuration element.
ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# security-config
ORACLE(security-config)#
2. Type select to begin editing the system-config object.
ORACLE(system-config)# select
ACMEPACKET(system-config)#
3. The parameter controlling ports 3000 and 3001 is called remote-control, and its default is enabled. To disable the
ports, set this parameter to disabled.
ORACLE(system-config)# remote-control disabled
4. Type done to save your configuration.
5. Reboot your Oracle USM. Type a y and press Enter to reboot.
ORACLE# reboot
----------------------------------------WARNING: you are about to reboot this SD!
----------------------------------------Reboot this SD [y/n]?:y
DNS Transaction Timeout
This section explains how to configure the DNS transaction timeout interval on a per network-interface basis. You can
currently configure the Oracle USM with a primary and two optional backup DNS servers. The Oracle USM queries
the primary DNS server and upon not receiving a response within the configured number of seconds, queries the
backup1 DNS server and if that times out as well, then contacts the backup2 DNS server.
Retransmission Logic
The retransmission of DNS queries is controlled by three timers. These timers are derived from the configured DNS
timeout value and from underlying logic that the minimum allowed retransmission interval should be 250
milliseconds; and that the Oracle USM should retransmit 3 times before timing out to give the server a chance to
respond.
•
132
Init-timer is the initial retransmission interval. If a response to a query is not received within this interval, the
query is retransmitted. To safeguard from performance degradation, the minimum value allowed for this timer is
250 milliseconds.
Oracle® Communications Unified Session Manager
System Configuration
•
•
Max-timer is the maximum retransmission interval. The interval is doubled after every retransmission. If the
resulting retransmission interval is greater than the value of max-timer, it is set to the max-timer value.
Expire-timer: is the query expiration timer. If a response is not received for a query and its retransmissions within
this interval, the server will be considered non-responsive and the next server in the list will be tried.
The following examples show different timeout values and the corresponding timers derived from them.
timeout >= 3 seconds
Init-timer = Timeout/11
Max-Timer = 4 * Init-timer
Expire-Timer = Timeout
timeout = 1 second
Init-Timer = 250 ms
Max-Timer = 250 ms
Expire-Timer = 1 sec
timeout = 2 seconds
Init-Timer = 250 ms
Max-Timer = 650 ms
Expire-Timer = 2sec
DNS Transaction Timeout Configuration
To configure DNS transaction timeout:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type system and press Enter to access the system-level configuration elements.
ORACLE(configure)# system
3. Type network-interface and press Enter. The system prompt changes to let you know that you can begin
configuring individual parameters.
ORACLE(system)# network-interface
ORACLE(network-interface)#
From this point, you can configure network interface parameters. To view all network interface parameters, enter
a ? at the system prompt.
4. dns-timeout—Enter the total time in seconds you want to elapse before a query (and its retransmissions) sent to a
DNS server would timeout. The default is 11 seconds. The valid range is:
•
•
Minimum—1
Maximum—999999999.
If a query sent to the primary DNS server times out, the backup1 DNS server is queried. If the query times out
after the same period of time elapses, the query continues on to the backup2 DNS server.
5. Save and activate your configuration.
DNS Server Status via SNMP
The Oracle USM monitors the status of all configured DNS servers used by a SIP daemon. If a DNS server goes
down, a major alarm is sent. If all DNS servers used by a SIP daemon are down, a critical alarm is sent. The
apAppsDnsServerStatusChangeTrap is sent for both events.
You can poll the status of a DNS server using the apAppsDNSServerStatusTable in the ap-apps.mib.
Once the apAppsDnsServerStatusChangeTrap has been sent, a 30 second window elapses until the server status is
checked again. At the 30 second timer expiration, if the server is still down, another trap and alarm are sent. If the
server has been restored to service, the apAppsDnsServerStatusChangeClearTrap is sent.
Oracle® Communications Unified Session Manager
133
System Configuration
Persistent Protocol Tracing
This section explains how to configure persistent protocol tracing to capture specific SIP and MGCP protocol
message logs and persistently send them off the Oracle USM, even after rebooting the system.
About Persistent Protocol Tracing
You can configure sending protocol message logs off of the Oracle USM, and have that persist after a reboot. You no
longer have to manually issue the notify command each time you reboot.
To support persistent protocol tracing, you configure the following system-config parameters:
•
•
•
call-trace—Enable/disable protocol message tracing (currently only sipmsg.log and alg.log) regardless of the
process-log-level setting. If the process-log-level is set to trace or debug, call-trace will not disable.
internal-trace—Enable/disable internal ACP message tracing for all processes, regardless of process-log-level
setting. This applies to all *.log (internal ACP message exchange) files other than sipmsg.log and alg.log. If the
process-log-level is set to trace or debug, call-trace will not disable.
log-filter—Determine what combination of protocol traces and logs are sent to the log server defined by the
process-log-ip parameter value. You can also fork the traces and logs, meaning that you keep trace and log
information in local storage as well as sending it to the server. You can set this parameter to any of the following
values: none, traces, traces-fork, logs, logs, all, or all-fork.
The Oracle USM uses the value of this parameter in conjunction with the process-log-ip and process-log-port
values to determine what information to send. If you have configured the proc-log-ip and proc-log-port
parameters, choosing traces sends just the trace information (provided they are turned on), logs sends only process
logs (log.*), and all sends everything (which is the default).
About the Logs
When you configure persistent protocol tracing, you affect the following types of logs.
Note: Enabling logs can have an impact on Oracle USM performance.
Process Logs
Events are logged to a process log flow from tasks and are specific to a single process running on the Oracle USM.
By default they are placed into individual files associated with each process with the following name format:
log.<taskname>
By setting the new log-filter parameter, you can have the logs sent to a remote log server (if configured). If you set
log-filter to logs or all, the logs are sent to the log server. Otherwise, the logs are still captured at the level the processlog-level parameter is set to, but the results are stored on the Oracle USM’s local storage.
Communication Logs
These are the communication logs between processes and system management. The logs are usually named
<name>.log, with <name> being the process name. For example, sipd.log.
This class of log is configured by the new internal-trace parameter.
Protocol Trace Logs
The only protocol trace logs included at this time are sipmsg.log for SIP and alg.log for MGCP. All of the logs
enabled with the call–trace parameter are sent to remote log servers, if you also set the log-filter parameter to logs or
all.
134
Oracle® Communications Unified Session Manager
System Configuration
Persistent Protocol Tracing Configuration
Before you configure persistent protocol tracing, ensure you have configured the process logs by setting the system
configuration’s process-log-ip parameter.
To configure persistent protocol tracing:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type system and press Enter to access the system-level configuration elements.
ORACLE(configure)# system
3. Type system-config and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(system)# system-config
ORACLE(system-config)#
4. call-trace—Set to enabled to enable protocol message tracing for sipmsg.log for SIP and alg.log for MGCP. The
default is disabled. The valid values are:
• enabled | disabled
5. internal-trace—Set to enabled to enable internal ACP message tracing for all processes. The default is disabled.
The valid values are:
• enabled | disabled
6. log-filter—Choose the appropriate setting for how you want to send and/or store trace information and process
logs. The valid values are:
•
•
none—No information will be sent or stored.
traces—Sends the trace information to both the log server; includes <name>.log files that contain information
about the Oracle USM’s internal communication processes (<name> is the name of the internal process)
• traces-fork—Sends the trace information to both the log server and also keeps it in local storage; includes
<name>.log files that contain information about the Oracle USM’s internal communication processes (<name>
is the name of the internal process)
• logs—Sends the process logs to both the log server; includes log.* files, which are Oracle USM process logs
• logs-fork—Sends the process logs to both the log server and also keeps it in local storage; includes log.* files,
which are Oracle USM process logs
• all—Sends all logs to the log servers that you configure
• all-fork—Sends all logs to the log servers that you configure, and it also keeps the logs in local storage
7. Save and activate your configuration.
System Access Control
You can configure a system access control list (ACL) for your Oracle USM that determines what traffic the Oracle
USM allows over its management interface (wancom0). By specifying who has access to the Oracle USM via the
management interface, you can provide DoS protection for this interface.
Using a list of IP addresses and subnets that are allowable as packet sources, you can configure what traffic the Oracle
USM accepts and what it denies. All IP packets arriving on the management interface are subject; if it does not match
your configuration for system ACL, then the Oracle USM drops it.
Note: All IP addresses configured in the SNMP community table are automatically permitted.
Oracle® Communications Unified Session Manager
135
System Configuration
Adding an ACL for the Management Interface
The new subconfiguration system-access-list is now part of the system configuration, and its model is similar to host
routes. For each entry, you must define an IP destination address and mask; you can specify either the individual host
or a unique subnet.
If you do not configure this list, then there will be no ACL/DoS protection for the Oracle USM’s management
interface.
You access the system-access-list via system path, where you set an IP address and netmask. You can configure
multiple system ACLs using this configuration.
To add an ACL for the management interface:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type system and press Enter to access the signaling-level configuration elements.
ORACLE(configure)# system
ORACLE(system)#
3. Type system-access-list and press Enter.
ORACLE(system)# system-access-list
ORACLE(system-access-list)#
4. source-address—Enter the IP address representing for the source network for which you want to allow traffic over
the management interface.
5. netmask—Enter the netmask portion of the source network for the traffic you want to allow. The netmask is in
dotted decimal notation.
Notes on Deleting System ACLs
If you delete a system ACL from your configuration, the Oracle USM checks whether or not there are any active FTP
or Telnet client was granted access when the entry was being removed. If such a client were active during ACL
removal, the Oracle USM would warn you about the condition and ask you to confirm the deletion. If you confirm the
deletion, then the Oracle USM’s session with the active client is suspended.
The following example shows you how the warning message and confirmation appear. For this example, and ACLI
has been deleted, and the user is activating the configuration that reflects the change.
ORACLE # activate-config
Object deleted will cause service disruption:
system-access-list: identifier=172.30.0.24
** WARNING: Removal of this system-ACL entry will result
in the lockout of a current FTP client
Changes could affect service, continue (y/n) y
Activate-Config received, processing.
System TCP Keepalive Settings
You can configure the Oracle USM to control TCP connections by setting:
•
•
The amount of time the TCP connection is idle before the Oracle USM starts sending keepalive messages to the
remote peer
The number of keepalive packets the Oracle USM sends before terminating the TCP connection
If TCP keepalive fails, then the Oracle USM will drop the call associated with that TCP connection.
In the ALCI, a configured set of network parameters appears as follows:
network-parameters
tcp-keepinit-timer
tcp-keepalive-count
136
75
4
Oracle® Communications Unified Session Manager
System Configuration
tcp-keepalive-idle-timer
tcp-keepalive-interval-timer
tcp-keepalive-mode
400
75
0
Then you apply these on a per-interface basis.
System TCP Keepalive Configuration
TCP setting are global, and then enabled or disabled on a per-interface basis.
To configure TCP keepalive parameters on your Oracle USM:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type system and press Enter to access the system-related configurations.
ORACLE(configure)# system
3. Type network-parameters and press Enter. The system prompt changes to let you know that you can begin
configuring individual parameters.
ORACLE(system)# network-parameters
ORACLE(network-parameters)#
4. tcp-keepinit-timer—If a TCP connection cannot be established within some amount of time, TCP will time out the
connect attempt. It can be used to set the initial timeout period for a given socket, and specifies the number of
seconds to wait before the connect attempt is timed out. For passive connections, this value is inherited from the
listening socket. The default is 75. The valid range is:
• Minimum—0
• Maximum—999999999.
5. tcp-keepalive-count—Enter the number of packets the Oracle USM sends to the remote peer before it terminates
the TCP connection. The default is 8. The valid range is:
• Minimum—0
• Maximum—223-1
6. tcp-keepalive-idle-timer—Enter the number of seconds of idle time before TCP keepalive messages are sent to the
remote peer if the SO-KEEPALIVE option is set. The default is 7200. The valid range is:
• Minimum—30
• Maximum—7200
7. tcp-keepalive-interval-timer—When the SO_KEEPALIVE option is enabled, TCP probes a connection that has
been idle for some amount of time. If the remote system does not respond to a keepalive probe, TCP retransmits
the probe after a set amount of time. This parameter specifies the number of seconds to wait before retransmitting
a keepalive probe. The default value is 75 seconds. The valid range is:
• Minimum—15
• Maximum—75
8. tcp-keepalive-mode—Set the TCP keepalive response sequence number. The default is 0. The valid values are:
•
•
•
0—The sequence number is sent un-incremented
1—The number is incremented
2—No packets are sent
Configurable TCP Timers
You can configure your Oracle USM to detect failed TCP connections more quickly so that data can be transmitted
via an alternate connection before timers expire. Across all protocols, you can now control the following for TCP:
•
•
Connection establishment
Data retransmission
Oracle® Communications Unified Session Manager
137
System Configuration
•
Timer for idle connections
These capabilities all involve configuring an options parameter that appears in the network parameters configuration.
Configuring TCP Connection Establishment
To establish connections, TCP uses a three-way handshake during which two peers exchange TCP SYN messages to
request and confirm the active open connection. In attempting this connection, one peer retransmits the SYN
messages for a defined period of time if it does not receive acknowledgement from the terminating peer. You can
configure the amount of time in seconds between the retries as well as how long (in seconds) the peer will keep
retransmitting the messages.
You set two new options in the network parameters configuration to specify these amounts of time: atcp-syn-rxmtinterval and atcp-syn-rxmt-maxtime.
Note that for all configured options, any values entered outside of the valid range are silently ignored during
configuration and generate a log when you enter the activate command.
To configure TCP connection establishment:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type system and press Enter.
ORACLE(configure)# system
ORACLE(system)#
3. Type network-parameters and press Enter.
ORACLE(system)# network-parameters
ORACLE(network-parameters)#
4. options—Set the options parameter by typing options, a Space, the option name atcp-syn-rxmt-interval=x (where
x is a value in seconds between 2 and 10) with a plus sign in front of it. Then press Enter. This value will be used
as the interval between TCP SYN messages when the Oracle USM is trying to establish a connection with a
remote peer.
Now enter a second option to set the maximum time for trying to establish a TCP connection. Set the options
parameter by typing options, a Space, the option name atcp-syn-rxmt-maxtime=x (where x is a value in seconds
between 5 and 75) with a plus sign in front of it. Then press Enter.
ORACLE(network-parameters)# options +atcp-syn-rxmt-interval=5
ORACLE(network-parameters)# options +atcp-syn-rxmt-maxtime=30
If you type the option without the plus sign, you will overwrite any previously configured options. In order to
append the new options to the configuration’s options list, you must prepend the new option with a plus sign as
shown in the previous example.
Note: atcp-syn-rxmt-maxtime=x option is equivalent to the tcp-keepinit-timer parameter, but only affects
ATCP.
5. Save and activate your configuration.
Configuring TCP Data Retransmission
TCP is considered reliable in part because it requires that entities receiving data must acknowledge transmitted
segments. If data segments go unacknowledged, then they are retransmitted until they are finally acknowledged or
until the maximum number of retries has been reached. You can control both the number of times the Oracle USM
tries to retransmit unacknowledged segments and the periodic interval (how often) at which retransmissions occur.
You set two new options in the network parameters configuration to specify how many retransmissions are allowed
and for how long: atcp-rxmt-interval and atcp-rxmt-count.
To configure TCP data retransmission:
1. In Superuser mode, type configure terminal and press Enter.
138
Oracle® Communications Unified Session Manager
System Configuration
ORACLE# configure terminal
2. Type system and press Enter.
ORACLE(configure)# system
ORACLE(system)#
3. Type network-parameters and press Enter.
ORACLE(system)# network-parameters
ORACLE(network-parameters)#
4. options—Set the options parameter by typing options, a Space, the option name atcp-rxmt-interval=x (where x is a
value in seconds between 2 and 60) with a plus sign in front of it. Then press Enter. This value will be used as the
interval between retransmission of TCP data segments that have not been acknowledged.
Now enter a second option to set the number of times the Oracle USM will retransmit a data segment before it
declares the connection failed. Set the options parameter by typing options, a Space, the option name atcp-rxmtcount=x (where x is a value between 4 and 12 representing how many retransmissions you want to enable) with a
plus sign in front of it. Then press Enter.
ORACLE(network-parameters)# options +atcp-rxmt-interval=30
ORACLE(network-parameters)# options +atcp-rxmt-count=6
If you type the option without the plus sign, you will overwrite any previously configured options. In order to
append the new options to the configuration’s options list, you must prepend the new option with a plus sign as
shown in the previous example.
5. Save and activate your configuration.
Timer for Idle Connections
When enabled to do so, the Oracle USM monitors inbound TCP connections for inactivity. These are inbound
connections that the remote peer initiated, meaning that the remote peer sent the first SYN message. You can
configure a timer that sets the maximum amount of idle time for a connection before the Oracle USM consider the
connection inactive. Once the timer expires and the connection is deemed inactive, the Oracle USM sends a TCP RST
message to the remote peer.
To configure the timer for TCP idle connections:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type system and press Enter.
ORACLE(configure)# system
ORACLE(system)#
3. Type network-parameters and press Enter.
ORACLE(system)# network-parameters
ORACLE(network-parameters)#
4. options—Set the options parameter by typing options, a Space, the option name atcp-idle-timer=x (where x is a
value in seconds between 120 and 7200) with a plus sign in front of it. Then press Enter. This value will be used to
measure the activity of TCP connections; when the inactivity on a TCP connection reaches this value in seconds,
the Oracle USMdeclares it inactive and drops the session.
ORACLE(network-parameters)# options +atcp-idle-timer=900
If you type the option without the plus sign, you will overwrite any previously configured options. In order to
append the new options to the configuration’s options list, you must prepend the new option with a plus sign as
shown in the previous example.
5. Save and activate your configuration.
Oracle® Communications Unified Session Manager
139
System Configuration
Historical Data Recording (HDR)
Updated HDR and HDR configuration information resides in the Net-Net® C-Series Historical Data Recording
(HDR) Resource Guide Version C6.3.0, 400-0141-63 (Net-Net 4000 S-CX6.3.0 HDR Resource Guide.pdf). This
document is available with the complete Version S-CX6.3.0 documentation set.
RAMdrive Log Cleaner
The RAMdrive log cleaner allows the Oracle USM to remove log files proactively and thereby avoid situations where
running low on RAMdrive space is a danger. Because even a small amount of logging can consume a considerable
space, you might want to enable the RAMdrive log cleaner.
The RAMdrive cleaner periodically checks the remaining free space in the RAMdrive and, depending on the
configured threshold, performs a full check on the /ramdrv/logs directory. During the full check, the RAMdrive
cleaner determines the total space logs files are using and deletes log files that exceed the configured maximum
lifetime. In addition, if the cleaner finds that the maximum log space has been exceeded or the minimum free space is
not sufficient, it deletes older log files until the thresholds are met.
Not all log files, however, are as active as others. This condition affects which log files the log cleaner deletes to
create more space in RAMdrive. More active log files rotate through the system more rapidly. So, if the log cleaner
were to delete the oldest of these active files, it might not delete less active logs files that could be older than the
active ones. The log cleaner thus deletes files that are truly older, be they active or inactive.
Applicable Settings
In the system configuration, you establish a group of settings in the options parameter that control the log cleaner’s
behavior:
•
ramdrv-log-min-free—Minimum percent of free space required when rotating log files.
•
When the amount of free space on the RAMdrive falls below this value, the log cleaner deletes the oldest copy of
the log file. The log cleaner also uses this setting when performing period cleaning.
ramdrv-log-max-usage—Maximum percent of the RAMdrive the log files can use.
•
•
•
•
The log cleaner removes old log files to maintain this threshold.
ramdrv-log-min-check—Minimum percent of free space on the RAMdrive that triggers the log cleaner to perform
a full check of log files.
ramdrv-min-log-check—Minimum time (in seconds) between log cleaner checks.
ramdrv-max-log-check—Maximum time (in seconds) between log cleaner checks. This value must be greater than
or equal to the ramdrv-min-log-check.
ramdrv-log-lifetime—Maximum lifetime (in days) for log files. You give logs unlimited lifetime by entering a
value of 0.
Clean-Up Procedure
The log cleaner checks the amount of space remaining in the RAMdrive and performs a full check of the logs
directory when:
•
•
•
Free space is less than the minimum percent of the RAMdrive that triggers a full check of log files
The amount of free space has changed by more than 5% of the RAMdrive capacity since the last full check
A full check of the logs directory has not been performed in the last hour
When it checks the logs directory, the log cleaner inventories the collected log files. It identifies each files as one of
these types:
•
•
•
140
Process log—Files beginning with log.
Internal trace file—A <task>.log file
Protocol trace file—Call trace including sipmsg.log, dns.log, sipddns.log, and alg.log
Oracle® Communications Unified Session Manager
System Configuration
•
CDR file—File beginning with cdr
Next, the log cleaner determines the age of the log files using the number of seconds since the log files were created.
Then it orders the files from oldest to newest. The age adjusts such that it always increases as the log file sequence
number (a suffix added by file rotation) increases. The log cleaner applies an additional weighting factor to produce a
weighted age that favors the preservation of protocol traces files over internal trace files, and internal trace files over
process log files. The base log file and CDR files are excluded from the age list and so will not be deleted; the
accounting configuration controls CDR file aging.
With the age list constructed, the log cleaner examines the list from highest weighted age to lowest. If the actual file
age exceeds the RAMdrive maximum log lifetime, the log cleaner deletes it. Otherwise, the log cleaner deletes files
until the maximum percent of RAMdrive that logs can use is no longer exceeded and until the minimum percent of
free space required when rotating logs is available.
Clean-Up Frequency
The minimum free space that triggers a full check of log files and the maximum time between log file checks control
how often the log cleaner performs the clean-up procedure. When it completes the procedure, the log cleaner
determines the time interval until the next required clean-up based on the RAMdrive’s state.
If a clean-up results in the deletion of one or more log files or if certain thresholds are exceeded, frequency is based
on the minimum time between log cleaner checks. Otherwise, the system gradually increases the interval up to the
maximum time between log cleaner checks. The system increases the interval by one-quarter of the difference
between the minimum and maximum interval, but not greater than one-half the minimum interval or smaller than 10
seconds. For example, using the default values, the interval would be increased by 30 seconds.
RAMdrive Log Cleaner Configuration
You configure the log cleaner’s operating parameters and thresholds in the system configuration. Note that none of
these settings is RTC-supported, so you must reboot your Oracle USM in order for them to take effect. If you are
using this feature on an HA node, however, you can add this feature without impact to service by activating the
configuration, rebooting the standby, switching over to make the newly booted standby active, and then rebooting the
newly standby system.
Unlike other values for options parameters, the Oracle USM validates these setting when entered using the ACLI. If
any single value is invalid, they all revert to their default values.
To configure the RAMdrive log cleaner:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
2. Type system and press Enter.
ORACLE(configure)# system
ORACLE(system)#
3. Type system-config and press Enter.
ORACLE(system)# system-config
ORACLE(system-config)#
4. options—Set the options parameter by typing options, a Space, <option name>=X (where X is the value you want
to use) with a plus sign in front of it. Then press Enter.
Remember that if any of your settings are invalid, the Oracle USM changes the entire group of these options back
to their default settings.
Option Name
Description
ramdrv-log-min-free
Minimum percent of free space required when rotating log files.
Oracle® Communications Unified Session Manager
141
System Configuration
Option Name
Description
When the amount of free space on the RAMdrive falls below this value, the
log cleaner deletes the oldest copy of the log file. The log cleaner also uses
this setting when performing period cleaning.
Default=40; Minimum=15; Maximum=75
ramdrv-log-max-usage
Maximum percent of the RAMdrive the log files can use.
The log cleaner removes old log files to maintain this threshold.
Default=40; Minimum=15; Maximum=75
ramdrv-log-min-check
Minimum percent of free space on the RAMdrive that triggers the log
cleaner to perform a full check of log files.
Default=50; Minimum=25; Maximum=75
ramdrv-min-log-check
Maximum time (in seconds) between log cleaner checks. This value must be
greater than or equal to the ramdrv-min-log-check.
Default=180; Minimum=40; Maximum=1800
ramdrv--log-lifetime
Maximum lifetime (in days) for log files. You give logs unlimited lifetime by
entering a value of 0.
Default=30; Minimum=2; Maximum=9999
ORACLE(system-config)#
ORACLE(system-config)#
ORACLE(system-config)#
ORACLE(system-config)#
ORACLE(system-config)#
ORACLE(system-config)#
options
options
options
options
options
options
+ramdrv-log-min-free=50
+ramdrv-log-max-usage=50
+ramdrv-log-min-check=35
+ramdrv-min-log-check=120
+ramdrv-max-log-free=1500
+ramdrv-log-lifetime=7
If you type options and then the option value for either of these entries without the plus sign, you will overwrite
any previously configured options. In order to append the new options to this configuration’s options list, you
must prepend the new option with a plus sign as shown in the previous example.
5. Reboot your Oracle USM.
Configurable Alarm Thresholds and Traps
The Oracle USM supports user-configurable threshold crossing alarms. These configurations let you identify system
conditions of varying severity which create corresponding alarms of varying severity. You configure an alarm
threshold type which indicates the resource to monitor. The available types are:
•
•
•
•
•
cpu — CPU utilization monitored as a percentage of total CPU capacity
memory — memory utilization monitored as a percentage of total memory available
sessions — license utilization monitored as a percentage of licensed session capacity
space — remaining disk space (configured in conjunction with the volume parameter - see the Storage Expansion
Module Monitoring section of the Accounting Guide for more information.)
deny-allocation — denied entry utilization monitored as a percentage of reserved, denied entries.
For the alarm type you create, the Oracle USM can monitor for 1 through 3 severity levels as minor, major, and
critical. Each of the severities is configured with a corresponding value that triggers that severity. For example the
configuration for a CPU alarm that is enacted when CPU usage reaches 50%:
alarm-threshold
type
142
cpu
Oracle® Communications Unified Session Manager
System Configuration
severity
value
minor
50
You may create addition CPU alarms for increasing severities. For example:
alarm-threshold
type
severity
value
cpu
critical
90
The alarm state is enacted when the resource defined with the type parameter exceeds the value parameter. When the
resource drops below the value parameter, the alarm is cleared.
SNMP Traps
When a configured alarm threshold is reached, the Oracle USM sends an apSysMgmtGroupTrap. This trap contains
the resource type and value for the alarm configured in the alarm-threshold configuration element. The trap does not
contain information associated with configured severity for that value.
apSysMgmtGroupTrap
NOTIFICATION-TYPE
OBJECTS
{ apSysMgmtTrapType, apSysMgmtTrapValue }
STATUS
current
DESCRIPTION
" The trap will generated if value of the monitoring object
exceeds a certain threshold. "
::= { apSystemManagementNotifications 1 }
When the resource usage retreats below a configured threshold, the Oracle USM sends an
apSysMgmtGroupClearTrap.
apSysMgmtGroupClearTrap
NOTIFICATION-TYPE
OBJECTS
{ apSysMgmtTrapType }
STATUS
current
DESCRIPTION
" The trap will generated if value of the monitoring object
returns to within a certain threshold. This signifies that
an alarm caused by that monitoring object has been cleared. "
::= { apSystemManagementNotifications 2 }
The alarm and corresponding traps available through the User Configurable Alarm Thresholds functionality are
summarized in the following table.
Alarm
Severity
Cause
Actions
CPU
minor
high CPU usage
apSysMgmtGroupTrap sent with
memory
major
apSysCPUUtil
critical
apSysMgmtTrapValue
minor
major
high memory
usage
critical
sessions
minor
major
minor
major
apSysMemoryUtil
apSysMgmtTrapValue
high license
usage
critical
space
apSysMgmtGroupTrap sent with
apSysMgmtGroupTrap sent with
apSysLicenseCapacity
apSysMgmtTrapValue
high HDD usage, apSysMgmtStorageSpaceAvailThresholdTrap
per volume
sent with:
critical
Oracle® Communications Unified Session Manager
apSysMgmtSpaceAvailCurrent
143
System Configuration
Alarm
Severity
Cause
Actions
apSysMgmtSpaceAvailMinorThreshold
apSysMgmtSpaceAvailMajorThreshold
apSysMgmtSpaceAvailCriticalThreshold
apSysMgmtPartitionPath
deny allocation
minor
major
high usage of
denied ACL
entries
apSysMgmtGroupTrap sent with
apSysCurrentEndptsDenied
critical
apSysMgmtTrapValue
Alarm Thresholds Configuration
To configure alarm thresholds:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type system and press Enter to access the system-level configuration elements.
ORACLE(configure)# system
3. Type system-config and press Enter.
ORACLE(system)# system-config
ORACLE(system-config)#
4. Type alarm-threshold and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(system-config)# alarm-threshold
ORACLE(alarm-threshold)#
5. type — Enter the type of resource which this alarm monitors. Valid values include:
• cpu
• memory
• sessions
• space
• deny-allocation
6. volume — Enter the logical disk volume this alarm monitors (used only in conjunction when type = space).
7. severity — Set the severity of the threshold. Valid values include:
• minor
• major
• critical
8. value — Enter the value from 1 to 99, indicating the percentage, which when exceeded generates an alarm.
9. Save and activate your configuration.
Alarm Synchronization
Two trap tables in the ap-smgmt.mib record trap information for any condition on the Oracle USM that triggers an
alarm condition. You can poll these two tables from network management systems, OSS applications, and the Session
Delivery Manager to view the fault status on one or more Oracle USM s.
The two trap tables that support alarm synchronization, and by polling them you can obtain information about the
current fault condition on the Oracle USM . These tables are:
144
Oracle® Communications Unified Session Manager
System Configuration
•
•
apSysMgmtTrapTable—You can poll this table to obtain a summary of the Oracle USM ’s current fault conditions.
The table records multiples of the same trap type that have occurred within a second of one another and have
different information. Each table entry contains the following:
• Trap identifier
• System time (synchronized with an NTP server)
• sysUpTime
• Instance number
• Other trap information for this trap identifier
apSysMgmtTrapInformationTable—You can poll this table to obtain further details about the traps recorded in the
apSysMgmtTrapTable table. The following information appears:
•
•
•
•
Data index
Data type
Data length
The data itself (in octets)
Trap tables do not record information about alarm severity.
The apSysMgmtTrapTable can hold up to 1000 entries, and you can configure the number of days these entries stay in
the table for a maximum of seven days. If you set this parameter to 0 days, the feature is disabled. And if you change
the setting to 0 days from a greater value, then the Oracle USM purges the tables.
Caveats
Note that the Oracle USM does not replicate alarm synchronization table data across HA nodes. That is, each Oracle
USM in an HA node maintains its own tables.
Alarm Synchronization Configuration
You turn on alarm synchronization in the system configuration.
To use alarm synchronization:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
2. Type system and press Enter.
ORACLE(configure)# system
ORACLE(system)#
3. Type system-config and press Enter.
ORACLE(system)# system-config
ORACLE(system-config)#
4. trap-event-lifetime—To enable alarm synchronization—and cause the Oracle USM to record trap information in
the apSysMgmtTrapTable and the apSysMgmtTrapInformationTable—set this parameter to the number of days
you want to keep the information. Leaving this parameter set to 0 (default) turns alarm synchronization off, and
you can keep information in the tables for up to 7 days. 7 is the maximum value for this parameter.
Accounting Configuration
The Oracle USM offers support for RADIUS, an accounting, authentication, and authorization (AAA) system. In
general, RADIUS servers are responsible for receiving user connection requests, authenticating users, and returning
all configuration information necessary for the client to deliver service to the user.
You can configure your Oracle USM to send call accounting information to one or more RADIUS servers. This
information can help you to see usage and QoS metrics, monitor traffic, and even troubleshoot your system.
Oracle® Communications Unified Session Manager
145
System Configuration
This guide contains all RADIUS information, as well as information about:
•
•
•
•
•
•
Local CDR storage on the Oracle USM , including CSV file format settings
The ability to send CDRs via FTP to a RADIUS sever (the FTP push feature)
Per-realm accounting control
Configurable intermediate period
RADIUS CDR redundancy
RADIUS CDR content control
Stream Control Transfer Protocol Overview
The Stream Control Transmission Protocol (SCTP) was originally designed by the Signaling Transport (SIGTRAN)
group of IETF for Signalling System 7 (SS7) transport over IP-based networks. It is a reliable transport protocol
operating on top of an unreliable connectionless service, such as IP. It provides acknowledged, error-free, nonduplicated transfer of messages through the use of checksums, sequence numbers, and selective retransmission
mechanism.
SCTP is designed to allow applications, represented as endpoints, communicate in a reliable manner, and so is similar
to TCP. In fact, it has inherited much of its behavior from TCP, such as association (an SCTP peer-to-peer connection)
setup, congestion control and packet-loss detection algorithms. Data delivery, however, is significantly different.
SCTP delivers discrete application messages within multiple logical streams within the context of a single
association. This approach to data delivery is more flexible than the single byte-stream used by TCP, as messages can
be ordered, unordered or even unreliable within the same association.
SCTP Packets
SCTP packets consist of a common header and one or more chunks, each of which serves a specific purpose.
•
•
•
•
•
•
•
•
•
•
•
•
•
DATA chunk — carries user data
INIT chunk — initiates an association between SCTP endpoints
INIT ACK chunk — acknowledges association establishment
SACK chunk — acknowledges received DATA chunks and informs the peer endpoint of gaps in the received
subsequences of DATA chunks
HEARTBEAT chunk — tests the reachability of an SCTP endpoint
HEARTBEAT ACK chunk — acknowledges reception of a HEARTBEAT chunk
ABORT chunk — forces an immediate close of an association
SHUTDOWN chunk — initiates a graceful close of an association
SHUTDOWN ACK chunk — acknowledges reception of a SHUTDOWN chunk
ERROR chunk — reports various error conditions
COOKIE ECHO chunk — used during the association establishment process
COOKIE ACK chunk — acknowledges reception of a COOKIE ECHO chunk
SHUTDOWN COMPLETE chunk — completes a graceful association close
SCTP Terminology
This section defines some terms commonly found in SCTP standards and documentation.
SCTP Association
is a connection between SCTP endpoints. An SCTP association is uniquely identified by the transport addresses used
by the endpoints in the association. An SCTP association can be represented as a pair of SCTP endpoints, for
example, assoc = { [IPv4Addr : PORT1], [IPv4Addr1, IPv4Addr2: PORT2]}.
Only one association can be established between any two SCTP endpoints.
SCTP Endpoint
146
Oracle® Communications Unified Session Manager
System Configuration
is a sender or receiver of SCTP packets. An SCTP endpoint may have one or more IP address but it always has one
and only one SCTP port number. An SCTP endpoint can be represented as a list of SCTP transport addresses with the
same port, for example, endpoint = [IPv6Addr, IPv6Addr: PORT].
An SCTP endpoint may have multiple associations.
SCTP Path
is the route taken by the SCTP packets sent by one SCTP endpoint to a specific destination transport address or its
peer SCTP endpoint. Sending to different destination transport addresses does not necessarily guarantee separate
routes.
SCTP Primary Path
is the default destination source address, the IPv4 or IPv6 address of the association initiator. For retransmissions
however, another active path may be selected, if one is available.
SCTP Stream
is a unidirectional logical channel established between two associated SCTP endpoints. SCTP distinguishes different
streams of messages within one SCTP association. SCTP makes no correlation between an inbound and outbound
stream.
SCTP Transport Address
is the combination of an SCTP port and an IP address. For the current release, the IP address portion of an SCTP
Transport Address must be a routable, unicast IPv4 or IPv6 address.
An SCTP transport address binds to a single SCTP endpoint.
SCTP Message Flow
Before peer SCTP users (commonly referred to as endpoints) can send data to each other, an association (an SCTP
connection) must be established between the endpoints. During the association establishment process a cookie
mechanism is employed to provide protection against security attacks. The following figure shows a sample SCTP
association establishment message flow.
Endpoint1 initiates the association by sending Endpoint2 an SCTP packet that contains an INIT chunk, which can
include one or more IP addresses used by the initiating endpoint. Endpoint2 acknowledges the initiation of an SCTP
association with an SCTP packet that contains an INIT_ACK chunk. This chunk can also include one or more IP
addresses at used by the responding endpoint.
Oracle® Communications Unified Session Manager
147
System Configuration
Both the INIT chuck (issued by the initiator) and INIT ACK chunk (issued by the responder) specify the number of
outbound streams supported by the association, as well as the maximum inbound streams accepted from the other
endpoint.
Association establishment is completed by a COOKIE ECHO/COOKIE ACK exchange that specifies a cookie value
used in all subsequent DATA exchanges.
Once an association is successfully established, an SCTP endpoint can send unidirectional data streams using SCTP
packets that contain DATA chunks. The recipient endpoint acknowledges with an SCTP packet containing a SACK
chunk.
SCTP monitors endpoint reachability by periodically sending SCTP packets that contain HEARTBEAT chunks. The
recipient endpoint acknowledges receipt, and confirms availability, with an SCTP packet containing a HEARBEAT
ACK chunk.
Either SCTP endpoint can initiate a graceful association close with an SCTP packet that contains a SHUTDOWN
chunk. The recipient endpoint acknowledges with an SCTP packet containing a SHUTDOWN ACK chunk. The
initiating endpoint concludes the graceful close with an SCTP packet that contains a SHUTDOWN COMPLETE
chunk.
Congestion Control
SCTP congestion control mechanism is similar to that provided by TCP, and includes slow start, congestion
avoidance, and fast retransmit. In SCTP, the initial congestion window ( cwnd ) is set to the double of the maximum
transmission unit (MTU) while in TCP, it is usually set to one MTU. In SCTP, cwnd increases based on the number of
acknowledged bytes, rather than the number of acknowledgements in TCP. The larger initial cwnd and the more
aggressive cwnd adjustment provided by SCTP result in a larger average congestion window and, hence, better
throughput performance than TCP.
Multi-Streaming
SCTP supports streams as depicted in the following figure which depicts an SCTP association that supports three
streams.
148
Oracle® Communications Unified Session Manager
System Configuration
The multiple stream mechanism is designed to solve the head-of-the-line blocking problem of TCP. Therefore,
messages from different multiplexed flows do not block one another.
A stream can be thought of as a sub-layer between the transport layer and the upper layer. SCTP supports multiple
logical streams to improve data transmission throughput. As shown in the above figure, SCTP allows multiple
unidirectional streams within an association. This multiplexing/de-multiplexing capability is called multi-streaming
and it is achieved by introducing a field called Stream Identifier contained in every DATA chunk) that is used to
differentiate segments in different streams.
SIP transactions are mapped into SCTP streams as described in Section 5.1 of RFC 4168. In what it describes as the
simplest way, the RFC suggests (keyword SHOULD) that all SIP messages be transmitted via Stream 0 with the U bit
set to 1.
On the transmit side, the current SCTP implementation follows the RFC 4168 recommendation. On the receiving
side, a SIP entity must be prepared to receive SIP messages over any stream.
Delivery Modes
SCTP supports two delivery modes, ordered and unordered . Delivery mode is specified by the U bit in the DATA
chunk header — if the bit is clear (0), ordered delivery is specified; if the bit is set (1), unordered delivery is specified.
Within a stream, an SCTP endpoint must deliver ordered DATA chunks (received with the U bit set to 0) to the upper
layer protocol according to the order of their Stream Sequence Number . Like the U bit, the Stream Sequence Number
is a field within the DATA chunk header, and serves to identify the chunk’s position with the message stream. If
DATA chunks arrive out of order of their Stream Sequence Number, the endpoint must delay delivery to the upper
layer protocol until they are reordered and complete.
Unordered DATA chunks (received with the U bit set to 1) are processed differently. When an SCTP endpoint
receives an unordered DATA chunk, it must bypass the ordering mechanism and immediately deliver the data to the
upper layer protocol (after reassembly if the user data is fragmented by the sender). As a consequence, the Stream
Sequence Number field in an unordered DATA chunk has no significance. The sender can fill it with arbitrary value,
but the receiver must ignore any value in field.
When an endpoint receives a DATA chunk with the U flag set to 1, it must bypass the ordering mechanism and
immediately deliver the data to the upper layer (after reassembly if the user data is fragmented by the data sender).
Unordered delivery provides an effective way of transmitting out-of-band data in a given stream. Note also, a stream
can be used as an unordered stream by simply setting the U bit to 1 in all DATA chunks sent through that stream.
Multi-Homing
Call control applications for carrier-grade service require highly reliable communication with no single point of
failure. SCTP can assist carriers with its multi-homing capabilities. By providing different paths through the network
over separate and diverse means, the goal of no single point of failure is more easily attained.
Oracle® Communications Unified Session Manager
149
System Configuration
SCTP built-in support for multi-homed hosts allows a single SCTP association to run across multiple links or paths,
hence achieving link/path redundancy. With this capability, and SCTP association can be made to achieve fast failover
from one link/path to another with little interruption to the data transfer service.
Multi-homing enables an SCTP host to establish an association with another SCTP host over multiple interfaces
identified by different IP addresses. With specific regard to the Oracle USM these IP addresses need not be assigned
to the same physical interface, or to the same physical Network Interface Unit.
If the SCTP nodes and the according IP network are configured in such a way that traffic from one node to another
travels on physically different paths if different destination IP address are used, associations become tolerant against
physical network failures and other problems of that kind.
An endpoint can choose an optimal or suitable path towards a multi-homed destination. This capability increases fault
tolerance. When one of the paths fails, SCTP can still choose another path to replace the previous one. Data is always
sent over the primary path if it is available. If the primary path becomes unreachable, data is migrated to a different,
affiliated address — thus providing a level of fault tolerance. Network failures that render one interface of a server
unavailable do not necessarily result in service loss. In order to achieve real fault resilient communication between
two SCTP endpoints, the maximization of the diversity of the round-trip data paths between the two endpoints is
encouraged.
Multi-Homing and Path Diversity
As previously explained, when a peer is multi-homed, SCTP can automatically switch the subsequent data
transmission to an alternative address. However, using multi-homed endpoints with SCTP does not automatically
guarantee resilient communications. One must also design the intervening network(s) properly.
To achieve fault resilient communication between two SCTP endpoints, one of the keys is to maximize the diversity
of the round-trip data paths between the two endpoints. Under an ideal situation, one can make the assumption that
every destination address of the peer will result in a different, separate path towards the peer. Whether this can be
achieved in practice depends entirely on a combination of factors that include path diversity, multiple connectivity,
and the routing protocols that glue the network together. In a normally designed network, the paths may not be
diverse, but there may be multiple connectivity between two hosts so that a single link failure will not fail an
association.
In an ideal arrangement, if the data transport to one of the destination addresses (which corresponds to one particular
path) fails, the data sender can migrate the data traffic to other remaining destination address(es) (that is, other paths)
within the SCTP association.
Monitoring Failure Detection and Recovery
When an SCTP association is established, a single destination address is selected as the primary destination address
and all new data is sent to that primary address by default. This means that the behavior of a multi-homed SCTP
association when there are no network losses is similar to behavior of a TCP connection. Alternate, or secondary,
destination addresses are only used for redundancy purposes, either to retransmit lost packets or when the primary
destination address cannot be reached.
A failover to an alternate destination is performed when the SCTP sender cannot elicit an acknowledgement — either
a SACK for a DATA chunk, or a HEARTBEAT ACK for a HEARTBEAT chunk — for a configurable consecutive
number of transmissions. The SCTP sender maintains an error-counter is maintained for each destination address and
if this counter exceeds a threshold (normally six), the address is marked as inactive, and taken out of service. If the
primary destination address is marked as inactive, all data is then switched to a secondary address to complete the
failover.
If no data has been sent to an address for a specified time, that endpoint is considered to be idle and a HEARTBEAT
packet is transmitted to it. The endpoint is expected to respond to the HEARTBEAT immediately with a
HEARTBEAT ACK. As well as monitoring the status of destination addresses, the HEARTBEAT is used to obtain
RTT measurements on idle paths. The primary address becomes active again if it responds to a heartbeat.
The number of events where heartbeats were not acknowledged within a certain time, or retransmission events
occurred is counted on a per association basis, and if a certain limit is exceeded, the peer endpoint is considered
unreachable, and the association is closed.
150
Oracle® Communications Unified Session Manager
System Configuration
The threshold for detecting an endpoint failure and the threshold for detecting a failure of a specific IP addresses of
the endpoint are independent of each other. Each parameter can be separately configured by the SCTP user. Careless
configuration of these protocol parameters can lead the association onto the dormant state in which all the destination
addresses of the peer are found unreachable while the peer still remains in the reachable state. This is because the
overall retransmission counter for the peer is still below the set threshold for detecting the peer failure.
Configuring SCTP Support for SIP
RFC 4168, The Stream Control Transfer Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP),
specifies the requirements for SCTP usage as a layer 4 transport for SIP. Use the following steps to:
•
•
•
•
•
configure SCTP as the layer 4 transport for a SIP interface
create an SCTP-based SIP port
associate physical interfaces/network interfaces with SIP realms
identify adjacent SIP servers that are accessible via SCTP
set SCTP timers and counters (optional)
Configuring an SCTP SIP Port
SIP ports are created as part of the SIP Interface configuration process.
1. From superuser mode, use the following command sequence to access sip-port configuration mode.
ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# sip-interface
ORACLE(sip-interface)# sip-ports
ORACLE(sip-port)#
2. Use the address parameter to provide the IPv4 or IPv6 address of the network interface that supports the SIP port.
This is the primary address of a the local multi-homed SCTP endpoint.
ORACLE(sip-port)# address 172.16.10.76
ORACLE(sip-port)#
3. Retain the default value, 5060 (the well-known SIP port) for the port parameter.
ORACLE(sip-port)# port 5060
ORACLE(sip-port)#
4. Use the transport-protocol parameter to identify the layer 4 protocol.
Supported values are UDP, TCP, TLS, and SCTP.
Select SCTP.
ORACLE(sip-port)# transport-protocol sctp
ORACLE(sip-port)#
5. Use the multi-homed-addrs parameter to specify one or more local secondary addresses of the SCTP endpoint.
Multi-homed addresses must be of the same type (IPv4 or IPv6) as that specified by the address parameter. Like
the address parameter, these addresses identify SD physical interfaces.
To specify multiple addresses, bracket an address list with parentheses.
ORACLE(sip-port)# multi-homed-addrs 182.16.10.76
ORACLE(sip-port)#
ORACLE(sip-port)# multi-homed-addrs (182.16.10.76 192.16.10.76
196.15.32.108)
ORACLE(sip-port)#
6. Remaining parameters can be safely ignored.
7. Use done, exit, and verify-config to complete configuration of this SCTP-based SIP port.
Oracle® Communications Unified Session Manager
151
System Configuration
ORACLE(sip-port)# done
ORACLE(sip-interface)# exit
ORACLE(session-router)# exit
ORACLE(configure)# exit
ORACLE# verify-config
--------------------------------------------------------------------Verification successful! No errors nor warnings in the configuration
ORACLE#
Configuring the Realm
After configuring a SIP port which identifies primary and secondary multi-homed transport addresses, you identify
the network interfaces that support the primary address and secondary addresses to the realm assigned during SIP
Interface configuration.
1. From superuser mode, use the following command sequence to access realm-config configuration mode.
ORACLE# configure terminal
ORACLE(configure)# media-manager
ORACLE(media-manager)# realm-config
ORACLE(realm-config)#
2. Use the select command to access the target realm.
3. Use the network-interfaces command to identify the network interfaces that support the SCTP primary and
secondary addresses.
Network interfaces are identified by their name.
Enter a list of network interface names using parentheses as list brackets. The order of interface names is not
significant.
ORACLE(realm-config)# network-interfaces (mo1 M10)
ORACLE(realm-config)#
4. Use done, exit, and verify-config to complete realm configuration.
ORACLE(realm-config)# done
ORACLE(media-manager)# exit
ORACLE(configure)# exit
ORACLE# verify-config
--------------------------------------------------------------------Verification successful! No errors nor warnings in the configuration
ORACLE#
Configuring Session Agents
After configuring the realm, you identify adjacent SIP servers who will be accessed via the SCTP protocol.
1. From superuser mode, use the following command sequence to access session-agent configuration mode.
ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# session-agent
ORACLE(session-agent)#
2. Use the select command to access the target session-agent.
3. Use the transport-method parameter to select the layer 4 transport protocol.
Select staticSCTP for SCTP transport
ORACLE(session-agent)# transport-method staticSCTP
ORACLE(session-agent)#
4. Set the reuse-connections parameter to none.
Select staticSCTP for SCTP transport
ORACLE(session-agent)# reuse-connections none
ORACLE(session-agent)#
152
Oracle® Communications Unified Session Manager
System Configuration
5. Use done, exit, and verify-config to complete session agent configuration.
ORACLE(session-agent)# done
ORACLE(session-router)# exit
ORACLE(configure)# exit
ORACLE# verify-config
--------------------------------------------------------------------Verification successful! No errors nor warnings in the configuration
ORACLE#
6. Repeat Steps 1 through 5 as necessary to configure additional session agents who will be accessed via SCTP
transport.
Setting SCTP Timers and Counters
Setting SCTP timers and counters is optional. All configurable timers and counters provide default values that
conform to recommended values as specified in RFC 4960, Stream Control Transmission Protocol.
Management of Retransmission Timer, section 6.3 of RFC 4960 describes the calculation of a Retransmission
Timeout (RTO) by the SCTP process. This calculation involves three SCTP protocol parameters: RTO.Initial,
RTO.Min, and RTO.Max. Suggested SCTP Protocol Parameter Values section 15 of RFC 4960 lists recommended
values for these parameters.
The following shows the equivalence of recommended values and ACLI defaults.
RTO.Initial = 3 seconds sctp-rto-initial = 3000 ms (default value)
RTO.Min = 1 second sctp-rto-min = 1000 ms (default value)
RTO.Max = 60 seconds sctp-rto-max = 60000 ms (default value)
Path Heartbeat, section 8.3 of RFC 4960 describes the calculation of a Heartbeat Interval by the SCTP process. This
calculation involves the current calculated RTO and a single SCTP protocol parameter — HB.Interval.
The following shows the equivalence of recommended the value and ACLI default.
HB.Interval = 30 seconds sctp-hb-interval = 3000 ms (default value)
Acknowledgement on Reception of DATA Chunks, section 6.2 of RFC 4960 describes requirements for the timely
processing and acknowledgement of DATA chunks. This section requires that received DATA chunks must be
acknowledged within 500 milliseconds, and recommends that DATA chunks should be acknowledged with 200
milliseconds. The interval between DATA chunk reception and acknowledgement is specific by the ACLI sctp-sacktimeout parameter, which provides a default value of 200 milliseconds and a maximum value of 500 milliseconds.
Transmission of DATA Chunks, section 6.1 of RFC 4960 describes requirements for the transmission of DATA
chunks. To avoid network congestion the RFC recommends a limitation on the volume of data transmitted at one
time. The limitation is expressed in terms of DATA chunks, not in terms of SCTP packets.
The maximum number of DATA chunks that can be transmitted at one time is specified by the ACLI sctp-max-burst
parameter, which provides a default value of 4 chunks, the limit recommended by the RFC.
Setting the RTO
An SCTP endpoint uses a retransmission timer to ensure data delivery in the absence of any feedback from its peer.
RFC 4960 refers to the timer itself as T3-rtx and to the timer duration as RTO (retransmission timeout).
When an endpoint's peer is multi-homed, the endpoint calculates a separate RTO for each IP address affiliated with
the peer. The calculation of RTO in SCTP is similar to the way TCP calculates its retransmission timer. RTO
fluctuates over time in response to actual network conditions. To calculate the current RTO, an endpoint maintains
two state variables per destination IP address — the SRTT (smoothed round-trip time) variable, and the RTTVAR
(round-trip time variation) variable.
Use the following procedure to assign values used in RTO calculation.
1. From superuser mode, use the following command sequence to access network-parameters configuration mode.
Oracle® Communications Unified Session Manager
153
System Configuration
ORACLE# configure terminal
ORACLE(configure)# system
ORACLE(system)# network-parameters
ORACLE(network-parameters)#
2. Use the sctp-rto-initial parameter to assign an initial timer duration.
Allowable values are integers within the range 0 through 4294967295 that specify the initial duration in
milliseconds. In the absence of an explicitly configured integer value, sctp-rto-initial defaults to 3000 milliseconds
(3 seconds, the recommended default value from RFC 4960).
As described in Section 6.3 of RFC 4960, the value specified by sctp-rto-initial is assigned to the SCTP protocol
parameter RTO.Initial, which provides a default RTO until actual calculations have derived a fluctuating duration
based on network usage. The value specified by the sctp-rto-initial parameter seeds these calculations.
ORACLE(network-parameters)# sctp-rto-initial 3000
ORACLE(network-parameters)#
3. Use the sctp-rto-min and sctp-rto-max parameters to assign an RTO floor and ceiling.
Allowable values are integers within the range 0 through 4294967295 that specify the minimum and maximum
durations in milliseconds. In the absence of an explicitly configured integer value, sctp-rto-min defaults to 1000
ms (1 second, the recommended default value from RFC 4960), and sctp-rto-max defaults to 60000 ms (60
seconds, the recommended default value from RFC 4960.)
As described in Section 6.3 of RFC 4960, the values specified by sctp-rto-min and sctp-rto-max are assigned to
the SCTP protocol parameters, RTO.min and RTO.max that limit RTO calculations. If a calculated RTO duration
is less than RTO.min, the parameter value is used instead of the calculated value; likewise, if a calculated RTO
duration is greater than RTO.max, the parameter value is used instead of the calculated value.
ORACLE(network-parameters)# sctp-rto-min 1000
ORACLE(network-parameters)# sctp-rto-max 60000
ORACLE(network-parameters)#
4. Use done, exit, and verify-config to complete RTO configuration.
ORACLE(network-parameters)# done
ORACLE(system)# exit
ORACLE(configure)# exit
ORACLE(configure)# exit
ORACLE# verify-config
--------------------------------------------------------------------Verification successful! No errors nor warnings in the configuration
ORACLE#
Setting the Heartbeat Interval
Both single-homed and multi-homed SCTP endpoints test the reachability of associates by sending periodic
HEARTBEAT chunks to UNCONFIRMED or idle transport addresses.
Use the following procedure to assign values used in Heartbeat Interval calculation.
1. From superuser mode, use the following command sequence to access network-parameters configuration mode.
ORACLE# configure terminal
ORACLE(configure)# system
ORACLE(system)# network-parameters
ORACLE(network-parameters)#
2. Use the sctp-hb-interval parameter to assign an initial Heartbeat Interval duration.
Allowable values are integers within the range 0 through 4294967295 that specify the initial Heartbeat Interval in
milliseconds. In the absence of an explicitly configured integer value, sctp-hb-interval defaults to 30000
milliseconds (30 seconds, the recommended default value from RFC 4960).
As described in Section 8.3 of RFC 4960, the value specified by sctp-hb-interval is assigned to the SCTP protocol
parameter HB.Interval, which provides a default interval until actual calculations have derived a fluctuating
154
Oracle® Communications Unified Session Manager
System Configuration
interval based on network usage. The value specified by the sctp-hb-interval parameter is used during these
calculations.
ORACLE(network-parameters)# sctp-hb-interval 30000
ORACLE(network-parameters)#
3. Use done, exit, and verify-config to complete Heartbeat Interval configuration.
ORACLE(network-parameters)# done
ORACLE(system)# exit
ORACLE(configure)# exit
ORACLE(configure)# exit
ORACLE# verify-config
--------------------------------------------------------------------Verification successful! No errors nor warnings in the configuration
ORACLE #
Setting the SACK Delay Timer
An SCTP Selective Acknowledgement (SACK) is sent to the peer endpoint to acknowledge received DATA chunks
and to inform the peer endpoint of gaps in the received subsequences of DATA chunks. Section 6.2 of RFC 4960 sets
a specific requirement for a SACK Delay timer that specifies the maximum interval between the reception of an
SCTP packet containing one or more DATA chunks and the transmission of a SACK to the packet originator.
Use the following procedure to set the SACK Delay timer.
1. From superuser mode, use the following command sequence to access network-parameters configuration mode.
ORACLE# configure terminal
ORACLE(configure)# system
ORACLE(system)# network-parameters
ORACLE(network-parameters)#
2. Use the sctp-sack-timeout parameter to assign a value to the SACK Delay timer.
Allowable values are integers within the range 0 through 500 which specify the maximum delay (in milliseconds)
between reception of a SCTP packet containing one or more Data chunks and the transmission of a SACK to the
packet source. The value 0 indicates that a SACK is generated immediately upon DATA chunk reception
In the absence of an explicitly configured integer value, sctp-sack-timeout defaults to 200 ms (the recommended
default value from RFC 4960).
ORACLE(network-parameters)# sctp-sack-timeout 200
ORACLE(network-parameters)#
3. Use done, exit, and verify-config to complete configuration of the SACK Delay timer.
ORACLE(network-parameters)# done
ORACLE(system)# exit
ORACLE(configure)# exit
ORACLE(configure)# exit
ORACLE# verify-config
--------------------------------------------------------------------Verification successful! No errors nor warnings in the configuration
ORACLE#
Limiting DATA Bursts
Section 6.1 of RFC 4960 describes the SCTP protocol parameter, Max.Burst, used to limit the number of DATA
chunks that are transmitted at one time.
Use the following procedure to assign a value to the SCTP protocol parameter, Max.Burst.
1. From superuser mode, use the following command sequence to access network-parameters configuration mode.
ORACLE# configure terminal
ORACLE(configure)# system
ORACLE(system)# network-parameters
ORACLE(network-parameters)#
Oracle® Communications Unified Session Manager
155
System Configuration
2. Use the sctp-max-burst parameter to assign a value to the SCTP protocol parameter, Max.Burst.
Allowable values are integers within the range 0 through 4294967295 that specify the maximum number of DATA
chunks that will be sent at one time. In the absence of an explicitly configured integer value, sctp-max-burst
defaults to 4 (DATA chunks, the recommended default value from RFC 4960).
ORACLE(network-parameters)# sctp-max-burst 4
ORACLE(network-parameters)#
3. Use done, exit, and verify-config to complete configuration of DATA burst limitations.
ORACLE(network-parameters)# done
ORACLE(system)# exit
ORACLE(configure)# exit
ORACLE(configure)# exit
ORACLE# verify-config
--------------------------------------------------------------------Verification successful! No errors nor warnings in the configuration
ORACLE#
Setting Endpoint Failure Detection
As described in Monitoring, Failure Detection and Recovery, a single-homed SCTP endpoint maintains a count of the
total number of consecutive failed (unacknowledged) retransmissions to its peer. Likewise, a multi-homed SCTP
endpoint maintains a series of similar, dedicated counts for all of its destination transport addresses. If the value of
these counts exceeds the limit indicated by the SCTP protocol parameter Association.Max.Retrans, the endpoint
considers the peer unreachable and stops transmitting any additional data to it, causing the association to enter the
CLOSED state.
The endpoint resets the counter when (1) a DATA chunk sent to that peer endpoint is acknowledged by a SACK, or
(2) a HEARTBEAT ACK is received from the peer endpoint.
Use the following procedure to configure endpoint failure detection.
1. From superuser mode, use the following command sequence to access network-parameters configuration mode.
ORACLE# configure terminal
ORACLE(configure)# system
ORACLE(system)# network-parameters
ORACLE(network-parameters)#
2. Use the sctp-assoc-max-retrans to assign a value to the SCTP protocol parameter Association.Max.Retrans.
Allowable values are integers within the range 0 through 4294967295 which specify the maximum number of
transmission requests. In the absence of an explicitly configured integer value, sctp-assoc-max-retrans defaults to
10 (transmission re-tries, the recommended default value from RFC 4960).
ORACLE(network-parameters)# sctp-assoc-max-retrans 10
ORACLE(network-parameters)#
3. Use done, exit, and verify-config to complete endpoint failure detection configuration.
ORACLE(network-parameters)# done
ORACLE(system)# exit
ORACLE(configure)# exit
ORACLE(configure)# exit
ORACLE# verify-config
--------------------------------------------------------------------Verification successful! No errors nor warnings in the configuration
ORACLE#
Setting Path Failure Detection
As described in Monitoring, Failure Detection and Recovery, when its peer endpoint is multi-homed, an SCTP
endpoint maintains a count for each of the peer’s destination transport addresses.
Each time the T3-rtx timer expires on any address, or when a HEARTBEAT sent to an idle address is not
acknowledged within an RTO, the count for that specific address is incremented. If the value of a specific address
156
Oracle® Communications Unified Session Manager
System Configuration
count exceeds the SCTP protocol parameter Path.Max.Retrans, the endpoint marks that destination transport address
as inactive.
The endpoint resets the counter when (1) a DATA chunk sent to that peer endpoint is acknowledged by a SACK, or
(2) a HEARTBEAT ACK is received from the peer endpoint.
When the primary path is marked inactive (due to excessive retransmissions, for instance), the sender can
automatically transmit new packets to an alternate destination address if one exists and is active. If more than one
alternate address is active when the primary path is marked inactive, a single transport address is chosen and used as
the new destination transport address.
Use the following procedure to configure path failure detection.
1. From superuser mode, use the following command sequence to access network-parameters configuration mode.
ORACLE# configure terminal
ORACLE(configure)# system
ORACLE(system)# network-parameters
ORACLE(network-parameters)#
2. Use the sctp-path-max-retrans parameter to assign a value to the SCTP protocol parameter Path.Max.Retrans.
Allowable values are integers within the range 0 through 4294967295 that specify the maximum number of RTOs
and unacknowledged HEARTBEATS. In the absence of an explicitly configured integer value, sctp-path-maxretrans defaults to 5 (RTO and/or HEARTBEAT errors per transport address, the recommended default value from
RFC 4960).
When configuring endpoint and path failure detection, ensure that the value of the sctp-assoc-max-retrans
parameter is smaller than the sum of the sctp-path-max-retrans values for all the remote peer’s destination
addresses. Otherwise, all the destination addresses can become inactive (unable to receive traffic) while the
endpoint still considers the peer endpoint reachable.
ORACLE(network-parameters)# sctp-path-max-retrans 5
ORACLE(network-parameters)#
3. Use done, exit, and verify-config to complete path failure detection configuration.
ORACLE(network-parameters)# done
ORACLE(system)# exit
ORACLE(configure)# exit
ORACLE(configure)# exit
ORACLE# verify-config
--------------------------------------------------------------------Verification successful! No errors nor warnings in the configuration
ORACLE#
Specifying the Delivery Mode
As described in Delivery Modes, SCTP support two delivery modes, ordered and unordered.
1. From superuser mode, use the following command sequence to access network-parameters configuration mode.
ORACLE# configure terminal
ORACLE(configure)# system
ORACLE(system)# network-parameters
ORACLE(network-parameters)#
2. Use the sctp-send-mode parameter to select the preferred delivery mode.
Choose ordered or unordered.
ORACLE(network-parameters)# sctp-send-mode unordered
ORACLE(network-parameters)#
3. Use done, exit, and verify-config to complete delivery mode configuration.
ORACLE(network-parameters)# done
ORACLE(system)# exit
ORACLE(configure)# exit
ORACLE(configure)# exit
Oracle® Communications Unified Session Manager
157
System Configuration
ORACLE# verify-config
--------------------------------------------------------------------Verification successful! No errors nor warnings in the configuration
ORACLE #
Example Configurations
The following ACLI command sequences summarize required SCTP port configuration, and the configuration of
required supporting elements.
•
•
•
•
•
PHY interfaces
Network interfaces
SIP ports
realms
session agents
Sequences show only configuration parameters essential for SCTP operations; other parameters can retain default
values, or assigned other values specific to local network requirements.
Phy Interface Configuration
The first ACLI command sequence configures a physical interface named m10, that will support an SCTP primary
address; the second sequence configures an interface named m01 that will support a secondary SCTP address.
ORACLE# configure terminal
ORACLE(configure)# system
ORACLE(system)# phy-interface
ORACLE(phy-interface)# operation-type media
ORACLE(phy-interface)# port 0
ORACLE(phy-interface)# slot 1
ORACLE(phy-interface)# name m10
ORACLE(phy-interface)#
...
...
...
ORACLE(phy-interface)#
ORACLE# configure terminal
ORACLE(configure)# system
ORACLE(system)# phy-interface
ORACLE(phy-interface)# operation-type media
ORACLE(phy-interface)# port 1
ORACLE(phy-interface)# slot 0
ORACLE(phy-interface)# name m01
ORACLE(phy-interface)#
...
...
...
ORACLE(phy-interface)#
Network Interface Configuration
These ACLI command sequences configure two network interfaces. The first sequence configures a network interface
named m10, thus associating the network interface with the physical interface of the same name. The ACLI ipaddress command assigns the IPv4 address 172.16.10.76 to the network interface. In a similar fashion, the second
command sequence associates the m01 network and physical interfaces, and assigns an IPv4 address of 182.16.10.76.
ORACLE# configure terminal
ORACLE(configure)# system
ORACLE(system)# network-interface
ORACLE(network-interface)# name m10
ORACLE(network-interface)# ip-address 172.16.10.76
...
...
158
Oracle® Communications Unified Session Manager
System Configuration
...
ORACLE(network-interface)#
ORACLE# configure terminal
ORACLE(configure)# system
ORACLE(system)# network-interface
ORACLE(network-interface)# name m01
ORACLE(network-interface)# ip-address 182.16.10.76
...
...
...
ORACLE(network-interface)#
SIP Port Configuration
This ACLI command sequence configures a SIP port for SCTP operations. It specifies the use of SCTP as the
transport layer protocol, and assigns the existing network interface address, 172.16.10.76, as the SCTP primary
address. Additionally, it identifies three other existing network addresses (182.16.10.76, 192.16.10.76, and
196.15.32.108) as SCTP secondary addresses.
ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# sip-interface
ORACLE(sip-interface)# sip-ports
ORACLE(sip-port)# address 172.16.10.76
ORACLE(sip-port)# transport-protocol sctp
ORACLE(sip-port)# multi-homed-addrs (182.16.10.76 192.16.10.76 196.15.32.108)
...
...
...
ORACLE(sip-port)#
Realm Configuration
These ACLI command sequences configure a realm for SCTP operations. The first ACLI sequence assigns a named
realm, in this example core-172, to a SIP interface during the interface configuration process. The second sequence
accesses the target realm and uses the network-interfaces command to associate the named SCTP network interfaces
with the realm.
ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# sip-interface
ORACLE(sip-interface)# realm-id core-172
...
...
...
ORACLE(sip-interface)#
ORACLE# configure terminal
ORACLE(configure)# media-manager
ORACLE(media-manager)# realm-config
ORACLE(realm-config)# select
identifier: core-172
1. core-172 ...
selection: 1
ORACLE(realm-config)# network-interfaces (m01 m10 ...)
...
...
...
ORACLE(ream-config)#
Session Agent Configuration
The final ACLI command sequence enables an SCTP-based transport connection between the Acme Packet 4500 and
an adjacent network element.
Oracle® Communications Unified Session Manager
159
System Configuration
ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# session-agent
ORACLE(session-agent)# select
<hostname>: core-172S1
1. core-172S1 ...
selection: 1
ORACLE(session-agent)#
ORACLE(session-agent)# transport-method staticSCTP
ORACLE(session-agent)# reuse-connections none
...
...
...
ORACLE(session-agent)#
IPV6 Address Configuration
IPv6 can be a licensed feature on the Oracle USM. IPv6 is available on the Oracle CSM without an explicit license or
entitlement.
If you want to add this license to a system, contact Oracle. Once you have the license, refer to the Getting Started
chapter for instructions about how to add a license.
You do not need to take action if you are working with a new system with which the IPv6 license was purchased.
Note: For ACLI parameters that support only IPv4, there are many references to that version as the accepted
value for a configuration parameter or other IPv4-specific languages. For IPv6 support, these references have
been edited. For example, rather than providing help that refers specifically to IPv4 addresses when
explaining what values are accepted in an ACLI configuration parameter, you will now see an <ipAddr> note.
This section calls out the configurations and parameters for which you can enter IPv6 addresses. In this first IPv6
implementation, the complete range of system configurations and their parameters are available for IPv6 use.
The Oracle USM follows RFC 3513 its definition of IPv6 address representations. Quoting from that RFC, these are
the two forms supported:
•
The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the hexadecimal values of the eight 16-bit pieces of the
address. Examples:
FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
1080:0:0:0:8:800:200C:417A
Note that it is not necessary to write the leading zeros in an individual field, but there must be at least one numeral in
every field (except for the case described in 2.).
•
Due to some methods of allocating certain styles of IPv6 addresses, it will be common for addresses to contain
long strings of zero bits. In order to make writing addresses containing zero bits easier a special syntax is available
to compress the zeros. The use of "::" indicates one or more groups of 16 bits of zeros. The "::" can only appear
once in an address. The "::" can also be used to compress leading or trailing zeros in an address. For example, the
following addresses: 1080:0:0:0:8:800:200C:417A a unicast address FF01:0:0:0:0:0:0:101 a multicast address
0:0:0:0:0:0:0:1 the loopback address
0:0:0:0:0:0:0:0 the unspecified addresses
may be represented as:
1080::8:800:200C:417A a unicast address
FF01::101 a multicast address
::1 the loopback address
:: the unspecified addresses
160
Oracle® Communications Unified Session Manager
System Configuration
Access Control
These are the IPv6-enabled parameters in the access-control configuration.
Parameter
Entry Format
source-address
<ip-address>[/<num-bits>][:<port>[/<port-bits>]]
destination-address
<ip-address>[/<num-bits>][:<port>[/<port-bits>]]
Host Route
These are the IPv6-enabled parameters in the host-route configuration.
Parameter
Entry Format
dest-network
<ipv4> | <ipv6>
netmask
<ipv4> | <ipv6>
gateway
<ipv4> | <ipv6>
Local Policy
These are the IPv6-enabled parameters in the local-policy configuration.
Parameter
Entry Format
from-address
<ipv4> | <ipv6> | POTS Number, E.164 Number, hostname, wildcard
to-address
<ipv4> | <ipv6> | POTS Number, E.164 Number, hostname, wildcard
Network Interface
These are the IPv6-enabled parameters in the network-interface configuration.
Parameter
Entry Format
hostname
<ipv4> | <ipv6> | hostname
ip-address
<ipv4> | <ipv6>
pri-utility-addr
<ipv4> | <ipv6>
sec-utility-addr
<ipv4> | <ipv6>
netmask
<ipv4> | <ipv6>
gateway
<ipv4> | <ipv6>
sec-gateway
<ipv4> | <ipv6>
dns-ip-primary
<ipv4> | <ipv6>
dns-ip-backup1
<ipv4> | <ipv6>
dns-ip-backup2
<ipv4> | <ipv6>
add-hip-ip
<ipv4> | <ipv6>
remove-hip-ip
<ipv4> | <ipv6>
add-icmp-ip
<ipv4> | <ipv6>
remove-icmp-ip
<ipv4> | <ipv6>
Oracle® Communications Unified Session Manager
161
System Configuration
ENUM Server
These are the IPv6-enabled parameters in the enum-config.
Parameter
Entry Format
enum-servers
[<ipv4> | <ipv6>]:port
Realm Configuration
These are the IPv6-enabled parameters in the realm-config.
Parameter
Entry Format
addr-prefix
[<ipv4> | <ipv6>]/prefix
Session Agent
These are the IPv6-enabled parameters in the session-agent configuration.
Parameter
Entry Format
hostname
<ipv4> | <ipv6>
ip-address
<ipv4> | <ipv6>
SIP Configuration
These are the IPv6-enabled parameters in the session-config.
Parameter
Entry Format
registrar-host
<ipv4> | <ipv6> | hostname | *
SIP Interface SIP Ports
These are the IPv6-enabled parameters in the sip-interface>sip-ports configuration.
Parameter
Entry Format
address
<ipv4> | <ipv6>
Steering Pool
These are the IPv6-enabled parameters in the steering-pool configuration.
Parameter
Entry Format
ip-address
<ipv4> | <ipv6>
System Configuration
These are the IPv6-enabled parameters in the system-config.
162
Parameter
Entry Format
default-v6-gateway
<ipv6>
Oracle® Communications Unified Session Manager
System Configuration
IPv6 Support for Management and Telemetry
Several management-oriented parameters on the Oracle USM may be configured with IPv6 addresses to be used
within IPv6 networks.
The following parameters that are configured with IP addresses accept IPv6 addresses to be used within IPv6 address
space.
You may configure the wancom0/eth0 physical interface in the bootparams with an IPv6 address and complementary
IPv6 gateway via the following parameters:
•
•
bootparams > inet on ethernet
bootparams > gateway inet
You may configure a syslog server with an IPv6 destination address via the following parameter:
•
system > system-config > syslog-servers > address
You may configure a system access list entry with an IPv6 source address and complementary IPv6 gateway.
•
•
system > system-access-list > source-address
system > system-access-list > netmask
You may configure a RADIUS server with an IPv6 destination address via the following parameter:
•
security > authentication > radius-servers > address
IPv6 Default Gateway
In the system configuration, you configure a default gateway—a parameter that now has its own IPv6 equivalent.
To configure an IPv6 default gateway:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
2. Type system and press Enter.
ORACLE(configure)# system
ORACLE(system)#
3. Type system-config and press Enter.
ORACLE(system)# system-config
ORACLE(system-config)#
4. default-v6-gateway—Set the IPv6 default gateway for this Oracle USM. This is the IPv6 egress gateway for traffic
without an explicit destination. The application of your Oracle USM determines the configuration of this
parameter.
5. Save your work.
IPv6 Link Local Addresses
The Oracle USM supports IPv6 Link Local addresses configured for a network interface’s gateway.
An IPv6 link local address is signified by its first hextet set to FE80:. Even if a network interface’s first hextet is not
FE80, but the gateway is, the Oracle USM will still function as expected.
show neighbor-table
The show neighbor-table command displays the IPv6 neighbor table and validates that there is an entry for the link
local address, and the gateway uses that MAC address.
Oracle® Communications Unified Session Manager
163
System Configuration
System# show neighbor-table
LINK LEVEL NEIGHBOR TABLE
Neighbor
Linklayer Address Netif Expire
S
Flags
300::100
0:8:25:a1:ab:43
sp0 permanent ? R
871962224
400::100
0:8:25:a1:ab:45
sp1 permanent ? R
871962516
fe80::bc02:a98f:f61e:20%sp0
be:2:ac:1e:0:20
sp0 4s
? R
871962808
fe80::bc01:a98f:f61e:20%sp1
be:1:ac:1e:0:20
sp1 4s
? R
871963100
-----------------------------------------------------------------------------ICMPv6 Neighbor Table:
----------------------------------------------------------------------------------------entry: slot port vlan IP
type
flag
pendBlk Hit MAC
----------------------------------------------------------------------------------------5
: 1
0
0
fe80::bc01:a98f:f61e:20/64
08-DYNAMIC 1
0
1
be:01:ac:1e:00:20
4
: 1
0
0
0.0.0.0/64
01-GATEWAY 0
0
1
be:01:ac:1e:00:20
3
: 1
0
0
400::/64
02-NETWORK 0
0
1
00:00:00:00:00:00
2
: 0
0
0
fe80::bc02:a98f:f61e:20/64
08-DYNAMIC 1
0
1
be:02:ac:1e:00:20
1
: 0
0
0
0.0.0.0/64
01-GATEWAY 0
0
1
be:02:ac:1e:00:20
0
: 0
0
0
300::/64
02-NETWORK 0
0
1
00:00:00:00:00:00
-----------------------------------------------------------------------------------------
Network Interfaces and IPv6
You set many IP addresses in the network interface, one of which is the specific IP address for that network interface
and others that are related to different types of management traffic. This section outlines rules you must follow for
these entries.
•
•
•
•
•
For the network-interface ip-address parameter, you can set a single IP address. When you are working with an
IPv6-enabled system, however, note that all other addresses related to that network-interface IP address must be of
the same version.
Heterogeneous address family configuration is prevented for the dns-ip-primary, dns-ip-backup1, and dns-ipbackup2 parameters.
For HIP addresses (add-hip-ip), you can use either IPv4 or IPv6 entries.
For ICMP addresses (add-icmp-ip), you can use either IPv4 or IPv6 entries.
For Telnet (add-telnet-ip), FTP (add-ftp-ip), and SNMP (add-snmp-ip), you are not allowed to use IPv6; your
entries MUST use IPv4.
IPv6 Reassembly and Fragmentation Support
As it does for IPv4, the Oracle USM supports reassembly and fragmentation for large signaling packets when you
enable IPV6 on your system.
The Oracle USM takes incoming fragments and stores them until it receives the first fragment containing a Layer 4
header. With that header information, the Oracle USM performs a look-up so it can forward the packets to its
164
Oracle® Communications Unified Session Manager
System Configuration
application layer. Then the packets are re-assembled at the applications layer. Media fragments, however, are not
reassembled and are instead forwarded to the egress interface.
On the egress side, the Oracle USM takes large signaling messages and encodes it into fragment datagrams before it
transmits them.
Note that large SIP INVITE messages should be sent over TCP. If you want to modify that behavior, you can use the
SIP interface’s option parameter max-udp-length=xx for each SIP interface where you expect to receive large INVITE
packets.
Other than enabling IPv6 on your Oracle USM, there is no configuration for IPv6 reassembly and fragmentation
support. It is enabled automatically.
Access Control List Support
The Oracle USM supports IPv6 for access control lists in two ways:
•
•
For static access control lists that you configure in the access-control configuration, your entries can follow IPv6
form. Further, this configuration supports a prefix that enables wildcarding the source IP address.
Dynamic ACLs are also supported; the Oracle USM will create ACLs for offending IPv6 endpoints.
Data Entry
When you set the source-address and destination-address parameters in the access-control configuration, you will use
a slightly different format for IPv6 than for IPv4.
For the source-address, your IPv4 entry takes the following format: <ip-address>[/<num-bits>][:<port>[/<portbits>]]. And for the destination-address, your IPv4 entry takes this format: <ip-address>[:<port>[/<port-bits>]].
Since the colon (:) in the IPv4 format leads to ambiguity in IPv6, your IPv6 entries for these settings must have the
address encased in brackets ([]): [7777::11]/64:5000/14.
In addition, IPv6 entries are allowed up to 128 bits for their prefix lengths.
The following is an example access control configuration set up with IPv6 addresses.
ORACLE(access-control)# done
access-control
realm-id
description
source-address
destination-address
application-protocol
transport-protocol
access
average-rate-limit
trust-level
minimum-reserved-bandwidth
invalid-signal-threshold
maximum-signal-threshold
untrusted-signal-threshold
deny-period
net7777
7777::11/64:5060/8
8888::11:5060/8
SIP
ALL
deny
0
none
0
10
0
0
30
DNS Support
The Oracle USM supports the DNS resolution of IPv6 addresses; in other words, it can request the AAAA record type
(per RFC 1886) in DNS requests. In addition, the Oracle USM can make DNS requests over IPv6 transport so that it
can operate in networks that host IPv6 DNS servers.
For mixed IPv4-IPv6 networks, the Oracle USM follows these rules:
Oracle® Communications Unified Session Manager
165
System Configuration
•
•
If the realm associated with the name resolution is an IPv6 realm, the Oracle USM will send the query out using
the AAAA record type.
If the realm associated with the name resolution is an IPv4 realm, the Oracle USM will send the query out using
the A record type.
In addition, heterogeneous address family configuration is prevented for the dns-ip-primary, dns-ip-backup1, and dnsip-backup2 parameters.
Homogeneous Realms
IPv6 is supported for realms and for nested realms, as long as the parent chain remains within the same address
family. If you try to configure realms with mixed IPv4-IPv6 addressing, your system will issue an error message
when you try to save your configuration. This check saves you time because you do not have to wait to run a
configuration verification (using the ACLI verify-config command) to find possible errors.
Parent-Child Network Interface Mismatch
Your system will issue the following error message if parent-child realms are on different network interfaces that
belong to different address families:
ERROR: realm-config [child] and parent [net8888] are on network interfaces
that belong to different address families
Address Prefix-Network Interface Mismatch
If the address family and the address-prefix you configure for the realm does not match the address family of its
network interface, your system will issue the following error message:
ERROR: realm-config [child] address prefix and network interface [1:1:0]
belong to different address families
RADIUS Support for IPv6
The Oracle USM’s RADIUS support now includes:
•
•
RADIUS CDR generation for SIPv6-SIPv6 and SIPv6-SIPv4 calls
IPv6-based addresses in RADIUS CDR attributes
This means that for the CDR attributes in existence prior to the introduction of IPv6 to the Acme Packet 4500 are
mapped to the type ipaddr, which indicates four-byte field. The sixteen-byte requirement for IPv6 addresses is now
supported, and there are a parallel set of attributes with the type ipv6addr. Attributes 155-170 are reserved for the
IPv6 addresses.
NAS addresses use the number 95 to specify the NAS-IPV6-Address attribute. And local CDRs now contain IPv6
addresses.
Supporting RADIUS VSAs
The following VSAs have been added to the Oracle RADIUS dictionary to support IPv6.
Acme-Flow-In-Src-IPv6_Addr_FS1_F
Acme-Flow-In-Dst-IPv6_Addr_FS1_F
Acme-Flow-Out-Src-IPv6_Addr_FS1_F
Acme-Flow-Out-Dst-IPv6_Addr_FS1_F
Acme-Flow-In-Src-IPv6_Addr_FS1_R
Acme-Flow-In-Dst-IPv6_Addr_FS1_R
Acme-Flow-Out-Src-IPv6_Addr_FS1_R
Acme-Flow-Out-Dst-IPv6_Addr_FS1_R
Acme-Flow-In-Src-IPv6_Addr_FS2_F
Acme-Flow-In-Dst-IPv6_Addr_FS2_F
166
155
156
157
158
159
160
161
162
163
164
ipv6addr
ipv6addr
ipv6addr
ipv6addr
ipv6addr
ipv6addr
ipv6addr
ipv6addr
ipv6addr
ipv6addr
Acme
Acme
Acme
Acme
Acme
Acme
Acme
Acme
Acme
Acme
Oracle® Communications Unified Session Manager
System Configuration
Acme-Flow-Out-Src-IPv6_Addr_FS2_F
Acme-Flow-Out-Dst-IPv6_Addr_FS2_F
Acme-Flow-In-Src-IPv6_Addr_FS2_R
Acme-Flow-In-Dst-IPv6_Addr_FS2_R
Acme-Flow-Out-Src-IPv6_Addr_FS2_R
Acme-Flow-Out-Dst-IPv6_Addr_FS2_R
Oracle® Communications Unified Session Manager
165
166
167
168
169
170
ipv6addr
ipv6addr
ipv6addr
ipv6addr
ipv6addr
ipv6addr
Acme
Acme
Acme
Acme
Acme
Acme
167
4
Realms and Nested Realms
This chapter explains how to configure realms and nested realms, and specialized media-related features.
A realm is a logical definition of a network or groups of networks made up in part by devices that provide real-time
communication sessions comprised of signaling messages and possibly media flows. These network devices might be
call agents, softswitches, SIP proxies, IP PBXs, etc., that are statically defined by IPv4 addresses. These network
devices might also be IPv4 endpoints: SIP phones, IADs, MAs, media gateways, etc., that are defined by an IPv4
address prefix.
Realms support bandwidth-based call admission control and QoS marking for media. They are the basis for defining
egress and ingress traffic to the Oracle USM—which supports the Oracle USM’s topology hiding capabilities.
This chapter also explains how to configure media ports (steering pools). A steering pool exists within a realm and
contains a range of ports that have a common address (for example, a target IPv4 address). The range of ports
contained in the steering pool are used to steer media flows from one realm, through the Oracle USM, to another.
Finally, in this chapter you can learn about TOS/DiffServ functionality for realm-based packet marking by media
type.
Overview
Realms are a logical distinction representing routes (or groups of routes) reachable by the Oracle USM and what
kinds of resources and special functions apply to those routes. Realms are used as a basis for determining ingress and
egress associations to network interfaces, which can reside in different VPNs. The ingress realm is determined by the
signaling interface on which traffic arrives. The egress realm is determined by the following:
•
•
•
Routing policy—Where the egress realm is determined in the session agent configuration or external address of a
SIP-NAT
Realm-bridging—As applied in the SIP-NAT configuration configurations
Third-party routing/redirect (i.e., SIP redirect)
Realms also provide configuration support for denial of service (DoS)/access control list (ACL) functionality.
Realms can also be nested in order to form nested realm groups. Nested realms consist of separate realms that are
arranged within a hierarchy to support network architectures that have separate backbone networks and VPNs for
signaling and media. This chapter provides detailed information about nested realms after showing you how to
configure realms on your Oracle USM.
Oracle® Communications Unified Session Manager
169
Realms and Nested Realms
About Realms and Network Interfaces
All realms reference network interfaces on the Oracle USM. This reference is made when you configure a list of
network interfaces in the realm configuration.
You configure a network interface to specify logical network interfaces that correspond existing physical interfaces on
the Oracle USM. Configuring multiple network interfaces on a single physical interface creates a channelized
physical interface, a VLAN. VLANs, in turn, allow you to reuse address space, segment traffic, and maximize
bandwidth.
In order to reach the realms you configure, you need to assign them network interfaces. The values you set for the
name and port in the network interface you select then indicate where the realm can be reached.
About the SIP Home Realm
The realm configuration is also used to establish what is referred to as the SIP home realm. This is the realm where
the Oracle USM’s SIP proxy sits.
In peering configurations, the SIP home realm is the internal network of the SIP proxy. In backbone access
configurations, the SIP home realm typically interfaces with the backbone connected network. In additions, the SIP
home realm is usually exposed to the Internet in an HNT configuration.
Although you configure a SIP home realm in the realm configuration, it is specified as the home realm in the main
SIP configuration by the home realm identifier parameter. Specifying the SIP home realm means that the Oracle
USM’s SIP proxy can be addressed directly by connected entities, but other connected network signaling receives
layer 3 NAT treatment before reaching the internal SIP proxy.
About Realms and Other Oracle USM Functions
Realms are referenced by other configurations in order to support this functionality across the protocols the Oracle
USM supports and to make routing decisions. Other configurations’ parameters that point to realms are:
•
•
•
•
•
•
•
SIP configuration: home realm identifier, egress realm identifier
SIP-NAT configuration: realm identifier
MGCP configuration: private realm, public realm
Session agent configuration: realm identifier
Media manager: home realm identifier
Steering ports: realm identifier
Static flow: in realm identifier, out realm identifier
Realms
Realm configuration is divided into the following functional areas, and the steps for configuring each are set out in
this chapter: identity and IP address prefix, realm interfaces, realm service profiles, QoS measurement, QoS marking,
address translation profiles, and DNS server configuration.
Before You Configure
Before you configure realms, you want to establish the physical and network interfaces with which the realm will be
associated.
•
•
Configure a physical interface to define the physical characteristics of the signaling line.
Configure a network interface to define the network in which this realm is participating and optionally to create
VLANs.
If you wish to use QoS, you should also determine if your Oracle USM is QoS enabled.
Remember that you will also use this realm in other configurations to accomplish the following:
•
170
Set a signaling port or ports at which the Oracle USM listens for signaling messages.
Oracle® Communications Unified Session Manager
Realms and Nested Realms
•
•
Configure sessions agents to point to ingress and egress signaling devices located in this realm in order to apply
constraint for admission control.
Configure session agents for defining trusted sources for accepting signaling messages.
Realm Configuration
To access the realm configuration parameters in the ACLI:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type media-manager and press Enter to access the media-related configurations.
ORACLE(configure)# media-manager
3. Type realm-config and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(media-manager)# realm-config
ORACLE(realm-config)#
From this point, you can configure realm parameters. To view all realm configuration parameters, enter a ? at the
system prompt.
Identity and IP Address Prefix
The first parameters you configure for a realm are its name (a unique identifier) and an IP address prefix and subnet
mask.
The IP address and subnet mask establish a set of matching criteria for the realm, and distinguishes between realms
that you assign to the same network interface.
To configure a realm’s identity and IP address prefix in the ACLI:
1. identifier—Enter the name of the realm. This parameter uniquely identifies the realm. You will use this parameter
in other configurations when asked for a realm identifier value.
2. addr-prefix—Enter the IPv4 or IPv6 address and subnet mask combination to set the criteria the Oracle USM uses
to match packets sent or received on the network interface associated with this realm. This matching determines
the realm, and subsequently what resources are used for that traffic. This setting determines whether the realm is
an IPv4 or IPv6 realm.
This parameter must be entered in the correct format where the IPv4 or IPv6 address comes first and is separated
by a slash (/) from the subnet mask value. For example, 172.16.0.0/24.
The default for this parameter is 0.0.0.0. When you leave this parameter set to the default, all addresses match.
Realm Interfaces
The realm points to one network interface on the Oracle USM.
Note: Only one network-interface can be assigned to a single realm-config object, except for Local multihoming SCTP deployments.
To assign interfaces to a realm:
network-interfaces—Enter the physical and network interface(s) that you want this realm to reference. These are
the network interfaces though which this realm can be reached by ingress traffic, and through which this traffic
exits the system as egress traffic.
Enter the name and port in the correct format where the name of the interface comes first and is separated by a
colon (:) from the port number. For example, f10:0.
The parameters you set for the network interfaces must be unique.
Enter multiple network interfaces for this list by typing an open parenthesis, entering each field value separated by
a Space, typing a closed parenthesis, and then pressing Enter.
Oracle® Communications Unified Session Manager
171
Realms and Nested Realms
ORACLE(realm-config)# network-interfaces fe1:0
You must explicitly configure a realm's network interface as either IPv4 or IPv6 when the applicable interface is
either dual-stack or IPv6. You do this by appending the realm's network-interface with a .4 or a .6, as shown
below.
ORACLE(realm-config)# network-interfaces fe1:0.6
For single-stack interface configurations that do not specify this format, the Oracle USM assumes an IPv4
interface. Dual stack interface configurations fail if this IP version family suffix is not specified.
Realm Service Profile
The parameters you configure to establish the realm service profile determine how bandwidth resources are used and
how media is treated in relation to the realm. Bandwidth constraints set for realm service profiles support the Oracle
USM’s admission control feature.
Peer-to-peer media between endpoints can be treated in one of three different ways:
•
•
•
Media can be directed between sources and destinations within this realm on this specific Oracle USM. Media
travels through the Oracle USM rather than straight between the endpoints.
Media can be directed through the Oracle USM between endpoints that are in different realms, but share the same
subnet.
For SIP only, media can be released between multiple Oracle USMs.
To enable SIP distributed media release, you must set the appropriate parameter in the realm configuration. You
must also set the SIP options parameter to media-release with the appropriate header name and header parameter
information. This option defines how the Oracle USM encodes IPv4 address and port information for media
streams described by, for example, SDP.
To configure realm service profile:
1. max-bandwidth—Enter the total bandwidth budget in kilobits per second for all flows to/from the realm defined in
this element. The default is 0 which allows for unlimited bandwidth. The valid range is:
• Minimum—0
• Maximum—4294967295
2. mm-in-realm—Enable this parameter to treat media within this realm on this Oracle USM. The default is disabled.
Valid values are:
• enabled | disabled
3. mm-in-network—Enable this parameter to treat media within realms that have the same subnet mask on this
Oracle USM. The default is enabled. Valid values are:
• enabled | disabled
4. msm-release—Enable or disable the inclusion of multi-system (multiple Oracle USMs) media release information
in the SIP signaling request sent into the realm identified by this realm-config element. If this field is set to
enabled, another Oracle USM is allowed to decode the encoded SIP signaling request message data sent from a
SIP endpoint to another SIP endpoint in the same network to resore the original SDP and subsequently allow the
media to flow directly between those two SIP endpoints in the same network serviced by multiple Oracle USMs.
If this field is disabled, the media and signaling will pass through boht Oracle USMs. Remember that for this
feature to work, you must also set the options parameter in the SIP configuration accordingly. The default is
disabled. Valid values are:
•
enabled | disabled
QoS Measurement
This chapter provides detailed information about when to configure the qos-enable parameter. If you are not using
QoS or a QoS-capable Oracle USM, then you can leave this parameter set to disabled (default).
172
Oracle® Communications Unified Session Manager
Realms and Nested Realms
QoS Marking
QoS marking allows you to apply a set of TOS/DiffServ mechanisms that enable you to provide better service for
selected networks
You can configure a realm to perform realm-based packet marking by media type, either audio/voice or video.
The realm configuration references a set of media policies that you configure in the media policy configuration.
Within these policies, you can establish TOS/DiffServ values that define an individual type (or class) of service, and
then apply them on a per-realm basis. In the media profiles, you can also specify:
•
•
•
One or more audio media types for SIP
One or more video types for SIP
Both audio and video media types for SIP
To establish what media policies to use per realm in the ACLI:
media-policy—Enter the name (unique identifier) of the media policy you want to apply in the realm. When the
Oracle USM first sets up a SIP media session, it identifies the egress realm of each flow and then determines the
media-policy element to apply to the flow. This parameter must correspond to a valid name entry in a media
policy element. If you leave this parameter empty, then QoS marking for media will not be performed for this
realm.
Address Translation Profiles
If you are not using this feature, you can leave the in-translationid and out-translationid parameters blank.
DNS Servers
You can configure DNS functionality on a per-network-interface basis, or you can configure DNS servers to use per
realm. Configuring DNS servers for your realms means that you can have multiple DNS servers in connected
networks. In addition, this allows you to specify which DNS server to use for a given realm such that the DNS might
actually be in a different realm with a different network interface.
This feature is available for SIP and MGCP only.
To configure realm-specific DNS in the ACLI:
dns-realm—Enter the name of the network interface that is configured for the DNS service you want to apply in
this realm. If you do not configure this parameter, then the realm will use the DNS information configured in its
associated network interface.
DoS ACL Configuration
If you are not using this functionality, you can leave the parameters at their default values: average-rate-limit, peakrate-limit, maximum-burst-size, access-control-trust-level, invalid-signal-threshold, and maximum-signal-threshold.
Enabling RTP-RTCP UDP Checksum Generation
You can configure the Oracle USM to generate a UDP checksum for RTP/ RTCP packets on a per-realm basis. This
feature is useful in cases where devices performing network address translation (NAT) do not pass through packets
with a zero checksum from the public Internet. These packets do not make it through the NAT, even if they have the
correct to and from IP address and UDP port information. When you enable this feature, the Oracle USM calculates a
checksum for these packets and thereby enables them to traverse a NAT successfully.
If you do not enable this feature, then the Oracle USM will not generate a checksum for RTP or RTCP packets if their
originator did not include one. If a checksum is already present when the traffic arrives at the hardware, the system
will relay it.
You enable this feature on the outbound realm.
Oracle® Communications Unified Session Manager
173
Realms and Nested Realms
Aggregate Session Constraints Per Realm
You can set session constraints for the Oracle USM’s global SIP configuration, specified session agents, and specified
SIP interfaces. This forces users who have a large group of remote agents to create a large number of session agents
and SIP interfaces.
With this feature implemented, however, you can group remote agents into one or more realms on which to apply
session constraints.
To enable sessions constraints on a per realm basis:
constraint-name—Enter the name of the constraint you want to use for this realm. You set up in the sessionconstraints confiuration.
UDP Checksum Generation Configuration
To enable UDP checksum generation for a realm:
generate-udp-checksum—Enable this parameter to generate a UDP checksum for this outbound realm. The default
is disabled. Valid values are:
•
enabled | disabled
Admission Control Configuration
You can set admission control based on bandwidth for each realm by setting the max-bandwidth parameter for the
realm configuration. Details about admission control are covered in this guide’s Admission Control and QoS chapter.
Reserved Parameters
In the ACLI, you do not need to configure the following parameters: max-latency, max-jitter, max-packet-loss, and
observ-window-size.
Nested Realms
Configuring nested realms allows you to create backbone VPN separation for signaling and media. This means that
you can put signaling and media on separate network interfaces, that the signaling and media VPN can have different
address spaces, and that the parent realm has one media-only sub-realm.
The following figure shows the network architecture.
174
Oracle® Communications Unified Session Manager
Realms and Nested Realms
In addition, you can achieve enhanced scalability by using a shared service interface. A single service address is
shared across many customers/peers, customer specific policies for bandwidth use and access control are preserved,
and you can achieve fine-grained policy control.
These benefits are achieved when you configure these types of realms:
•
•
•
•
•
Realm group—A hierarchical nesting of realms identified by the name of the highest order realm.
Controlling realm—A realms for which a signaling interface is configured. For example, you might configure
these signaling interfaces in the following configurations: SIP-NAT or SIP port. Typically, this is the highest order
realm for the parent realm in a realm group.
Parent realm—A realm that has one or more child realms. A parent realm might also be the child realm of another
realm group.
Child realm—A realm that is associated with a single higher order parent realm. A child might also be the parent
realm of another realm group. Child realms inherit all signaling and steering ports from higher order realms.
Media-only realm—A realm for which there is no configured signaling interface directly associated. Media-only
realms are nested within higher order realms.
As these definitions suggest, parent and child realms can be constructed so that there are multiple nesting levels.
Lower order realms inherit the traits of the realms above them, including: signaling service interfaces, session
translation tables, and steering pools.
Since realms inherit the traits of the realms above them in the hierarchy, you will probably want to map what realms
should be parents and children before you start configuring them. These relationships are constructed through one
parameter in the realm configuration that identifies the parent realm for the configuration. If you specify a parent
realm, then the realm you are configuring becomes a child realm subject to the configured parameters you have
Oracle® Communications Unified Session Manager
175
Realms and Nested Realms
established for that parent. And since parent realms can themselves be children of other realm, it is important that you
construct these relationships with care.
Configuring Nested Realms
When you are configuring nested realms, you can separate signaling and media by setting realm parameters in the SIP
interface configuration and the steering ports configuration.
•
•
The realm identifier you set in the SIP interface configuration labels the associated realm for signaling.
The realm identifier you set in the steering ports configuration labels the associated realm for media.
For MGCP, you set a special option that enables nested realm use.
Constructing a hierarchy of nested realms requires that you note which realms you want to handle signaling, and
which you want to handle media.
In the SIP port configuration for the SIP interface, you will find an allow anonymous parameter that allows you to set
certain access control measures. The table below outlines what each parameter means.
Allow Anonymous Parameter
Description
all
All anonymous connections allowed.
agents-only
Connections only allowed from configured session agents.
realm-prefix
Connections only allowed from addresses with the realm’s address prefix and
configured session agents.
registered
Connections allowed only from session agents and registered endpoints. (For SIP
only, a REGISTER is allowed for any endpoint.)
register-prefix
Connections allowed only from session agent and registered endpoints. (For SIP
only, a REGISTER is allowed for session agents and a matching realm prefix.)
Parent and Child Realm Configuration
To configure nested realms, you need to set parameters in the realm configuration.
To configure parent and child realms:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type media-manager and press Enter to access the system-level configuration elements.
176
Oracle® Communications Unified Session Manager
Realms and Nested Realms
ORACLE(configure)# media-manager
3. Type realm and press Enter. The system prompt changes to let you know that you can begin configuring individual
parameters.
ORACLE(media-manager)# realm-config
ORACLE(realm-config)#
4. parent-realm—Enter the identifier of the realm you want to name as the parent. Configuring this parameter makes
the realm you are currently configuring as the child of the parent you name. As such, the child realm is subject to
the configured parameters for the parent.
Aggregate Session Constraints Nested Realms
In addition to setting session constraints per realm for SIP sessions, you can also enable the Oracle USM to apply
session constraints across nested realms. When you set up session constraints for a realm, those constraints apply only
to the realm for which they are configured without consideration for its relationship either as parent or child to any
other realms.
You can also, however, enable the Oracle USM to take nested realms into consideration when applying constraints.
For example, if a call enters on a realm that has no constraints but its parent does, then the constraints for the parent
are applied. This parameter is global and so applies to all realms on the system. For the specific realm the call uses
and for all of its parents, the Oracle USM increments the counters upon successful completion of an inbound or
outbound call.
In the following example, you can see one parent realm and its multiple nested, child realms. Now consider applying
these realm constraints:
•
•
•
•
•
Parent Realm 1—55 active sessions
Child Realm 1—45 active sessions
Child Realm 2A—30 active sessions
Child Realm 2B—90 active sessions
Child Realm 3—20 active sessions
Given the realm constraints outlined above, consider these examples of how global session constraints for realms. For
example, a call enters the Oracle USM on Child Realm 2B, which has an unmet 90-session constraint set. Therefore,
the Oracle USM allows the call based on Child Realm 2B. But the call also has to be within the constraints set for
Child Realm 1 and Parent Realm 1. If the call fails to fall within the constraints for either of these two realms, then
the Oracle USM rejects the call.
Impact to Other Session Constraints and Emergency Calls
You can set up session constraints in different places in your Oracle USM configuration. Since session agents and SIP
interfaces also take session constraints, it is import to remember the order in which the Oracle USM applies them:
1. Session agent session constraints
2. Realm session constraints (including parent realms)
3. SIP interface session constraints
Oracle® Communications Unified Session Manager
177
Realms and Nested Realms
Emergency and priority calls for each of these is exempt from session constraints. That is, any call coming into the
Oracle USM marked priority is processed.
Session Contraints Configuration
You enabled use of session constraints for nested realms across the entire system by setting the nested-realms-stats
parameter in the session router configuration to enabled.
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
2. Type session-router and press Enter.
ORACLE(configure)# session-router
ORACLE(session-router)#
3. Type session-router and press Enter.
ORACLE(session-router)# session-router
ORACLE(session-router-config)#
4. nested-realms-stats—Change this parameter from disabled (default) to enabled if you want the Oracle USM to
apply session constraints across all nested realms (realms that are children to other realms)
5. Save and activate your configuration.
Realm-Based Packet Marking
The Oracle USM supports TOS/DiffServ functions that allow you to
•
•
Set up realm-based packet marking by media type, either audio-voice or video
Set up realm-based packet marking for signaling
Upstream devices use these markings to classify traffic in order to determine the priority level of treatment it will
receive.
About TOS DiffServ
TOS and DiffServ are two different mechanisms used to achieve QoS in enterprise and service provider networks;
they are two different ways of marking traffic to indicate its priority to upstream devices in the network.
For more information about TOS (packet) marking, refer to:
•
IETF RFC 1349 (http://www.ietf.org/rfc/rfc1349.txt)
For more information about DiffServ, refer to:
•
•
IETF RFC 2474 (http://www.ietf.org/rfc/rfc2474.txt)
IETF RFC 2475 (http://www.ietf.org/rfc/rfc2475.txt).
ToS Byte
The TOS byte format is as follows:
The TOS byte is broken down into three components:
•
•
178
Precedence—The most used component of the TOS byte, the precedence component is defined by three bits.
There are eight possible precedence values ranging from 000 (decimal 0) through 111 (decimal 7). Generally, a
precedence value of 000 refers to the lowest priority traffic, and a precedence value of 111 refers to the highest
priority traffic.
TOS—The TOS component is defined by four bits, although these bits are rarely used.
Oracle® Communications Unified Session Manager
Realms and Nested Realms
•
MBZ—The must be zero (MBZ) component of the TOS byte is never used.
DiffServ Byte
Given that the TOS byte was rarely used, the IETF redefined it and in doing so created the DiffServ byte.
The DiffServ byte format is as follows:
The DiffServ codepoint value is six bits long, compared to the three-bit-long TOS byte’s precedence component.
Given the increased bit length, DiffServ codepoints can range from 000000 (decimal 0) to 111111 (decimal 63).
Note: By default, DiffServ codepoint mappings map exactly to the precedence component priorities of the
original TOS byte specification.
Packet Marking for Media
You can set the TOS/DiffServ values that define an individual type or class of service for a given realm. In addition,
you can specify:
•
•
•
One or more audio media types for SIP
One or more video media types for SIP
Both audio and video media types for SIP
For all incoming SIP requests, the media type is determined by negotiation or by preferred codec. SIP media types are
determined by the SDP.
Configuring Packet Marking by Media Type
This section describes how to set up the media policy configuration that you need for this feature, and then how to
apply it to a realm.
These are the ACLI parameters that you set for the media policy:
name
media policy name
tos-settings list of TOS settings
This is the ACLI parameter that you set for the realm:
media-policy default media policy name
Packet Marking Configuration
To set up a media policy configuration to mark audio-voice or video packets:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type media-manager and press Enter to access the system-level configuration elements.
ORACLE(configure)# media-manager
3. Type media-policy and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(media-manager)# media-policy
ORACLE(media-policy)#
From this point, you can configure media policy parameters. To view all configuration parameters for media
profiles, enter a ? at the system prompt.
4. Type media-policy and press Enter.
ORACLE(media-manager)# media-policy
Oracle® Communications Unified Session Manager
179
Realms and Nested Realms
If you are adding support for this feature to a pre-existing configuration, then you must select (using the ACLI
select command) the configuration you want to edit.
5. name—Create a reference name for this policy and press Enter.
6. Type tos-settings and press Enter.
ORACLE(media-policy)# tos-settings
7. media-type—Enter the media type that you want to use for this group of TOS settings. You can enter any of the
IANA-defined media types for this value: audio, example, image, message, model, multipart, text, and video. This
value is not case-sensitive and can be up to 255 characters in length; it has no default.
ORACLE(tos-settings)# media-type message
8. media-sub-type—Enter the media sub-type you want to use for the media type. This value can be any of the subtypes that IANA defines for a specific media type. This value is not case-sensitive and can be up to 255 characters
in length; it has no default.
ORACLE(tos-settings)# media-sub-type sip
9. media-attributes—Enter the media attribute that will match in the SDP. This parameter is a list, so you can enter
more than one value. The values are case-sensitive and can be up to 255 characters in length. This parameter has
no default.
If you enter more than one media attribute value in the list, then you must enclose your entry in quotation marks
().
ORACLE(tos-settings)# media-attributes sendonly sendrecv
10. tos-value—Enter the TOS value you want applied for matching traffic. This value is a decimal or hexidecimal
value. The valid range is:
•
0x00 to 0xFF.
ORACLE(tos-settings)# tos-value 0xF0
11. Save and activate your configuration.
Applying a Media Policy to a Realm
To apply a media policy to a realm:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type media-manager and press Enter to access the system-level configuration elements.
ORACLE(configure)# media-manager
3. Type realm and press Enter. The system prompt changes to let you know that you can begin configuring individual
parameters.
ORACLE(media-manager)# realm
ORACLE(realm)#
4. media-policy—Enter the unique name of the media policy you want to apply to this realm.
Signaling Packet Marking Configuration
ToS marking for signaling requires you to configure a media policy and set the name of the media policy in the
appropriate realm configuration.
This section shows you how to configure packet marking for signaling.
Configuring a Media Policy for Signaling Packet Marking
To set up a media policy configuration to mark signaling packets:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
180
Oracle® Communications Unified Session Manager
Realms and Nested Realms
2. Type media-manager and press Enter to access the system-level configuration elements.
ORACLE(configure)# media-manager
3. Type media-policy and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(media-manager)# media-policy
ORACLE(media-policy)#
From this point, you can configure media policy parameters. To view all media policy configuration parameters,
enter a ? at the system prompt.
4. Type media-policy and press Enter.
ORACLE(media-manager)# media-policy
If you are adding support for this feature to a pre-existing configuration, then you must select (using the ACLI
select command) the configuration you want to edit.
5. name—Create a reference name for this policy and press Enter.
6. Type tos-settings and press Enter.
ORACLE(media-policy)# tos-settings
7. media-type—Enter the media type that you want to use for this group of TOS settings. You can enter any of the
IANA-defined media types for this value: audio, example, image, message, model, multipart, text, and video. This
value is not case-sensitive and can be up to 255 characters in length; it has no default.
ORACLE(tos-settings)# media-type message
8. media-sub-type—Enter the media sub-type you want to use for the media type. This value can be any of the subtypes that IANA defines for a specific media type. This value is not case-sensitive and can be up to 255 characters
in length; it has no default.
ORACLE(tos-settings)# media-sub-type sip
9. media-attributes—Enter the media attribute that will match in the SDP. This parameter is a list, so you can enter
more than one value. The values are case-sensitive and can be up to 255 characters in length. This parameter has
no default.
If you enter more than one media attribute value in the list, then you must enclose your entry in quotation marks
().
ORACLE(tos-settings)# media-attributes sendonly sendrecv
10. tos-value—Enter the TOS value you want applied for matching traffic. This value is a decimal or hexidecimal
value. The valid range is:
•
0x00 to 0xFF.
ORACLE(tos-settings)# tos-value 0xF0
11. Save and activate your configuration.
Applying a Media Policy to a Realm
To apply a media policy to a realm:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type media-manager and press Enter to access the system-level configuration elements.
ORACLE(configure)# media-manager
3. Type realm and press Enter. The system prompt changes to let you know that you can begin configuring individual
parameters.
ORACLE(media-manager)# realm
ORACLE(realm)#
4. media-policy—Enter the unique name of the media policy you want to apply to this realm.
Oracle® Communications Unified Session Manager
181
Realms and Nested Realms
Using Class Profile for Packet Marking
Class profile provides an additional means of ToS marking, but only for limited circumstances. Use class-profile only
if you are marking ToS on traffic destined for a specific To address, and when media-policy is not used on the same
realm. Using media-policy for ToS marking is, by far, more common.
To configure a class profile, you prepare your desired media policy, create the class profile referencing the media
policy and the To address, and set the name of the class profile in the appropriate realm configuration.
Class Profile and Class Policy Configuration
This section shows you how to configure packet marking using a class profile.
To configure the class profile and class policy:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter to access the system-level configuration elements.
ORACLE(configure)# session-router
3. Type class-profile and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(session-router)# class-profile
ORACLE(class-profile)#
4. Type policy and press Enter to begin configuring the class policy.
ORACLE(class-profile)# policy
From this point, you can configure class policy parameters. To view all class policy configuration parameters,
enter a ? at the system prompt.
5. profile-name—Enter the unique name of the class policy. When you apply a class profile to a realm configuration,
you use this value.
6. to-address—Enter a list of addresses to match to incoming traffic for marking. You can use E.164 addresses, a
host domain address, or use an asterisk (*) to set all host domain addresses.
7. media-policy—Enter the name of the media policy you want to apply to this class policy.
Applying a Class Policy to a Realm
To apply a class policy to a realm:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type media-manager and press Enter to access the system-level configuration elements.
ORACLE(configure)# media-manager
3. Type media-policy and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(media-manager)# realm
ORACLE(realm)#
4. class-profile—Enter the name if the class profile to apply to this realm. This is the name you set in the profilename parameter of the class-policy configuration.
Differentiated Services for DNS and ENUM
The Oracle USM can mark DNS/ENUM packets with a configurable differentiated services code point (DSCP).
Certain service providers mandate support for Differentiated Services (DS) on all traffic streams exiting any network
element. This mandate requires that network elements function as a DS marker — that is as a device that sets the
Distributed Services Codepoint (DSCP) in the Differentiated Services field of the IP header.
182
Oracle® Communications Unified Session Manager
Realms and Nested Realms
Previous software releases provided the capabilities to mark standard SIP and Real-Time Protocol (RTP) messages.
Release S-CX6.4.0M3 adds the capability to mark DNS and ENUM queries.
For basic information about DS, refer to:
•
•
•
The Net-Net S-CX6.4.0 4000 ACLI Configuration Guide (Realm-Based Packet Marking in Realms and Nested
Realms), which provides information on currently supported DS marking of SIP and RTP packets
IETF RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers (http://
www.ietf.org/rfc/rfc2474.txt)
IETF RFC 2475, An Architecture for Differentiated Services (http://www.ietf.org/rfc/rfc2475.txt).
DS provides a mechanism to define and deliver multiple and unique service classifications that can be offered by a
service provider. Specific service classifications are identified by a DSCP, essentially a numeric index. The DSCP
maps to a per-hop-behavior (PHB) that defines an associated service class. PHBs are generally defined in terms of
call admission controls, packet drop criteria, and queue admission algorithms. In theory, DS supports 64 distinct
classifications. In practice, however, network offerings generally consist of a much smaller suite, which typically
includes:
•
•
•
•
Default PHB - required best effort service — defined in RFC 2474
Expedited Forwarding (EF) PHB - low-loss, low-latency — defined in RFC 3246, An Expedited Forwarding PHB
Assured Forwarding (AF) PHB - assured delivery within subscriber limits — defined in RFC 2597, Assured
Forwarding PHB Group, and RFC 3260, New Terminology and Clarifications for Diffserv
Class Selector PHBs - maintain compatibility with previous TOS (type of service) precedence usage — defined in
RFC 2474
Marking of DNS and ENUM queries requires the creation of a Differentiated Services media policy, and the
assignment of such a policy to a specific realm.
Differentiated Services for DNS and ENUM Configuration
To create a Differentiated Services media policy:
1. From Superuser mode, use the following ACLI command sequence to move to media-policy configuration mode.
ORACLE# configure terminal
ORACLE(configure)# media-manager
ORACLE(media-manager)# media-policy
ORACLE(media-policy)#
2. Use the required name parameter to provide a unique identifier for this media-policy instance.
ORACLE(media-policy)# name diffServeDnsEnum
ORACLE(media-policy)#
3. Use the tos-settings command to move to tos-settings configuration mode.
ORACLE(media-policy)# tos-settings
ORACLE(tos-settings)#
4. Use the required media-type parameter to identify the packet-type subject to Diffentiated Services marking.
For DNS/ENUM packets, use message/dns.
ORACLE(tos-settings)# media-type message/dns
ORACLE(tos-settings)#
5. Use the required tos-value parameter to specify the 6-bit DSCP to be included in the Differentiated Services field
of the IP header.
Specify the DSCP as an integer (within the range from 0 to 63). The DSCP can be expressed in either decimal or
hexadecimal format.
ORACLE(tos-settings)# tos-value 0x30
ORACLE(tos-settings)#
6. Other displayed parameters, media-attributes and media-sub-type, can be safely ignored.
7. Use the done and exit commands to complete Differentiated Services media policy configuration and return to
media-policy configuration-mode.
Oracle® Communications Unified Session Manager
183
Realms and Nested Realms
ORACLE(tos-settings)# done
tos-settings
media-type
media-sub-type
tos-value
media-attributes
ORACLE(tos-settings)# exit
ORACLE(media-policy)#
message/dns
0x30
8. If necessary, repeat steps 2 through 7 to create additional Differentiated Services media policies.
9. Assign this media policy to the target realm via the media-policy parameter in a realm-config object.
SIP-SDP DCSP Marking ToS Bit Manipulation
Used to indicate priority and type of requested service to devices in the network, type of service (TOS) information is
included as a set of four-bit flags in the IP header. Each bit has a different purpose, and only one bit at a time can be
set: There can be no combinations. Available network services are:
•
•
•
•
Minimum delay—Used when latency is most important
Maximum throughput—Used when the volume of transmitted data in any period of time is important
Maximum reliability—Used when it is important to assure that data arrives at its destination without requiring
retransmission
Minimum cost—Used when it is most important to minimize data transmission costs
The Oracle USM’s support for type of service (TOS allows you to base classification on the media type as well as the
media subtype. In prior releases, you can configure the Oracle USM to mark TOS bits on outgoing packets using a
media policy. Supported media types include audio, video, application, data, image, text, and message; supported
protocol types are H.225, H.245, and SIP. Note that, although H.225 and H.245 are not part of any IANA types, they
are special cases (special subtypes) of message for the Oracle USM. When these criteria are met for an outgoing
packet, the Oracle USM applies the TOS settings to the IP header. The augmented application of TOS takes matching
on media type or protocol and expands it to match on media type, media-sub-type, and media attributes.
The new flexibility of this feature resolves issues when, for example, a customer needs to differentiate between TVphone and video streaming. While both TV-phone and video streaming have the attribute “media=video,” TV-phone
streaming has “direction=sendrcv” prioritized at a high level and video has direction=sendonly or recvonly with
middle level priority. The Oracle USM can provide the appropriate marking required to differentiate the types of
traffic.
In the media policy, the tos-values parameter accepts values that allow you to create any media type combination
allowed by IANA standards. This is a dynamic process because theOracle USM generates matching criteria directly
from messages.
The new configuration takes a media type value of any of these: audio, example, image, message, model, multipart,
text, and video. It also takes a media sub-type of any value specified for the media type by IANA; however, support
for T.38 must be entered exactly as t.38 (rather than t38). Using these values, the Oracle USM creates a value Based
on a combination of these values, the Oracle USM applies TOS settings.
You also configure the TOS value to be applied, and the media attributes you want to match.
You can have multiple groups of TOS settings for a media policy.
ToS Bit Manipulation Configuration
This section provides instructions for how to configure TOS bit manipulation on your Oracle USM.
To configure TOS bit manipulation:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type media-manager and press Enter.
184
Oracle® Communications Unified Session Manager
Realms and Nested Realms
ORACLE(configure)# media-manager
ORACLE(media-manager)#
3. Type media-policy and press Enter.
ORACLE(media-manager)# media-policy
If you are adding support for this feature to a pre-existing configuration, then you must select (using the ACLI
select command) the configuration you want to edit.
4. name—Create a reference name for this policy and press Enter.
5. Type tos-settings and press Enter.
ORACLE(media-policy)# tos-settings
6. media-type—Enter the media type that you want to use for this group of TOS settings. You can enter any of the
IANA-defined media types for this value: audio, example, image, message, model, multipart, text, and video. This
value is not case-sensitive and can be up to 255 characters in length; it has no default.
ORACLE(tos-settings)# media-type message
7. media-sub-type—Enter the media sub-type you want to use for the media type. This value can be any of the subtypes that IANA defines for a specific media type. This value is not case-sensitive and can be up to 255 characters
in length; it has no default.
ORACLE(tos-settings)# media-sub-type sip
8. media-attributes—Enter the media attribute that will match in the SDP. This parameter is a list, so you can enter
more than one value. The values are case-sensitive and can be up to 255 characters in length. This parameter has
no default.
If you enter more than one media attribute value in the list, then you must enclose your entry in quotation marks
().
ORACLE(tos-settings)# media-attributes sendonly sendrecv
9. tos-value—Enter the TOS value you want applied for matching traffic. This value is a decimal or hexidecimal
value. The valid range is:
•
0x00 to 0xFF.
ORACLE(tos-settings)# tos-value 0xF0
10. Save and activate your configuration.
DSCP Marking for MSRP and Media Over TCP
The Oracle USM supports Differentiated Services Code Point (DSCP) marking of MSRP and Media over TCP traffic.
This feature may be used for MSRP traffic in both B2BUA and non-B2BUA modes.
In order to configure the Oracle USM to mark MSRP or media over TCP packets with a value in the IP header's
DSCP field, create a media-manager > media-policy > tos-settings configuration element and set the media-type
parameter to message. This has the effect of marking all traffic described by prior SDP with m=message with this
DSCP value.
Note that setting media-type to message can potentially mark a large range of traffic. For other common traffic to
remain marked differently than marked MSRP, you need to create additional tos-settings configuration elements with
valid media-sub-type configurations. The following values may be provisioned in the media-sub-type parameter to
mark these other types of traffic differently (with an accompanying tos-value).
•
•
•
sip
li
dns
Oracle® Communications Unified Session Manager
185
Realms and Nested Realms
SDP Alternate Connectivity
The Oracle USM can create an egress-side SDP offer containing both IPv4 and IPv6 media addresses via a
mechanism which allows multiple IP addresses, of different address families (i.e., IPv4 & IPv6) in the same SDP
offer. Our implementation is based on the RFC draft "draft-boucadair-mmusic-altc-09".
Each realm on the Oracle USM can be configured with an alternate family realm on which to receive media in the alt
family realm parameter in the realm config. As deployed, one realm will be IPv4, and the alternate will be IPv6. The
Oracle USM creates the outbound INVITE with IPv4 and IPv6 addresses to accept the media, each in an a=altc: line
and each in its own realm. The IP addresses inserted into the a=altc: line are from the egress realm’s and alt-realmfamily realm’s steering pools. Observe in the image how the red lines indicate the complementary, alternate realms.
You can configure the order in which the a=altc: lines appear in the SDP in the pref-address-type parameter in the
realm-config. This parameter can be set to
•
•
•
IPv4 - SDP contains the IPv4 address first
IPv6 - SDP contains the IPv6 address first
NONE - SDP contains the native address family of the egress realm first
In the 200OK to the INVITE, the callee chooses either the IPv6 or IPv4 address to use for the call’s media transport
between itself and Oracle USM. After the Oracle USM receives the 200OK, the chosen flow is installed, and the
unused socket is discarded.
For two realms from different address families to share the same physical interface and vlan, you use a .4 or .6 tag in
the network-interface reference. When IPv4 and IPv6 realms share the same network-interface and VLAN, you
identify them by realm name and network-interface configured as:
•
•
IPv4 - <phy-interface>:<vlan>.4
IPv6 - <phy-interface>:<vlan>.6
IPv4 Network
IPv6 Network
network-interface
realm-config
steering-pool
name:M00
sub-port-id:100
ip-address:10.10.10.10
name:realm-out-4
network-interfaces:M00:100.4
alt-family-realm: realm-out-6
ip-address: 10.10.10.21
network-interface:M00:100.4
realm-id: realm-out-4
network-interface
realm-config
steering-pool
name:M00
sub-port-id:100
ip-address:2001:4860:4860::8888
name:realm-out-6
network-interfaces:M00:100.6
alt-family-realm: realm-out-4
ip-address: 2001:4860:4860::8889
network-interface:M00:100.6
realm-id: realm-out-6
If the INVITE’s egress realm is IPv6, pref-address-type = NONE, the outbound SDP has these a=altc: lines:
a=altc:1 IPv6 2001:4860:4860::8889 20001
a=altc:2 IPv4 10.10.10.21 20001
If the INVITE’s egress realm is IPv6, pref-address-type = IPv4, the outbound SDP has these a=altc: lines:
a=altc:1 IPv4 10.10.10.21 20001
a=altc:2 IPv6 2001:4860:4860::8889 20001
SDP Alternate connectivity supports B2B and hairpin call scenarios. SDP Alternate connectivity also supports
singleterm, B2B, and hairpin call scenarios.
When providing SDP alternate connectivity for SRTP traffic, in the security policy configuration element, the
network-interface parameter’s value must be configured with a .4 or .6 suffix to indicate IPv4 or IPv6 network,
respectively.
SDP Alternate Connectivity Configuration
To configure SDP alternate connectivity:
186
Oracle® Communications Unified Session Manager
Realms and Nested Realms
1. Access the realm-config configuration element.
ORACLE# configure terminal
ORACLE(configure)# media-manager
ORACLE(media-manager)# realm-config
ORACLE(realm-config)#
2. Select the realm-config object to edit.
ORACLE(realm-config)# select
identifier:
1: realm01 left-left:0 0.0.0.0
selection: 1
ORACLE(realm-config)#
3. alt-realm-family — Enter the realm name of the alternate realm, from which to use an IP address in the other
address family. If this parameter is within an IPv4 realm configuration, you will enter an IPv6 realm name.
4. pref-address-type — Set the order in which the a=altc: lines suggest preference. Valid values are:
• none — address family type of egress realm signaling
• ipv4 — IPv4 realm/address first
• ipv6 — IPv6 realm/address first
5. Type done to save your configuration.
Steering Pools
Steering pools define sets of ports that are used for steering media flows through the Oracle USM. These selected
ports are used to modify the SDP to cause receiving session agents to direct their media toward this system. Media
can be sent along the best quality path using these addresses and ports instead of traversing the shortest path or the
BGP-4 path.
For example, when the Oracle USM is communicating with a SIP device in a specific realm defined by a steering
pool, it uses the IP address and port number from the steering pool’s range of ports to direct the media. The port the
Oracle USM chooses to use is identified in the SDP part of the message.
Note: The values entered in the steering pool are used when the system provides NAT, PAT, and VLAN
translation.
Configuration Overview
To plan steering pool ranges, take into account the total sessions available on the box, determine how many ports
these sessions will use per media stream, and assign that number of ports to all of the steering pools on your Oracle
USM. For example, if your Oracle USM can accommodate 500 sessions and each session typically uses 2 ports, you
would assign 1000 ports to each steering pool. This strategy provides for a maximum number of ports for potential
use, without using extra resources on ports your Oracle USM will never use.
The following table lists the steering pool parameters you need to configure:
Parameter
Description
IP address
IPv4 address of the steering pool.
start port
Port number that begins the range of ports available to the steering pool.
You must define this port to enable the system to perform media steering
and NAT operations.
end port
Port number that ends the range of ports available to the steering pool.
You must define this port to enable the system to perform media steering
and NAT operations.
Oracle® Communications Unified Session Manager
187
Realms and Nested Realms
Parameter
Description
realm id
Identifies the steering pool’s realm. The steering pool is restricted to only
the flows that originate from this realm.
Note: The combination of entries for IP address, start port, and realm ID must be unique in each steering
pool. You cannot use the same values for multiple steering pools.
Each bidirectional media stream in a session uses two steering ports, one in each realm (with the exception of audio/
video calls that consume four ports). You can configure the start and end port values to provide admission control. If
all of the ports in all of the steering pools defined for a given realm are in use, no additional flows/sessions can be
established to/from the realm of the steering pool.
Steering Pool Configuration
To configure a steering pool:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type media-manager and press Enter to access the system-level configuration elements.
ORACLE(configure)# media-manager
3. Type steering-pool and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(media-manager)# steering-pool
ORACLE(steering-pool)#
4. ip-address—Enter the target IPv4 address of the steering pool in IP address format. For example:
192.168.0.11
5. start-port—Enter the start port value that begins the range of ports available to this steering pool. The default is 0.
The valid range is:
•
•
Minimum—0
Maximum—65535
You must enter a valid port number or the steering pool will not function properly.
6. end-port—Enter the end port value that ends the range of ports available to this steering pool. The default is 0. The
valid range is:
•
•
Minimum—0
Maximum—65535
You must enter a valid port number or the steering pool will not function properly.
7. realm-id—Enter the realm ID to identify the steering pool’s realm, following the name format. The value you
enter here must correspond to the value you entered as the identifier (name of the realm) when you configured the
realm. For example:
peer-1
This steering pool is restricted to flows that originate from this realm.
The following example shows the configuration of a steering pool that
steering-pool
ip-address
start-port
end-port
realm-id
last-modified-date
188
192.168.0.11
20000
21000
peer-1
2005-03-04 00:35:22
Oracle® Communications Unified Session Manager
Realms and Nested Realms
Multiple Interface Realms
The multi-interface realm feature lets you group multiple network interfaces to aggregate their bandwidth for media
flows. In effect, this feature lets you use the total throughput of the available physical interfaces on your Oracle USM
for a single realm. Multi-interface realms are implemented by creating multiple steering pools, each on an individual
network interface, that all reference a single realm.
Of course, you can not to use this feature and configure your Oracle USM to create a standard one-realm to onenetwork interface configuration.
Without using multiple interface realms, the basic hierarchical configuration of the Oracle USM from the physical
interface through the media steering pool looks like this:
In this model, one (non-channelized) network interface exists on a physical interface. One realm exists on one
network interface. One or more steering pools can exist on one realm. Within each higher level configuration element
exists a parameter that references a lower level configuration element in the Oracle USM’s logical network model.
The multi-interface realm feature directs media traffic entering and exiting multiple network interfaces in and out of a
single realm. Since all the steering pools belong to the same realm, their assigned network interfaces all feed into the
same realm as well. The following diagram shows the relationship in the new logical model:
Oracle® Communications Unified Session Manager
189
Realms and Nested Realms
The advantage of using multi-interface realms is the ability to aggregate the bandwidth available to multiple network
interfaces for a larger-than-previously-available total bandwidth for a realm. In the illustration below, three physical
interfaces each have X Kbps of bandwidth. The total bandwidth available to the realm with multiple network
interfaces is now 3X the bandwidth. (In practical usage, interface-1 only contributes X - VoIP Signaling to the total
media bandwidth available into the realm.)
Steering Pool Port Allocation
Every steering pool you create includes its own range of ports for media flows. The total number of ports in all the
steering pools that feed into one realm are available for calls in and out of the realm.
190
Oracle® Communications Unified Session Manager
Realms and Nested Realms
Steering pool ports for a given realm are assigned to media flows sequentially. When the first call enters the Oracle
USM after start-up, it is assigned the first ports on the first steering pool that you configured. New calls are assigned
to ports sequentially in the first steering pool. When all ports from the first steering pool are exhausted, the Oracle
USM uses ports from the next configured steering pool. This continues until the last port on the last configured
steering pool is used.
After the final port is used for the first time, the next port chosen is the one first returned as empty from the full list of
ports in all the steering pools. As media flows are terminated, the ports they used are returned to the realm’s full
steering pool. In this way, after initially exhausting all ports, the realm takes new, returned, ports from the pool in a
least last used manner.
When a call enters the Oracle USM, the signaling application allocates a port from all of the eligible steering pools
that will be used for the call. Once a port is chosen, the Oracle USM checks if the steering pool that the port is from
has a defined network interface. If it does, the call is set up on the corresponding network interface. If a network
interface is not defined for that steering pool, the network interface defined for the realm is used.
Network Interface Configuration
This section explains how to configure your Oracle USM to use multiple interface realms.
You must first configure multiple physical interfaces and multiple network interfaces on your Oracle USM.
To configure the realm configuration for multi-interface realms.
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type media-manager and press Enter to access the media-manager path.
ORACLE(configure)# media-manager
3. Type realm-config and press Enter. The system prompt changes.
ORACLE(media-manager)# realm-config
ORACLE(realm-config)#
From this point, you can configure a realm that will span multiple network interfaces.
4. network-interfaces—Enter the name of the network interface where the signaling traffic for this realm will be
received.
Creating Steering Pools for Multiple Interface Realms
To configure steering pools for multi-interface realms:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type media-manager and press Enter to access the media-manager path.
ORACLE(configure)# media-manager
3. Type steering-pool and press Enter. The system prompt changes.
ORACLE(media-manager)# steering-pool
ORACLE(steering-pool)#
From this point, you can configure steering pools which collectively bridge the multiple network interfaces they
are connected to.
4. ip-address—Enter the IP address of the first steering pool on the first network interface.
This IP address must correspond to an IP address within the subnet of a network interface you have already
configured.
This IP can not exist on a network interface other than the one you configure in the network-interface parameter.
5. start-port—Enter the beginning port number of the port range for this steering pool. The default is 0. The valid
range is:
Oracle® Communications Unified Session Manager
191
Realms and Nested Realms
• Minimum—0
• Maximum—65535
6. end-port—Enter the ending port number of the port range for this steering pool. The default is 0. The valid range
is:
• Minimum—0
• Maximum—65535
7. realm-id—Enter the name of the realm which this steering pool directs its media traffic toward.
8. network-interface—Enter the name of the network interface you want this steering pool to direct its media toward.
This parameter will match a name parameter in the network-interface configuration element. If you do not
configure this parameter, you can only assign a realm to a single network interface, as the behavior was in all
Oracle USM Software releases pre- 2.1.
9. Create additional steering pools on this and on other network interfaces as needed. Remember to type done when
you are finished configuring each new steering pool.
Media over TCP
The Oracle USM now supports RFC 4145 (TCP-Based Media Transport in the SDP), also called TCP Bearer support.
Media over TCP can be used to support applications that use TCP for bearer path transport.
RFC 4145 adds two new attributes, setup and connection, to SDP messages. The setup attribute indicates which end
of the TCP connection should initiate the connection. The connection attribute indicates whether an existing TCP
connection should be used or if a new TCP connection should be setup during re-negotiation. RFC 4145 follows the
offer/answer model specified in RFC3264. An example of the SDP offer message from the end point 192.0.2.2 as per
RFC4145 is as given below:
m=image 54111 TCP t38
c=IN IP4 192.0.2.2
a=setup:passive
a=connection:new
This offer message indicates the availability of t38 fax session at port 54111 which runs over TCP. Oracle USM does
not take an active part in the application-layer communication between each endpoint.
The Oracle USM provides the means to set up the end-to-end TCP flow by creating the TCP/IP path based on the
information learned in the SDP offer/answer process.
Note: SIP-interfaces configured as TCP with overlapping IP addresses using the same network-interface is
not supported for Session Replication for Recording (SRR). In other words, if multiple realms are configured
on a single network interface and Session Replication for Recording (SRR) is enabled on all the realms, there
is no support for multiple SIP-interfaces using TCP signaling on the same IP address.
TCP Bearer Conditions
The following conditions are applicable to the Oracle USM’s support of RFC 4145.
1. The Oracle USM can not provide media-over-TCP for HNT scenarios (endpoints behind a NAT).
2. When media is released into the network, the TCP packets do not traverse the Oracle USM because nNo TCP
bearer connection is created.
3. The Oracle USM does not inspect the setup and connection attributes in the SDP message since the TCP packets
transparently pass through the Oracle USM. These SDP attributes are forwarded to the other endpoint. It is the
other endpoint's responsibility to act accordingly.
4. After the Oracle USMreceives a SYN packet, it acts as a pure pass through for that TCP connection and ignores
all further TCP handshake messages including FIN and RST. The flow will only be torn down in the following
instances:
•
192
The TCP initial guard timer, TCP subsequent guard timer, or the TCP flow time limit timer expire for that
flow.
Oracle® Communications Unified Session Manager
Realms and Nested Realms
•
The whole SIP session is torn down.
TCP Port Selection
When a call is first set up, the Oracle USM inspects the SDP message's m-line to see if any media will be transported
via TCP. If the SDP message indicates that some content will use TCP, the Oracle USM allocates a configured
number of steering ports for the media-over-TCP traffic. These TCP media ports are taken from the each realm’s
steering pool.
Each endpoint can initiate up to four end-to-end TCP flows between itself and the other endpoint. The Oracle USM
assigns one port to receive the initial TCP packet (server port), and one to four ports assigned to send TCP traffic
(client ports) to the receiving side of the TCP flow. The number of TCP flows for each call is configured globally.
In order to configure the Oracle USM to facilitate and support this process, you need to specify the number of ports
per side of the call that can transport discrete TCP flows. You can configure one to four ports/flows. For configuration
purposes, the Oracle USM counts this number as inclusive of the server port. Therefore if you want the Oracle USM
to provide a maximum of one end-to-end TCP flow, you have to configure two TCP ports; one to receive, and one to
send. The receiving port (server) is reused to set up every flow, but the sending port (client) is discrete per flow. For
example: for 2 flows in each direction, set the configuration to 3 TCP ports per flow; for 3 flows in each direction, set
the configuration to 4 TCP ports per flow, etc.
The server port is used for initiating a new TCP connection. An endpoint sends the first packet to a server port on the
ingress interface. The packet is forwarded out of the Oracle USM through a client port on the egress interface toward
an endpoint:
The endpoint responds back to the client port on the egress interface. This message traverses the Oracle USM and is
forwarded out of the server port on the ingress interface where the initial packet was sent. The remainder of the TCP
flow uses the server and client port pair as a tunnel through the Oracle USM:
Oracle® Communications Unified Session Manager
193
Realms and Nested Realms
When the second TCP connection is set up in the same direction as in the first example, the first packet is still
received on the server port of the ingress interface. The next unused client port is chosen for the packet to exit the
Oracle USM:
The response takes the same path back to the caller. The remainder of the second TCP connection uses this
established path:
194
Oracle® Communications Unified Session Manager
Realms and Nested Realms
When the callee initiates a TCP connection, it must send its initial traffic to the server port on its Oracle USM ingress
interface. The packet is forwarded out of the first free client port on the egress side of this TCP connection toward the
caller.
The caller’s response takes the same path back to the callee that initiated this TCP connection. The remainder of the
third TCP connection uses this established path.
Oracle® Communications Unified Session Manager
195
Realms and Nested Realms
The Oracle USM can support a total of eight media-over-TCP connections per call. A maximum of 4 connections are
supported as initiated from each side of the call.
SDP Offer Example
The following abbreviated call flow diagram sets up a media-over-TCP flow. Observe that the caller listens for audio
over TCP on 172.16.0.10:10000, as described in the SDP offer (1). The Oracle USM re-writes the m and c lines in the
SDP offer to reflect that it is listening for audio over TCP on its egress interface at 192.168.0.1:10000 (3). The Oracle
USM then forwards the SIP invite to the callee.
The SIP callee responds with an SDP answer in a 200 OK message. The callee indicates it is listening for the audio
over TCP media on 192.168.0.10:10001 (6). The Oracle USM re-writes the m and c lines in the SDP answer to reflect
that it is listening for audio over TCP on the call's ingress interface at 172.16.0.1:10001 (7). The Oracle USM then
forwards the SIP invite to the caller.
196
Oracle® Communications Unified Session Manager
Realms and Nested Realms
All interfaces involved with the end-to-end TCP flow have now established their listening IP address and port pairs.
Timers
The Oracle USM has three guard timers that ensure a TCP media flow does not remain connected longer than
configured. You can set each of these from 0 (disabled) to 999999999 in seconds.
•
•
•
TCP initial guard timer — Sets the maximum time in seconds allowed to elapse between the initial SYN packet
and the next packet in this flow.
TCP subsequent guard timer — Sets the maximum time in seconds allowed to elapse between all subsequent
sequential TCP packets.
TCP flow time limit — Sets the maximum time that a single TCP flow can last. This does not refer to the entire
call.
TCP Port Configuration
To configure media over TCP:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type media-manager and press Enter to access the media-level configuration elements.
ORACLE(configure)# media-manager
ORACLE(media-manager)#
3. Type media-manager and press Enter to begin configuring media over TCP.
ORACLE(media-manager)# media-manager
ORACLE(media-manager-config)#
4. tcp-number-of-ports-per-flow—Enter the number of ports, inclusive of the server port, to use for media over TCP.
The total number of supported flows is this value minus one. The default is 2. The valid range is:
•
Minimum—2
Oracle® Communications Unified Session Manager
197
Realms and Nested Realms
•
Maximum—5
ORACLE(realm-config)# tcp-number-of-ports-per-flow 5
5. tcp-initial-guard-timer—Enter the maximum time in seconds allowed to elapse between the initial SYN packet
and the next packet in a media-over-TCP flow. The default is 300. The valid range is:
•
•
Minimum—0
Maximum—999999999
ORACLE(realm-config)# tcp-initial-guard-timer 300
6. tcp-subsq-guard-timer—Enter the maximum time in seconds allowed to elapse between all subsequent sequential
media-over-TPC packets. The default is 300.
•
•
Minimum—0
Maximum—999999999
ORACLE(realm-config)# tcp-subsq-guard-timer 300
7. tcp-flow-time-limit—Enter the maximum time in seconds that a media-over-TCP flow can last. The default is
86400. The valid range is:
•
•
Minimum—0
Maximum—999999999
ORACLE(realm-config)# tcp-flow-time-limit 86400
Restricted Media Latching
The restricted media latching feature lets the Oracle USM latch only to media from a known source IP address, in
order to learn and latch the dynamic UDP port number. The restricting IP address’s origin can be either the SDP
information or the SIP message’s Layer 3 (L3) IP address, depending on the configuration.
About Latching
Latching is when the Oracle USM listens for the first RTP packet from any source address/port for the destination
address/port of the Oracle USM. The destination address/port is allocated dynamically and sent in the SDP. After it
receives a RTP packet for that allocated destination address/port, the Oracle USM only allows subsequent RTP
packets from that same source address/port for that particular Oracle USM destination address/port. Latching does not
imply that the latched source address/port is used for the destination of the reverse direction RTP packet flow (it does
not imply the Oracle USM will perform symmetric RTP).
Restricted Latching
The Oracle USM restricts latching of RTP/RTCP media for all calls within a realm. It latches to media based on one
of the following:
•
•
SDP: the IP address and address range based on the received SDP c= connect address line in the offer and answer.
Layer 3: the IP address and address range based on the received L3 IP address of the offer or answer. This option
is for access registered HNT endpoints. If the L3 IP address is locally known and cached by the Oracle USM as
the public SIP contact address, that information could be used instead of waiting for a response. The Oracle USM
might use the L3 IP address restriction method for all calls regardless of whether the endpoint is behind a NAT or
not, for the same realms.
Symmetric Latching
A mode where a device’s source address/ports for the RTP/RTCP it sends to the Oracle USM (USM) that are latched,
are then used for the destination of RTP/RTCP sent to the device.
After allocating the media session in SIP, the USM sets the restriction mode and the restriction mask for the calling
side as well as for the called side. It sets the source address and address prefix bits in the flow. It also parses and loads
the source flow address into the MIBOCO messages. After receiving the calling SDP, the USM sets the source
198
Oracle® Communications Unified Session Manager
Realms and Nested Realms
address (address and address prefix) in the appropriate flow (the flow going from calling side to the called side). After
receiving the SDP from the called side, the USM sets the source address in the flow going from the called side to the
calling side.
The USM uses either the address provided in the SDP or the layer 3 signaling address for latching. You also configure
the USM to enable latching so that when it receives the source flow address, it sets the address and prefix in the NAT
flow. When the NAT entry is installed, all the values are set correctly. In addition, sipd sends the information for both
the incoming and outgoing flows. After receiving SDP from the called side sipd, the USM sends information for both
flows to the MBCD so that the correct NAT entries are installed.
Enabling restricted latching may make the USM wait for a SIP/SDP response before latching, if the answerer is in a
restricted latching realm. This is necessary because the USM does not usually know what to restrict latching to until
the media endpoint is reached. The only exception could be when the endpoint’s contact/IP is cached.
Relationship to Symmetric Latching
The current forced HNT symmetric latching feature lets the Oracle USM assume devices are behind NATs, regardless
of their signaled IP/SIP/SDP layer addresses. The Oracle USM latches on any received RTP destined for the specific
IP address/port of the Oracle USM for the call, and uses the latched source address/port for the reverse flow
destination information.
If both restricted latching and symmetric latching are enabled, the Oracle USM only latches if the source matches the
restriction, and the reverse flow will only go to the address/port latched to, and thus the reverse flow will only go to
an address of the same restriction.
•
Symmetric latching is enabled.
•
If symmetric latching is enabled, the Oracle USM sends the media in the opposite direction to the same IP and
port, after it latches to the source address of the media packet.
Symmetric latching is disabled.
If symmetric latching is disabled, the Oracle USM only latches the incoming source. The destination of the media
in the reverse direction is controlled by the SDP address.
Example 1
A typical example is when the Oracle USM performs HNT and non-HNT registration access for endpoints. Possibly
the SDP might not be correct, specifically if the device is behind a NAT. Therefore the Oracle USM needs to learn the
address for which to restrict the media latching, based on the L3 IP address. If the endpoint is not behind a NAT, then
the SDP could be used instead if preferred. However, one can make some assumptions that access-type cases will
require registration caching, and the cached fixed contact (the public FW address) could be used instead of waiting for
any SDP response.
Example 2
Another example is when a VoIP service is provided using symmetric-latching. A B2BUA/proxy sits between HNT
endpoints and the Oracle USM, and calls do not appear to be behind NATs from the Oracle USM’s perspective. The
Oracle USM’s primary role, other than securing softswitches and media gateways, is to provide symmetric latching so
that HNT media will work from the endpoints.
To ensure the Oracle USM’s latching mechanism is restricted to the media from the endpoints when the SIP Via and
Contact headers are the B2BUA/proxy addresses and not the endpoints’, the endpoint’s real (public) IP address in the
SDP of the offer/answer is used. The B2BUA/proxy corrects the c= line of SDP to that of the endpoints’ public FW
address.
The Oracle USM would then restrict the latching to the address in the SDP of the offer from the access realm (for
inbound calls) or the SDP answer (for outbound calls).
Restricted Latching Configuration
To configure restricted latching:
1. In Superuser mode, type configure terminal and press Enter.
Oracle® Communications Unified Session Manager
199
Realms and Nested Realms
ORACLE# configure terminal
2. Type media-manager and press Enter to access the media-level configuration elements.
ORACLE(configure)# media-manager
ORACLE(media-manager)#
3. Type realm-config and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(media-manager)# realm-config
ORACLE(realm-config)#
4. Select the realm where you want to apply this feature.
ORACLE(realm-config)# select
identifier:
1: Acme_Realm <none>
2: MGCP_Realm <none>
3: H323REALM <none>
selection:1
ORACLE(realm-config)#
0.0.0.0
0.0.0.0
0.0.0.0
5. restricted-latching— Enter the restricted latching mode. The default is none. The valid values are:
• none—No restricted-latching used
• sdp—Use the address provided in the SDP for latching
• peer-ip—Use the layer 3 signaling address for latching
6. restriction-mask— Enter the number of address bits you want used for the source latched address. This field will
be used only if the restricted-latching is used. The default is 32. When this value is used, the complete IP address
is matched for IPv4 addresses. The valid range is:
•
•
Minimum—1
Maximum—128
Media Release Across SIP Network Interfaces
This feature lets the Oracle USM release media between two SIP peers, between two realms on two network
interfaces of the same Oracle USM. Use this feature when you want the Oracle USM to release media for specific call
flows, regardless of the attached media topology.
Example
You can have two or more Oracle USMs with MGCP realms, performing MGCP signaling, media, and NATing to the
MGCP call agent. The call agent signals SIP to peers (Level 3) for off-net calls, always through a default Oracle USM
route. In many cases, the Oracle USM being used for SIP call routing (USM) is not the same Oracle USM where the
MGCP endpoint resides (USM1). In addition, a more direct media path exists between the MGCP-served Oracle
USM (USM1) and Level-3. The SDP provided by the Oracle USM MGCP ALG (USM1) is public and can be routed
to Level 3. However, the SIP default route Oracle USM (USM2) is also an MGCP ALG and cannot have global
media release. It must keep media management for MGCP.
SIP can also arrive from other Oracle USMs (or perhaps go out through them in the future). The Oracle USM must be
able to perform similar media release for SIP while managing media for MGCP or access SIP realms.
In the following diagram, the access realms for endpoints are currently MGCP, with the expectation they will be
migrated to SIP in the future.
200
Oracle® Communications Unified Session Manager
Realms and Nested Realms
Media Release Configuration
To configure media release across network interfaces:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type media-manager and press Enter to access the media-level configuration elements.
ORACLE(configure)# media-manager
ORACLE(media-manager)#
3. Type realm-config and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(media-manager)# realm-config
ORACLE(realm-config)#
4. Select the realm where you want to apply this feature.
ORACLE(realm-config)# select
identifier:
1: Acme_Realm <none>
2: MGCP_Realm <none>
3: H323REALM <none>
selection:1
ORACLE(realm-config)#
0.0.0.0
0.0.0.0
0.0.0.0
5. mm-in-system—Set this parameter to enabled to manage/latch/steer media in the Oracle USM. Set this parameter
to disabled to release media in the Oracle USM.
Oracle® Communications Unified Session Manager
201
Realms and Nested Realms
Note: Setting this parameter to disabled will cause the Oracle USM to NOT steer media through the
system (no media flowing through this Oracle USM).
The default is enabled. The valid values are:
•
enabled | disabled
Media Release Behind the Same IP Address
The media management behind the same IP feature lets the Oracle USM release media when two endpoints are
behind the same IP address, in the same realm. Using this feature prevents the media for intra-site calls from going
through the Oracle USM. You can use this feature for both hosted NAT traversal (HNT) and non-HNT clients. It
works with NATed endpoints and for non-NATed ones that are behind the same IP.
Additional Media Management Options
Additional media management options include:
•
•
•
Media directed between sources and destinations within this realm on this specific Oracle USM. Media travels
through the Oracle USM rather than straight between the endpoints.
Media directed through the Oracle USM between endpoints that are in different realms, but share the same subnet.
For SIP only, media released between multiple Oracle USMs.
To enable SIP distributed media release, you must set the appropriate parameter in the realm configuration. You
must also set the SIP options parameter to media-release with the appropriate header name and header parameter
information. This option defines how the Oracle USM encodes IPv4 address and port information for media
streams described by, for example, SDP.
Configuring Media Release Behind the Same IP Address
You need to configure both the mm-in-realm and mm-same-ip parameters for the realm:
•
•
If the mm-in-realm parameter is disabled, the mm-same-ip parameter is ignored.
If the mm-in-realm parameter is enabled and the mm-same-ip parameter is disabled, media will be managed in the
realm but released if the two endpoints are behind the same IP address.
To configure media management:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type media-manager and press Enter to access the media-related configurations.
ORACLE(configure)# media-manager
3. Type realm and press Enter. The system prompt changes to let you know that you can begin configuring individual
parameters.
ORACLE(media-manager)# realm-config
ORACLE(realm-config)#
From this point, you can configure realm parameters. To view all realm configuration parameters, enter a ? at the
system prompt.
4. mm-in-realm—Enable if you plan to use mm-same-ip. If this parameter is disabled, the mm-same-ip parameter is
ignored. If you set this to enabled and mm-same-ip to disabled, media is managed in the realm but released if the
two endpoints are behind the same IP address. The default is disabled. The valid values are:
• enabled | disabled
5. mm-same-ip—Enable if you want media to go through this Oracle USM, if mm-in-realm is enabled. When
disabled, the media will not go through the Oracle USM for endpoint that are behind the same IP. The default is
enabled. The valid values are:
202
Oracle® Communications Unified Session Manager
Realms and Nested Realms
•
enabled | disabled
Bandwidth CAC for Media Release
The bandwidth CAC for media release feature adds per-realm configuration that determines whether or not to include
inter-realm calls in bandwidth calculations. When you use this feature, the Oracle USM’s behavior is to count and
subtract bandwidth from the used bandwidth for a realm when a call within a single site has its media released. When
you do not enable this feature (and the Oracle USM’s previous behavior), the Oracle USM does not subtract the
amount of bandwidth.
In other words:
•
•
When you enable this feature, an inter-realm media-released call will decrement the maximum bandwidth allowed
in that realm with the bandwidth used for that call.
When you disable this feature (default behavior), and inter-realm media-released call will not decrement the
maximum bandwidth allowed for that call.
Bandwidth CAC Configuration
To enable bandwidth CAC for media release:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type media-manager and press Enter.
ORACLE(configure)# media-manager
ORACLE(media-manager)#
3. Type realm-config and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(media-manager)# realm-config
ORACLE(realm-config)#
4. Select the realm where you want to want to add this feature.
ORACLE(realm-config)# select
5. bw-cac-non-mm—Enable this parameter to turn on bandwidth CAC for media release. The default is disabled.
The valid values are:
• enabled | disabled
6. Save and activate your configuration.
Media Release between Endpoints with the Same IP Address
You can configure your Oracle USM to release media between two endpoints even when one of them:
•
•
Is directly addressable at the same IP address as a NAT device, but is not behind a NAT device
Is at the same IP address of a NAT device the other endpoint is behind
You enable this feature on a per-realm basis by setting an option in the realm configuration.
When this option is not set, theOracle USM will (when configured to do so) release media between two endpoints
sharing one NAT IP address in the same realm or network.
Media Release Configuration
In order for this feature to work properly, the following conditions apply for the realm configuration:
•
Either the mm-in-realm or the mm-in-network parameter must be disabled; you can have one of these enabled as
long as the other is not. The new option will apply to the parameter that is disabled.
Oracle® Communications Unified Session Manager
203
Realms and Nested Realms
•
If either the mm-in-realm or mm-in-network parameter is enabled, then the mm-same-ip parameter must be
disabled.
To enable media release between endpoints with the same IP address:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
2. Type media-manager and press Enter.
ORACLE(configure)# media-manager
ORACLE(media-manager)#
3. Type realm-config and press Enter.
ORACLE(media-manager)# realm-config
If you are adding support for this feature to a pre-existing realm, then you must select (using the ACLI select
command) the realm that you want to edit.
4. options—Set the options parameter by typing options, a Space, the option name release-media-at-same-nat with a
plus sign in front of it, and then press Enter.
ORACLE(realm-config)# options +release-media-at-same-nat
If you type the option without the plus sign, you will overwrite any previously configured options. In order to
append the new options to the realm configuration’s options list, you must prepend the new option with a plus sign
as shown in the previous example.
5. Save and activate your configuration.
Media Release Behind the Same NAT IP Address
You can now configure your Oracle USM to release media between endpoints sharing the same NAT IP address, even
if one endpoint is at—but not behind—the same NAT. This feature expands on the Oracle USM’S pre-existing ability
to release media between calling and called parties behind the same IP address/NAT device in the same realm or
network.
Media Release Configuration
For this feature to work properly, your realm configuration should either have the mm-in-realm or mm-in-network
parameter set to disabled, unless the mm-same-ip parameter is set to disabled. If the mm-same-ip parameter is
enabled, then mm-in-realm or mm-in-network can both be enabled.
To set the option that enables media release behind the same IP address:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
2. Type media-manager and press Enter.
ORACLE(configure)# media-manager
ORACLE(media-manager)#
3. Type realm-config and press Enter.
ORACLE(media-manager)# realm-config
ORACLE(realm-config)#
If you are adding support for this feature to a pre-existing realm, then you must select (using the ACLI select
command) the realm that you want to edit.
4. options—Set the options parameter by typing options, a Space, the option name release-media-at-same-nat with a
plus sign in front of it, and then press Enter.
ORACLE(realm-config)# options +release-media-at-same-nat
204
Oracle® Communications Unified Session Manager
Realms and Nested Realms
If you type the option without the plus sign, you will overwrite any previously configured options. In order to
append the new options to the realm configuration’s options list, you must prepend the new option with a plus sign
as shown in the previous example.
5. Save and activate your configuration.
Codec Reordering
Certain carriers deploy voice services where their peering partners do not use the carriers’ preferred codecs. The
Oracle USM can now reorder the codecs so that the preferred one is selected first.
Take the example of a carrier that deploys a voice service using G.729 rather than G.711. If that carrier has a peering
partner providing call origination for the VoIP customers with G.711 used as the preferred codec, there can be issues
with codec selection.
The Oracle USM resolves this issue by offering its codec reordering feature. Enabled for realms and session agents,
this feature gives the Oracle USM the ability to reorder the default codec in an SDP offer to the preferred codec
before it forwards the offer to the target endpoint. When you enable this feature, you increase the probability that the
target endpoint will choose the preferred codec for its SDP answer, thereby avoiding use of the undesired codec.
You enable codec reordering feature by setting the preferred-codec=X (where X is the preferred codec) option in the
realm and session agent configurations. You set it in the realm from which the Oracle USM receives SDP offers (in
requests or responses), and for which the media format list needs to be reordered by the Oracle USM prior to being
forwarded. To configure additional codec ordering support for cases when a response or request with an SDP offer is
from a session agent, you can set this option in the session agent configuration.
If you enable the option, the Oracle USM examines each SDP media description before if forwards an SDP offer. And
if necessary, it performs reordering of the media format list to designate that the preferred codec as the default.
The Oracle USM determines preferred codecs in the following ways:
•
•
•
If the response or request with an SDP offer is from a session agent, the Oracle USM determines the preferred
codec by referring to the session agent configuration. You set the preferred codec for a session agent by
configuring it with the preferred-codec=X option.
If the response or request with an SDP offer is not from a session agent or is from a session agent that does not
have the preferred-codec=X option configured, the Oracle USM determines the preferred codec by referring to the
preferred-codec=X option in the realm.
If the Oracle USM cannot determine a preferred codec, it does not perform codec reordering.
The way that the Oracle USM performs codec reordering is to search for the preferred codec in the SDP offer’s media
description (m=) line, and designate it as the default codec (if it is not the default already). After it marks the preferred
codec as the default, the Oracle USM does not perform any operation on the remaining codecs in the media format
list.
Note: that the Oracle USM performs codec reordering on the media format list only. If the rtpmap attribute of
the preferred codec is present, the Oracle USM does not reorder it.
Preferred Codec Precedence
When you configure preferred codecs in session agents or realms, be aware that the codec you set for a session agent
takes precedence over one you set for a realm. This means that if you set preferred codecs in both configurations, the
one you set for the session agent will be used.
In the case where the Oracle USM does not find the session agent’s preferred codec in the SDP offer’s media format
list, then it does not perform codec reordering even if the media format list contains the realm’s preferred codec.
Codec Reordering Configuration
When you configure codec ordering, the codec you set in either the session agent or realm configuration must match
the name of a media profile configuration. If your configuration does not use media profiles, then the name of the
preferred codec that you set must be one of the following:
Oracle® Communications Unified Session Manager
205
Realms and Nested Realms
•
•
•
•
•
•
•
PCMU
G726-32
G723
PCMA
G722
G728
G729
Note: If you configure this feature for a session agent, you must configure it for the associated realm as
well. Otherwise, the feature will not work correctly.
Setting a Preferred Codec for a Realm
To set a preferred codec for a realm configuration:
These instructions assume that you want to add this feature to a realm that has already been configured.
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type media-manager and press Enter.
ORACLE(configure)# media-manager
ORACLE(media-manager)#
3. Type realm-config and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(media-manager)# realm-config
ORACLE(realm-config)#
4. Select the realm where you want to apply this feature.
ORACLE(realm-config)# select
identifier:
1: public
media2:0
2: private
media1:0
selection:1
ORACLE(realm-config)#
0.0.0.0
0.0.0.0
5. options—Set the options parameter by typing options, a Space, the option name preceded by a plus sign (+)
(preferred-codec=X), and then press Enter. X is the codec that you want to set as the preferred codec.
ORACLE(realm-config)# options +preferred-codec=PCMU
If you type options preferred-codec=X, you will overwrite any previously configured options. In order to append
the new option to the realm-config’s options list, you must prepend the new option with a plus sign as shown in
the previous example.
6. Save and activate your configuration.
Setting a Preferred Codec for a Session Agent
To set a preferred codec for a session agent configuration:
These instructions assume that you want to add this feature to a session agent that has already been configured.
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter.
ORACLE(configure)# session-router
ORACLE(session-router)#
3. Type session-agent and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
206
Oracle® Communications Unified Session Manager
Realms and Nested Realms
ORACLE(session-router)# session-agent
ORACLE(session-agent)#
4. Select the session agent where you want to apply this feature.
ORACLE(session-agent)# select
<hostname>:
1: acmepacket.com realm=
ip=
2: sessionAgent2 realm=tester ip=172.30.1.150
selection:
selection:1
ORACLE(session-agent)#
5. options—Set the options parameter by typing options, a Space, the option name preceded by a plus sign (+)
(preferred-codec=X), and then press Enter. X is the codec that you want to set as the preferred codec.
ORACLE(session-agent)# options +preferred-codec=PCMU
If you type options preferred-codec=X, you will overwrite any previously configured options. In order to append
the new option to the session agent’s options list, you must prepend the new option with a plus sign as shown in
the previous example.
6. Save and activate your configuration.
Media Profiles Per Realm
For different codecs and media types, you can set up customized media profiles that serve the following purposes:
•
•
Police media values
Define media bandwidth policies
You can use media policies globally for the Oracle USM, or you can configure them for application on a per-realm
basis. For a realm, you can configure a list of media profiles you want applied. The Oracle USMmatches the value
you set for the match-media-profiles parameter, and then applies those media profiles to the realm itself and to all of
its child realms (but not to its parent realms).
Note: This feature has no impact on the ways the Oracle USM uses media profiles non-realm applications
such as: SIP interfaces, session agents, codec policies, and policy attributes.
Call Admission Control and Policing
The Oracle USM supports call admission control (CAC) based on realm, and it applies the limits on either ingress or
egress bandwidth counters. If a calls exceeds bandwidth on either the ingress or egress side, the Oracle USM rejects
the call. You can also use per-user CAC, which limits the maximum bandwidth from the east and west flows for both
the TO and FROM users.
When you apply media profiles to a realm, the Oracle USM applies bandwidth policing from the flow’s ingress realm
media profile. In the diagram below, the Oracle USM policies traffic for Realm A based Realm A’s policing values,
and the same is true for Realm B.
Oracle® Communications Unified Session Manager
207
Realms and Nested Realms
Media Profile Configuration
This section shows you how to configure multiple media profiles per realm, and it explains how to use wildcarding.
To reference a media profile in this list, you need to enter its name and subname values in the following format
<name>::<subname>. Releases C6.1.0 and later accept the subname so you can configure multiple media profile for
the same codec; the codec name customarily serves and the name value for a media profile configuration.
About Wildcarding
You can wildcard both portions (name and subname) of this value:
•
•
When you wildcard the name portion of the value, you can provide a specific subname that the Oracle USM uses
to find matching media profiles.
When you wildcard the subname portion of the value, you can provide a specific name that the Oracle USM uses
to find matching media profiles.
You can also enter the name value on its own, or wildcard the entire value. Leaving the subname value empty is also
significant in that it allows the realm to use all media profile that have no specified subname. However, you cannot
leave the name portion of the value unspecified (as all media profiles are required to have names).
Consider the examples in the following table:
Syntax
Example Value
Description
<name>
PCMU
Matches any and all media profiles with the name value
configured as PCMU. This entry has the same meaning as a
value with this syntax: <name>::*.
<name>::
PCMU::
Matches a media profile with the name with the name value
configured as PCMU with an empty subname parameter.
<name>::<subname>
PCMU::64k
Matches a media profiles with the name with the name value
configured as PCMU with the subname parameter set to 64k.
*
*
Matches anything, but does not have to be a defined media
profile.
*::*
*::*
Matches any and all media profiles, but requires the presence
of media profile configurations.
*::<subname>
*::64k
Matches all media profiles with this subname. You might have
a group of media profiles with different names, but the same
subname value.
*::
*::
Matches any media profiles with an empty subname parameter.
::
::
Invalid
::*
::*
Invalid
The Oracle USM performs matching for wildcarded match-media-profiles values last. Specific entries are applies first
and take precedence. When the Oracle USM must decide between media profiles matches, it selects the first match.
To use media profiles for a realm:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
2. Type media-manager and press Enter.
ORACLE(configure)# media-manager
ORACLE(media-manager)#
208
Oracle® Communications Unified Session Manager
Realms and Nested Realms
3. Type realm-config and press Enter. If you are adding this feature to a pre-existing realm configuration, you will
need to select and edit your realm.
ORACLE(media-manager)# realm-config
ORACLE(realm-config)#
4. match-media-profiles—In the form <name>::<subname>, enter the media profiles you would like applied to this
realm. These values correspond to the name and subname parameters in the media profile configuration. You can
wildcard either of these portions of the value, or you can leave the <subname> portion empty.
This parameter has no default.
5. Save and activate your configuration.
Multiple Media Profiles
You can use the media profiles configuration to set up:
•
•
One media profile for a particular SIP SDP encoding (such as G729), where the name of the profile identifies it
uniquely. This behavior is your only option in Oracle USM release prior to Release C6.1.0.
Multiple media profiles for the same SIP SDP encoding. Available in Release C6.1.0 and forward, you can create
multiple media profiles for the same encoding. To do so, you add a subname to the configuration, thereby
identifying it uniquely using two pieces of information rather than one.
The sections below provide two descriptions of deployments where using multiple profiles for the same codec would
solve codec and packetization problems for service providers.
Use Case 1
Service Provider 1 peers with various carriers, each of which uses different packetization rates for the same codec.
For example, their Peer 1 uses 10 milliseconds G.711 whereas their Peer 2 uses 30 milliseconds for the same codec.
The difference in rates produces a difference in bandwidth consumption—resulting in a difference in SLA agreements
and in Oracle USM call admission control (CAC) and bandwidth policing. Service Provider 1 uses the Oracle USM’s
media profile configuration parameters to determine CAC (req-bandwidth) and bandwidth policing (avg-rate-limit).
Because this service provider’s peers either do not use the SDP p-time attribute or use it inconsistently, it is difficult to
account for bandwidth use. And so it is likewise difficult to set up meaningful media profiles.
The best solution for this service provider—given its traffic engineering and desire for the cleanest routing and
provisioning structures possible—is to define multiple media profiles for the same codec.
Use Case 2
Service Provider 2 supports H.263 video, for which the Oracle USM offers a pre-provisioned media profile with a set
bandwidth value. And yet, H.263 is not a codec that has a single bandwidth value. Instead, H.263 can have different
bandwidth values that correspond to various screen resolution and quality. While it is true that the Oracle USMcan
learn the requisite bandwidth value from SDP, not all SDP carries the bandwidth value nor do system operators
always trust the values communicated.
Configuring multiple media profiles for the same codec (here, H.263) helps considerably with this problem—and
moves closer to complete solution. Service Provider 2 can configure H.263 media profiles capable of handling the
different bandwidth values that might appear.
Multiple Media Profiles Configuration
Configuring the subname parameter in the media profiles configuration allows you to create multiple media profiles
with the same name.
To configure the subname parameter for a media profile:
1. In Superuser mode, type configure terminal and press Enter.
Oracle® Communications Unified Session Manager
209
Realms and Nested Realms
ORACLE# configure terminal
ORACLE(configure)#
2. Type session-router and press Enter.
ORACLE(configure)# session-router
ORACLE(session-router)#
3. Type media-profile and press Enter. If you are adding this feature to a pre-existing media profile configuration,
you will need to select and edit your media profile.
ORACLE(session-router)# media-profile
ORACLE(media-profile)#
4. subname—Enter the subname value for this media profile. Information such as the rate or bandwidth value make
convenient subname values. For example, you might set the name of the media profile as PCMU and the subname
as 64k.
This parameter is not require and has no default.
5. Save and activate your configuration.
SIP Disable Media Inactivity Timer for Calls Placed on Hold
Hardware-based media flow guard timers detect when a call has lost media while it is being relayed through the
Oracle USM. In response, the system tears down the call.
You can configure disable-guard-timer-sendonly to disable media inactivity timers for calls placed on hold. The
Oracle USM disableds initial and subsequent guard timers for media when the SIP or IWF call is put on hold with a
0.0.0.0 address in:
•
•
•
The c=connection line
An a=inactive attribute
An a=sendonly attribute
It should be noted that disabling the media inactivity timers will also disable the guard timers for calls which are not
necessarily on hold, but simply are one-way audio applications.
No license requirements to enable this feature.
Media Inactivity Timer Configuration
To disable the media inactivity timer for calls placed on hold:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
2. Type media-manager and press Enter.
ORACLE(configure)# media-manager
ORACLE(media-manager)#
3. Type media-manager-config and press Enter.
ORACLE(media-manager)# media-manager-config
ORACLE(media-manager-config)#
4. options—Set the options parameter by typing options, a Space, the option-name disable-guard-timer-sendonly
with a plus sign in front of it, and then press Enter.
ORACLE(media-manager-config)# options +disable-guard-timer-sendonly
If you type the option without the plus sign, you will overwrite any previously configured options. In order to
append the new options to the SIP interface configuration’s options list, you must prepend the new option with a
plus sign as shown in the previous example.
5. Save and activate your configuration.
210
Oracle® Communications Unified Session Manager
Realms and Nested Realms
Peer-to-Peer MSRP TCP Stitching
The Oracle USM supports peer-to-peer TCP connections for peers behind NATs, enabling Message Session Relay
Protocol (MSRP) client to communicate with one another. More specifically, the Oracle USM can:
•
•
•
•
Establish incoming TCP connections with each endpoint participating in the MSRP session using a 3-way
handshake. The Oracle USM receives incoming SYNs on the local address and port provided in the SDP offer and
answer to each endpoint.
Stitch together the two TCP connections internally after successful establishment of both connections. This
capability is used when the caller and the callee initiate TCP SYNs towards one another via the Oracle USM; the
stitching makes both clients think they are talking to a server. To achieve this end, the Oracle USM caches SYNs
from both sides so it can modify the SYN packets to SYN-Acks with the correct sequence and Ack numbers.
Note, though this case is rare, that if a user is behind a NAT offers a=passive, then this feature cannot function
properly.
Relay MSRP stream between the endpoints.
Police bandwidth for MSRP streams based on a defined media profile for MSRP.
Oracle® Communications Unified Session Manager
211
5
Oracle USM Supporting the IMS Core
General Description
The Oracle USM functions in an IMS core. It communicates with the HSS to obtain Authorization, Authentication, SCSCF assignment, and ultimately routing instructions. To accomplish these functions, the Oracle USM can perform
the SIP registrar role in conjunction with an HSS.
Message Authentication for SIP Requests
The Oracle USM authenticates requests by configuring the sip authentication profile configuration element. The name
of this configuration element is either configured as a parameter in the sip registrar configuration element’s
authentication profile parameter or in the sip interface configuration element’s sip-authentication-profile parameter.
This means that the Oracle USM can perform SIP digest authentication either globally, per domain of the Request
URI or as received on a SIP interface.
After naming a sip authentication profile, the received methods that trigger digest authentication are configured in the
methods parameter. You can also define which anonymous endpoints are subject to authentication based on the
request method they send to the Oracle USM by configuring in the anonymous-methods parameter. Consider the
following three scenarios:
•
•
•
By configuring the methods parameter with REGISTER and leaving the anonymous-methods parameter blank, the
Oracle USM authenticates only REGISTER request messages, all other requests are unauthenticated.
By configuring the methods parameter with REGISTER and INVITE, and leaving the anonymous-methods
parameter blank, the Oracle USM authenticates all REGISTER and INVITE request messages from both
registered and anonymous endpoints, all other requests are unauthenticated.
By configuring the methods parameter with REGISTER and configuring the anonymous-methods parameter with
INVITE, the Oracle USM authenticates REGISTER request messages from all endpoints, while INVITES are
only authenticated from anonymous endpoints.
User Authorization
In an IMS network, the Oracle USM requests user authorization from an HSS when receiving a REGISTER message.
An HSS is defined on the Oracle USM by creating a home subscriber server configuration element that includes a
name, ip address, port, and realm as its basic defining data.
Oracle® Communications Unified Session Manager
213
Oracle USM Supporting the IMS Core
UAR/UAA Transaction
Before requesting authentication information, the Oracle USM sends a User Authorization Request (UAR) to the HSS
for the registering endpoint to determine if this user is allowed to receive service. The Oracle USM populates the
UAR’s AVPs as follows:
•
•
•
•
Public-User-Identity—the SIP AOR of the registering endpoint
Visited-Network-Identity—the value of the network-id parameter from the ingress sip-interface.
Private-User-Identity—the username from the SIP authorization header, if it is present. If not, this value is the
public User ID.
User-Authorization-Type—always set to REGISTRATION_AND_CAPABILITIES (2)
The Oracle USM expects the UAA to be either:
•
•
DIAMETER_FIRST_REGISTRATION
DIAMETER_SUBSEQUENT_REGISTRATION
Any of these responses result in the continued processing of the registering endpoint. Any other result code results in
an error and a 403 returned to the registering UA (often referred to as a UE). The next step is the authentication and
request for the H(A1) hash.
SIP Digest User Authentication
Authentication via MAR/MAA
To authenticate the registering user, the Oracle USM needs a digest realm, QoP, and the H(A1) hash. It requests these
from a server, usually the HSS, by sending it a Multimedia Auth Request (MAR) message. The MAR’s AVPs are
populated with:
•
•
•
•
•
•
Public-User-Identity—the SIP AOR of the endpoint being registered (same as UAR)
Private-User-Identity—the username from the SIP authorization header or the SIP AOR if the AOR for PUID
parameter is enabled. (Same as UAR)
SIP-Number-Auth-Items—always set to 1
SIP-Auth-Data-Item -> SIP-Item-Number—always set to 1
SIP-Auth-Data-Item -> SIP-Authentication-Scheme—always set to SIP_DIGEST
Server-Name—the home-server-route parameter in the sip registrar configuration element. It is the URI
(containing FQDN or IP address) used to identify and route to this Oracle USM.
The Oracle USM expects the MAA to include a SIP-Auth-Data-Item VSA, which includes digest realm, QoP and
H(A1) information as defined in RFC2617. The information is cached for subsequent requests. Any result code
received from the HSS other than DIAMETER_SUCCESS results in a 403 error response returned for the original
request.
The MAR/MAA transaction is conducted with the server defined in the credential retrieval config parameter found in
the sip-authentication profile configuration element. This parameter is populated with the name of a home-subscriberserver configuration element.
SIP Authentication Challenge
When the Oracle USM receives a response from the HSS including the hash value for the user, it sends a SIP
authentication challenge to the endpoint, if the endpoint did not provide any authentication headers in its initial
contact the with Oracle USM. If the endpoint is registering, the Oracle USM replies with a 401 Unauthorized message
with the following WWW-Authenticate header:
WWW-Authenticate: Digest realm="atlanta.com", domain="sip:boxesbybob.com",
qop="auth", nonce="f84f1cec41e6cbe5aea9c8e88d359", opaque="", stale=FALSE,
algorithm=MD5
214
Oracle® Communications Unified Session Manager
Oracle USM Supporting the IMS Core
If the endpoint initiates any other request to the Oracle USM besides REGISTER, the Oracle USM replies with a 407
Proxy Authentication Required message with the following Proxy-Authenticate header:
Proxy-Authenticate: Digest realm="atlanta.com", qop="auth",
nonce="f84f1cec41e6cbe5aea9c8e88d359", opaque="", stale=FALSE, algorithm=MD5
Authentication Header Elements
•
•
•
•
•
•
Domain—A quoted, space-separated list of URIs that defines the protection space. This is an optional parameter
for the "WWW-Authenticate" header.
Nonce—A unique string generated each time a 401/407 response is sent.
Qop—A mandatory parameter that is populated with a value of "auth" indicating authentication.
Opaque—A string of data, specified by the Oracle USM which should be returned by the client unchanged in the
Authorization header of subsequent requests with URIs in the same protection space.
Stale—A flag indicating that the previous request from the client was rejected because the nonce value was stale.
This is set to true by the SD when it receives an invalid nonce but a valid digest for that nonce.
Algorithm—The Oracle USM always sends a value of "MD5"
SIP Authentication Response
After receiving the 401/407 message from the Oracle USM, the UA resubmits its original request with an
Authorization: header including its own internally generated MD5 hash.
Oracle USM Authentication Check
At this point, the Oracle USM has received an MD5 hash from the HSS and an MD5 hash from the UA. The Oracle
USM compares the two values and if they are identical, the endpoint is successfully authenticated. Failure to match
the two hash values results in a 403 or 503 sent to the authenticating endpoint.
The following image shows the User Authorization and Authentication process:
Note: Diagram information states "USM/CSM" when the applicable content applies to both the Oracle USM
and the Oracle CSM.
The Oracle USM acts as a SIP Registrar and updates an HSS with the state of its registrants.
Oracle® Communications Unified Session Manager
215
Oracle USM Supporting the IMS Core
IMS-AKA Support
The Oracle USM also supports IMS-AKA for secure authentication end-to-end between UAs in an LTE network and
an IMS core. It supports IMS-AKA in compliance with 3GPP specifications TS 33-203 and TS 33-102.
The goal of IMS-AKA is to achieve mutual authentication between end station termination mechanisms, such as an IP
Multimedia Services Identity Module (ISIM), and the Home Network (IMS Core). Achieving this goal requires
procedures both inside and outside the core. Ultimately, IMS performs the following:
•
•
•
Uses the IMPI to authenticate the home network as well as the UA;
Manages authorization and authentication information between the HSS and the UA;
Enables subsequent authentication via authentication vectors and sequence information at the ISIM and the HSS.
The Oracle USM authenticates registrations only. This registration authentication process is similar to SIP Digest. The
process accepts REGISTER requests from UAs, conducts authorization procedures via UAR/UAA exchanges and
conducts authentication procedures via MAR/MAA exchanges and challenges with the UA.
Configuration and operational support are not the same on the Oracle USM and Oracle CSM. This is because the
Oracle USM can perform the P-CSCF role as well as the I-CSCF and S-CSCF roles. Applicable configuration to
support IMS-AKA on the P-CSCF access interface is documented in the Security chapter of the Oracle
Communications Session Border Controller ACLI Configuration Guide. This configuration includes defining an IMSAKA profile, enabling the sip-interface for IMS-AKA and configuring the sip-port to use the profile.
There is no configuration required for the S-CSCF role, but there is an optional configuration that specifies how may
authentication vectors it can accept from the HSS. The S-CSCF stores these authentication vectors for use during
subsequent authentications. Storing vectors limits the number of times the device needs to retrieve them from the
HSS. The default number of authentication vectors is three.
Authentication Sequence - Registration
UAs get service from an IMS core after registering at least one IMPU. To become registered, the UA sends
REGISTER requests to the IMS core, which then attempts to authenticate the UA.
The first device to receive the REGISTER at the core is a P-CSCF, such as the Oracle USM. For the Oracle USM,
appropriate configuration determines that it uses IMS-AKA as the authentication mechanism on the access interface.
For an Oracle CSM, the presence and state of the “integrity-protected” parameter in the Authorization header of a
REGISTER triggers the use of IMS-AKA. If the value of this parameter is either “yes” or "no", IMS-AKA is invoked.
If the parameter is not present, or it is set to any other value, the Oracle USM falls back to SIP Digest authentication.
To proceed with IMS-AKA authentication, the P-CSCF engages in S-CSCF selection procedures via the I-CSCF to
identify the target S-CSCF. Having identified the S-CSCF (your Oracle USM), the I-CSCF forwards the REGISTER
to it. The I-CSCF next engages in standard UAR and MAR procedures. For IMS-AKA deployments, the HSS follows
procedures defined in TS 33-203 to create authentication vectors for the UA. The HSS provides the vectors to the SCSCF, which then proceeds with authentication procedures defined in TS 33-203.
After processing, the S-CSCF uses authentication vectors to challenge the UA. The UA uses the information in this
challenge to, first, authenticate the Home Network. Having confirmed the network, the UA then prepares and sends
its authentication information back towards the S-CSCF. The S-CSCF is then responsible for authenticating the UA.
The S-CSCF sends a 200OK back to the UA upon successful authentication, allowing the UA to get service from the
HN.
The Oracle USM caches the AOR’s registration and stores authentication vectors for subsequent authentications,
thereby minimizing the work required by the HSS.
The overall sequence is depicted below.
216
Oracle® Communications Unified Session Manager
Oracle USM Supporting the IMS Core
Outside the Core
LTE networks include UAs that have an IP Multimedia Service Identity Module (ISIM) or equivalent. ISIMs are
configured with a long-term key used to authenticate and calculate cipher keys, as well as IP Multimedia Private and
Public Identities (IMPI and IMPU). The ISIM serves as the means of authenticating the home network to the UA. The
UA, in turn, sends information based on it’s ISIM configuration to the home network, which can then authenticate the
UA.
Establishment of Security Associations (SAs) to and from the UA are the responsibility of the P-CSCF. The P-CSCF
should also be capable of managing the processes when the UA is behind a NAT.
Note: Within the context of IMS-AKA, only traffic between the P-CSCF and the UA is encrypted.
Authentication Success
When using IMS-AKA, successful registration of a UA consists of registering at least one IMPU and the IMPI
authenticated within IMS. The UA begins this process by sending it REGISTER request to the P-CSCF properly
specifying IMS-AKA authentication. IMS then performs standard procedures to identify the appropriate S-CSCF.
Upon receipt of the REGISTER, the S-CSCF checks for the presence of an authentication vector. If it is present the SCSCF issues the authentication challenge; if not, it requests authentication vector(s) from the HSS. Note that the
Oracle USM allows you to request multiple authentication vectors via configuration. The HSS provides the following
components within an authentication vector:
•
•
•
•
•
RAND—random number
XRES—expected response
CK—cipher key
IK—integrity key
AUTN—authentication token
The MAR provided to the S-CSCF differ from that of SIP digest authentication requests as follows:
Oracle® Communications Unified Session Manager
217
Oracle USM Supporting the IMS Core
•
•
The SIP-Number-Auth-Items AVP specifies the number of authentication vectors, which is equal to the homesubscriber-server's num-auth-vectors setting.
The SIP-Authentication-Scheme AVP specifies the authentication scheme, Digest-AKAv1-MD5.
At this point, the Oracle USM can send the authentication challenge to the UA. If multiple authentication vectors
were provided by the HSS, the Oracle USM can independently authenticate the UA until the pool is exhausted. The SCSCF stores the RAND it sends to the UA to resolve future synchronization errors, if any. No authentication vector
can be used more than once. This is validated by the ISIM, using a sequence number (SQN).
When a P-CSCF receives an authentication challenge, it removes and stores the CK and the IK. The P-CSCF forward
the rest of the information to the UA.
The UA is responsible for verifying the home network. Having received the AUTN from the P-CSCF, the UA derives
MAC and SQN values. Verifying both of these, the UA next generates a response including a shared secret and the
RAND received in the challenge. The UA also computes the CK and IK.
Upon receipt of this response, IMS provides the message to the S-CSCF, which determines that the XRES is correct.
If so, it registers the IPMU and, via IMS sends the 200 OK back to the UA.
Authentication Failure
Either the UA or IMS can deny authentication via IMS-AKA. In the case of the UA, this is considered a network
failure; in the case of IMS there would be a user authentication failure.
Network Authentication Failure
The UA determines that the HN has failed authentication, it sends a REGISTER request with an empty authorization
header parameter and no authentication token for synchronization (AUTS). This indicates that the MAC parameter
was invalid as determined by the UA. In this case, the S-CSCF sends a 403 Forbidden message back to the UA.
User Authentication Failure
IMS-AKA determines user authentication failure as either:
•
•
IK incorrect—If the REGISTER includes a bad IK, the P-CSCF detects this and discards the packet at the IPSEC
layer. In this case, the REGISTER never reaches the S-CSCF.
XRES incorrect—In this case, the REGISTER reaches the S-CSCF. The S-CSCF detects the incorrect XRES, the
S-CSCF sends a 4xxx Auth_Failure message back to the UA via IMS.
Synchronization
Synchronization refers to authentication procedures when the (REFRESH TIMING) is found to be stale. This is not
an authentication failure.
The UA may send an AUTS in response to the challenge, indicating that the authentication vector sequence is "outof-range". Upon receipt of the AUTS, the S-CSCF sends a new authorization vector request to the HSS. The HSS
checks the AUTS and, if appropriate sends a new set of authentication vectors back the the S-CSCF. Next the S-CSCF
sends 401 Unauthorized back to the UA. Assuming the UA still wants to register, this would trigger a new registration
procedure.
Optional IMS-AKA Configuration
The following configuration enables the Oracle USM to specify, on a per-HSS basis, the number of authentication
vectors it can download per MAR. Making this setting is not required as it has a valid default entry (3).
home subscriber server
To configure the number of authentication vectors to download from a home subscriber server (HSS):
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter to access the session router path.
218
Oracle® Communications Unified Session Manager
Oracle USM Supporting the IMS Core
ORACLE(configure)# session-router
3. Type home-subscriber-server and press Enter. The system prompt changes to let you know that you can begin
configuring individual parameters.
ORACLE(session-router)# home-subscriber-server
ORACLE(home-subscriber-server)#
4. Select—If already configured, choose the home subscriber server for which you want to set the number of
authentication vectors.
5. num-auth-vector— [1-10] 3 default - The number of authentication vectors downloaded from HSS per MAR.
The range is from 1-10 with 3 as the default.
6. Type done when finished.
Oracle USM as Registrar
Creating a sip registrar configuration element enables the Oracle USM to act as a SIP registrar. When registration
functionality is enabled, the Oracle USM actually registers endpoints rather than only caching and forwarding
registrations to another device. Oracle USM registry services are enabled globally per domain, not on individual SIP
interfaces or other remote logical entities.
On receiving a REGISTER message, the Oracle USM checks if it is responsible for the domain contained in the
Request-URI as defined by the domains parameter and finds the corresponding sip registrar configuration. This is a
global parameter—all messages are checked against all sip registrar domains. Thus you could create one sip registrar
configuration element to handle all .com domains and one sip registrar configuration element to handle all .org
domains. The Oracle USM begins registrar functions for all requests that match the configured domain per sipregistrar configuration element.
A UA is considered registered once a SAA assignment is received from the HSS, after which the Oracle USM sends a
200 OK message back to the registering UA.
New Registration
The following image shows a simplified call flow for a registering user:
Releasing Unregistered Users
When a call arrives at an Oracle USM either to or from a user that is not registered at that Oracle USM, it performs a
location query with the HSS to determine if the unknown UE is registered at another S-CSCF. If there is no
registration, the Oracle USM takes ownership of the UE. The system stores information about these UEs in its
registration cache, labelled "NEVER REGISTERED". Barring any further, related action within the infrastructure, the
UE would remain homed to the Oracle USM. Upon expiry of this feature's timer, the Oracle USM sends an SAR to
the HSS, providing an assignment type of ADMINISTRATIVE_DEREGISTRATION for the UE. This allows the UE
Oracle® Communications Unified Session Manager
219
Oracle USM Supporting the IMS Core
to be a user at a different S-CSCF the next time it is a call sender or receiver. A common use case for this scenario is a
roaming UE.
When the Oracle USM issues the SAR, it also marks the UE as 'dirty' (in the process of being de-assigned) to
accommodate the following operational scenarios:
•
•
•
The UE attempts to register—The Oracle USM rejects the register, replying with a 504 error message.
The UE has existing calls—The Oracle USM continues to support the call, based on a stored copy of the service
profile.
A new call arrives—The Oracle USM rejects the call. The Oracle USM replies with a '480, Temporarily
Unavailable' error message if the UE is the callee; the Oracle USM responds with a 504 if the UE is the caller.
The user can configure the unreg-cache-expiry parameter in seconds on a per-registrar basis. This syntax is shown
below.
ORACLE(sip-registrar)# unreg-cache-expiry 120
The parameter accepts values in the range of 0 to 604800, with 0 specifying that the Oracle USM does not cache
unregistered users. A setting of 0 means the Oracle USM takes ownership, downloads service profiles, and then
releases the user after the call without caching.
Handling Public Service Identities (PSIs)
Public Service Identities (PSI) appear as unregistered users in the Oracle USM. PSIs appear as either Distinct PSIs or
Wildcarded PSIs. Similar to unregistered users, the Oracle USM takes ownership of the PSI if it is unassigned and a
call is made to or from it. By default, PSIs are not released. However, the user can configure the psi-cache-expiry
option in seconds on a per-registrar basis to cause the Oracle USM to release PSIs. This syntax is shown below.
ORACLE(sip-registrar)# options psi-cache-expiry=120
Limiting AOR Contacts
The Oracle USM allows you to limit the number of contacts that apply to AORs. If the Oracle USM receives a
registration request that exceeds the maximum that you configured, it responds with a local response, a 403 Forbidden
by default, and does not register the additional contact. The system only rejects registration requests that exceed the
maximum. Existing contacts persist normally.
The system checks against the maximum in the following circumstances:
•
•
•
•
•
A new registration is received
The location-update-interval expires
A call-id changes (and the forward-reg-callid-change option is enabled)
A registrar message sequence number has skipped a number
There is any change to the contact list
If the number of contacts in the initial registration exceeds the maximum, the Oracle USM rejects the entire
registration. In addition, if you configure this feature while the system is operational, your setting only applies to new
registrations.
You configure these maximums on a per-registrar basis. The value ranges from 0-256. The feature is RTC supported.
HSS Server Assignment
As the Oracle USM registers UAs, it requests to assign itself as the S-CSCF for the registering AoR. The Oracle
USM’s S-CSCF identity is configured in the home-server-route parameter in sip-registrar configuration element. This
is a entered as a SIP URI (containing FQDN or IP address) and is used to identify and route messages to this Oracle
USM on behalf of the registered user.
220
Oracle® Communications Unified Session Manager
Oracle USM Supporting the IMS Core
Server Assignment Messages
The Oracle USM sends a Server Assignment Request (SAR) to the HSS requesting to confirm the SIP or SIPS URI of
the SIP server that is currently serving the user. The SAR message also serves the purpose of requesting that the
Diameter server send the user profile to the SIP server. The SAR's AVPs are populated as follows:
•
•
•
•
Public-User-Identity—the SIP AOR of the endpoint being registered (same as UAR)
Private-User-Identity—the username from the SIP authorization header, if it is present. If not, this value is the
public User ID. (Same as UAR)
Server-Name—the home server route parameter in the sip-registrar configuration element. It is the FQDN or IP
address used to identify and route to this Oracle USM sent as a URI.
Server-Assignment-Type—the value of this attribute depends upon the registration state:
•
•
•
REGISTRATION (1)—for all new and refreshing registrations.
Set to TIMEOUT_DEREGISTRATION (4)—when the contact is unregistered due to expiration. This occurs if
the force-unregistration option is configured in the sip config.
• USER_DEREGISTRATION (5)—when the contact is unregistered by the user (contact parameter expires=0).
User-Data-Already-Available—always set to USER_DATA_ALREADY_AVAILABLE (1)
Server-Assignment-Response
The Oracle USM expects a DIAMETER_SUCCESS code in the SAA to indicate that the assignment was successful.
Then a 200 OK response is returned to the registering user. Any other Diameter result code is an error and results in
an error response for the original REGISTER request (by default 503) and the contacts to be invalidated in the
registration cache.
Register Refresh
When a UA sends a register refresh, the Oracle USM first confirms that the authentication exists for that UE’s
registration cache entry, and then is valid for the REGISTER refresh. (If a valid hash does not exist for that AoR, then
the Oracle USM sends an MAR to the HSS to retrieve authentication data once again).
Next, the Oracle USM determines if the it can perform a local REGSITER refresh or if the HSS needs to be updated.
If any of the following 3 conditions exists for the re-registering UA, the Oracle USM updates the HSS:
•
•
•
The location update interval timer has expired—This value, configured in the sip registrar configuration element
ensures that HSS database always has the correct Oracle USM address by periodically sending SARs for each
registered contact.
The message’s call-id changes while the forward-reg-callid-change option in the sip config configuration element
is set. This covers the case where the UA changes the Oracle USMs through which it attaches to the network.
The REGISTER message’s Cseq has skipped a number. This covers the case in which a user registered with
Oracle USM1, moves to Oracle USM2 , and then returns to Oracle USM1.
If the Oracle USM updates the HSS database because of matching one of the above conditions, the access side
expiration timer per contact is reset to the REGISTER message’s Expires: header value, and returned in the 200 OK.
This happens even in the case when the reREGISTER was received in the first half of the previous Expires period. In
addition, the core-side location update interval timer are refreshed on both active and standby.
When the above three conditions are not met, the registration expiration proceeds normally.
If the timer has not exceeded half of its lifetime, a 200 OK is returned to the UA. If the timer has exceeded half of its
lifetime, the Oracle USM just refreshes the access-side expiration timer; the registration cache expiration timer for
that AoR begins its count again.
Oracle® Communications Unified Session Manager
221
Oracle USM Supporting the IMS Core
Core-side SAR Lifetime
The Oracle USM maintains a timer for user registrations per SAR on the core side as specified above. The core-side
SAR lifetime timer is configured in the location update interval parameter in the sip registrar configuration element.
This timer ensures that the HSS always has the correct Oracle USM address, by sending SAR messages periodically.
Entry Unregistration
Because AoRs and not contacts are referenced by the HSS, an AoR is valid and should not be removed from HSS
until all associated contacts have been removed or expired. If all the contacts are removed for an AoR by receiving
REGISTER messages with Expires:0 header, then the SAR sent to the HSS includes Server-Assignment-Type of
USER_DEREGISTRATION (5).
When the force-unregister option in the sip config is enabled, then the HSS is explicitly updated when all of the
contacts for an AoR have expired. This event prompts the Oracle USM to send a SAR to the HSS using the ServerAssignment-Type of TIMEOUT_DEREGISTRATION (4).
The HSS can send a Registration-Termination-Request to request removing a registration, which corresponds to
entries in the Oracle USM’s registration cache. When an RTR is received, the following AVPs are expected:
•
•
•
Private-User-Identity—Username of the user, which is being de-registered.
Associated-Identities—The Private-Id's in the same subscription which need to be de-registered. (optional)
Public-Identity—One or more public-Id's of the user being de-registered. (optional)
For the AoR specified by the Private-User-Identity AVP, all associated contacts are removed in the registration cache.
The Oracle USM sends a Registration Termination Answer to the HSS to indicate success.
User Registration based on Reg-ID and Instance-ID (RFC
5626)
Sometimes a user’s device reregisters from a different network than its original registration. This event should be
considered a location update rather that a completely new registration for the Contact. The Oracle USM can perform
this way by considering the endpoint’s reg-id and instance-id parameters defined in RFC 5626.
The Oracle USM identifies new REGISTER requests received on a different access network as a location update of
the existing binding between the Contact and AoR. Without this feature, the Oracle USM would create a new binding
and leave the old binding untouched in the local registration cache/ENUM database. This scenario is undesirable and
leads to unnecessary load on various network elements including the Oracle USM itself.
The following conditions must be matched to equate a newly registering contact as a location update:
For a received REGISTER:
222
Oracle® Communications Unified Session Manager
Oracle USM Supporting the IMS Core
•
•
•
•
The message must not have more than 1 Contact header while 1 of those Contact headers includes a reg-id
parameter. (failure to pass this condition prompts the Oracle USM to reply to the requester with a 400 Bad
Request).
The Supported: header contains outbound value
The Contact header contains a reg-id parameter
The Contact header contains a +sip.instance parameter
After these steps are affirmed, the Oracle USM determines if it is the First hop. If there is only one Via: header in the
REGISTER, the Oracle USM determines it is the first hop and continues to perform Outbound Registration Binding
processing.
If there is more than 1 Via: header in the REGISTER message, the Oracle USM performs additional validation by
checking that a Path: header corresponding to the last Via: includes an ob URI parameter, Outbound Registration
Binding may continue.
If the Oracle USM is neither the first hop nor finds an ob URI in Path headers, it replies to the UA’s REGISTER with
a 439 First Hop Lack Outbound Support reply.
reREGISTER Example
The user (AoR) bob@example.com registers from a device +sip.instance= <urn:uuid:0001> with a reg-id ="1",
contact URI = sip:1.1.1.1:5060. A binding is be created for bob@example.com+<urn:uuid:0001>+reg-id=1 at sip:
1.1.1.1.:5060.
Next, Bob@example.com sends a reREGISTER with the same instance-id but with a different reg-id = 2 and contact
URI = sip:2.2.2.2:5060.
The previous binding is removed. A binding for the new contact URI and reg-id is created. bob@example.com
+<urn:uuid:0001>+reg-id=2 at sip:2.2.2.2:5060
Outbound Registration Binding Processing
An outbound registration binding is created between the AoR, instance-id, reg-id, Contact URI, and other contact
parameters. This binding also stores the Path: header.
Matching re-registrations update the local registration cache as expected. REGISTER messages are replied to
including a Require: header containing the outbound option-tag.
If the Oracle USM receives requests for the same AOR with some registrations with reg-id + instance-id and some
without them, the Oracle USM will store them both as separate Contacts for the AOR; The AoR+sip.instance+reg-id
combination becomes the key to this entry.
Wildcarded PUID Support
The Oracle USM supports the use of wildcarded Public User IDs (PUIDs), typically for registering multiple endpoints
on a PBX with a single PUID. A wildcard is composed of a regular expression that, when used in a PUID prefix,
represents multiple UEs. The group of UEs is referred to as an implicit registration set and share a single service
profile. This support is typically implemented to reduce HSS resource requirements. The regular expressions
themselves are in form of Perl Compatible Extended Regular Expressions (PCRE).
Each implicit registration set is associated with an explicitly registered distinct PUID. Typically, this distinct PUID is
the PBX itself. The implicit registration set is dependent on the distinct PUID, including the distinct PUID’s
registration status.
There is no Oracle USM configuration required.
Wildcarded PUID support is applicable to both I-CSCF and S-CSCF operation. In addition, all Oracle USMs in the
applicable data paths must be in the same trust domain.
To allow the feature, the Oracle USM supports:
•
Wildcarded PUID AVP in the LIR, SAR and SAA
Oracle® Communications Unified Session Manager
223
Oracle USM Supporting the IMS Core
•
•
User Profile AVP in the SAA
P-Profile-Key across the Mw interface, as defined in RFC 5002
Note also that the HSS must support the wildcarded-public-Identify AVP.
ACLI Instructions
The following configuration enables the Oracle USM to authorize and authenticate registering users. In addition it
sets the Oracle USM to request itself as the S-CSCF for the registering users.
home subscriber server
To configure a home subscriber server (HSS):
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter to access the session router path.
ORACLE(configure)# session-router
3. Type home-subscriber-server and press Enter. The system prompt changes to let you know that you can begin
configuring individual parameters.
ORACLE(session-router)# home-subscriber-server
ORACLE(home-subscriber-server)#
4. name—Enter the name for this home subscriber server configuration element to reference from other
configuration elements.
5. state—Set this to enabled to use this configuration element.
6. address—Enter the IP address of this HSS. Both IPv4 and IPv6 addressing is supported.
7. port—Enter the port which to connect on of this HSS, the default value is 80.
8. realm—Enter the realm name where this HSS exists.
9. Type done when finished.
SIP Authentication Profile
To configure the SIP Authentication Profile:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter to access the session router path.
ORACLE(configure)# session-router
3. Type sip-authentication-profile and press Enter. The system prompt changes to let you know that you can begin
configuring individual parameters.
ORACLE(session-router)# sip-authentication-profile
ORACLE(sip-authentication-profile)#
4.
5.
6.
7.
8.
224
You may now begin configuring the SIP Authentication Profile configuration element.
name—Enter the name of this SIP authentication profile that will be referenced from a SIP registrar (or a SIP
interface) configuration element.
methods—Enter all the methods that should be authenticated. Enclose multiple methods in quotes and separated
by commas.
anonymous-methods—Enter the methods from anonymous users that require authentication. Enclose multiple
methods in quotes and separated by commas.
digest-realm—Leave this blank for Cx deployments.
credential-retrieval-method—Enter CX.
Oracle® Communications Unified Session Manager
Oracle USM Supporting the IMS Core
9. credential-retrieval-config—Enter the home-subscriber-server name used for retrieving authentication data.
10. Type done when finished.
SIP Interface
The full SIP interface should be configured according to your network needs. Please refer to the Oracle SBC ACLI
Configuration Guide.
To configure a SIP Digest Authentication on a specific SIP Interface:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter to access the session router path.
ORACLE(configure)# session-router
3. Type sip-interface and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(session-router)# sip-interface
ORACLE(sip-interface)#
4. Type select and choose the number of the pre-configured sip interface you want to configure.
ORACLE(sip-interface)# select
<realm-id>:
1: private 192.168.101.17:5060
2: public 172.16.101.17:5060
selection: 1
5. registration-caching—Set this parameter to enabled.
6. ims-access—Set this parameter to enabled for access interfaces, when applicable. Core interfaces should have this
feature disabled.
7. sip-authentication-profile—Set this to the name of an existing sip-authentication profile if you wish to authenticate
per SIP interface.
8. Type done when finished.
SIP Registrar
To configure the Oracle USM to act as a SIP Registrar:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter to access the session router path.
ORACLE(configure)# session-router
3. Type sip-registrar and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(session-router)# sip-registrar
ORACLE(sip-registrar)#
4. name—Enter a name for this SIP registrar configuration element.
5. state—Set this to enabled to use this SIP registrar configuration element.
6. domains—Enter one or more domains that this configuration element will invoke SIP registration for. Wildcards
are valid for this parameter. Multiple entries can be entered in quotes, separated by commas.
7. subscriber-database-method—Set this to CX.
8. subscriber-database-config—Enter the home-subscriber-server configuration element name that will handle
REGISTER messages for this domain. The HSS configuration element includes the actual IP address of the server
that SAR’s are sent to.
Oracle® Communications Unified Session Manager
225
Oracle USM Supporting the IMS Core
9. authentication-profile—Enter a sip-authentication-profile configuration element’s name. The sip authentication
profile object referenced here will be looked up for a REGISTER message with a matching domain in the request
URI. You may also leave this blank for the receiving SIP Interface to handle which messages require
authentication if so configured.
10. home-server-route—Enter the identification for this Oracle USM that will be sent as the Server-Name in MAR
and SAR messages to the HSS. This value should be entered as a SIP URI.
11. location-update-interval—Keep or change from the default of 1400 minutes (1 day). This value is used as the
timer lifetime for core-side HSS updates.
12. Type done when finished.
Maximum Number of Contacts
To configure a sip-registrar with a maximum of 10 contacts per AOR:
1. From superuser mode, use the following command sequence to access sip-registrar element.
ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# sip-registrar
ORACLE(sip-registrar)# select
Select the registrar you want to configure.
2. Specify the number of contacts.
AORACLE(sip-registrar)# max-contacts-per-aor 10
AORACLE(sip-registrar)# done
Response to Exceeding Maximum Contacts
To configure local response for the Oracle USM to issue when max-contacts-per-aor is exceeded:
1. From superuser mode, use the following command sequence to access local-response and add an entry.
ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# local-response-map
2. Access the entries configuration.
ORACLE(local-response-map)# entries
3. Specify the local error you need to configure.
ORACLE(local-response-map-entry)# local-error contacts-per-aor-exceed
4. Specify the sip-reason for this error.
ORACLE(local-response-map-entry)# sip-reason forbidden
5. Specify the error code for this error.
ORACLE(local-response-map-entry)# sip-status 403
ORACLE(local-response-map-entry)# done
local-response-map-entry
local-error
contacts-per-aor-exceed
sip-status
403
q850-cause
0
sip-reason
forbidden
q850-reason
method
register-response-expires
ORACLE(local-response-map-entry)# exit
226
Oracle® Communications Unified Session Manager
Oracle USM Supporting the IMS Core
SIP Registration Event Package Support
The Oracle USM supports UA subscriptions to the registration event package, as defined in RFC3680. As such, it
maintains contact with entities, often application servers, that need to know about UA registration events and provides
those application servers with notifications when registration events occur.
Common usage for this functionality includes:
•
•
Forcing re-authentication
The provision of welcome notices to users who need information or instructions customized to their location
An operational example, shown below, begins with the Oracle USM performing 3rd party registration on behalf of a
UA to an AS, based on the iFC request from the UA. The AS, being an appropriately authorized UA itself, subscribes
to NOTIFY messages on reg events for the initial UA. The Oracle USM sends a 200OK to the AS, and then proceeds
to forward NOTIFY messages about that UE’s registration events to the AS.
This feature is relevant when the Oracle USM is performing S-CSCF functions. You enable this feature on the Oracle
USM per registrar, by simply creating a profile and applying it to the applicable registrar.
SUBSCRIBE Processing
When the Oracle USM has the reg-event notification function enabled for a registrar, it includes the allow-events
header in its 200OK replies to successful REGISTERS. This lets UEs know that they can subscribe to registration
event packages.
When the Oracle USM receives reg-event subscription requests, it follows the sequence below to process
SUBSCRIBE requests for reg events:
1. Determines validity of the request.
Subscriptions cannot include more than one package name. If there is more than one package name in the request,
the Oracle USM replies with a 400 Bad Request message.
2. Determines if it can be a notifier, as follows:
•
•
The SUBSCRIBE must include EVENT=reg.
The requesting UA must be in the same domain as the registrar.
If both of the above are true, the Oracle USM proceeds with the request.
3. Authorizes the request. The Oracle USM only authorizes requests from UEs that come from the same realm and
layer 2 connection on which it received the initial REGISTER.
Furthermore, the Oracle USM only authorizes the following UEs:
•
•
Public user identities from UEs that are subscribing to their own registration events.
Public user identities that this user owns. Examples include implicitly registered public user identities.
Oracle® Communications Unified Session Manager
227
Oracle USM Supporting the IMS Core
•
•
Entities that were included in the PATH header of the target UE’s registration.
All ASs that are listed in the UE’s iFC and that are part of the trust domain.
If all of the above are true, the Oracle USM proceeds with the request. If not, it sends 403 Forbidden to the
requester.
4. Determines how it is functionally related to the UA. The Oracle USM only processes subscriptions for users in its
registration cache, replying with a 403 Forbidden if not. For cached users, the Oracle USM forwards the request to
the registrar if it is the P-CSCF. If it is the S-CSCF, it sends a 200 OK and begins to act as notifier.
5. Identifies the subscription duration, as follows, and sends the 200 OK to the UE:
If there is no Expires header in the UE’s 200OK message, the Oracle USM applies it’s own configured minimum
or the default (600000 seconds), whichever is greater.
If the SUBSCRIBE includes an Expires header, the Oracle USM honors the request unless it is less than the
configured minimum.
If the SUBSCRIBE’s Expires header is less than the minimum subscription time configured in the registration
event profile, the Oracle USM denies the subscription, sending a 423 Too Brief message.
When the Oracle USM encounters an Expires header set to 0, it terminates the subscription. This is referred to as
unsubscribing.
SUBSCRIBE REFRESH Requests
Subscriptions must be refreshed to keep them from expiring. ASs accomplish this by sending SUBSCRIBE
REFRESH messages to the Oracle USM. Messages must be received from authorized subscribers and on the same
realm and connection as the original SUBSCRIBE or the Oracle USM rejects the refresh request.
Reg Event NOTIFY Messages
When configured, the Oracle USM issues NOTIFY messages to subscribed ASs when significant registration events
occur. NOTIFY messages sent by the Oracle USM comply fully with RFC3680. Events that trigger NOTIFY
messages include:
•
•
•
•
•
Registered
Registration refreshed
Registration expired
Registration deactivated
UE unregistered
The Oracle USM does not send NOTIFY messages for the following events:
•
•
•
•
Registration created
Registration shortened
Registration probation
Registration rejected
Additional detail about NOTIFY messages that is specific to the Oracle USM includes:
•
•
•
•
228
The Oracle USM always sends full information on all contacts, and indicates such within the reginfo element. The
Oracle USM does not utilize the partial state described within RFC 3680.
Wildcarded PUIDs are included, enclosed in the <wildcardedIdentity> tag within the <registration> element.
The Oracle USM does not include the following optional attributes within the contact element:
• expires
• retry-after
• duration registered
• display-name
The Oracle USM uses the optional unknown-param element within the contact element to convey UA capabilities
and distribute reg-id, sip.instance and header filed attributes.
Oracle® Communications Unified Session Manager
Oracle USM Supporting the IMS Core
An example of the XML body of a NOTIFY message below documents the registration status for the AOR
joe@example.com.
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
xmlns:xsi=http://www.w3.org/
2001/XMLSchema-instance version="0" state="full">
<registration aor="sip:joe@example.com" id="as9" state="active">
<contact id="6" state="active" event="registered">
<uri>sip:joe@pc887.example.com</uri>
</contact>
<contact id="7" state="terminated" event="expired">
<uri>sip:joe@university.edu</uri>
</contact>
</registration>
</reginfo>
Use the show registration and show sipd subscription commands to display all information about each subscription.
Reducing NOTIFY Traffic
RFC 3265 stipulates that the Subscription server sends NOTIFY messages to all subscribers when a UA sends a
registration refresh. This can generate excessive NOTIFY traffic. You, however, can mitigate this by configuring the
Oracle USM to limit notification traffic. By specifying the number of seconds between NOTIFY messages, you
prevent the Oracle USM from sending notifications upon events that do not generate a change in the registration
database.
Database changes that trigger notifications when this option is configured include:
•
•
•
•
The Cseq number of the REGISTER message increases by more than 1
The call-ID changes
A contact parameter changes
The number of contacts changes
Upon expiry of this timer, the Oracle USM sends out a NOTIFY for every registration event subscription. Note also
that the Oracle USM does not send the cseq attribute in the CONTACT element when this interval is configured.
Configuring Registration Event Package
This section shows you how to create reg-event profiles and apply those profiles to sip-registrars. These profiles
enable the monitoring of UA registration events and the delivery of state change notifications to each UA that
subscribes to the package. The procedure includes:
•
•
•
Create one or more registration-event profiles
Apply each profile to the applicable sip-registrar
Optionally specify the registration event notification interval timer
Registration Event Profile Configuration
To configure a registration event profile:
1. From superuser mode, use the following command sequence to access regevent-notification-profile command.
ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# regevent-notification-profile
ORACLE(registration-event-profile)#
2. To define the profile, simply name it and specify a timeout in seconds.
ORACLE(registration-event-profile)#
ORACLE(registration-event-profile)#
ORACLE(registration-event-profile)#
ORACLE(registration-event-profile)#
name reg-event-profile1
min-subscription-duration 2500
done
exit
3. Navigate to the registrar for which you want registration event package support.
Oracle® Communications Unified Session Manager
229
Oracle USM Supporting the IMS Core
ORACLE(session-router)# sip-registrar
ORACLE(sip-registrar)# regevent-notification-profile reg-event-profile1
ORACLE(sip-registrar)# done
ORACLE(sip-registrar)# exit
Optional NOTIFY Refresh Frequency
To specify optional NOTIFY refresh frequency:
1. From superuser mode, use the following command sequence to access registration-event-profile command within
session router.
ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# regevent-notification-profile
ORACLE(registration-event-profile)#
2. To enable NOTIFY, set the send-notify-for-reg-refresh option to the time, in seconds,
ORACLE(registration-event-profile)# options notify-refresh-interval=1800
ORACLE(registration-event-profile)# done
ORACLE(registration-event-profile)# exit
Prepend the option with the + sign if you have multiple options configured that you want to retain.
ORACLE(registration-event-profile)# options +notify-refresh-interval=1800
Running the command without the + character causes the system to remove any previously configured options.
Message Routing
The Oracle USM provides two major types of routing that use the routing precedence parameter in the sip registrar.
Routing precedence can be set to either registrar (HSS) or local policy. Routing precedence is set to registrar by
default. There are additional controls that the user may configure to refine message routing.
Registrar routing uses the configured subscriber database and registration cache to route the call. Local policy routing
lets you configure routing decisions within the Oracle USM’s local policy routing functionality.
Within the context of local policy routing, the Oracle USM chooses the next hop through the network for each SIP
session based on information received from routing policies and constraints. Routing policies can be as simple as
routing all traffic to a proxy or routing all traffic from one network to another. Routing policies can also be more
detailed, using constraints to manage the volume and rate of traffic that can be routed to a specific network. For
example, you can manage volume and rate of traffic to enable theOracle USM to load balance and route around
softswitch failures.
When a message arrives at the Oracle USM, it determines whether it is coming from a session agent. If so, the Oracle
USM checks whether that session agent is authorized to make the call. Local policy is then checked to determine
where to send the message.
Depending on whether the Oracle USM is performing originating or terminating services for the call, described in the
chapter on operations within the IMS core, it performs those services prior to routing to the endpoint.
If the Oracle USM is unable to proceed with routing a request, it replies to the UA that sent the request with a 4xx
response.
This chapter provides an overview of registrar routing for perspective, but focuses on local policy routing. Local
policy routing is configuration intensive, allowing precise route specification. As a result, configuring local policy
routing is a complex process requiring that the user understand the purpose and interaction of multiple configuration
elements. This chapter also provides descriptions and configuration instruction on additional routing controls, such as
the use of multistage and UA capability routing.
230
Oracle® Communications Unified Session Manager
Oracle USM Supporting the IMS Core
Registrar Routing
When the routing precedence parameter is set to registrar, the Oracle USM is using the HSS as a resource within the
context of its routing decisions.
When an INVITE arrives, the Oracle USM checks its own registration cache for a pre-existing matching contact in
the INVITE. If it finds a match, it forwards the request to that location. If it does not find a match, it issues an
Location Information Request (LIR) to the HSS. If the HSS’s response, called an LIA, provides an assigned S-CSCF
for that UA, the Oracle USM proceeds as described below in the section LIR/LIA Transaction.
Note that you can configure the Oracle USM to fallback to a local policy lookup if the lookup via the registrar fails.
Configure this by adding the fallback-to-localpolicy option to the sip-registrar configuration element.
For situations where the database routing decision needs to be done in lieu of the default, you can set routing
precedence to local-policy. Note that you can configure a routing entry that points to an HSS by setting a policy
attribute with a next-hop of cx:<home-subscriber-server-name> within the local-policy.
LIR/LIA Transaction
An LIR includes the Public-User-Identity AVP, which contain a UA’s actual PUID. The HSS responds with the
assigned S-CSCF server (often a Oracle USM) for this PUID. The answer is the form of a Location Info Answer
(LIA). The LIA includes the assigned S-CSCF in the Server Name AVP.
If the S-CSCF returned in the LIR is this Oracle USM, then the Oracle USM performs unregistered termination
services for this UA. (This situation indicates that the UA is currently unregistered.) Such services could include
directing the call to voice mail. If the HSS returns an S-CSCF in the LIA that is not this Oracle USM, it forwards the
request to that S-CSCF.
Default Egress Realm
The sip registrar configuration element should be configured with a default egress realm id. This is the name of the
realm config that defines the IMS control plane, through which all Oracle USMs, HSSs, and other network elements
communicate and exchange SIP messaging. It is advisable to configure this parameter to ensure well defined
reachability among Oracle USMs.
RX Interface Features
The Oracle USM can run the Rx interface over a Diameter connection and act as a P-CSCF communicating with a
PCRF. The Rx interface supports quality of service and policy management within applicable network infrastructures.
See the Oracle SBC ACLI Configuration Guide for full descriptions of this functionality.
ACLI Instructions
Configuring the SIP Registrar's Routing Precedence
To configure a SIP registrar configuration element for message routing:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter to access the session router path.
ORACLE(configure)# session-router
3. Type sip-registrar and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(session-router)# sip-registrar
ORACLE(sip-registrar)#
4. Type select and choose the number of the pre-configured sip interface you want to configure.
5. routing-precedence— Set this to either registrar or local-policy depending on your deployment.
6. egress-realm-id—Enter the default egress realm for Oracle USM messaging.
Oracle® Communications Unified Session Manager
231
Oracle USM Supporting the IMS Core
7. Type done when finished.
Home Subscriber Server
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter to access the session router path.
ORACLE(configure)# session-router
3. Type home-subscriber-server and press Enter. The system prompt changes to let you know that you can begin
configuring individual parameters.
ORACLE(session-router)# home-subscriber-server
ORACLE(home-subscriber-server)#
4. Begin configuring your HSS, or type select and choose the number of the pre-configured HSS you want to
configure.
5. Type done when finished.
Tel-URI Resolution
The Oracle USM can initiate number resolution procedures for requests that have tel-URI or SIP-URI (with
user=phone) numbers in the R-URI. It does this by querying number resolutions services, including the local routing
table(s) or ENUM server(s) to resolve the R-URI to a SIP URI. In addition, the original R-URI may not include a full
E.164 number. As such, you can also configure the Oracle USM to perform a number normalization procedure and
ensure it presents a full E.164 number for resolution. Upon successful resolution, the Oracle USM proceeds with
ensuing signaling procedures.
To configure the Oracle USM to perform these lookups, you create applicable local-routing-config or enum-config
elements and set an option within the sip-registrar that specifies a primary and, optionally, a secondary local-routingconfig or enum-config that the sip-registrar uses for LRT or ENUM lookups. If there is no ENUM configuration on
the sip-registrar, the Oracle USM forwards applicable requests to a border gateway function via local policy.
Refer to the Net-Net SD ACLI Configuration guide, Session Routing and Load Balancing chapter for complete
information on how to configure a local-routing-config and an enum-config.
Number Lookup Triggers
Use cases that are applicable to number lookups and the associated Oracle USM procedures include:
•
Request from the access side:
•
1. The Oracle USM performs originating services.
2. If the R-URI is a tel-URI or SIP-URI (with user=phone), it requests e.164 resolution from the ENUM
server(s), regardless of its presence in the registration cache.
Request from core side including request for originating services:
•
1. The Oracle USM performs originating services.
2. If the R-URI is a tel-URI or SIP-URI (with user=phone), it requests e.164 resolution from the ENUM
server(s), regardless of its presence in the registration cache.
Request from core side, for terminating services only:
1. If the R-URI is a tel-URI or SIP-URI (with user=phone) and is not in the Oracle USM cache, it performs an
LIR.
2. If the LIA reply indicates the tel-URI or SIP-URI (with user=phone) is not provisioned, the Oracle USM
requests e.164 resolution from the ENUM server(s).
Actions Based on Lookup Results
The Oracle USM forwards to the resultant SIP-URI under the following conditions:
232
Oracle® Communications Unified Session Manager
Oracle USM Supporting the IMS Core
•
•
•
The SIP-URI is in the Oracle USM cache, in which case the Oracle USM performs terminating services.
The SIP-URI is not in the Oracle USM cache, and the Oracle USM is configured to service the returned domain.
In this case, the Oracle USM performs the following:
1. The Oracle USM issues an LIR for the SIP-URI.
2. The Oracle USM forwards the message to the correct S-CSCF.
The SIP-URI is not in the Oracle USM cache, and the Oracle USM is not configured to service the returned
domain.
In this case, the Oracle USM performs refers to local policy to forward the message via local policy.
PSTN Breakout Routing
The Oracle USM complies with RFC 4694 for operation with request-URIs that include carrier identification code/
route number/number portability database dip indicator (cic/rn/npdi) information and routes those requests according
to the rn information. The routing process includes utilization of local policy configured to break the request out of
the home network via gateways such as a BGCF.
The Oracle USM does not validate any rn or cic information. Instead, it simply routes the request. Note that the
Oracle USM uses cic information instead of rn if both are present in the request. RFC 4694 compliant circumstances
under which the Oracle USM does not use rn, cic and npdi information include:
•
•
•
Invalid routing information, including rn present, but npdi missing.
Invalid routing information, including npdi present, but rn missing.
Request uses a sip-URI presented without user=phone.
If the request includes originating services as well as cic/rn/npdi information, the Oracle USM performs those
services rather than break out. If, after completing originating services, the request still includes cic/rn/npdi
information, the system performs this breakout.
Primary and Secondary ENUM Configuration
For the purpose of redundancy, the Oracle USM allows you to configure these number lookups to use a backup
resource in case the lookup at the primary fails. Such scenarios include losing contact with the primary ENUM/LRT
server config (query time-out) and the entry is not found at the primary (LRT or ENUM).
To apply primary and secondary number lookup resources to a sip-registrar:
1. From superuser mode, use the following command sequence to access the sip-registrar element and select the
registrar you want to configure.
ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# sip-registrar
ORACLE(sip-registrar)# select
2. Specify the resources to use with the options command.
Prepend the option with the + character if you have multiple options configured that you want to retain. Running
the command without the + character causes the system to disable any previously configured options.
To specify primary and secondary ENUM servers:
ORACLE(sip-registrar)# options +e164-primary-config=enum:<enum-config name>
ORACLE(sip-registrar)# options +e164-secondary-config=enum:<enum-config
name>
ORACLE(sip-registrar)# done
To specify primary and secondary LRT resources:
ORACLE(sip-registrar)# options +e164-primary-config=lrt:<lrt-config name>
ORACLE(sip-registrar)# options +e164-secondary-config=lrt:<lrt-config name>
ORACLE(sip-registrar)# done
Oracle® Communications Unified Session Manager
233
Oracle USM Supporting the IMS Core
Bear in mind that an enum-config can reference multiple servers. When the Oracle USM references an enumconfig, queries follow the normal enum-config sequence, checking each referenced server in order. If the lookup is
not successful at the primary, the Oracle USM checks the servers in the registrar’s e164-secondary-config.
In addition, each enum-config may refer to a different top-level-domain. This allows you to configure the Oracle
USM to successfully perform lookups within two domains.
HSS Initiated User Profile Changes
The Oracle USM can receive Push Profile Request (PPR) messages from an HSS and update the state of the IMS
User Profile and associated subscription information it has cached locally. The SIP digest authentication information
can also be updated and reassociated with an AoR in case that has changed too. The Oracle USM expects to receive
the following AVPs in a PPR message.
•
•
•
•
Private-User-Identity—the username, whose subscription/authentication data has changed.
SIP-Auth-Data-Item—if present new authentication data is included here.
User-Data—if present new User data is included here.
Charging-Information—if present new charging information is included here.
The Oracle USM replies to an HSS’s PPR in a PPA message with the following AVPs:
•
Result-Code—indicates Diameter base protocol error. Valid errors for in a PPA are:
•
•
•
DIAMETER_SUCCESS—The request succeeded.
DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA—The request failed. The Oracle USM informs
HSS that the received user information contained information, which was not recognized or supported.
• DIAMETER_ERROR_USER_UNKNOWN—The request failed because the Private Identity is not found in
Oracle USM.
• DIAMETER_ERROR_TOO_MUCH_DATA—The request failed. The Oracle USM informs to the HSS that it
tried to push too much data into the Oracle USM.
• DIAMETER_UNABLE_TO_COMPLY—The request failed.
Experimental-Result—indicates diameter application (3GPP/Cx) error if present.
Licensing and Database Registration Limits
The Oracle USM limits the number of unexpired registration cache entries globally. The total number of system
registrations is configured with the registration cache limit parameter in the sip config configuration element.
The Oracle USM also limits the number of registration cache entries that were obtained from a User Subscriber
Database; only REGISTERs that prompted the database query are counted here. As User Subscriber Database entries
are added and removed, this counter is updated accordingly. Note that it is the actual number of SD-contacts that
count against the license limit. Discrete database registration license values range from 20,000 through 500,000 in
increments of 20,000.
When a registering contact is rejected because it will exceed one of these limits, the Oracle USM sends a 503 message
to the registering endpoint.
Refer to the Getting Started chapter for information about install license management.
Database Registration Limit Alarm
By default, a major alarm is enabled when 98% or more of the licensed number of Database Registrations are used.
This alarm is cleared when the number of database registrations falls below 90%. You can configure minor and
critical alarms when crossing configured thresholds and you can also reassign the major alarm. This is configured in
by creating a system-config > alarm-threshold sub element with type of database-registration.
234
Oracle® Communications Unified Session Manager
Oracle USM Supporting the IMS Core
3GPP Compliance
P-Asserted-Id in Requests and Dialogs
When an AoR is successfully registered through the Oracle USM, the list of implicitly registered public IDs is
returned from the HSS. The set of implicitly registered public IDs includes the explicitly registered Public-id and may
include wild-carded public-ids. If there are no implicitly registered public-ids, then the implicit set returned by HSS
will at least contain the explicitly registered public-id.
Based on local configuration and network conditions, the registering UE may or may not be trusted.
Non-trusted UE
When a non-trusted UE sends an initial request for a dialog or a request for a standalone transaction to the Oracle
USM, the P-Asserted-Identity to be inserted in the outgoing request is formed as follows:
•
•
•
If the request does not have a P-Preferred-Identity header field or none of the P-Preferred-Identity header fields
included in the request match any of the registered public user identities, then the Oracle USM inserts the default
Public-Identity in the outgoing P-Asserted-Identity header.
If the request includes one or more P-Preferred-Identity header fields which match the registered public user
identities, then the Oracle USM includes only the first P-Preferred-Identity header field.
If the request includes one or more P-Asserted-Identity header fields which do not match the registered public user
identities, then the Oracle USM inserts the default Public-Identity in the outgoing P-Asserted-Identity header.
Trusted UE
When a trusted UE sends an initial request for a dialog or a request for a standalone transaction to the Oracle USM,
the P-Asserted-Identity to be inserted in the outgoing request is formed as follows:
•
•
•
If the request does not have a P-Preferred-Identity header field or none of the P-Preferred-Identity header fields
included in the request match any of the registered public user identities, then the Oracle USM inserts the default
Public-Identity in the outgoing P-Asserted-Identity header.
If the request includes one or more P-Preferred-Identity header fields which match the registered public user
identities, then the Oracle USM inserts the first P-Preferred-Identity header field.
If the request includes one or more P-Asserted-Identity header fields, then the Oracle USM will use the first PAsserted-Identity header field.
•
•
The contents of the From header field do not form any part of this decision process.
P-Preferred-Identity header fields will always be removed.
The Default Public Identity is the first appearing, non-barred identity in the set of implicitly registered Public User
Identities.
To enable this behavior, add the pai-comply-to-3gpp option in the sip config configuration element.
P-Associated-URI in 200 OK
In a 200 OK response to a UE on a successful registration, the Oracle USM includes a P-Associated-URI header. This
header includes the list of registered, distinct public user identities and the associated set of implicitly registered
distinct public user identities.
When there are no associated implicit public identities, only the explicitly registered Public User Identity is included.
Oracle® Communications Unified Session Manager
235
Oracle USM Supporting the IMS Core
Other Diameter Cx Configuration
Host and Realm AVP Configuration for Cx
You can configure the values sent in the origin-host, origin-realm and destination-host AVPs when the Oracle USM
communicates with a server over the Cx interface. Configure destination-host when you want to precisely specify the
HSS with which these Cx exchanges take place.
The applicable configuration parameters are located in the home-subscriber-server configuration element. The
parameters used to configured the AVPs are origin-realm, origin-host-identifier and destination-host-identifier. The
AVPs are constructed as follows:
Origin Host AVP = <origin-host-identifier>.<origin-realm>
Origin Realm AVP = <origin-realm>
Destination Host AVP = <destination-host-identifier>.<destination-realm>
If the origin-realm is not configured, then the realm parameter in the home-subscriber-server configuration element
will be used as the default. If origin-host-identifier is not configured, then the name parameter in the home-subscriberserver configuration element will be used as the default.
If these parameters are not configured, then the AVPs are constructed as follows:
Origin Host = <HSS Config name>.<HSS Config realm>.com
Origin Realm AVP = <HSS Config realm>
Destination Host = <HSS Config name>.<HSS Config realm>.com
ACLI Instructions
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter to access the session router path.
ORACLE(configure)# session-router
3. Type home-subscriber-server and press Enter. The system prompt changes to let you know that you can begin
configuring individual parameters.
ORACLE(session-router)# home-subscriber-server
ORACLE(home-subscriber-server)#
4.
5.
6.
7.
origin-realm—Set this to a string for use in constructing unique Origin Host and Origin Realm AVPs.
origin-host-identifier—Set this to a string for use in constructing a unique Origin Host AVP.
destination-host-identifier—Set this to a string for use in constructing a unique Destination Host AVP.
Save your work.
Initial Filter Criteria (IFC)
The Oracle USM, acting as a S-CSCF, downloads a set of rules known as Initial Filter Criteria (IFC) from the
HSS/AS. IFCs are downloaded over the Cx interface.
iFCs are a way for an S-CSCF to evaluate which ASs should be involved in the call flow for a given user agent (UA).
iFCs are functionally defined by Boolean statements, whose component parts are expressed in XML; they reference
the destination AS(s) where a desired service is provided.
IFC Evaluation
IFCs are evaluated as described in 3GPP TS 29.228. The Oracle USM supports all tags found in the 3GPP initial filter
criteria specifications. An IFC is evaluated until its end, after which the call flow continues as expected.
236
Oracle® Communications Unified Session Manager
Oracle USM Supporting the IMS Core
SIP Registration
When the Oracle USM receives an authenticated REGISTER request from a served UA, it sends an SAR request to
the HSS to obtain an SAA which includes iFCs associated with the UE’s subscription. Within the context of
registration, the Oracle USM also manages third party registration procedures in conjunction with iFC exchanges or
manually via the ACLI. These procedures are described in the Third Party Registration chapter.
SIP Call
The Oracle USM evaluates all IFC logic to determine that messages with matching characteristics are sent to the
proper AS specified in the iFC evaluation using the IP Multimedia Service Control (ISC) interface. In this INVITE,
the Oracle USM adds two Route headers. The first (top) route header contains the target AS’s URI. The second Route
parameter is built using the IP address of the egress SIP interface and contains the ODI as a parameter. For example:
INVITE SIP:test@service.com
...
Route:2.2.2.2;lr
Route:1.1.1.1:5060;lr;smx_odi=1
If the AS routes the call back to the Oracle USM, it is expected to include the ODI parameter that it received from the
Oracle USM, unchanged. The presence of the ODI parameter indicates that IFC evaluation needs to continue from
where it left off for this call. If this continuation of IFC evaluation results in another AS URI, the Oracle USM
initiates a request towards that AS this time with a new ODI. In this way, the ODI is a state-signifier of Service Point
Triggers.
The process continues until IFC evaluation is completed. Below is an example of an IFC evaluation completing after
two iterations.
The iFC continues to be evaluated completely which may result in the INVITE being forwarded to additional ASs. At
the conclusion of evaluating the iFC, the Oracle USM checks if the target of the initial request is registered to itself,
or not. If the UA is not registered locally the Oracle USM forwards the request by regular means into the network. If
the target UA is registered locally, the Oracle USM proceeds to obtain iFCs for the target and begin iFC evaluation for
the terminating side of the call.
Evaluating Session Case in the P-Served-User Header
The P-served-user header field conveys the identity of the served user, the session case that applies to the particular
communication session, and application invocation, as defined in RFC 5502 and TS 24.229. The Session Case
(sescase) and Registration State (regstate) parameters are either populated by the UA originating the message or by
the Oracle USM after it determines if a request is originating or terminating, and registered or unregistered
Oracle® Communications Unified Session Manager
237
Oracle USM Supporting the IMS Core
The P-served-user header is created and added to an outgoing request if the next hop is trusted. A trusted next hop is
an entity defined by a session agent whose trust-me parameter is enabled. Likewise, the P-served-user header is
stripped if the request is forwarded to a next hop that is not known to be trusted.
When the Oracle USM creates a P-served-User header, the user value in the originating case is the user value found in
the P-Asserted-Identity header field. In the terminating case, the user value is taken from the Request URI.
Supported Sessioncase and Registration State
The following cases are supported for IFC evaluation. Conditions for classifying the calls as such are listed below.
Originating request by a UA, Registered User
When the Oracle USM receives an Initial request, it is validated as an originating request from a registered user when
the following conditions are met:
•
•
•
The request is a dialog creating request or a standalone request.
There is no "odi" parameter in the top route of the request.
The regstate and sescase parameters of the P-served-user indicate for this to be treated as originating request for a
registered user OR "The request is received from a registered contact.
Originating request by a UA, Unregistered User
When the Oracle USM receives an Initial request, it is validated as an originating request from an unregistered user
when the following conditions are met:
•
•
•
•
The request is a dialog creating request or a standalone request.
There is no "orig" parameter in the top route of the request.
The served user is unregistered.
The request is from an AS or I-CSCF and the top route header contains the orig parameter OR
The regstate and sescase of the P-served-user header indicates that the request is an originating request for an
unregistered user.
Terminating Requests to a UA, Registered User
When the Oracle USM receives an Initial request, it is validated as a terminating request towards a registered user
when the following conditions are met:
•
•
•
•
•
The request is a dialog creating request or a standalone request.
There is no "orig" parameter in the top route of the request.
There is no "odi" parameter in the top route of the request.
The regstate and sescase parameters of the P-served-user indicate for this to be treated as terminating request for a
registered user OR the request is finished with originating services if applicable and the request is destined to a
user who is currently registered with the Oracle USM.
If the Request-URI changes when visiting an application server, the Oracle USM terminates the checking of filter
criteria and routes the request based on the changed value of the Request-URI, per 3GPP Specification TS 23.218.
Terminating Requests to a UA, Unregistered User
See the IFC Support for Unregistered Users section for this case.
•
If the Request-URI changes when visiting an application server, the Oracle USM terminates the checking of filter
criteria and routes the request based on the changed value of the Request-URI, per 3GPP Specification TS 23.218.
Additional Options
•
•
238
The Oracle USM can populate the top Route: header with the sescase value for ASs that require it. In such a case,
the parameter is created as either call=orig or call=term. This behavior is enabled by configuring the add-sescaseto-route option in the ifc-profile.
When the dialog-transparency parameter in the sip-config is set to enabled and your network includes multiple
ASs, you should add the dialog-transparency-support option in the ifc-profile.
Oracle® Communications Unified Session Manager
Oracle USM Supporting the IMS Core
•
The Oracle USM provides an alternative, configurable option that allows the user to specify the use of route
header information to determine Served User and Session Case for out-of-the-blue (OOTB) calls. This method is
3GPP-compliant. By default, the Oracle USM uses information from the P-Served-User (PSU) header. The user
configures this behavior by enabling the ignore-psu-sesscase option in the ifc-profile.
IFC Support for Unregistered Users
The Oracle USM can download Initial Filter Criteria (IFC) from the HSS for unregistered users. This section displays
applicable message sequence diagrams.
UE-terminating requests to an unregistered user
The Oracle USM downloads and executes IFCs for the terminating end of calls. The following call flows indicate
possible cases for the terminating unregistered user.
Terminating UA - Unregistered
UE has never registered.
Terminating UA - Unregistered
UE originally registered as a consequence of an originating or terminating request or an S-CSCF has stored the user
profile.
Oracle® Communications Unified Session Manager
239
Oracle USM Supporting the IMS Core
Terminating UA - Not Registered, Served by other Oracle USM
UE Subsequent Registration
If the Oracle USM has a cached IFC downloaded for an unregistered UA who later registers to that Oracle USM, the
cached IFC will be cleared and updated with the IFC downloaded by the registration process.
Caching the Downloaded IFC
When the Oracle USM downloads IFCs for unregistered users, they are saved to a local cache. If the IFC cache fills
up, an older cached IFC for a user is released.
Optimizing IFC Updates
The Oracle USM aims to reduce the number of IFC updates traversing the network to save bandwidth and
transactional overhead. Unless the unregistered UE’s IFC entry has been deleted because of exhausting cache space,
the following optimizations are performed:
•
•
If IFCs are available locally, then an SAR/SAA operation to download IFCs will not be performed.
If a previous IFC download operation did not return any IFCs, then subsequent calls to that unregistered user will
not invoke the SAR/SAA messaging to download IFCs.
Push Profile Request (PPR) updates
The HSS can push service profile updates for private IDs. The Oracle USM can process PPR updates for unregistered
entities. If the user entry has been deleted because IFC cache space has been exhausted, the PPRs will not be
processed.
ACLI Instructions
SIP Registrar
To create an IFC Profile:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter to access the session router path.
ORACLE(configure)# session-router
3. Type ifc-profile and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
240
Oracle® Communications Unified Session Manager
Oracle USM Supporting the IMS Core
ORACLE(session-router)# ifc-profile
ORACLE(ifc-profile)#
4. name—Enter a name for this IFC profile.
5. state—Set this to enabled to use this ifc-profile.
6. options—Set the options parameter by typing options, a Space, the option name with a plus sign in front of it, and
then press Enter.
If you type the option without the plus sign, you will overwrite any previously configured options. In order to
append the new options to the options list, you must prepend the new option with a plus sign.
The options included in this section are: add-sescase-to-route and dialog-transparency-support.
7. Type done when finished.
SIP Registrar
To enable IFC support in a SIP Registrar:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter to access the session router path.
ORACLE(configure)# session-router
3. Type sip-registrar and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(session-router)# sip-registrar
ORACLE(sip-registrar)#
4. Type select and choose the number of the pre-configured SIP registrar configuration element you want to
configure.
ORACLE(sip-registrar)# select
name:
1: registrar1
selection:1
ORACLE(sip-registrar)#
5. ifc-profile—Set this parameter to the name of the IFC profile you just created.
6. serving-function—Set this parameter to disabled when you want the Oracle USM to act solely as an I-CSCF.
When disabled, the Oracle USM always forwards requests from unregistered users to the serving group.
The default is enabled, which retains the S-CSCF function on this Oracle USM.
7. serving-group—Set this parameter to a Session Agent Group (SAG) name. The Oracle USM forwards requests
from unregistered users to this group when the serving function parameter is disabled.
Use of this parameter requires the prior configuration of a SAG that includes all prospective S-CSCFs. The name
you give to that group is the name you specify as an argument to this parameter.
8. Type done when finished.
Shared and Default iFCs
The Oracle USM supports Shared iFCs (SiFC), as defined by TS 29.229 and Default iFCs, which are an Oracle
extension upon SiFCs. SiFCs provide an operator with the ability to create iFC templates and apply them to a large
number of UEs. The SiFC process optimizes the provisioning, storage and transfer of service profile information. The
default IFC (DiFC) establishes a configuration wherein the iFC associations are available on the Oracle USM itself.
This establishes a backup scenario in case the HSS is not responsive.
To support the SiFC feature on the Oracle USM, you create a profile that refers to a local, XML-formatted file. This
file specifies the iFCs to be shared. You apply these profiles to registrars to specify where they are used.
Oracle® Communications Unified Session Manager
241
Oracle USM Supporting the IMS Core
When an SiFC configuration is in place, the Oracle USM notifies the HSS that it supports SiFCs within the
Supported-Features AVP in the SAR. The HSS replies to confirm that it supports SiFCs within the SAA. The SiFC
feature must be enabled on the HSS.
Note that the form and function of the SiFC and DiFC files are compatible. You can use the same file for both SiFC
and DiFC configuration, if desired.
SiFC Usage
When an applicable end station registers, the Oracle USM forwards the registration to the HSS normally. Given SiFC
configuration however, the HSS sends a service-profile containing the SiFC identifiers to the Oracle USM rather than
the entire service definition. The Oracle USM parses these identifiers and maps the user to the locally stored filter
criteria.
The <IFCSet id =”x”> tags in the XML file on the Oracle USM map to the HSS identifiers.
DiFC Usage
In contrast to SiFCs, the Oracle USM fires DiFCs within the context of a session. During the session, the Oracle USM
associates the iFCs within the DiFC file with the user, as needed. DiFC usage is invoked during session initiation.
Note that DiFCs are database agnostic. You can use DiFCs for HSS, ENUM and local database configurations. An
operational overview of SiFCs and DiFCs is shown below.
SiFC/DiFC File Example
An example of a Oracle USM local SiFC/DiFC XML file, including a single iFC Set containing a single iFC, is
presented below.
<?xml version="1.0" encoding="UTF-8"?>
<IFCSets>
<IFCSet id=”0”>
<InitialFilterCriteria>
<Priority>0</Priority>
<TriggerPoint>
<ConditionTypeCNF>0</ConditionTypeCNF>
<SPT>
<ConditionNegated>0</ConditionNegated>
<Group>0</Group>
<Method>INVITE</Method>
<Extension></Extension>
</SPT>
</TriggerPoint>
<ApplicationServer>
<ServerName>sip:172.16.101.26:5060</ServerName>
<DefaultHandling>0</DefaultHandling>
</ApplicationServer>
<ProfilePartIndicator>0</ProfilePartIndicator>
242
Oracle® Communications Unified Session Manager
Oracle USM Supporting the IMS Core
</InitialFilterCriteria>
</IFCSet>
</IFCSets>
Note that the Shared IFCSet contains the integer value property (id=”0”) that associates these filter criteria with users
registered with the Oracle USM. In the case of SiFC, it is the value that the HSS should send when referencing shared
sets. In the case of DiFC, the integer is meaningless. The Oracle USM loads and executes default iFCs in the order
they appear within the XML file.
iFC Execution Order
Within the context of the 3GPP standards, the Oracle USM evaluates explicitly downloaded iFCs first when
determining where to look for a service. If the Oracle USM cannot execute on the service based on explicitly
downloaded iFCs, it refers to the SiFC, then the DiFC information to identify an AS that supports the service.
Refreshing SiFC and DiFC Files
Given the nature of local file usage, an ACLI command is available to allow the user to refresh SiFC and DiFC
contexts in memory after the user has saved changes to the SiFC and DiFC files. Run the following command to
deploy these changes:
ORACLE# refresh ifc <ifc-profile name>
Note also that the Oracle USM validates the SiFC and DiFC files whenever you Activate your configuration.
SiFC and DiFC Configuration
To configure the Oracle USM to use Shared and Default IFCs:
1. From superuser mode, use the following command sequence to access ifc-profile element.
ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# ifc-profile
2. Define your profile.
3. name—Enter a name for this IFC profile.
ORACLE(ifc-profile)# name acmeTelecomIFC
4. state—Set this to enabled to use this ifc-profile.
ORACLE(ifc-profile)# state enabled
5. default-ifc-filename—Specify filename and, if not stored in the default directory /code/ifc, the applicable
pathname.
ORACLE(ifc-profile)# default-ifc-filename Afile.xml.gz
6. shared-ifc-filename—Specify filename and, if not stored in the default directory /code/ifc, the applicable
pathname.
ORACLE(ifc-profile)# shared-ifc-filename Bfile.xml.gz
7. options—Set the options parameter by typing options, a Space, the option name with a plus sign in front of it, and
then press Enter.
ORACLE(ifc-profile)# done
8. Apply the ifc-profile to your sip registrar.
ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# sip-registrar
Select the registrar you want to configure and apply the profile.
ORACLE(sip-registrar)# select
ORACLE(sip-registrar)# ifc-profile acmeTelecomIFC
ORACLE(sip-registrar)# done
Oracle® Communications Unified Session Manager
243
Oracle USM Supporting the IMS Core
Distinct and Wildcarded Public Service Identity (PSI) Support
The Oracle USM supports the use of distinct Public Service Identity (PSI) and wildcarded PSIs, typically for
specifying access to a service. There is no configuration required on the Oracle USM to enable this support.
Administrators use individual PSI entries and/or wildcarded PSIs as service identifiers on an HSS. These identifiers
provide the information needed to direct applicable messages to applicable application servers. Distinct PSIs can
reside within individual PSI entries; wildcarded PSI entries are managed within iFC lists. Wildcarded PSI support is
typically implemented to reduce HSS resource requirements. By configuring a wildcarded PSI, administrators can use
a single record within the iFC to manage multiple resources.
A wildcard is composed of an expression that, when used in a user part, provides for access to multiple service
resources. The regular expressions themselves are in form of Perl Compatible Extended Regular Expressions (PCRE).
For example, consider the following two service resources:
•
•
sip:chatroom-12@core.com
sip:chatroom-64@core.com
These two service resources can be represented simultaneously at the HSS using the following syntax:
•
sip:chatroom-!.*!@core.com
The Oracle USM caches filter criteria information that uses this wildcard syntax. This avoids the need for SAR/SAA
exchanges between the Oracle USM and the HSS every time an entity requests the service. The Oracle USM is
equally capable of caching distinct PSIs, which similarly offloads the need for SAR/SAA exchanges during service
resource location processes.
For most call flows, the Oracle USM does not evaluate the expression for the purpose of finding a match. Instead, it
keeps the syntax provided by the HSS in its cache and provides the wildcarded syntax in the applicable AVP.
To allow the feature, the Oracle USM supports:
•
•
•
Wildcarded public user identity AVP in the LIA, SAR and SAA
User Profile AVP in the SAA
P-Profile-Key across the Mw interface, as defined in RFC 5002
Configuring SIP Ping OPTIONS Support
You can configure the Oracle USM to respond to SIP ping OPTIONS. This support is typically configured on an SCSCF so it can respond to pings OPTIONS sent by a P-CSCF:
To configure an SIP Options Ping response support:
1. From superuser mode, use the following command sequence to access ping-response command on a sip-interface
element.
ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# sip-interface
ORACLE(sip-interface)# sel
2. Enable the support with the ping-response command.
ORACLE(http-config)# ping-response enabled
ORACLE(http-config)# done
ping-response—Enable ping-response to allow your device to respond to ping OPTIONS. For example, this
feature is useful within hybrid deployment environments on a P-CSCF as a means of verifying the S-CSCF’s
availability. This configuration allows the S-CSCF to respond to SIP ping OPTIONS.
244
Oracle® Communications Unified Session Manager
Oracle USM Supporting the IMS Core
Redundancy and Load Balancing with HSS Servers
The Oracle USM allows you to operate with multiple HSS servers, supporting:
•
•
Redundancy - Continue normal operation despite HSS failure.
Load Balancing - Divide the traffic load between HSS servers in a group of HSSs. Preference is based on the HSS
list order configured on the Oracle USM.
You configure HSS servers within HSS Groups to support this functionality. For redundancy, you create and assign
HSS groups, and apply either the hunt or fail-over strategy to your HSS group. To implement load balancing, you
configure the applicable HSS group with a the round-robin server allocation strategy. This functionality assumes the
HSS infrastructure itself is configured for redundancy.
The Oracle USM establishes and manages multiple Cx connections with each applicable HSS. This management is
achieved by connection identifiers on the Oracle USM that allow it to distinguish between connections. This provides
the network with the flexibility of being able to use multiple paths to a given HSS regardless of AVP values.
About HSS Groups
You configure HSS groups based on your redundancy and failover design. You accomplish this by configuring your
HSS groups with the applicable HSS servers. You then assign your group to a registrar. HSS group configuration does
not preclude assigning an HSS in the group to a registrar individually.
HSS groups can contain individual HSSs. Members of an HSS group are prioritized by the server list; the first server
in the list takes the highest priority; the last takes the lowest. You can manually disable an HSS group, if desired,
which prevents the Oracle USM from attempting to access any of the HSS servers via that group.
HSS group members do not need to reside in the same domain, network, or realm. The Oracle USM can allocate
traffic among member HSSs regardless of their location. It uses the allocation strategies you configure for the group
to distribute traffic across the group members.
Group allocation strategies define how the Oracle USM selects an HSS. For example, the hunt strategy selects HSSs
in the order in which they are listed. Allocation strategies include the following:
Allocation Strategy
Description
failover
For HSS redundancy deployments, the failover strategy specifies that the
Oracle USM selects the next highest priority HSS server for all operations if
the first HSS fails. The Oracle USM does not resume operation with the
initial HSS when it comes back into service.
hunt
For HSS redundancy deployments, the hunt strategy specifies that the Oracle
USM select HSSs in the order in which they are configured in the HSS
group. If the first HSS is available, all traffic is sent to the first HSS.
If the first HSS is unavailable, all traffic is sent to the second HSS. The
system follows this process for all HSS servers in the group. When a higher
priority HSS returns to service, all traffic is routed back to it.
roundrobin
This strategy targets HSS load balancing deployments. The Oracle USM
selects each HSS in the order in which it appears in the group list, routing
diameter requests to each HSS in turn.
Paths taken by specific messaging is constrained by the purpose of that messaging, and refined by a group’s allocation
strategy. Applicable messaging includes UAR/UAA, MAR/MAA, SAR/SAA and LIR/LIA. For both failover and
hunt strategies, all messaging is sent to the current active server. For the round-robin strategy, messaging is distributed
to group members sequentially, using the member list order.
Oracle® Communications Unified Session Manager
245
Oracle USM Supporting the IMS Core
Connection Failure Detection
The Oracle USM detects that a connection between itself and a given HSS has failed if either a diameter request fails
or the diameter DWR/DWA handshake fails. If the HSS does not respond to five requests, the Oracle USM marks that
HSS as out of service.
The Oracle USM forwards unacknowledged messages to subsequent HSSs based on strategy. It changes the
destination host AVP of these messages and marks then with the T flag. The HSS recognizes the T flag as an
indication that the request may be a duplicate, caused by a problem in the network.
Periodically, the Oracle USM attempts to establish diameter connections with out of service HSS servers. When those
connections succeed, the Oracle USM marks the HSS as in-service and resumes using it within the context of the
configured redundancy and load balancing strategy.
Configuring HSS Groups
To configure HSS groups:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter to access the system-level configuration elements.
ORACLE(configure)# session-router
3. Type hss-group and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(session-router)# hss-group
ORACLE(hss-group)#
4. name—Enter a unique name for the HSS group in Name format.
5. state—Enable or disable the HSS group on the Oracle USM. The default value is enabled. Valid values are:
• enabled | disabled
6. origin-host-identifier— Set this to a string for use in constructing a unique Origin Host AVP. This setting always
takes precedence over the origin-host-identifier configured for the home-subscriber-server. This setting is
required.
7. strategy—Indicate the HSS server allocation strategy you want to use. The strategy you chose selects the HSS
servers that will be made available by this hss-group. The default value is hunt. The valid values are:
•
hunt—Selects HSS servers in the order in which they are listed. For example, if the first server is online, all
traffic is sent to the first server. If the first server is offline, the second server is selected. If the first and second
servers are offline, the third server is selected. When the Oracle USM detects that a higher priority HSS is back
in service, it routes all subsequent traffic to that HSS.
• roundrobin—Selects each HSS server in the order in which they are listed in the destination list, selecting each
server in turn, one per session.
• failover — Selects the first server in the list until failure is detected. Subsequent signaling goes to the next
server in the list.
8. hss-configs—Identify the HSS servers available for use by this hss-group. This list can contain as many HSS
servers as is necessary. An hss-config list value must correspond to a valid hss-config.
Display syntax for the hss-configs parameter by typing the question mark character after the parameter name on
the ACLI.
ORACLE(hss-group)# hss-configs ?
<string> list of home-subscriber-server configs for this group
for single-entry: hss1
for multi-entry: (hss1 hss2)
for adding an entry to an existing list: +hss3
for deleting an entry from an existing list: -hss3
for multiple entries add/remove from a list: +/-(hss1 hss2)
The following example shows an HSS group using the hunt allocation strategy applied.
246
Oracle® Communications Unified Session Manager
Oracle USM Supporting the IMS Core
hss-group
name
state
origin-host-identifier
strategy
hss-configs
last-modified-by
last-modified-date
Oracle® Communications Unified Session Manager
group-test1
enabled
hunt
hss1, hss2
admin@console
2013-05-13 14:58:01
247
6
Routing with Local Policy
This chapter explains how to configure session routing and load balancing for SIP services using local policy and
session agents. It contains information about configuring session agents and session agent groups, as well as local
policies that can be used for routing SIP messaging.
Session Agents Session Groups and Local Policy
When you configure session routing for SIP, you can use session agents, session agent groups and local policies to
define routing. (Using session agents and session agent groups is not required.)
•
•
•
session agent: defines a signaling endpoint. It is a next hop signaling entity that can be configured to apply traffic
shaping attributes.
session agent group (SAG): contains individual session agents. Members of a SAG are logically equivalent
(although they might vary in their individual constraints) and can be used interchangeably.
You apply an allocation strategy to the SAG to allocate traffic across the group members. Session agent groups
also assist in load balancing among session agents.
local policy: indicates where session request messages, such as SIP INVITES, are routed and/or forwarded. You
use a local policy to set a preference for selecting one route over another.
Another element of routing is the realm. Realms are used when a any log level you set here overrides the log level
you set in the system configuration’s process log level parameter, communicates with multiple network elements over
a shared intermediate connection. Defining realms allows sessions to go through a connection point between the two
networks.
When you configure a realm, you give it an identifier, which stores the name of the realm associated with the any log
level you set here overrides the log level you set in the system configuration’s process log level parameter.. The realm
identifier value is also needed when you configure session agents and local policies. You can associate a realm with a
session agent to identify the realm for sessions coming from or going to the session agent. You also need the realm
identifier when you configure local policy to identify the egress realm (realm of the next hop).
About Session Agents
This section describes session agents. A session agent defines a signaling endpoint. It is a next hop signaling entity
that can be configured to apply traffic shaping attributes. Service elements such as gateways, softswitches, and
gatekeepers are defined automatically within the Oracle USM as session agents. For each session agent, concurrent
session capacity and rate attributes can be defined. You can group session agents together into session agent groups
and apply allocation strategies to achieve traffic load balancing.
Oracle® Communications Unified Session Manager
249
Routing with Local Policy
You can assign a media profile to a session agent.
You can configure a set of attributes and constraints for each session agent to support the following:
•
•
session access control: Oracle USM only accepts requests from configured session agents
session admission control (concurrent sessions): Oracle USM limits the number of concurrent inbound and
outbound sessions for any known service element.
session agent load balancing: session agents are loaded based on their capacity and the allocation strategy
specified in the session agent group.
session (call) gapping: Oracle USM polices the rate of session attempts to send to and receive from a specific
session agent.
•
•
Session Agent Groups
Session agent groups contain individual session agents. Members of a session agent group are logically equivalent
(although they might vary in their individual constraints) and can be used interchangeably. You can apply allocation
strategies to session agent groups.
Examples of session agent groups include the following:
•
•
•
•
•
application server cluster
media gateway cluster
softswitch redundant pair
SIP proxy redundant pair
gatekeeper redundant pair
Session agent group members do not need to reside in the same domain, network, or realm. The Oracle USM can
allocate traffic among member session agents regardless of their location. It uses the allocation strategies configured
for a SAG to allocate traffic across the group members.
Allocation strategies include the following:
Allocation Strategy
Description
Hunt
Oracle USM selects the session agents in the order in which they are
configured in the SAG. If the first agent is available, and has not exceeded
any defined constraints, all traffic is sent to the first agent.
If the first agent is unavailable, or is in violation of constraints, all traffic is
sent to the second agent. And so on for all session agents in the SAG. When
the first agent returns to service, the traffic is routed back to it.
Round robin
Oracle USM selects each session agent in the order in which it is configured,
routing a session to each session agent in turn.
Least busy
Oracle USM selects the session agent with the least number of active
sessions, relative to the maximum outbound sessions or maximum sessions
constraints (lowest percent busy) of the session agent.
Proportional distribution
Session agents are loaded proportionately based upon the respective
maximum session constraint value configured for each session agent.
Lowest sustained rate
Oracle USM routes traffic to the session agent with the lowest sustained
session rate, based on observed sustained session rate.
You apply allocation strategies to select which of the session agents that belong to the group should be used. For
example, if you apply the Hunt strategy session agents are selected in the order in which they are listed.
250
Oracle® Communications Unified Session Manager
Routing with Local Policy
Request URI Construction as Sent to SAG-member Session Agent
The Oracle USM constructs the request URI for a session agent selected from a session agent group by using the
session-agent > hostname value of the selected session-agent target. This default behavior enables features such as
trunk groups and ENUM to work properly. However, care must be given when the hostname parameter is not a
resolvable FQDN. The sag-target-uri=<value> option can be used to overcome the default behavior.
The value is either
•
•
ip – request URI constructed from session-agent > ip-address
host – request URI constructed from session-agent > hostname
This option is global and is configured in the sip-config configuration element.
Request URI Construction as Forwarded to SAG-member Session Agent
The Oracle USM constructs the request URI for a session agent selected from a session agent group by using the
session-agent > hostname value of the selected session-agent target. This default behavior enables features such as
trunk groups and ENUM to work properly. However, care must be given when the hostname parameter is not a
resolvable FQDN. Use the sag-target-uri=<value> option to override the default behavior.
The value can be set to either:
•
•
ip - request URI constructed from session-agent > ip-address
host - request URI constructed from session-agent > hostname
This option is global and is configured in the sip-config configuration element.
SIP Session Agent Group Recursion
You can configure a SIP session agent group (SAG) to try all of its session agents rather than to the next-best local
policy match if the first session agent in the SAG fails.
With this feature disabled, the Oracle USM performs routing by using local policies, trunk group URIs, cached
services routes, and local route tables. Local policies and trunk group URIs can use SAGs to find the most appropriate
next-hop session agent based on the load balancing scheme you choose for that SAG: round robin, hunt, proportional
distribution, least busy, and lowest sustained rate. When it locates a SAG and selects a specific session agent, the
Oracle USM tries only that single session agent. Instead of trying other members of the SAG, the Oracle USM
recurses to the local policy that is the next best match. This happens because the Oracle USM typically chooses a
SAG based on the fact that it has not breached its constraints, but the Oracle USM only detects failed call attempts
(due to unreachable next hops, unresolved ENUM queries, or SIP 4xx/5xx/6xx failure responses) after it has checked
constraints. So the Oracle USM only re-routes if there are additional matching local policies.
When you enable SIP SAG recursion, the Oracle USM will try the additional session agents in the selected SAG if the
previous session agent fails. You can also set specific response codes in the SAG configuration that terminate the
recursion. This method of terminating recursion is similar to the Oracle USM’s ability to stop recursion for SIP
interfaces and session agents.
Session agents are selected according to the strategy you set for the SAG, and these affect the way that the Oracle
USM selects session agents when this feature enabled:
•
•
Round robin and hunt—The Oracle USM selects the first session agent according to the strategy, and it selects
subsequent session agents based on the order they are entered into the configuration.
Proportional distribution, least busy, and lowest sustained rate—The Oracle USM selects session agents based on
the list of session agents sorted by the criteria specified.
You can terminate recursion based on SIP response codes that you enter into the SAG configuration. You can
configure a SAG with any SIP response code in the 3xx, 4xx, and 5xx groups. Since you can also set such a list in the
session agent configuration, this list is additive to that one so that you can define additional codes for a session agent
group with out having to repeat the ones set for a session agent.
Oracle® Communications Unified Session Manager
251
Routing with Local Policy
SIP Session Agents
SIP session agents can include the following:
•
•
•
•
•
softswitches
SIP proxies
application servers
SIP gateways
SIP endpoints
In addition to functioning as a single logical next hop for a signaling message (for example, where a SIP INVITE is
forwarded), session agents can provide information about next or previous hops for packets in a SIP agent, including
providing a list of equivalent next hops.
You can use the session agent to describe one or more SIP next or previous hops. Through the configured carriers list,
you can identify the preferred carriers to use for traffic coming from the session agent. This set of carriers will be
matched against the local policy for requests coming from the session agent. You can also set constraints for specific
hops.
Session Agent Status Based on SIP Response
The Oracle USM can take session agents out of service based on SIP response codes that you configure, and you can
also configure SIP response codes that will keep the session agent in service.
With this feature disabled, the Oracle USM determines session agents’ health by sending them ping messages using a
SIP method that you configure. Commonly, the method is an OPTIONS request. If it receives any response from the
session agent, then the Oracle USM deems that session agent available for use.
However, issues can arise when session agents are administratively out of service, but able to respond to OPTIONs
requests. A session agent like this might only respond with a 200 OK when in service, and send a 4xx or 5xx message
otherwise.
The session agent status feature lets you set the SIP response message that either takes a session agent out of service
or allows it to remain in service when it responds to the Oracle USM’s ping request.
Details of this feature are as follows:
•
•
The Oracle USM only considers a session agent in service when it responds to a request method you set with the
final response code that you also set. If a final response code is set, then provisional responses are not used for
determining whether or not to take a session agent out of service. If the Oracle USM receives a final response
code that does not match the session agent configuration, it treats the session agent as though it had not responded.
The Oracle USM takes a session agent out of service when it receives an error response for dialog creating request
with a response code listed in the new out-service-response-codes parameter.
In the case where a the session agent’s response has a Retry-After header, the Oracle USM tries to bring the session
agent back into service after the period of time specified in the header. To do so, it sends another ping request.
There are two lists you can configure in the session agent configuration to determine status:
•
•
In-service list—Set in the ACLI ping-in-service-response-codes parameter, this list defines the response codes that
keep a session agent in service when they appear in its response to the Oracle USM’s ping request. Furthermore,
the Oracle USM takes the session agent out of service should a response code be used that does not appear on this
list.
Out-of-service list—Set in the ACLI out-service-response-codes parameter, this list defines the response codes
that take a session agent out of service when they appear in its response to the Oracle USM’s ping request or any
dialog-creating request.
When the Oracle USM receives a session agent’s response to its ping request, it first checks to see if there is an inservice list of responses configured for that session agent. If the list is configured and the Oracle USM determines that
there is a match, the session agent is deemed in service. Otherwise it takes the session agent out of service. In this
252
Oracle® Communications Unified Session Manager
Routing with Local Policy
way, the in-service list takes precedence over the out-of-service list. If you configure the in-service list, then the
Oracle USM ignores the out-of-service list.
If there is no list of in-service responses for the session agent, then the Oracle USM checks the out of service list. If it
is configured and the Oracle USM determines that there is a match, the Oracle USM removes that session agent from
service. If there is no match, then the session agent is deemed in service.
SIP Session Agent Continuous Ping
You can configure the Oracle USM to use either a keep-alive or continuous method for pinging SIP session agents to
determine their health—i.e., whether or not the Oracle USM should route requests to them. To summarize the two
methods:
•
•
keep-alive— Oracle USM sends a ping message of a type you configure to the session agent in the absence of
regular traffic. Available in Release C5.1.0 and in earlier releases.
continuous—The Oracle USM sends a ping message regardless of traffic state (regular or irregular); the Oracle
USM regularly sends a ping sent based on the configured ping interval timer. Available in Release C5.1.1p6 and in
later releases.
By sending ping messages, the Oracle USM monitors session agents’ health and can determine whether or not to take
a session out of service (OOS), leave it in service, or bring it back into service after being OOS.
When you set it to use the keep-alive mode of pinging (available in Release C5.1.0 and before), the Oracle USM
starts sending a configured ping message to a session agent when traffic for that session agent has become irregular.
The Oracle USM only sends the ping if there are no SIP transactions with a session agent over a configurable period
of time, to which the session agent’s response can have one of the following results:
•
•
•
Successful response—A successful response is either any SIP response code or any response code not found in the
out-service-response-codes parameter; these leave the session agent in service. In addition, any successful
response or any response in the ping-in-service-response-codes parameter can bring a session agent from OOS to
in-service status.
Unsuccessful response—An unsuccessful response is any SIP response code configured in the out-serviceresponse-codes parameter and takes the session agent sending it OOS. Because this parameter is blank by default,
the Oracle USM considers any SIP response code successful.
Transaction timeout—A transaction timeout happens when the session agent fails to send a response to the Oracle
USM’s request, resulting in the session agent’s being taken OOS.
Despite the fact that the keep-alive ping mode is a powerful tool for monitoring session agents’ health, you might
want to use the continuous ping method if you are concerned about the Oracle USM not distinguishing between
unsuccessful responses from next-hop session agents and ones from devices downstream from the next-hop session
agent. For example, if a SIP hop beyond the session agent responds with a 503 Service Unavailable, the Oracle USM
does not detect whether a session agent or the device beyond it generated the response.
When you use the continuous ping method, only the next-hop session agent responds—preventing the request from
being sent to downstream devices. The Oracle USM also sends the ping in regular traffic conditions when in
continuous ping mode, so it is certain the response comes from the next hop associated with the session agent. And in
continuous ping mode, only entries for the ping-out-service-response-codes parameter and transaction timeouts bring
session agents OOS.
SIP SA Continuous Ping Configuration
You can set the ping mode in the session agent or session constraints configuration. For backward compatibility, the
default for the ping-send-mode parameter is keep-alive, or the functionality available in Release C5.1.0 and in earlier
releases.
To configure the ping mode for a session agent:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
2. Type session-router and press Enter.
Oracle® Communications Unified Session Manager
253
Routing with Local Policy
ORACLE(configure)# session-router
ORACLE(session-router)#
3. Type session-agent and press Enter.
ORACLE(session-router)# session-agent
ORACLE(session-agent)#
If you are adding rate constraints to an existing configuration, then you will need to select the configuration you
want to edit.
4. ping-send-mode—If to want to use continuous ping mode to send ping messages to session agents in regular
traffic conditions, set this parameter to continuous. If you want to use the keep-alive mode, leave this parameter
set to keep-alive (default).
5. Save and activate your configuration.
To configure the ping mode for the session constraints:
6. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
7. Type session-router and press Enter.
ORACLE(configure)# session-router
ORACLE(session-router)#
8. Type session-constraints and press Enter.
ORACLE(session-router)# session-constraints
ORACLE(session-constraints)#
If you are adding rate constraints to an existing configuration, then you will need to select the configuration you
want to edit.
9. ping-send-mode—If to want to use continuous ping mode to send ping messages to session agents in regular
traffic conditions, set this parameter to continuous. If you want to use the keep-alive mode, leave this parameter
set to keep-alive (default).
10. Save and activate your configuration.
About Local Policy
This section explains the role of local policy. Local policy lets you indicate where session requests, such as SIP
INVITES, should be routed and/or forwarded. You use a local policy to set a preference for selecting one route over
another. The local policy contains the following information that affects the routing of the SIP signaling messages:
•
information in the From header
•
Information in the message’s From header is matched against the entries in the local policy’s from address
parameter to determine if the local policy applies.
list of configured realms
•
This list identifies from what realm traffic is coming and is used for routing by ingress realm. The source realms
identified in the list must correspond to the valid realm IDs you have already configured
local policy attributes
The attributes serve as an expression of preference, a means of selecting one route over another. They contain
information such as the next signaling address to use (next hop) or whether you want to select the next hop by
codec, the realm of the next hop, and the application protocol to use when sending a message to the next hop. You
can also use the attributes to filter specific types of traffic.
Routing Calls by Matching Digits
Local policy routing of a call can be based on matching a sequence of digits against what is defined in the local
policy. This sequence refers to the first digits in the (phone) number, matching left to right.
254
Oracle® Communications Unified Session Manager
Routing with Local Policy
The following examples show how the Oracle USM matches an area code or number code against configured local
policies.
•
•
If the number or area code being matched is 1234567 (where 123 is an area code), and the from address value in
one local policy is 123, and the from address value in another local policy is 12, the Oracle USM forwards the call
to the server that is defined as the next hop in the local policy with 123 as the from address value.
If the number or area code being matched is 21234, and the from address value in one local policy is 123, and the
from address value in another local policy is 12, the Oracle USM will not find a match to either local policy
because the first character of the number or area code must match the first character in a from address or to
address field.
The following examples show how the Oracle USM matches an area or number code against different local policies:
the first one has a From address value of 12 and the second has a From address value of 123. The Oracle USM
chooses the route of the local policy that is configured with the most digits matching the area or number code in its
From address and To address fields.
•
•
When the two different local policies route to two different servers, and the area or number code being matched is
123, the Oracle USM selects the second local policy based on the From address value of 123.
When the two different local policies route to two different servers, and the area or number code being matched is
124, the Oracle USM selects the first local policy based on the From address value of 12.
Route Preference
The Oracle USM builds a list of possible routes based on the source realm and the From-address (From-URI) and Toaddress (Request-URI), which forms a subset from which preference then decides. Any local policy routes currently
outside of the configured time/day are not used, if time/day are set. Also, any local policy routes not on the list of
carriers (if carriers is set and the requests has a Carrier header) are not used.
Note: Source realm is used in the local policy lookup process, but it is not used in route preference
calculations.
The Oracle USM applies preference to configured local policies in the following order:
1. Cost (cost in local policy attributes) is always given preference.
2. Matching media codec (media profiles option in local policy attributes).
3. Longest matching To address (to address list in local policy).
4. Shortest matching To address (to address list in local policy).
5. Longest matching From address (from address list in local policy).
6. Shortest matching From address (from address list in local policy).
7. Narrowest/strictest day of week specification (days of week option in local policy attributes).
8. Narrowest/strictest time of day specification (start time and end time options in local policy attributes).
9. Wildcard matches (use of an asterisk as a wildcard value for the from address and to address lists in local policy).
10. Wild card matches are given the least preference. A prefix value of 6 is given a higher preference than a prefix
value of * even though both prefix values are, in theory, the same length.
DTMF-Style URI Routing
The Oracle USM supports the alphanumeric characters a-d, A-D, the asterisk (*), and the ampersand (#) for local
policy matching purposes. The Oracle USM handles these characters as standards DN (POTS) or FQDN when found
in the to-addr (req-uri username) or from-addr (from0uri username for SIP, SIPS, and TEL URIs.
In addition, before performing the lookup match, the Oracle USM strips characters that provide ease-of-reading
separation. For example, if the Oracle USM were to receive a req-uri containing tel:a-#1-781-328-5555, it would treat
it as tel:a#17813285555.
Oracle® Communications Unified Session Manager
255
Routing with Local Policy
SIP Routing
This section describes SIP session routing. When routing SIP call requests, the Oracle USM communicates with other
SIP entities, such as SIP user devices, other SIP proxies, and so on, to decide what SIP-based network resource each
session should visit next. The Oracle USM processes SIP call requests and forwards the requests to the destination
endpoints to establish, maintain, and terminate real-time multimedia sessions.
Certain items in the messages are matched with the content of the local policy, within constraints set by the previous
hop session agent, and the SIP configuration information (for example, carrier preferences) to determine a set of
applicable next hop destinations.
The sending session agent is validated as either a configured session agent or a valid entry in a user cache. If the
session INVITATION does not match any registering user, the SIP proxy determines the destination for routing the
session INVITATION.
Limiting Route Selection Options for SIP
You can configure the local policy to use the single most-preferred route. And you can configure the SIP
configuration max routes option to restrict the number of routes which can be selected from a local policy lookup:
•
•
A max-routes=1 value limits the Oracle USM to only trying the first route from the list of available preferred
routes.
A max-routes=0 value or no max-routes value configured in the options field allows the Oracle USM to use all of
the routes available to it.
About Loose Routing
According to RFC 3261, a proxy is loose routing if it follows the procedures defined in the specification for
processing of the Route header field. These procedures separate the destination of the request (present in the RequestURI) from the set of proxies that need to be visited along the way (present in the Route header field).
When the SIP NAT’s route home proxy field is set to enabled, the Oracle USM looks for a session agent that matches
the home proxy address and checks the loose routing field value. If the loose routing is:
•
•
enabled—A Route header is included in the outgoing request in accordance with RFC 3261.
disabled—A Route header is not included in the outgoing request; in accordance with the route processing rules
described in RFC 2543 (referred to as strict routing). That rule caused proxies to destroy the contents of the
Request-URI when a Route header field was present.
Whether loose routing field is enabled is also checked when a local policy ‘s next hop value matches a session agent.
Matching occurs if the hostname or the session agent’s IP address field value corresponds to the next hop value. If
loose routing is enabled for the matching session agent, the outgoing request retains the original Request-URI and
Route header with the next hop address.
About the Ingress Realm
You can create a list of realms in your local policy that is used by the Oracle USM to determine how to route traffic.
This list determines from which realm traffic is coming and is used for routing by ingress realm.
The source realm values must correspond to valid identifier entered when the realm was configured.
About the Egress Realm
An egress realm allows SIP signaling to travel out of the Oracle USM through a network other than the home realm.
The Oracle USM uses egress realms for signaling purposes (when matching flows). When a packet arrives at the
Oracle USM with a destination address that does not match any defined session agents, the Oracle USM uses the
address associated with the realm that is, in turn, associated with the SIP configuration’s egress realm ID, as the
outgoing network. With the use of the egress realm ID, it is possible to define a default route for SIP requests
addressed to destinations outside the home realm. If no egress realm is defined, the home realm (default ingress
realm) is used as the default egress realm.
256
Oracle® Communications Unified Session Manager
Routing with Local Policy
With session agent egress realm configured, the Oracle USM adds a default egress realm to the session agent to
identify the signaling interface used for ping requests. The Oracle USM also uses the default egress realm when the
normal routing request does not yield an egress realm—for example, when a local policy does not specify the next
hop’s realm.
When you configure session agents, you can define them without realms or you can wildcard the realm value. These
are global session agents, and multiple signaling interfaces can reach them. Then, when you use session agent
pinging, the Oracle USM sends out ping requests using the signaling interface of the default egress realm defined in
the global SIP configuration. The global session agents in certain environments can cause problems when multiple
global session agents residing in multiple networks, some of which might not be reachable using the default SIP
interface egress realm.
The Oracle USM uses the session agent egress realm for ping messages even when the session agent has a realm
defined. For normal request routing, the Oracle USM uses the egress realm for global session agents when local
policies or SIP-NAT bridge configurations do not point to an egress realm.
Ping Message Egress Realm Precedence
For ping messages, the egress realm precedence occurs in the following way (in order of precedence):
•
•
•
•
Egress realm identified for the session agent.
Session agent realm (set in the realm-id parameter) or the wildcarded value
Global SIP configuration egress realm, when configured in the egress-realm parameter
Global SIP configuration home realm
Normal Request Egress Realm Precedence
For normal request routing, the egress realm precedence occurs in the following way (in order of precedence):
•
•
•
•
•
•
Egress SIP-NAT realm, when the route-home-proxy parameter is set to forced and no local policy match is found
Matching local policy realm, when configured in the local policy attributes
Session agent realm (set in the realm-id parameter) or the wildcarded value
Session agent egress realm, when configured in the egress-realm-id parameter
Global SIP configuration egress realm, when configured in the egress-realm parameter
Global SIP configuration home realm
Session Agent Egress Realm Configuration
Configuring a session agent egress realm is optional.
To configure a session agent egress realm:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
2. Type session-router and press Enter.
ORACLE(configure)# session-router
ORACLE(session-router)#
3. Type session-agent and press Enter.
ORACLE(session-router)# session-agent
ORACLE(session-agent)#
If you are adding this feature to an existing configuration, you need to select the configuration (using the ACLI
select command) before making your changes.
4. egress-realm-id—Enter the name of the realm you want defined as the default egress realm used for ping
messages. The Oracle USM will also use this realm when it cannot determine the egress realm from normal
routing. There is no default value for this parameter.
5. Save and activate your configuration.
Oracle® Communications Unified Session Manager
257
Routing with Local Policy
About SIP Redirect
SIP redirect involves proxy redirect and tunnel redirect.
Proxy Redirect
You can configure the SIP proxy mode to define how the SIP proxy will forward requests coming from the session
agent. This value is used if the session agent’s proxy mode has no value (is empty).
Tunnel Redirect
You can use tunnel redirect when requests are routed to a server behind a SIP NAT that sends redirect responses with
addresses that should not be modified by the SIP NAT function. For example, a provider might wish to redirect
certain calls (like 911) to a gateway that is local to a the UA that sent the request. Since the gateway address is local
to the realm of the UA, it should not be modified by the SIP NAT of the server’s realm. Note that the server must have
a session agent configured with the redirect-action field set to the proxy option in order to cause the redirect response
to be sent back to the UA.
SIP Method Matching and To Header Use for Local Policies
For SIP, this feature grants you greater flexibility when using local policies and has two aspects: basing local policy
routing decisions on one or more SIP methods you configure and enabling the Oracle USM to use the TO header in
REGISTER messages for routing REGISTER requests.
SIP Methods for Local Policies
This feature allows the Oracle USM to include SIP methods in routing decisions. If you want to use this feature, you
set a list of one or more SIP methods in the local policy attributes. These are the SIP methods you can enter in the list:
INVITE, REGISTER, PRACK, OPTIONS, INFO, SUBSCRIBE, NOTIFY, REFER, UPDATE, MESSAGE, and
PUBLISH.
After the Oracle USM performs a local policy look-up for SIP, it then searches for local policy attributes that have this
methods list configured. If it finds a a set of policy attributes that matches a method that matches the traffic it is
routing, the Oracle USM uses that set of policy attributes. This means that the Oracle USM considers first any policy
attributes with methods configured before it considers those that do not have methods. In the absence of any policy
attributes with methods, the Oracle USM uses the remaining ones for matching.
In cases where it finds neither matching policy attributes with methods or matching policy attributes without them,
the Oracle USM either rejects the calls with a 404 No Routes Found (if the request calls for a response) or drops the
call.
You configure local policy matching with SIP methods in the local policy attributes parameter calls methods. This
parameter is a list that takes either one or multiple values. If you want to enter multiple values, you put them in the
same command line entry, enclosed in quotation marks and separated by spaces.
To configure SIP methods for local policy matching:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
2. Type session-router and press Enter.
ORACLE(configure)# session-router
ORACLE(session-router)#
3. Type local-policy and press Enter. If you are adding this feature to a pre-existing local policy configuration, you
will need to select and edit your local policy.
ORACLE(session-router)# local-policy
ORACLE(local-policy)#
4. Type policy-attributes and press Enter. If you are adding this feature to a pre-existing local policy configuration,
you will need to select and edit your local policy.
258
Oracle® Communications Unified Session Manager
Routing with Local Policy
ORACLE(local-policy))# policy-attributes
ORACLE(policy-attributes)#
5. methods—Enter the SIP methods you want to use for matching this set of policy attributes. Your list can include:
INVITE, REGISTER, PRACK, OPTIONS, INFO, SUBSCRIBE, NOTIFY, REFER, UPDATE, MESSAGE, and
PUBLISH.
By default, this parameter is empty—meaning that SIP methods will not be taken into consideration for routing
based on this set of policy attributes.
If you want to enter more than one method, you entry will resemble the following example.
ACMEPACKET(local-policy-attributes)# methods "PRACK INFO REFER"
6. Save and activate your configuration.
Routing Using the TO Header
For the Oracle USM’s global SIP configuration, you can enable the use of an ENUM query to return the SIP URI of
the Registrar for a SIP REGISTER message. Without this feature enabled, the Oracle USM uses the REQUEST URI.
This ability can be helpful because REGISTER messages only have the domain in the REQUEST URI, whereas the
SIP URI in the To header contains the user’s identity.
There are two parts to enabling this feature. First, you must enable the register-use-to-for-lp parameter in the global
SIP configuration. Then you can set the next-hop in the applicable local policy attributes set to ENUM.
To enable your global SIP configuration for routing using the TO header:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
2. Type session-router and press Enter.
ORACLE(configure)# session-router
ORACLE(session-router)#
3. Type sip-config and press Enter. If you are adding this feature to a pre-existing SIP configuration, you will need to
select and edit it.
ORACLE(session-router)# sip-config
ORACLE(sip-config)#
4. register-use-to-for-lp—Set this parameter to enabled if you want the Oracle USM to use, for routing purposes, an
ENUM query to return the SIP URI of the Registrar for a SIP REGISTER message. This parameters defaults to
disabled.
To set up your local policy attributes for routing using the TO header:
5. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
6. Type session-router and press Enter.
ORACLE(configure)# session-router
ORACLE(session-router)#
7. Type local-policy and press Enter. If you are adding this feature to a pre-existing local policy configuration, you
will need to select and edit your local policy.
ORACLE(session-router)# local-policy
ORACLE(local-policy)#
8. Type policy-attributes and press Enter. If you are adding this feature to a pre-existing local policy configuration,
you will need to select and edit your local policy.
ORACLE(local-policy))# policy-attributes
ORACLE(policy-attributes)#
Oracle® Communications Unified Session Manager
259
Routing with Local Policy
9. next-hop—This is the next signaling host. Set this parameter to ENUM if you want to use SIP methods in local
policy attribute information for routing purposes.
10. Save and activate your configuration.
Load Balancing
This section describes Oracle USM load balancing. You can use session agent groups to assist in load balancing
among session agents. You define concurrent session capacity and rate attributes for each session agent and then
define the session agent group. Next, you select the allocation strategy you want applied to achieve the load balancing
you want.
The following example shows a configuration for load balancing gateways based on a proportional allocation
strategy.
Routing and load balancing capabilities include the following:
•
•
•
•
•
•
•
•
•
260
least cost, which includes cost-based and time-based routing
customer preference
traffic aggregation
routing by media (codec) type
capacity-based, by destination
service element load balancing
service element failure detection and re-route
session agent failure
routing by codec
Oracle® Communications Unified Session Manager
Routing with Local Policy
Configuring Routing
This section explains how to configure routing on the Oracle USM.
Configuration Prerequisite
You should have already configured the realms for your environment before you configure the routing elements. You
need to know the realm identifier when configuring session agents and local policy.
You can use an asterisk (*) when the session agent exists in multiple realms.
Configuration Order
Recommended order of configuration:
•
•
•
•
realm
session agent
session agent group
local policy
Routing Configuration
You can enable, then configure, individual constraints that are applied to the sessions sent to the session agent. These
constraints can be used to regulate session activity with the session agent. In general, session control constraints are
used for session agent groups or SIP proxies outside or at the edge of a network. Some individual constraints, such as
maximum sessions and maximum outbound sessions are not applicable to core proxies because they are transaction
stateful, instead of session stateful. Other constraints, such as maximum burst rate, burst rate window, maximum
sustained rate, and sustained rate are applicable to core routing proxies.
Configuring Session Agents
To configure session agents:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter to access the system-level configuration elements.
ORACLE(configure)# session-router
3. Type session-agent and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(session-router)# session-agent
ORACLE(session-agent)#
4. host-name—Enter the name of the host associated with the session agent in either hostname or FQDN format, or
as an IP address.
If you enter the host name as an IP address, you do not have to enter an IP address in the optional IP address
parameter. If you enter the host name in FQDN format, and you want to specify an IP address, enter it in the
optional IP address parameter. Otherwise you can leave the IP address parameter blank to allow a DNS query to
resolve the host name.
If the initial DNS query for the session agent fails to get back any addresses, the session agent is put out-ofservice. When session agent is pinged, the DNS query is repeated. The ping message is not sent until the DNS
query gets back one or more IP addresses. After the query receives some addresses, the ping message is sent. The
session agent remains out of service until one of the addresses responds.
Note: The value you enter here must be unique to this session agent. No two session agents can have the
same hostname.
The hostnames established in the session agent populate the corresponding fields in other elements.
Oracle® Communications Unified Session Manager
261
Routing with Local Policy
5. ip-address—Optional. Enter the IP address for the hostname you entered in FQDN format if you want to specify
the IP address. Otherwise, you can leave this parameter blank to allow a DNS query to resolve the host name.
6. port—Enter the number of the port associated with this session agent. Available values include:
•
•
zero (0)—If you enter zero (0), the Oracle USM will not initiate communication with this session agent
(although it will accept calls).
1025 through 65535
The default value is 5060.
Note: If the transport method value is TCP, the Oracle USM will initiate communication on that port
of the session agent.
7. state—Enable or disable the session agent by configuring the state. By default, the session agent is enabled.
• enabled | disabled
8. transport-method—Indicate the IP protocol to use (transport method) to communicate with the session agent. UDP
is the default value. The following protocols are supported:
•
UDP—Each UDP header carries both a source port identifier and destination port identifier, allowing highlevel protocols to target specific applications and services among hosts.
• UDP+TCP—Allows an initial transport method of UDP, followed by a subsequent transport method of TCP if
and when a failure or timeout occurs in response to a UDP INVITE. If this transport method is selected,
INVITEs are always sent through UDP as long as a response is received.
• DynamicTCP—dTCP indicates that dynamic TCP connections are the transport method for this session agent.
A new connection must be established for each session originating from the session agent. This connection is
torn down at the end of a session.
• StaticTCP—sTCP indicates that static TCP connections are the transport method for this session agent. Once a
connection is established, it remains and is not torn down.
• DynamicTLS—dTLS indicates that Dynamic TLS connections are the transport method for this session agent.
A new connection must be established for each session originating from the session agent. This connection is
torn down at the end of a session.
• StaticTLS—sTLS indicates that Static TLS connections are the transport method for this session agent. Once a
connection is established, it will remain and not be torn down.
9. realm-id—Optional. Indicate the ID of the realm in which the session agent resides.
The realm ID identifies the realm for sessions coming from or going to this session agent. For requests coming
from this session agent, the realm ID identifies the ingress realm. For requests being sent to this session agent, the
realm ID identifies the egress realm. In a Oracle USM, when the ingress and egress realms are different, the media
flows must be steered between the realms.
•
•
no value: the egress realm is used unless the local policy dictates otherwise
asterisk (*): keep the egress realm based on the Request URI
Note: The realm ID you enter here must match the valid identifier value entered when you configured
the realm.
10. description—Optional. Enter a descriptive name for this session agent.
11. carriers—Optional. Add the carriers list to restrict the set of carriers used for sessions originating from this session
agent.
Carrier names are arbitrary names that can represent specific service providers or traditional PSTN telephone
service providers (for sessions delivered to gateways). They are global in scope, especially if they are exchanged
in TRIP. Therefore, the definition of these carriers is beyond the scope of this documentation.
You could create a list using carrier codes already defined in the North American Numbering Plan (NANP); or
those defined by the local telephone number or carrier naming authority in another country.
Note: If this list is empty, any carrier is allowed. If it is not empty, only local policies that reference one or
more of the carriers in this list will be applied to requests coming from this session agent.
12. allow-next-hop-lp—Indicate whether this session agent can be used as a next hop in the local policy.
262
Oracle® Communications Unified Session Manager
Routing with Local Policy
If you retain the default value of enabled, the session agent can be used as the next hop for the local policy. Valid
values are:
• enabled | disabled
13. constraints—Enable this parameter to indicate that the individual constraints you configure in the next step are
applied to the sessions sent to the session agent. Retain the default value of disabled if you do not want to apply
the individual constraints. Valid values are:
•
enabled | disabled
Note: In general, session control constraints are used for SAGs or SIP proxies outside or at the edge of
a network.
14. Enter values for the individual constraints you want applied to the sessions sent to this session agent. The
following table lists the available constraints along with a brief description and available values.
Constraint
Description
maximum sessions
Maximum number of sessions (inbound and outbound) allowed by the
session agent. The range of values is:
•
•
maximum outbound sessions
minimum: zero (0) is the default value and means there is no limit
maximum: 4294967295
Maximum number of simultaneous outbound sessions (outbound from
the Oracle USM) that are allowed from the session agent. The range of
values is:
•
•
minimum: zero (0) is the default value and means there is no limit
maximum: 4294967295
The value you enter here cannot be larger than the maximum sessions
value.
maximum burst rate
Number of session invitations allowed to be sent to or received from the
session agent within the configured burst rate window value. SIP
session invitations arrive at and leave from the session agent in
intermittent bursts. By entering a value in this field, you can limit the
amount of session invitations that are allowed to arrive at and leave
from the session-agent.
For example, if you enter a value of 50 here and a value of 60 (seconds)
for the burst rate window constraint, no more than 50 session
invitations can arrive at or leave from the session agent in that 60
second time frame (window). Within that 60-second window, any
sessions over the limit of 50 are rejected.
The range of values is:
•
•
minimum: zero (0) session invitations per second
maximum: 4294967295 session invitations per second
Zero is the is the default value.
maximum sustain rate
Maximum rate of session invitations (per second) allowed to be sent to
or received from the session agent within the current window. The
current rate is determined by counting the number of session invitations
processed within a configured time period and dividing that number by
the time period. By entering a value in this field, you can limit the
amount of session invitations that are allowed to arrive at and leave
from the session agent over a sustained period of time.
Oracle® Communications Unified Session Manager
263
Routing with Local Policy
Constraint
Description
For the sustained rate, the Oracle USM maintains a current and
previous window size. The period of time over which the rate is
calculated is always between one and two window sizes.
For example, if you enter a value of 5000 here and a value of 3600
(seconds) for the sustain rate window constraint, no more than 5000
session invitations can arrive at or leave from the session agent in any
given 3600 second time frame (window). Within that 3600-second
window, sessions over the 5000 limit are rejected.
The range of values is:
•
•
minimum: zero (0) invitations per second
maximum: 4294967295 invitations per second
Zero is the is the default value.
The value you set here must be larger than the value you set for the
maximum burst rate constraint.
time to resume
Time in seconds after which the SIP proxy resumes sending session
invitations to this session agent. This value only takes effect when the
SIP proxy stops sending invitations because a constraint is exceeded.
The range of values is:
•
•
minimum: zero (0) seconds
maximum: 4294967295 seconds
Default is zero.
time to resume (ttr) no response
Delay in seconds that the SIP proxy must wait from the time that it
sends an invitation to the session agent and gets no response before it
tries again.
The range of values is:
•
•
minimum: zero (0) seconds
maximum: 4294967295 seconds
Default is zero.
The value you enter here must be larger than the value you enter for the
time to resume constraint.
in service period
Amount of time in seconds the session agent must be operational (once
communication is re-established) before the session agent is declared as
being in-service (ready to accept session invitations). This value gives
the session agent adequate time to initialize.
The range of values is:
•
•
minimum: zero (0) seconds
maximum: 4294967295 seconds
Default is zero.
burst rate window
Burst window period (in seconds) that is used to measure the burst rate.
The term window refers to the period of time over which the burst rate
is computed. Refer to the maximum burst rate information.
The range of values is:
264
Oracle® Communications Unified Session Manager
Routing with Local Policy
Constraint
Description
•
•
minimum: zero (0) seconds
maximum: 4294967295seconds
Zero is the is the default value.
The value you set here must be smaller than the value you set for the
maximum burst rate constraint.
sustain rate window
Sustained window period (in seconds) that is used to measure the
sustained rate. Refer to the maximum sustain rate information.
The range of values is:
•
•
minimum: zero (0) seconds
maximum: 4294967295seconds
Zero is the is the default value.
The value you set here must be larger than the value you set for the
maximum sustain rate constraint.
15. req-uri-carrier-mode—SIP only. Set whether you want the selected carrier (determined by a value in the local
policy) added to the outgoing message by configuring the request uri carrier mode parameter.
You can set this parameter to let the system perform simple digit translation on calls sent to gateways. A 3-digit
prefix is inserted in front of the telephone number (the Request-URI) that the gateway will use to select a trunk
group. Most often, the Oracle USM needs to insert the carrier code into the signaling message that it sends on.
The default value is none. The following lists the available modes.
•
•
•
none—Carrier information will not be added to the outgoing message.
uri-param—Adds a parameter to the Request-URI. For example, cic-XXX.
prefix—Adds the carrier code as a prefix to the telephone number in the Request-URI (in the same manner as
PSTN).
16. proxy-mode—SIP only. Indicate the proxy mode to use when a SIP request arrives from this session agent.
If this field is empty (upon initial runtime or upgrade), it’s value is set to the value of the SIP configuration’s
proxy mode by default. If no proxy mode value was entered for the SIP configuration, the default for this field is
proxy.
The following are valid proxy modes:
•
proxy—If the Oracle USM is a Session Router, the system will proxy the request coming from the session
agent and maintain the session and dialog state. If the Oracle USM is a Session Director, the system behaves as
a B2BUA when forwarding the request.
• redirect—The system sends a SIP 3xx reDIRECT response with contacts (found in the local policy) to the
previous hop.
17. redirect-action—SIP only. Indicate the action you want the SIP proxy to take when it receives a Redirect (3XX)
response from the session agent.
The following table lists the available proxy actions along with a brief description
•
•
•
recurse-305-only—(default) If the Oracle USM receives a 305 SIP redirect response (Use Proxy) on the SIP
interface, it automatically redirects all requests to the Contact URI specified in the 305 response. All other 3xx
responses are sent back to the previous hop.
proxy—The SIP proxy passes the response back to the previous hop; based on the proxy mode of the original
request.
recurse—The SIP proxy serially sends the original request to the list of contacts in the Contact header of the
response (in the order in which the contacts are listed in the response). For example, if the first one fails, the
Oracle® Communications Unified Session Manager
265
Routing with Local Policy
request will be send to the second, and so on until the request succeeds or the last contact in the Contact header
has been tried.
18. loose-routing—SIP only. Enable this parameter if you want to use loose routing (as opposed to strict routing). The
default is enabled. Valid values are:
•
enabled | disabled
When the SIP NAT route home proxy parameter is enabled, the Oracle USM looks for a session agent that
matches the home proxy address and checks the loose routing value. If loose routing is enabled, a Route
header is included in the outgoing request in accordance with RFC 3261. If loose routing is disabled, the Route
header is not included in the outgoing request (in accordance with strict routing procedures defined in RFC
2543).
The loose routing value is also checked when the local policy’s next hop value matches a session agent. If
loose routing is set to enabled, the outgoing request retains the original Request-URI and Route header with
the next hop address.
19. send-media-session—SIP only. Enable this parameter if you want to include a media session description (for
example, SDP) in the INVITE or REINVITE message sent by the Oracle USM. Setting this field to disabled
prevents the Oracle USM from establishing flows for that INVITE message.
The default is enabled. Valid values are:
•
enabled | disabled
Note: Only set send media session to disabled for a session agent that always redirects requests. It
returns an error or 3xx response instead of forwarding an INVITE message.
20. response-map—Optional and for SIP only. Enter the name of the response map to use for this session agent. The
mappings in each SIP response map is associated with a corresponding session agent. You can also configure this
value for individual SIP interfaces.
21. ping-method—SIP only. Indicate the SIP message/method to use to ping a session agent. The ping confirms
whether the session agent is in service. If this field is left empty, no session agent will be pinged.
Setting this field value to the OPTIONS method might produce a lengthy response from certain session agents and
could potentially cause performance degradation on your Oracle USM.
22. ping-interval—SIP only. Indicate how often you want to ping a session agent by configuring the ping interval
parameter. Enter the number of seconds you want the Oracle USM to wait between pings to this session agent.
The default value is 0. The valid range is:
•
•
Minimum: 0
Maximum: 999999999
The Oracle USM only sends the ping if no SIP transactions (have occurred to/from the session agent within the
time period you enter here.
23. trunk-group—Enter up to 500 trunk groups to use with this single session agent. Because of the high number of
trunk groups you can enter, the ACLI provides enhanced editing mechanisms for this parameter:
•
You use a plus sign (+) to add single or multiple trunk groups to the session agent’s list.
When you add a single trunk group, simply use the plus sign (+) in front of the trunk group name and context.
Do not use a Space between the plus sign and the trunk group name and context.
For example, you might have already configured a list of trunk groups with the following entries:
tgrpA:contextA, tgrpB:contextB, and tgrpC:contextC. To add tgrp1:context1, you would make the following
entry:
ORACLE(session-agent)# trunk-group +tgrp1:context1
Your list would then contain all four trunk groups.
When you add multiple trunk groups, simply enclose your entry in quotation marks () or in parentheses (()).
While you put spaces between the trunk group name and context entries, you do not use spaces with the plus
sign, parentheses or quotation marks.
266
Oracle® Communications Unified Session Manager
Routing with Local Policy
•
ORACLE(session-agent)# trunk-group +tgrp1:context1 tgrp2:context2
tgrp3:context3
You use a minus sign (-) to delete single or multiple trunk groups from the session agent’s list.
When you remove a single trunk group, simply use the minus sign (-) in front of the trunk group name and
context. Do not use a Space between the minus sign and the trunk group name and context.
For example, you might have already configured a list of trunk groups with the following entries:
tgrpA:contextA, tgrpB:contextB, tgrpC:contextC, and tgrp1:context1. To delete tgrp1:context1 from the list,
you would make the following entry:
ORACLE(session-agent)# trunk-group -tgrp1:context1
Your list would then contain: tgrpA:contextA, tgrpB:contextB, and tgrpC:contextC.
When you add multiple trunk groups, simple enclose your entry in quotation marks () or in parentheses (()).
While you put spaces between the trunk group name and context entries, you do not use spaces with the plus
sign, parentheses or quotation marks.
ORACLE(session-agent)# trunk-group -tgrp1:context1 tgrp2:context2
You overwrite (replace) the entire list of a session agent’s trunk groups by entering a list that does not use
either the plus (+) or the minus (-) sign syntax.
24. ping-in-service-response-codes—SIP only. Enter the list of response codes that keep a session agent in service
when they appear in its response to the Oracle USM’s ping request. The Oracle USM takes the session agent out
of service should a response code be used that does not appear on this list. Default is none.
25. out-service-response-codes—SIP only. Enter the list defines the response codes that take a session agent out of
service when they appear in its response to the Oracle USM’s ping request or any in-dialog creating request (such
as an INVITE, SUBSCRIBE, etc.). The Oracle USM ignores this list if an in-service list exists.
26. options—Optional. You can add your own features and/or parameters by using the options parameter. You enter a
comma-separated list of either or both of the following:
•
•
feature=<value feature>
For example:
You can include the original address in the SIP message from the Oracle USM to the proxy in the Via header
parameter by entering the following option:
via-origin=<parameter-name>
The original parameter is included in the Via of the requests sent to the session agent. The via origin feature can
take a value that is the parameter name to include in the Via. If the value is not specified for via origin, the
parameter name is origin.
Note: If the feature value itself is a comma-separated list, enclose it within quotation marks.
27. in-translationid—Optional. Enter the In Translation ID for a configured session translation (group of address
translation rules with a single ID) if you want to apply session translation to incoming traffic.
28. out-translationid—Optional. Enter the Out Translation ID for a configured session translation (group of address
translation rules with a single ID) if you want to apply session translation to outgoing traffic.
Address translations attached to session agents take precedence over address translations attached to realms. If no
address translation is applied to a session agent, then the Oracle USM will use the address translation applied to a
realm. If an address translation is applied to both a realm and session agent, the translation attached to the session
agent will apply. If the applicable session agent and realm have no associated translations, then the addresses will
remain in their original forms and no address translations will be performed.
29. trust-me—Indicate whether this session agent is a trusted source, which the Oracle USM checks when it receives a
message to determine if the source is trusted. The default value is disabled. The valid values are:
•
enabled | disabled
The following example shows a session agent with an IP address used for the hostname.
Oracle® Communications Unified Session Manager
267
Routing with Local Policy
session-agent
hostname
ip-address
port
state
app-protocol
app-type
transport-method
realm-id
description
carriers
allow-next-hop-lp
constraints
max-sessions
max-inbound-sessions
4
max-outbound-sessions
max-burst-rate
max-inbound-burst-rate
max-outbound-burst-rate
max-sustain-rate
max-inbound-sustain-rate
max-outbound-sustain-rate
min-seizures
min-asr
ttr-no-response
in-service-period
burst-rate-window
sustain-rate-window
req-uri-carrier-mode
proxy-mode
redirect-action
loose-routing
send-media-session
response-map
ping-method
ping-interval
media-profiles
in-translationid
out-translationid
trust-me
request-uri-headers
stop-recurse
local-response-map
ping-to-user-part
ping-from-user-part
li-trust-me
in-manipulationid
out-manipulationid
p-asserted-id
trunk-group
max-register-sustain-rate
192.168.1.10
192.168.1.10
5060
enabled
SIP
UDP
realm-1
englab
carrier1
enabled
disabled
355
355
0
10
1
3000
0
0
5
0 time-to-resume
0
30
60
3600
None
Proxy
Recurse
enabled
enabled
60
0
disabled
disabled
0
Configuring Session Agent Groups
To configure session agent groups:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter to access the system-level configuration elements.
ORACLE(configure)# session-router
268
Oracle® Communications Unified Session Manager
Routing with Local Policy
3. Type session-group and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(session-router)# session-group
ORACLE(session-agent-group)#
4. group-name—Enter a unique name for the session agent group in Name format.
5. description—Optional. Enter descriptive information about the session agent group.
6. state—Enable or disable the session agent group on the Oracle USM. The default value is enabled. Valid values
are:
• enabled | disabled
7. strategy—Indicate the session agent allocation strategy you want to use. The strategy you chose selects the session
agents that will be made available by this session agent group. The default value is hunt. The valid values are:
•
hunt—Selects session agents in the order in which they are listed. For example, if the first agent is online,
working, and has not exceeded defined constraints, all traffic is sent to the first agent. If the first agent is
offline or if it exceeds a defined constraint, the second agent is selected. If the first and second agents are
offline or exceed defined constraints, the third agent is selected. And so on through the list of session agents.
• roundrobin—Selects each session agent in the order in which they are listed in the destination list, selecting
each agent in turn, one per session.
• leastbusy—Selects the session agent that has the fewest number of sessions relative to the maximum sessions
constraint (for example, lowest percent busy) of the session agent element. The Least Busy Calculation is the
result of dividing the number of active calls for a session agent by the max-sessions parameter within the
session-agent element configuration. If the default max-session parameter value issued for a session agent (0),
the result of the Least Busy Calculation will be 0. The Least Busy SAG Strategy will route a session to the
session agent with the lowest resulting Least Busy Calculation percentage. If multiple session agents have the
lowest percentage, the foremost session agent in the Session Agent Group dest parameter will be used.
• propdist—Based on programmed, constrained session limits, the Proportional Distribution strategy
proportionally distributes the traffic among all of the available session agents. Sessions are distributed among
session agents based on the max-outbound-sessions value in each session agent. The sum of max-outboundsessions for every session-agent within a session group equates to 100% and the max-outbound-sessions value
for each session-agent represents a % that total. Sessions are proportionally allocated to session agents based
on their individual session agent max-outbound-sessions value, as a % of the total max-outbound-sessions for
the group.
• lowsusrate—The Lowest Sustained Rate strategy routes to the session agent with the lowest sustained rate of
session initiations/invitations (based on observed sustained session request rate).
8. destination—Identify the destinations (session agents) available for use by this session agent group.
A value you enter here must be a valid IP address or hostname for a configured session agent.
9. trunk-group—Enter trunk group names and trunk group contexts to match in either IPTEL or custom format. If
left blank, the Oracle USM uses the trunk group in the realm for this session agent group. Multiple entries are
surrounded in parentheses and separated from each other with spaces.
Entries for this list must one of the following formats: trgp:context or trgp.context.
10. sag-recursion—Enable this parameter if you want to use SIP SAG recursion for this SAG. The default value is
disabled. Valid values are:
• enabled | disabled
11. stop-sag-recurse—Enter the list of SIP response codes that terminate recursion within the SAG. Upon receiving
one of the specified response codes, such as 401 unauthorized, or upon generating one of the specified response
codes internally, such as 408 timeout, the Oracle USM returns a final response to the UAC. You can enter the
response codes as a comma-separated list or as response code ranges.
The following example shows a session agent group using the SIP protocol and with the Hunt allocation strategy
applied.
session-group
group-name
proxy-sag1
Oracle® Communications Unified Session Manager
269
Routing with Local Policy
description
state
app-protocol
strategy
dest
trunk-group
tgname2:tgcontext2
sag-recursion
stop-sag-recurse
last-modified-date
proxies for external domain
enabled
SIP
Hunt
gw1
gw2
disabled
401,407
2005-01-09 23:23:36
SAG Matching for LRT and ENUM
When this feature is enabled and a match is found, the Oracle USM uses the matching SAG for routing. When there is
no match for the SAG, the Oracle USM processes the result as it would have if this feature had not been enabled:
either matching to a session agent hostname, or performing a DNS query to resolve it.
Note that you set the state of this feature in the SIP configuration.
To configure a SAG for ENUM or LRT matching:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter to access the signaling-level configuration elements.
ORACLE(configure)# session-router
ORACLE(session-router)#
3. Type sip-config and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(session-router)# sip-config
ORACLE(sip-config)#
If you are adding support for this feature to a pre-existing SIP configuration, then you must select (using the ACLI
select command) that configuration to edit it.
4. enum-sag-match—Set this parameter to enabled so the Oracle USM will match session agent group (SAG) names
with the hostname portion in the naming authority pointer (NAPTR) from an ENUM query or LRT next-hop entry.
The default value is disabled. The valid values are:
• enabled | disabled
5. Save and activate your configuration.
Configuring Local Policy
To configure local policy:
1. In Superuser mode, type configure terminal and press Enter.
ACMEPACKET# configure terminal
2. Type session-router and press Enter.
ACMEPACKET(configure)# session-router
3. Type local-policy and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ACMEPACKET(session-router)# local-policy
ACMEPACKET(local-policy)#
4. from-address—Indicate the originating address information by entering a From address value. You can use the
asterisk (*) as a wildcard to indicate this policy can be used with all originating addresses.
You can also use complete or partial E.164 addresses (strings that contain telephone keypad characters) here.
Number matching works from left to right. Formats include the following:
270
Oracle® Communications Unified Session Manager
Routing with Local Policy
•
•
•
•
SIP From address
FQDNs
IP addresses
123*456
The Oracle USM also supports the asterisk as part of the From address you configure in your local policies.
This means that for the from-address parameters of a local policy configuration, you can enter values in which
an asterisk appears and match them accordingly. You might enter a value that resemble the following example:
Note: After entering the from-address value, the Oracle USM automatically saves it to the configuration
when exiting from localpolicy.
5. to-address—Indicate the destination address by entering a To address value. You can use the asterisk (*) as a
wildcard to indicate all this policy can be used for any destination address.
You can also use E.164 addresses (strings that contain telephone keypad characters) here. Number matching works
from left to right. Formats include the following:
•
•
•
•
SIP Request-URI
FQDNs
IP addresses
123*456
The Oracle USM also supports the asterisk as part of the To address you configure in your local policies.
This means that for the to-address parameters of a local policy configuration, you can enter values in which an
asterisk appears and match them accordingly. You might enter a value that resembles the following example:
Note: After entering the to-address value, the Oracle USM automatically saves it to the configuration
when exiting from localpolicy.
6. source-realm—Enter the realm, or list of realms, you want the Oracle USM to use to determine how to route
traffic. This list identifies from what realm traffic is coming and is used for routing by ingress realm by the local
policy.
You can use the asterisk (*) as a wildcard to indicate this local policy can be used with all realms. The default
value is *.Or you can enter a value that corresponds to the identifier of an already configured realm. Formats
include the following:
• realm ID
• customer name
• peer name
• subdomain name
• VPN identifier
7. activate-time—Set the time you want the local policy to be activated using the following syntax:
yyyy:mm:dd hh:mm:ss
yyyy:mm:dd-hh:mm:ss
8. deactivate-time—Set the time you want the local policy to be deactivated using the following syntax:
yyyy:mm:dd hh:mm:ss
yyyy:mm:dd-hh:mm:ss
9. state—Indicate whether you want the local policy to be enabled or disabled on the system. The default value is
enabled. The valid values are:
• enabled | disabled
10. policy-attribute—Configure local policy attributes by following steps 8 through 21.
11. next-hop—Identify the next signaling host by entering the next hop value. You can use the following as next hops:
•
•
IPv4 address or IPv6 address of a specific endpoint
Hostname or IPv4 address or IPv6 address of a configured session agent
Oracle® Communications Unified Session Manager
271
Routing with Local Policy
•
Group name of a configured session agent group
Note: The group name of a configured session agent group must be prefixed with SAG:
For example:
policy-attribute
next-hop SAG:appserver
policy-attribute
next-hop lrt:routetable
policy-attribute
next-hop enum:lerg
You can also configure a next hop that has an address of 0.0.0.0, thereby creating a null route. Different from
not having a local policy configured (which would trigger Oracle USM local policy recursion), this terminates
local policy recursion and immediately fails the request. In these cases, the Oracle USM responds a request
with a 404 Not Found.
12. realm—Identify the egress realm (the realm used to reach the next hop) if the Oracle USM must send requests out
from a specific realm.
The value you enter here must correspond to a valid identifier you enter when you configured the realm. If you do
not enter a value here, and the next hop is a session agent, the realm identified in the session agent configuration is
used for egress.
13. replace-uri—Indicate whether you want to replace the Request-URI in outgoing SIP requests with the next hop
value.
14. carrier—Optional. Enter the name of the carrier associated with this route. The value you enter here must match
one or more of the carrier names in the session agent configuration.
Entries in carrier fields can be from 1 to 24 characters in length and can consist of any alphabetical character (AaZz), numerical character (0-9), or punctuation mark (! ” # $ % ^ & * ( ) + - = < > ? ‘ | { } [ ] @ / \ ‘ ~ , . _ : ; ) or
any combination of alphabetical characters, numerical characters, or punctuation marks. For example, both 1-0288
and acme_carrier are valid carrier field formats.
15. start-time—Indicate the time of day (from the exact minute specified) the local policy attributes go into effect.
Enter only numerical characters (0-9) and follow the 4-digit military time format. For example:
1400
The default value of 0000 implies that the defined policy attributes can be considered in effect any time after
00:00:00. The valid range is:
• Minimum—0000
• Maximum—2400
16. end-time—Indicate the time of day (from the exact minute specified) the local policy attributes are no longer in
effect. Enter only numerical characters (0-9) and follow the 4-digit military time format. For example:
2400
The default value of 2400 implies that the defined policy attributes can be considered in effect any time before
midnight. The valid range is:
• Minimum—0000
• Maximum—2400
17. days-of-week—Enter any combination of days of the week (plus holidays) you want the local policy attributes to
be in effect. You must enter at least one day or holiday here. A holiday entry must correspond with a configured
holiday established in the Session Router.
The default is U-S. The valid values are:
272
Oracle® Communications Unified Session Manager
Routing with Local Policy
•
•
•
•
•
•
•
•
U (Sunday)
M (Monday)
T (Tuesday(
W (Wednesday)
R (Thursday)
F (Friday)
S (Saturday)
H (Holiday)
You can enter a range of values separated by a hyphen, for example U-S. And you can enter multiple values
separated by commas, for example M,W,F. You cannot use spaces as separators.
18. cost—Enter a cost value that acts as a unitless representation of the cost of a route relative to other routes reaching
the same destination (To address). This value is used as a way of ranking policy attributes.
The default value is zero (0). The valid values are:
• minimum—zero (0)
• maximum—999999999
19. state—Indicate whether you want to enable or disable the local policy. The default value is enabled. The valid
values are:
• enabled | disabled
20. media-profiles—Configure a list of media profiles if you want the local policy to route SIP traffic by the codecs
specified in the SDP. The list of media profiles entered here are matched against the SDP included in SIP requests
and the next hop is selected by codec.
The values in this list are matched against the rtpmap attribute of passed SDP, and preference weight for route
selection is based on the order in which the matching payload type appears in the SDP’s media (m=) line.
For example when the following SDP arrives:
m=audio 1234 RTP/AVP 0 8 18
that contains the following attributes that correspond to three configured local policies with the same cost:
•
•
•
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
the following route selection action occurs:
The local policy route that corresponds to the a=rtpmap:0 PCMU/8000 attribute is selected because the
payload type of 0 in the attribute line matches the first payload type of 0 listed in the m= line. The codec value
of PCMU indicated in this selected attribute is used to find the local policy with the media profiles attribute
that includes PCMU in the list.
Because the value you enter here is matched against the codec values included in the actual passed SDP, it
must correspond to accepted industry-standard codec values.
The following example shows a local policy with a next hop value of the session agent group called gw-sag2.
local-policy
from-address
to-address
source-realm
activate-time
deactivate-time
state
last-modified-date
policy-attribute
next-hop
Oracle® Communications Unified Session Manager
*
192.168.1.10
*
2005-01-20 20:30:00
N/A
enabled
2005-01-10 00:36:29
SAG:gw-sag2
273
Routing with Local Policy
realm
replace-uri
carrier
start-time
end-time
days-of-week
cost
app-protocol
state
media-profiles
enabled
0000
2400
U-S
0
enabled
Local Policy Matching for Parent Realms
You can configure the Oracle USM to use the parent realm for routing purposes even when the source realm for an
incoming message is a child realm.
With this feature disabled (default), the Oracle USM uses the specific source realm to perform a local policy look-up.
When the source realm is a child realm and any relevant local policies are configured with the parent realm, there will
be no matches and the local policy look-up will fail. To avoid this issue and ensure successful look-ups, you must
configure multiple local policies if you want to use a configuration with nested realms.
The Oracle USM examines the source realm to determine if it is a parent realm with any child realms when you
enable this feature. If the parent, source realm does have child realms, then the Oracle USM creates local policy
entries for the parent and all of its child realms. This operation is transparent and can save time during the
configuration process.
It is possible, then, for a local policy look-up to match the same child realm in two ways:
•
•
Through a match via the parent realm
Through a direct match for a local policy configured with that specific child realm
In such a case, the child realm must have different costs for each type of match to avoid collisions.
This feature is enabled on a global basis in the session router configuration. Because it applies system-wide, all source
realms will use this form of matching when enabled.
To enable local policy matching for parent realms:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter to access the signaling-related configurations.
ORACLE(configure)# session-router
3. Type session-router and press Enter.
ORACLE(session-router)# session-router
ORACLE(session-router-config)#
4. match-lp-source-parent-realms—If you want the Oracle USM to perform local policy realm matching based on the
parent realm (so that there are local policy entries for parent and child realms), set this parameter to enabled. The
default value is disabled. The valid values are:
•
enabled | disabled
ORACLE(session-router-config)# match-lp-src-parent-realms enabled
5. Save and activate your configuration.
SIP Session Agent DNS-SRV Load Balancing
Prior to Release 6.2.0 the Oracle USM provided the ability to specify an FQDN (fully qualified domain name) for a
destination session-agent. During DNS lookup the FQDN could resolve to multiple SRV (Resource Record for
Servers) records. Each SRV could resolve to a single IP address via A-Record query in IMS or DNS.
274
Oracle® Communications Unified Session Manager
Routing with Local Policy
With Release 6.2.0 the Oracle USM supports load balancing behavior as described in RFC 3263, Session Initiation
Protocol (SIP): Locating SIP Servers.
The Oracle USM will provide a new parameter ping-all-addresses in session-agent configuration mode to enable
internal load balancing and RFC 3263 compliance. The Oracle USM monitor the availability of the dynamically
resolved IP addresses obtained from DNS server using OPTIONS ping (ping-per-DNS entry). The ping-method and
ping-interval for each resolved IP addresses will be copied from original session-agent.
Status of Session-Agent:
In Service – if any of dynamically resolved IP addresses is in service
Out of service – if all dynamically resolved IP addresses is out of service.
The default of ping-all-addresses is disabled, in which case the Oracle USM only pings the first available resolved IP
addresses.
With status of each resolved IP addresses above, the Oracle USM will recurse through the list of these in-service IP
addresses dynamically resolved from DNS server on 503 response, and stop recursion based upon a configured list of
response values specified by the stop-recurse parameter in sip-interface configuration mode. With internal load
balancing enabled in the session-agent, the Oracle USM provides the ability to select routing destinations based on
SRV weights. The priority/weight algorithm is based on RFC 2782, A DNS RR for specifying the location of services
(DNS SRV).
The Oracle USM will provide the similar functionality as that listed above for A-records, the Oracle USMwill select
first available routing destinations because there is no priority/weight contained in A-records.
Session Agent DNS-SRV Load Balancing Configuration
To configure the Oracle USM to perform Session-Agent DNS-SRV load balancing:
1. From superuser mode, use the following command sequence to access sip-config configuration mode. While in
this mode, you configure SAG-based address resolution.
ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# session-agent
ORACLE(session-agent)#
2. Use the ping-all-addresses parameter to enable Session-Agent DNS-SRV load balancing.
3. Use done, exit, and verify-config to complete Session-Agent DNS-SRV load balancing configuration.
The show agents ACLI command displays the availability of dynamically resolved IP addresses
ORACLE# show sip agents acme.engr.com
21:46:05-51-router
Session Agent acme.engr.com(core) [In Service] NO ACTIVITY
Session Agent acme.hxu.com(core) [In Service] NO ACTIVITY
Destination: 192.168.200.235 In Service
Destination: 192.168.200.231 In Service
...
...
Answer to Seizure Ratio-Based Routing
New SIP session agent constraints set a threshold for Answer to Seizure Ratio (ASR) has been implemented. ASR is
considered when determining whether session agents are within their constraints to route calls (in addition to session
and rate constraints).
The new session agent constraints indicate the minimum acceptable ASR value and computes the ASR while making
routing decisions. ASR is calculated by taking the number of successfully answered calls and dividing by the total
number of calls attempted (which are known as seizures).
Oracle® Communications Unified Session Manager
275
Routing with Local Policy
If the ASR constraints are exceeded, the session agent goes out of service for a configurable period of time and all
traffic is routed to a secondary route defined in the local policy (next hop with higher cost).
The two session agent constraints are:
•
•
minimum seizure: determines if the session agent is within its constraints. When the first call is made to the
session agent or the if calls to the session agent are not answered, the minimum seizure value is checked.
For example, if 5 seizures have been made to the session agent and none of them have been answered, the sixth
time, the session agent is marked as having exceeded its constraints and the calls will not be routed to it until the
time-to-resume has elapsed.
minimum ASR: considered when make routing decisions. If some or all of the calls to the session agent have been
answered, the minimum ASR value is considered to make the routing decisions.
For example, if the you set the minimum ASR at 50% and the session agent’s ASR for the current window falls
below 50%, the session agent is marked as having exceeded its constraints and calls will not be routed to it until
the time-to-resume has elapsed.
ASR Constraints Configuration
To configure ASR constraints:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter to access the system-level configuration elements.
ORACLE(configure)# session-router
3. Type session-agent and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(session-router)# session-agent
ORACLE(session-agent)#
4. If configuring an existing session agent, enter the select command to select the session agent.
5. min-seizures—Enter the minimum number of seizures that when exceeded, cause the session agent to be marked
as having exceeded its constraints. Calls will not be routed to the session agent until the time-to-resume has
elapsed. The default value is 5. The valid range is:
• Minimum—1
• Maximum—999999999
6. min-asr—Enter the percentage you want as the minimum. If the session agent’s ASR for the current window falls
below this percentage, the session agent is marked as having exceeded its constraints and calls will not be routed
to it until the time-to-resume has elapsed. The default value is 0. The valid range is:
• Minimum—0
• Maximum—100
7. Save and activate your configuration.
The following example shows a session agent configuration.
session-agent
hostname
ip-address
port
state
app-protocol
app-type
transport-method
realm-id
description
carriers
allow-next-hop-lp
276
192.168.1.6
1720
enabled
H323
H323-GW
external
enabled
Oracle® Communications Unified Session Manager
Routing with Local Policy
constraints
max-sessions
max-inbound-sessions
4
max-outbound-sessions
max-burst-rate
max-inbound-burst-rate
max-outbound-burst-rate
max-sustain-rate
max-inbound-sustain-rate
max-outbound-sustain-rate
min-seizures
5
min-asr
time-to-resume
ttr-no-response
in-service-period
burst-rate-window
sustain-rate-window
req-uri-carrier-mode
proxy-mode
redirect-action
loose-routing
send-media-session
response-map
ping-method
ping-interval
media-profiles
in-translationid
out-translationid
trust-me
request-uri-headers
stop-recurse
local-response-map
ping-to-user-part
ping-from-user-part
li-trust-me
in-manipulationid
out-manipulationid
p-asserted-id
trunk-group
max-register-sustain-rate
early-media-allow
invalidate-registrations
last-modified-date
enabled
0
5
0
10
1
0
0
0
50
30
0
0
0
0
None
enabled
enabled
0
disabled
disabled
0
disabled
2006-05-12 19:48:06
ENUM Lookup
Telephone Number Mapping (ENUM from TElephone NUmber Mapping) is a suite of protocols used to unify the
telephone system with the Internet by using E.164 addresses with the Domain Name System (DNS). With ENUM, an
E.164 number can be expressed as a Fully Qualified Domain Name (FQDN) in a specific Internet infrastructure
domain defined for this purpose (e164.arpa). E.164 numbers are globally unique, language independent identifiers for
resources on Public Switched Telecommunication Networks (PSTNs). ITU-T recommendation E.164 is the
international public telecommunication telephony numbering plan.
How ENUM Works
ENUM uses DNS-based architecture and protocols for mapping a complete international telephone number (for
example, +1 202 123 1234) to a series of Uniform Resource Identifiers (URIs).
The protocol itself is defined in the document E.164 number and DNS (RFC 3761) that provides facilities to resolve
E.164 telephone numbers into other resources or services on the Internet. The syntax of Uniform Resource Identifiers
Oracle® Communications Unified Session Manager
277
Routing with Local Policy
(URIs) is defined in RFC 2396. ENUM uses Naming Authority Pointers (NAPTR) records defined in RFC 2915 in
order to identify available ways or services for contacting a specific node identified through the E.164 number.
Translating the Telephone Number
A telephone number is translated into an Internet address using the following steps:
1. The number is first stored in the following format, +1-202-555-1234. 1 is the country code for the United States,
Canada, and the seventeen other countries that make up the North American Numbering Plan (NANP). The +
indicates that the number is a complete, international E.164 telephone number.
2. All characters are removed except for the digits. For example, 12025551234.
3. The order of the digits is reversed. For example, 43215552021. The telephone number is reversed because DNS
reads addresses from right to left, from the most significant to the least significant character. Dots are placed
between each digit. Example: 4.3.2.1.5.5.5.2.0.2.1. In DNS terms, each digit becomes a zone. Authority can be
delegated to any point within the number.
4. A domain (for example, e164.arpa) is appended to the end of the numbers in order to create a FQDN. For
example,4.3.2.1.5.5.5.2.0.2.1.e164.arpa.
5. The domain name is queried for the resource records that define URIs necessary to access SIP-based VoIP.
Once the authoritative name server for that domain name is found, ENUM retrieves relevant records and uses that
data to complete the call or service. For example, the number 12025551234 returns
sip:my.name@bigcompany.com.
About NAPTR Records
ENUM uses NAPTR records for URI resource records. NAPTR records are used to translate E.164 addresses to SIP
addresses. An example of a NAPTR record is:
$ORIGIN 4.3.2.1.5.5.5.2.0.2.1.e164.arpa.
IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:phoneme@example.net!"
This example specifies that if you want to use the "sip+E2U" service, you should use sip:phoneme@example.net as
the address.
The regular expression can be used by a telephone company to easily assign addresses to all of its clients. For
example, if your number is +15554242, your SIP address is sip:4242@555telco.example.net; if your number is
+15551234, your SIP address is sip:1234@555telco.example.net.
About the Oracle USM ENUM Functionality
The ENUM functionality lets the Oracle USM make an ENUM query for a SIP request. The ENUM lookup capability
lets the Oracle USM transform E.164 numbers to URIs during the process of routing (or redirecting) a call. During the
routing of a SIP call, the Oracle USM uses a local policy attribute to determine if an ENUM query is required and if
so which ENUM server(s) need to be queried. A successful ENUM query results in a URI that is used to continue
routing or redirecting the call.
Configurable Lookup Length
You can configure a lookup length in the ENUM configuration that provides for more efficient caching of URI lookup
results; in it, you can specify the length of the string for the DNS request starting from the most significant digit. This
provides more flexibility for length matching, which is useful given the amount of wild card matching available in
ENUM services. Specific ENUM groups might only be intended to provide NPANXX or wild card results.
UDP Datagram Support for DNS NAPTR Responses
The Oracle USM’s default behavior is to conform to the DNS standard defined in RFC 1035 Domain Names:
Implementation and Specification, which sets a maximum size for UDP responses of 512 bytes. This limitation means
that responses larger than 512 bytes are truncated (set with the TC, or truncation, bit). In addition, this limitation
protects network and system resources because using TCP consumes an undesirable amount of both.
278
Oracle® Communications Unified Session Manager
Routing with Local Policy
However, you can configure support ENUM queries that manage larger UDP DNS responses as set out in RFC 2671,
Extension Mechanisms for DNS (EDNS0), enabling your Oracle USM to manage responses beyond 512 bytes.
According to RFC 2671, senders can advertise their capabilities using a new resource record (OPT pseudo-RR),
which contains the UDP payload size the sender can receive. When you specify a maximum response size over 512
bytes, then the Oracle USM add the OPT pseudo-RR to the ENUM query—without which the ENUM server will
truncate the response.
Custom ENUM Service Type Support
You can configure the ENUM service type that you want to use for an ENUM group. The Oracle USM has always
supported E2U+sip and sip+E2U by default, and still does. With Release S-C6.1.0, however, you are also able to
configure the service type to those supported in RFCs 2916 and 3721.
For example, you can now set the service type in the ENUM configuration to support E2U+sip and E2U
+voicemsg:sip. When you configure customer ENUM service types on your system, however, you should note the
following:
•
•
New entries in the service-type parameter overwrite pre-existing values, including the default values.
Because of the overwriting noted above, you must include the defaults (if you want them configured) when you
are adding additional ENUM service type support. That is, you have to also type in E2U+sip and sip+E2U if you
want them to be used in addition to the customized types you are setting.
ENUM Failover and Query Distribution
ENUM Query Distribution
The Oracle USM can intelligently distribute ENUM queries among all configured ENUM servers. By setting the
enum config’s query method parameter to round robin, the Oracle USM will cycle ENUM queries, sequentially,
among all configured ENUM servers. For example, query 1 will be directed to server 1, query 2 will be directed to
server 2, query 3 will be directed to server 3, and so on.
The default query method, hunt, directs all ENUM queries toward the first configured ENUM server. If the first server
is unreachable, the Oracle USM directs all ENUM queries toward the next configured ENUM server, and so on.
Failover to New enum-config
When an enum-config’s configured servers are unreachable via the network, i.e., no response is received on a query,
the Oracle USM can failover to a defined ENUM config that contains different enum servers to query. This failover
behavior works when all servers in an enum config are unreachable, rather than when the Oracle USM receives notfound type responses.
The Oracle USM queries each ENUM server once before trying the next configured server, and then ultimately trying
the servers listed in the failover-to enum config. If the failover-to servers also are unreachable, the Oracle USM fails
the call; the failover-to behavior does not recurse among enum-configs, it only checks the first, linked enum-config.
ENUM Server Operation States
After 5 consecutive failed attempts, an ENUM server is considered Out of Service (OOS). All subsequent queries
which would be directed to the OOS servers are immediately directed to the first non-OOS server. ENUM servers
return to in-service after 600 seconds. If all configured ENUM servers are OOS, the Oracle USM fails the call.
After the first failed attempt to reach an ENUM server, it is placed in a Time Out state, which it stays in for 30
seconds. Within this 30 seconds it will not be contacted when an ENUM query is made. After the 30 seconds pass, the
ENUM server goes back to an in-service state.
Oracle® Communications Unified Session Manager
279
Routing with Local Policy
Server Availability Monitoring
The Oracle USM can probe an ENUM server’s health by sending it a standard ENUM NAPTR query and receiving a
valid answer. The query is for the phone number defined in the health query number parameter, which should be one
that the ENUM servers can positively resolve. As long as the query succeeds, that ENUM server maintains its inservice state and is available for ENUM queries. Any lack of response, whether network based (time-outs), or
application based (DNS error or not found response) is considered a query failure and the server is set to OOS and
unavailable for ENUM queries.
The Oracle USM continuously checks the health of all configured ENUM servers to determine their current state and
monitor for failed servers’ return to service. All servers are checked for availability at the health query interval
parameter, as defined in seconds.
Note: When ENUM server availability monitoring is enabled, ENUM servers can only exist in an in-service
or out-of-service states; Without the health query interval defined, server availability monitoring is disabled,
and ENUM servers exist in three service states.
ENUM Server IP Address and Port
You can configure an IP address and port for each enum server listed in the enum-servers parameter. IP address and
port are specified in XXX.XXX.XXX.XXX:YYYY format with a port value range of 1024-65535. If the port number
is not specified, 53 is assumed.
The Oracle USM supports IPv6 ENUM configurations in IPv6 realms. The enumservers parameter in the enumconfig configuration parameter can be configured IPv6 addresses in addition to IPv4 addresses. When IPv6 Addresses
are used, the realm configured in the realm-id parameter must be an IPv6 realm.
Unapplicable SNMP Traps and Objects
When only IPv4 ENUM servers are configured, all legacy SNMP object and trap functionality remains the same.
When IPv6 addressing is used for ENUM servers, these existing SNMP objects are obsoleted.
apSysMgmtENUMStatusChangeTrap
apENUMServerStatusTable OBJECT-TYPE
NOTIFICATION-TYPE
IPv6 ENUM SNMP Traps and Objects
New SNMP trap notifies operators of ENUM Server Status change.
apAppsENUMServerStatusChangeTrap
NOTIFICATION-TYPE
OBJECTS
{ apAppsENUMConfigName,
apAppsENUMServerInetAddressType,
apAppsENUMServerInetAddress,
apAppsENUMServerStatus }
STATUS
current
DESCRIPTION
" The trap will be generated if the reachability status of an ENUM
server changes."
::= { apAppsNotifications 1 }
The following objects support this trap.
apAppsENUMServerStatusTable OBJECT-TYPE
SYNTAX
SEQUENCE OF ApAppsENUMServerStatusEntry
MAX-ACCESS
not-accessible
STATUS
current
DESCRIPTION
"A read-only table to hold the status of configured ENUM servers,
indexed by the name of the enum server, server address type and server IP.
Please note this table is the replacement of
apENUMServerStatusTable defined in ap-smgmt.mib, where the table was
obsoleted."
::= { apAppsMIBTabularObjects 1 }
apAppsENUMServerStatusEntry OBJECT-TYPE
280
Oracle® Communications Unified Session Manager
Routing with Local Policy
SYNTAX
ApAppsENUMServerStatusEntry
MAX-ACCESS
not-accessible
STATUS
current
DESCRIPTION
"An entry designed to hold the status of a single ENUM server"
INDEX { apAppsENUMConfigName,
apAppsENUMServerInetAddressType,
apAppsENUMServerInetAddress }
::= { apAppsENUMServerStatusTable 1 }
ApAppsENUMServerStatusEntry ::= SEQUENCE {
apAppsENUMConfigName
DisplayString,
apAppsENUMServerInetAddressType
InetAddressType,
apAppsENUMServerInetAddress
InetAddress,
apAppsENUMServerStatus
INTEGER
}
apAppsENUMConfigName
OBJECT-TYPE
SYNTAX
DisplayString
MAX-ACCESS
read-only
STATUS
current
DESCRIPTION
"The name of the enum-config element that contains this
ENUM server."
::= { apAppsENUMServerStatusEntry 1 }
apAppsENUMServerInetAddressType
OBJECT-TYPE
SYNTAX
InetAddressType
MAX-ACCESS
read-only
STATUS
current
DESCRIPTION
"The IP address of this ENUM server."
::= { apAppsENUMServerStatusEntry 2 }
apAppsENUMServerInetAddress
OBJECT-TYPE
SYNTAX
InetAddress
MAX-ACCESS
read-only
STATUS
current
DESCRIPTION
"The IP address of this ENUM server."
::= { apAppsENUMServerStatusEntry 3 }
apAppsENUMServerStatus OBJECT-TYPE
SYNTAX
INTEGER {
inservice(0),
lowerpriority(1),
oosunreachable(2)
}
MAX-ACCESS
read-only
STATUS
current
DESCRIPTION
"The status of this ENUM server."
::= { apAppsENUMServerStatusEntry 4 }
apAppsENUMServerStatusGroup OBJECT-GROUP
OBJECTS {
apAppsENUMConfigName,
apAppsENUMServerInetAddressType,
apAppsENUMServerInetAddress,
apAppsENUMServerStatus
}
STATUS
current
DESCRIPTION
"Report the status of configured ENUM servers."
::= { apAppsObjectGroups 1 }
apAppsEnumServerNotificationsGroup NOTIFICATION-GROUP
NOTIFICATIONS {
apAppsENUMServerStatusChangeTrap
}
STATUS
current
Oracle® Communications Unified Session Manager
281
Routing with Local Policy
::= {
DESCRIPTION
"A collection of traps to extend reporting capabilities."
apAppsNotificationGroups 1 }
Caching ENUM Responses
As DNS responses often lead to further DNS queries, a DNS server can send additional multiple records in a response
to attempt to anticipate the need for additional queries. The Oracle USM can locally cache additional NAPRT, SRV,
and A records returned from an ENUM query to eliminate the need for unnecessary external DNS requests by
enabling the cache addl records parameter. These cached records can then be accessed by internal ENUM and DNS
agents.
The unprompted NAPTR, SRV, or A record returned to the Oracle USM must include complete information to
resolve a call to be added to the local DNS/ENUM cache, otherwise the Oracle USM will preform an external query
to fine the address it is looking to resolve.
Cached entries are per ENUM config. That means if one ENUM config has a number of cached entries, and an
ENUM request is directed through a different ENUM config, the second configuration is not privy to what the first
configuration has cached.
The Oracle USM uses the shorter lifetime of the DNS response’s TTL or the server dns attribute’s transaction-timeout
to determine when to purge a DNS record from the local cache.
Source URI Information in ENUM Requests
ENUM queries can be configured to include the source URI which caused the ENUM request by enabling the include
source info parameter. The Oracle USM can add the P-Asserted-ID URI (only if not in an INVITE) or the From URI
into an OPT-RR Additional Record to be sent to the ENUM server. It can be useful to specify the originating SIP or
TEL URI from a SIP request which triggered the ENUM query, so the ENUM server can provide a customized
response based on the caller.
This feature implements the functionality described in the Internet Draft, DNS Extension for ENUM Source-URI,
draft-kaplan-enum-source-uri-00.
When a P-Asserted-ID is blocked or removed before the ENUM query is made, the Oracle USM only sends the URI
in the From header.
Note that to support this feature, according to the Internet draft, ENUM clients must support 1220 bytes in UDP
responses. Therefore, if this feature is enabled, and the max response size parameter is not set i.e., with a 512 byte
default, the Oracle USM will set the size to 1200 on the OPT-RR records sent.
Operation Modes
There are four modes of ENUM operation that are selected on a global basis:
•
•
•
•
stateless proxy
transaction stateful proxy
session stateful proxy
B2BUA with or without media
Stateless Proxy Mode
The stateless proxy mode is the most basic form of SIP operation. The stateless proxy mode:
•
•
•
•
•
282
Has the least number of messages per call. No record route header is added and there are no 100 Trying or BYEs.
Does not keep transaction state (timers and retransmission). There are no session counters and no session stop
time. No session stop time means no RADIUS STOP records.
Has no limits on session state.
Can restrict functionality by specification. This can mean no media management, limited potential for RADIUS
accounting, and no CALEA (no Release/BYE messages for CDC).
Acts primarily as a routing device, with local policy routing and ENUM routing.
Oracle® Communications Unified Session Manager
Routing with Local Policy
Transaction Stateful Proxy
In the transaction stateful proxy mode:
•
•
•
•
•
•
•
Adds state to the proxy (not dialogs).
Has lower number of messages per call. No Record Route header added and no BYES.
Keeps transaction state (timers and retransmissions.
Enforces session restrictions (32k) because of state management. These restrictions can be increased.
Can restrict functionality by specification. This can mean no media management, limited potential for RADIUS
accounting, and no CALEA (no Release/BYE message for CDC).
Acts as routing device with transaction timers, with local policy routing and ENUM routing.
Can off-load some transactions across unreliable links.
Session Stateful Proxy
The session stateful proxy mode:
•
•
•
•
•
•
•
Maintains dialog state as a proxy.
Includes BYES (though cannot be inserted)
Keeps transaction state (timers and retransmission)
Provides per-session information such as session counters per session agent, RADIUS STOP accounting record
generation, CALEA CDC generation.
Enforces session restrictions (32k) because of state management.
Does not provide media management. There is no CALEA CCC.
Routes full sessions with transaction timers with local policy routing and ENUM routing.
B2BUA
The B2BUA mode:
•
•
•
•
•
•
•
Acts as UAS and UAC within call flow.
Includes BYES (can be inserted).
Keeps transaction state (timers and retransmissions)
Provides per-session information such as session counters per session agent, RADIUS STOP accounting record
generation, CALEA CDC generation.
Enforces session restrictions (32k) because of state management.
Can provide media management, including media routing through a single IP address with topology masking,
CALEA CCC, media watchdogs for state management.
Routes full sessions with topology masking. Includes rewriting Via, Route, Contact headers, full NATing with SIP
NAT or header manipulation, direct bridging, local policy routing, and ENUM routing.
Example ENUM Stateless Proxy
The following diagram shows the Oracle USM using ENUM to query a local subscriber database. The Oracle USM
serves as the inbound and outbound routing hub and performs media management. Calls are routed throughout the
MSO network using ENUM lookup results.
Oracle® Communications Unified Session Manager
283
Routing with Local Policy
ENUM Configuration
This section shows you how to configure ENUM on your Oracle USM.
To configure ENUM:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter to access the signaling-level configuration elements.
ORACLE(configure)# session-router
ORACLE(session-router)#
3. Type enum-config and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(session-router)# enum-config
ORACLE(enum-config)#
4. name—Enter a string that uniquely identifies this ENUM configuration. You use this name in other areas of the
Oracle USM configuration to refer to this ENUM configuration. For example, in the local policy attributes.
5. top-level-domain—Enter the domain extension to be used when querying the ENUM servers for this
configuration. For example, e164.arpa. The query name is a concatenation of the number and the domain.
For example the number is +17813334444 and the domain is e164.arpa, the query name would be
4.4.4.4.3.3.3.1.8.7.1.e164.arpa.com.
6. realm-id—Enter the realm where the ENUM servers can be reached. The realm ID is used to determine on which
network interface to issue the ENUM query.
7. enum-servers—Enter the list of ENUM servers (an ENUM server and corresponding redundant servers) to be
queried. Separate each server address with a space and enclose list within parentheses.
The first server on this list is the first one to be queried. If the query times out (including retransmissions) without
getting a response, the next server on the list is queried and so on.
8. service-type—Enter the ENUM service types you want supported in this ENUM configuration. Possible entries
are E2U+sip and sip+E2U (the default), and the types outlines in RFCs 2916 and 3721.
This parameter defaults to the following service types: E2U+sip and sip+E2U.
You can enter multiple services types in the same entry, as in this example:
284
Oracle® Communications Unified Session Manager
Routing with Local Policy
ORACLE(enum-config)# service-type E2U+sip,sip+E2U,E2U+voicemsg
9. query-method—Set the strategy the Oracle USM uses to contact ENUM servers. Valid values are:
•
hunt—Directs all ENUM queries toward the first configured ENUM server. If the first server is unreachable,
the Oracle USM directs all ENUM queries toward the next configured ENUM server, and so on.
• round-robin—Cycles all ENUM queries, sequentially, among all configured in-service ENUM servers. Query
1 will be directed to server 1, query 2 will be directed to server 2, query 3 will be directed to server 3.
10. timeout—Enter the total time in seconds that should elapse before a query sent to a server (and its retransmissions)
will timeout. If the first query times out, the next server is queried and the same timeout is applied. This process
continues until all the servers in the list have timed out or until one of the servers responds.
The retransmission of ENUM queries is controlled by three timers. These timers are derived from this timeout
value and from underlying logic that the minimum allowed retransmission interval should be 250 milliseconds;
and that the Oracle USM should retransmit 3 times before timing out to give the server a chance to respond. The
valid values are:
•
•
•
Init-timer—Is the initial retransmission interval. If a response to a query is not received within this interval, the
query is retransmitted. To safeguard from performance degradation, the minimum value allowed for this timer
is 250 milliseconds.
Max-timer—Is the maximum retransmission interval. The interval is doubled after every retransmission. If the
resulting retransmission interval is greater than the value of max-timer, it is set to the max-timer value.
Expire-timer—Is the query expiration timer. If a response is not received for a query and its retransmissions
within this interval, the server will be considered non-responsive and the next server in the list will be tried.
The following examples show different timeout values and the corresponding timers derived from them.
timeout >= 3 seconds
Init-timer = Timeout/11
Max-Timer = 4 * Init-timer
Expire-Timer = Timeout
timeout = 1 second
Init-Timer = 250 ms
Max-Timer = 250 ms
Expire-Timer = 1 sec
timeout = 2 seconds
Init-Timer = 250 ms
Max-Timer = 650 ms
Expire-Timer = 2sec
11. cache-inactivity-timer—Enter the time interval in seconds after which you want cache entries created by ENUM
requests deleted, if inactive for this interval. If the cache entry gets a hit, the timer restarts and the algorithm is
continued until the cache entry reaches its actual time to live.
Setting this value to zero disables caching. For optimal performance, set this to one hour. Rarely used cache
entries are purged and frequently used entries are retained. The default value is 3600. The valid range is:
• Minimum—0
• Maximum—999999999
12. lookup-length—Specify the length of the ENUM query, starting from the most significant digit. The default is 0.
The valid range is:
• Minimum—1
• Maximum—255
13. max-response-size—Enter the maximum size in bytes for UDP datagrams in DNS NAPTR responses. This
parameter takes values from 512 (default) to 65535. Although the maximum value you can set is 65535, Oracle
recommends configuring values that do not exceed 4096 bytes.
14. health-query-number—Set this parameter to a standard ENUM NAPTR query that will consistently return a
positive response from the ENUM server.
Oracle® Communications Unified Session Manager
285
Routing with Local Policy
15. health-query-interval—Set this parameter to the number of seconds to perpetually probe ENUM servers for health.
16. failover-to—Set this parameter to the name of another ENUM-config which to failover to under appropriate
conditions.
17. cache-addl-records—Set this parameter to enabled for the Oracle USM to add additional records received in an
ENUM query to the local DNS cache.
18. include-source-info—Set this parameter to enabled for the Oracle USM to send source URI information to the
ENUM server with any ENUM queries.
19. Save your work.
Example
The following example shows an ENUM configuration called enumconfig.
enum-config
name
top-level-domain
realm-id
enum-servers
enumconfig
public
10.10.10.10:3456
10.10.10.11
E2U+sip,sip+E2U
hunt
11
3600
512
+17813245678
0
enumconfig2
enabled
disabled
service-type
query-method
timeout
cacheInactivityTimer
max-response-size
health-query-number
health-query-interval
failover-to
cache-addl-records
include-source-info
Configuring the Local Policy Attribute
You can specify that an ENUM query needs to be done for the routing of SIP calls. You do so by configuring the local
policy’s next-hop attribute with the name of a specific ENUM configuration, prefixed with the enum: tag. For
example: enum:test
You can configure multiple next-hops with different ENUM servers or server groups (possibly with different toplevel-domains). If the first ENUM server group you enter as the next hop is not available, one of the others can be
used.
Note: A new parameter called action has replaced the policy attribute’s replace-uri parameter available prior
to build 211p19.
To configure local policy:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter.
ORACLE(configure)# session-router
3. Type local-policy and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(session-router)# local-policy
ORACLE(local-policy)#
4. next-hop—Enter the name of the ENUM configuration with the prefix enum:. For example, enum:test.
5. action—Set to redirect if you want to send a REDIRECT message back to the calling party with the information
returned by ENUM in the Contact. The calling party then needs to send a REDIRECT using that information. The
default value is none. Valid values are:
286
Oracle® Communications Unified Session Manager
Routing with Local Policy
• none—No specific actions requested.
• replace-uri—To replace the next Request-URI with the next hop.
• redirect—To send a redirect response with this next hop as contact.
6. Save and activate your configuration.
Local Policy Example
The following example shows one local policy with the next-hop configured to use enum:test and a second with the
next-hope configured to use enum:test_alternate.
local-policy
from-address
to-address
source-realm
activate-time
deactivate-time
state
last-modified-date
policy-attribute
next-hop
realm
action
terminate-recursion
carrier
start-time
end-time
days-of-week
cost
app-protocol
state
media-profiles
policy-attribute
next-hop
realm
action
terminate-recursion
carrier
start-time
end-time
days-of-week
cost
app-protocol
state
*
*
public
N/A
N/A
enabled
2006-03-09 09:18:43
enum:test
public
none
disabled
0000
2400
U-S
1
SIP
enabled
enum:test_alternate
public
none
disabled
0000
2400
U-S
2
SIP
enabled
CNAM Subtype Support for ENUM Queries
CNAM, calling name, data is a string up to 15 ASCII characters of information associated with a specific calling
party name. The Internet-draft, draft-ietf-enum-cnam-08.txt, registers the Enumservice 'pstndata' and subtype 'cnam'
using the URI scheme 'pstndata:' to specify the return of CNAM data in ENUM responses. The Oracle USM
recognizes CNAM data returned via this mechanism. CNAM data is then inserted into the display name of the From:
header in the original Request. If a P-Asserted-ID header is present in the original request, the CNAM data is inserted
there as well.
CNAM data is identified by an ENUM response with service-type: E2U+pstndata:cnam
CNAM support is configured in the sip profile configuration element, which can then be applied to either a session
agent, realm, or SIP interface.
The Oracle USM can preform CNAM queries on the signaling message’s ingress or egress from the system by setting
the cnam lookup direction parameter to either ingress or egress. If the CNAM lookup direction parameters are
Oracle® Communications Unified Session Manager
287
Routing with Local Policy
configured on both the ingress and egress sides of a call, the Oracle USM will only preform the lookup on the ingress
side of the call.
CNAM Unavailable Response
A CNAM response can include a Calling Name Privacy Indicator parameter ('unavailable=p') or Calling Name Status
Indicator parameter ('unavailable=u') in responses. The Oracle USM can insert a custom reason string into the SIP
message’s From and P-Asserted-ID header in the original requires.
Configuring the cnam unavailable ptype parameter inserts the specified text into the From and P-Asserted-ID headers
when a CNAM response contains the unavailable=p parameter.
Configuring the cnam unavailable utype parameter inserts the specified text into the From and P-Asserted-ID headers
when a CNAM response contains the unavailable=u parameter.
SIP Profile Inheritance
CNAM features, via the SIP Profile configuration element can be applied to session agents, realms, and SIP
interfaces. The more generalized object inherits the more specific object’s values. For example, if CNAM support via
a SIP profile is configured on a session agent, the expected processing will override any SIP profile configuration on
the downstream realm or SIP interface. Likewise, if CNAM support is unconfigured on the receiving session agent,
but configured in the realm, CNAM configuration on the SIP interface will be ignored.
CNAM Subtype Support Configuration
To enable the Oracle USM to preform CNAM subtype ENUM queries, you must configure a SIP profile with an
enum-config object (that points to valid ENUM servers). The referenced enum-config configuration element lists the
servers to contact for CNAM type queries (and other general ENUM server interaction parameters).
To configure CNAM subtype support:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter to access the signaling-level configuration elements.
ORACLE(configure)# session-router
ORACLE(session-router)#
3. Type sip-profile and press Enter. The system prompt changes to let you know that you can begin configuring
individual parameters.
ORACLE(session-router)# sip-profile
ORACLE(sip-profile)#
4. name—Enter a string that uniquely identifies this SIP profile configuration. You use this name in other areas of
the Oracle USM configuration to refer to this SIP profile in session agents, realms, or SIP interfaces.
5. cnam-lookup-server—Set this parameter to the name of an ENUM-config to that will query ENUM servers for
CNAM data.
6. cnam-lookup-dir—Set this parameter to ingress or egress to identify where the Oracle USM performs a CNAM
lookup with respect to where the call traverses the system. The default value is egress.
7. cnam-unavailable-ptype—Set this parameter to a string, no more than 15 characters, to indicate that the
unavailable=p parameter was returned in a CNAM response.
8. cnam-unavailable-utype—Set this parameter to a string, no more than 15 characters, to indicate that the
unavailable=u parameter was returned in a CNAM response.
9. Save your work.
Using the Local Route Table (LRT) for Routing
The LRT allows the Oracle USM to determine next hops and map E.164 to SIP URIs locally for routing flexibility.
288
Oracle® Communications Unified Session Manager
Routing with Local Policy
The LRT uses a local route cache that is populated by a local XML file on the Oracle USM. Each local cache is
populated from one defined XML file. For routing, the local route cache operates in a way similar to the ENUM
model where a local policy next hop specifies the local route table that the Oracle USM references. For example, you
can configure one next hop to use one table, and another next hop to use a different table.
Similar to the ENUM model, the Oracle USM typically performs a local route table lookup using the telephone
number (TN) of the SIP Request-URI. This is the user portion of the URI, and the Oracle USM ignores user
parameters or non-digit characters. The local route table XML file defines the matching number and the resulting
regular expression replacement value such as ENUM NAPTR entries do. The Oracle USM uses the resulting regular
expression to replace the Request-URI, and it uses the hostname or IP address portion to determine the next hop. If
the hostname or IP address matches a configured session agent, the request is sent to that session agent. If the Oracle
USM does not find a matching session agent for the hostname/IP address, the Oracle USM either performs a DNS
query on the hostname to determine its IP address or sends the request directly to the IP address.
When the next hop is defined as a user-parameter lookup key, such as a routing number (RN) or carrier identification
code (CIC), the defined key is used for the local route table lookup.
The Oracle USM can attempt up to 10 next hops per LRT entry in the order in which they appear in the XML file. If
the next hop is unsuccessful, the Oracle USM tires the next hop on list. An unsuccessful hop may occur when an outof-service session agent or the next hop responds with a failure response.
Note: Entering XML comments on the same line as LRT XML data is not supported.
The Oracle USM can perform local route table lookups for SIP requests and communicate the results to the SIP task.
The new task processes the new local routing configuration objects.
When a SIP call is routed, the Oracle USM uses local policy attributes to determine if a local route table lookup is
required. If a lookup is needed, the Oracle USM selects the local routing configuration to use. Successful local route
table lookups result in URIs that can be used to continue routing and redirecting calls.
Local Route Table (LRT) Performance
Capabilities
•
•
•
Loads approximately 500 LRT tables during boot time
Loads 100,000 entries per LRT file
Loads 2,000,000 LRT entries total per system
Constraints
•
•
You cannot configure the Oracle USM with 500 LRT files each with 100,000 entries.
Actual performance that affects the interaction among the three performance attributes varies with system memory
and configuration.
Local Routing Configuration
This section shows you how to:
•
•
Set up local route configuration
Specify that a set of local policy attributes needs to use local routing
Configure Local Routing
The local routing configuration is an element in the ACLI session-router path, where you configure a name for the
local route table, the filename of the database corresponding to this table, and the prefix length (significant digits/bits)
to be used for lookup.
To configure local routing:
1. In Superuser mode, type configure terminal, and press Enter.
ORACLE# configure terminal
Oracle® Communications Unified Session Manager
289
Routing with Local Policy
2. Type session-router, and press Enter.
ORACLE(configure)# session-router
3. Type local-routing-config,and press Enter.
ORACLE(session-router)# local-routing-config
ORACLE(local-routing-config)#
4. name—Enter the name (a unique identifier) for the local route table; this name is used for reference in the local
policy attributes when to specify that local routing should be used. There is no default for this parameter, and it is
required.
5. file-name—Enter the name for the file from which the database corresponding to this local route table will be
created. You should use the .gz format, and the file should be placed in the /code/lrt/ directory. There is no default
for this parameter and it is required.
6. prefix-length—Enter the number of significant digits/bits to used for lookup and cache storage. The default value
is 0. The valid range is:
• Minimum—0
• Maximum—999999999
7. Save and activate your configuration.
The following example displays a typical local routing configuration.
local-routing-config
name
file-name
prefix-length
lookup
abc.xml.gz
3
Applying the Local Routing Configuration
Apply the local routing configuration by calling it to use in the local policy attributes. You do this by setting a flag in
the next-hop parameter along with the name of the local routing configuration that you want to use.
To apply the local routing configuration:
1. In Superuser mode, type configure terminal, and press Enter.
ORACLE# configure terminal
2. Type session-router, and press Enter.
ORACLE(configure)# session-router
3. Type local-policy, and press Enter.
ORACLE(session-router)# local-policy
ORACLE(local-policy)#
4. Type policy-attributes, and press Enter.
ORACLE(local-policy)# policy-attributes
ORACLE(local-policy-attributes)#
5. next-hop—In the next-hop parameter, type in lrt: followed directly by the name of the local routing configuration
to be used. The lrt: tag tells the Oracle USM that a local route table will be used.
ACMEPACKET(local-policy-attributes)# next-hop lrt:lookup
6. Save and activate the configuration.
LRT Entry Matching
When searching an LRT for a matching route, the Oracle USM can be configured with one of three match modes with
the match mode parameter in the local routing config. These modes are:
•
•
290
exact—When searching the applicable LRT, the search and table keys must be an exact match.
best—The longest matching table key in the LRT is the chosen match.
Oracle® Communications Unified Session Manager
Routing with Local Policy
•
all—The all mode makes partial matches where the table's key value is a prefix of the lookup key. For example, a
lookup in the following table with a key of 123456 returns entries 1, 3, and 4. The 'all' mode incurs a performance
penalty because it performs multiple searches of the table with continually shortened lookup keys to find all
matching entries. This mode also returns any exact matches too.
Entry#
Key
Result
1
1
<sip:\0@host1.example.com>
2
122
<sip:\0@host22.example.com>
3
123
<sip:\0@host3.example.com>
4
1234
<sip:\0@host4.example.com>
5
1234567
<sip:\0@host7.example.com>
6
1235
<sip:\0@host5.example.com>
LRT Entry Matching Configuration
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter.
ORACLE(configure)# session-router
3. Type local-routing-config and press Enter.
ORACLE(session-router)# local-routing-config
ORACLE(local-routing-config)#
4. match-mode—Set this parameter to either best, all, or leave it as exact which is the default. This indicates to the
Oracle USM how to determine LRT lookup matches.
5. Save your work using the done command.
LRT String Lookup
The Oracle USM can search an LRT for either E.164 or string table keys. This selection is on a global basis. When the
string-lookup parameter is disabled (default) in the local routing configuration, all lookups with be E.164 type, except
when:
•
•
If eloc-str-lkup is enabled in a matching local policy’s policy-attribute, E-CSCF procedures are applied and the
resulting lookup type is 'string'.
The Oracle USM also performs string lookups exclusively when a compound lookup key is specified.
When the lookup type is 'E.164', the lookup is skipped if the lookup key is not a valid telephone number (i.e. it must
contain only digits).
LRT String Lookup Configuration
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter.
ORACLE(configure)# session-router
3. Type local-routing-config and press Enter.
ORACLE(session-router)# local-routing-config
ORACLE(local-routing-config)#
4. string-lookup—Set this parameter to enabled for the Oracle USM to perform LRT lookups on table keys of a
string data type. Leave this parameter to its default as disabled to continue using E.164 type lookups.
Oracle® Communications Unified Session Manager
291
Routing with Local Policy
5. Save your work using the done command.
Directed Egress Realm from LRT ENUM
A message can be sent into a specific egress realm identified in an ENUM query or LRT lookup. The egress realm is
noted by a configurable parameter in the result URI. The Oracle USM is configured with the name of this parameter,
that indicates an egress realm name, and looks for it in the returned URI.
To configure the parameter name, the egress-realm-param option is added to the sip config using the following
format:
egress-realm-param=<name>
Where <name> is the parameter name to extract the egress realm name from.
When the egress realm param is defined, the ENUM and LRT results will always be checked for the presence of the
URI parameter. The sip config options will apply for received SIP requests.
For example, if egress-realm-param=egress is added to the sip config, a matching entry in the LRT that specifies the
egress realm core will look like this:
<route>
<user type="E164">+17815551212</user>
<next type="regex">!^.*$!sip:\0@core.example.com;egress=core!</next>
</route>
If the URI does not contain the parameter or the parameter identifies a realm that is not configured on the system, the
egress realm that is normally applicable (from local policy, SIP-NAT, or session-agent data) will be used.
Directed Egress Realm Configuration
To add an egress parameter to look for in a sip-config:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
2. Type session-router and press Enter.
ORACLE(configure)# session-router
ORACLE(session-router)#
3. Type sip-config and press Enter. If you are adding this feature to a pre-existing SIP configuration, you will need to
select and edit it.
ORACLE(session-router)# sip-config
ORACLE(sip-config)#
4. egress-realm-param—Configure this option with the parameter to parse for in a returned ENUM or LRT result:
For example
•
options egress-realm-param=egress
In order to append the new option to the sip-config’s options list, you must prepend the new option with a plus
sign. For example:
ORACLE(sip-config)# options +egress-realm-param=egress
5. Save your work using the ACLI done command.
Note: The egress-realm-param option can be configured similarly in the h323-config.
292
Oracle® Communications Unified Session Manager
Routing with Local Policy
SIP Embedded Route Header
The Oracle USM examines the ENUM and LRT lookup result for embedded Route headers. In the LRT or as returned
in an ENUM query a URI including an embedded route header would look like:
<sip:user@example.com?Route=%3Csip:host.example.com;lr%3E>
Using embedded Route headers is the Oracle USM’s default behavior. This can be overridden by adding the sipconfig option use-embedded-route.
When the ENUM or LRT result becomes the top Route header, any embedded Route headers extracted are inserted
just after that top Route (which will always be a loose route and include the "lr" URI parameter). In this case, the
request will be sent to the top Route.
When the ENUM or LRT results become the Request-URI, any embedded Route headers extracted from the result are
inserted before any Route headers already in the outgoing request. After that, if there are any Route headers in the
outgoing request and the top Route header has an "lr" URI parameter, the request is sent to the top Route header.
Otherwise, the request is sent to the Request URI.
SIP Embedded Route Header Configuration
To set the Oracle USM’s default behavior of using embedded route headers from ENUM queries or LRT lookups:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
2. Type session-router and press Enter.
ORACLE(configure)# session-router
ORACLE(session-router)#
3. Type sip-config and press Enter. If you are adding this feature to a pre-existing SIP configuration, you will need to
select and edit it.
ORACLE(session-router)# sip-config
ORACLE(sip-config)#
4. use-embedded-route—Configure this as an option with one of the following arguments:
•
•
•
•
all = use embedded routes from both ENUM and LRT results (default)
none = do not use embedded routes
enum = use embedded routes from ENUM results only
lrt = use embedded routes from LRT results only
In order to append the new option to the sip-config’s options list, you must prepend the new option with a plus
sign. For example:
Set the options parameter by typing options, a Space, the option name use-embedded-route, and then press
Enter.
ORACLE(sip-config)# options +use-embedded-route=none
5. Save your work using the ACLI done command.
LRT Lookup Key Creation
This section describes the Oracle USM’s LRT lookup key creation capability.
Arbitrary LRT Lookup Key
In addtion to the standard From, To, and and P-Asserted-Identity header fields the Oracle USM can now use the
values from any arbitrary SIP header as an LRT or ENUM lookup key. This is preformed by prepending a dollar sign
Oracle® Communications Unified Session Manager
293
Routing with Local Policy
$ by the header name whose value’s userinfo portion of the URI will be used as the lookup key. For example, key=
$Refer-To would use the userinfo portion of the URI in the Refer-To header of the request as the lookup key.
An ampersand & followed by a header name will use the whole value of the header as the lookup key. For example,
key=&X-Route-Key would use the whole value of the X-Route-Key as the lookup key. As a shortcut, an ampersand is
not required for a "hidden" header. For example, "key=@LRT-Key" would use the value of the @LRT-Key header as
the lookup key.
Hidden Headers for HMR and LRT lookup
When an LRT lookup key is more complex than just the URI’s userinfo or a Tel-URI, HMR can be used to extract the
data and build a special header.
By using a header name that begins with the at-sign ”@” (e.g. @lrt-key), the header can be hidden and not included in
outgoing SIP message, thus eliminating the need for an extra HMR rule to remove it.
Since '@' is not a valid character in a header name as defined by RFC 3261, there is no possibility of a collision
between a header name defined in the future and a hidden header name beginning with @.
Compound Key LRT Lookup
LRT lookup keys can be combinations of more than one key value. For example, "key=$FROM,$TO" would
construct a compound key with the userinfo of the From URI followed by a comma flowed by the userinfo of the To
URI.
If the request message contained:
From: <sip:1234@example.com>
To: <sip:5678@example.com>
The compound key to match this From/To pair is "1234,5678".
In the table lookup, the compound key is a single key value and there is no special treatment of the comma in key
matching. The comma is simply an ordinary additional character that is matched like any letter or digit (i.e. the
comma must appear in the LRT entry's "type" element data). For example, if the table were configured for "best"
match-mode, the lookup key "1234,5678" would match a table entry of "1234,567", but it would not match a table
entry of "123,5678".
Retargeting LRT ENUM-based Requests
Request re-targeting is when a target or a request as indicated in the Request-URI, is replaced with a new URI.
The happens most commonly when the "home" proxy of the target user replaces the Request-URI with the registered
contact of that user. For example, the original request is targeted at the Address-of-Record of bob (e.g. sip:
bob@example.net). The "home" proxy for the domain of the original target, example.net, accesses the location
service/registration database to determine the registered contact(s) for the user (e.g. sip:bob@192.168.0.10). This
contact was retrieved in a REGISTER request from the user's UA. The incoming request is then re-targeted to the
registered contact. When retarget-requests is enabled, or the original Request-URI is the Oracle USM itself, the URI
from the LRT lookup is used as the new Request-URI for the outgoing request.
When a request is routed rather than re-targeted, the Request-URI is not changed, but one or more Route headers may
be inserted into the outgoing request. Sometimes a request which already contains Route headers will be routed
without adding additional Route headers.
When the Oracle USM routes requests and the original Request-URI was not the Oracle USM itself, the URI from the
LRT /ENUM lookup is added as the top Route: header including the "lr" parameter. The Request-URI then remains
unchanged.
Whether the Oracle USM re-targets or routes a request depends on the following:
•
•
294
The target (Request-URI) of the received request
The presence of Route headers
Oracle® Communications Unified Session Manager
Routing with Local Policy
•
•
Local Policy Attributes,
Registration Cache matching.
If the original target is the Oracle USM itself (i.e. the Request-URI contains the IP Address in the SIP interface the
request was received on), the request is always retargeted. When the original target is not the Oracle USM and Local
Policy is applied, the request will be re-targeted when the policy attribute action parameter is replace-uri. The request
will also be re-targeted when the policy attribute specifies an ENUM or LRT lookup.
Retargetting requests can be configured in either the ENUM or LRT config depending on the request URI retrieval
method choosen.
Re-targeting LRT ENUM-based Requests Configuration
This section shows you how to configure the Oracle USM to retarget/re-route request message when performing an
LRT or an ENUM lookup.
To configure the Oracle USM to retarget or route request messages when performing an LRT lookup:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter.
ORACLE(configure)# session-router
3. Type local-routing-config and press Enter.
ORACLE(session-router)# local-routing-config
ORACLE(local-routing-config)#
4. retarget-requests—Leave this parameter set to enabled for the Oracle USM to replace the Request-URI in the
outgoing request. Change this parameter to disabled for the Oracle USM to route the request by looking to the
Route header to determine where to send the message.
5. Save your work using the done command.
To configure the Oracle USM to retarget or route request messages when performing an ENUM lookup:
6. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
7. Type session-router and press Enter.
ORACLE(configure)# session-router
8. Type local-routing-config and press Enter.
ORACLE(session-router)# enum-config
ORACLE(enum-config)#
9. retarget-requests—Leave this parameter set to enabled for the Oracle USM to replace the Request-URI in the
outgoing request. Change this parameter to disabled for the Oracle USM to route the request by looking to the
Route header to determine where to send the message.
10. Save your work using the done command.
Recursive ENUM Queries
If the Oracle USM receives an A-record in response to an ENUM query, it will reperform that ENUM query to the
server received in the A-record.
If the Oracle USM receives an NS record in response to an ENUM query, it will resend the original ENUM query to
the DNS server defined in the realm of the FQDN in the NS record. It will use the response to perform a subsequent
ENUM query.
This behavior is configured by setting the recursive query parameter in the enum config to enabled.
Oracle® Communications Unified Session Manager
295
Routing with Local Policy
Recursive ENUM Queries Configuration
To configure the Oracle USM to query a DNS server for a hostname returned in an ENUM lookup result:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter.
ORACLE(configure)# session-router
3. Type local-routing-config and press Enter.
ORACLE(session-router)# enum-config
ORACLE(enum-config)#
4. recursive-query—Set this parameter to enabled for the Oracle USM to query a DNS server for a hostname
returned in an ENUM result.
5. Save your work using the done command.
Multistage Local Policy Routing
Multistage local policy routing enables the Oracle USM to perform multiple stages of route lookups where the result
from one stage is used as the lookup key for the next routing stage.
Routing Stages
A routing stage signifies a re-evaluation of local policy based on the results of a local policy lookup. In the simplest,
single stage case, the Oracle USM performs a local policy lookup on a SIP message’s Request URI. The result of that
local policy lookup is a next hop FQDN, IP address, ENUM lookup, or LRT lookup; that result is where the Oracle
USM forwards the message. In the multistage routing model, that resultant next hop is used as the lookup key for a
second local policy lookup.
The results of each stage do not erase the results of the previous stage. Thus, previous results are also possible routes
to use for recursion, but the next stage results are tried first.
Note: Setting a next hop to a SAG in a multistage scenario constitutes an error.
Multi-stage Routing Source Realm
By default, the Oracle USM uses the realm within which a message was received as the source realm through all
stages of a multistage local policy routing lookup. You can change this by setting the multi-stage-src-realm-override
parameter in the session router config to enabled. Enabling this setting causes the Oracle USM to use the next-hop
realm from the current local policy stage as the source realm for the next stage of the lookup. This source realm
selection process also repeats for each stage of a multistage routing scenario.
Network Applications
The following are typical applications of multistage routing:
•
•
•
296
An operator might need to query an ENUM server for a destination number. Based on the NAPTR result of the
ENUM query, the Oracle USM performs a local policy lookup to decide how to route the request, perhaps based
on a LRT table lookup.
An operator might need to query one ENUM server for a number portability lookup, then based on the routing
number perform a second ENUM query to a different server to learn which carrier to use for the routing number.
Then, then based on the identified carrier perform a LRT lookup for what next-hop(s) to use for that carrier.
An operator might query an LRT table to confirm the allowed source number. Then, based on the result, query an
ENUM server for destination routing.
Oracle® Communications Unified Session Manager
Routing with Local Policy
Multistage Routing Conceptual Example
Multistage routing is enabled by setting a policy attribute’s lookup parameter to multi. Instead of replacing the SIP
message’s request URI with the policy attribute’s next hop address or response from an ENUM or LRT lookup, the
system uses that next hop or ENUM or LRT lookup response to reconstruct the SIP message. The reconstructed SIP
message is fed again through all configured local policy configuration elements (and policy attribute sub elements).
Each time the Oracle USM re-evaluates a SIP message against local policies, it is considered an additional routing
stage. When multiple records are returned from an ENUM or LRT lookup, the Oracle USM evaluates the first
response against all applicable local policies. If unsuccessful, the Oracle USM evaluates all additional responses, in
turn, against all applicable local policies.
For example:
Multistage Routing Example 2
The following three local policy configuration elements are configured in the Oracle USM:
Oracle® Communications Unified Session Manager
297
Routing with Local Policy
The local route table in default-lrt appears as follows:
<route>
<user type="E164">159</user>
<next type="regex">!^.*$!sip:11568000000@192.168.200.47!</
next>
<next type="regex">!^.*$!sip:215680000002@192.168.200.99!</next>
<next type="regex">!^.*$!sip:11578000000@192.168.200.44!</next>
</route>
1. The Oracle USM receives an INVITE on realm, private (SDP is omitted below):
INVITE sip:159@192.168.1.49:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.48:5060
From: sipp <sip:sipp@192.168.1.48:5060>;tag=1
To: sut <sip:159@192.168.1.49:5060>
Call-ID: 1-4576@192.168.1.48
CSeq: 1 INVITE
Contact: sip:sipp@192.168.1.48:5060
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: 135
2. The Oracle USM performs a local policy search based on the following parameters:
from-address:
to-address:
Source Realm:
sipp <sip:sipp@192.168.1.48:5060>;tag=1
sip:159@192.168.1.49:5060
private
3. The local policy search returns the four following routes to try:
lrt:default-lrt
192.168.200.50
lrt:emergency
lrt:carrier-lrt
The first next-hop route will be an LRT query. In addition, this policy attribute is configured with lookup=multi,
meaning the results of the LRT query should be used for another local policy query, i.e., a second stage. More
specifically, the request-uri that was received in response to the LRT query will be used as the to-uri in the next LP
query.
298
Oracle® Communications Unified Session Manager
Routing with Local Policy
The Oracle USM performs the LRT lookup in the default-lrt configuration element and is returned the following:
sip:11568000000@192.168.200.47
sip:215680000002@192.168.200.99
sip:11578000000@192.168.200.44
The Oracle USM attempts to use the results from the LRT query for the next stage Local Policy lookup(s).
Beginning with the first route and continuing in sequential order, the Oracle USM will try to route the outgoing
INVITE message by performing additional Local Policy lookups on the remaining LRT query results, until the
INVITE is successfully forwarded.
The Oracle USM performs a local policy query on:
sip:11568000000@192.168.200.47
Which equates to a local policy lookup on:
from-URI=sipp <sip:sipp@192.168.1.48:5060>;
to-URI=sip:11568000000@192.168.200.47
Source Realm: private
The query fails because there is no Local Policy entry for 11568000000.
The Oracle USM performs a second query on request-uri
sip:215680000002@192.168.200.99
Which equates to a local policy lookup on:
from-URI=sipp <sip:sipp@192.168.1.48:5060>;
to-URI=sip:215680000002@192.168.200.99
Source Realm: private
The LP query is successful and returns the following next- hops:
192.168.200.98
192.168.200.99
192.168.200.44
The three routes shown above represent the next stage of the multistage routing for this INVITE. The policy
attributes’ lookup parameter is set to single for these next-hops. Therefore, the Oracle USM will attempt to send
the outgoing INVITE message to one or more of these next-hops; there are no more stages to check.
4. The Oracle USM sends an INVITE to 192.168.200.98:
INVITE sip:215680000002@192.168.200.98;lr SIP/2.0
Via: SIP/2.0/UDP 192.168.200.49:5060
From: sipp <sip:sipp@192.168.1.48:5060>
To: sut <sip:159@192.168.1.49:5060>
Call-ID: SDnhae701-76e8c8b6e168958e385365657faab5cb-v3000i1
CSeq: 1 INVITE
Contact: <sip:sipp@192.168.200.49:5060;transport=udp>
Max-Forwards: 69
Subject: Performance Test
Content-Type: application/sdp
Content-Length: 140
5. If the INVITE is sent to 192.168.200.98 successfully, the local policy routing will conclude and the call will
continue processing. Otherwise the Oracle USM will try the other next hops until a route succeeds or all next-hops
have been exhausted
Customizing Lookup Keys
When the next hop parameter points to perform an ENUM or LRT lookup, it can be provisioned with a "key="
attribute in order to specify a parameter other than the username to perform the lookup on. The following table lists
the header, key value, and corresponding syntax to configure the Oracle USM with.
Oracle® Communications Unified Session Manager
299
Routing with Local Policy
Username from Header:
Key Value
Example
To-URI
$TO
key=$TO
From-URI
$FROM
key=$FROM
P-Asserted-Identity
$PAI
key=$PAI
For a subsequent stage in multistage local policy routing, the lookup key to use for the next stage can be explicitly
specified by configuring the next key parameter. By default, multistage lookups use the modified Request-URI
returned from the ENUM/LRT response as the to-address key for the next local policy lookup. When the next key
parameter is configured, its value will be used for the to-address key in the subsequent local policy lookup regardless
if an ENUM or LRT lookup is configured for that policy attribute. The key syntax is for this parameter is the same as
with the Routing-based RN and CIC feature.
Multistage Routing Lookup Termination
It is important for the Oracle USM to have a mechanism to stop performing additional stages of route lookups and
limit the number of attempts and results to be tried. Routing termination can be performed at in the non-multistage
way or at the global session router level.
Global Local Policy Termination
The Oracle USM can be configured to limit local policy lookups based several aspects of the route lookup process:
•
•
•
Limiting the number of stages per message lookup—The Oracle USM can limit to the number of additional local
policy lookup stages it will perform received message to a maximum of 5. This is configured with the additional
lp lookups parameter. Leaving this parameter at its default value of 0 essentially disables multistaged local policy
lookups.
Limiting the number of routes per Local Policy lookup—The Oracle USM can limit the number of route results to
use as returned for each Local-Policy lookup. This is configured with the max lp lookups routes per lookup
parameter. Leaving this parameter at its default value of 0 places no limit on the number of returned routes the
Oracle USM can try.
Limiting the total number of routes for all local policy lookups per message request—The Oracle USM can limit
the number of route returned in total across all lookups for a given request, including additional stages. This is
configured with the total lp routes parameter. Leaving this parameter at its default value of 0 places no limit on the
number of returned routes the Oracle USMcan try. This parameter overrides any configured options.
Additionally, the Oracle USM monitors for local policy lookup loops which could cause a significant deterioration in
performance. If a loop is found, the Oracle USM stops trying the looping route list and proceeds to try any remaining
routes..
Multistage Local Policy Routing Configuration
To set up your local policy attributes for routing using the TO header:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
2. Type session-router and press Enter.
ORACLE(configure)# session-router
ORACLE(session-router)#
3. Type local-policy and press Enter. If you are adding this feature to a pre-existing local policy configuration, you
will need to select and edit a local policy.
ORACLE(session-router)# local-policy
ORACLE(local-policy)#
4. Type policy-attributes and press Enter. If you are adding this feature to a pre-existing local policy configuration,
you will need to select and edit your local policy.
300
Oracle® Communications Unified Session Manager
Routing with Local Policy
ORACLE(local-policy)# policy-attributes
ORACLE(local-policy-attributes)#
5. next-hop—This is the next signaling host and/or object to query. This parameter can be configured as an IP
address, ENUM server, or LRT. You can also add a lookup key to an ENUM server or LRT lookup with the
following syntax:
next-hop
enum:ENUM-object;key=$TO
6. terminate-recursion—Set this parameter to enabled to terminate local policy route recursion when the current
stage completes.
7. lookup—Leave this parameter at the default single for single stage local policy routing or set it to multi to enable
multistage local policy routing.
8. next-key—Set this parameter to $TO, $FROM, or $PAI if you wish to override the recently-returned lookup key
value for the next stage.
9. Save and activate your configuration.
Maintenance and Troubleshooting
The show sipd policy command includes four additional counters that refer to single and multistage local policy
lookups. All counters are reported for the recent period, and lifetime total and lifetime period maximum. These
counters are:
•
•
•
•
Local Policy Inits—Number of times the Oracle USM makes an initial local policy lookup.
Local Policy Results Max—Number of times the Oracle USM truncated the number of routes returned for a local
policy lookup because the maximum number of routes per local policy lookup (max lp lookups routes per lookup)
threshold was reached.
Local Policy Exceeded—Number of times the Oracle USM truncated the number of routes returned for a local
policy lookup because the maximum number of routes per message request (total lp routes) threshold was reached.
Local Policy Loops—Number of times the Oracle USM detected a loop while performing a multistage local
policy lookup.
Traps
An SNMP trap is generated to notify that the limit on the additional lp lookups threshold has been reached during the
recent window period. This trap occurs a maximum of once during a window period.
apSysMgmtLPLookupExceededTrap NOTIFICATION-TYPE
STATUS
current
DESCRIPTION
" The trap will be generated the first time the additional Local
Policy Lookups limit is reached is in the recent window period. The trap will
only occur once during a window period."
::= { apSystemManagementMonitors 65}
Routing Based on UA Capabilities
In compliance with RFC 3841, the Oracle USM is able to make forwarding and forking decisions based on
preferences indicated by the UA. To do this, the Oracle USM evaluates each callee’s AOR contact to determine the
capabilities advertised by the UA and uses this information to make forwarding and forking decisions.
Prior to this support, the Oracle USM made routing preference decisions solely via the q value present in the contact
header. In cases where the preferences were equal, the Oracle USM simply forwarded to those contacts
simultaneously (parallel forking). In cases where the q value were not equal, the Oracle USM forwarded in sequence
(sequential forking), forwarding to the highest q value first.
The Oracle USM now extends upon this functionality by scoring contacts, based on their capabilities, and making
forwarding decisions using that score in addition to the q value.
There is no additional Oracle USM configuration required to enable or invoke this processing. This functionality is
supported for HSS, ENUM and Local Database configurations.
Oracle® Communications Unified Session Manager
301
Routing with Local Policy
UE Capabilities
RFC2533 includes a framework that defines feature sets. Feature sets make up a group of media capabilities
supported by a UA, individually referred to as media feature tags. In session networks, feature tag information is
converted to a form specified in RFC3840 and exchanged between devices in the network to establish lists of UA
capabilities. Based on these capabilities, session operation procedures are performed that facilitate preferred
communications modalities.
RFC3840 defines:
•
•
•
•
The format a UA uses to specify feature sets
How a UA registers capabilities within the network
An extension to the contact header so that it can include feature parameters
The media tags that specify each capability
The full list of applicable media tags is presented in RFC 3840. Examples of tags include audio, automata, data,
mobility, application and video.
Registering Capabilities at the Oracle USM
Endpoints register their capabilities by listing them in the Contact headers of the REGISTER request. The Oracle
USM stores these feature parameters in its registration cache along with the other contact information. In the case of
ENUM databases, the Oracle USM also sends capabilities information to the ENUM infrastructure so that it can
maintain capabilities records.
In addition to the standard set of tags, the Oracle USM supports storing custom feature tags. Tags formatted with a +
sign preceding the tag are recognized as custom tags. The exception to this are tags formatted using +sip.<tagname>,
which are registered sip media feature tags.
An example of a contact header specifying audio, video and methods capabilities is shown below:
Contact: sip:u1@h.example.com;audio;video;methods="INVITE,BYE";q=0.2
Preferential Routing
The Oracle USM routes using UA capabilities only when acting as S-CSCF. It calculates preferred forwarding and
forking using this information in conjunction with UA requests. This calculation is based on Preferential Routing, as
defined in RFC3841. Note that the q value is used in this calculation.
Using Preferential Routing, the Oracle USM creates a target UA list from applicable contacts by matching capabilities
with preferences. After creating the match list, it scores UEs based on how closely they match the preferred criteria.
The system determines the forwarding order referring to the q value first and then the routing score. UEs for which
both scores are equal are forwarded at the same time. All remaining UEs are forwarded sequentially.
The table below presents an example wherein the result of matching and scoring calculations causes the Oracle USM
to forwards sequentially to UE3, then UE2, then UE1.
User Agent
q Value
Preferential Score
UE3
1000
1000
UE1
500
1000
UE2
1000
700
UAs may or may not include capability request information in their messages. Preferential routing processing
accounts for this by defining both explicit and implicit feature preference processing procedures.
Explicit Feature Preference
RFC3841 defines the two headers that a UA can use to explicitly specify the features the target UA must support,
including:
302
Oracle® Communications Unified Session Manager
Routing with Local Policy
Accept-Contact: — UEs the session initiator would like to reach
Reject-Contact: — UEs the session initiator does not want to reach
When the Oracle USM receives messages that includes these headers, it gathers all the contacts associated with the
AOR and creates a target list using preferential routing calculations. The example below, drawn from RFC 3841,
specifies the desire to route to a mobile device that can accept the INVITE method.
Accept-Contact: *;mobility="mobile";methods="INVITE"
The “require” and explicit Feature Tag Parameters
RFC 3841 defines operational procedures based on the require and explicit feature tag parameters, which the Oracle
USM fully supports. UAs include these parameters in the accept-contact: header to further clarify capabilities
requirements for the session. The Oracle USM can use these parameters to exclude contacts or specify the forwarding
order.
To summarize the use of these parameters per RFC 3841:
When both parameters are present, the Oracle USM only forwards to contacts that support the features and have
registered that support.
If only the require parameter is present, the Oracle USM includes all contacts in the contact list, but uses a forwarding
sequence that places the “best” match (with the most matching capabilities) first from those with the same q value.
If only the explicit parameter is present, the Oracle USM includes all contacts in the contact list, but uses a
forwarding sequence that places contacts that have explicitly indicated matching capabilities before those with the
same q value. Unlike requests that specify both require and explicit, non-matching contacts may be tried if the
matching ones fail.
If neither parameter is present, the Oracle USM includes all contacts in the contact list, but determines a “best” match
based on the “closest” match to the desired capabilities. Again the forwarding order starts with contacts that have the
same q value.
Note that this preferential routing sequence can proceed with attempts to reach contacts with a lower q value after the
sequences above are exhausted. Note also that the orders calculated by preferential routing never override any
forwarding order specified by the UA.
Implicit Feature Preference
If the caller does not include accept-contact or reject-contacts in the message, the Oracle USM makes implicit feature
preference assumptions. Implicit feature preference forwards messages to target UEs that support the applicable
method, and, in the case of SUBSCRIBE requests, that support the applicable event.
For implicit feature preference cases, the Oracle USM uses the UE’s q value solely to determine parallel and
sequential forking.
Supporting Media Sessions Established via ICE
The Oracle USM supports media session establishment for stations running Interactive Connectivity Establishment
(ICE) despite the addressing changes made during normal operations. By inserting Oracle USM media interface
addresses as relay candidates for all components (RTP, RTCP, and so forth) within the SDP offer/answer, the Oracle
USM prevents ICE mismatch detection that would otherwise stop further ICE processing, including pair nomination
and status updating. If the Oracle USM did not do this, the call would then proceed under the control of the B2BUA,
which would select the media path instead of ICE.
As defined in RFC 5245, ICE defines the insertion of "candidate" addressing within the SDP offer/answer messaging.
In conjunction with STUN (RFC 5389), the associated call setup procedure includes connectivity checks to these
addresses, which must pass before a media session can proceed. This mechanism helps overcome a variety of network
intricacies, including NAT traversal. In addition, RFC 5245 specifies a security mechanism that requires the address
outlined in the default media destination be included as a candidate. This default media destination is presented in the
Oracle® Communications Unified Session Manager
303
Routing with Local Policy
SDP's "m" and "c" lines. Normal SBC operations, to which the Oracle USM complies, includes altering this data to
support media negotiation and/or media transport. This scenario causes an ICE mismatch. This feature prevents these
mismatches.
Users configure this support on the Oracle USM using a sip-config option called turn-on-the-fly. With this option
enabled, the Oracle USM inserts its own addressing as a relay candidate. This mechanism is based on RFC 5766
Traversal Using Relays around NAT (TURN), which itself is an extension of RFC 5389, Session Traversal Utilities
for NAT (STUN).
The Oracle USM inserts itself as a lowest priority candidate. This ensures that ICE would choose the Oracle USM as
a participant in the media path last.
In the SDP example below, the Oracle USM has replaced address and port information in the c and m lines with its
own media port information. In this case, ICE checks determine that the Oracle USM address is not in the candidate
list, to the media flows normally without further ICE processing.
c=IN IP4 172.16.101.15
m=audio 15086 RTP/AVP 103
a=candidate:5c0a80165 1 UDP
2130706431 172.16.100.166 2340 typ srflx
raddr 192.168.1.101 rport 2340
a=candidate:Hc0a80165 1 UDP
1694498815 192.168.1.101 2340 typ host
In the SDP example below, the user has enabled the turn-on-the-fly option, so the Oracle USM inserts itself as a
relay candidate. The ICE checks pass and the media proceeds using ICE processing. Note also the priority designation
of 255, which is ICE's lowest priority.
c=IN IP4 172.16.101.15
m=audio 15086 RTP/AVP 103
a=candidate:5c0a80165 1 UDP
2130706431 172.16.100.166 2340 typ srflx
raddr 192.168.1.101 rport 2340
a=candidate:Hc0a80165 1 UDP
1694498815 192.168.1.101 2340 typ host
a=candidate:C214c2Jj 1 UDP 255
172.16.101.15 15086 typ relay raddr
172.16.101.15 rport 15086
Further implementation details include:
•
•
•
•
•
The Oracle USM uses latching to specify media flow source and destination addressing for endpoints behind a
NAT. This is also true for RTCP, requiring the user to enable the hnt-rtcp parameter in the media-manager
element.
To ensure that the IP address and port pair used by the applicable outbound flow is reused for the inbound flow,
enable the symmetric-latching parameter in the access signaling realm element.
The Oracle USM disables flow guard timing for calls whose media paths are identified by ICE. Normal SIP
session timers take down calls that fail to terminate.
The Oracle USM sets up NAT entries assuming the RTCP address is (RTP IP address:RTP port +1).
Use media management on the Oracle USM in conjunction with this turn-on-the-fly configuration. If not, the
resultant media release by the Oracle USM causes unpredictable media path selection.
Configuring Support for ICE
Use the two configurations, shown below, to enable the Oracle USM to properly manage SDP for ICE processing.
1. From superuser mode, use the following command sequence to access
sip-config configuration mode.
304
Oracle® Communications Unified Session Manager
Routing with Local Policy
ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# sip-config
2. Use the select command to access the sip-config element.
3. Enable the turn-on-the-fly option.
ORACLE(sip-config)# +option turn-on-the-fly enabled
ORACLE(sip-config)# done
ORACLE(sip-config)# exit
4. Use the hnt-rtcp command to enable the insertion of addressing to accommodate NAT traversal by RTCP.
ORACLE(configure)# media-manager
ORACLE(media-manager)# hnt-rtcp enabled
5. Navigate to the access realm element to enable symmetric latching.
ORACLE(media-manager)# done
ORACLE(media-manager)# realm-config
ORACLE(realm-config)# select
Select the realm to which the source endpoint belongs.
ORACLE(realm-config)# symmetric-latching enabled
6. Use done, exit configuration mode, and run verify-config to complete ICE support configuration.
ORACLE(realm-config)# done
ORACLE(media-manager)# done
ORACLE(media-manager)# exit
ORACLE(configure)# exit
ORACLE# verify-config
--------------------------------------------------------------------Verification successful! No errors nor warnings in the configuration
ORACLE#
Routing-based RN and CIC
When the Oracle USM performs local policy routing, it selects local policy entries based on from addresses, to
addresses, and source realms. All three are configurable in the local policy configuration. The to addresses can either
be the username in a Request-URI (if it is an E.164/phone number format), or the request-URI’s hostname or IP
address. The Oracle USM sorts matching local policies based on policy attribute entries. A policy attribute defines a
next hop, which can be a session agent or a session agent group. Alternatively, the next hop might define an ENUM
server group or local route table to use to find the next hop.
If the routing-based RN and CIC feature is not enabled, the Oracle USM performs the subsequent ENUM query or
local route table lookup using the Request-URI’s username, if it is a telephone number (TN). The TN is the
normalized user part of the Request-URI, ignoring any user parameters or non-digit characters.
If the routing-based RN and CIC feature is enabled, the Oracle USM instead performs the ENUM or local route table
lookup based on a user parameter, which is useful for lookups based on routing number (RN) or carrier identification
code (CIC):
•
•
An RN is a number that identifies terminating switch nodes in Number Portability scenarios when the original TN
has been moved to the switch defined by the RN.
A CIC is the globally unique number of the terminating carrier to which a ported number has been moved.
In applications where the Oracle USM is given the RN or the CIC in the Request-URI, this feature is useful because
the Oracle USM can perform an additional ENUM or local route table lookup to find the next hop to the RN or the
CIC. Typically, ENUM servers have imported Number Portability data with which to respond to the Oracle USM
query, and (for example) the Oracle USM can use local route tables for storing CIC values for direct carrier hand-off.
Even with this feature enabled, the Oracle USM still performs local policy match selection based on the TN. This
feature only uses the RN or CIC user-parameter for the ENUM or local route table lookup after the local policy and
policy attributes have been selected.
Oracle® Communications Unified Session Manager
305
Routing with Local Policy
Routing-based RN Configuration
This section shows you how to specify that a set of local policy attributes should use an RN for lookup. You can also
set this value to CIC, or to any value you require.
You can set the lookup key to an RN in the local policy attributes’ next-hop parameter.
To set the lookup key to RN:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter.
ORACLE(configure)# session-router
3. Type local-policy and press Enter.
ORACLE(session-router)# local-policy
ORACLE(local-policy)#
4. Type policy-attributes and press Enter.
ORACLE(local-policy)# policy-attributes
ORACLE(local-policy-attributes)#
5. next-hop—In the next-hop parameter—after the kind of ENUM service used—type a colon (;). Then, without
spaces, type in key=rn and press Enter.
ORACLE(local-policy-attributes)# next-hop lrt:lookup;key=rn
6. Save and activate your configuration.
Codec Policies for SIP
The Oracle USM has the ability to add, strip, and reorder codecs for SIP sessions. This builds on the Oracle USM’s
pre-existing abilities to route by codec and reorder one codec in an SDP offer by allowing you to configure the order
of multiple codecs and to remove specific codecs within the media descriptions in SDP offers.
You can enable the Oracle USM to perform these operations on SDP offers by configuring codec policies. Codec
policies are sets of rules that specify the manipulations to be performed on SDP offers. They are applied on an ingress
and egress basis using the realm and session agent configurations.
Oracle USM supports three types of codec policies:
•
•
•
Ingress policy—Codec policy that the Oracle USM applies to the SDP offer for incoming traffic
Egress policy—Codec policy that the Oracle USM applies to the SDP offer for traffic leaving the Oracle USM
Conditional policy—Codec policy that the Oracle USM applies to the SDP offer for traffic leaving the Oracle
USM. A conditional policy differs from an egress policy in providing the capability to perform standard codec
manipulations (add and strip) dynamically, based on the codec list and associated parameters contained in the
original SDP offer.
The Oracle USM applies codec policies during the offer phase of media format negotiation. If codec manipulation is
enabled, then the Oracle USM performs the modification according to the specific policy and forwards on the traffic.
For example, when the Oracle USM receives a SIP INVITE with SDP, it refers to the realm through which the
INVITE arrived and performs any manipulations specified by an ingress codec policy that may have been assigned to
the ingress realm. With the media description possibly changed according to the ingress codec policy, the Oracle
USM passes the SDP offer to the outgoing realm so that the an egress codec policy can be applied. Note that the SDP
to be evaluated by the egress codec policy may match the original SDP, or it may have been changed during transit
through the ingress realm. After applying the egress coded policy, the Oracle USM forwards the INVITE.
306
Oracle® Communications Unified Session Manager
Routing with Local Policy
Since the offer-answer exchange can occur at different stages of SIP messaging, the assigned ingress and egress roles
follow the media direction rather than the signaling direction. It might be, for example, that the offer is in an OK that
the Oracle USM modifies.
You can apply codec policies to realms and to session agents; codec policies configured in session agents take
precedence over those applied to realms. However, it is not required that there be both an ingress and an egress policy
either for realms or for session agents. If either one is unspecified, then no modifications take place on that side. If
neither ingress nor egress policies specified, SDP offers are forwarded as received.
Relationship to Media Profiles
For each codec that you specify in a codec policy, there must be a corresponding media profile configuration on the
Oracle USM. You configure media profiles in the ACLI via the session-router path. In them, you can specify codec
type, transport protocol, required bandwidth, and a number of constraints.
Manipulation Modes
You can configure a codec policy to perform several different kinds of manipulations:
•
Allow—List of codecs that are allowed for a certain codec policy; if a codec does not appear on this list, then the
Oracle USM removes it. You can wildcard this list with an asterisk (*) so that all codecs are allowed. Further, you
can create exceptions to a wildcarded allow list.
•
•
•
You make an exception to the wildcarded list of codecs by entering the codec(s) that are not allowed with a no
attribute. This tells the Oracle USM to allow all codecs except the one(s) you specify.
ACMEPACKET(codec-policy)# allow-codecs (* PCMA:no)
You can also create exceptions to allow lists such that audio or video codecs are removed. However, when the
allow list specifies the removal of all audio codecs and an INVITE arrives at the Oracle USM with only audio
codecs, the Oracle USM behaves in accordance with RFC 3264. This means that the resulting SDP will
contain one attribute line, with the media port for the media line set to 0. The terminating side will need to
supply new SDP in its reply because the result of the manipulation is the same as an INVITE with no body.
ACMEPACKET(codec-policy)# allow-codecs (* audio:no)
Order—List of the codecs where you specify their preferred order in the outgoing media offer. The Oracle USM
arranges matching codecs according to the rule you set, and any remaining ones are added to the list in the same
relative order they took in the incoming media offer. If your list specifies a codec that is not present, then the
ordering proceeds as specified but skips the missing codec.
You can use an asterisk (*) as a wildcard in this list, too. The placement of the asterisk is key, as you can see in the
following examples:
Oracle® Communications Unified Session Manager
307
Routing with Local Policy
•
For an order rule set this way
ACMEPACKET(codec-policy)# order (A B C *)
•
codecs A, B, and C will be placed at the front of the codec list in the order specified; all other codecs in the
offer will follow A, B, and C in the same relative order they had in the original SDP offer.
For an order rule set this way:
ACMEPACKET(codec-policy)# order (* A B C)
•
codecs A, B, and C will be placed at the end of the codec list in the order specified; all other codecs in the offer
will come before A, B, and C in the same relative order they had in the original SDP offer.
For an order rule set this way
ACMEPACKET(codec-policy)# order (A * B C)
•
codec A will be placed at the beginning of the codec list, to be followed by all other codecs in the offer in the
same relative order they had in the original SDP offer, and then B and C will end the list.
Force—An attribute you can use in the allow list with one codec to specify that all other codecs should be stripped
from the outgoing offer. You can specify multiple forced codecs in your rules.
•
•
If you set multiple codecs in the allow list and one of them is forced, then the outgoing offer will contain the
forced codec.
If you set multiple codecs in the allow list and the one that is forced is not present in the offer, then the Oracle
USM will select a non-forced codec for the outgoing offer.
ACMEPACKET(codec-policy)# allow (PCMU G729:force)
•
You cannot use the force attribute with a wildcarded allow list.
No—An attribute that allows you to strip specified codecs or codec types from a wildcarded allow list.
ACMEPACKET(codec-policy)# allow (* PCMA:no)
In-Realm Codec Manipulation
In addition to being able to apply codec policies in realms, the realm configuration supports a setting for determining
whether codec manipulation should be applied to sessions between endpoints in the same realm.
In-realm codec manipulation can be used for simple call flows that traverse two realms. If the originating and
terminating realms are the same, the Oracle USM checks to see if you have enabled this capability. If you have
enabled it, then the Oracle USM performs the specified manipulations. If this capability is not enabled, or if the
realm’s media management in realm (mm-in-realm) setting is disabled, then the Oracle USM does not perform codec
manipulations.
For more complex calls scenarios that involve call agent or reinitiation of a call back to the same realm, the Oracle
USM does not perform in-realm codec manipulation.
Codec Policy Configuration
This section gives instructions and examples for how to configure codec policies and then apply them to realms and
session agents. It also shows you how to configure settings for in-realm codec manipulation.
Creating a Codec Policy
To create a codec policy:
1. In Superuser mode, type configure terminal and press Enter.
ACMEPACKET# configure terminal
2. Type media-manager and press Enter to access the signaling-related configurations.
ACMEPACKET(configure)# media-manager
ACMEPACKET(media-manager)#
3. Type codec-policy and then press Enter.
308
Oracle® Communications Unified Session Manager
Routing with Local Policy
ACMEPACKET(media-manager)# codec-policy
ACMEPACKET(codec-policy)#
4. name—Enter the unique name for the codec policy. This is the value you will use to refer to this codec policy
when you apply it to realms or session agents. This parameter is required and is empty by default.
5. allow-codecs—Enter the list of media format types (codecs) to allow for this codec policy. In your entries, you can
use the asterisk (*) as a wildcard, the force attribute, or the no attribute so that the allow list you enter directly
reflects your configuration needs. Enclose entries of multiple values in parentheses ( ( ) ).
The codecs that you enter here must have corresponding media profile configurations.
6. add-codecs-on-egress—Enter the codecs that the Oracle USM adds to an egress SDP offer if that codec is not
already there. This parameter applies only to egress offers.
The codecs that you enter here must have corresponding media profile configurations.
add-codecs-on-egress can be used to construct ingress, egress, or conditional codec policies.
7. order-codecs—Enter the order in which you want codecs to appear in the outgoing SDP offer. Remember that you
can use the asterisk (*) as a wildcard in different positions of the order to directly reflect your configuration needs.
Enclose entries of multiple values in parentheses ( ( ) ).
The codecs that you enter here must have corresponding media profile configurations.
8. Save and activate your configuration.
Your codec policy configuration will resemble the following example:
codec-policy
name
allow-codecs
order-codecs
private
g723:no pcmu video:no
pcmu
Applying a Codec Policy to a Realm
Note that codec policies defined for session agents always take precedence over those defined for realms.
To apply a codec policy to a realm:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type media-manager and press Enter.
ORACLE(configure)# media-manager
3. Type realm-config and press Enter.
ORACLE(media-manager)# realm-config
If you are adding support for this feature to a pre-existing realm, then you must select (using the ACLI select
command) the realm that you want to edit.
4. codec-policy—Enter the name of the codec policy that you want to apply to this realm. By default, this parameter
is empty.
5. Save and activate your configuration.
Applying a Codec Policy to a Session Agent
Note that codec policies that are defined for session agents always take precedence over those that are defined for
realms.
To apply a codec policy to a realm:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter.
ORACLE(configure)# session-router
Oracle® Communications Unified Session Manager
309
Routing with Local Policy
3. Type session-agent and press Enter.
ORACLE(session-router)# session-agent
If you are adding support for this feature to a pre-existing session agent, then you must select (using the ACLI
select command) the realm that you want to edit.
4. codec-policy—Enter the name of the codec policy that you want to apply to this realm. By default, this parameter
is empty.
5. Save and activate your configuration.
In-Realm Codec Manipulations
To enable in-realm codec manipulations:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type media-manager and press Enter.
ORACLE(configure)# media-manager
3. Type realm-config and press Enter.
ORACLE(media-manager)# realm-config
If you are adding support for this feature to a pre-existing realm, then you must select (using the ACLI select
command) the realm that you want to edit.
4. codec-manip-in-realm—Enter the name of the codec policy that you want to apply to this realm. The default value
is disabled. The valid values are:
• enabled | disabled
5. Save and activate your configuration.
QoS Based Routing
In addition to configuring your system for routing based on certain session constraints, you can also set up routing
based on QoS. QoS based routing uses the R-Factor on a per-realm basis to either cut back on the traffic allowed by a
specific realm, or to shut that traffic off altogether.
To use this feature, you set up QoS constraints configurations and apply one per realm. The QoS constraints
configuration allows you to set up two thresholds:
•
•
Major—The major threshold sets the R-Factor limit beyond which the Oracle USM rejects a certain percentage
(that you configure) of calls. That is to say, it rejects inbound calls at the rate you set with a 503 Service
Unavailable status code, and rejects outbound calls if there are no alternative routes.
Critical—The critical threshold, when exceeded, causes the Oracle USM to behave the same way it does when any
of the session constraints (set in the session-constraints configuration) are exceeded. All inbound calls to the realm
are rejected with a 503 Service Unavailable status code, and (if there is no alternate route) outbound calls are
rejected, too. Until the R-Factor falls within acceptable means and the session constraint’s time-to-resume value
has elapsed, the realm remains in this state.
Management
This feature is supported by MIBs and traps. Historical data recording (HDR) also supports this feature by providing
the following metrics in the session realm statistics collection group:
•
•
•
•
•
310
Average QoS RFactor (0-93)
Maximum QoS RFactor (0-93)
Current QoS Major Exceeded
Total QoS Major Exceeded
Current QoS Critical Exceeded
Oracle® Communications Unified Session Manager
Routing with Local Policy
•
Total QoS Critical Exceeded
QoS Contraints Configuration
This section shows you how to configure a QoS constraints configuration and then how to apply it to a realm.
Configuring QoS Constraints
Your first step to enabling QoS based routing is to set up a QoS constraints configuration. This configuration is where
you enter major and critical thresholds, as well as the load reduction for the realm should the R-Factor exceed the
major threshold.
To set up a QoS constraints configuration:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
2. Type session-router and press Enter.
ORACLE(configure)# session-router
ORACLE(session-router)#
3. Type qos-constraints and press Enter.
ORACLE(session-router)# qos-constraints
ORACLE(qos-constraints)#
4. name—Enter the name of this QoS constraints configuration. This parameter uniquely identifies the configuration,
and you use this value when applying the configuration to a realm. This parameter has no default and is required.
5. state—Set the state of this QoS constraints configuration. The default is enabled, but you can set this parameter to
disabled if you want to stop applying these constraints.
6. major-rfactor—Enter a numeric value between 0 (default) and 9321 to set the threshold that determines when the
Oracle USM applies the call reduction rate. If you leave this parameter set to 0, then the Oracle USM will not
apply a major threshold for any realm where you apply this QoS constraints configuration.
Note that this value must be greater than that you set for the critical-rfactor, except when the major-rfactor is 0.
7. critical-rfactor—Enter a numeric value between 0 (default) and 9321 to set the threshold that determines when the
Oracle USM rejects all inbound calls for the realm, and rejects outbound calls when there is no alternate route. If
you leave this parameter set to 0, then the Oracle USM will not apply a critical threshold for any realm where you
apply this QoS constraints configuration.
Note that this value must be less than that you set for the major-rfactor, except when the major-rfactor is 0.
8. call-load-reduction—Enter a number from 0 (default) to 100 representing the percentage by which the Oracle
USM will reduce calls to the realm if the major-rfactor is exceeded. If you leave this parameter set to 0, then the
Oracle USM will not reduce call load for the realm—even when the major-rfactor is configured.
This is the percentage of inbound and outbound calls the Oracle USM will reject. For example, if you set this
parameter to 50 and the major threshold is exceeded, then the Oracle USM rejects every other call to the realm.
9. Save and activate your configuration.
Applying QoS Constraint to a Realm
You apply QoS constraints to realms using the qos-constraint parameter.
To apply a QoS constraint to a realm:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
2. Type media-manager and press Enter
ORACLE(configure)# media-manager
ORACLE(media-manager)#
Oracle® Communications Unified Session Manager
311
Routing with Local Policy
3. Type realm-config and press Enter. If you adding this feature to a pre-existing realm, then you need to select and
edit that realm.
ORACLE(media-manager)# realm-config
ORACLE(realm-config)#
4. qos-constraints—Enter the name value from the QoS constraints configuration you want to apply to this realm.
Save and activate your configuration.
312
Oracle® Communications Unified Session Manager
7
ENUM Based Oracle USM
The Oracle USM contacts an ENUM server via DNS for two purposes:
•
•
to obtain authentication data for a registering UA (often referred to as a UE)
to query the user subscriber database (ENUM) regarding the registration state of the AoR and update the database
with the latest information
Message Authentication for SIP Requests
The Oracle USM authenticates requests by configuring the sip authentication profile configuration element. The name
of this configuration element is either configured as a parameter in the sip registrar configuration element’s
authentication profile parameter or in the sip interface configuration element’s sip-authentication-profile parameter.
This means that the Oracle USM can perform SIP digest authentication either globally, per domain of the Request
URI or as received on a SIP interface.
After naming a sip authentication profile, the received methods that trigger digest authentication are configured in the
methods parameter. You can also define which anonymous endpoints are subject to authentication based on the
request method they send to the Oracle USM by configuring in the anonymous-methods parameter. Consider the
following three scenarios:
1. By configuring the methods parameter with REGISTER and leaving the anonymous-methods parameter blank, the
Oracle USM authenticates only REGISTER request messages, all other requests are unauthenticated.
2. By configuring the methods parameter with REGISTER and INVITE, and leaving the anonymous-methods
parameter blank, the Oracle USM authenticates all REGISTER and INVITE request messages from both
registered and anonymous endpoints, all other requests are unauthenticated.
3. By configuring the methods parameter with REGISTER and configuring the anonymous-methods parameter with
INVITE, the Oracle USM authenticates REGISTER request messages from all endpoints, while INVITES are
only authenticated from anonymous endpoints.
Credential Retrieval
The Oracle USM requests authentication information from an ENUM server via DNS when it receives a REGISTER
or other message from an endpoint. This server, which provides authentication information, is defined on the Oracle
USM in an enum-config configuration element that includes an enum-servers (the IP addresses of the servers) and
realm parameters. Together, these two parameters define the DNS/ENUM server(s) which provide authentication
data.
Oracle® Communications Unified Session Manager
313
ENUM Based Oracle USM
The target ENUM server is determined first by setting the credential retrieval config parameter to enum-config so the
Oracle USM will reference that enum config. Next, set the credential retrieval config parameter to the name of an
enum config configuration element which is populated with the ENUM servers’ IP addresses.
User Authentication Query
As soon as a request is received on a SIP interface and has been determined to require authentication, the Oracle USM
attempts to authenticate the endpoint. It sends a DNS TXT query including the UA’s AoR to an ENUM database and
expects the H(A1) defined in RFC2617 for the user being authenticated.
SIP Digest User Authentication
SIP Authentication Challenge
When the Oracle USM receives a response from the ENUM server including the hash value for the user, it sends a
SIP authentication challenge to the endpoint, if the endpoint did not provide any authentication headers in its initial
contact the with Oracle USM. If the endpoint is registering, the Oracle USM replies with a 401 Unauthorized message
with the following WWW-Authenticate header:
WWW-Authenticate: Digest realm="atlanta.com", domain="sip:boxesbybob.com",
qop="auth", nonce="f84f1cec41e6cbe5aea9c8e88d359", opaque="", stale=FALSE,
algorithm=MD5
If the endpoint initiates any other request to the Oracle USM besides REGISTER, the Oracle USM replies with a 407
Proxy Authentication Required message with the following Proxy-Authenticate header:
Proxy-Authenticate: Digest realm="atlanta.com", qop="auth",
nonce="f84f1cec41e6cbe5aea9c8e88d359", opaque="", stale=FALSE, algorithm=MD5
Authentication Header Elements
•
•
•
•
•
•
•
Digest Realm—This value is configured in the digest-realm parameter in the sip-registrar configuration element.
This parameter is mandatory when using the "ENUM-TXT" credential retrieval method.
Domain—A quoted, space-separated list of URIs that defines the protection space. This is an optional parameter
for the "WWW-Authenticate" header.
Nonce—A unique string generated each time a 401/407 response is sent.
Qop—A mandatory parameter that is populated with a value of "auth" indicating authentication.
Opaque—A string of data, specified by the Oracle USM which should be returned by the client unchanged in the
Authorization header of subsequent requests with URIs in the same protection space.
Stale—A flag indicating that the previous request from the client was rejected because the nonce value was stale.
This is set to true by the SD when it receives an invalid nonce but a valid digest for that nonce.
Algorithm—The Oracle USM always sends a value of "MD5"
SIP Authentication Response
After receiving the 401/407 message from the Oracle USM, the UA resubmits its original request with an
Authorization: header including its own internally generated MD5 hash.
Oracle USM Authentication Check
At this point, the Oracle USM has received an MD5 hash from the ENUM server and an MD5 hash from the UA. The
Oracle USM compares the two values and if they are identical, the endpoint is successfully authenticated. Failure to
match the two hash values results in a 403 or 503 sent to the authenticating endpoint.
The following image shows the user authentication process.
314
Oracle® Communications Unified Session Manager
ENUM Based Oracle USM
Oracle USM as Registrar
DDNS Update to User Subscriber Database
As REGISTER messages are received, the Oracle USM updates the ENUM database via DDNS UPDATE messages
as defined by RFC2136. New registrations are added to the database while expired or deleted registrations are
removed.
The Oracle USM acts as a registrar by configuring the sip registrar configuration element. When registrar
functionality is enabled, the Oracle USM acts as a registrar rather than only caching and forwarding registrations to
another device. Oracle USM registry services are enabled globally per domain, not on individual SIP interfaces or
other remote logical entities.
On receiving a REGISTER message, the Oracle USM checks if it is responsible for the domain contained in the
Request-URI as defined by the domains parameter and finds the corresponding sip registrar configuration. This is a
global parameter and all messages are checked against all sip registrar domains. Thus you could create one sip
registrar configuration element to handle all *.com domains and one sip registrar configuration element to handle all
*.org domains. The Oracle USM begins registrar functions for all requests that match the configured domain per sipregistrar configuration element.
A UA is considered registered after the Oracle USM updates the ENUM server with a DDNS dynamic update. After
this action, the Oracle USM sends a 200 OK message back to the registering UA.
TTL
Part of the Oracle USM architecture includes a local ENUM cache which maintains the results from ENUM queries
locally. To enable Oracle USM, the TTL value in the enum config must be set to 0. This ensures that whenever an
ENUM query is required, the Oracle USM consults the central User Subscriber Database to have the latest networkwide information about the UA it is trying to reach, instead of its ENUM cache.
ENUM Database Correlation
When a UA registers, as the number of associated contacts for an AoR grows or shrinks, the ENUM-based User
Subscriber Database is updated in turn with the latest information using a DDNS UPDATE. After a REGISTER
including authentication information is received from a UA, the Oracle USM sends a Standard NAPTR query for the
AoR to the ENUM server. The ENUM server replies with a Standard Query response, including the NAPTR records.
Oracle® Communications Unified Session Manager
315
ENUM Based Oracle USM
After receiving the entries from the ENUM database via the ENUM query, the list must be correlated with the Oracle
USM’s view of the AoR’s registration state. The differences will be resolved by sending a DDNS UPDATE to add or
remove entries from the ENUM server. The database correlation phase only occurs when endpoints register.
Contacts that need to be added are put on the UPDATE add list. Contacts that are being unregistered (contact with
Expires=0) or have expired timestamp are added to the UPDATE remove list.
Entry Expiration
The Oracle USM employs a process to remove expired contacts from the ENUM database whether they were entered
by the active Oracle USM or other Oracle USM. After determining that a contact is expired, the Oracle USM removes
the contact in a subsequent DDNS update.
To do this, the Oracle USM includes an expiration parameter in the Contacts it insert into the ENUM database.
Expiration is indicated with a ts= parameter. This parameter’s value is set to the initial registration time measured on
the Oracle USM plus the REGISTER message’s Expires: header value or Expires para