Beruflich Dokumente
Kultur Dokumente
Controller
Configuration Guide
Release S-CZ7.3.0
September 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
2 Getting Started.............................................................................. 43
Installation and Start-Up..................................................................................................................................... 43
Hardware Installation Process................................................................................................................. 43
Connecting to Your Oracle Communications Session Border Controller...............................................44
System Boot............................................................................................................................................ 45
Oracle Communications Session Border Controller Boot Parameters................................................................46
Boot Parameters...................................................................................................................................... 46
Boot Parameter Definitions..................................................................................................................... 46
Boot Parameter Changes......................................................................................................................... 48
Acme Packet 6000 Boot Parameters....................................................................................................... 50
Setting Up System Basics....................................................................................................................................51
New System Prompt................................................................................................................................51
Security Update for Default / Hard-coded Passwords.............................................................................51
Using the Oracle Communications Session Border Controller Image................................................................52
Software Images...................................................................................................................................... 52
Obtaining a New Image...........................................................................................................................53
Copy an Image to the Oracle Communications Session Border Controller using SFTP........................ 53
Booting an Image on Your Oracle Communications Session Border Controller................................................54
Booting from Flash Memory...................................................................................................................54
Booting from an External Device............................................................................................................54
Software Licensing..............................................................................................................................................55
Unlicensed Oracle Communications Session Border Controller............................................................ 55
System Provisioning................................................................................................................................55
High Availability (HA) Pair Licensing................................................................................................... 58
Keyed Licenses and Provisioned Entitlements Compatibility................................................................ 63
Legacy - Obtaining a License..................................................................................................................63
Legacy - Standalone System Licensing...................................................................................................63
Legacy - License Expiration....................................................................................................................65
Legacy Viewing Licenses........................................................................................................................65
RADIUS Authentication..................................................................................................................................... 67
PAP Handshake....................................................................................................................................... 68
CHAP Handshake....................................................................................................................................69
MS-CHAP-v2 Handshake....................................................................................................................... 69
Management Protocol Behavior..............................................................................................................70
RADIUS Authentication Configuration..................................................................................................71
TACACS+ AAA..................................................................................................................................................73
TACACS+ Introduction.......................................................................................................................... 73
TACACS+ Administrative Security........................................................................................................73
7 IWF Services................................................................................613
Access Network Application.............................................................................................................................613
Networking Peering Application.......................................................................................................................614
SIP and H.323....................................................................................................................................................615
SIP H.323 Negotiation H.323 Fast Start............................................................................................... 615
SIP H.323 Negotiation H.323 Slow Start..............................................................................................616
Status and Codec Mapping....................................................................................................................618
14 Security..................................................................................... 889
Security Overview.............................................................................................................................................889
Denial of Service Protection..............................................................................................................................890
Levels of DoS Protection...................................................................................................................... 891
About the Process..................................................................................................................................892
Trusted Path...........................................................................................................................................892
Untrusted Path....................................................................................................................................... 893
Static and Dynamic ACL Entry Limits................................................................................................. 894
Dynamic Deny for HNT........................................................................................................................894
Host and Media Path Protection Process...............................................................................................894
Session Director Access Control...........................................................................................................895
Access Control Endpoint Classification Capacity and DoS..................................................................895
Media Access Control........................................................................................................................... 895
Host Path Traffic Management..............................................................................................................895
Traffic Promotion.................................................................................................................................. 895
Malicious Source Blocking................................................................................................................... 895
Blocking Actions...................................................................................................................................896
Protecting Against Session Agent Overloads........................................................................................896
ARP Flood Protection Enhancements................................................................................................... 896
Dynamic Demotion for NAT Devices................................................................................................... 896
Configuring DoS Security................................................................................................................................. 897
Configuration Overview........................................................................................................................897
Changing the Default Oracle Communications Session Border Controller Behavior.......................... 897
Access Control List Configuration........................................................................................................898
Host Access Policing.............................................................................................................................900
Configuring ARP Flood Protection.......................................................................................................901
Access Control for a Realm...................................................................................................................902
Configuring Overload Protection for Session Agents...........................................................................904
DDoS Protection from Devices Behind a NAT.....................................................................................905
Media Policing.................................................................................................................................................. 907
Policing Methods...................................................................................................................................907
Configuration Notes.............................................................................................................................. 908
Media Policing Configuration for RTP Flows...................................................................................... 908
Media Policing Configuration for Static Flows.................................................................................... 909
RTP Payload Type Mapping..................................................................................................................910
ITU-T to IANA Codec Mapping...........................................................................................................910
SDP Anonymization..............................................................................................................................911
SDP Anonymization Configuration...................................................................................................... 911
Unique SDP Session ID........................................................................................................................ 912
Unique SDP Session ID Configuration................................................................................................. 912
TCP Synchronize Attack Prevention.................................................................................................................912
About SYN............................................................................................................................................ 912
17 IMS Support.............................................................................1091
Oracle Communications Session Border Controller Access Border Functions.............................................. 1092
Oracle Communications Session Border Controller Interconnect Border Functions..................................... 1092
IMS Access Border Functions.........................................................................................................................1092
P-CSCF Functions...............................................................................................................................1092
A-BGF Functions................................................................................................................................ 1093
Resource and Admission Control (RACS) Functions.........................................................................1093
IMS Interconnect Border Functions................................................................................................................ 1094
Interworking Function (IWF)..............................................................................................................1094
Interconnect Border Control Function (I-BCF)...................................................................................1094
Interconnect-Border Gateway Function (I-BGF)................................................................................ 1094
IMS Path and Service Route Header Support................................................................................................. 1094
Path Header......................................................................................................................................... 1094
Service Route Header..........................................................................................................................1095
Summary............................................................................................................................................. 1095
IMS Path and Service Route Headers Configuration..........................................................................1096
Network Provided Location Information During Registration....................................................................... 1097
Network Provided Location Information upon Register Configuration............................................. 1097
Network Provided Location Information for Short Message Service.............................................................1098
NPLI for Short Message Service Examples........................................................................................ 1098
NPLI for Short Message Configuration.............................................................................................. 1102
18 Transcoding............................................................................. 1211
Introduction..................................................................................................................................................... 1211
Transcoding Hardware........................................................................................................................ 1211
Transcoding Configuration..............................................................................................................................1213
Transcoding Processing Overview...................................................................................................... 1213
Defining Codec Policies......................................................................................................................1213
Codec Policy Definition.................................................................................................................................. 1215
Syntax..................................................................................................................................................1215
Answer Processing and Examples...................................................................................................................1216
Unoffered Codec Reordering.............................................................................................................. 1216
Non-transcoded Call............................................................................................................................1217
Transcoded Call...................................................................................................................................1217
Voice Transcoding............................................................................................................................... 1217
RFC 2833 Transcoding........................................................................................................................1223
FAX Transcoding................................................................................................................................ 1227
Transrating...........................................................................................................................................1232
Default Media Profiles.................................................................................................................................... 1234
Transcodable Codecs...........................................................................................................................1234
Preferred Default Payload Type.......................................................................................................... 1235
Redefining Codec Packetization Time................................................................................................ 1235
mptime Support for Packet Cable....................................................................................................... 1235
EVRC Family of Codecs.................................................................................................................................1236
EVRC-A Codec for Transcoding........................................................................................................ 1236
EVRC-B Codec for Transcoding.........................................................................................................1238
T.140 to Baudot Relay.....................................................................................................................................1239
Opus Codec Transcoding Support...................................................................................................................1242
SILK Codec Transcoding Support.................................................................................................................. 1243
Glossary...................................................................................................................................... 1363
Related Documentation
The following table lists the members that comprise the documentation set for this release:
Acme Packet 4500 Hardware Installation Guide Contains information about the components and installation of
the Acme Packet 4500.
Acme Packet 3820 Hardware Installation Guide Contains information about the components and installation of
the Acme Packet 3820.
Acme Packet 4600 Hardware Installation Guide Contains information about the components and installation of
the Acme Packet 4600.
Acme Packet 6100 Hardware Installation Guide Contains information about the components and installation of
the Acme Packet 6100.
Acme Packet 6300 Hardware Installation Guide Contains information about the components and installation of
the Acme Packet 6300.
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 Service Provider 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.
Document Name Document Description
Maintenance and Troubleshooting Guide Contains information about Oracle Communications Session
Border Controller 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 Communication's 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 the Oracle Communications Session
Border Controller’s accounting support, including details about
RADIUS and Diameter accounting.
HDR Resource Guide Contains information about the Oracle Communications Session
Border Controller’s Historical Data Recording (HDR) feature.
This guide includes HDR configuration and system-wide
statistical information.
Administrative Security Essentials Contains information about the Oracle Communications Session
Border Controller’s support for its Administrative Security
license.
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.
Installation and Platform Preparation Guide Contains information about upgrading system images and any
pre-boot system provisioning.
Call Traffic Monitoring Guide Contains information about traffic monitoring and packet traces
as collected on the system. This guide also includes WebGUI
configuration used for the SIP Monitor and Trace application.
Revision History
Date Description
What Is a Realm
A realm is a logical way of identifying a domain, a network, a collection of networks, or a set of addresses. Realms
are used when a Oracle Communications Session Border Controller communicates with multiple network elements
over a shared intermediate connection. Defining realms allows flows to pass through a connection point between two
networks.
From an external perspective, a realm is a collection of systems that generates real-time interactive communication
sessions comprised of signaling messages and media flows, or a group of multiple networks containing these systems.
These systems may be session agents such as call agents, softswtiches, SIP proxies, H.323 gatekeepers, IP PBXs, etc.,
that can be defined by IPv4 addresses. These systems can also be IP endpoints such as SIP phones, IADs, MTAs,
media gateways, etc.
From an internal perspective, a realm is associated with Oracle Communications Session Border Controller
configurations to define interfaces and resources in a logical way. Realms are used to support policies that control the
collection of systems or networks that generate media sessions. Realms are referenced by other configuration
elements in order to support this functionality across the protocol the Oracle Communications Session Border
Controller supports and to make routing decisions.
Nested Realms
Nested Realms is a Oracle Communications Session Border Controller feature that supports hierarchical realm
groups. One or more realms may be nested within higher order realms. Realms and sub-realms may be created for
media and bandwidth management purposes. This feature supports:
• Separation of signaling & media on unique network interfaces
• Signaling channel aggregation for Hosted IP Services applications
• Configuration scalability
• Per-realm media scalability beyond single physical interface capacity
High Availability
High Availability (HA) is a network configuration used to ensure that planned and unplanned outages do not disrupt
service. In an HA configuration, Oracle Communications Session Border Controllers (SBC) are deployed in a pair to
deliver continuous high availability for interactive communication services. Two SBCs operating in this way are
called an HA node. The HA node design ensures that no stable call is dropped in the event of an outage.
In an HA node, one SBC operates in the active mode and the other SBCoperates in the standby mode.
• Active. The active member of the HA node is the system actively processing signal and media traffic. The active
member continuously monitors itself for internal process and IP connectivity health. If the active member detects
a condition that can interrupt or degrade service, it hands over its role as the active member of the HA node to the
standby member.
• Standby. The standby member of the HA node is the backup system. The standby member is fully synchronized
with active member's session status, but it does not actively process signal and media traffic. The standby member
monitors the status of the active member and it can assume the active role without the active system having to
instruct it to do so. When the standby system assumes the active role, it notifies network management using an
SNMP trap.
The SBC establishes active and standby roles in the following ways.
• If an SBC boots up and is alone in the network, it is automatically the active system. If you pair a second SBC
with the first one to form an HA node, the second system automatically establishes itself as the standby.
• If both SBCs in the HA node boot up at the same time, they negotiate with each other for the active role. If both
systems have perfect health, then the SBC with the lowest HA rear interface IPv4 address becomes the active
SBC. The SBC with the higher HA rear interface IPv4 address becomes the standby SBC.
If the rear physical link between the twoSBCs is unresponsive during boot up or operation, both will attempt to
become the active SBC. In this circumstance, processing does not work properly.
The standby SBC assumes the active role when:
• it does not receive a checkpoint message from the active SBC for a certain period of time.
• it determines that the active SBC health score declined to an unacceptable level.
• the active SBC relinquishes the active role.
To produce a seamless switch over from one SBC to the other, the HA node members share their virtual MAC and
virtual IP addresses for the media interfaces in a way that is similar to Virtual Router Redundancy Protocol (VRRP).
Sharing these addresses eliminates the possibility that the MAC address and the IPv4 address set on one SBC in an
HA node will be a single point of failure. Within the HA node, the SBCs advertise their current state and health to one
another in checkpointing messages to apprise each one of the other one's status. Using the Oracle HA protocol,
theSBCs communicate with UDP messages sent out and received on the rear interfaces. During a switch over, the
standby SBC sends out an ARP request using the virtual MAC address to establish that MAC address on another
physical port within the Ethernet switch. To the upstream router, the MAC address and IP address are still alive.
Existing sessions continue uninterrupted.
System Boot
When your Oracle Communications Session Border Controller boots, the following information about the tasks and
settings for the system appear in your terminal window.
Boot Parameters
• boot device—The boot device for the Oracle Communications Session Border Controller should be eth0.
• file name—The file name for the Oracle Communications Session Border Controller should start with /boot/ (if
local).
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 Communications Session Border Controller.
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 Communications Session Border Controller.
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 Communications Session Border Controller from which you will
copy a configuration.
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.
target name (tn) Name of the Oracle Communications Session Border Controller 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.
This name is required to be unique among Oracle Communications Session
Border Controllers in your network. This name can be 64 characters or less.
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
The Oracle Communications Session Border Controller 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 Communications Session Border
Controller 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.
[Acme Boot]: ?
? - print this list
@ - boot (load and go)
p - print boot params
c - change boot params
v - print boot logo with version
r - reboot
s - 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
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.
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.
For example, at login to admin level privilege when an appropriate license is found:
*ALERT*
*******************************************************
Admin password has not been set. Please change password now.
*******************************************************
* - numerals
* - punctuation
Password is acceptable.
Software Images
Software image filenames for S-CZ7.0.2F1 and higher end with the .bz extension. They should be placed in the /boot
volume.
that you can fix by stopping the countdown, entering the appropriate filename, and rebooting the Oracle
Communications Session Border Controller.
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 Communications Session Border Controller
• user—username for the FTP account on the boot host
• password—password for the FTP account on the boot host
4. Reboot your Oracle Communications Session Border Controller.
5. You are returned to the ACLI login prompt. To continue with system operations, enter the required password
information.
Software Licensing
New users should migrate to the Provisioning Entitlements method of licensing their system(s). Please contact an
Oracle representative for more information. Task descriptions for the legacy keyed method of licensing your system
remain in this section. The following guidelines apply to Oracle software licenses.
• Each license is bound to a specific Oracle Communications Session Border Controller by serial number.
• Oracle does not allow transferring a license from one Oracle Communications Session Border Controller to
another.
• Multiple licenses can be active on the same Oracle Communications Session Border Controller simultaneously.
• If a feature is covered by more than one license, the latest expiration date applies.
• You can activate and deactivate a license in real time.
• A license is fully extensible and upgradable.
• The system does not display the interface and configuration parameters for an unlicensed component.
Oracle software licenses are aggregate. When a new license is added to the original license set, the related capacity,
protocol, or interface becomes part of the functionality that you can configure and deploy.
When using the Provisioned Entitlements method, the only software component that requires a license is
Administration Security. This software component enables the use of Administration Security features; installation
and use of this feature set should be executed with care.
System Provisioning
The majority of the Oracle Communications Session Border Controller's capacities and features are self provisioned
at the ACLI. Initial system configuration consists of setting the system type and available features. These choices
determine the feature groups that are available for use and the maximum session capacities available for certain
features. The system provisions a set of default entitlements based on the software version, the hardware on which the
software runs, and the product type that you choose.
You may not enable features until the product type has been set. Use the setup product command to set the system
product type and use the setup entitlements command to enable features.
Controlled Features
Certain features are enabled only by entering a license key in the system > license configuration element, and not
through the setup entitlements command. Contact your sales representative for more information on purchasing
these features.
The following controlled features are available:
• Codecs including EVRC family and AMR family
• Lawful Intercept
• Admin Security
Note: Once the Admin Security feature is provisioned, it may not be removed from the system in the field;
your chassis must be returned to Oracle for replacement.
Note: Not all of the above controlled features are available on all platforms.
• After running setup product and setup entitlements, the system will be seeded with the existing licenses'
functionality.
• When the system is seeded with its previous 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 features, the show features command will still function to display the previously
installed keyed entitlements.
--------------------------------------------------------------
WARNING:
Alteration of product alone or in conjunction with entitlement
changes will not be complete until system reboot
Last Modified
--------------------------------------------------------------
1 : Product : Uninitialized
Product
1 - Session Border Controller
2 - Session Router - Session Stateful
3 - Session Router - Transaction Stateful
4 - Peering Session Border Controller
Enter choice : 1
Note: When configuring an HA pair, you must provision the same product type and features on each system.
Feature Provisioning
1. Type setup entitlements at the ACLI. Currently provisioned features are printed on the screen.
2. Type the number of the feature you wish to configure followed by pressing the <Enter> Key. Some features are
set as enabled/disabled (provisionable feature ), and some features are provisioned with a maximum capacity
value (provisionable capacity feature). The command will let you provision these values as appropriate.
3. Type enabled or disabled to set a provisionable feature , or type an integer value for a provisionable capacity
feature. 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 Communications Session Border Controller.
-----------------------------------------------------
Entitlements for Session Border Controller
Last Modified: 2014-06-01 18:57:55
-----------------------------------------------------
1 : Session Capacity : 32000
2 : Accounting : enabled
3 : IPv4 - IPv6 Interworking :
4 : IWF (SIP-H323) : enabled
5 : Load Balancing : enabled
6 : Policy Server : enabled
7 : Quality of Service : enabled
8 : Routing : enabled
9 : SIPREC Session Recording : enabled
10: Admin Security with ACP/NNC :
11: IMS-AKA Endpoints : 0
12: IPSec Trunking Sessions : 0
13: MSRP B2BUA Sessions : 0
14: SRTP Sessions : 0
Note: When configuring an HA pair, you must provision the same product type and features on each system.
ORACLE-2# display-running-cfg-version
Running configuration version is 5
2. Provision additional entitlements/licenses on system-1 with the setup entitlements command. This procedure is
explained in the Entitlements Configuration section, but DO NOT reboot the system at this point.
3. Save and activate the configuration on system-1.
ORACLE-1# save-config
checking configuration
Save-Config received, processing.
waiting for request to finish
Request to 'SAVE-CONFIG' has Finished,
Save complete
Currently active and saved configurations do not match!
To sync & activate, run 'activate-config' or 'reboot activate'.
ORACLE-1# activate-config
Activate-Config received, processing.
waiting for request to finish
Request to 'ACTIVATE-CONFIG' has Finished,
Activate Complete
4. Repeat steps 2 and 3 on system-2.
At the end of this step, identical licenses are installed, synchronized, and verified both system-1 and system-2.
5. Confirm once again that system-1 and system-2 are synchronized exactly as you did in step 1.
6. Reboot the standby system-2.
ORACLE-2# reboot
7. Wait for system-2 to startup and synchronize, then confirm that system-1 and system-2 are fully synchronized as
explained in step 1.
8. Trigger a switchover from system-1 so that the standby system transitions to active, and vice-versa.
ORACLE-1# notify berpd force
9. Wait while system-2 transitions to the active state, then confirm that system-1 and system-2 are fully synchronized
as explained in step 1.
10. Reboot the newly-standby system-1.
ORACLE-1# reboot
11. Wait for system-1 to complete rebooting, then confirm that system-1 and system-2 are fully synchronized as
explained in step 1.
At this point both systems should be healthy, synchronized, and contain identical license configurations.
12. If desired, trigger a switchover between the two systems in the HA node so the originally active system (system-1)
assumes the active role again.
This procedure uses the designations system-1 as the original active and system-2 as the original standby.
1. Confirm that system-1 and system-2 are healthy and synchronized. First check system health with the show
health command on both systems to confirm they are in identical states and healthy.
• Verify that both systems are in identical health with all processes synchronized with the show health
command.
Note: The following examples may not accurately portray your Oracle Communications product and
version combination.
ORACLE-1# show health
configurations. If the configurations are out of sync, use the save-config and activate-config commands to fix
this.
• Verify that the current configurations are in sync on both system-1 and system-2 with the display-current-cfg-
version command.
ORACLE-1# display-current-cfg-version
Current configuration version is 5
ORACLE-2# display-current-cfg-version
Current configuration version is 5
• Verify that the running configurations are in sync on both system-1 and system-2 with the display-running-
cfg-version command.
ORACLE-1# display-running-cfg-version
Running configuration version is 5
ORACLE-2# display-running-cfg-version
Running configuration version is 5
2. De-provision or change entitlements/licenses on system-1 with the setup entitlements command. This procedure
is explained in the Entitlements Configuration section, but DO NOT reboot the system at this point.
3. Save and activate the configuration on system-1.
ORACLE-1# save-config
checking configuration
Save-Config received, processing.
waiting for request to finish
Request to 'SAVE-CONFIG' has Finished,
Save complete
Currently active and saved configurations do not match!
To sync & activate, run 'activate-config' or 'reboot activate'.
ORACLE-1# activate-config
Activate-Config received, processing.
waiting for request to finish
Request to 'ACTIVATE-CONFIG' has Finished,
Activate Complete
4. Repeat steps 2 and 3 on system-2.
At the end of this step, identically changed licenses are installed, synchronized, and verified both system-1 and
system-2.
5. Confirm once again that system-1 and system-2 are synchronized exactly as you did in step 1.
6. Reboot the standby system-2.
ORACLE-2# reboot
7. Wait for system-2 to startup and synchronize, then confirm that system-1 and system-2 are fully synchronized as
explained in step 1.
8. Trigger a switchover from system-1 so that the standby system transitions to active, and vice-versa.
ORACLE-1# notify berpd force
9. Wait while system-2 transitions to the active state, then confirm that system-1 and system-2 are fully synchronized
as explained in step 1.
10. Reboot the newly-standby system-1.
ORACLE-1# reboot
11. Wait for system-1 to complete rebooting, then confirm that system-1 and system-2 are fully synchronized as
explained in step 1.
At this point both systems should be healthy, synchronized, and contain identical license configurations.
12. If desired, trigger a switchover between the two systems in the HA node so the originally active system (system-1)
assumes the active role again.
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.
4. Using the add command and the key generated by Oracle, add the license to your Oracle Communications
Session Border Controller.
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: High Availability
2: Accounting
3: SIP
4: H323
5: 250 sessions, ACP
6: QOS
ORACLE(license)#
6. To activate your license, type the activate-config command and press Enter. The Oracle Communications
Session Border Controller then enables any of the processes that support associated features.
ORACLE# activate-config
access-control realm-id
source-address
destination-address
application-protocol
transport-protocol
access
average-rate-limit
trust-level
invalid-signal-threshold
maximum-signal-threshold
untrusted-signal-threshold
deny-period
media-manager max-signaling-bandwidth
max-untrusted-signaling
min-untrusted-signaling
fragment-msg-bandwidth
tolerance-window
arp-msg-bandwidth
rtcp-rate-limit
media-profile average-rate-limit
realm-config average-rate-limit
access-control-trust-level
invalid-signal-threshold
maximum-signal-threshold
untrusted-signal-threshold
nat-trust-threshold
deny-period
static-flow average-rate-limit
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.
User authentication configuration also allows you to use local authentication, localizing security to the Oracle
Communications Session Border Controller 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 Communications
Session Border Controller and your RADIUS server(s). In these roles:
• The Oracle Communications Session Border Controller restricts access and requires authentication via the
RADIUS server; the Oracle Communications Session Border Controller 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 Communications Session Border
Controller 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 Communications Session Border Controller 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
Communications Session Border Controller 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 Communications Session Border Controller communicates
with one or more configured RADIUS servers that validates the user and specifies privileges. On the Oracle
Communications Session Border Controller, you configure:
• What type of authentication you want to use on the Oracle Communications Session Border Controller
• If you are using RADIUS authentication, you set the port from which you want the Oracle Communications
Session Border Controller to send messages
• If you are using RADIUS authentication, you also set the protocol type you want the Oracle Communications
Session Border Controller 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 Communications
Session Border Controller 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 Communications Session Border Controller will choose
servers to which it sends traffic in a round-robin strategy. For example, if you specify three servers are primary, the
Oracle Communications Session Border Controller 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 Communications Session Border Controller initiates
communication and proceeds with the authentication process. The authentication process between the Oracle
Communications Session Border Controller and the RADIUS server takes place uses one of three methods, all of
which are defined by RFCs:
Protocol RFC
PAP (Password Authentication B. Lloyd and W. Simpson, PPP Authentication Protocols, RFC 1334,
Protocol) October 1992
CHAP (Challenge Handshake B. Lloyd and W. Simpson, PPP Authentication Protocols, RFC 1334,
Authentication Protocol) October 1992
W. Simpson, PPP Challenge Handshake Authentication Protocol (CHAP),
RFC 1994, August 1996
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 Communications Session Border Controller.
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.
CHAP Handshake
When the authentication mode is CHAP, the user credentials sent to the RADIUS server include “username,” “CHAP-
Password,” 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 Communications Session Border
Controller is always 0), followed by the user password, and then the challenge (as specified in RFC 1994, section
4.1).
MS-CHAP-v2 Handshake
When the authentication method is MS-CHAP-v2, the user credentials sent to the RADIUS server in the Access-
Request 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 MS-
CHAP2-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 Communications
Session Border Controller 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.
• 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.
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 Communications Session Border Controller
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 Communications Session Border Controller
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 Communications Session
Border Controller marks is as dead.
8. retry-time—Set the amount of time (in seconds) that you want theOracle Communications Session Border
Controller to wait before retrying for authentication from this RADIUS server. The default value is 5. The valid
range is:
• Minimum—5
• Maximum—10
9. dead-time—Set the amount of time in seconds before the Oracle Communications Session Border Controller
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 Communications Session Border Controller 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 Communications Session Border
Controller 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 Communications Session
Border Controller 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
Communications Session Border Controller 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.
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-grant-
tacacs-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 Communications Session Border Controller 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.
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)
system's media interfaces. This feature implements TACACS+ authorization (user permissions management on a
command basis), authentication (user management), and accounting on management interfaces.
TACACS+ Authentication
The Oracle Communications Session Border Controller uses TACACS+ authentication services solely for the
authentication of user accounts. Administrative users must be authenticated locally by the Oracle Communications
Session Border Controller.
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.
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.
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 Communications Session Border Controller 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
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 Communications Session Border Controller 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.
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
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 Scenarios
Each of the supported user authentication scenarios is described in terms of packet flow in the following sections.
ASCII Authentication
The Oracle Communications Session Border Controller 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 Communications Session Border Controller 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 Communications Session Border Controllerresponds with an 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 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 Communications Session Border Controller 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 |
+-----------------+
• 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.
PAP Authentication
The Oracle Communications Session Border Controller 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 |
+-----------------------------------+
CHAP Authentication
The Oracle Communications Session Border Controller 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 |
TACACS+ Authorization
The Oracle Communications Session Border Controller 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 Communications Session Border Controller 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 Communications Session Border Controller 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.
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 Communications Session Border Controller 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:
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.
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 Communications Session Border Controller 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 |
+-----------------------------------+
• 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.
• The user field contains the login name of an admin user.
• The port field contains the name of the Oracle Communications Session Border Controller 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.
Authorization Fail
The Oracle Communications Session Border Controller 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 |
+-----------------------------------+
• 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.
TACACS+ Accounting
The Oracle Communications Session Border Controller 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.
3. For each ACLI command executed by an admin user, the Oracle Communications Session Border Controller
sends an accounting REQUEST WATCHDOG packet requesting accounting of the ACLI command. As the Oracle
Communications Session Border Controller 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 Communications Session Border
Controller sends an accounting REQUEST STOP packet.
7. The daemon responds with an accounting REPLY packet, indicating that accounting has stopped.
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 Communications Session Border
Controller, 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 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 Communications Session Border Controller 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
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.
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.
Accounting Scenario
The Oracle Communications Session Border Controller 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 |
+-----------------------------------+
• 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 Communications Session Border Controller 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 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 Communications Session Border Controller 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 |
TACACS+ Configuration
Configuration of TACACS+ consists of the following steps.
1. Enable TACACS+ client services
2. Specify one or more TACACS+ servers (daemons)
7. management-strategy — Configure this parameter to identify the selection algorithm used to choose among
multiple available TACACS+ daemons. Retain the default value of hunt when only a single daemon is available.
• hunt (default) — for the first transaction the Security Gateway selects the initially configured TACACS+
daemon. When 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.
• roundrobin — for the first transaction the Security Gateway selects the initially configured TACACS+
daemon. After completing the first transaction, it selects each daemon in order of configuration — in theory,
evenly distributing AAA transactions to each daemon over time.
8. Type done to save your configuration.
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 Counter32
apSecurityTacacsPlusSuccess Authentications Counter32
apSecurityTacacsPlusFailureAuthentications Counter32
apSecurityTacacsPlusSuccess Authorizations Counter32
apSecurityTacacsPlusFailureAuthorizations Counter32
}
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
TACACS+ Logging
All messages between the Oracle Communications Session Border Controller and the TACACS+ daemon are logged
in a cleartext format, allowing an admin user to view all data exchange, except for password information.
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 Communications Session Border Controller will create it upon boot if it does not exist.
System Identification
Global system identification is used primarily by the Oracle Communications Session Border Controller to identify
itself to other systems and for general identification purposes.
Connection Timeouts
It is important to set administrative session timeouts on the Oracle Communications Session Border Controller 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 Communications Session Border Controller access.
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 Communications Session
Border Controller. 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 Communications Session Border Controller 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 Communications Session Border Controller.
System Identification
You must specify identification parameters for this Oracle Communications Session Border Controller.
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 Communications
Session Border Controller system chassis is located.
4. default-gateway—Set the default gateway for this Oracle Communications Session Border Controller. This
is the egress gateway for traffic without an explicit destination. The application of your Oracle Communications
Session Border Controller determines the configuration of this parameter.
• Fan Pod
• System Air Filter
• SFP Module (1 GbE)
• SFP+ Module (10GbE)
The Acme Packet 4600 NIU contains the following ports (from left to right).
• Console—Provides serial access for administrative and maintenance purposes.
• Alarm—Dry contact alarm port.
• USB—The USB port is reserved for use by Oracle support employees, only.
• Mgmt 0–Mgmt 2—These 10/100/1000 Base-T Ethernet ports are used for EMS control, RADIUS accounting, CLI
management, SNMP queries and traps, and other management functions.
• P4–P5—2 x 10GbE ports for signaling and media traffic.
• P0–P3—4 x GbE ports for signaling and media traffic.
The OID in ap-products.mib for the Acme Packet 4600 is 1.3.6.1.4.1.9148.1.1.3.
1. Console port
2. Alarm port
3. wancom0
4. wancom1
5. wancom2
6. USB Port (for Acme Packet personnel access only)
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. Slot 0, Port 0
2. Slot 0, Port 1
3. Slot 1, Port 0
4. Slot 1, Port 1
• 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).
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
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 Communications Session Border
Controller 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 Communications Session Border Controller begins to negotiate the link
to the connected device at the duplex mode you configure. If auto-negotiation is disabled, then the Oracle
Communications Session Border Controller 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:
• 10 | 100 | 1000
10. virtual-mac—Refer to Oracle Communications Session Border Controller High Availability (HA) documentation
to learn how to set this parameter on an HA interface.
11. Type done to save your configuration.
HA Configuration
Refer to this guide’s HA Nodes documentation for more information about when and how to configure virtual-
mac and wancom-health-score parameters. If you are not using HA, you can leave these parameters set to their
defaults.
Calculation Overview
When enabled to do so, the Oracle Communications Session Border Controller 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 Communications
Session Border Controller 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:
• Minor, set to 50%
• Major, set to 70%
• Critical, Set to 90%
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.
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 Communications Session Border Controller network interface has standard parameters common to nearly all
IP network interfaces. There are a few fields that are unique to the Oracle Communications Session Border
Controller.
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 Communications Session Border Controller are VPNs and peering.
Several peering partners may terminate their connections to a Oracle Communications Session Border Controller on a
single physical interface. VLAN tags are used to segregate and correctly route the terminated traffic. The Oracle
Communications Session Border Controller 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 Communications Session Border Controller 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 Communications Session Border
Controller 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 Communications Session Border Controller network interface will obviously not
work. The Oracle Communications Session Border Controller includes the IP Address, Subnet Mask, and 802.1q
VLAN tag in its Network Interface determination. This allows Oracle Communications Session Border Controller to
directly interface to multiple VPNs with overlapping address space.
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.
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.
Link Redundancy
Link redundancy enables the Oracle Communications Session Border Controller to run a pair of media interfaces
redundantly so that in the event of a network or link failure, the Oracle Communications Session Border Controller
automatically fails over to the redundant physical link. The Oracle Communications Session Border Controller polls
link state on a one-second basis, so the maximum outage time is one second. And if gateway heartbeats are enabled,
then gateway timeout alarms will also cause failovers.
This feature is only supported on the Acme Packet 3820 and 4500 on the following NIUs:
• 4-port 10/100/1000 copper
• 4-port 1Gig SFP
• 4-port 1Gig SFP phy card with QoS
The link redundancy feature enables each slot pair (SxP1 and SxP2) on an NIU to behave as only a single port with
one port as an active port and the other port as the hot standby simultaneously. Port 0 on Slots 0 and 1 is the master
port, and the two Port 1s are the backup ports. The NIU receives and sends all traffic on one port, while the other acts
as a standby in the event of failure. When enabled, this feature takes effect system-wide.
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.
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 Communications Session Border Controller service, but
they are necessary to use network management systems to manage the Oracle Communications Session Border
Controller. 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 Communications Session Border Controller. These
settings are system-wide configurations including MIB contact information, SNMP community settings, and trap
receivers.
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 Communications Session Border Controller lets you define two types of
access levels: read-only and read-write. You can define multiple SNMP communities on a Oracle Communications
Session Border Controller to segregate access modes per community and NMS host.
Configuring SNMP
This section describes how to configure your Oracle Communications Session Border Controller to work with
external SNMP systems. Sample configurations are also provided.
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 John Doe
mib-system-name Test System
mib-system-location Upstairs
snmp-enabled enabled
enable-snmp-auth-traps disabled
enable-snmp-syslog-notify disabled
enable-snmp-monitor-traps disabled
enable-env-monitor-traps disabled
snmp-syslog-his-table-length 1
snmp-syslog-level WARNING
• 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 Communications Session Border
Controller generates traps with unique trap-IDs 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:
• Minimum—1
• 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
ORACLE(trap-receiver)#
3. ip-address — Set the IPv4 or IPv6 address of an authorized NMS. This parameter is the IPv4 or IPv6 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.
4. filter-level — Set the filter level threshold that indicates the severity level at which a trap is to be sent to this
particular trap receiver. The default for this parameter is critical.
Example: When a trap with a severity level of critical is generated, the SNMP agent will send this trap only to
NMSs that are configured in a trap-receiver element and have a filter-level value of critical.
The following table maps Syslog and SNMP alarms to trap receiver filter levels.
When configuring the trap-receiver element for use with Oracle Communications Session Element Manager
systems, Oracle recommends that the value of filter-level be set to All for that configuration element that includes
those servers.
5. community-name — Set the community name to which this trap receiver belongs. This community must be
defined in the SNMP community element.
6. Type done to save your configuration.
Overview
The Oracle Communications Session Border Controller 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.
Syslog Configuration
The Oracle Communications Session Border Controller supports multiple syslog servers. As the number of active
syslog increases, the performance level of the Oracle Communications Session Border Controller 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
Communications Session Border Controller to the syslog server. This parameter is used only for identifying the
source of this syslog message as coming from the Oracle Communications Session Border Controller. 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 Communications Session Border Controller 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
Host Routes
Host routes let you insert entries into the Oracle Communications Session Border Controller's routing table. These
routes affect traffic that originates at the Oracle Communications Session Border Controller’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 Communications Session Border
Controller, 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.
Note: Do not configure a host-route > gateway with an address already used for any existing network-
interface > gateway.
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.
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.
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 Communications Session Border Controller should retransmit 3 times before timing
out to give the server a chance to respond.
• 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
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.
Process Logs
Events are logged to a process log flow from tasks and are specific to a single process running on the Oracle
Communications Session Border Controller. 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 process-
log-level parameter is set to, but the results are stored on the Oracle Communications Session Border Controller’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.
• 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. This option is set via the h323-stack
configuration element. 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
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:
• 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
• 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.
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.
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
SNMP Traps
When a configured alarm threshold is reached, the Oracle Communications Session Border Controller 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 Communications Session Border
Controller sends an apSysMgmtGroupClearTrap.
apSysMgmtGroupClearTrap NOTIFICATION-TYPE
OBJECTS { apSysMgmtTrapType }
STATUS current
Alarm Synchronization
Two trap tables in the ap-smgmt.mib record trap information for any condition on the Oracle Communications
Session Border Controller 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
Communications Session Border Controller 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 Communications Session Border Controller . These tables are:
• apSysMgmtTrapTable—You can poll this table to obtain a summary of the Oracle Communications Session
Border Controller ’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 Communications Session Border Controller purges the
tables.
Caveats
Note that the Oracle Communications Session Border Controller does not replicate alarm synchronization table data
across HA nodes. That is, each Oracle Communications Session Border Controller in an HA node maintains its own
tables.
Accounting Configuration
The Oracle Communications Session Border Controller 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 Communications Session Border Controller 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.
This guide contains all RADIUS information, as well as information about:
• Accounting for SIP and H.323
• Local CDR storage on the Oracle Communications Session Border Controller , 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
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
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.
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.
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.
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.
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 Communications Session Border Controller
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.
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-
sack-timeout 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.
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.
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)#
Access Control
These are the IPv6-enabled parameters in the access-control configuration.
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.
Local Policy
These are the IPv6-enabled parameters in the local-policy configuration.
Network Interface
These are the IPv6-enabled parameters in the network-interface configuration.
ENUM Server
These are the IPv6-enabled parameters in the enum-config.
Realm Configuration
These are the IPv6-enabled parameters in the realm-config.
Session Agent
These are the IPv6-enabled parameters in the session-agent configuration.
SIP Configuration
These are the IPv6-enabled parameters in the session-config.
Steering Pool
These are the IPv6-enabled parameters in the steering-pool configuration.
System Configuration
These are the IPv6-enabled parameters in the system-config.
default-v6-gateway <ipv6>
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.
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
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 Communications Session Border Controller, there is no configuration for
IPv6 reassembly and fragmentation support. It is enabled automatically.
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>[/<port-
bits>]]. 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 net7777
description
source-address 7777::11/64:5060/8
destination-address 8888::11:5060/8
application-protocol SIP
transport-protocol ALL
access deny
average-rate-limit 0
trust-level none
minimum-reserved-bandwidth 0
invalid-signal-threshold 10
maximum-signal-threshold 0
untrusted-signal-threshold 0
deny-period 30
DNS Support
The Oracle Communications Session Border Controller 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
Communications Session Border Controller 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 Communications Session Border Controller follows these rules:
• If the realm associated with the name resolution is an IPv6 realm, the Oracle Communications Session Border
Controller will send the query out using the AAAA record type.
• If the realm associated with the name resolution is an IPv4 realm, the Oracle Communications Session Border
Controller 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 dns-ip-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.
Overview
Realms are a logical distinction representing routes (or groups of routes) reachable by the Oracle Communications
Session Border Controller 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 and H.323 stack configurations
• Third-party routing/redirect (i.e., SIP redirect or H.323 LCF)
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 Communications Session Border Controller.
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.
Remember that you will also use this realm in other configurations to accomplish the following:
• Set a signaling port or ports at which the Oracle Communications Session Border Controller listens for signaling
messages.
• 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.
Realm Interfaces
The realm points to one network interface on the Oracle Communications Session Border Controller.
Note: Only one network-interface can be assigned to a single realm-config object, except for Local multi-
homing 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(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 Communications Session
Border Controller assumes an IPv4 interface. Dual stack interface configurations fail if this IP version family
suffix is not specified.
• 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 Communications Session Border Controller, then you can leave this parameter set to
disabled (default).
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 and/or H.323
• One or more video types for SIP and/or H.323
• Both audio and video media types for SIP and/or H.323
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 Communications Session Border Controller first sets up a SIP or H.323 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.
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 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.
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 Communications Session Border Controller 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 Communications Session Border Controller 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.
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.
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, SIP port or H.323 stack. 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
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.
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-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.
Given the realm constraints outlined above, consider these examples of how global session constraints for realms. For
example, a call enters the Oracle Communications Session Border Controller on Child Realm 2B, which has an unmet
90-session constraint set. Therefore, the Oracle Communications Session Border Controller 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 Communications Session Border
Controller rejects the call.
ToS Byte
The TOS byte format is as follows:
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.
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.
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
sub-types 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.
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
profile-name parameter of the class-policy configuration.
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
sub-types 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.
Each realm on the Oracle Communications Session Border Controller 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 Communications Session Border Controller 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-realm-family 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 Communications Session Border Controller. After the Oracle Communications Session
Border Controller 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 name:realm-out-6 ip-address: 2001:4860:4860::8889
sub-port-id:100 network-interfaces:M00:100.6 network-interface:M00:100.6
ip-address:2001:4860:4860::8888 alt-family-realm: realm-out-4 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.
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 Communications Session
Border Controller. 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 Communications Session Border Controller 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 Communications Session Border Controller 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
Communications Session Border Controller. For example, if your Oracle Communications Session Border Controller
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 Communications Session Border Controller will never use.
The following table lists the steering pool parameters you need to configure:
Parameter Description
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.
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.
Communications Session Border Controller 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 Communications Session Border Controller to
create a standard one-realm to one-network interface configuration.
Without using multiple interface realms, the basic hierarchical configuration of the Oracle Communications Session
Border Controller 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 Communications Session Border
Controller’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:
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 ports for a given realm are assigned to media flows sequentially. When the first call enters the Oracle
Communications Session Border Controller 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 Communications Session Border Controller 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 Communications Session Border Controller, 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 Communications
Session Border Controller 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.
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:
• 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 Communications Session Border Controller 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.
4. After the Oracle Communications Session Border Controllerreceives 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:
• The TCP initial guard timer, TCP subsequent guard timer, or the TCP flow time limit timer expire for that
flow.
• The whole SIP session is torn down.
The endpoint responds back to the client port on the egress interface. This message traverses the Oracle
Communications Session Border Controller 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 Communications Session Border Controller:
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 Communications Session Border Controller:
The response takes the same path back to the caller. The remainder of the second TCP connection uses this
established path:
When the callee initiates a TCP connection, it must send its initial traffic to the server port on its Oracle
Communications Session Border Controller 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.
The Oracle Communications Session Border Controller 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.
All interfaces involved with the end-to-end TCP flow have now established their listening IP address and port pairs.
Timers
The Oracle Communications Session Border Controller 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.
• Minimum—2
• 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
About Latching
Latching is when the Oracle Communications Session Border Controller listens for the first RTP packet from any
source address/port for the destination address/port of the Oracle Communications Session Border Controller. 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 Communications Session Border Controller only allows subsequent RTP packets
from that same source address/port for that particular Oracle Communications Session Border Controller 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 Communications Session Border Controller will perform
symmetric RTP).
Restricted Latching
The Oracle Communications Session Border Controller 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
Communications Session Border Controller as the public SIP contact address, that information could be used
instead of waiting for a response. The Oracle Communications Session Border Controller 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 Communications Session
Border Controller (SBC) that are latched, are then used for the destination of RTP/RTCP sent to the device.
After allocating the media session in SIP, the SBC 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 SBC sets the source 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 SBC sets the source address in the flow going from the called side to the
calling side.
The SBC uses either the address provided in the SDP or the layer 3 signaling address for latching. You also configure
the SBC 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 SBC sends information for both
flows to the MBCD so that the correct NAT entries are installed.
Enabling restricted latching may make the SBC wait for a SIP/SDP response before latching, if the answerer is in a
restricted latching realm. This is necessary because the SBC 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.
Example 1
A typical example is when the Oracle Communications Session Border Controller 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 Communications Session Border Controller 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 Communications Session Border Controller, and calls do not appear to be behind NATs
from the Oracle Communications Session Border Controller’s perspective. The Oracle Communications Session
Border Controller’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 Communications Session Border Controller’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 Communications Session Border Controller 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).
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> 0.0.0.0
2: H323REALM <none> 0.0.0.0
selection:1
ORACLE(realm-config)#
5. mm-in-system—Set this parameter to enabled to manage/latch/steer media in the Oracle Communications
Session Border Controller. Set this parameter to disabled to release media in the Oracle Communications
Session Border Controller.
Note: Setting this parameter to disabled will cause the Oracle Communications Session Border Controller
to NOT steer media through the system (no media flowing through this Oracle Communications Session
Border Controller).
The default is enabled. The valid values are:
• enabled | disabled
• enabled | disabled
6. 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 Communications Session Border Controller 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 Communications Session Border Controller resolves this issue by offering its codec reordering feature.
Enabled for realms and session agents, this feature gives the Oracle Communications Session Border Controller 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 Communications Session
Border Controller receives SDP offers (in requests or responses), and for which the media format list needs to be
reordered by the Oracle Communications Session Border Controller 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 Communications Session Border Controller 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 Communications Session Border Controller determines preferred codecs in the following ways:
• If the response or request with an SDP offer is from a session agent, the Oracle Communications Session Border
Controller 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 Communications Session Border Controller determines
the preferred codec by referring to the preferred-codec=X option in the realm.
• If the Oracle Communications Session Border Controller cannot determine a preferred codec, it does not perform
codec reordering.
The way that the Oracle Communications Session Border Controller 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 Communications Session Border
Controller does not perform any operation on the remaining codecs in the media format list.
Note: that the Oracle Communications Session Border Controller performs codec reordering on the media
format list only. If the rtpmap attribute of the preferred codec is present, the Oracle Communications Session
Border Controller does not reorder it.
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 0.0.0.0
2: private media1:0 0.0.0.0
selection:1
ORACLE(realm-config)#
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.
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
Communications Session Border Controller uses to find matching media profiles.
• When you wildcard the subname portion of the value, you can provide a specific name that the Oracle
Communications Session Border Controller 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:
<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 Communications Session Border Controller performs matching for wildcarded match-media-
profiles values last. Specific entries are applies first and take precedence. When the Oracle Communications
Session Border Controller 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)#
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.
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 Communications Session Border Controller call admission control (CAC) and bandwidth policing.
Service Provider 1 uses the Oracle Communications Session Border Controller’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 Communications Session Border Controller 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 Communications Session Border Controllercan 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.
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.
• Establish incoming TCP connections with each endpoint participating in the MSRP session using a 3-way
handshake. The Oracle Communications Session Border Controller 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
Communications Session Border Controller; the stitching makes both clients think they are talking to a server. To
achieve this end, the Oracle Communications Session Border Controller 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.
• peering
• hosted IP services
About B2BUA
A B2BUA is a logical entity that receives a request and processes it as a user agent server (UAS). In order to
determine how the request should be answered, it acts as a user agent client (UAC) and generates requests. It
maintains dialog state and must participate in all requests sent on the dialogs it has established.
Example
The following example shows a SIP INVITE message from a softswitch to a Oracle Communications Session Border
Controller.
INVITE sip:05030205555@ss-side-ext-address;gateway=encoded-gw-address
From: "Anonymous"<sip:anonymous@anonymous.invalid>;tag=xxxx
To: <sip:05030205555@ss-side-ext-address;user=phone>
The following example shows a SIP INVITE message from a Oracle Communications Session Border Controller to a
gateway.
INVITE sip:05030205555@gw-ip-address SIP/2.0
From: "Anonymous"<sip:anonymous@anonymous.invalid>;tag=SDxxxx-xxxx
To: <sip:05030205555@ hostpart;user=phone>
The Oracle Communications Session Border Controller converts the hostpart in the To header except in the following
scenarios:
• when the original hostpart value received is an Fully Qualified Domain Name (FQDN)
• when the Oracle Communications Session Border Controller is configured not to NAT the To headers.
Acme Packet recommends configuring the Oracle Communications Session Border Controller to NAT the To headers
to ensure the security of protected addresses. Otherwise, the outgoing hostpart is set to the SIP NAT’s external proxy
address for the SIP NAT’s external realm.
Home Realm
This section explains how to configure a home realm. The home realm applies only to a SIP configuration. It
represents the internal default realm or network for the Oracle Communications Session Border Controller and is
where the Oracle Communications Session Border Controller’s SIP proxy is located.
Overview
You primarily use a home realm when using the SIP NAT function to connect multiple realms/networks to the Oracle
Communications Session Border Controller. You define the home realm defined as either public or private for the
purposes of using the SIP NAT function. If the home realm is public, all external realms are considered private. If the
home realm is private, all external networks are considered public. Usually the home realm is public.
Messages are encoded (for example, the topology is hidden) when they pass from a private to a public realm.
Messages are decoded when the pass from a public realm to a private realm.
These external realms/networks might have overlapping address spaces. Because SIP messages contain IP addresses,
but no layer 2 identification (such as a VLAN tag), the SIP proxy must use a single global address space to prevent
confusing duplicate IP addresses in SIP URIs from different realms.
Note: You should leave this parameter blank for access/backbone applications. When left blank, the realm
specified in the home-realm-id parameter is used by default.
6. nat-mode—Indicate the SIP NAT mode. The default is none. The valid values are:
• public—Indicates the subnet defined in the addr-prefix-id field of the home realm is public and the subnet
defined in the addr-prefix-id field of all external realms identified in the SIP NAT are private networks. IPv4
addresses are encoded in SIP messages received from the external realm defined by the SIP NAT. The IPv4
addresses are decoded in messages that are sent to the realm.
• private—Indicates the subnet defined in the addr-prefix-id field of the home realm is private and the subnet
defined in the addr-prefix-id field of all external realms identified in the SIP NAT are public networks. IPv4
addresses are encoded in SIP messages sent to the external realm defined by the SIP NAT and decoded in
messages received from the realm.
• none—No SIP NAT function is necessary.
The following example shows the SIP home realm configured for a peering network.
sip-config
state enabled
operation-mode dialog
dialog-transparency disabled
home-realm-id acme
egress-realm-id
nat-mode Public
registrar-domain
registrar-host
registrar-port 0
init-timer 500
max-timer 4000
trans-expire 32
invite-expire 180
inactive-dynamic-conn 32
red-sip-port 1988
red-max-trans 10000
red-sync-start-time 5000
red-sync-comp-time 1000
last-modified-date 2005-03-19 12:41:28
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 Communications Session Border Controller 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 Communications Session Border Controller 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
Proxy Mode
The Oracle Communications Session Border Controller’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 Communications Session Border Controller’s
addresses added. As a result, all subsequent requests are routed through the Oracle Communications Session Border
Controller.
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 Communications Session Border Controllerto perform a global redirect action in response to
Redirect messages. Or you can retain the default behavior where the Oracle Communications Session Border
Controller 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 Communications Session Border Controller is to recurse on SIP Redirect
responses received from the user agent server (UAS) and send a new request to the Contact headers contained in the
SIP Redirect response.
Instead of this default behavior, the Oracle Communications Session Border Controller 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.
session-group
group-name test.acmepacket.com
description
state enabled
app-protocol SIP
strategy Hunt
dest
192.168.200.222
192.168.200.223
...
...
In this case, when the Oracle Communications Session Border Controller 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
Communications Session Border Controller will look for a SAG matching the hostname.
2. When the Contact URI has an maddr parameter that contains an IP address, the Oracle Communications Session
Border Controller 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 Communications
Session Border Controller 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.
Trust Mode
The Oracle Communications Session Border Controller 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 Communications Session Border
Controller can understand and support the privacy headers and provide the capability for anonymous packets
The Oracle Communications Session Border Controller, 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 Communications Session Border
Controller is being operated (B2BUA or the proxy), the appropriate actions are performed.
strips the Proxy-Require header if it is set to privacy. The Oracle Communications Session Border Controller 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 Communications Session Border Controller 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.
the realm-config value so, therefore, the value “Unlimited” is used for the ingress side. On the egress side the value
of session-max-life-limit in realm-config is set to 43200 and the value of session-max-life-limit in session-agent is
set to 0 (no timer), so the value of session-max-life-limit in realm-config is used. When compared against the ingress
side the value 43200 is less than “Unlimited”; therefore, the value set for the timer is 43200.
selection: 1
ORACLE(realm-config)#
3. session-max-life-limit — Enter the maximum interval in seconds before the SBC must terminate long duration
calls. The value supercedes the value of session-max-life-limit in the sip-interface and sip-config configuration
elements and is itself superceded by the value of session-max-life-limit in the session-agent configuration
element. The default value is 0 (off/ignored).
4. Type done to save your configuration.
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
Communications Session Border Controller’s address. For stateless and transaction mode only.
9. redirect-action—Enter the value for the redirect action. Valid values are:
• 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 Communications Session Border Controller’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 Communications Session
Border Controller’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 Communications Session Border
Controller’s cached registration entry for an HNT endpoint. The default is 30. The valid range is:
• 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 Communications Session Border Controller 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 Communications Session Border Controller 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 Communications Session Border
Controller. By adding a separate configuration for the TCP NAT interval, the load is reduced.
For upgrade and backward compatibility with Oracle Communications Session Border Controller 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 Communications Session Border Controller caches the Contact header in the UA’s
REGISTER request when it is addressed to one of the following:
• Oracle Communications Session Border Controller
• registrar domain value
• registrar host value
The Oracle Communications Session Border Controller then generates a Contact header with the Oracle
Communications Session Border Controller’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 Communications Session Border Controller 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 client-server 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 Communications Session Border Controller.
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 Communications Session Border Controller, which is the
Contact address. Then, the Oracle Communications Session Border Controller 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 Communications Session Border Controller
places in each REGISTER message it sends to the real registrar. In HNT, the Oracle Communications Session
Border Controller caches the registration after receiving a response from the real registrar and sets the
expiration time to the NAT interval value.
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 Communications Session Border Controller to send
frequent registrations on to the real registrar.
16. registration-interval—Set the Oracle Communications Session Border Controller’s cached registration
entry interval for a non-HNT endpoint. Enter the expiration time in seconds that you want the Oracle
Communications Session Border Controller 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 Communications Session Border Controller 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 Communications Session Border Controller 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 Communications
Session Border Controller. 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 Communications Session Border Controller’s address. Because the registrar
host is the real registrar, it should send the requests back to the Oracle Communications Session Border Controller
with the Oracle Communications Session Border Controller’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 Communications
Session Border Controller 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 Communications Session Border Controller
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 Communications Session Border Controller 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 Communications
Session Border Controller 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 Communications Session Border Controller’s registration cache.
• none—Trust nothing.
Session agents must have one or more of the following:
• global realm
• same realm as the SIP interface
• 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
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
Communications Session Border Controller:
• 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.
Diversion header for each History-Info header, initialized with the value of the History-Info header, when the SBC
receives a SIP INVITE which does not contain a to-tag in the To header.
selection: 1
ORACLE(sip-interface)#
3. diversion-info-mapping-mode— Configure this parameter to specify how the Diversion and History-Info
headers map to and work with each other on the interface. The default value is none.
• div2hist — any Diversion headers in the initial INVITEs going out of this sip-interface will be converted to
History-Info headers before sending
• force — behavior is the same as div2hist when a Diversion header is present in the incoming INVITE. If
there are no Diversion headers, a History-Info header for the current URI is added in the outgoing INVITE.
• hist2div — any History-Info headers in the initial INVITEs going out of this sip-interface will be converted to
Diversion headers before sending
• none — no conversion applied (default)
4. Type done to save your 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 Communications Session Border Controller 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 Communications Session Border Controller 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.
Note: If there are multiple challenges in the request, and if the Oracle Communications Session Border
Controller has only some of the cached credentials configured, the Oracle Communications Session
Border Controller adds challenge-responses for the requests it can handle, and does not pass the challenge
back to the IP-PBX.
Additional Notes
The following are additional notes that describe the digest authentication process:
• The Oracle Communications Session Border Controller 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 Communications Session Border Controller does not receive any communication from the client
within the expiration period, the Oracle Communications Session Border Controller logs the client out and tears
down the transport connection. Faced with interface loss, the Oracle Communications Session Border Controller
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 Communications Session Border Controller, and then repopulate the
empty database using a series of ADD requests. This behavior ensures that client and Oracle Communications
Session Border Controller target databases are synchronized.
Alternatively, when faced with interface loss, the Oracle Communications Session Border Controller can retain all
warrant information within the target database. This response necessitates only that the client first login/re-register
with the Oracle Communications Session Border Controller. 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 Communications
Session Border Controller and client target databases are synchronized.
• The Oracle Communications Session Border Controller ignores the Authentication-Info header that comes in the
200OK response after digest authentication is complete. The Oracle Communications Session Border Controller
receives a 401/407 response from the client. However, some surrogate-agents may process the Authentication-Info
header in a single challenge.
You need to configure PRACK interworking for a SIP interface associated with the endpoints that need RFC 3262
support. To enabled the feature, you set the 100rel-interworking option. The Oracle Communications Session
Border Controller applies PRACK interworking for either the UAC or the UAS. TheOracle Communications Session
Border Controller checks to see whether or not it needs to apply PRACK interworking when an INVITE arrives at the
ingress or egress SIP interface with the option enabled. First, it checks the Require header for the 100rel tag; if not
found there, it checks the Supported header.
Since there is a slight difference in the application of this feature between the UAC and UAS, this section explains
both.
Note: If SDP is included in a PRACK request sent to a SIP interface where PRACK interworking is enabled,
it will not be responded to, nor will any SDP be included in the locally-generated 200 OK to that PRACK.
Overview
SIP timers define the transaction expiration timers, retransmission intervals when UDP is used as a transport, and the
lifetime of dynamic TCP connections. The retransmission and expiration timers correspond to the timers defined in
RFC 3261.
• init timer: is the initial request retransmission interval. It corresponds to Timer T1 in RFC 3261.
This timer is used when sending requests over UDP. If the response is not received within this interval, the request
is retransmitted. The retransmission interval is doubled after each retransmission.
• max timer: is the maximum retransmission interval for non-INVITE requests. It corresponds to Timer T2 in RFC
3261.
The retransmission interval is doubled after each retransmission. If the resulting retransmission interval exceeds
the max timer, it is set to the max timer value.
• trans expire: is the transaction expiration timer. This value is used for timers B, D, F, H and J as defined in RFC
3261.
• invite expire: defines the transaction expiration time for an INVITE transaction after a provisional response has
been received. This corresponds to timer C in RFC 3261.
If a final response is not received within this time, the INVITE is cancelled. In accordance with RFC 3261, the
timer is reset to the invite expire value when any additional provisional responses are received.
• Inactive dynamic conn timer defines the idle time of a dynamic TCP connection before the connection is torn
down. Idle is defined as not transporting any traffic. There is no timer in RFC 3261 corresponding to this function.
Timers Configuration
To configure timers:
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 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)#
4. init-timer—Enter the initial timeout value in milliseconds for a response to an INVITE request, and it applies
to any SIP request in UDP. In RFC 3261, this value is also referred to as TIMER_T1. The default is 500. The
valid range is:
• Minimum—0
• Maximum—999999999
5. max-timer—Enter the maximum transmission timeout (T2) for SIP in milliseconds.
When sending SIP over UDP, a re-transmission timer is used. If the timer expires and the message is re-
transmitted, the re-transmission timer is then set to twice the previous value (but will not exceed the maximum
timer value). Using the default values of 500 milliseconds and 4000 milliseconds, the re-transmission timer is 0.5,
then 1, 2, and finally 4. The incrementing continues until the transmission expire timer activates. The default is
4000. The valid range is:
• Minimum—0
• Maximum—999999999
6. trans-expire—Enter the transaction expire timeout value (Timer B) in seconds to set the time for SIP
transactions to live. The same value is used for Timers D, F, H and J. The default is 32. The valid range is:
• Minimum—0
• Maximum—999999999
7. invite-expire—Enter the invite expire timeout value (Timer C) in seconds to indicate the time for SIP client
transaction will live after receiving a provisional response. The default is 180. The valid range is:
• Minimum—0
• Maximum—999999999
8. inactive-dynamic-conn—Enter the inactive dynamic connection value in seconds to set the time limit for
inactive dynamic connections.
If the connection between the SIP proxy and a session agent is dynamic (for example, through dTCP), and the
connection has been idle for the amount of time specified here, the SIP proxy breaks the connection. Idle is
defined as not transporting any traffic. The default value is 32. The valid range is:
• Minimum—0
• Maximum—999999999
Note: Setting this parameter to 0 disables this parameter.
The following example shows SIP config timer values for a peering network. Some parameters are omitted for
brevity.
sip-config
state enabled
operation-mode dialog
dialog-transparency disabled
home-realm-id acme
egress-realm-id
nat-mode Public
registrar-domain
registrar-host
registrar-port 0
init-timer 500
max-timer 4000
trans-expire 32
invite-expire 180
inactive-dynamic-conn 32
Timer D, the Wait-Time for response retransmitals timer, defined in Section 17.1.1.2 and Appendix A of RFC 3261,
SIP: Session Initiation Protocol.
Timer F, the non-INVITE transaction timeout timer, defined in Section 17.1.2.2 and Appendix A of RFC 3261, SIP:
Session Initiation Protocol.
Timer H, the Wait-Time for ACK receipt timer, defined in Section 17.2.1 and Appendix A of RFC 3261, SIP: Session
Initiation Protocol.
Timer J, the Wait-Time for non-INVITE requests timer, defined in Section 17.2.2 and Appendix A of RFC 3261, SIP:
Session Initiation Protocol.
A new ACLI command (initial-inv-trans-expire) that enables user control over SIP Timer B for initial
INVITE transactions. Other timers, namely B for non-initial INVITEs, D, F, H, and J remain under the control of
trans-expire.
Use initial-inv-trans-expire in the sip-config configuration mode, to establish a global, default
transaction timeout value (expressed in seconds) used exclusively for initial INVITE transactions.
ORACLE(sip-config)# initial-inv-trans-expire 4
ORACLE(sip-config)#
Allowable values are integers within the range 0 (the default) through 999999999. The default value, 0, indicates that
a dedicated INVITE Timer B is not enabled. Non-default integer values enable a dedicated Timer B and set the timer
value.
The default value retains compatibility with previous operational behavior in that Timers B, D, F, H, and J all remain
subject to the single timer value set by trans-expire. However, when initial-inv-trans-expire is et to
a supported non-zero value, SIP Timer B as it applies to initial INVITEs, assumes that value rather than the value
assigned by trans-expire. This functionality is available in both sip-config and in sip-interface objects.
If a dedicated Timer B is enabled at the sip-config level, you can use initial-inv-trans-expire in the sip-
interface configuration mode, to establish a local interface-specific Timer B timeout value that overrides the global
default value.
ORACLE(sip-interface)# initial-inv-trans-expire 8
ORACLE(sip-interface)#
CAC mode you select (either aor or ip). When an endpoint registers with the Oracle Communications Session Border
Controller, theOracle Communications Session Border Controller allots it a total amount of bandwidth and total
number of sessions.
This section describes the details of how SIP per user CAC works.
You should note that the functionality this section describes only works if you enable registration caching on your
Oracle Communications Session Border Controller.
For SIP sessions, the Oracle Communications Session Border Controller now keeps track of the amount of bandwidth
a user consumes and the number of active sessions per address of record (AoR) or per IP address, depending on the
CAC mode you select (either aor or ip). When an endpoint registers with the Oracle Communications Session Border
Controller, the Oracle Communications Session Border Controller allots it a total amount of bandwidth and total
number of sessions.
Notes on HA Nodes
This feature has been implemented so that a newly active system is able to perform SIP per user CAC. The standby
Oracle Communications Session Border Controller is updated with the appropriate parameters as part of the SIP
session update.
The Oracle Communications Session Border Controller calculates the number of minutes used when a call completes,
and counts both call legs for a call that uses the same realm for ingress and egress. The total time attributed to a call is
the amount of time between connection (SIP 200 OK) and disconnect (SIP BYE), regardless of whether media is
released or not; there is no pause for calls being placed on hold.
If the number of minutes is exhausted, the Oracle Communications Session Border Controller rejects calls with a SIP
503 Service Unavailable message (including additional information “monthly minutes exceeded). In the event that the
limit is reached mid-call, the Oracle Communications Session Border Controller continues with the call that pushed
the realm over its threshold but does not accept new calls. When the limit is exceeded, the Oracle Communications
Session Border Controller issues an alarm and sends out a trap including the name of the realm; a trap is also sent
when the alarm condition clears.
Note: The Oracle Communications Session Border Controller does not reject GETS/NSEP calls based on
monthly minutes CAC.
You can change the value for minutes-based CAC in a realm configuration at any time, though revising the value
downward might cause limits to be reached. This value resets to zero (0) at the beginning of every month, and is
checkpointed across both system in an HA node. Because this data changes so rapidly, however, the value will not
persist across and HA node if both systems undergo simultaneous failure or reboot.
You can use the ACLI show monthly minutes <realm-id> command (where <realm-id> is the realm
identifier of the specific realm for which you want data) to see how many minutes are configured for a realm, how
many of those are still available, and how many calls have been rejected due to exceeding the limit.
Overview
The SIP specification (RFC 3261) requires that the Oracle Communications Session Border Controller B2BUA reject
any request that contains a Require header with an option tag the Oracle Communications Session Border Controller
does not support. However, many of these extensions operate transparently through the Oracle Communications
Session Border Controller's B2BUA. You can configure how SIP defines the Oracle Communications Session Border
Controllers B2BUA treatment of specific option tags.
Also, there might be certain extensions that an endpoint indicates support for by including the option tag in a
Supported header. If you do not want a given extension used in your network, the you can configure SIP option tag
handling to remove the undesired option tag from the Supported header. You can also specify how option tags in
Proxy-Require headers are to be treated.
Configuration Overview
You configure the SIP feature element to define option tag names and their treatment by the Oracle Communications
Session Border Controller when the option tag appears in a Supported header, a Require header, and a Proxy-Require
header. If an option tag is encountered that is not configured as a SIP feature, the default treatments apply. You only
need to configure option tag handling in the SIP feature element when non-default treatment is required.
You can specify whether a SIP feature should be applied to a specific realm or globally across realms. You can also
specify the treatment for an option based on whether it appears in an inbound or outbound packet. Inbound packets
are those that are coming from a realm to the Oracle Communications Session Border Controller and outbound
packets are those which are going from the Oracle Communications Session Border Controller to the realm.
The following tables lists the SIP option tag parameters you need to configure.
Parameter Description
Parameter Description
require mode inbound Action for tag in Require header in an inbound packet
proxy require mode inbound Action for tag in Proxy-Require header in an inbound packet
support mode outbound Action for tag in Supported header in an outbound packet
require mode outbound Action for tag in Require header in an outbound packet
proxy require mode outbound Action for tag in Proxy-Require header in an outbound packet
9. support-mode-outbound—Optional. Indicate the support mode to define how the option tag is treated when
encountered in an outbound SIP message’s Supported header. The default value is pass. Valid values are:
• pass—Indicates the B2BUA should include the tag.
• strip—Indicates the tag should not be included in the outgoing message. Use strip if you do not want the
extension used.
10. require-mode-outbound—Optional. Indicate the require mode to define how the option tag is treated when
it is encountered in an outbound SIP message’s Require header. The default value is reject. Valid values are:
• pass—Indicates the B2BUA should include the tag.
• reject—Indicates the B2BUA should reject the request with a 420 (Bad Extension) response. The option
tag is included in an Unsupported header in the reject response.
11. require-mode-outbound—Optional. Indicate the require proxy mode to define how the option tag is treated
when encountered in an outgoing SIP message’s Proxy-Require header. The default value is reject. The valid
values are:
• pass—Indicates the B2BUA should include the tag.
• reject—Indicates the B2BUA should reject the request with a 420 (Bad Extension) response. The option
tag is included in an Unsupported header in the reject response.
The following example shows SIP option tag handling configured for non-default treatment of option tags.
sip-feature
name newfeature
realm peer-1
support-mode-inbound Strip
require-mode-inbound Reject
proxy-require-mode-inbound Pass
support-mode-outbound Pass
require-mode-outbound Reject
proxy-require-mode-outbound Reject
last-modified-date 2004-12-08 03:55:05
The SDP from the original 183 response is used for the 200 response back to the originator if present to complete the
early transaction. If reliable provisional messages are used, then no SDP is included in the 200 response.
If no SDP is present in any of the provisional messages, then the Oracle Communications Session Border Controller
constructs it from the original offer and modifying the IP port information for each c= and m= line with information
from the INVITE with Replaces: header. If there are more m= lines in the original offer than ports from the INVITE
with Replaces: header, then the extra ports are disabled with port value of 0. If no SDP was offered in the original
INVITE, then the SDP from the INVITE with Replaces: header is used as the offer in the 200 OK.
If the SDP media parameters were compatible between the replaced and replacing SDPs, then media does not need to
be renegotiated and no re-INVITE is created. If the re-INVITE fails, the original dialogs are torn down using a BYE
for the original server dialog.
Debugging
show sipd status
Includes Replaced Dialogs counts to show successfully replaced dialogs:
SIP Options
This section explains how you can configure a limited list of specialized SIP features and/or parameters called
options. The options described here were developed to meet specific needs not addressed by the standard SIP
configuration parameters. Not all users have a need for these options.
Note: Oracle recommends checking with your Oracle representative before applying any of these options.
Overview
You can configure options for the SIP configuration and SIP interface. Both elements include a parameter (options)
that you use to configure the options.
Option Description
add-error-to-tag=no If present (even when set to no), suppresses the addition of an Acme tag
on 3xx-6xx responses.
add-prov-to-tag=no Prevents the SBC from adding a tag parameter to the To header (to-tag)
to non-100 provisional responses to INVITE requests. Used when a
provisional (101-199) response is received from the UAS on a client
transaction without a to-tag. By default, the SBC adds the tag cookie in
the response (as though it had a tag) sent back to the UAC for the
associated server transaction. When you include this option in the SIP
configuration, and the response from the UAS does not have a to-tag, the
response forwarded to the UAC will not have a to-tag.
add-reg-expires Causes an Expires header to always be included in a REGISTER
response with the registration caching and HNT traversal functions of
the SBC. Use for endpoints that do not understand the Expires parameter
in the Contact header.
add-ruri-user=<methods> Causes a userinfo portion to be added to a Request-URI when one is not
present. Used to support the OKI phone, which registers a Contact of
just an IP-Address but rejects initial INVITEs if the Request_URI does
not have a userinfo part.
Option Description
allow-notify-no-contact Prevents the SBC from rejecting NOTIFYs with a 400 Bad Request
response.NOTIFY requests without Contact header are allowed to pass
through the SBC instead.
call-id-host=<host> Causes the SBC to include a host part (ID@host) in the Call-ID it
generated.
<host> is the hostname (or IP address) that is to appear in the host part
of the Call-ID. If not specified, the SIP port address is used.
contact-firewall=<param-name> Defines a URL parameter to report the NAT between the SBC and the
real Contact address of an endpoint in a REGISTRAR message
forwarded to a registrar when the SBC is doing registration caching for
NHT.
If <param-name> is not specified, the default value firewall is used.
This parameter will be added as a URL parameter in the Contact on the
REGISTER message.
In order for the registration cache to work properly, the softswitch/
registrar is expected to include the endpoint parameter in the Request-
URI of any SIP request it forwards for the address-of-record.
encode-contact=<prefix> Causes the SBC to encode Contact addresses into the userinfo part of the
URI. It applies only to Contact address that usually get the maddr
parameter. Use when the SBC needs requests sent to the URI in the
Contact sent instead to the SBC. The host part of the URI will have the
SBC’s address.
Option Description
The <prefix> serves as a place between the original userinfo and the
encoded address. If a <prefix> is specified, a default of +SD is used.
Without this option, the SBC adds a maddr parameter.
fix-to-header For requests that have the SBC address in both the Request-URI and the
To-URI, it sets the hostport of the To-URI to a local policy’s next hop
target on out-of-dialog requests (no to-tag).
This is the default IWF behavior, even without this option configured.
forward-reg-callid-change Addresses the case when an endpoint reboots and performs a third party
registration before its old registration expires. During this re-registration,
the contact header is the same as it was pre-reregistration. As a
consequence of the reboot, the SIP Call-ID changes.
In this situation, the SBC does not forward the REGISTER to the
registrar, because it believes the endpoint is already registered, based on
a previous registration from the same Contact: header URI.
To remedy this problem, the SBC now keeps track of the Call-ID in its
registration cache. A new option in the SIP interface configuration
element forces the SBC to forward a REGISTER message to the
registrar when the Call-ID header changes in a REGISTER message
received from a reregistering UAC.
ignore-register-service-route-oos Prohibits a Register message from using a service route if that service
route is an out-of-service session agent.
load-limit=<cpu percentage> Defines the CPU usage percentage at which the SBC should start
rejecting calls. Default value is 90%.
lp-sa-match=<match strategy> Changes the ways local policies and session agents match; accounts for
realm in matching process. Strategy choices are: all, realm, sub-realm,
interface, and network.
max-register-forward=<value> Defines a limit (as assigned in the value field) of REGISTERs to be
forwarded to the registrar.
During each second, the sipd counts how many REGISTERs have been
sent to the registrar. It checks the threshold when it receives a
REGISTER from the UA and determines that less than half the real
registration lifetime is left. If the number of REGISTERs forwarded
(new and updates) in the current second exceeds the configured
threshold, it will respond to the UA from the cache.
max-register-refresh=<value> Defines the desired limit of REGISTER refreshes from all the UAs.
Each second of time, sipd counts the number of REGISTER/200-OK
responses sent back. When the threshold is exceeded, it increments the
expire time (based on NAT interval) by one second and resets the count.
Option Description
max-routes=<number of routes> Restricts the number of routes through which the sipd will iterate from a
local policy lookup. For example, setting this option to 1 causes the SBC
to only try the first, best, route. Setting this option to 0, or omitting it,
lets the SBC use all of the routes available to it (with the priority scheme
for route matching).
When you test a policy using the test-policy ACLI command, this option
is not recognized and all options that match the criteria are displayed.
max-udp-length=<maximum length> Setting this option to zero (0) forces sipd to send fragmented UDP
packets. Using this option, you override the default value of the
maximum UDP datagram size (1500 bytes; sipd requires the use of
SIP/TCP at 1300 bytes).
You can set the global SIP configuration’s max-udp-length=x option for
global use in your SIP configuration, or you can override it on a per-
interface basis by configuring this option in a SIP interface
configuration.
media-release=<header-name>[;<header- Enables the multi-system media release feature that encodes IP address
param>] and port information for the media streams described by SDP. It lets
another SBC decode the data to restore the original SDP, which allows
the media to flow directly between endpoints in the same network (that
is serviced by multiple SBCs).
The media release information can appear in the following places:
• SIP header
P-Media-Release: <encoded-media-interface-information>
• Header parameter on a SIP header
Contact: <sip:1234@abc.com> ; acme-media=<encoded-media-
interface-information>
• SDP attribute in the message body
a=acme-media: <encoded-media-interface-information>
Option includes the following:
• <header-name> is SIP header in which to put the information or the
special value sdp, which indicates the information should be put into
the SDP.
• <header-param> is the header parameter name in which to put the
information or in the case of the special header name value sdp, it is
the SDP attribute name in which to put the information.
They identify to where the encoded information is passed. If you do not
specify a header, P-Media-Release is used.
no-contact-endpoint-port Enables the SBC to add a URL parameter (defined as an argument to the
contact-endpoint option) to the Contact headers of REGISTER messages
that it forwards to the registrar when it performs registration caching.
The value of the contact-endpoint URL parameter is the real address of
the endpoint; and if the endpoint is behind a NAT, this includes the IP
Option Description
address and a port number. However, not all network entities can parse
that port number, which is included unconditionally. This feature allows
you to configure the exclusion of the port number.
Despite the fact that you set this parameter in the global SIP
configuration, it is applied only to SIP interfaces. However, you can set a
contact-endpoint option in the realm configuration, on which this new
parameter has no effect.
reg-contact-user-random Support the SIP random registered-contact feature. Gives the SBC the
ability to support endpoints that randomly change their contact
usernames every time they re-register. Only applicable to operators who
need to support the Japan TTC standard JJ-90.22 in specific
applications.
Applies to cases when an endpoint re-registers with a different contact
username, but with the same hostname/IP address and the same address
of record (AoR). Without this feature enabled, the SBC forwards every
re-registration to the registrar with the new contact information without
it being considered a registration refresh. The SBC forwards it to the
Registrar using the same sd-contact as the previous registration.
When you set this option, the SBC does treat such a re-registration as a
registration refresh when it is received prior to the half-life time for the
specific contact. The SBC also uses the new contact username for the
Request-URI in requests it sends to the UA, and verifies that the UA
uses the correct one when that SBC is set to allow-anonymous registered
mode.
NOTE: The registration cache mode is set using the option reg-cache-
mode, but regardless of how you configure it, the registration cache
mode will be set to contact when SIP random registered-contact feature
is enabled.
Option Description
register-grace-timer Makes the grace time for the SIP Registration configurable. You can
configure the grace timer in seconds.
reinvite-trying=[yes] Causes the SBC to send a 100 Trying for re-INVITEs, which is normally
suppressed. If you enter the option name but omit the value yes, the
option is still active.
reject-interval=<value> Acts as a multiplier to increase the value presented to the UAC in the
Retry-After field. For example, if reject-interval=5 (reject interval is set
to 10); at a 90% rejection rate the SBC sends Retry-After: 45.
When rejecting calls because of CPU load limiting, the SBC adds a
Retry-After parameter to the error response (typically 503 Service
Unavailable). By default the SBC sets the Retry-After value to be 1/10th
of the current rejection rate.
reject-register=[no | refresh] Allows REGISTER messages through even during load limiting. By
default, REGISTER messages are subject to load limiting.
response-for-not-found=<response code> Change the 404 Not Found generated by the SBC to a different response
code.
route-register-no-service-route Controls how a UA is registered. Option can have three values:
• route-register-no-service-route—This option prevents the use of the
Service-Route procedure to route the Re-Register requests after the
UA has initially registered.
• route-register-no-service-route=all—Prevents the use of the Service-
Route procedure to route the Re-Register requests for all messages,
after the UA has initially registered.
• route-register-no-service-route=refresh—Prevents the use of the
Service-Route procedure to route the Re-Register requests for all
refresh-register messages, but not de-register messages, after the UA
has initially registered.
Addition idle argument ensures that, when enabled, the SBC follows the
previously defined rules for idle calls, where idle means not engaged in
any INVITE-based sessions.
Sample syntax: route-register-no-service-route=refresh;idle
sdp-insert-sendrecv When a call is initiated, the SDP communicates between call offerer and
call answerer to determine a route for the media. Devices can be
configured to only send media (“a=sendonly”), to only receive media
(“a=recvonly”), or to do both (“a=sendrecv”). Some devices, do not
disclose this information. With this option configured, when either the
offerer or answerer does not disclose its directional attribute, the SBC
automatically inserts a sendrecv direction attribute to the media session.
set-inv-exp-at-100-resp Set Timer C when a 100 Trying response is received (instead of waiting
until 1xx (> 100) is received). If the SBC does not receive a 100 Trying
response within Timer B, the call should be dropped because there is a
problem communicating with the next hop.
strip-domain-suffix-route Causes sipd to strip any Router headers from the inbound messages
coming to the external address of a SIP NAT; if the message contains a
FQDN that matches the configured domain suffix for that SIP NAT.
Option Description
video-sbc-session Use with drain-sendonly for conference floor support. When configured
with drain-sendonly and when the SBC receives an SDP, the SBC
proxies the m=control and its related a= and c= unchanged. Although
media streams are allocated for this m line, an actual flow is not set up.
SDP received with the following:
m=video
a=sendonly
is sent out as the following:
m=video
a=sendonly
a=X-SBC-Session
session-timer-support This option enables the SBC to start the session timer for session
refreshes coming from the UAC. The SBC determines whether or not a
session is active based on session refreshes or responses. It terminates
the session when no session refreshes occur within the session timer
interval.
session-timer-support Enables RFC4028 session timer support.
inmanip-before-validate Enables SIP Header Pre-processing for HMR.
proccess-implicit-tel-URI Correctly appends coodie in REGISTER message when user=phone
does not exist.
offerless-bw-media Reserves appropriate bandwidth for an INVITE with no SDP.
Option Description
contact-firewall=<firewall name> The Oracle Communications Session Border Controller inserts the
firewall IP address and port into the Contact headers as messages egress
using that SIP interface. The inserted data is the same as the information
received in the Request or Response being forwarded.
If the endpoint name is not specified, the default value firewall is used.
contact-vlan=<VLAN/realm name> The Oracle Communications Session Border Controllerinserts the realm
and VLAN ID into the Contact headers as messages egress using that
Option Description
SIP interface. The inserted data is the same as the information received
in the Request or Response being forwarded.
If the endpoint name is not specified, the default value vlan is used.
response-for-not-found=<response code> Change the 404 Not Found generated by the SBC to a different response
code.
strip-route-headers Causes the Oracle Communications Session Border Controller to
disregard and strip all route headers for requests received on a SIP
interface.
upd-fallback When a request needs to be sent out on the SIP interface for which you
have configured this option, the Oracle Communications Session Border
Controller first tries to send it over TCP. If the SIP endpoint does not
support TCP, however, then the Oracle Communications Session Border
Controller falls back to UDP and tries the request again.
via-header-transparency Enables the Oracle Communications Session Border Controller to insert
its Via header on top of the top-most Via header received from user
equipment (UE). It then forwards it on to the IP Multimedia Subsystem
(IMS) core with the original Via header now located as the bottom-most
Via header.
The Oracle Communications Session Border Controller still replaces the
Contact and other header addresses with its own, and does not pass on
the core’s Via headers in outbound requests.
Option Description
dropResponse The Oracle Communications Session Border Controllerdrops responses by
specified status codes. The option value can contain one or more status codes
separated by semicolons. Error ranges can also be entered. If any of the response
codes matches then a response is not sent. If the dropResponse option is set in
both the sip-interface and the session-agent elements, the session-agent setting
takes precedence.
trans-timeouts=<value> Defines the number of consecutive non-ping transaction timeouts that will cause
a session agent to be out of service. When the session agent is configured, i.e.
when the PING options are defined, the value is 10. If not defined, the default
value is 5. A Value of 0 prevents the session agent from going out of service
because of a non-ping transaction timeout.
via-origin=<parameter-name> Causes a parameter to be included in the top Via header of requests sent to the
session agent. The parameter indicates the source IP address of the
corresponding request received by the Oracle Communications Session Border
Controller.
<parameter-name> defines the name of the parameter. If not specified, the
default value origin is used.
Option Description
For example, if you want to configure the refer-to-uri-prefix option (the add-on conferencing feature):
Type options, followed by a Space.
Type refer-to-uri-prefix, followed by an equal sign (=).
Type the opening quotation mark (“) followed by conf, another equal sign and the closing quotation mark.
Press Enter.
For example:
options refer-to-uri-prefix=conf=
If the feature value itself is a comma-separated list, it must be enclosed in quotation marks.
Adding an Entry
Enter the new entry with a preceding plus (+) sign. For example:
options +response-for-not-found
This format allows previously configured options field values to remain intact without requiring re-entry of the entire
field value.
SIP Security
This section provides an overview of Oracle Communications Session Border Controller’s security capability. Oracle
Communications Session Border Controller security is designed to provide security for VoIP and other multi-media
services. It includes access control, DoS attack, and overload protection, which help secure service and protect the
network infrastructure (including the Oracle Communications Session Border Controller). In addition, Oracle
Communications Session Border Controller security lets legitimate users to still place calls during attack conditions,
protecting the service itself.
Oracle Communications Session Border Controller security includes the Net-SAFE framework’s numerous features
and architecture designs. Net-SAFE is a requirements framework for the components required to provide protection
for the Session Border Controller (SBC), the service provider’s infrastructure equipment (proxies, gateways, call
agents, application servers, and so on), and the service itself.
Configuration Overview
NAT table entries are used to filter out undesired IP addresses (deny list). After the packet from an endpoint is
accepted through NAT filtering, policing is implemented in the Traffic Manager based on the sender’s IP address.
NAT table entries are used to distinguish signaling packets coming in from different sources for policing purposes.
You can configure deny rules based on the following:
• ingress realm
• source IP address
• transport protocol (TCP/UDP)
• application protocol (SIP)
You can configure guaranteed minimum bandwidth for trusted and untrusted signaling paths.
You can configure signaling path policing parameters for individual source addresses. Policing parameters include:
• peak data rate in bits per second
• average data rate in bits per second
• maximum burst size
You might enable this feature if you have a network in which unauthorized SIP endpoints continually try to register
even if the Oracle Communications Session Border Controller has previously rejected them and never will accept
them. For instance, the user account associated with the endpoint might have been removed or core registrars might
be overloaded.
Overview
TheOracle Communications Session Border Controller is an intermediary device that provides NAT functions
between two or more realms. It translates IP addresses between untrusted and trusted networks using NAT. A trusted
network is inside the NAT, and a untrusted network is outside the NAT. A NAT also lets a single IP address represent
a group of computers.
For SIP, the SIP NAT function on the Oracle Communications Session Border Controller does the following:
• routes SIP packets between the Oracle Communications Session Border Controller’s SIP proxy (B2BUA) and
external networks (or realms), including the translation of IP address and UDP/TCP port information.
• prevents private IP addresses in SIP message URIs from traveling through the untrusted network. SIP NAT either
translates the private address to one appropriate for an untrusted address or encrypts the private address into the
URI.
Packets arriving on the external address (at port 5060) are forwarded to the Oracle Communications Session Border
Controller’s SIP proxy with the source address changed to the home address (at port 5060). When the Oracle
Communications Session Border Controller’s SIP proxy sends packets to the home address (at port 5060), they are
forwarded to the external proxy address (and external proxy port), with the source address changed to the external
address (at port 5060).
Note: The SIP config’s NAT mode parameter works in conjunction with the SIP NAT function configuration.
It identifies the type of realm in which the SIP proxy is located (public or private) and affects whether IPvr
addresses in SIP messages are encoded.
The translation of URIs in the actual SIP message occurs as messages are received and sent from the Oracle
Communications Session Border Controller’s SIP proxy. For the messages being sent to the external network, the
contents of the SIP message are examined after the translation to determine if the destination needs to be changed
from the external proxy address to an address and port indicated by the SIP message. This process takes place so the
request is sent to where the Request-URI or the Route header indicates, or so the response is sent to where the Via
indicates.
NAT Modes
The specific addresses used in translating URIs in the SIP message depend on whether the Oracle Communications
Session Border Controller is performing NAT functions for a trusted or untrusted network. This condition is
determined by the NAT mode value you enter when you configure the SIP config element. The NAT modes are:
• untrusted—The SIP proxy is associated with an address for an untrusted network (the address value you
entered when you configured the SIP interface’s SIP port parameter), and the home address in the SIP NAT is the
address of the external realm/network. When the URI contains the external address, it is translated to the SIP
NAT’s home proxy address (or to the SIP port address if the home proxy address field is empty). When a URI
contains the external proxy address, it is translated to the home address.
If the URI contains any other private address (matching the realm’s address prefix, identified in the SIP NAT’s
realm ID), it is encrypted and the address is replaced with the home address value. If the URI contains a user part,
a suffix consisting of the user NAT tag and the encrypted address is appended to the user part. For example, with a
user NAT tag value of -private-, the private URI of sip@123192.169.200.17:5060 will become the public URI of
sip:123-private-eolmhet2chbl3@172.16.0.15.
If there is no user part, the host consists of the host NAT tag followed by the encrypted address and the domain
suffix. A maddr parameter equal to the home address (or received in the case of a Via header) is added to the URI.
For example, with a host NAT tag value of PRIVATE- and a domain suffix value of private.com, the private URI
of sip:192.168.200.17:5060 will become the public URI of sip:PRIVATE-eolmhet2chbl3.private.com:
5060;maddr=172.16.0.15.
• trusted—The SIP proxy is on a trusted network (the address value you entered when you configured the SIP
interface’s SIP port parameter), and the SIP NAT’s external address is the public address of the external realm/
network. When the URI contains the home address value, it is translated to the value set for the external proxy
address. When the URI contains the SIP proxy’s address, it is translated to the external address. If the URI
contains any other private address (matching the realm’s address prefix, identified in the SIP NAT’s realm ID), the
private address is encrypted and the address is replaced with the external address.
Note: Do not use the home proxy address value with private NAT functioning.
You might require this encryption to cause other SIP elements in the untrusted network to send requests directly to the
SIP proxy. Otherwise, the requests are sent to the home address. However, responses sent by the SIP proxy will have
the SIP proxy’s source address, rather than the home address. Some SIP elements might drop responses that come
from a IP address different from the one to which the request is sent.
About Headers
You can specify which SIP headers you want effected by the SIP NAT function. The URIs in these headers are
translated and encrypted, the encryption occurs according to the rules of this SIP NAT function.
You can enter header values by using either the full header name or its corresponding abbreviation, if applicable. The
following table lists the available headers and their corresponding abbreviations
Header Abbreviation
Call-ID i
Contact m
From f
Record-Route none
Route none
Ready-To none
Replaces none
Refer-To r
To t
Via v
SIP sessions are terminated and re-originated as new sessions as they are routed through the Oracle Communications
Session Border Controller. Among the actions performed, SIP headers are modified to prevent the transmission of IP
address and route information.
Replacing Headers
In the SIP signaling message, any Via headers are stripped out and a new one is constructed with the Oracle
Communications Session Border Controller’s IP address in the sent-by portion. If a Contact header is present, it is
replaced with one that has the Oracle Communications Session Border Controller’s IP address. All other headers are
subject to NATing based on the following rules:
• The Request-URI is replaced with the next hop’s IP or FQDN address.
• All other headers are replaced based on the two SIP NAT function SIP NAT function rules
Mapping FQDNs
The Oracle Communications Session Border Controller maps FQDNs that appear in the certain headers of incoming
SIP messages to the IP address that the 12:00 inserts in outgoing SIP contact headers. The mapped FQDNs are
restored in the SIP headers in messages that are sent back to the originator.
This feature is useful to carriers that use IP addresses in the SIP From address to create trunk groups in a softswitch
for routing purposes. When the carrier’s peer uses FQDNs, the carrier is forced to create trunk groups for each
possible FQDN that it might receive from a given peer. Similarly, this can apply to SIP Contact and P-Asserted-
Identity headers.
(SBC) encodes various information in the outgoing message, which is passed from one side to another in SIP
transactions.
SIP NAT function cookies let the SBC hide headers, IPv4 addresses, and SIP URIs. These cookies are included when
certain conditions are present in SBC SIP transactions.
Oracle’s SIP NAT function cookies can be used in the userinfo, host, URL parameter, and tel URL parameter portions
of the SIP message.
userinfo
The Oracle Communications Session Border Controller places a cookie in the userinfo portion of a SIP URI when a
SIP header contains a SIP URI, and includes that header type in the list of headers to be hidden (encrypted) in the
associated SIP NAT function. The cookie for the userinfo portion is the following:
[user nat tag][encrypted 13-byte host IP][encrypted 13 byte maddr IP (if
present)]
where:
• [user nat tag] refers to the SIP NAT function’s original user NAT tag field.
• [encrypted 13-byte host IP] refers to the host IP encryption.
• [encrypted 13 byte maddr IP (if present)] refers to the maddr IP encryption, if it exists.
With a user NAT tag of -acme, the following SIP-URI:
sip:6175551212@192.168.1.100
might be translated into:
sip:6175551212-acme-pfi1s7n2pstna@172.16.1.10
Note: Multiple additional cookies might be appended with each hop (for example, from the external proxy to
the home proxy and back).
host
When hiding IP addresses in a SIP message, the SIP NAT function generates the following cookie for a SIP-URI with
no userinfo portion:
[host nat tag][encrypted 13-byte host IP][encrypted 13 byte maddr IP (if
present)][domain suffix]
where:
• [host nat tag] refers to the SIP NAT function’s host NAT tag.
• [encrypted 13-byte host IP] refers to the host IP encryption.
• [encrypted 13 byte maddr IP (if present)] refers to the maddr IP encryption, if it exists.
• [domain suffix] refers to the SIP NAT function’s domain suffix field.
With a SIP NAT function’s host tag of ACME- and a domain suffix of .acme.com, the following SIP header:
Via: SIP/2.0/UDP 192.168.1.100:5060
might be translated into the following:
Via: SIP/2.0/UDP ACME-pfi1s7n2pstna.acme.com
URL Parameter
If the SIP NAT function’s use url parameter field has a value of from-to or all, the SIP NAT function places all
cookies generated to hide SIP URIs in a custom tag appended to the header. Setting the use url parameter field to:
• from-to only affects the behavior of the SIP NAT function’s cookies in the From and To headers.
• all affects all SIP headers processed by the SIP NAT function
The cookie is the following:
tel URL
The SIP NAT function cookie is used when devices in your network are strict about the context portion of SIP
messages regarding the conversion of tel URLs. This cookie for the tel URL parameter portion of a SIP message is
the following:
tel URL parameter-[13-byte host IP][13 byte optional maddr IP]domain suffix
where:
• tel URL parameter refers to the SIP NAT function’s use url parameter.
This cookie type is associated with the use url parameter’s phone field value for the SIP NAT.
• [13-byte host IP] refers to the host IP encryption.
• [13 byte optional maddr IP] refers to the maddr IP encryption, if it exists.
• domain suffix refers to the SIP NAT function’s domain suffix field.
Configuration Overview
Configuring the SIP NAT function falls into two areas, the SIP NAT interface parameters and the SIP NAT policies.
Parameter Description
realm ID Name of the external realm. The realm ID must be unique; no two SIP
NATs can have the same realm ID.
This realm ID must also correspond to a valid realm identifier entered
when you configured the realm.
external proxy address IPv4 address of the SIP element (for example, a SIP proxy) in the external
network with which the SBC communicates. Entries must follow the IP
address format.
external proxy port UDP/TCP port of the SIP element (for example, a SIP proxy) in the
external network with which the SBC communicates.
Minimum value is 1025, and maximum value is 65535. Default is 5060.
external address IPv4 address on the media interface in the external realm. Enter a value
that ensures any packet with an external address value as its destination
Parameter Description
home address IPv4 address on the media interface in the home realm. Enter a value that
ensures any packet with a home address value as its destination address
must be routed to the SBC through the media interface connected to or
routable from the home realm. Entries must follow the IP address format.
The value entered in this field must be different from the IP address value
of the home realm’s network interface element.
The home realm network interface is associated with this SIP NAT by its
realm ID and the realm’s identifier and network interface value you
entered when you configured the realm. The realm’s network interface
identifier value corresponds to this SIP NAT’s realm ID, the SIP config’s
home realm ID, and the media manager’s home realm ID.
home proxy address Sets the IP address for the home proxy (from the perspective of the
external realm).
By default, this field is empty.
An empty home proxy address field value signifies that there is no home
proxy, and the external address will translate to the address of the SBC ’s
SIP proxy. Entries must follow the IP address format.
home proxy port Sets the port number for the home realm proxy.
Value can be set to zero (0). Minimum is 1025 and maximum is 65535.
Default is 5060.
route home proxy Whether to route all inbound requests for the SIP NAT to the home proxy.
enabled adds route if Request-URI is not the SBC
disabled does not route inbound requests to the home proxy
forced always adds route
Parameter Description
domain suffix Domain name suffix of the external realm. The domain name suffix refers to
and must conform to the hostname part of a URI. In combination with the user
NAT tag and host NAT tag values, this value is used to help the SBC identify
an encoded URI that it needs to translate when moving between public and
private realms.
This suffix is appended to encoded hostnames that the SIP NAT function
creates. For example, if the encoded hostname is ACME-abc123 and the
domain-suffix value is .netnetsystem.com, the resulting FQDN will be
ACME-abc123.netnetsystem.com.
Parameter Description
address prefix Defines which IPv4 address prefixes from incoming messages require SIP-
NAT encoding (regardless of the realm from which these messages came).
tunnel redirect Controls whether Contact headers in a 3xx Response message received by the
SBC are NATed when sent to the initiator of the SIP INVITE message.
use url parameter Establishes whether SIP headers will use the URL parameter entered in the
parameter name for encoded addresses that the SIP NAT function creates.
Also, if SIP headers will be used, which type of headers will use the URL
parameter. For example, all headers or just the From and To headers.
Enumeration field.
parameter name Indicates the name of the URL parameter when use url applies. This field
value will be used in SIP NAT encoding addresses that have a use url
parameter value of either from-to or all.
user NAT tag Identifies the prefix used when an address is encoded into the username
portion of user@host;name=xxxx; where name = parameter name.
The user NAT tag values can consist of any characters that are valid for the
userinfo part of a URI. In combination with the domain suffix and host NAT
tag field values, this value is used to help the SBC identify an encoded URI
that it needs to translate when moving between public and private realms.
host NAT tag Identifies the prefix used when encoding an address into the hostname part of
the URI or into a URL parameter. The host NAT tag values refer to domain
labels and can consist of any characters that are valid for the hostname part of
a URI. In combination with the domain suffix and user NAT tag values, this
value is used to help the SBC identify an encoded URI that it needs to
translate when moving between public and private realms.
headers Lists the SIP headers to be affected by the SBC SIP NAT function. The URIs
in these headers will be translated and encrypted, and encryption will occur
according to the rules of this SIP NAT.
The domain suffix is appended to encoded hostnames that the SIP NAT function creates. For example, if the
encoded hostname is ACME-abc123, the resulting FQDN is ACME-abc123.netnetsystem.com.
6. external-proxy-address—Enter the external proxy address to identify the IPv4 address of the SIP
element (for example, a SIP proxy) in the external network with which the SBC communicates.
Enter the value in the IP address format. For example:
192.168.11.200
7. external-proxy-port—Enter the external proxy port value to identify the UDP/TCP port of the SIP
element (for example, a SIP proxy) in the external network with which the SBC communicates. The default is
5060. The valid range is:
• Minimum—1025
• Maximum—65535
8. external-address—Enter the external address, which is an IPv4 address on the media interface in the
external realm.
Enter the value in the IP address format. For example:
192.168.11.101
This value must be such that any packet with an external address value as its destination address is routed to the
SBC through the media interface connected to or routable from the external realm.
9. home-address—Enter the home address, which is an IPv4 address on the network interface in the home realm.
This value must be such that any packet with a home address value as its destination address must be routed to the
SBC through the media interface connected to or routable from the home realm.
Enter the value in the IP address format. For example:
127.0.0.10
The value entered in this field must be different from the IP address value of the home realm’s network
interface element.
The home realm network interface is associated with this SIP NAT by its realm ID and the realm’s identifier and
network interface value you entered when you configured the realm. The realm’s network interface identifier
value corresponds to this SIP NAT’s realm ID, the SIP config’s home realm ID, and the media manager’s home
realm ID.
10. home-proxy-address—Enter the home proxy address to set the IP address for the home proxy (from the
perspective of the external realm).
By default, this field is empty. No home proxy address entry signifies there is no home proxy, and the external
address will translate to the address of the SBC’s SIP proxy.
Enter the value in the IP address format. For example:
127.1.0.10
11. home-proxy-port—Enter the home proxy port to set the port number for the home realm proxy. The default
value is 0. The valid range is:
• Minimum—0, 1025
• Maximum—65535
12. route-home-proxy—Optional. Enable or disable requests being routed from a given SIP-NAT to the home
proxy. The default value is disabled. The valid values are:
• enabled—All inbound requests for a specific SIP NAT are routed to the home proxy
• disabled—All inbound requests are not routed through the home proxy.
• forced—The Request is forwarded to the home proxy without using a local policy.
13. address-prefix—Optional. Indicate the IPv4 address prefix from incoming messages that requires SIP NAT
function encoding (regardless of the realm from which these messages came).
Note: This value overrides the value set in the realm’s address prefix field.
This field’s format incorporates an IPv4 address and number of bits in the network portion of the address. For
example, a Class C address has a 24-bit network part. The address prefix for 101.102.103.x would be represented
as 10.102.103.0/24.
The default value is an asterisk (*). When you enter this value or do not enter a value, the realm’s address prefix
value is used.
14. tunnel-redirect—Set to one of the following values to indicate whether certain headers in a 3xx Response
message received by the SBC are NATed when sent to the initiator of the SIP INVITE message. The default is
disabled. The valid values are:
• enabled—Certain headers in a 3xx Response message are NATed.
• disabled—Certain headers in a 3xx Response message are not NATed.
15. use-url-parameter—Establish whether SIP headers will use the URL parameter (configured in the next
step) for encoded addresses created by the SIP NAT function. If SIP headers will be used, this value identifies
which types of headers will use the URL parameter. The default value is none. The available values include:
• none—No headers will use the URL parameter for address encoding.
The following example illustrates the functionality of an SBC using a use url parameter value of none:
sip: 1234@1.2.3.4 is translated into sip: 1234-acme-xxxx@5.6.7.8
where -acme-xxxx is a cookie and xxxx is the encoded version of 1.2.3.4.
• from-to—From and To headers will use the URL parameter for address encoding
The following example illustrates the functionality of a SBC using a use url parameter value of none:
sip: 1234@1.2.3.4 is translated into sip: 1234@5.6.7.8; pn=acme-xxxx
where -acme-xxxx is a cookie and xxxx is the encoded version of 1.2.3.4.
• all—All headers will use the URL parameter for address encoding. Acme Packet recommends not using this
values because other SIP elements or implementations (other than the Oracle Communications Session Border
Controller) might not retain the URL parameter in subsequent SIP messages that they send to the Oracle
Communications Session Border Controller.
• phone—
If this field is set to either from-to or all, the SBC puts the encoded address of the SIP NAT into a URL
parameter instead of using the encoding name inside the userinfo part of the address.
16. parameter-name—If you have configured the use-url-parameter with the from-to or all value, you
need to indicate the hostname prefix.
The parameter name value is used in SIP NAT encoding addresses that have the use url parameter values of from-
to or all.
17. user-NAT-tag—Enter a value to identify the username prefix used for SIP URIs. The values you can use can
include any characters valid for the userinfo part of a URI. This should be made unique for each realm and SIP
NAT function.
The default value is -acme-.
In combination with the domain suffix and host NAT tag values, this value is used to help the SBC identify an
encoded URI that it needs to translate when moving between public and private realms.
18. host-NAT-tag—Enter a value for the host NAT tag field to identify the hostname prefix used for SIP URIs.
The value refers to domain labels and can include any characters valid for the hostname part of the URI. This
should be made unique for each realm and SIP NAT function.
The default value is ACME-.
In combination with the domain suffix and user NAT tag values, this value is used to help the SBC identify an
encoded URI that it needs to translate when moving between public and private realms.
19. headers—List the SIP headers you want affected by the SIP NAT function. The URIs in these headers are
translated and encrypted, and encryption occurs according to the SIP NAT function rules.
To enter the full default list, type headers, followed by a Space and -d, then press Enter.
You can also insert the following tags in SIP NAT headers if you want to replace FQDNs with next hop or SIP
interface IP addresses:
• fqdn-ip-tgt: replaces the FQDN with the target address
• fqdn-ip-ext: replaces the FQDN with the SIP NAT external address
Enter the tag using the following format:
<header-name>=<tag>
For example:
To=fqdn-ip-tgt
The FQDN in a To header is replaced with the target IP address.
You can insert the following tags to apply NAT treatment to a From header in an INVITE when the gateway
sends it into the home realm.
• ip-ip-tgt: replaces any IP address in the From header with the next hop target
• ip-ip-ext: replaces any IP address in the From header with the SBC’s external address
To view all SIP NAT function parameters, enter a ? at the system prompt. The following example shows SIP
NAT configuration for peering network.
sip-nat
realm-id peer-1
domain-suffix .p1.acme.com
ext-proxy-address 192.168.11.200
ext-proxy-port 5060
ext-address 192.168.11.101
home-address 127.0.0.10
home-proxy-address 127.1.0.10
home-proxy-port 5060
route-home-proxy enabled
address-prefix *
tunnel-redirect disabled
use-url-parameter none
parameter-name
user-nat-tag -p1-
host-nat-tag P1-
headers Call-ID Contact From Join Record-
Route
Refer-To Replaces Reply-To Route
To Via
f i m r t v
One-to-One Configuration
In the one-to-one scenario, a single customer SIP NAT is tied to a single backbone SIP NAT. On the backbone SIP
NAT side, you configure the home proxy address to match the home address of the customer SIP NAT. On the
customer side, you configure the home proxy address to match the home address of the backbone SIP NAT.
The following diagram illustrates the one-to-one SIP-NAT bridge configuration.
Many-to-One Configuration
To configure many-to-one:
1. For the backbone SIP NAT, ensure the home proxy address field is blank.
2. For the customer side SIP NAT:
Set the home address to match the home address of the customer.
Set the home proxy address to match the backbone SIP NAT home address.
Set route home proxy to forced.
The following table lists the field values you need to set to create a many-to-one SIP NAT bridge.
Backbone SIP NAT home address IPv4 address of the home realm. For
example:
127.0.0.120
home proxy address IPv4 address of the home proxy from the
perspective of the external realm.
For a backbone SIP NAT, leave blank.
One-to-One Configuration
In the one-to-one scenario, a single customer SIP NAT is tied to a single backbone SIP NAT. The home proxy address
field value of the backbone SIP NAT must match the home address of the customer SIP NAT. On the customer side,
the home address of the customer SIP NAT should be defined as the home address of the customer, the home proxy
address field value should match the home address of the backbone SIP NAT, and route home proxy should be set to
forced.
The following table lists the field values you need to set to create a one-to-one SIP NAT bridge.
Backbone SIP NAT home address IPv4 address of the home realm. For
example:
127.0.0.110
home proxy address IPv4 address of the home proxy from the
perspective of the external realm.
127.0.0.120
The Oracle Communications Session Border Controller’s HNT function allows endpoints located behind NATs to
communicate; providing means to traverse NATs. The Oracle Communications Session Border Controller interacts
with endpoints (using SIP) to allow persistent inbound and outbound signaling and media communications through
these NATs.
The Oracle Communications Session Border Controller automatically detects when an intermediate NAT exists
between the UA and the Oracle Communications Session Border Controller by comparing the Layer 3 IP address of a
REGISTER message with the IP address indicated within the UA. The Oracle Communications Session Border
Controller sends signaling responses to the address and port that the request came from, rather than the address and
port indicated in the request. The Via header in the request message indicates where the response should be sent.
Registering Endpoints
The Oracle Communications Session Border Controller uses periodic endpoint registration messages to dynamically
establish and maintain bindings in the NAT. These bindings keep a signaling port (port that is opened on a firewall to
allow traffic to pass through it is a pinhole) open in the NAT that allows the inbound signaled communications to pass
through. Using the endpoint registrations, the Oracle Communications Session Border Controller then maps the Layer
3 (OSI network layer that deals with switching and routing technologies for data transmission between network
devices) IPv4 address/port information from the NAT device to the Layer 5 (OSI session layer that deals with session
and connection coordination between applications) entity (for example, user name or phone number) behind the NAT
so that when an incoming signaling message is received, the Oracle Communications Session Border Controller sends
it to the appropriate address and port on the NAT for the called party.
Prerequisites
In order to achieve HNT, the endpoints involved must be capable of:
• symmetric signaling: sending and receiving SIP messages from the same transport address (IP address or User
Datagram Protocol/Transmission Control Protocol (UDP/TCP) port
• symmetric media: sending and receiving Real-Time Transport Protocol (RTP) messages from the same UDP port
These conditions are required to allow signaling and media packets back through the NAT (through the bound
external address and port). These packets must come from the address and port to which the outbound packet that
created the NAT binding was sent. The NAT sends these inbound packets to the source address and port of the
original outbound packet.
When SIP HNT is used, the Oracle Communications Session Border Controller sends signaling responses to the
address and port that the request came from rather than the address and port indicated in the request. The Via header
in the request message indicates where the response should be sent.
When a successful response is received, the Oracle Communications Session Border Controller caches the registration
to memory. This cached registration lives for the length of time indicated by the expiration period defined in the
REGISTER response message from the registrar. The response sent back to the endpoint has a shorter expiration time
(defined by the SIP config’s NAT interval) that causes the endpoint to send another REGISTER message within that
interval. If the endpoint sends another REGISTER message before the cached registration expires, the Oracle
Communications Session Border Controller responds directly to the endpoint. It does not forward the message to the
real registrar.
If the cached registration expires within the length of time indicated by the NAT interval, the REGISTER message is
forwarded to the real registrar. If the Oracle Communications Session Border Controller does not receive another
REGISTER message from the endpoint within the length of time indicated by the NAT interval, it discards the cached
registration.
The Contact Uniform Resource Identifier (URI) in the REGISTER message sent to the registrar by the Oracle
Communications Session Border Controller points at the Oracle Communications Session Border Controller so that
the proxy associated with the real registrar sends inbound requests to the Oracle Communications Session Border
Controller. This way, the inbound requests can be forwarded to the endpoint through the NAT binding.
The following example illustrates the SIP HNT registration call flow for the SIP HNT feature.
The following example illustrates the SIP HNT invitation call flow for the SIP HNT feature.
registrar domain *
registrar host *
registrar port 0
• SIP interface
HNT Configuration
To configure a SIP interface on the Oracle Communications Session Border Controller (SBC):
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(session-router)# sip-interface
ORACLE(sip-interface)#
From this point, you can configure physical interface parameters. To view all SIP interface parameters, enter a ? at
the system prompt.
4. nat-traversal—Define the type of HNT enabled for SIP. The default value is none. Available values
include:
• none—Disables the HNT feature for SIP (default value)
• rport—SIP HNT function only applies to endpoints that include the rport parameter in the Via header and
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.)
5. nat-interval—Set the expiration time in seconds for the SBC’s cached registration entry for an HNT
endpoint. The default value is 30. The valid range is:
• Minimum—0
• Maximum—999999999
Acme Packet 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 prevent the NAT device from keeping an unused port open.
6. registration-caching—Enable for use with all UAs, not just those that are behind NATs. By default, this
field is set to disabled. If enabled, the SBC caches the Contact header in the UA’s REGISTER request when it
is addressed to one of the following:
• SBC
• registrar domain value
• registrar host value
The SBC then generates a Contact header with the SBC’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:
• enabled—The SBC 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 client-server
communication so that the information can be used in the future.
• 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 Communications Session Border Controller.
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 SBC, which is the Contact address. Then, the v forwards the
request to the Contact-URI it cached from the original REGISTER message.
7. 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 value is 300. The valid range is:
• Minimum—1
• Maximum—999999999
This value defines the minimum expiration value the SBC places in each REGISTER message it sends to the
real registrar. In HNT, the SBC caches the registration after receiving a response from the real registrar and
sets the expiration time to the NAT interval value.
Some UAs might change the registration expiration value they use in subsequent requests to the value
specified in this field. This change causes the SBC to send frequent registrations on to the real registrar.
8. registration-interval—Set the SBC’s cached registration entry interval for a non-HNT endpoint. Enter
the expiration time in seconds that you want the SBC 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 value is 3600. The valid range is:
• Minimum—1
A registration interval of zero causes the SBC 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
SBC responds to the refresh request directly rather than forwarding it to the registrar.
Note: With registration caching, there is no NAT; therefore, a short registration interval causes the UA
to send excess REGISTER messages.
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 SBC. 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.
9. 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 SBC’s address. Because the registrar host is the real registrar, it should send the
requests back to the SBC with the SBC’s address in the Request-URI. The default value is disabled. The valid
values are:
• enabled | disabled
For example, you should enable routing to the registrar if your network uses a SBC and needs requests to go
through its service proxy, which is defined in the registrar host field.
• IPv4 address: must follow the dotted notation format. Each of the four segments can contain a numerical value
between zero (0) and 255. For example, 192.168.201.2. An example of a invalid segment value is 256.
By default, the registrar host field remains empty.
6. registrar-port—Set the SIP registrar port number. The SIP registrar server configured in this and the
registrar host field is the real registrar. Or the values entered in those fields map to the home proxy address and
home proxy port of the SIP NAT with external proxy address and external proxy port values that correspond to the
real registrar. The default value is 0. The valid range is:
• Minimum—0, 1025
• Maximum—65535
The following example shows the values for a single domain and registrar configuration.
sip-config
state enabled
operation-mode dialog
dialog-transparency disabled
home-realm-id acme
egress-realm-id
nat-mode Public
registrar-domain
registrar-host
registrar-port 0
init-timer 500
max-timer 4000
trans-expire 32
invite-expire 180
inactive-dynamic-conn 32
red-sip-port 1988
red-max-trans 10000
red-sync-start-time 5000
red-sync-comp-time 1000
last-modified-date 2005-03-19 12:41:28
Endpoint-Initiated Keep-Alives
The Oracle Communications Session Border Controller provides three Keep-Alive algorithms designed to generate
sufficient traffic flow to maintain NAT (Network Address Translation) bindings. Prior releases provided a single
Keep-Alive algorithm that is described in the SIP Hosted NAT Traversal (HNT) section of the SIP Signaling Services
chapter of the ACLI Configuration Guide. This method is SD-based and requires no explicit participation by the SIP
endpoint. Instead the SD manipulates SIP registration requests and responses to spoof the endpoint — generating
frequent and extraneous registration requests that generate a periodic traffic flow to maintain existing NAT bindings.
Unlike the current SD-centric method, the new methods require the active participation of the SIP endpoint. With
these methods the SIP endpoint initiates a Keep-Alive negotiation with the SD that produces a periodic request/
response message sequence which also generates sufficient traffic flow to maintain NAT bindings.
The new methods are based upon the following RFCs.
RFC 5626, Managing Client-Initiated Connections in the Session Initiation Protocol (SIP), which, in Section 3.5.2,
provides a framework for the implementation of an endpoint-initiated Keep-Alive on both TCP and UDP connections
and provides two approaches to generating endpoint-initiated Keep-Alive traffic flows. One approach described in
Section 4.4.1 of the RFC is restricted to connection-oriented transport protocols such as TCP. It defines an end-point
initiated ping which requires an SD pong in response. A second approach described in Section 4.4.2 of the RFC is
restricted to connectionless transport protocols such as UDP. It defines an endpoint-initiated STUN binding request
which requires as SD-originated STUN binding response.
RFC 6223, Indication of support for Keep-Alive, was initially published as an internet draft (most recently as draft-
ietf-sipcore-keep-12.txt). RFC 6223 defines a procedure that enables a SIP endpoint to signal its capability and
willingness to send and receive periodic Keep-Alive messages to a device referred to by the RFC as an edge proxy, a
role performed by the SD. After receiving such a signal, the SD returns a response indicating its willingness to
exchange Keep-Alives, and specifying the interval between Keep-Alive exchanges.
RFC 5389, Session Traversal Utilities for NAT (STUN), defines STUN binding requests and responses in Section 6 of
the RFC. Endpoints that support endpoint-initiated Keep-Alives over a UDP connection must be capable of
constructing and transmitting a STUN binding request, and receiving and parsing a STUN binding response.
The SD indicates its willingness to exchange Keep-Alives by assigning a value, which specifies the interval between
Keep-Alives, to the keep parameter and re-inserting the parameter and its assigned value into the Via header of the
REGISTER response.
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.101.38:5070;branch=dd1;keep=20
From: "512" <sip:512@172.16.101.38:5070;transport=UDP>;tag=443322
To: "512" <sip:512@172.16.101.38:5070>;tag=b68b3d53a5a90225609112ff6c211bef.
16a6
Call-ID: 1-14400@172.16.101.38
CSeq: 1 REGISTER
Contact: <sip:512@172.16.101.38:5070>;expires=3600
Server: OpenSER (1.3.0-notls (i386/linux))
Content-Length: 0
Connectionless Keep-Alives
After the endpoint-initiated Keep-Alive exchange has been negotiated for an unreliable UDP connection, the SIP
endpoint, acting as a STUN client, transmits a periodic STUN binding request so that the interval between each
request is randomly distributed between 80 and 100 percent of the value of the keep parameter. Assuming a parameter
value of 20 seconds, for example, the SIP endpoint transmits a STUN binding request at random intervals between 16
and 20 seconds in length.
The STUN binding request has the following format.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0| STUN Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Transaction ID (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The initial two bits of any STUN message are always 00
STUN Message Type
This 14-bit field contains the message class and method — for a STUN binding request, class is request and method is
binding.
Message Length
This 16-bit field contains the length, in octets, of the Attribute section of the STUN binding request. Since the
Attribute section is not present in a binding request, this field contains a value of 0.
Magic Cookie
This 16-bit field always contains a value of 0x2112A442.
Transaction ID
This 96-bit field contains a random value that provides a transaction identifier. The value is generated by the STUN
client and echoed in the STUN server response.
Upon receipt of a binding request, the SD, acting as a STUN server, transmits a STUN binding response. Receipt of
the binding response by the endpoint confirms the UDP connection between the endpoint and the SD, and the
viability of NAT bindings in the transmission path.
The STUN binding response has the following format.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0| STUN Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Transaction ID (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Mapped Address |
| |
|---------------------------------------------------------------
The initial two bits of any STUN message are always 00.
STUN Message Type
This 14-bit field contains the message class and method — for a STUN binding response, class is response and
method is binding.
Message Length
This 16-bit field contains the length, in octets, of the Attribute section of the STUN binding response. Since the
binding response contains a single attribute, MAPPED-ADDRESS, the message length can be either 8 or 16 octets,
depending on the IP address type.
Magic Cookie
This 16-bit field always contains a value of 0x2112A442.
Transaction ID
This 96-bit field contains a random value that provides a transaction identifier. The value is generated by the STUN
client and echoed by the STUN server.
MAPPED-ADDRESS
This attribute contains the IP address and port number of the proximate NAT device, that is the address translator
closest to the SD, that forwarded the STUN request toward the SD. Specific fields within the attribute identify the IP
family (Version 4 or 6), the IP address, and port number. The attribute length is 8 octets if it contains an IPv4 address,
or 16 octets if it contains an IPv6 address.
Once initiated, endpoint transmission of STUN binding requests and SD responses continue for the duration of the
SIP Registration, 1 hour in the sample negotiation, or until the endpoint transmits a new REGISTER request. In the
event of such a new request, the endpoint once again indicates its willingness to exchange STUN Keep-Alives with an
unvalued keep parameter in the Via header. If endpoint-initiated Keep-Alive renegotiation is not successful, the
endpoint must cease the transmission of Keep-Alive messages.
An endpoint failure to issue a timely STUN binding request is not fatal. In the absence of an expected request, the SD
takes no action with regard to the UDP connection, or to current calls, nor does it remove entries from its registration
cache. After reception of a tardy STUN request, the SD simply returns a STUN response.
In contrast, however, Section 4.4.2 of RFC 5626 states that an endpoint “considers the flow failed” if (1) it receives a
malformed STUN bonding response from the SD, or (2) it fails to receive a timely binding response from the SD. If
the endpoint receives a STUN binding response that contains a different MAP Address field from the previous
response, It MUST treat this event as a failure on the flow.
Statistics
The SD does not gather or maintain endpoint-initiated Keep-Alive statistical counts. However, malformed STUN
binding requests and responses are included in the count of mal-formed SIP messages. Additionally, if DoS is
enabled, STUN binding exchanges are included in endpoint message counts.
3. Type sip-interface and press Enter. If you are adding this feature to a pre-existing configuration, you will
need to select and edit it.
ORACLE(session-router)# sip-interface
ORACLE(sip-interface)#
4. tcp-conn-dereg—The delay (in seconds) that is used to determine when to terminate the TCP connection for
a user that has been removed from the registration cache or changed location. This feature can be disable by
setting the value to zero.
ORACLE(session-agent)# tcp-conn-dereg 5300
5. Save your work.
process-implicit-tel-URI Configuration
To enable proccess-implicit-tel-URI
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.
ORACLE(session-router)# sip-config
ORACLE(sip-config)#
4. options—Set the options parameter by typing options, a Space, the option-name proccess-implicit-
tel-URI with a plus sign in front of it, and then press Enter.
ORACLE(sip-config)# options +proccess-implicit-tel-URI
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.
• Preserving resource utilization for the SBC and the softswitch by deleting a contact binding that is no longer valid
or needed
• Preventing extra bindings from being generated at the softswitch (e.g., in instances when the UA or NAT restart)
This feature applies to:
• HNT endpoints with registration caching enabled by default, and when the nat-traversal parameter in the
SIP interface configuration is set to always
• non-HNT endpoints with registration caching enabled, when the registration-interval parameter in the SIP
interface configuration is used in the expires header sent to the UA in the 200 OK
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
4. Use the ACLI select command so that you can work with the SIP configuration.
ORACLE(sip-config)# select
5. options—Set the options parameter by typing options, a Space, the option name force-
unregistration, and then press Enter.
ORACLE(sip-config)# options +force-unregistration
If you type options force-unregistration, you will overwrite any previously
configured options. In order to append the new option to the sip-config’s
options list, you must prepend the new option with a plus sign as shown in
the previous example.
Adaptive HNT
This section explains how to configure adaptive HNT. The adaptive HNT expires feature allows the Oracle
Communications Session Border Controller to automatically determine the maximum SIP REGISTER message
expires time interval in order to keep each individual NAT pinhole open when performing SIP HNT. This feature
applies only to SIP over UDP.
Overview
Without adaptive HNT, the Oracle Communications Session Border Controller keeps NAT pinholes open and port
mapping cached by forcing the UAC to send frequent SIP REGISTER messages. It does so by setting the expires time
to a short interval. Some NATs only need a message to be sent by the private client once every twenty minutes, while
other NATs delete their cache/pinhole in thirty seconds if no messages appear. Given this large variation in time
intervals, the Oracle Communications Session Border Controller’s nat-interval (expire time) has been set to a low
value in order to support as many NAT types as possible. However, CPU performance and scalability issues result
from such a small refresh time, especially when there is a very large number of potential registered users.
When you use adaptive HNT, the Oracle Communications Session Border Controller waits for a time interval and
then sends a SIP OPTIONS message to the UAC to see if it can still be reached. If the UAC can still be reached, the
Oracle Communications Session Border Controller increases the timer and tries again. In case the pinhole closes
because it has exceeded the NAT's cache time, the Oracle Communications Session Border Controller sets the expires
time to be slightly longer than the time it tests using the OPTIONS method. This way, the UAC will send another
REGISTER message shortly thereafter and impact on service will be minimal.
receives another REGISTER, it responds with the previously successful timer value (in this case, the minimum NAT
interval).
However, if the OPTIONS request succeeds, then the Oracle Communications Session Border Controller persists with
the test until it fails or until the maximum NAT timer value is reached. In this case, when the OPTIONS message
fails, the Oracle Communications Session Border Controller uses the last successful test-timer value as the time for
the expires header in the 200 OK for the REGISTER message.
Overview
You establish SIP server redundancy by creating session agents, which are virtual representations of the SIP signaling
entities. These agents are then collected into a session agent group, which is a logical collection of two or more
session agents that behaves as a single aggregate entity.
Rather than direct signaling messages to a single session agent (IP), the signaling message is directed to a session
agent group (SAG). The group will have a set distribution pattern: hunt, round robin, proportionally distributed, and
so on. Signaling is spread amongst the agents using this chosen pattern.
You direct the signaling message by configuring a route policy, known as a local policy, which determines where SIP
REQUESTS should be routed and/or forwarded. The values in the To and From headers in the SIP REQUEST are
matched with the content of the local policy within the constraints set by the session agent’s previous hop value and
SIP interface values such as the list of carriers.
To summarize, you need:
• two or more session agents
• a session group containg those session agents
• a local policy which directs traffic to the session agent group
Configuration Overview
You make a session agent group a target by using a local policy to select the next hop from the members of a session
agent group. You need to set the replace URI field of the configured local policy to enabled; which causes NAT rules
such as realm prefixing to be overridden. The replace URI field allows you to indicate whether the local policy’s
value is used to replace the Request-URI in outgoing requests. This boolean field can be set to either enabled or
disabled.
When the SIP NAT’s route home proxy field is set to forced, it forces the Request to be forwarded to the home proxy
without using a local policy. When this option is set to either disabled or enabled and the Request-URI matches the
external address of the SIP NAT, the local policy is used.
However, the local policy only replaces the Request-URI when the original Request-URI matches the SBC’s IP
address or hostname. This behavior is in accordance with that described in RFC 3261. The original Request-URI will
be the home proxy address value (the home address of the SIP NAT into the backbone) and not the Oracle
Communications Session Border Controller (SBC) address.
Using strict routing, the Request-URI would be the next hop, but the message would also include a Route header with
the original Request-URI. With loose routing, the Request-URI remains unchanged and the next hop value is added as
the top Route header.
Sometimes the next hop field value must replace the Request-URI in the outgoing request, even if the original
Request-URI is not the SBCC. To accomplish this, an option has been added to the local policy that causes the next
hop value to be used as the Request-URI and prevents the addition of Route headers. This option is the replace uri
value in the local policy.
The following table lists the policy attributes for the local policy:
Parameter Description
next hop IP address of your internal SIP proxy. This value corresponds to the IP
address of the network interface associated with the SIP proxy.
realm Number of the port associated with the SIP port.
replace uri Stores the transport protocol used for sending an receiving signaling
messages associated with the SIP port.
allow anonymous Indicates whether this SIP port allows anonymous connections from
session agents.
Note: You should also define the ping method intervals for the session agents so that the SBC can detect
when the agents are back in service after failure.
offline. Session agents can come back online once they send 200 OK messages the Oracle Communications Session
Border Controller receives successfully.
Without using the manual trigger, session agents can go offline because of they do not respond to pings or because of
excessive transaction timeouts. However, you might not want to use these more dynamic methods of taking session
agents out of service (and subsequently invalidating any associated registrations). You can disable both of these
mechanisms by setting the following parameters to 0:
• ping-interval—Frequency (amount of time in seconds) with which the Oracle Communications Session
Border Controller pings the entity the session agent represents)
• ttr-no-response—Dictates when the SA (Session Agent) should be put back in service after the SA is taken
OOS (Out Of Service) because it did not respond to the Oracle Communications Session Border Controller
However, you can still use the new SIP manual trigger even with these dynamic methods enabled; the trigger simply
overrides the configuration to send the session agent offline.
Invalidate Registrations
An existing feature called invalidate-registrations located in the session agent keeps track of when
surrogate agents go out of service. When REGISTER messages are received, registration entries that had out-of-
service session agents since the last REGISTER will always allow the message through to the registrar (as opposed to
responding directly from the cache).
The invalidate-registrations parameter in session agent configuration enables the Oracle
Communications Session Border Controller to detect failed Registrar session agents.
If invalidate-registrations is enabled for the session agent, a response from a surrogate REGISTER that contains a
service-route header that corresponds to a session-agent is installed to the registration cache entry.
The surrogate-agents are scanned. Surrogate agents with registration entries matching the out-of-service registrar have
their timer reset to initiate a refresh. For an immediate refresh, the registration entry will only be considered when the
service-route session agent goes out-of-service. The service-route session agent takes precedence and any previous
registrar session agent w ill not be considered for an immediate refresh of the surrogate-agent registration.
Performance Impact
In cases with a large number of surrogate-agent registrations, there may be an impact to CPU usage when a session-
agent goes out-of-service. All of the surrogate-agent registrations are scanned at that time. Refresh registrations are
then sent out on timers.
The Oracle Communications Session Border Controller only performs this procedure on messages encoded with types
for which it is configured and that are properly formed. Examples of when the Oracle Communications Session
Border Controller does not perform this procedure include:
• The Oracle Communications Session Border Controller receives a message with an encoded multipart message
block, but proxy-content-type-encodings list is empty. In this case, the Oracle Communications Session Border
Controller responds with a 415 Unsupported Media Type.
• The message arrives with a multipart message body with encoding for which the proxy-content-type-encodings
is configured, but there is no terminating boundary. In this case, the Oracle Communications Session Border
Controller replies with a 400 Invalid Body error.
• The Oracle Communications Session Border Controller receives a response with an encoded multipart message
block, but proxy-content-type-encodings list is empty. In this case, the Oracle Communications Session Border
Controller simple drops the response.
Overview
The SIP DMR feature lets RTP/RTCP media be sent directly between SIP endpoints (for example, SIP phones or user
agents) without going through a Oracle Communications Session Border Controller; even if the SIP signaling
messages traverse multiple Oracle Communications Session Border Controllers. It encodes IPv4 address and port
information for the media streams described by the media, for example SDP.
With SIP DMR, the media realm and IPv4 address and port information from the UA's SDP is encoded into SIP
messages (either in the SIP header or in the SDP) as they enter the backbone network. The information is decoded by
a Oracle Communications Session Border Controller from SIP messages that come from the backbone network. The
decoded address and port information is put into the SDP sent the UAs in the access (private/customer) network.
This functionality lets the RTP/RTCP flow directly between the UAs in the access network without traversing the
Oracle Communications Session Border Controllers and without passing into the backbone network. The media can
then flow directly between the two SIP endpoints in the same network, if it is serviced by multiple Oracle
Communications Session Border Controllers.
You can enable this feature on a per-realm basis and multiple realms can be supported.
Endpoint Locations
You can configure the Oracle Communications Session Border Controller to release media when the source and
destination of the call are in the same network, customer VPN, or customer LAN. In architectures that use DMR, the
Oracle Communications Session Border Controller is only part of the media path for traffic that originates and
terminates in different networks.
If configured to do so, the Oracle Communications Session Border Controller can release media:
• Between endpoints supported by a single Oracle Communications Session Border Controller
In the same network/VPN
In the same network behind the same NAT/firewall
• Between endpoints supported by multiple distributed Oracle Communications Session Border Controllers
In the same network/VPN
As shown in the network diagram, UA A and UA B register with the softswitch through Oracle Communications
Session Border Controller A while UA C and UA D register with the softswitch through Oracle Communications
Session Border Controller B. Without DMR, the media for calls between UA A/UA B and UA C/UA D is steered
through both Oracle Communications Session Border Controller A and Oracle Communications Session Border
Controller B.
With SIP DMR, the media realm and IPv4 address and port information from the UA's Session Description Protocol
(SDP) is encoded into SIP messages (either in the SIP header or in the SDP) as they enter the backbone (public/
service provider) network. The information is decoded from SIP messages that come from the backbone network. The
decoded address and port information is put into the SDP sent to the UAs in the access (private/customer) network.
This functionality allows for the RTP/RTCP to flow directly between the UAs in the access network without
traversing the Oracle Communications Session Border Controllers and without passing into the backbone network.
Note: You can also use the realm config element’s mm in network field to release the media back to a
connected network that has multiple realms. This field is not specific SIP distributed media release and it
is not required for the SIP DMR to work. However, if this field is set to enabled and the ingress and egress
realms are part of the same network interface, it lets the Oracle Communications Session Border
Controller release the media.
Add-On Conferencing
This section explains how to configure the add-on conferencing functionality. It also includes a description of the SIP
B2BUA functionality related to the SIP add-on conferencing. This description includes information about Contact
header mapping and processing and Refer-to header processing.
Overview
SIP add-on conferencing lets you:
• Use the Oracle Communications Session Border Controller’s add-on conferencing feature for network
architectures in which the conference initiator is located on a different network than that of the media server.
• Configure the Oracle Communications Session Border Controller to enable Contact header mapping for the Refer-
To header.
Caveats
The following caveats are associated with add-on conferencing:
• Contact header mapping is not replicated on the standby Oracle Communications Session Border Controller in an
HA Oracle Communications Session Border Controller pair architecture.
• Upon switchover, any conferences in progress remain in progress, but no new parties can be invited to or join the
conference.
• By default, the Oracle Communications Session Border Controller does not map SIP Contact headers for reasons
of performance.
The Oracle Communications Session Border Controller add-on conferencing feature applies to situations when the
Contact URI is used in another dialog. In such a case, the SIP B2BUA will not be able to find the correct dialog that
retrieves the correct Contact URI of the other leg if it needs to replace the Contact URI.
Using the SIP add-on conferencing, the SIP B2BUA on the Oracle Communications Session Border Controller can
map the Contact headers it receives to the Contact headers it creates. It can also convert the Refer-To URI to the
correct value required for forwarding the REFER request.
If the user part of the Refer-To URI contains the refer to URI prefix but a matched URI cannot be found, the SIP
B2BUA will leave the existing Refer-To URI unchanged and will write a WARNING level log message to record
the failure.
• REFER method transfer from different sources within the destination realm
• The REFER event package as defined in RFC 3515. This applies for situations where multiple REFER methods
are used within a single dialog.
• Third party initiated REFER method signalling the transfer of a call by associating the REFER method to the
dialogue via the REFER TargetDialog.
• The Referred-To party can be both in a different realm (and thus a different steering pool) from the referrer, and in
the same realm
• The associated latching should not prohibit the Referred-To party from being latched to while the referee is still
sending media.
Call Flows
The following is an example call flow for an unattended call transfer:
Supported Scenarios
In the basic scenario for REFER initiated call transfer, a call is established between two User Agents (Alice and Bob).
User Agent Bob then sends a REFER request to transfer the call to a third User Agent Eva. With dynamic call-
transfer enabled, the Oracle Communications Session Border Controller (SBC) prevents the REFER from being sent
to Alice and generates the INVITE to Eva.
If the INVITE to Eva succeeds, the SBC sends a re-INVITE to Alice modifying the SIP session as described in
Section 14 of RFC 3261, SIP: Session Initiation Protocol. At this point the SBC cancels the original dialog between
the SBC and Bob.
If the INVITE to Eva fails, call disposition depends on whether or not Bob issued a BYE after the REFER call
transfer. If the Oracle Communications Session Border Controller did receive a BYE from Bob (for instance, a blind
transfer), it proxies the BYE to A. Otherwise, the SBC retains the original SIP session and media session, thus
allowing Bob to re-establish the call with Alice by sending a re-INVITE. In this case, the SBC sets a timer (32
seconds), after which a BYE will be sent.
If a REFER method is received containing no Referred-By header, the SBC adds one, allowing the SBC to support all
call agent screen applications.
In addition, the SIP REFER method call transfer feature supports the following:
• Both unattended and attended call transfers
• Both successful and unsuccessful call transfers
• Early media from the Referred-To party to the transferee
• REFER method transfer from different sources within the destination realm
• The REFER event package as defined in RFC 3515. This applies for situations where multiple REFER methods
are used within a single dialog.
• Third party initiated REFER method signalling the transfer of a call by associating the REFER method to the
dialogue via the REFER TargetDialog.
• The Referred-To party can be both in a different realm (and thus a different steering pool) from the referrer, and in
the same realm
• The associated latching should not prohibit the Referred-To party from being latched to while the referee is still
sending media.
The SBC does not successfully handle the following anomalous transfer scenarios:
• The new INVITE to the Referred-To party gets challenged — the SBC does not answer the challenge. It is treated
with the 401/407 response just as any other unsuccessful final response.
• The header of the REFER message contains a method other than INVITE or contains URI-parameters or
embedded headers not supported by the SBC.
• The SBC shall allow the Referred-To URI that happens to resolve to the same next-hop as the original INVITE
went to, to do so.
• The SBC ignores any MIME attachment(s) within a REFER method.
• The SBC recurses (when configured to do so) when the new INVITE sent to the Referred-To party receives a 3xx
response.
• The transferee indicated support for 100rel, and the original two parties agreed on using it, yet the Referred-To
party does not support it.
• The original parties negotiated SRTP keys.
Call Flows
The following is an example call flow for an unattended call transfer:
INVITE INVITE
302
ACK
INVITE
Request route call
180 180 Ringing
media media
REFER
202 Accepted
INVITE
10 seconds pass
180 Ringing
Timeout error Ringing
Answer
200 OK
200 OK
INVITE
100 Trying
200 OK
media media
BYE BYE
200 OK 200 OK
When you compare the call flow above to the one depicting the scenario when the Oracle Communications Session
Border Controller has the refer-notify-provisional changed from its default, you can see that the Oracle
Communications Session Border Controller now response with a NOTIFY in response to the 202 Accepted and it
sends another after the 180 Ringing.This causes the event to be diverted successfully.
INVITE INVITE
302
ACK
INVITE
200 OK 200 OK
Request route call
ACK ACK
media media
REFER
202 Accepted
INVITE
INVITE
180 Ringing
INVITE
200 OK
BYE
200 OK Event route used;
100 Trying event diverted
200 OK
media media
200 OK 200 OK
200 OK
Sample Messages
In compliance with RFC 5589, the NOTIFY message with 100 Trying as the message body looks like the sample
below. Note that the expires value in the subscription state header is populated with a value that equals 2* TIMER C,
where the default value of TIMER C is 180000 milliseconds.
NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=1928301774
From: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>;tag=a6c85cf
Call-ID: a84b4c76e66710
CSeq: 73 NOTIFY
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, tdialog
Event: refer
Subscription-State: active;expires=360
Content-Type: message/sipfrag
Scenario
In a call transfer initiated by SIP REFER, a call is established between two user agents, UA-A and UA-B. UA-B then
sends a REFER request to transfer the call to UA-C. The challenge is that UA-A and UA-B had already been
communicating using mutually agreed-on codec, while UA-C might not be using an entirely different codec.
To solve this problem, the Oracle Communications Session Border Controller causes a new SIP session and new
media session to be created between UA-A and UA-C. The Oracle Communications Session Border Controller
removes any resources allocated for use between UA-A and UA-B, and then severs its connection with UA-B. The
session between UA-A and UA-C continues.
Implementation Details
This section describes the details of how the Oracle Communications Session Border Controller behaves in SIP
REFER scenarios with the changes made in Oracle Communications Session Border Controller Release S-
C(X)6.1.0M2. The Oracle Communications Session Border Controller makes the new call between Party A and Party
C appear as though A were participating to allow the Oracle Communications Session Border Controller’s natural
media setup occur in the same way as if the REFER had actually been sent to A and A had sent a new INVITE.
When the Oracle Communications Session Border Controller receives a REFER request and determines it needs to
handle it locally, it creates a new INVITE made to look like one from Party A. And the Oracle Communications
Session Border Controller actually processes this INVITE as though it were from Party A. As a result, new SIP and
new media sessions are created with new media ports for Parties A and C. When the INVITE to Party C receives a
final response, the Oracle Communications Session Border Controller sends the result to Party B using a SIP
NOTIFY request.
If the new INVITE succeeds, the old context and flows disappear and the new context and flows for the A-to-C
connection remain in place. Because of the new media ports, the Oracle Communications Session Border Controller
sends a re-INVITE to Party A, directing media to the new port and forwarded to Party C. Next, the original dialog
with Party B needs to be terminated; if the Oracle Communications Session Border Controller has not received Party
B’s BYE, it will wait five second and then send Party B a BYE.
If the INVITE to Party C fails, the new SIP and media sessions are deleted as are the new context and flows. The
Oracle Communications Session Border Controller treats Party A differently depending on whether or not a BYE was
received from Party B. If a BYE was received from Party B. then the Oracle Communications Session Border
Controller sends a BYE to Party A. If not, the original SIP and media sessions as well as the context and media flows
remain in tact. This way, Party B can re-establish the call with Party A using a re-INVITE. In the case, the Oracle
Communications Session Border Controller waits 32 second before sending a BYE.
If the Oracle Communications Session Border Controller receives a BYE while processing the INVITE to Party C, it
sends a CANCEL message to Party C in an attempt to cancel the call. The BYE passes to Party B, and associated
sessions, contexts, and flows terminate normally. Still, the Oracle Communications Session Border Controller waits
for the final response to the INVITE to Party C. If the Oracle Communications Session Border Controller receives a
successful response, it sends an ACK and then a BYE to terminate the abandoned call. If the Oracle Communications
Session Border Controller receives an unsuccessful final response, it uses its normal response error handling
processes. In either of these last two cases, all sessions, context, and flow are deleted.
Please note that the Oracle Communications Session Border Controller does not remove the a=sendonly attribute
from the SDP it sends to Party A during the A-to-B call, and extra media ports are not allocated for the original media
session.
SIP REFER-to-BYE
The Oracle Communications Session Border Controller’s SIP REFER-to-BYE capability addresses situations when
other network elements do not support the REFER method but do offer blind transfer in a SIP BYE request. The
target number is encoded in a Reason header of the BYE request. In such cases, the Oracle Communications Session
Border Controller terminates the REFER and passes the Refer-To number in a Reason header of the BYE.
You configure both SIP interfaces and SIP session agents with the refer-to-bye option to use this function:
• SIP interface—You add this ability to SIP interfaces facing the SIP elements that need to receive a BYE instead of
a REFER. This setting only applies when the next hop is not a session agent.
• SIP session agent—The SIP session agent takes precedence over the SIP interface. You add this ability to SIP
session agents that need to receive a BYE instead of a REFER. If the next hop SIP element—the remote target in
the dialog—is a session agent, in other words, you need to configure the option for it. Note that when you use this
option for SIP session agents, the SIP interface or realm on which the REFER is received takes precedence over
the REFER-to-BYE capability.
When a REFER request arrives and the REFER-to-BYE capability applies, the Oracle Communications Session
Border Controller responds to it with a 202 Accepted and sends a NOTIFY to terminate the implicit refer
subscription. This NOTIFY contains a message/sipfrag body with SIP/2.0 200 OK. Upon receiving the response to
this NOTIFY, the Oracle Communications Session Border Controller sends a BYE with an added Reason header
(encoded with the Refer-To number) to the other end.
The network element that does not accept REFERs takes the BYE with the Reason header and issues a new initial
INVITE that initiates transfer, which the Oracle Communications Session Border Controller sees as starting a new
and independent session.
SIP Roaming
This section explains how to configure SIP roaming. SIP roaming lets subscribers move from one active SIP device to
another (at the same site or multiple sites) and retain service at the last registering device.
Overview
The Oracle Communications Session Border Controller supports multiple active registrations for the same user. The
softswitch makes decisions regarding the current location of the user and the handling of requests from devices that
are not currently identified as the user location. When there are multiple NATs, the Oracle Communications Session
Border Controller is still required to let the softswitch be able to differentiate it.
The Oracle Communications Session Border Controller’s SIP roaming ability supports the following features:
• Multiple active registrations from the same user can be cached, allowing subscribers to move from one active SIP
device to another (at the same site or multiple sites) and still retain service at the last registering device. With the
SIP roaming feature, one person, using multiple devices, can be contacted at all of the devices. These multiple
devices (with their unique contact information) register to indicate that they are available for anyone that wants to
contact that one person.
• The Oracle Communications Session Border Controller can also inform network devices (such as softswitches) of
private SIP device IPv4 addresses (endpoints) and the public firewall address of the user location.
Process Overview
Caller 1 wants to contact Person A. Caller 1 sends a message to persona@acmepacket.com, but Person A has
configured more than one SIP-enabled device to accept messages sent to that address. These devices have unique
addresses of desk@10.0.0.4 and phone2@10.0.0.5. Person A has desk@10.0.0.4 and phone2@10.0.0.5 registered
with the Oracle Communications Session Border Controller for anything addressed to persona@acmepacket.com.
With the SIP roaming feature, the Oracle Communications Session Border Controller accepts and stores both
registrations for persona@acmepacket.com. That way, when someone wants to get in touch with Person A, the
messages are sent to both devices (desk@10.0.0.4 and phone2@10.0.0.5) until Person A answers one of them. You do
not need to configure your Oracle Communications Session Border Controller for this functionality; your Oracle
Communications Session Border Controller automatically provides it.
From this point, you can configure SIP config parameters. To view all SIP config parameters, enter a ? at the
system prompt.
4. Type options followed by a Space.
5. After the Space, type the information for an endpoint or a firewall, or both:
contact-endpoint=”<label>
contact-firewall=”<label>
"contact-endpoint="<label>",contact-firewall="<label>""
6. Press Enter.
For example, if you want your Oracle Communications Session Border Controller to add private endpoint and
public firewall information to Contact headers, and you want to label this information as ep and fw, you would
enter the following information in the ACLI.
ORACLE(configure)# session-router
ORACLE(session-router)# sip-config
ORACLE(sip-config)# options "contact-endpoint="ep",contact-firewall="fw""
ll sB
Ca
r
se
R -U
FE to Call Center
RE ser-
:U B - Referrer
-To
f er
Re
Calls B
Tran
sfer
INV to C
Use IT
r-to E
-Use
Calling Party r
A - Source
SBC
Agent
C - Destination
Refer-To Header
The Oracle Communications Session Border Controller supports the format of User-to-User in the "Refer-To" header
in the REFER message. The following example shows the new text after the IP address and port in the second to last
line.
REFER sip:7325550000@192.168.28.10:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.29.1:5060;branch=z9hG4bK-10659-1-4
From: 7325550000 <sip:7325550000@192.168.29.1:5060>;tag=1
To: 7321110000 <sip:732111000@192.168.28.19:5060>;tag=1
Call-ID: 1-10679@192.168.28.1
...
Refer-To: <sip:9785550000@192.168.29.1:6062?User-to-
User=56a390f3d2b7310023a%3Bencoding%3Dhex%3Bpurpose%3Disdn-
interwork%3Bcontent%3Disdn-uui
Content-Length:0
v=0
o=user153655765 2353687637 IN IP$ 192.168.28.1
s=-
c=IN IP4 192.168.28.1
t= 0 0
m=audio 8000 RTP/AVP 8
a=rtpmap 8 PCMA/8000
selection: 1
ORACLE(realm-config)#
3. options—Set the options parameter by typing options, a space, disable-refer-to-uui=yes. You may prepend the
option name with a plus to add and not replace this option to the existing realm-config option list.
ORACLE#options +disable-refer-to-uui=yes
4. Type done to save your configuration.
action—Enter the action you want applied to the header specified in the name parameter. The default value is
none. Valid options are:
• add—Add a new header, if that header does not already exist.
• delete—Delete the header, if it exists.
• manipulate—Elements of this header will be manipulated according to the element rules configured.
• store—Store the header.
• none—No action to be taken.
match-value—Enter the value to be matched (only an exact match is supported) with a header value. The
action you specify is only performed if the header value matches.
msg-type—Enter the message type to which this header rule applies. The default value is any. Valid options
are:
• any—Both Requests and Reply messages
• request—Request messages only
• reply—Reply messages only
Type show to display the header rule configuration values.
6. element-rules—Define the element rules you want to use to be performed on the elements of the header
specified by the header rule.
Type element-rules and press Enter.
ORACLE(sip-header-rules)# element-rules
ORACLE(sip-element-rules)#
name—Enter the name of the element to which this rule applies.
Note: The name parameter usage depends on the element type you enter in step 6. For uri-param, uri-user-
param, and header-param it is the parameter name to be added, replaced, or deleted. For all other types, it
serves to identify the element rule and any name can be used.
type—Enter the type of element on which to perform the action. The default value is none. Valid options are:
• header-value—Enter value of the header.
• header-param-name—Header parameter name.
• header-param—Parameter portion of the header.
• uri-display—Display of the SIP URI.
• uri-user—User portion of the SIP URI.
• uri-host—Host portion of the SIP URI.
• uri-port—Port number portion of the SIP URI.
• uri-param-name—Name of the SIP URI param.
• uri-param—Parameter included in the SIP URI.
• uri-header-name—SIP URI header name
• uri-header—Header included in a request constructed from the URI.
• uri-user-param—User parameter of the SIP URI.
action—Enter the action you want applied to the element specified in the name parameter, if there is a match
value. The default value is none. Valid options are:
• none—No action is taken.
• add—Add a new element, if it does not already exist.
• replace—Replace the elements.
• delete-element—Delete the specified element if it exists. Based on the match value if entered in step 6f.
• delete-header—Delete the specified header, if it exists.
• store—Store the elements.
match-val-type—Enter the type of value that needs to be matched to the match-field entry for the action to be
performed. The default value is ANY. Valid options are:
• IP—Element value in the SIP message must be a valid IP address to be compared to the match-value field
entry. If the match-value field is empty, any valid IP address is considered a match. If the element value is not
a valid IP address, it is not considered a match.
• FQDN—Element value in the SIP message must be a valid FQDN to be compared to the match-value field
entry. If the match-value field is empty, any valid FQDN is considered a match. If the element value is not a
valid FQDN, it is not considered a match.
• ANY—Element value in the SIP message is compared with the match-value field entry. If the match-value field
is empty, all values are considered a match.
match-value-—Enter the value you want to match against the element value for an action to be performed.
new-value-—Enter the value for a new element or to replace a value for an existing element. You can enter an
expression that includes a combination of absolute values, pre-defined parameters, and operators.
• Absolute values, with which you can use double quotes for clarity. You must escape all double quotes and back
slashes that are part of an absolute value, and enclose the absolute value in double quotes.
For example:
sip:”+$TRUNK_GROUP+”.$TRUNK_GROUP_CONTEXT
• Pre-defined parameters always start with a $. Valid pre-defined parameters are:
Parameter Description
Operator Description
For example, if the IP address of the SIP interface ($LOCAL_IP) is 10.1.2.3 and the Oracle Communications Session
Border Controller receives the following Contact header:
Contact: <sip:1234@10.4.5.6;user=phone>
The header rule is applied to strip the user parameter from the Contact header URI and add the acme parameter with
the value 10.1.2.3:
Contact: <sip:1234@10.4.5.6;acme=10.1.2.3>
Precedence
The Oracle Communications Session Border Controller applies SIP header rules in the order you have entered them.
This guards against the Oracle Communications Session Border Controller removing data that might be used in the
other header rules.
This ordering also provides you with ways to use manipulations strategically. For example, you might want to use two
rules if you want to store the values of a regular expression. The first rule would store the value of a matched regular
expression, and the second could delete the matched value.
In addition to taking note of the order in which header rules are configured, you now must also configure a given
header rule prior to referencing it. For example, you must create Rule1 with the action store for the Contact header
BEFORE you can create Rule2 which uses the stored value from the Contact header.
Note that the header instance functionality has no impact on HMR’s add action, and you cannot use this feature to
insert headers into a specific location. Headers are added to the end of the list, except that Via headers are added to
the top.
MIME Support
Using the SIP HMR feature set, you can manipulate MIME types in SIP message bodies. While you can manipulate
the body of SIP messages or a specific content type using other iterations of SIP HMR, this version gives you the
power to change the MIME attachment of a specific type within the body by using regular expressions. To achieve
this, you use the find-replace-all action type, which enables the search for a particular string and the
replacement of all matches for that type. Although you use find-replace-all to manipulate MIME attachments,
it can also be used to achieve other goals in SIP HMR.
Note that using find-replace-all might consume more system resources than other HMR types. Therefore this
powerful action type should only be used when another type cannot perform the type of manipulation you require.
match within the supplied string, the SBC substitutes the new value for that match. Yet if you want to replace a certain
portion of the regular expression and not the entire matched expression, you need to use a subgroup of expressions
and the right syntax to indicate the sub-group replacement index.
You can indicate the sub-group replacement syntax by adding the string [[:n:]] to the end of the regular expression—
where n is a number between 0 and 9. For example, given the following settings:
• action=find-replace-all
• match-value=sip:(user)@host[[:1:]]
• new-value=bob
you create a new rule to replace only the user portion of the URI that searches for the regular expression and replaces
all instances of the user subgroup with the value bob.
Taking advantage of the find-replace-all’s recursive nature, you can replace all the 0 digits in a telephone
number with 1:
• action=find-replace-all
• match-value=0
• new-value=1
So for the user portion of a URI—or for any other string—with a value 1-781-308-4400 would be replaced as
1-781-318-4411.
If you leave the new-value parameter blank for find-replace-all, the SBC replaces the matched sub-group
with an empty string—an equivalent of deleting the sub-group match. You can also replace empty sub-groups, which
is like inserting a value within the second sub-group match. For example, user()@host.com[[:1:]]with a configured
new-value _bob yields user_bob@host.com.
When you use find-replace-all, you cannot use the following parameter-type values: uri-param-
name, uri-header-name, and header-param-name. These values are unusable because the SBC only uses
case-sensitive matches for the match-value to find the parameter name within the URI. Since it can only be found by
exact match, the SBC does not support finding and replacing that parameter.
Escaped Characters
SIP HMR’s support for escaped characters allows for searches for values you would be unable to enter yourself.
Because they are necessary to MIME manipulation, support for escaped characters now includes:
• \f
• \n
• \r
• \t
• \v
manipulates in a specific part of the MIME attachment. You cannot leave this parameter blank; the Oracle
Communications Session Border Controller does not let you save the configuration if you do. When you use the
store action on a multi-part MIME attachment that has different attachment types, the Oracle Communications
Session Border Controller stores the final instance of the content-type because it does not support storing multiple
instances of element rule stored values.
In the event you do not know the specific content-type where the Oracle Communications Session Border Controller
will find the match-value, you can wildcard the parameter-name by setting with the asterisk (*) as a value.
You cannot, however, set partial content-types (i.e., application/*). So configured, the Oracle Communications
Session Border Controller loops through the MIME attachment’s content types.
You can set the additional action types listed in this table with the described result:
delete-element Removes the matched mime-type from the body. If this is the last mime-type within in
message body, the Oracle Communications Session Border Controller removes the
Content-Type header.
delete-header Removes all body content and removes the Content-Type header.
replace Performs a complete replacement of the matched mime-type with the new-value you
configure.
find-replace-all Searches the specifies mime-type’s contents and replaces all matching regular expressions
with the new-value you configure
store Stores the final instance of the content-type (if there are multi-part MIME attachments of
various attachment types)
add Not supported
MIME manipulation does not support manipulating headers in the individual MIME attachments. For example, the
Oracle Communications Session Border Controller cannot modify the Content-Type given a portion of a message
body like this one:
--boundary-1
Content-Type: application/sdp
v=0
o=use1 53655765 2353687637 IN IP4 192.168.1.60
s=-
c=IN IP4 192.168.1.60
t=0 0
m=audio 10000 RTP/AVP 8
a=rtpmap:8 PCMA/8000/1
a=sendrecv
a=ptime:20
a=maxptime:200
Syntax Description
\s Whitespace
\S Non-whitespace
\d Digits
\D Non-digits
\R Any \r, \n, \r\n
\w Word
\W Non-word
\A Beginning of buffer
\Z End of buffer
\ Any character including newline, in the event that the dot (.) is not
2. Type session-router and press Enter to access the system-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)#
4. options—Set the options parameter by typing options, a Space, the option name stripPreambleCrlf with a plus
sign.
ORACLE(sip-config)# options +stripPreambleCrlf
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 global SIP 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.
Best Practices
This section lists practices that AOracle recommends you follow for successful implementation of this feature.
• Define all storage rules first.
This recommendation is made because each subsequent header rule processes against the same SIP message, so
each additional header rules works off of the results from the application of the rule that precedes it.
In general, you want to store values from the original SIP header rather than from the iteratively changed versions.
• Implement rules at the element rule rather than the header rule level.
Header rules should only be a container for element rules.
• When you are creating rules to edit a header, add additional element rules to modify a single header rather than try
to create multiple header rules each with one element rule. That is, create multiple element rules within a header
rule rather than creating multiple header rules.
• Do not use header or element rule names that are all capital letters (i.e., $IP_ADDRESS). Capitals currently refer
to predefined rules that are used as macros, and they might conflict with a name that uses capital letters.
| bar/vertical bar/pipe Matches anything to the left or to the right; the bar
separates the alternatives. Both sides are not always
tried; if the left does not match, only then is the right
attempted. Used for alternation.
{ left brace Begins an interval range, ended with } (right brace) to
match; identifies how many times the previous
singles character or group in parentheses must repeat.
Interval ranges are entered as minimum and
maximums ({minimum,maximum}) where the
character/group must appear a minimum of times up
to the maximum. You can also use these character to
set magnitude, or exactly the number of times a
character must appear; you can set this, for example,
as the minimum value without the maximum
({minimum,}).
You can also escape the escape character itself, so that it is used as a literal string. For example, the SBC now
treats the string \+1234 as +1234.
The following are escape characters: +, -, +^, -^, &, |, \, (, ), ., $, ^, and “.
You can also use two variables, $REMOTE_PORT and $LOCAL_PORT, which resolve respectively to the far-end
and remote UDP or TCP port value.
12. new-value—When the action parameter is set to add or to manipulate, enter the new value that you want to
substitute for the entire header value. This is where you can set stored regular expression values for the SBC to
use when it adds or manipulates SIP headers.
When you configure HMR (using SIP manipulation rules, elements rules, etc.), you can now use escape characters
in the new-value parameter to support escaping Boolean and string manipulation operators..
You can also escape the escape character itself, so that it is used as a literal string. For example, the SBC now
treats the string \+1234 as +1234.
The following are escape characters: +, -, +^, -^, &, |, \, (, ), ., $, ^, and “.
You can also use two variables, $REMOTE_PORT and $LOCAL_PORT, which resolve respectively to the far-end
and remote UDP or TCP port value.
9. match-val-type—Enter the value type that you want to match when this rule is applied. The default value is
ANY. Valid values are:
• IP | FQDN | ANY
10. comparison-type—Enter the way that you want SIP headers to be compared from one of the available. This
choice dictates how the SBC processes the match rules against the SIP header parameter/element. The default is
refer-case-sensitive.
• boolean | refer-case-sensitive | refer-case-insensitive | pattern-rule
11. action—Enter the action that you want this rule to perform on the SIP header parameter/element. The default is
none. The valid rules are:
• add | replace | delete-element | delete-header | store | none
Remember that you should enter rules with the action type store before you enter rules with other types of
actions.
When you set the action type to store, the SBC always treats the match value you enter as a regular expression.
As a default, the regular expression is uses for the match value is .+ (which indicates a match value of at least
one character), unless you set a more specific regular expression match value.
12. match-value—Enter the value to match against the header value in SIP packets; the SBC matches these
against the value of the parameter/element. This is where you can enter values to match using regular expression
values, or stored pattern matches. Your entries can contain Boolean operators.
When you configure HMR (using SIP manipulation rules, elements rules, etc.), you can now use escape characters
in the match-value parameter to support escaping Boolean and string manipulation operators..
You can also escape the escape character itself, so that it is used as a literal string. For example, the SBC now
treats the string \+1234 as +1234.
The following are escape characters: +, -, +^, -^, &, |, \, (, ), ., $, ^, and “.
You can also use two variables, $REMOTE_PORT and $LOCAL_PORT, which resolve respectively to the far-end
and remote UDP or TCP port value.
13. new-value—When the action parameter is set to add or to manipulate, enter the new value that you want to
substitute for the entire header value. This is where you can set stored regular expression values for the SBC to
use when it adds or manipulates parameters/elements.
When you configure HMR (using SIP manipulation rules, elements rules, etc.), you can now use escape characters
in the new-value parameter to support escaping Boolean and string manipulation operators..
You can also escape the escape character itself, so that it is used as a literal string. For example, the SBC now
treats the string \+1234 as +1234.
The following are escape characters: +, -, +^, -^, &, |, \, (, ), ., $, ^, and “.
You can also use two variables, $REMOTE_PORT and $LOCAL_PORT, which resolve respectively to the far-end
and remote UDP or TCP port value.
Configuration Examples
This section shows you several configuration examples for HMR. This section shows the configuration for the various
rules that the Oracle Communications Session Border Controllerapplied, and sample results of the manipulation.
These examples present configurations as an entire list of fields and settings for each ruleset, nested header rules and
nested element rules. If a field does not have any operation within the set, the field is shown with the setting at the
default or blank.
So the unmodified header must be cached because for any subsequent request (as in the case of a BYE originating
from the terminator; see the diagram below) the Oracle Communications Session Border Controller might need to
restore the original value—enabling the UAC to identify the message correctly as being part of the same dialog. For
out-of-dialog requests (when the To, From, or Call-ID headers are modified) the original header will be stored in the
dialog when the msg-type out-of-dialog is used.
The Oracle Communications Session Border Controller performs the restoration of original headers outside of SIP
manipulations. That is, there are no manipulation rules to configure for restore the header to their original context.
The Oracle Communications Session Border Controller will recognize the headers have been modified, and restore
them to their original state prior to sending the message out on the wire. Restoration takes place prior to outbound
manipulations so that any outbound manipulation can those headers once they have been restored.
HMR Import-Export
Due to the complexity of SIP manipulations rules and the deep understanding of system syntax they require, it is often
difficult to configure reliable rules. This feature provides support for importing and exporting pieces of SIP
manipulation configuration in a reliable way so that they can be reused.
Exporting
The SIP manipulation configuration contains an export command. When you use it, the Oracle Communications
Session Border Controller sends the configuration you have selected to a designated file. The contents are the same
information you see when you use the ACLI show command in XML format; it includes the selected configuration
and any changes that have been made. Because you can only export one SIP manipulation configuration at a time, you
must export each one-by-one if you need more than one.
The file name can be any you selected, and would be most useful if it were to identify its contents in some way. If the
file already exists, then the export fails and informs you the file already exists. A successfully-executed export simply
returns you to the system prompt.
The system writes exported files to /code/imports, a new location that will be created to avoid overlap with existing
backup files. The files will carry the extension .gz to show that they have been compressed with gzip.
Your export data will look like this sample:
<?xml version='1.0' standalone='yes'?>
<sipManipulation
name='manip'
description=''
lastModifiedBy='admin@console'
lastModifiedDate='2009-10-16 14:16:29'>
<headerRule
headerName='Foo'
msgType='any'
name='headerRule'
action='manipulate'
cmpType='boolean'
matchValue='$REGEX("[bB][A-Za-z]{2}")'
newValue='foo'
methods='INVITE'>
</headerRule>
</sipManipulation>
To avoid conflict with other objects on the system, key and object ID are not included as part of the exported XML.
Importing
Using the import command in the SIP manipulation configuration, you can import data from an exported file to a
currently-selected configuration. If you have not selected a configuration into which to load the data, a new one will
be created. Including the .gz extension, you enter the full name of the file you want imported. After it finds the file,
the Oracle Communications Session Border Controller unarchives it and parses its contents. If these steps fail, the
Oracle Communications Session Border Controller will alert you. If they succeed, then the configuration data loads
into the object.
If you have been making changes to the configuration into which data was imported, the Oracle Communications
Session Border Controller will inform you prior to importing the data so that you will not lose any of your work. This
way, you will be less likely to overwrite unsaved changes.
Once the import is complete, it will be as if you entered the configuration by hand. You only need to save your work
(by typing done) to save the SIP manipulation to the global SIP configuration. Note that if for some reason the XML
is malformed or contained more than one object, the import will fail.
If you attempt to import a configuration with the same key as one that already exists, the system returns an error and
prevents you from saving the imported object. In this case, you can delete the object with the same key and then carry
out your import, or you can select the object with the same key and perform an import that will overwrite it with new
data.
Displaying Imports
You can display imported SIP manipulations data at the system prompt. The command lists all files in the exported
files directory, and also tells you if there are none.
Removing Files
Using the delete-import command with the name of the file you want to delete removes it from the system.
Using this command, you can delete files that are no longer useful to you. Carrying out this command is final and
there is no warning before you go ahead with the deletion. A failed deletion (for instance, because there is no such
file) will produce an error message; a successful deletion simply returns you to the system prompt.
Reject Action
When you use this action type and a condition matching the manipulation rule arises, the Oracle Communications
Session Border Controller rejects the request (though does not drop responses) and increments a counter.
• If the msg-type parameter is set to any and the message is a response, the Oracle Communications Session
Border Controller increments a counter to show the intention to reject the message—but the message will continue
to be processed.
• If the msg-type parameter is set to any and the message is a request, the Oracle Communications Session
Border Controller performs the rejection and increments the counter.
The new-value parameter is designed to supply the status code and reason phrase corresponding to the reject. You
can use the following syntax to supply this information: status-code[:reason-phrase]. You do not have to supply the
status code and reason phrase information; by default, the system uses 400:Bad Request.
If you do supply this information, then the status code must be a positive integer between 300 and 699. The Oracle
Communications Session Border Controller then provides the reason phrase corresponding to the status code. And if
there is no reason phrase, the system uses the one for the applicable reason class.
You can also customize a reason phrase. To do so, you enter the status code followed by a colon (:), being sure to
enclose the entire entry in quotation marks () if your reason code includes spaces.
When the Oracle Communications Session Border Controller performs the reject action, the current SIP
manipulation stops processing and does not act on any of the rules following the reject rule. This course of action
is true for nested SIP manipulations that might have been constructed using the sip-manip action type.
About Counters
The Oracle Communications Session Border Controller tracks messages that have been flagged for rejection using the
reject action type. In the show sipd display, refer to the Rejected Messages category; there is no distinction
between requests and responses.
ORACLE# show sipd
13:59:07-102
SIP Status -- Period -- -------- Lifetime --------
Active High Total Total PerMax High
Sessions 0 0 0 0 0 0
Subscriptions 0 0 0 0 0 0
Dialogs 0 0 0 0 0 0
SNMP Support
The Oracle Communications Session Border Controller provides SNMP support for the Rejected Messages data, so
you can access this information externally. The new MIB objects are:
apSysRejectedMessages OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of messages rejected by the SD due to matching
criteria."
::= { apSysMgmtMIBGeneralObjects 18 }
apSysMgmtRejectedMesagesThresholdExeededTrap NOTIFICATION-TYPE
OBJECTS { apSysRejectedMessages }
STATUS current
DESCRIPTION
" The trap will be generated when the number of rejected messages
exceed the configured threshold within the configured window."
::= { apSystemManagementMonitors 57 }
apSysMgmtRejectedMessagesGroup OBJECT-GROUP
OBJECTS {
apSysRejectedMessages
}
STATUS current
DESCRIPTION
"Objects to track the number of messages rejected by the SD."
::= { apSystemManagementGroups 18 }
apSysMgmtRejectedMessagesNotificationsGroup NOTIFICATION-GROUP
NOTIFICATIONS {
apSysMgmtRejectedMesagesThresholdExeededTrap
}
STATUS current
DESCRIPTION
"Traps used for notification of rejected messages"
::= { apSystemManagementNotificationsGroups 26 }
apSmgmtRejectedMessagesCap
AGENT-CAPABILITIES
PRODUCT-RELEASE "Acme Packet SD"
STATUS current
DESCRIPTION "Acme Packet Agent Capability for enterprise
system management MIB."
SUPPORTS APSYSMGMT-MIB
INCLUDES {
apSysMgmtRejectedMessagesGroup,
Log Action
When you use this action type and a condition matching the manipulation rule arises, the Oracle Communications
Session Border Controller logs information about the current message to a separate log file. This log files will be
located on the same core in which the SIP manipulation occurred. On the core where sipt runs, a logfile called
matched.log will appear when this action type is executed.
The matched.log file contains a timestamp, received and sent Oracle Communications Session Border Controller
network interface, sent or received IP address:port information, and the peer IP address:port information. It also
specifies the rule that triggered the log action in this syntax: rule-type[rule:name]. The request URI, Contact header,
To Header, and From header are also present.
----------------------------------------
Apr 17 14:17:54.526 On [0:0]192.168.1.84:5060 sent to 192.168.1.60:5060
element-rule[checkRURIPort]
INVITE sip:service@192.168.1.84:5060 SIP/2.0
From: sipp <sip:+2125551212@192.168.1.60:5060>;tag=3035SIPpTag001
To: sut <sip:service@192.168.1.84>
Contact: sip:sipp@192.168.1.60:5060
Removal of Restrictions
The following restrictions related to HMR have been removed in Release S-C6.2.0:
• The action find-replace-all now executes all element rules. Previously, no child rules were executed.
• The action sip-manip now executes existing all element rules. Previously, no child rules were executed.
• The action store now executes existing all element rules. Previously, only child rules with the store action
were executed.
• The action add now executes existing all element rules. Previously, only child rules with the add action were
executed.
All pre-existing configurations will continue to function normally. If you want to change a manipulation rule,
however, you are required to change its name if it does not follow the new format.
The ACLI verify-config command warns you if the system has loaded a configuration containing illegal
naming syntax.
Please note that the software allows you to make changes to HMRs, including configuring new functionality to
existing rules, as long as you do not change the rule name. This results in an important consideration surrounding
HMRs with hyphens in previously configured rule names.
• You can reference stored values in new value names. (Recall that stored values may be rule names.)
• You can perform subtraction in new value names.
If you use a rule names with hyphens within the REGEX of new value names, the system cannot determine whether
the hyphen is part of the rule name or is intended to invoke subtraction within the REGEX. For this reason, you need
to use great care with legacy HMR naming that includes hyphens.
As a general rule, create new rule names that follow the new rule naming guidelines if you intend to use new
functionality in those rules.
Platform Support
HMR for SDP is available on the following platforms: Acme Packet 38x0, Acme Packet 4500 and Acme Packet
4600.
SDP Manipulation
mime-sdp-rules function in a similar fashion as header-rules. They provide
• parameters used to match against specific SIP methods and/or message types
• parameters used to match and manipulate all or specified parts of an SDP offer or answer
• a means of comparing search strings or expressions against the entire SDP
sdp-session-rule
An sdp-session-rule groups all SDP descriptors, up until the first media line, into a single entity, thus allowing the
user to perform manipulation operations on a session-specific portion of the SDP.
Like the mime-sdp-rule, all match-value and new-value operations performed at this level are executed against the
entire session group as a complete string. Given the sample SDP below, if an sdp-session-rule is configured, the
match-value and new-values operate only on the designated portion.
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31
m=application 32416 udp wb
a=orient:portrait
Nested under the sdp-session-rule configuration object is an sdp-line-rule object, the object that identifies individual
descriptors within the SDP. The types of descriptors used at the sdp-session-rule level are v, o, s, i, u, e, p, c, b, t, r, z,
k, and a, the descriptors specific to the entire session description.
This level of granularity affords the user a very simple way to making subtle changes to the session portion of the
SDP. For instance, it is very common to have to change the connection line at the session level.
The add and delete actions perform no operation at the sdp-session-rule level.
sdp-media-rule
An sdp-media-rule groups all of the descriptors that are associated with a specific media-type into single entity, thus
allowing the user to perform manipulation operations on a media-specific portion of the SDP. For example, a user can
construct an sdp-media-rule to change an attribute of the audio media type.
Like a mime-sdp-rule, all match-value and new-value operations performed at this level are executed against the
entire media-group as a complete string. Given the sample SDP below, if a media-level-descriptor is configured to
operate against the application group, the match-value and new-values would operate only on designated portion.
sdp-line-rule
Unlike header-rules, sdp descriptors are not added in the order in which they are configured. Instead they are added to
the SDP adhering to the grammar defined by RFC 4566 (as is shown below).
Session description
v= (protocol version)
o= (originator and session identifier)
s= (session name)
i=* (session information)
u=* (URI of description)
e=* (email address)
p=* (phone number)
c=* (connection information -- not required if included in
all media)
b=* (zero or more bandwidth information lines)
One or more time descriptions ("t=" and "r=" lines; see
below)
z=* (time zone adjustments)
k=* (encryption key)
a=* (zero or more session attribute lines)
Zero or more media descriptions (see below)
Time description
t= (time the session is active)
r=* (zero or more repeat times)
The only validation that will occur is the prevention of adding duplicate values. In much the same way that header-
rules prevents the user from adding multiple To headers, the descriptor rule will not allow the user to add multiple
descriptors; unless multiple descriptors are allowed, as is in the case of b, t, r and a.
There exists a parameter type under the sdp-line-rule object that allows the user to specify the specific line on which
to perform the operation. For example: v, o, s, i, u, e, p, c, b, t, r, z, k, a, and m. Details on these types can be found in
RFC 4566.
For those descriptors, of which there may exist zero or more (b, t, r, and a) entries, indexing grammar may be used to
reference the specific instance of that attribute. This indexing grammar is consistent with that of header-rules for
referring to multiple headers of the same type.
Given the example SDP below:
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
r=604800 3600 0 90000
r=7d 1h 0 25h
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31
m=application 32416 udp wb
a=orient:portrait
and the following sdp-line-rule:
sdp-line-rule
name removeRepeatInterval
type r[1]
action delete
The rule removeRepeatInterval removes the second repeat interval descriptor within the SDP.
The behavior of all SDP rules follow the same behavior of all manipulation rules in that they are executed in the order
in which they are configured and that each rule executes on the resultant of the previous rule.
Each descriptor follows its own grammar and rules depending on the type specified. The values of the descriptor are
evaluated at runtime since the new-values themselves are evaluated at runtime. At this time no validation of the
grammar for each of the types is performed. The user is responsible for properly formatting each of the descriptors
according to their specifications.
For instance, the version (v) descriptor can be removed from the SDP but leaving all descriptors for that SDP, causing
the SDP to become invalid. This is consistent with the way header-rules operate, in that there is no validation for the
specific headers once they have been manipulated through HMR.
([^\\]|^)\{\$[^0-9]+[^}]*\}
The example below demonstrates using a user defined variable within a regular expression of another rule at runtime.
element-rule
name someRule
type header-value
action replace
comparison-type pattern-rule
match-value ^sip:{$rule1.$0}@(.+)$
new-value sip:bob@company.com
If the value of $rule1.$0 evaluates to alice then it will successfully match against the string sip:alice@comcast.net. An
interpolated expression can be as simple as “{$rule1.$0}” or as complex as ^sip:{rule1.$0}@{$rule2[1].$2}$. It is
not possible to interpolate a normal regular expression since the grammar will not allow the user to enter such an
expression. Only variables can be contained with the curly braces.
The resultant of interpolated expressions can be stored in user defined variables. Given the same example from above,
if the rule someRule was referenced by another rule, the value of sip:alice@comcast.net would be stored within that
rule.
Interpolation only makes a single pass at interpolation, but does so every time the Rule executes. In other words, if the
Rule is applied to the Route header, it will interpolate again for each Route header instance. What this means is that
the value within the curly braces will only be evaluated once. For instance, if the value {$someRule.$1} evaluates to
{$foobar.$2} the Oracle Communications Session Border Controller (SBC) will treat $foobar.$2 as a literal string
which it will compile as a regular expression. The SBC will not recursively attempt to evaluate $foobar.$2, even if it
was a valid user defined variable.
Interpolated regular expressions will evaluate to TRUE if an only if both the regular expression itself can be compiled
and it successfully matches against the compared string.
mime-rule
name someMimeRule
content-type application/text
action replace
comparison-type boolean
match-value $someRule & ^every good boy .*
new-value every good girl does fine
There are many cases where the user has the need to compare some value as a regular expression in conjunction with
another stored value. It is possible to perform this behavior today, however it requires an extra step in first storing the
value with the regular expression, followed by another Manipulation Rule which compares the two boolean
expressions together (e.g. $someRule & $someMimeRule).
In order to simplify the configuration of some sip-manipulations and to make them more efficient this functionality is
being added.
Unfortunately, it is not possible to just use the example as is shown above. The problem is there are many characters
that are commonly used in regular expressions that would confuse the HMR expression parser (such as $, and +).
Therefore delimiting characters need to be used to separate the regular expression from the other parts of the
expression.
To treat a regular expression as a boolean expression, it needs to be enclosed within the value
$REGEX(<expression>,<compare_string>=$ORIGINAL); where <expression> is the regular expression to be
evaluated. <compare_string> is the string to compare against the regular expression. This second argument to the
function is defaulted to $ORIGINAL which is the value of the of the specific Manipulation Rule object. It can be
overridden to be any other value the user desires.
The proper configuration for the example above to use regular expressions as boolean expressions is
mime-rule
name someMimeRule
content-type application/text
action replace
comparison-type boolean
match-value $someRule & $REGEX(“^every good boy .*”)
new-value every good girl does fine
It is also possible to use expressions as arguments to the $REGEX function. These expressions will in turn be
evaluated prior to executing the $REGEX function. A more complex example is illustrated below.
header-rule
name checkPAU
header-name request-uri
action reject
comparison-type boolean
match-value (!$REGEX($rule1[0],$FROM_USER))&
(!$REGEX($rule2[0],$PAI_USER))
msg-type request
new-value 403:Forbidden
methods INVITE,SUBSCRIBE,MESSAGE,PUBLISH,
OPTIONS, REFER
It should be noted that when using $REGEX() in a boolean expression, the result of that expression is not stored in
the user variable. The comparison-type must be set to pattern-rule in order to store the result of a regular expression.
The arguments to the $REGEX() function are interpolated by default. This is the case since the arguments themselves
must be evaluated at runtime. The following example is also valid.
mime-rule
name someMimeRule
content-type application/text
action replace
comparison-type boolean
match-value $someRule & $REGEX(“^every good
{$rule1[0].$0} .*”)
from the bottom or middle moves to the top, all rules below are shifted down up to the position of the rule that was
moved. Positions start from 1.
A valid from-index and to-index are required to be supplied as arguments to the move action. If a user enters a range
that is out of bounds for either the from-index or to-index, the ACLI will inform the user that the command failed to
execute and for what reason.
With respect to the issue of creating an invalid sip-manipulation by incorrectly ordering the manipulation rules, this
issue is handled by the Oracle Communications Session Border Controller validating the rules at configuration time
and treating them as invalid prior to runtime. This may or may not affect the outcome of the sip-manipulation as a
configured rule may not perform any operation if it refers to a rule that has yet to be executed. It is now the user’s
responsibility to reorder the remaining rules in order to make the sip-manipulation valid once again.
It is important to note that rules of a different type at the same level are all part of the same list. To clarify; header-
rules, mime-rules, mime-isup-rules and mime-sdp-rules all share the same configuration level under sip-manipulation.
When selecting a move from-index and to-index for a header-rule, one must take into consideration the location of all
other rules at the same level, since the move is relative to all rules at that level, and not relative to the particular rule
you have selected (for example, the header-rule).
Since the list of rules at any one level can be lengthy, the move command can be issued one argument at a time,
providing the user with the ability to select indices. For instance, typing move without any arguments will present the
user with the list of all the rules at that level. After selecting an appropriate index, the user is then prompted with a to-
index location based on the same list provided.
For Example:
ORACLE(sip-mime-sdp-rules)# move
select a rule to move
1: msr sdp-type=any; action=none; match-value=; msg-type=any
2: addFoo header-name=Foo; action=none; match-value=; msg-type=any
3: addBar header-name=Bar; action=none; match-value=; msg-type=any
selection: 2
destination: 1
Rule moved from position 2 to position 1
ACMEPACKET(sip-mime-sdp-rules)#
Remove SDP
sip-manipulation
name stripSdp
description remove SDP from SIP message
mime-sdp-rule
Add SDP
sip-manipulation
name addSdp
description add an entire SDP if one does
not exist
mime-sdp-rule
name addSdp
msg-type request
methods INVITE
action add
comparison-type case-sensitive
match-value
new-value “v=0\r\no=mhandley
2890844526 2890842807 IN IP4 “+$LOCAL_IP+”\r\ns=SDP Seminar\r\ni=A
Seminar on the session description protocol\r\nu=http:
//www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps\r\ne=mjh@isi.edu
(Mark Handley)\r\nc=IN IP4 “+$LOCAL_IP+”\r\nt=2873397496
2873404696\r\na=recvonly\r\nm=audio 49170 RTP/AVP 0\r\n”
Manipulate Contacts
This rule changes the contact in the SDP to the value contained in the Contact header.
sip-manipulation
name changeSdpContact
description changes the contact in the SDP to the
value of the contact header
header-rule
name storeContact
header-name Contact
action store
comparison-type pattern-rule
msg-type request
methods INVITE
Remove a Codec
This rule changes the contact in the SDP to the value contained in the Contact header.
sip-manipulation
name removeCodec
description remove G711 codec if it exists
mime-sdp-rule
name removeCodec
msg-type request
methods INVITE
action manipulate
comparison-type case-sensitive
match-value
new-value
sdp-media-rule
name removeG711
media-type audio
action manipulate
comparison-type case-sensitive
match-value
new-value
sdp-line-rule
name remove711
type m
action replace
comparison-type pattern-rule
match-value ^(audio [0-9]
{1,5} RTP.*)( [07]
\b)(.*)$
new-value $1+$3
Change Codec
sip-manipulation
name convertCodec
description changeG711toG729
mime-sdp-rule
name changeCodec
msg-type request
methods INVITE
action manipulate
comparison-type case-sensitive
match-value
new-value
sdp-media-rule
name change711to729
media-type audio
action manipulate
comparison-type case-sensitive
match-value
new-value
sdp-line-rule
name change711
type m
action replace
comparison-type pattern-rule
match-value ^(audio [0-9]{4,5}
RTP/AVP.*)( 0)(.*)$
new-value $1+” 18”+$3
sdp-line-rule
name stripAttr
type a
action delete
comparison-type pattern-rule
match-value ^rtpmap:0 PCMU/
.+$
new-value
sdp-line-rule
name addAttr
type a
action add
comparison-type boolean
match-value $change711to729.
$stripAttr
new-value rtpmap:18 G729/8000
Dialog Transparency
This section explains how to configure dialog transparency, which prevents the Oracle Communications Session
Border Controller from generating a unique Call-ID and modifying dialog tags.
Overview
With dialog transparency enabled, the Oracle Communications Session Border Controller is prevented from
generating a unique Call-ID and from modifying the dialog tags; the Oracle Communications Session Border
Controller passes what it receives. Therefore, when a call made on one Oracle Communications Session Border
Controller is transferred to another UA and crosses a second Oracle Communications Session Border Controller, the
second Oracle Communications Session Border Controller does not note the context of the original dialog, and the
original call identifiers are preserved end to end. The signalling presented to each endpoint remains in the appropriate
context regardless of how many times a call crosses through a Oracle Communications Session Border Controller or
how many Oracle Communications Session Border Controllers a call crosses.
Without dialog transparency enabled, the Oracle Communications Session Border Controller’s SIP B2BUA rewrites
the Call-ID header and inserted dialog cookies into the From and To tags of all messages it processes. These dialog
cookies are in the following format: SDxxxxxNN-. Using these cookies, the Oracle Communications Session Border
Controller can recognize the direction of a dialog. However, this behavior makes call transfers problematic because
one Oracle Communications Session Border Controllers’ Call-ID might not be properly decoded by another Oracle
Communications Session Border Controller. The result is asymmetric header manipulation and failed call transfers.
needs to see the each user endpoint’s original Via header in order to perform some implicit authentication, admission,
and control functions in a TISPAN-compliant model.
You enable Via header transparency on the access SIP interface. Received Via headers are saved for inclusion in
requests going out another interface or session agent that does not have the parameter set, in other words, the core
side. For any received SIP message where the inbound previous hop interface was enabled for Via header
transparency, theOracle Communications Session Border Controller adds its own Via header as it forwards it, and it
also copies the received top-most Via as the new bottom-most Via, if the outbound next hop interface/session agent is
not enabled for Via header transparency. The Oracle Communications Session Border Controller also adds a
received= parameter to the copied Via header, per the SIP RFC 3261.
Any message received from an interface without Via header transparency enabled, does not have the received Via
header copied over to any other direction.
For HNT, where the original top-most (and only) Via header from a UE is a private/false address, the SD should still
copy that false address into the core-side, and the received= parameter will contain the real Layer-3 addressing.
Symmetric Latching
Symmetric latching, or forced HNT, ensures that symmetric RTP/RTCP is used for a SIP endpoint. Symmetric RTP/
RTCP means that the IP address and port pair used by an outbound RTP/RTCP flow is reused for the inbound flow.
The IP address and port are learned when the initial RTP/RTCP flow is received by the Oracle Communications
Session Border Controller. The flow's source address and port are latched onto and used as the destination for the
RTP/RTCP sourced by the other side of the call. The IP address and port in the c line and m line respectively in the
SDP message are ignored.
If your network is configured with nested realms in order to separate signalling from media, make sure that the
symmetric latching feature is enabled on the signaling realm.
Note: This description is applicable to RTCP only when you also enable the HNT RTCP option in the media-
manager configuration. Do not enable symmetric latching on core-facing interfaces.
Terminology
The following lists explains the terminology used later.
• X is any digit having the value 0 through 9
• N is any digit having the value 2 through 9
• 0/1 is a digit having the value of either 0 or 1
• NXX is a form of Numbering Plan Area (NPA).
• CC is a 1, 2, or 3 digit country code used in international dialing
• NN is a national number that can be a four to fourteen digit national number used in international dialing, where
the combination of CC+NN is a 7 to 15 digit number.
• + symbol in E.164 indicates that an international prefix is required
• E.164 numbers are globally unique, language independent identifiers for resources on Public Telecommunication
Networks that can support many different services and protocols.
• N11 number is any of the three-digit dialing codes in the form N11 used to connect users to special services,
where N is a digit between 2 and 9
Realm
To configure SIP number normalization for 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 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. You can either add SIP number normalization support to a new session agent configuration or to an existing
session agent configuration:
• For a new realm configuration, add the option by typing options, a Space, and then number-
normalization.
ORACLE(realm-config)# options number-normalization
• For an existing realm configuration without any options already configured, select the realm, type options
followed by a Space, and then number-normalization.
ORACLE(realm-config)# select
ORACLE(realm-config)# options number-normalization
• For an existing realm configuration with other options, select the realm, type options followed by a Space,
the plus sign (+), and the number-normalization option.
ORACLE(realm-config)# select
ORACLE(realm-config)# options +number-normalization
5. Save your work using the ACLI save or done command.
Session Agent
To configure SIP number normalization for a session agent:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter to access the media-level configuration elements.
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.
ORACLE(session-router)# session-agent
ORACLE(session-agent)#
4. You can either add SIP number normalization support to a new session agent configuration or to an existing
session agent configuration:
• For a new a session agent configuration, add the option by typing options, a Space, and then number-
normalization.
ORACLE(session-agent)# options number-normalization
• For an existing session agent configuration without any options already configured, select the session agent,
type options followed by a Space, and then number-normalization.
ORACLE(session-agent)# select
ORACLE(session-agent)# options number-normalization
• For an existing session agent configuration with other options, select the session agent, type options
followed by a Space, the plus sign (+), and the number-normalization option.
ORACLE(session-agent)# select
ORACLE(session-agent)# options +number-normalization
5. Save your work using the ACLI save or done command.
The diagram shows UA1, UA2, and UA3 are endpoints within the access network and that the SIP interface for the
access network is 172.16.0.15:5060. On the provider network, the SIP interface is at 192.168.24.15, with the SIP port
mapping feature enabled. The softswitch/registrar is also located on the provider network at 192.168.24.90:5060.
The diagram shows that port 2001 on the provider network is allocated to UA1 on the access network, port 2002 is
allocated to UA2, and port 2003 is allocated to UA3. Because of this allocation, all SIP signaling messages sent from
the endpoints in the access network to the softswitch on the provider network travel through an allocated signaling
port. For example, all signaling messages between UA1 and the softswitch use 192.168.24.15:2001 as the transport
address.
Using SIP port mapping with SIPconnect—where unique ports are used for each registered PBX—hinders the SBC
from routing incoming calls to the corresponding PBX because the SBC uses DN for the PBX’s parent during
registration, but the incoming INVITE from the softswitch contains the child DN in its Request URI. Thus the SBC
cannot find a matching SBC-Contact because the username of the Request URI contains the child DN, but the
username of the SBC-Contact contains the parent DN.
You can enable SIPconnect support in either the realm configuration or session agent for the SIP access network by
setting the sip-connect-pbx-reg option. With this option set and the destination realm configured for port
mapping, the SBC inserts a special search key in the registration table. Rather than adding the SD-Contact as the key
as with regular (non-SIPconnect) registrations, the SBC strips user information and instead uses the host and port
information as the registration key. The SBC still forwards the registration message with an intact contact username.
Acme Packet recommends you use port map ranges that fall on bit boundaries to ensure the fewest possible ACL
entries are created and only the configured ports are allowed by the ACLs. For example, a range of 32768 to 49151
provides for 16,384 signaling ports in a single ACL entry (192.168.24.15:32768/2).
Note: If the ACLs added for the port map range do not include the SIP port configured in the SIP interface;
the normal SIP ACL entry for the SIP port is also added.
Dynamic Configuration
Dynamic configuration of SIP port mapping can cause disruption in service for existing registration cache entries;
depending on the changes made to the defined port map range. If the range of mapping ports is reduced, it is possible
that SIP signaling messages from the registrar/softswitch realm will no longer be sent to the host processor because of
the changes in the NAT Table ACL entries.
When the range of mapping ports is changed, any signaling ports in the free signaling port pool not allocated to a
registration cache entry are removed from the pool. When an allocated signaling port that is no longer part of the
defined mapping port range is released, it is not returned to the pool of free steering ports.
The administrator is warned when the changed configuration is activated after the port map range of a SIP interface
has been changed.
Registration Statistics
The SIP registration cache statistics include counters for free and allocated signaling ports. You can issue a show
registration command to display the statistics:
17:36:55-190
SIP Registrations -- Period -- -------- Lifetime --------
Active High Total Total PerMax High
User Entries 4 4 0 7 4 4
Local Contacts 4 4 0 7 4 4
Free Map Ports 12284 12284 0 12291 12288 12288
Used Map Ports 4 4 0 7 4 4
Forwards - - 1 22 4
Refreshes - - 3 43 3
Rejects - - 0 0 0
Timeouts - - 0 1 1
Fwd Postponed - - 0 0 0
Fwd Rejected - - 0 0 0
Refr Extension 0 0 0 0 0 0
Refresh Extended - - 0 0 0
The labels for the first two items reflect the restructured registration cache:
• User Entries: counts the number of unique SIP addresses of record in the cache. Each unique address of record
represents a SIP user (or subscriber). The address of record is taken from the To header in the REGISTER request.
There might be one or more registered contacts for each SIP user. The contacts come from the Contact header of
the REGISTER request.
• Local Contacts: counts the number of contact entries in the cache. Because the same user can register from
multiple endpoints (user agents); the number of Local Contacts might be higher than the number of User Entries.
• Free Map Ports: counts the number of ports available in the free signaling port pool.
• Used Map Ports: counts the number of signaling ports allocated for registration cache entries. The value of Used
Map Ports will equal the number of Local Contacts when the port mapping feature is used for all registrar/
softswitch realms in the Oracle Communications Session Border Controller.
• Configured SIP port, which might be used for signaling messages not associated with a registered endpoint.
• Port range defined for steering pool configuration using the same IP address as the SIP interface. If overlap
occurs, the NAT table entry for the steering port used in a call prevents SIP messages from reaching the host
processor.
To configure SIP port mapping:
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. port-map-start—Set the starting port for the range of SIP ports available for SIP port mapping. The valid
range is 1025 through 65535. The default values is 0 and when this value is set, SIP port mapping is disabled. The
valid range is:
• Minimum: 0, 1025
• Maximum: 65535
ORACLE(sip-interface)# port-map-start 32768
5. port-map-end—Set the ending port for the range of SIP ports available for SIP port mapping. The valid range
is 1025 through 65535. If you set the value to the default 0, SIP port mapping is disabled. The valid range is:
• Minimum—0, 1025
• Maximum—65535
Note: If not set to zero (0), the ending port must be greater than the starting port.
Example 1
A more detailed example is when a softswitch might return a list of contacts for multiple PSTN gateways in a
Redirect message. If the PSTN target number contacted on redirection is busy, a 486 response will be sent to the
Oracle Communications Session Border Controller. Since the single target is located in the PSTN, a subsequent
request through a different gateway will yield another 486 response. The Oracle Communications Session Border
Controller should be configured to return the 486 response to the UAC immediately. No other SIP requests should be
sent to applicable targets/contacts that were enumerated in the redirect list. See the following example:
Example 2
The Oracle Communications Session Border Controller might determine from a local policy lookup that several
routes are applicable for forwarding a SIP message. The Oracle Communications Session Border Controller will try
each route in turn, but the SIP response recursion disable feature can be implemented to stop the route recursion when
a configured responses message is received by the Oracle Communications Session Border Controller. See the
following example:
There are a few conditions on the parameter used to configure response recursion:
• SIP Route Recursion is configurable for either the SIP interface or session agent.
• 401 and 407 are preconfigured for all configured SIP interfaces. They are not configured for session agents.
• The format is a comma-separated list of response codes or response code ranges: 404, 484-486.
• Only response codes that fall within the 3xx, 4xx, and 5xx range may be specified.
Topology Hiding
So that it can perform topology hiding, the Oracle Communications Session Border Controller retains necessary
routing information (such as the Contact or Record-Route header values) and it encodes certain data from the
messages it receives in the messages it sends. To be more specific, the Oracle Communications Session Border
Controller encodes the original URI hostport and the ingress realm name into a gr parameter it adds to the URI. The
hostport information is replaced with the IP address and port of the SIP interface from which the message is sent (the
egress interface). Without this information, subsequent in-dialog messages cannot be routed correctly because the
Oracle Communications Session Border Controller does not retain dialog state (i.e., the route-set or remote-target).
For example, the URI sip:td@192.168.24.121:5060 might be encoded as sip:td@192.168.24.121:5060;
gr=vjml9qtd175bhmhvhkgp0jov81popvbp000040.
The Oracle Communications Session Border Controller also performs URI encoding on the message body for
Content-Type application/pdif+xml. this contains a Presence Information Data Format document (or PIDF) in
PUBLISH and NOTIFY requests so subsequent SIP requests using the URIs in the PIDF document can be routed
correctly.
The Oracle Communications Session Border Controller performs URI encoding in outgoing SIP messages after
SIP=NAT is applied and before outbound HMR occurs. And the system decodes URIs in SIP messages after inbound
HMR takes place and before SIP-NAT is applied.
In the event a URI is encoded several times (as is the case in spiral and hairpin calls), the encoded realm+hostport
values are separated by a plus sign (+), as in the following:
sip:td@192.168.24.121:5060; gr=vjml9qtd175bhmhvhkgp+dhfhb0jov81opvbp
When the Oracle Communications Session Border Controller receives any of the following requests, it matches the
contents of the request’s Event header with the list you configure in the proxy-sub-events parameter:
• PUBLISH
• SUBSCRIBE
• NOTIFY
• REFER
This is provided the operation-mode for the SIP configuration is set to either session or dialog. If it finds a
match, the Oracle Communications Session Border Controller marks the request for processing in transaction-stateful
mode rather than in B2BUA mode.
Note: Although PUBLISH is not a dialog-creating request, topology hiding needs to be applied to the PIDF
so that subsequent NOTIFY requests containing portions of the published PIDF can be decoded properly.
When the Oracle Communications Session Border Controller forwards the request, it will have encoded all Contact
and Record-Route header information using the ingress realm. The hostport value of the URIs then has egress SIP
interface’s IP address and port. The Via headers in the requested the Oracle Communications Session Border
Controller received are not included in the outgoing request.
Then PUBLISH, SUBSCRIBE, NOTIFY, and REFER responses are compared to the request that was sent to
determine if the response should receive transaction-stateful proxy treatment. The Oracle Communications Session
Border Controller decodes any encoded Record-Route headers back to their original values for the outgoing response.
Any Record-Route headers added downstream from the Oracle Communications Session Border Controller are
encoded using the original request’s egress realm (meaning the realm from which the response was received). In
addition, the Contact header is encoded using the request’s egress realm and ingress SIP interface and port.
Feature Interaction
When using this feature, the Oracle Communications Session Border Controller does not keep dialog or subscription
state. Therefore the Per-user SUBSCRIBE Dialog Limit feature—configured in the enforcement-profile
configuration—will not function properly when a subscription is handled in proxy mode.
Oracle Communications Session Border Controller to forward a REGISTER message to the registrar when the Call-
ID header changes in a REGISTER message received from a reregistering UAC.
For the 200 OK it generates, the Oracle Communications Session Border Controller removes any Reason or Retry-
After header in the 200 OK and sets the expires time. By default, the expires time is the Retry-After time (if there is
one in the response) or the expires value in the Register request (if there is no Retry-After expires time). You can also
set this value using the register-response-expires parameter, but the value you set should never exceed the Register
request’s expires time.
selection: 1
ORACLE(session-agent)#
3. ping-from-user-part—Set the user portion of the From: header that defines the source of a session agent ping
message.
ORACLE(session-agent)# ping-from-user-part bob
4. ping-to-user-part—Set the user portions of the Request-URI and To: headers that define the destination of a
session agent ping message.
ORACLE(session-agent)# ping-to-user-part anna
5. Type done to save your configuration.
• Multiple SIP PAIs in a SIP INVITE—The Oracle Communications Session Border Controller removes all PAIs
when there are multiple PAIs set in SIP INVITEs that come from untrusted realms.
• Oracle Communications Session Border Controller behavior bridging trusted and untrusted realms—The
following graphics shows you how Oracle Communications Session Border Controllers can be positioned and
configured to handle PAI stripping between trusted and untrusted realms.
SBC’s behavior Strip PAI regardless of Same as behavior for SIP Same as behavior for SIP
privacy type privacy support in privacy support in previous
previous 1.3.1 releases 1.3.1 releases
Take this relationship into consideration when you configure SIP PAI header stripping, or this feature will not work as
designed.
For the sample configuration cited below, the desired Oracle Communications Session Border Controller behavior is
to always strip the PAI regardless of privacy type.
To configure SIP PAI stripping for an existing realm using 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-manager path.
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)#
4. Select the realm to which you want to apply this feature.
ORACLE(realm-config)# select
identifier:
1: acmePacket <none> 192.168.20.0/24
SIP-SIP Calls
The SIP Reason header might appear in any request within a dialog, in a CANCEL request, and in any response
where the status code explicitly allows the presence of this header field. The syntax of the header follows the standard
SIP parameter:
Reason: SIP;cause=200;text=”completed elsewhere”
Reason: Q.850;cause=16;text=”Terminated”
This feature attends to the following possible SIP call scenarios:
• When the Oracle Communications Session Border Controller receives a SIP request or SIP response that contains
the Reason header, the Oracle Communications Session Border Controller passes it without modification.
• When it generates a SIP response, the Oracle Communications Session Border Controller includes the RFC 3326
Reason header containing a Q.850 cause code and reason. This is the case for all local conditions and for all
internally generated error responses (4xx, 5xx, and 6xx) to an initial SIP INVITE.
Possible local error scenarios are:
• invalid-message
• cpu-overloaded
• media-released
• media-not-allocated
10. method—Enter the name of the received SIP failure response message you want to map to a 200 OK.
There is no default for this parameter, and leaving the parameter empty turns off the SIP registration response
mapping feature.
11. register-response-expires—Enter the time you want to use for the expires time what mapping the SIP method you
identified in the method parameter from Step 4.
The maximum is 999999999. By default, the expires time is the Retry-After time (if there is one in the response)
or the expires value in the Register request (if there is no Retry-After expires time). Any value you configure in
this parameter (when not using the defaults) should never exceed the Register request’s expires time.
12. Repeat this process to create the number of local response map entries that you need.
13. Save and activate your configuration for changes to take effect.
Default Mappings
This table defines the default mappings the Oracle Communications Session Border Controller uses when it cannot
locate an appropriate entry that you have configured.
SIP Status
To configure a SIP status to Q.850 Reason with cause mapping:
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 sip-q850-map and press Enter.
ORACLE(session-router)# sip-q850-map
ORACLE(sip-q850-map)#
4. Type entries and press Enter.
ORACLE(sip-q850-map)# entries
ORACLE(sip-q850-map-entry)#
From here, you can view the entire menu for the SIP status to Q.850 Reason with cause mapping entries
configuration by typing a ?.
5. sip-status—Set the SIP response code that you want to map to a particular Q.850 cause code and reason.
There is no default, and the valid range is:
• Minimum—100
• Maximum—699
6. q850-cause—Set the Q.850 cause code that you want to map to the SIP response code that you set in step 5.
There is no default.
7. q850-reason—Set the Q.850 reason corresponding to the Q.850 cause code that you set in step 6. There is no
default. If your value has spaces between characters, then your entry must be surrounded by quotation marks.
8. Repeat this process to create the number of local response map entries that you need.
9. Save and activate your configuration for changes to take effect.
To configure a Q.850 cause to a SIP status with reason mapping:
10. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
11. Type session-router and press Enter.
ORACLE(configure)# session-router
12. Type sip-q850-map and press Enter.
ORACLE(session-router)# q850-sip-map
ORACLE(q850-sip-map)#
13. Type entries and press Enter.
ORACLE(q850-sip-map)# entries
ORACLE(q850-sip-map-entry)#
From here, you can view the entire menu for the Q.850 cause to a SIP response code with reason mapping entries
configuration by typing a ?.
14. q850-cause—Set the Q.850 cause code that you want to map to a SIP status with reason. There is no default.
15. sip-status—Set the SIP response code to which you want to map the Q.850 cause that you set in step 5.
There is no default, and the valid range is:
• Minimum—100
• Maximum—699
16. sip-reason—Set the reason that you want to use with the SIP response code that you specified in step 6. There
is no default. If your value has spaces between characters, then your entry must be surrounded by quotation marks.
17. Repeat this process to create the number of local response map entries that you need.
18. Save and activate your configuration for changes to take effect.
To enable the Oracle Communications Session Border Controller to add the Reason header for calls that require
IWF:
19. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
20. Type session-router and press Enter.
ORACLE(configure)# session-router
21. Type iwf-config and press Enter.
ORACLE(session-router)# iwf-config
ACMEPACKET(iwf-config)#
22. add-reason-header—Enable this parameter to add the Reason header. The default is disabled. The valid
values are:
• enabled | disabled
23. Save and activate your configuration for changes to take effect.
Terminology
The following IPTEL terms are used in the descriptions of and instructions for how to configure this feature:
• Trunk—In a network, a communication path connecting two switching systems used in the establishment of an
end-to-end connection; in selected applications, it may have both its terminations in the same switching system
• Trunk group—A set of trunks, traffic engineered as a unit, for the establishment of connections within or between
switching systems in which all of the paths are interchangeable except where sub-grouped
• Trunk group name—Provides a unique identifier of the trunk group; referred to as tgrp
• Trunk group context—Imposes a namespace by specifying a domain where the trunk groups are; also referred to
simply as context
There are two available formats for the originating trunk group URIs:
1. In compliance with the IPTEL draft, the first format has two parameters: tgrp (identifier of the specific trunk
group) and trunk-context (defines the network domain of the trunk group). These appear in the following formats:
• tgrp=”trunk group name”
• trunk-context=”network domain”
The URI BNF for would appear as it does in the example directly below, where the tgrp is tg55 and the trunk-
context is trunk-context is telco.example.com:
tel:+15555551212;tgrp=tg55;trunk-context=telco.example.com
2. The second format is customized specifically for access URIs and contains two provisioned parameters: tgrp (or
tgname) and context (or provstring). This appears as tgrp.context, where these definitions apply:
• tgrp (tgname)—Provisioned trunk group name for the originating session agent; this value must have at least
one alphabetical character, cannot contain a period (.), and can contain a hyphen (-) but not as the first or the
last character
• context (provstring)—Name of the originating trunk group context; this value must have at least one
alphabetical character in the top label
This format conforms to format for a hostname in the SIP URI as specified in RFC 3261, such that a trunk
group identifier would appear as:
custsite2NY-00020.type2.voip.carrier.net
where the tgrp is custsite2NY-00020, and the context is type2.voip.carrier.net.
The BNF for an access URI conforms to the following:
SIP-URI = "sip:" [userinfo ] hostport uri-parameters [headers ]
uri-parameters = *( ";" uri-parameter )
uri-parameter = transport-param / user-param / method-param
/ ttl-param / maddr-param / lr-param / other-param
other-param = accessid / pname [ '=' pvalue ]
accessid = "access=" accessURI
accessURI = scheme tgname ["." provstring]
scheme = "sip:" / token
tgname = ALPHA / *(alphanum) ALPHA *(alphanum / "-") alphanum /
alphanum *(alphanum / "-") ALPHA *(alphanum) # up to 23 characters
provstring = *(domain ".") toplabel # up to 24 characters
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
domain = alphanum/ alphanum *( alphanum / "-" ) alphanum
In the absence of official SIP standards for transporting trunk groups between signaling elements, the Oracle
Communications Session Border Controller allows you to define the URI parameters used in terminating trunk
groups.
There are two available formats for the terminating trunk group URIs:
1. In compliance with the IPTEL draft, the first format has two parameters: tgrp (which can be either a trunk group
name or an IP address) and trunk-context (defines the network domain of the trunk group). These appear in the
following formats:
• tgrp=”trunk group name”
• trunk-context=”network domain”
An example R-URI with terminating trunk group parameters appears as follows, where the tgrp is TG2-1 and
the context is isp.example.net@egwy.isp.example.net:
INVITE sip:+15555551212;tgrp=TG2-1;trunk-
context=isp.example.net@egwy.isp.example.net SIP/2.0
2. The second format is customized specifically for egress URIs and contains two provisioned parameters: tgrp (or
tgname) and context (or tgdomain). This appears as tgrp.context (or tgname.tgdomain), where definitions apply:
• tgrp (tgname)—Provisioned trunk group name for the originating session agent; this value must have at least
one alphabetical character, cannot contain a period (.), and can contain a hyphen (-) but not as the first or the
last character
• context (tgdomain)—Name of the terminating trunk group context; this value can be up to twenty-four
characters
The use of multiple terminating trunk groups is not supported.
The BNF for a single, egress URI with trunk group information conforms to:
SIP-URI = "sip:" [userinfo ] hostport uri-parameters [headers ]
uri-parameters = *( ";" uri-parameter )
uri-parameter = transport-param / user-param / method-param
/ ttl-param / maddr-param / lr-param / other-param
other-param = egressid / pname [ '=' pvalue ]
egressid = "egress=" egressURI
egressURI = scheme tgname ["." tgdomain]
scheme = "sip:" / token
tgname = ALPHA / *(alphanum) ALPHA *(alphanum / "-") alphanum /
alphanum *(alphanum / "-") ALPHA *(alphanum) # up to 23 characters
tgdomain = *(domain ".") toplabel # up to 24 characters
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
domain = alphanum/ alphanum *( alphanum / "-" ) alphanum
For all trunk group URI support, you must set the appropriate parameters in the SIP manipulations
configuration and in the session agent or session agent group configurations.
In the originating trunk group URI scenario, a call arrives at the Oracle Communications Session Border
Controller from a configured session agent or session agent group. If this session agent or session agent group
has the appropriate trunk group URI parameters and inbound manipulation rules configured, the Oracle
Communications Session Border Controller then looks to the SIP manipulations configuration and add the
trunk group URI information according to those rules. Those rules tell the Oracle Communications Session
Border Controller where and how to insert the trunk group URI information, and the system forwards the call.
In the terminating trunk group scenario, a call arrives at the Oracle Communications Session Border Controller
from, for instance, a call agent. This call contains information about what trunk group to use. If the
information matches a session agent or session agent group that has outbound manipulation rules configured,
the Oracle Communications Session Border Controller will then look up the SIP manipulations configuration
and strip information according to those rules. Those rules tell the Oracle Communications Session Border
Controller where and how to remove the information, and the Oracle Communications Session Border
Controller forwards the call.
To make multiple entries, surround your entries in parentheses and separate them from each other with spaces. For
example:
ORACLE(session-agent)# trunk-group (tgrp1:context1 tgrp2:context2)
7. options—If you want to configure trunk group URIs for SIP-H.323 calls that use the IWF and you are using
SIP registration caching, you might need to add the preserve-user-info-sa to your list of session agent options.
If you are adding this option to a new session agent, you can just type options, a Space, and preserve-
user-info-sa.
If are adding this to an existing session agent, you must type a plus (+)
sign before the option or you will remove any previously configured options.
In order to append the new option to the options list, you must prepend the
new option with a plus sign: options +preserve-user-info-sa.
When the Oracle Communications Session Border Controller receives a non-allowed emergency request, it performs
a local policy lookup for a matching local policy. An emergency local policy could be configured to match if the To:
header in a SIP message was addressed to 911.
An emergency policy priority selection criteria has been added to both the SIP interface and the local policy
configuration elements. In the SIP interface, the parameter is called anonymous-priority. In the local policy, the
parameter is called policy-priority.
For the Oracle Communications Session Border Controller to choose a local policy to route an emergency call, the
emergency policy priority value on the local policy must be equal to or greater than the emergency policy priority
value on the SIP interface where the emergency message was received. In this scheme, an emergency policy priority
value of none is the lowest value and an emergency policy priority value of emergency is the highest.
When a match is made between all existing local policy criteria and the emergency policy priority, the emergency call
will be sent to the core network according to the chosen local policy. In addition, the policy priority value of the
chosen local policy is inserted into the Priority header of the core-bound SIP message..
Fraud Prevention
The Oracle Communications Session Border Controller can constrain outgoing SIP messages to a maximum size in
bytes in order to support fraud prevention techniques. If a message does exceed the configured size, it is dropped. A
SIP message can be constrained from 0 to 65535 bytes, with a default value of 4096 bytes.
the reverse direction, or allow early media in both directions. The forward direction is when the packets flow from the
caller to the called party. The reverse direction is when the packets flow from the called party to the caller.
The early media suppression rule is applied to a session. When the Oracle Communications Session Border Controller
initiates a new session, it first checks whether the next hop is a session agent and if so, whether an early media
suppression rule has been configured it. If an early media suppression rule is found, the Oracle Communications
Session Border Controller enforces it. If the next hop is not a session agent or no early media suppression rule is
configured, the Oracle Communications Session Border Controller checks whether an early media suppression rule
has been configured for the outbound realm. If it finds one, it enforces it.
Example
The following illustration shows two examples of early media suppression.
1. Caller UE1 makes a call to the PSTN media gateway (MGW). The INVITE traverses from UE1 to the Oracle
Communications Session Border Controller through the softswitch to the MGW. The Oracle Communications
Session Border Controller allows early media from the core to reach UE1.
2. The PSTN MGW makes a call to UE1. The INVITE traverses to the Oracle Communications Session Border
Controller and to UE1. The Oracle Communications Session Border Controller blocks all early media to and from
UE1 until a 200 OK is received.
The Oracle Communications Session Border Controller allows all media when a 200 OK response is received for the
INVITE, regardless of whether the 200 OK response contains SDP.
Call Signaling
The Oracle Communications Session Border Controller media manager performs early media suppression according
to an early media suppression rule. No change has been made to call signaling. For SIP, the Oracle Communications
Session Border Controller still forwards SDP received in an INVITE request or response after performing a NAT to
the media connection address. After which, the Oracle Communications Session Border Controller is ready to receive
media packets from the endpoints. If an early media suppression rule has been configured, the Oracle
Communications Session Border Controller drops the packets going in the direction being specified by the rule.
For a H.323 to SIP call, early media suppression rule does not change how the Oracle Communications Session
Border Controller performs H.225/Q.931 call signaling and starts the H.245 procedure (if required) to establish
logical channels for early media on the H.323 leg of the call.
Suppression Duration
When early media suppression is enabled in a session, the block lasts until the session is established. For a SIP to SIP
call or an H.323 to SIP call, a session is established when the system receives a 200 OK response to the INVITE. A
200 OK response to the INVITE terminates early media suppression, even when it does not contain a SDP. (A 200
OK response to a PRACK or an UPDATE request does not terminate early media suppression.) After a session is
established, the Oracle Communications Session Border Controller can receive a change in media session (for
example, a re-INVITE with a new SDP) without an early media suppression rule blocking the media.
Rule Resolution
When the call’s next hop is a session agent and both the outbound realm of the call and the session agent have an
early media suppression rule, the session agent’s early media suppression rule takes precedence. If the session agent’s
early media suppression rule has not been configured, the outbound realm’s early media suppression rule is used, if
configured.
Selective early media suppression addresses the fact that some service providers need to allow early media for certain
user-to-user and PSTN-to-user calls to support, for example, custom ringback tones. The enhancements also address
the fact that Oracle Communications Session Border Controllers can themselves lose the ability to decide whether or
not early media should be blocked when confronted with hairpinned call flows, or with traffic that traverses multiple
Oracle Communications Session Border Controllers.
To address this need, you can configure realm groups. Realm groups are sets of source and destination realms that
allow early media to flow in the direction you configure. For example, you can set up realm groups to allow media
from PSTN realms to user realms so that users can listen to PSTN announcements, but prohibit early media from user
realms to PSTN realms.
Note: The source and destination realms you add to your lists need to be a global signaling realm matching
the caller’s SDP address prefix or a SIP realm.
SIP-Based Addressing
With the SIP-based addressing described in the SIP Early Media Suppression section, early media suppression is
based on the outbound SIP interface realms and the value of their early-media-allow parameter. When the Oracle
Communications Session Border Controller forwards a SIP Invite out a SIP interface, the outbound realm is chosen
based on the SIP layer information, such as the session agent for the next-hop or the address prefix of the next-hop
SIP device. The matching realm’s early-media-allow parameter value then applies to either allow all, block all, or
block one-way early media until a 200 ok is received. At that point bidirectional media is allowed. The decision is
based on SIP-layer addressing of next-hops.
SDP-Based Addressing
SDP-response early media suppression follows the same sequence described for SIP-based addressing with one
exception. A provisional response with SDP media can make the Oracle Communications Session Border Controller
select a new early-media-allow rule from another realm, based on the addressing inside the responding SDP.
When the SDP-response early media suppression feature is enabled, the Oracle Communications Session Border
Controller searches the outbound SIP interface’s realms for a matching address prefix with the connection address in
the responding SDP. If it finds a match, it uses the early-media-allow parameter value of that realm until the 200 OK
message is received, then bidirectional media is allowed regardless. If the Oracle Communications Session Border
Controller does not find a match, it searches all of the global realms for one. If it finds a match, the Oracle
Communications Session Border Controller uses that realm’s early-media-allow parameter value. If it does not find a
match in the global realm(s), the Oracle Communications Session Border Controller continues to use the previous
early-media-allow parameter value.
Global Realms
Global realms are realms that are not parents or children of any other realms, do not have defined SIP interfaces and
ports (or any signaling interface or stack), and are configured to use the network interface lo0:0. They are special
realms, applicable system-wide, and are currently only used for this feature. The only global realm configuration
parameters applicable to early media suppression are:
• addr-prefix
• additional-prefixes
• early-media-allow
• network-interface (which must be set to lo0:0)
Additional Prefixes
You can specific additional prefixes in addition to that of the addr-prefix parameter you configure for a realm. For
example, you can configure a global realm with additional address prefixes to specify the IP addresses (or ranges of
addresses) of the media gateways that are allowed to send and receive early media. This overrides the SIP interface
realm’s early media blocking settings.
You can also enter additional prefixes in non-global realms. These additional prefixes function the same as would
multiple values in the addr-prefix parameter (which only takes one value), except addresses in additional-prefixes are
not used for SIP NATs.
Example
The following illustration shows two examples of SDP-response early media suppression.
From this point, you can configure SIP interface parameters. To view all sip-interface parameters, enter a ? at the
system prompt.
4. If configuring an existing interface, enter the select command to select the interface.
5. options—Enter early-media-sdp-realms as the option. If adding to an existing list of options, use a preceding
plus (+) sign.
options +early-media-sdp-realms
6. Continue to the next section to configure the outbound realm.
For example:
ORACLE(session-router)# sip-interface
ORACLE(sip-interface)# options + early-media-sdp-realms
ORACLE(sip-interface)# done
sip-interface
state enabled
realm-id access1
sip-port
address 192.168.1.30
port 5060
transport-protocol UDP
allow-anonymous all
carriers
proxy-mode Proxy
redirect-action
contact-mode maddr
nat-traversal none
nat-interval 30
registration-caching disabled
min-reg-expire 300
registration-interval 3600
route-to-registrar disabled
teluri-scheme disabled
uri-fqdn-domain
options early-media-sdp-realms
trust-mode all
last-modified-date 2006-05-10 18:27:31
Configuring a Realm
To configure 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-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. If configuring an existing realm, enter the select command to select the realm.
5. early-media-allow—Enter the early media suppression rule for the realm. The valid values are:
• both—Early media is allowed in both directions
• reverse—Early media received by Oracle Communications Session Border Controller in the reverse
direction is allowed
• none—Early media is blocked
flow set-up. In order to leave the media flows unchanged when session version changes but the rest of the SDP does
not, an option is configured in the media-manager-config.
If the Oracle Communications Session Border Controller attempts to modify these media flows when unnecessary,
calls could be dropped by the system disrupting media packet sequence number synchronization.
The ignore-reinv-session-ver option is set to handle this situation. When configured, the Oracle Communications
Session Border Controller compares the current SDP received from a UE against the previously-received SDP from
the same UE. If the SDP in the newer and older messages is the same, the Oracle Communications Session Border
Controller ignores any changes to the session-version and will not modify the media flow portion of the call.
Note: When the SDP change is only a reordering of SDP lines without any other change, the option has no
effect.
This option is used only to mitigate compatibility issues when running SRTP calls over any of Acme Packet’s IPSec
accelerated NIUs for the Acme Packet 4600, Acme Packet 4500 or Acme Packet3820, NOT for ETC NIUs.
About Latching
Latching is when the Oracle Communications Session Border Controller listens for the first RTP packet from any
source address/port for the destination address/port of the Oracle Communications Session Border Controller. 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 Communications Session Border Controller only allows subsequent RTP packets
from that same source address/port for that particular Oracle Communications Session Border Controller 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 Communications Session Border Controller will perform
symmetric RTP).
Restricted Latching
The Oracle Communications Session Border Controller 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
Communications Session Border Controller as the public SIP contact address, that information could be used
instead of waiting for a response. The Oracle Communications Session Border Controller 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 Communications Session
Border Controller (SBC) that are latched, are then used for the destination of RTP/RTCP sent to the device.
After allocating the media session in SIP, the SBC 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 SBC sets the source 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 SBC sets the source address in the flow going from the called side to the
calling side.
The SBC uses either the address provided in the SDP or the layer 3 signaling address for latching. You also configure
the SBC 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 SBC sends information for both
flows to the MBCD so that the correct NAT entries are installed.
Enabling restricted latching may make the SBC wait for a SIP/SDP response before latching, if the answerer is in a
restricted latching realm. This is necessary because the SBC 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.
Example 1
A typical example is when the Oracle Communications Session Border Controller 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 Communications Session Border Controller 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 Communications Session Border Controller, and calls do not appear to be behind NATs
from the Oracle Communications Session Border Controller’s perspective. The Oracle Communications Session
Border Controller’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 Communications Session Border Controller’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 Communications Session Border Controller 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).
• Cases where endpoints dynamically change transport protocols between UDP and TCP
Anonymous Requests
If a SIP endpoint sends an INVITE message with a From header that is anonymous, the Oracle Communications
Session Border Controller can find the registration cache entry by using the Contact and Via headers. In cases such as
instant messaging (IM), where there is no Contact header, the Oracle Communications Session Border Controller can
use the Via header.
The Oracle Communications Session Border Controller’s checks whether the reg-via-key option is configured for the
access-side SIP interface where a REGISTER is received. If the option is enabled, the Oracle Communications
Session Border Controller makes the via-key by adding the IP address from the Via header to the firewall address (if
there is a firewall present between the Oracle Communications Session Border Controller and the endpoint).
When an INVITE arrives at a SIP interface where this option is enabled, the Oracle Communications Session Border
Controller determines whether the From header is anonymous or not. If it is anonymous, then the Oracle
Communications Session Border Controlleruses the Via-key to find the registration entry.
Request Routing
So that requests addressed to the corresponding registered contact are routed to the proxy, the Oracle Communications
Session Border Controller includes the intervening proxy (i.e., the top Via) in the routing information for the
registration cache when you set reg-via-proxy. To carry out this routing scheme, the system adds a Path header
(if none is present) to the REGISTER. But it removes the Path header prior to sending the REGISTER to the registrar.
Note that when the received REGISTER contains a Path header, the Oracle Communications Session Border
Controller uses it for routing requests toward the endpoint and includes it in the forwarded REGISTER request—as is
the case when you do not enable SIP registration via proxy.
user
The Oracle Communications Session Border Controller supports the Privacy type user. It can remove non-essential
information headers that reveal user information by:
header
The Oracle Communications Session Border Controller also supports the Privacy type header. It modifies SIP headers
that might reveal the user identity by:
• Stripping the Via header
• Replacing the Contact header
• Stripping Record-Route
• Removing the Privacy header
• Removing Proxy-Require option tag = privacy (if present)
In general, the B2BUA behavior of the Oracle Communications Session Border Controller by default provides header
privacy for all sessions.
id
The Oracle Communications Session Border Controller also supports the Privacy type id. It keeps the Network
Asserted Identity private from SIP entities outside the trusted domain by:
• Stripping only P-Asserted-Identity
• Removing the Privacy header and Proxy-Require option-tag = privacy
• Setting the From header to anonymous (for the backward compatibility)
Examples
The following examples show the actions the Oracle Communications Session Border Controller performs depending
on the source and target of the calls.
If the Privacy header is set to none, the Oracle Communications Session Border Controller does not change the From
header and passes on the Privacy header, if there is one.
Trust Mode
To configure the trust mode:
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(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. If configuring an existing interface, enter the select command to select the interface.
5. trust-mode—Select the trust mode for this SIP interface. The default value is all. The valid values are:
• all—Trust all previous and next hops except untrusted session agents
• agents-only—Trust only trusted session agents
• realm-prefix—Trusted only trusted session agents or address matching realm prefix
• registered—Trust only trusted session agents or registered endpoints
• none—Trust nothing
6. Save and activate your configuration.
The following example shows the trust-mode set to none. The remaining SIP interface options are omitted for
brevity.
sip-interface
state enabled
realm-id access1
sip-port
address 192.168.1.30
port 5060
transport-protocol UDP
allow-anonymous all
carriers
proxy-mode Proxy
redirect-action
contact-mode maddr
nat-traversal none
cache is full. The default response is the 503 Registration DB-Full message, but you can use the SIP response
mapping feature to use another message if required.
You can set an option in the global SIP configuration that defines the value in the Retry-After header. The Oracle
Communications Session Border Controller sends this header as part of its rejection response when the registration
cache is full. Another option sets the percentage of the registration cache size which, if exceeded, causes the Oracle
Communications Session Border Controller to send an alarm.
Monitoring Information
You can monitor how many entries are in the SIP registration cache using the ACLI show registration
command and referring to the Local Contacts statistics.
reach the Oracle Communications Session Border Controller. Temporary promotion lasts only for the amount of time
remaining before the REGISTER server transaction expires plus the time allotted in the transaction expiration
parameter in the SIP configuration. Before the temporary promotion expires, there is enough time for any necessary
retransmissions of the first REGISTER and for the second REGISTER to take place. The following situations might
also occur:
• If the Oracle Communications Session Border Controller receives a 401 or 407 to the second REGISTER request,
it resets its access control level for the endpoint’s address to the default level; it then treats additional REGISTER
requests from the same context at the default access control level.
• If the Oracle Communications Session Border Controller receives a 200 OK response to the REGISTER message,
it extends the promotion time to the expiration period for the registration cache.
If the Oracle Communications Session Border Controller is able to find the temporary registration cache and the
saved challenge context when the second REGISTER arrives, it forwards the REGISTER without checking the
maximum registration sustain rate constraint for ingress and egress session agents—thereby ensuring that the
REGISTER with authentication credentials is sent to the registrar. So when you use this feature, you should set the
maximum registration sustain rate constraint of the session agent (representing the registrar) at half the registrar’s
maximum registration sustain rate. Additional REGISTER requests with the same challenge context are subject to the
maximum registration sustain rate constraint.
not to any other methods for which you might set up rate constraints. You can, however, set the burst rate window in
the session constraints configuration that will apply to all methods configured as rate constraints.
The Oracle Communications Session Border Controller captures statistics for SIP methods throttled by rate
constraints for SIP interfaces and session agents; it does not capture these statistics for the global SIP configuration.
• NOTIFY
• OPTIONS
• MESSAGE
• PUBLISH
• REGISTER
6. max-inbound-burst-rate—For the SIP method you set in the methods parameter, enter the number to
restrict the inbound burst rate on the SIP interface where you apply these constraints. The default and minimum
value is 0, and the maximum is 999999999.
7. max-outbound-burst-rate—For the SIP method you set in the methods parameter, enter the number to
restrict the outbound burst rate on the SIP interface where you apply these constraints. The default and minimum
value is 0, and the maximum is 999999999.
8. max-inbound-sustain-rate—For the SIP method you set in the methods parameter, enter the number to
restrict the inbound sustain rate on the SIP interface where you apply these constraints. The default and minimum
value is 0, and the maximum is 999999999.
9. max-outbound-sustain-rate—For the SIP method you set in the methods parameter, enter the number to
restrict the outbound sustain rate on the SIP interface where you apply these constraints. The default and minimum
value is 0, and the maximum is 999999999.
10. Save your changes and apply this session constraint and its rate constraint(s) to SIP interfaces.
This behavior affects specific applications that are better served by the Oracle Communications Session Border
Controller waiting to update media flow information until it receives the answer to the second offer.
media flows simultaneously by default. In addition, when the first hairpinned call leg is torn down, the second call leg
is gracefully released immediately by the Oracle Communications Session Border Controller creating and sending an
appropriate signaling message (e.g., BYE for a SIP call or ReleaseComplete for an H.323 call) to the endpoint.
You can override this behavior by configuring the dont-terminate-assoc-legs option in the media manager.
When configured, the orphaned call leg in the hairpin scenario will be torn down after the initial guard
timer expires. The disconnect times of the two call legs, as recorded by the accounting appliation, will be
significantly different, due to the initial guard time for the second call leg.
Accounting Considerations
To indicate cases like this, where the second leg of the hairpinned call was preempted, Oracle Communications
Session Border Controller includes the following combination of release/termination causes in the CDR:
VSA 49: Acct-Terminate-Cause = NAS_REQUEST
VSA 62: Acme-Disconnect-Cause = 8
SIPconnect
The Oracle Communications Session Border Controller supports the SIPconnect model, wherein PBXs register
themselves so that service providers do not need to know IP addresses or locations in advance for static
configurations. This is particularly helpful when the PBX is behind a NAT.
In the PBX registration process, the PBX creates a binding between one of its phone numbers as the address of record
(AoR) and Contact-URI in the REGISTER message. The registrar knows that the single AoR actually represents
many addresses, and so it registers them implicitly. However, the registrar does not return the implicit AoR number in
P-Associated-URIs.
The SIPconnect feature resolves the following issues that arise from using this model:
• SIP INVITEs sent to the PBX from the Registrar through the Oracle Communications Session Border Controller
have the Request-URI of registered contact. Because it typically ignores the To-URI, the PBX needs the Request-
URI username portion to be the specific extension number being called.
With the SIP connect feature enabled, the Oracle Communications Session Border Controller overwrites the
Request-URI username with the To-URI username.
• SIP INVITEs from the PBX have the From AoR and Contact-URI usernames of specific phones rather than of the
registered AoR and Contact-URI. For the Oracle Communications Session Border Controller, this means that it
cannot use the allow-anonymous parameter value of register; there would be no registered user matches, and
the Oracle Communications Session Border Controller would reject them (with a 403 Forbidden).
With the SIP connect feature enabled, the Oracle Communications Session Border Controller performs allow-
anonymous checking based on the registered Via address, which is the same for all requests for the same PBX.
the bullet directly above. When it is not configured, the Oracle Communications Session Border Controller does
not make any replacements.
When it receives an INVITE request, the Oracle Communications Session Border Controller checks the incoming
realm for the sip-connect-pbx-reg option.
• If it is configured, the Oracle Communications Session Border ControllerC uses the INVITE’s source address
(instead of the AoR and Contact-URI) to search the registration cache for a matched registration entry.
• If it is not configured, the Oracle Communications Session Border Controller determines if the INVITE’s source
address is for a session agent and whether that session agent has sip-connect-pbx-reg option configured.
When it is configured, the Oracle Communications Session Border Controller replaces the user part of the
Request-URI with the user part of the To header. When the INVITE contains a P-Called-Party-ID header, the
Oracle Communications Session Border Controlleruses the user part of the P-Called-Party-ID header (instead of
the To header).
When it is not configured, the Oracle Communications Session Border Controller does not make any
replacements.
Required Configuration
• Registration caching is enabled.
• For the realm from which registrations come, the options list must include sip-connect-pbx-reg; this is new
configuration introduced to support this feature. The presence of this option instructs the Oracle Communications
Session Border Controller to skip matching the Contact header in the INVITE request with the registered Contact
of the registration entry. The Oracle Communications Session Border Controller finds a registration using only the
INVITE’s source address.
Alternatively, you can configure the sip-connect-pbx-reg option in the options list for a session agent. When the
realm where an INVITE comes from does not have this option set, the Oracle Communications Session Border
Controller determines whether or not the INVITE came from a session agent. You might choose to configure
session agents with this option if you do not want it applied to an entire realm. If the PBX is behind a NAT device,
the session agent’s IP address for the PBX (if statically configured) must be the IP address of the NAT device.
And if DNS is use, the session agent’s hostname must resolve to the NAT device’s IP address.
not match a cache entry and the host part of the URI is an IP address, the Oracle Communications Session Border
Controller will NAT the host part using the applicable SIP NAT configuration
• Contacts are found in the XML URI element for the contact. But if there is no URI element, then the Oracle
Communications Session Border Controller uses the Contact element information for the contact.
• If the expires attribute in the Contact element is a value other than zero, the Oracle Communications Session
Border Controller uses (inserts) the expires values from the registration cache.
• This feature also introduces delayed deletion from the registry cache. When a 200 OK comes back in response to a
REGISTER message and the 200 OK does not include all previously registered contacts, the missing contacts are
deleted. If the global SIP configuration option contact_cache_linger=XX (where XX is the number of seconds to
wait before deleting), then the contacts to be deleted remain for the specified number of seconds before they in
fact are deleted.
4. options—Set the options parameter by typing options, a Space, the option name preceded by a plus sign (+)
(contact-cache-linger=XX) where XX is the number of seconds to keep a contact in the cache before
deleting it.
ORACLE(sip-config)# options +contact-cache-linger=5
If you type either of these options without the plus (+) sign, you will
remove any previously configured options. In order to append the new option
to the options list, you must prepend the new option with a plus sign as
shown in the example above.
5. Save and activate your configuration.
Applicable Standards
RFC 3265, Session Initiation Protocol (SIP)-Specific Event Notification, outlines a framework within which a SIP
node, designated as the subscriber, can request automatic, asynchronous notification of certain events from a remote
peer, designated as the notifier. RFC 3265 also defines an Event Package as a set of state information to be reported
by a notifier to a subscriber, and mandates that such Event Packages be described in a specific RFC explicitly
identifying the state information to be reported by the notifier and defining required syntax and semantics to support
the subscription/notification exchange.
RFC 3680, A Session Initiation Protocol (SIP) Event Package for Registrations, fulfills this requirement by defining a
method that enables SIP user agents to request a defined set of state information from a SIP Registrar.
Section 5.2.3 of the 3GPP (Third Generation Partnership Project) 24.229, IP Multimedia Call Control Protocol Based
on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3, mandates that a P-CSCF
subscribe to the SIP Event Package for Registrations as defined in RFC 3680.
Call Flow
An example call flow between a SIP endpoint, the Oracle Communications Session Border Controller, acting as a P-
CSCF, and a SIP Registrar (S-CSCF) illustrates the Subscription/Notification process.
| REGISTER | REGISTER |
| ----------------> | ----------------> |
| 200 OK | 200 OK |
| <---------------- | <--------------- |
| | SUBSCRIBE |
| | Event:reg |
| | ----------------> |
| | 200 OK |
| | <---------------- |
| | NOTIFY |
| | <---------------- |
| | 200 OK |
| | ----------------> |
|
| | NOTIFY |
| | ----------------> |
| | 200 OK |
| | <-----------------|
The first two messages (the REGISTER request and the 200 REGISTER response) accomplish the successful
registration of the SIP endpoint.
<?xml version="1.0"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo" version="1"
state="partial">
<registration aor="sip:joe@example.com" id="a7" state="active">
<contact id="76" state="init" event="registered"
duration-registered="0">
<uri>sip:joe@pc34.example.com</uri>
</contact>
</registration>
</reginfo>
Notification Bodies
Registration state changes are reported in XML attachments to NOTIFICATIONS generated by the S-CSCF. As
shown above, the XML consists of one or more registration elements that report the state of a specific address-of-
record. Attributes supported by the registration element are as follows:
aor contains the address-of-record
id identifies this specific registration
state reports the Registration state — init, active, or terminated
init — address-of-record not yet cached
active — address-of-record maintained in current cache
terminated — address-of-record removed from cache, not currently valid
registration elements, in turn, contain one or more child contact elements. Attributes supported by the contact element
are as follows>
id identifies this specific contact
state reports the Contact state — active or terminated
event reports the event that generated the last state change — registered, created, refreshed, shortened, expired,
deactivated, probation, unregistered, or rejected
duration-registered reports the length (in seconds) of the current registration
contact elements, contain a single child uri element that identifies the contact address of FQDN.
ORACLE(sip-interface)#
2. Use the subscribe-reg-event parameter to subscribe to the SIP Event Package for Registrations.
By default, subscription is disabled.
ORACLE(sip-interface)# subscribe-reg-event enabled
ORACLE(sip-interface)#
3. Use done, exit, and verify-config to complete enabling the Event Package subscription.
5. options—Set the options parameter by typing options, a Space, the option name udp-fallback, and then
press Enter.
ORACLE(sip-interface)# options +udp-fallback
If you type options udp-fallback, you will overwrite any previously
configured options. In order to append the new option to the sip-interface’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.
Overview
Certain customers who use a uaCSTA for third party call control have encountered difficulties with the XML in their
SIP messages used to support business applications. In these cases, the XML—specifically the <deviceID> XML tag
—carries encoded IP addresses that need to be changed as they traverse the Oracle Communications Session Border
Controller.
The SIP business application allows users to click-to-dial another party using e-mail application clients. The user’s
click triggers the application server to send a uaCSTA SIP INFO message through the system to the UA/phone. These
SIP INFO messages contain XML with the user’s Contact-URI. But the server is only aware of the Oracle
Communications Session Border Controller’s NAT’d Contact-URI and not the user’s, so the XML in the SIP INFO is
carrying incorrect information.
The XML element, then, needs to be NAT’d to the phone’s real Contact-URI. This is especially important because of
the broad use of SIP INFO messages, which instruct a phone to:
• Answer a call
• Hold a call
• Retrieve a call
All of these functions are available via a clickable interface on the e-mail application.
The Oracle Communications Session Border Controller performs the NAT to the <deviceID> XML tag only if it is
configured to perform registration caching.
When the Oracle Communications Session Border Controller receives a SIP message from the core side and the
request has:
• A Content-Type of application/csta+xml
• A Content-Length greater than 0
it parses the message’s message body into an XML document. Should parsing fail, then the Oracle Communications
Session Border Controller will forward the SIP INFO request without modification to the XML message body.
Otherwise, the Oracle Communications Session Border Controller searches for the <deviceID> subelement within the
XML document. If it finds the <deviceID> subelement, the Oracle Communications Session Border Controller
searches through its registration cache for a registered Contact that matches the value of the <deviceID>. If it finds a
match, the Oracle Communications Session Border Controller replaces the value of the <deviceID> with that of the
corresponding registered Contact. If the value of the <deviceID> is a Contact that the Oracle Communications
Session Border Controller generates for a registered UA, the corresponding contact from the look-up would be the
Contact of the registered UA.
These functions performed, the Oracle Communications Session Border Controller then reformats the SIP INFO
request with the modified XML message body before sending it to the next hop. If there is no match found, then the
Oracle Communications Session Border Controller forwards the SIP INFO request without modifying the XML
message body.
Other than ensuring your Oracle Communications Session Border Controller is configured to perform registration
caching, you do not need take any further steps.
To enforce QoS properly on the access side, the flow between the SIP client (or the SIP client’s post-NAT IP address
and port) and the internal local address must be revealed on the core side using SIP signaling messages.
Details
To enable this enhancement, you set three parameters in the SIP interface configuration:
• sdp-internals—Establishes that local and remote transport addresses need to be added.This option must be
enabled on the access-side SIP interface, which is where the Oracle Communications Session Border Controller
receives SDP.
• sdp-local=<name>—Sets a name for the internal local transport port address that the Oracle Communications
Session Border Controller inserts into outgoing SDP. This option is configured on the core-side SIP interface. This
address is removed from incoming SDP from the core side to prevent attributes from being sent back to the core in
a hairpinned call.
• sdp-remote=<name>—Sets a name for the internal remote transport address that the Oracle Communications
Session Border Controller inserts into outgoing SDP. This option is also configured on the core-side SIP interface.
This address is also removed from incoming SDP from the core side to prevent attributes from being sent back to
the core in a hairpinned call.
Further, the Oracle Communications Session Border Controller determines whether or not to insert the SDP attributes
based on a call’s ingress and egress signaling realms:
To set the local and remote transport addresses for a core SIP interface:
6. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
7. Type session-router and press Enter to access the signaling-level configuration elements.
ORACLE(configure)# session-router
ORACLE(session-router)#
8. 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-config
ORACLE(sip-interface)#
9. options—Set the options parameter by typing options, a Space, the option name preceded by a plus sign (+)
(sdp-local=<name>, where the name is attribute name for the SDP), and then press Enter. Follow the same
steps to add the sdp-remote option.
ORACLE(sip-interface)# options +sdp-local=Local_Turn
ORACLE(sip-interface)# options +sdp-remote=PCMM_USERADD
If you type either of these options without the plus (+) sign, you will
remove any previously configured options. In order to append the new option
to the options list, you must prepend the new option with a plus sign as
shown in the example above.
10. Save and activate your configuration.
Licensing
To enable NSEP for SIP on your Oracle Communications Session Border Controller, you must obtain and install a
new license. If properly installed on your system, it appears as NSEP RPH in the display issued when you use the
ACLI show command in the license configuration.
For information about how to obtain an NSEP RPH license, contact your Oracle sales representative.
the Oracle Communications Session Border Controller performs matching based on RPH by comparing resource
values (r-values) in the RPH with values you set in the RPH profile configuration.
For an ETS call that matches by ETS DN and NMC rule, the system checks the NMC rule to determine if it has an
RPH profile (with r-values) assigned to it. If so, the Oracle Communications Session Border Controller continues by
comparing the RPH profile’s r-values against those in the request’s RPH. In cases where the RPH does not contain a
recognized value r-value, the Oracle Communications Session Border Controller:
• Processes the call as it normally would (as a non-ETS call) without changing the RPH if the resource-priority
option tag is not present in the Required header (for an INVITE only and not any other requests or response from
which RPH would be deleted)
• Rejects the Request when the Require header has the resource-priority header; or, inserts an Accept-Resource-
Priority header (ARPH) in the response if the insert-arp-header parameter option is enabled
However, the call goes through the Oracle Communications Session Border Controller as an ETS call when it is
matched by ETS DN and the applicable NMC does not have an RPH profile assigned. According to the settings in the
NMC rule, the Oracle Communications Session Border Controller either diverts or rejects such a call. And when the
call matches by RPH rather than ETS DN, the Oracle Communications Session Border Controller applies the
configured RPH profile from the relevant NMC rule.
It can be the case that non-ETS calls have RPH in their requests. Here, the Oracle Communications Session Border
Controller call treatment is performed according to the settings in the matching RPH profile when there is no
matching NMC rule. When you configure treatment as “reject,” then the Oracle Communications Session Border
Controller rejects the call with a 417 Unknown-Resource Priority status code. When you set the treatment to either
“accept” or priority, the Oracle Communications Session Border Controller allows the call to proceed as a non-ETS
call or as a priority call.
The ETS r-value can appear in ACK, BYE, INFO, PRACK, REFER and UPDATE requests. In cases when it does and
the session with which the request is associated is a non-ETS call, the Oracle Communications Session Border
Controller removes the RPH from the request before forwarding it and logs a TRACE-level error. The Oracle
Communications Session Border Controller also removes RPH from responses before forwarding them and logs a
TRACE-level error when responses contain RPH headers with ETS values for non-ETS sessions.
Call Treatment
This section describes how ETS calls are treated as they traverse the Oracle Communications Session Border
Controller.
Routing ETS calls are routed the same way as any other calls are, except when the applicable NMC
rule’s treatment type is divert, and rule defines the next hop. This route takes precedence
over other normal routes.
Local NMC ETS calls are exempt from the local NMC, including: session agent constraints, bandwidth
constraints (e.g., per-realm bandwidth), per-user CAC, and CPU constraints. However, the
call is subject to the ETS congestions control threshold. Licensing session constraints apply.
ETS Call Congestion ETS calls are subject to congestion control constraints that you configure specifically for
Control this type of traffic. In the global SIP configuration, you set up one option that defines a load
limit (greater than that set for normal calls).
ETS CAC Although the Oracle Communications Session Border Controller uses the call rate control
value in the applicable NMC rule, you can also enforce call rate on a per-user basis for ETS
calls.
When the Oracle Communications Session Border Controller receives a SIP INVITE with an RPH matching an NMC
with an ETS DN, but whose r-values do not match the NMC’s rph-profile, the Oracle Communications Session
Border Controller behaves as follows:
• If the INVITE does not have the resource-priority option tag and:
• If the matching NMS is set to PRIORITY, the call will be treated as an NSEP call. If there is an rph-profile
matching the r-value (not necessarily the one in the NMC), the Oracle Communications Session Border
Controller uses the media-policy from that rph-profile for the call. The rph-policy from the NMC (if present)
also applies to the call.
• If the matching NMC is not set to PRIORITY, the Oracle Communications Session Border Controller will treat
the call as a normal one.
If the INVITE contains the resource-priority option tag, the Oracle Communications Session Border Controller will
reject the call with the 417 Unknown Resource-Priority message.
Incoming request without Outgoing RPH value becomes the r-value set in the insert-r-value parameter in the
RPH (matched by ETS DN) RPH policy applied to the NMC rule.
Incoming request without If the insert-r-value parameter is empty in the RPH policy applied to the NMC rule
RPH (matched by ETS DN) or there is no RPH policy applied to the NMC rule, then the egress RPH will also
not have RPH.
Incoming request has RPH Egress RPH is the same as the ingress if the NMC rule has an RPH policy applied
but the override-r-value for the policy is empty or if there is not RPH policy applied
to the NMC rule.
If the override-r-value for the policy is set, then the egress RPH is set to that value.
For example, given an incoming request with the resource priority ets.0, dsn.flash and an RPH policy with an override
value of wps.1,ets.1, the egress request would be sent with a resource-priority of wps.1,ets.1,dsn.flash.
The Oracle Communications Session Border Controller also includes RPH in the following series of responses, even
when the downstream SIP entity does not respond with an RPH: 1xx, 2xx, 3xx, 4xx, 5xx, and 6xx. The 401
Unauthorized response is an exception.
Media Treatment
If the RPH profile set in an NMC names a media policy, then the Oracle Communications Session Border Controller
implements it for the ETS call. This media policy overrides any media policy set in the realm configuration.
The possible Differentiated Services Code Point (DSCP) values for an ETS call are:
• Audio—Applied to the respective media for an ETS call
• Video—Applied to the respective media for an ETS call
• SIP—Applied to the ETS calls’ SIP signaling messages, only for the egress call leg for the ETS session
RPH Configuration
This section shows you how to configure RPH profiles and policies that enable the Oracle Communications Session
Border Controller to act on SIP calls that have an ETS DN and/or an RPH carrying ETS resources values. There are
also settings for the global SIP configuration and for the NMC rule configuration that support this feature.
In addition, note that:
• You must set a media policy for the RPH profile to use. Check your system configuration and note the name of the
media policy that best suits your needs.
• Valid values for the parameters that take r-values are wps.x and ets.x, where x is 0 through 4.
Remember to save and activate your configuration after you have completed the processes detailed in this section.
3. Type rph-profile and press Enter. From here, you can configure the individual parameters for the RPH
policy.
ORACLE(session-router)# rph-profile
ACMEORACLEPACKET(rph-profile)#
4. name—Enter the name that uniquely identifies this RPH profile. This is the value you use to apply the profile in
the NMC rules configuration. There is no default for this parameter, and you are required to set it.
5. r-values—Enter one or more r-values that the Oracle Communications Session Border Controller is to
recognize for matching purposes. When you enter more than one value in the list, you type the name of the
parameter followed by a Space, open quotation mark, the values for the list separated by spaces, a closed
quotation mark. Then press Enter.
You must enter them in the order reflected below (a WPS and then an ETS value). A WPS call always has to have
an ETS namespace.
ORACLE(rph-profile)# r-values "wps.0 ets.2"
6. media-policy—Enter the name of a media policy configuration that you want applied for this RPH profile.
The Oracle Communications Session Border Controller implements this media policy for the ETS call, and this
media policy overrides any media policy set in the realm configuration.
7. call-treatment—Enter the call treatment method for a non-ETS call that contains RPH matching it to this
profile. The default is accept. The valid values are:
• accept—The call proceeds as it normally would
• reject—The Oracle Communications Session Border Controller rejects the call with the 417 Unknown-
Resource Priority status code
• priority—The Oracle Communications Session Border Controller treats the call as a priority call
Adding the apply-local-policy value to the options parameter in the network management controls
configuration allows the NMC to take precedence over cached Service Route when a session matches an NMC rule.
Instead, it locates a matching local policy.
Without the NMC configured to take precedence, the Oracle Communications Session Border Controller does not
function optimally as an E-CSCF for registered users.
Consider the following scenario in which a UE registers as a P-CSCF to the S-CSCF via the Oracle Communications
Session Border Controller. In this case, the registrar returns a Service Route header in a 200 OK response to the
REGISTER message to the Oracle Communications Session Border Controller. Or, if an implicit service route is
enabled, the Oracle Communications Session Border Controller generates a Service Route that it saves in the register
cache before forwarding the 200 OK on to the UA. Then when a new INVITE comes from the UA, the Oracle
Communications Session Border Controller checks its register cache and uses the Service Route as the next hop—
without taking local policy into consideration.
Using the apply-local-policy value requires local policy’s consideration in deciding the next hop. If you
configure this option and the Oracle Communications Session Border Controller receives a new INVITE, it will
decide whether the session is priority, registered, or with Service Route. Then it will determine if the call is E-CSCF.
If so and the first matching local policy has E-CSCF enabled, the priority local policy is applied over the Service
Route. The Oracle Communications Session Border Controller stays with the Service Route if not.
can use for outgoing requests rather than creating its own connection (as it does when this feature is not enabled). So
if a preferred connection fails, the Oracle Communications Session Border Controller can refer to this list and use the
alias connection.
The presence of an alias parameter in the Via header is just one mechanism that will call the Oracle Communications
Session Border Controller to use the inbound TCP/TLS connection for outbound requests. The Oracle
Communications Session Border Controller will automatically add an alias for the inbound connections in the
following circumstances:
• The other end of the connection is behind a NAT. When the Oracle Communications Session Border Controller
sees that the Via sent-by does not match the source address of the connection, it will automatically reuse the
connection to deliver requests to the UA.
• The Contact address of a REGISTER request received on a TCP connection matches the source address and port.
This is because the contact adress is the ephemeral port the UA used to form the connection to the Oracle
Communications Session Border Controller and, therefore, will not be listening on that port for inbound
connections.
• The presence of reuse-connections in the options field of the sip-interface will cause the Oracle Communications
Session Border Controller to reuse all inbound TCP connections for sending rquests to the connected UA.
This feature adds to the Oracle Communications Session Border Controller’s pre-existing TCP keepalive functionality
that you can enable in the network parameters configuration. Using existing functionality, you can customize
keepalive timing by:
• Specifying the number of unacknowledged packets the Oracle Communications Session Border Controller sends
to the remote peer before it terminates the TCP connection.
• Specifying the number of seconds of idle time before TCP keepalive messages are sent to the remote peer.
You can now set three modes for TCP keepalive for session agents and SIP interfaces:
• none—(Default) Keepalives are not enabled for use with the session agent/SIP interface; when you select this
setting for a session agent, it will use the setting for this feature from the SIP interface.
• enabled—Keepalives are enabled for the session agent/SIP interface.
• disabled—Keepalives are disabled for the session agent/SIP interface.
Note that the setting for this feature for a session agent takes precedence over that for a SIP interface. In addition, the
session agent offers you a way to set the re-connection interval.
4. tcp-keepalive—Enable or disable SIP TCP keepalive. The default value is none. The valid values are:
• none | enabled | disabled
ORACLE(session-agent)# tcp-keepalive enabled
5. Save and activate your configuration.
The Oracle Communications Session Border Controller stores session agent information that it looks up when
performing local policing session agent matching. To perform the lookup, it uses the session agent hostname as a key.
When the hostname is an FQDN and there is a configured IP address in the ip-address parameter, the Oracle
Communications Session Border Controller uses the ip-address value as a secondary key. Given this implementation,
the following are true when selecting session agents:
• If multiple session agents share the same IP address, the one with an IP address in the hostname parameter takes
precedence.
• If all session agents with the same IP address have an FQDN as their hostname, the one whose name is
alphabetically lower will take precedence, where alphabetically lower means earlier in the alphabet (closer to A
than to Z).
• For non-global session agents (whose realms are configured but not wildcarded) with an IP address, the Oracle
Communications Session Border Controller uses a key that is a combination of the IP address and the realm in the
form <address>:<realm>.
• For a session agent whose realm has a parent realm, the Oracle Communications Session Border Controller uses a
combination of the IP address, realm, and realm-path (or lineage for the realm) in the form <address>:<realm-
path>. For example, the realm path for a realm core3 with a parent core2, which in turn has a parent core would be
core:core2:core3.
When it looks up a session agent with a realm, the Oracle Communications Session Border Controller first searches
for an exact match for the IP address and realm combination. If this fails, it performs a second search if the desired
realm has parents or children. The Oracle Communications Session Border Controller locates an entry in its
repository of session agent information that is greater than or equal to the IP address with the base realm, which is the
ancestor of the desired realm without a parent. Having gathered this set of candidates, the Oracle Communications
Session Border Controller narrows down the search for a match by comparing sub-realms and determines there is a
match if either:
• The desired realm path is a sub-string of the entry’s realm path, or
• The entry’s realm path is a substring of the desired realm path (i.e., the desired realm is a sub-realm of the entry’s
realm)
Then the Oracle Communications Session Border Controller orders the candidates by depth of the entry’s realm-path,
or number of levels from the base realm relative to the depth of the desired realm. By searching the ordered set until
the entry’s realm depth equals the desired realm’s depth, the Oracle Communications Session Border Controller
determines a parent candidate, all subsequent entries being sub-realms of the desired realm. The Oracle
Communications Session Border Controller only considers entries at the first level deeper than the desired realm. If at
this point there is only one entry, the Oracle Communications Session Border Controller deems it a match. Otherwise,
it selects the parent candidate as the matching entry. In the event the search does not yield a matching realm, the
Oracle Communications Session Border Controller uses the global session agent for the IP address, if there is one.
The following diagram shows the realm tree, where the clouds are realms and squares are session agents, representing
a group of session agents sharing the IP address 1.2.3.4. The Oracle Communications Session Border Controller
searches for the session agents lower in the tree along the session agent realm-path and the desired realm.
For the diagram above, the following shows how the hostname would look for this group of session agents.
1.2.3.4 1.2.3.4[CORE2]
(This session agent owns the primary key for the IP
address because its hostname is the IP address.)
1.2.3.4:CORE SA[CORE]
(IP+realm key entry)
1.2.3.4:CORE 1.2.3.4[CORE2]
(IP+realm key entry)
1.2.3.4:CORE212 SA212[CORE212]
(IP+realm key entry)
1.2.3.4:CORE2121 SA2121[CORE2121]
(IP+realm key entry)
1.2.3.4:CORE231 SA231[CORE231]
(IP+realm key entry)
1.2.3.4:CORE232 SA232[CORE232]
(IP+realm key entry)
1.2.3.4:CORE: SA[CORE]
(IP+realm-path key entry)
1.2.3.4:CORE:CORE2: 1.2.3.4[CORE2]
(IP+realm-path key entry)
1.2.3.4:CORE2:CORE21:CORE212 SA212[CORE212]
1.2.3.4:CORE2:CORE21:CORE212:CORE2121 SA2121[CORE2121]
(IP+realm-path key entry)
1.2.3.4:CORE2:CORE23:CORE231 SA231[CORE231]
(IP+realm-path key entry)
1.2.3.4:CORE2:CORE23:CORE232 SA232[CORE232]
(IP+realm-path key entry)
For each realm in the table above, the search results for each realm would look like this:
Remember that if you do not specify a method, the system uses the all method.
ORACLE(sip-config)# options +lp-sa-match=realm
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. Save and activate your configuration.
• Unordered—Meaning that the endpoint can deliver data within regard for their stream sequence number
You set this preference in the network parameters configuration.
About Wildcarding
The Oracle Communications Session Border Controller supports wildcarding the event type in the subscribe-
event configuration. To wildcard the value, you enter an asterisk (*) for the event-type parameter instead of
typing in the name of an actual event type.
When you wildcard this value, the Oracle Communications Session Border Controller applies the subscription
limitations you set across all event types. Or, if you have entered multiple subscribe-event configurations, the Oracle
Communications Session Border Controller applies the wildcard limits across the event types for which you have not
set limits.
Consider the following example of a configured enforcement profile with a wildcarded subscribe-event
configuration:
enforcement-profile
name rulefour
allowed-methods
sdp-address-check disabled
subscribe-event
event-type *
max-subscriptions 1
subscribe-event
event-type xyz
max-subscriptions 0
last-modified-by admin@console
last-modified-date 2008-11-11 12:49:27
In this example, the enforcement profile allows all subscriptions that are event type xyz for a user. But it allows only
one maximum for every other subscription event type.
Monitoring
You can display the number of subscription dialogs per SUBSCRIBE event type using the ACLI show
registration sipd subscriptions-by-user command. You can display this information per event type,
or you can show data for all event types by wildcarding the event type argument.
STUN Server
The Oracle Communications Session Border Controller supports RFC 3489, which defines Simple Traversal User
Datagram Protocol (UDP) through Network Address Translators (NATs). Known as STUN, this lightweight protocol
that allows applications to:
• Discover the presence and types of both NATs and firewalls between themselves and the public Internet
• Determine the public IP addresses allocated to them by the NAT
SIP endpoints use the STUN protocol to find out the public IP addresses and ports for SIP signaling and RTP media
transport. Then they can use the address and port information to create multimedia sessions with other endpoints on
the public network.
You can define STUN servers functionality on a per-realm basis, allowing you set up multiple STUN servers.
MAPPED-ADDRESS Appears in the Binding Response; contains the source IP address and port
from which the Binding Request was sent to the STUN server.
XOR-MAPPED-ADDRESS Appears in the Binding Response; contains the MAPPED-ADDRESS
information encoded in a way the prevents intelligent NAT devices from
modifying it as the response goes through the NAT.
SOURCE-ADDRESS Appears in the Binding Response; contains the IP address and port from
which the STUN server sent its response.
CHANGED-ADDRESS Appears in the Binding Response; contains an alternate STUN server IP
address and port, different from the primary STUN server port. The STUN
client might use this attribute to perform the NAT tests described in RFC
3489.
CHANGE-REQUEST Appears in the Binding Request; instructs the STUN server to send its
response from a different IP address and/or port. The STUN client might
use this attribute to perform the NAT tests described in RFC 3489.
RESPONSE-ADDRESS Appears in the Binding Request; defines an IP address and port to which
the STUN server should send its responses. Appears in the Binding
Request;
REFLECTED-FROM Appears in the Binding Response; reflects the IP address and port from
which a Binding Request came. Only included when the Binding Request
has used the RESPONSE-ADDRESS attribute.
To perform NAT discovery, the endpoint (STUN client) sends a Binding Request to the STUN server port (IP address
and port) with which it is configured. The STUN server then returns either a;
• Binding Response—Allows the transaction to proceed
• Binding Error—Halts the transaction, and prompts the client to take the action appropriate to the response given in
the ERROR-CODE attribute
When the transaction proceeds and the STUN server sends the Binding Response, that response contains the
MAPPED-ADDRESS attribute, which contains the IP address and port from which the server received the request.
The STUN client then uses the MAPPED-ADDRESS when sending signaling messages.
For example, a SIP endpoint sends Binding Requests from its SIP port to determine the public address it should place
in SIP headers, like the Via and Contact, of the SIP requests it sends. When this SIP endpoint prepares to make or
answer a call, it sends Binding Requests from its RTP port to find out the public address it should place in SDP
included in an INVITE request or response.
If the Binding Request contains a CHANGE-REQUEST attribute, the server sends Binding Response from the IP
address and port matching the information in the CHANGE-REQUEST. The following variations can occur:
• If the IP address and port flags are set, the server selects the server port with a different IP address and different
port.
• If only the IP address flag is set, the server selects the server port with a different IP address but with the same
port.
• If only the port flag is set, the server selects the server port with the same IP address but with a different port.
The selected server port appears in the Binding Responses’s SOURCE-ADDRESS attribute. When there is no
CHANGE-REQUEST attribute, the server uses the server port on which the Binding Request was received.
Finally, the server encodes the outgoing message and sends it to the client at either:
• The destination IP address and port in the REPONSE-ADDRESS attribute, if it was present in the Binding
Request.
• The MAPPED-ADDRESS.
rfc3489bis Procedures
If the Binding Request contains the appropriate cookie in its Transaction ID, the server constructs a Binding Response
populated with the XOR-MAPPED-ADDRESS attribute. That attribute will contain the source IP address and port
from which the server saw the request come. Then the server encodes and sends the message to the client from the IP
address and port on which the request was received. The message is sent to the IP address and port from which the
request came.
Monitoring
• STUN Server Statistics—You can display statistics for the STUN server using the ACLI show mbcd stun
command when the STUN server has been enabled. However, if the STUN server has not been enabled since the
last system reboot, the command does not appear and no statistics will be displayed.
• STUN Protocol Tracing—You can enable STUN protocol tracing two ways: by configuration or on demand.
• By configuration—The Oracle Communications Session Border Controller’s STUN protocol trace file is called
stun.log, which is classified as a call trace. This means that when the system configuration’s call-trace
parameter is set to enabled, you will obtain STUN protocol information for the system. As with other call
protocol traces, tracing data is controlled by the log-filter in the system configuration.
• On demand—Using the ACLI notify mbcd log or notify mbcd debug commands, you enable
protocol tracing for STUN. Using notify mbcd debug sets the STUN log level to TRACE. You can turn
off tracing using the notify mbcd onlog or notify mbcd nodebug commands. Using notify
mbcd nodebug returns the STUN log level back to its configured setting.
SIP GRUU
SIP Globally Routable User Agent (UA) URIs (GRUU) are designed to reliably route a SIP message to a specific
device or end user. This contrasts with a SIP AoR which can refer to multiple UAs for a single user, thus contributing
to routing confusion. The Oracle Communications Session Border Controller can perform different behaviors when it
finds SIP GRUUs in Contact headers.
User agents supporting GRUU include a GRUU-identifying parameter in the Contact header of dialog forming and
target refresh requests. The Oracle Communications Session Border Controller scans for the GRUU parameter in the
Contact header either when the message is received on a realm or interface configured for registered endpoints or
when the pass-gruu-contact parameter is enabled. Configure an interface for registered endpoints by enabling nat-
traversal or registration caching.
When the Oracle Communications Session Border Controller forwards a request where the original Contact header
contains a GRUU, the contact header’s URI is forwarded unchanged on the egress side of the call. For example:
Record-Route Addition
When the request is forwarded to a realm where the endpoint’s registrar does not exist, the Oracle Communications
Session Border Controller adds a Record-Route header containing the egress SIP interface address. This causes
subsequent replies or requests addressed to the GRUU to be routed through the Oracle Communications Session
Border Controller first.
When the request is forwarded to the realm where the registrar exists, adding the Record-Route header is unnecessary
and does not occur. This is because subsequent requests are directed to the registrar which will ultimately forward
them to the Oracle Communications Session Border Controller using the registered Contact in the Request-URI.
5. options—Set the options parameter by typing options, a Space, the option name scan-for-ms-gruu.
This option forces the Oracle Communications Session Border Controller to first scan for the gruu URI parameter,
then the gr URI parameter.
6. Save and activate your configuration.
SIP-ISUP Configuration
To use this feature, you set up:
• sip-profile—Defines the redirection behavior
• sip-isup-profile—Defines the ISUP version to use when supporting SIP-T
You can then apply these profiles to realms, session agents, and SIP interfaces where you want this feature enabled.
The sip-profile configuration contains information that defines redirection behavior for the configuration where
you apply it. You can set the redirection behavior to: none, isup, or redirection. You also uniquely identify the
profile so that you can apply it by name in other configurations. This is a multiple-instance configuration, meaning
that you can set up as many SIP profiles as needed.
To set up a SIP profile:
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-profile and press Enter.
ORACLE(session-router)# sip-profile
ORACLE(sip-profile)#
4. name—Enter the name of the SIP profile. You will use this name when you apply this profile to realms, session
agents, and SIP interfaces. This parameter is required, and it has no default value.
5. redirection—Choose the redirection mode you want to use: none (default), isup, or redirection. The
inherit value is reserved for future use. Note that when you set this parameter to isup, you should configure
along with it a SIP ISUP profile; this will avoid any possible incompatibility when support for this feature expands
(as expected).
6. Save your work.
SIP-ISUP Configuration
When you want to enable this feature for a realm, session agent, or SIP interface, you configure the sip-profile
and sip-isup-profile parameters with the name of the profile you want applied.
The sample here shows this feature being applied to a session agent, but the realm and SIP interface configurations
also have the same two parameters you use to set up the feature.
To apply a SIP profile and a SIP ISUP profile to 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(configure)# session-router
ORACLE(session-router)#
3. Type session-agent and press Enter.
ORACLE(session-router)# session-agent
ORACLE(session-agent)#
4. sip-profile—Enter the name of the SIP profile, which defines the redirection behavior. This is the value you
entered in the name parameter of the SIP profile configuration. This parameter has no default value.
5. sip-isup-profile—Enter the name of the SIP ISUP profile, which defines the ISUP version to use for SIP
Diversion SIP-ISUP interworking. This is the value you entered in the name parameter of the SIP ISUP profile
configuration. This parameter has no default value.
6. Save your work.
Details
The ISUP message version is determine by one of two things: the content type of the SIP message or the MIME
content-type. When the base and version parameters do not match, the Oracle Communications Session Border
Controller first uses the base parameter value to determine the format. If there is no base, the Oracle Communications
Session Border Controller then checks the version parameter. And if there is neither, the Oracle Communications
Session Border Controller uses the isup-version configured in the sip-isup-profile configuration from
the inbound realm, session agent, or SIP interface. Available values for that parameter are ansi-2000, itu-99,
gr-317, or etsi-356. The Oracle Communications Session Border Controller considers unknown any value for
the version that fails to match one of these or is missing.
Messages that contain an unknown ISUP format pass through the Oracle Communications Session Border Controller
untouched. If there are operations to be performed on them, however, SIP ISUP HMR will take place. After the body
has been converted, the Oracle Communications Session Border Controller updates both the base and version
parameters of the content-type.
Custom formats are not supported.
the operator will compare the two values and return true only if
the left side is greater than the right side of the operator.
Reserved Words
To improve system performance and simply configuration, the Oracle Communications Session Border Controller
now supports pre-defined reserved words for commonly-used URI parameters for HMR.
Reserved words retrieve values directly from the SIP message, without your needing to create rules to store them.
Their function is similar to the $REMOTE_VIA_HOST and other already-defined variables. If the header or value
does not exist in the SIP message, either an empty string is returned or—for Boolean uses—the value FALSE is
returned.
Reserved words apply to these commonly-accessed SIP headers and their prefixes are:
• To—$TO_xxx
• From—$FROM_xxx
• Contact—$CONTACT_xxx
• Request URI—$RURI_xxx
• P-Asserted-Identity—$PAI_xxx
• P-Preferred-Identity—$PPI_xxx
• P-Called-Party-ID—$PCPID_xxx
The following table contains the list of supported reserved words and a description of each.
xxx_USER The URI name of the header without any user parameters
xxx_PHONE The URI user of the header as a phone number but without visual separators; may or may
not contains a leading plus sign (+)
xxx_HOST The URI host of the header
xxx_PORT The URI port of the header; Value set to 5060 even if it is not actually in the message
CALL_ID Resolves to the Call-ID of the current SIP message; added for convenience, and is a
common store rule
TIMESTAMP_UTC Timestamp is RFC 3339 format: 2009-10-10T22:00:09Z or YYY-MM-
DDTHH:MM:SS:PPPZ. The .PPP refers to partial seconds and is optional; time is based
on UTC.
The reserved word CRLF resolves to \r\n and is commonly used in MIME manipulation. If you are creating a new
body, there might be a need for many CRLFs in the new-value parameter.
All of these operators cause additional overhead to the HMR processing because each operator requires an evaluation
of the left and right sides of the expression. To speed up evaluation of new-value expressions, you can now enter
escapable characters (\f, \n, \r, \t, \v) with a backslash (\) and the Oracle Communications Session Border Controller
will covert them to escaped characters during the compilation of the expression (i.e., ACLI configuration time).
Reserved words that do not use the referenced header name include:
• $TARGET_* references the To-URI hostname
• $REPLY_* references the FROM-URI hostname
Reserved word names that are equal, to support legacy version configurations, include:
• $T_GROUP is the same as TRUNK_GROUP
• $T_CONTEXT is the same as TRUNK_CONTEXT
• $M_STRING is the same as MANIP_STRING (and refers to another manipulation)
Reserved variables operate just like user-defined variables. The recommended usage syntax is "$variable.$0". Use of
the $0 suffix causes the HMR to retrieve the value of the data. If the $0 is omitted then the resulting value would be
<TRUE/FALSE>.
For example, "$PAI_USER" is a valid usage. In this case, the TRUE/FALSE result could be used to determine if there
was not a username in the PAI header, or that no PAI header was present in the message.
Changes to Action
In releases prior to S-C6.2.0, the sip-manip action is only supported in the header rule (header-rule)
configuration. This limitation has been deemed unnecessary, and so you can now set the action parameter to sip-
manip at all levels of HMR configuration, including element rules.
enter a content-type value of application/sdp to manipulate specifically on the SDP portion of the SIP
message. The Oracle Communications Session Border Controller knows automatically if it is operating on SIP
messages with single or multiple body parts, and the content-type setting applies to both kinds. And when making its
comparison, the Oracle Communications Session Border Controller matches the content-type of the body with regard
to case (case insensitive), ignoring any header parameters.
Both for making comparisons against the body part and for new/replacement values, the Oracle Communications
Session Border Controller treats the match and new values you set for a MIME rule as ASCII strings. Therefor, a
mime rule operating on a binary body part will yield an improper conversion of a new value with respect to the binary
body part.
Within MIME rules, you configure MIME headers, which operate on the specific headers in the match body part of
the SIP message. The Oracle Communications Session Border Controller uses the MIME header name to run a string
comparison to match the specific header in the message’s body part.
Using these rules, you can also manipulate the preamble—or the SIP message text that follows the headers but
precedes the body separator. To do so, enter the keyword @preamble for the content type parameter in the MIME
rule. Likewise you can manipulate the epilogue—or the text that follows the last body part after the last separator—
using the keyword @epilogue.
Note that the ACLI limits character entries to 255 characters before the return character must be entered, but MIME
parts can easily exceed this 255-character size. So you might need to enter a value larger that 255 characters. To do
so, you start your entry (in the match-value or new-value parameters) with a plus sign (+). The plus sign instructs the
system to add the string after it to the pre-existing match or new value. For the new-value parameter, the Oracle
Communications Session Border Controller checks the value immediately for validity. Be sure that when you are
appending values to a new-value that the entire expression is valid at each point where strings are appended.
8. comparison-type—Enter the way that you want body part of the SIP message to be compared. This choice
dictates how the Oracle Communications Session Border Controller processes the match rules against the SIP
header. the default is case-sensitive. The valid values are: case-sensitive, case-insensitive,
boolean, refer-case-sensitive, refer-case-insensitive, and pattern-rule.
9. msg-type—Enter the SIP message type on which you want the MIME rules to be performed. Valid values are
any, request, and reply. The default value is any.
10. methods—Enter the list of SIP methods to which the MIME rules applies. There is no default for this parameter.
11. match-value—Enter the value to match against the body part in the SIP message. This is where you can enter
values to match using regular expression values. Your entries can contain Boolean operators.
12. new-value—When the action parameter is set to add or to manipulate, enter the new value that you want to
substitute.
To configure MIME headers for performing HMR operations on specific headers in the matched body part of the
SIP message:
13. Follows Steps 1 through 4 above.
14. Type mime-header-rules and press Enter.
ORACLE(sip-mime-rules)# mime-header-rules
ORACLE(sip-mime-header-rules)#
15. name—Enter a name for this MIME header rule. This parameter is required and has no default.
16. mime-header—Enter the value to be used for comparison with the specific header in the body part of the SIP
message. There is no default for this parameter.
17. action—Choose the type of action you want to be performed: none, add, delete, manipulate, store,
sip-manip, and find-replace-all. The default is none.
18. comparison-type—Enter the way that you want the header in the body part of the SIP message to be
compared. This choice dictates how the Oracle Communications Session Border Controller processes the match
rules against the SIP header. the default is case-sensitive. The valid values are: case-sensitive,
case-insensitive, boolean, refer-case-sensitive, refer-case-insensitive, and
pattern-rule.
19. match-value—Enter the value to match against the header in the body part of the SIP message. This is where
you can enter values to match using regular expression values. Your entries can contain Boolean operators.
20. new-value—When the action parameter is set to add or to manipulate, enter the new value that you want to
substitute.
21. Save your work.
• isup-parameter-rules (sub-configuration)—If you are familiar with HMR, then think of this parameter as
being similar to the element-rule for a SIP header rule. You use it to create, manipulate, and store different
parameters in the body of the ISUP message. Two parameters for this rule are unique: parameter-rule and
parameter-format.
• parameter-rule—Using ISUP parameter mapping, this setting identifies which of the ISUP parameters
on which your want to perform manipulation. This parameter takes values between 0 and 255, and you must
know the correct ISUP mapping value for your entry. The Oracle Communications Session Border Controller
calculates the offset and location of this parameter in the body. Note that the value returned from the body does
not the type or length, only the parameter value. For example, a parameter-type value of 4 acts on the Called
Party Number parameter value.
In accordance with the ISUP specifications, only certain message types are allowed to have optional
parameters. And if optional parameters are present, an offset field must exist for them; so its value is 0 even if
there are no optional parameters in the SIP message. For example, if you define a SIP ISUP rule that applies to
all message types and adds a parameter that is neither fixed nor variable, The system adds it as an optional
parameter regardless of whether that message type should not support optional parameters.
If you define an ISUP parameter rule with an add action and an empty new-value, the Oracle
Communications Session Border Controller uses the default for that parameter. If you define an ISUP
parameter rule with a replace action and no parameters exist, the Oracle Communications Session Border
Controller will not perform any action. This behavior is consistent with that of SIP header rules in that a value
can only be replaced if it already exists. If there is a value and no new value is set, the Oracle Communications
Session Border Controller set it as a zero-length parameter.
• parameter-format—This parameter converts the specific parameter to a string representation of that
value. Valid values for parameter-format are: number-param, hex-ascii (default), binary-
ascii, ascii-string, and bcd.
Both match and new values are encoded and decoded by the designated parameter-format type. In this regard,
the match-value decodes the parameters and the new-value encodes the ASCII string into the respective
binary format.
Note if you enter a new-value setting larger than the size of the parameter, the Oracle Communications Session
Border Controller will perform no operation and will generate a corresponding error log message.
The following table provides information about the values you can enter:
parameter-format Description
Setting
hex-ascii Default.
Converts the entire binary body. Non-hexadecimal characters fail in matching
against the body part if they are in the match-value setting and non-hexadecimal
characters places in a new-value setting result in no operation being formed.
binary-ascii Converts each hexadecimal value to its corresponding string, binary representation.
For example, the Oracle Communications Session Border Controllerwould convert
the ISUP parameters with a hexadecimal binary value of 8A to 10001010. Non-
binary digit characters fail when matching against the body part if they are contained
in the match-value setting and non-binary characters in the new-value setting results
in no operation being performed.
ascii-string Treats the binary parameter as true ASCII in raw format. The Oracle
Communications Session Border Controller supports only the printable range of
ASCII characters.
If a value in the ISUP parameters cannot be decoded to ASCII, the Oracle
Communications Session Border Controller returns an empty string. Non-printable
parameter-format Description
Setting
bcd In ISUP speak, BCD refers to the binary forma of the number used as a half a byte
nibble, with the byte’s lower nibble containing the first digit and the higher
containing the second digit. For example, the number 127 is encoded as the two
binary bytes 0x2107 on the wire.
Using this mode, the Oracle Communications Session Border Controller treats the
binary ISUP content as BCD; it should decode it from 0x2107 to the string 1270,
and from a string of 127 it should decode it as 0x2107.
Since a byte has two nibbles, a nibble might have to be added. And when the Oracle
Communications Session Border Controller performs decoding, it cannot know that
a BCD byte represents one or two ASCII digits—so it assumes there are two. The
number-param setting decodes the parameter as a common number parameter. The
Oracle Communications Session Border Controller sees the odd/even bit as in the
first bite as telling it how many nibbles to decode correctly, and it will set the odd-
even when it decodes.
Non-binary digit characters fail to match against the body part if they are contained
in the match value, and non-binary characters in the new value results in no
operation being performed.
number-param As the decimal value of the specified number type, treats the parameters as a generic
number parameter type. For example, a parameter-type 4 acts on the Called Party
Number parameter.
When the action type is replace or add, the Oracle Communications Session Border
Controller automatically sets the parameter’s odd-even bit based on the number
being inserted in relation to the new-value setting. If the Numbering Plan Indicator
bits are 0b001 (ISDN, E.164), then the Oracle Communications Session Border
Controller sets the Nature of Address field to 0b0000100 (international). If this
number type is added to a non-existent parameter field, then the Numbering Plan
Indicator field is 0b0000011 (national number). If this number type is added to a
non-existent parameters field, then the Numbering Plan Indicator field will be set to
0b001 (ISDN,E.164) and the Oracle Communications Session Border Controllerwill
also follow the previous rules.
Regardless of the action type you set, the string represented for match-value use for
this type will be the numbers of the address fields after the BCD coding. There will
be a leading plus sign (+) if the Number Plan is 0b001 and the Nature of Address is
0b0000100 ((international); otherwise, there will not be a plus sign (+).
If it cannot convert the data field to a number parameter, the Oracle
Communications Session Border Controller will return an empty string. And if the
new-value is not in digit form or cannot fit in the specified parameter type field, the
Oracle Communications Session Border Controller takes no action.
• You can create a mime-isup-rule with the action type set to add, and enter the entire body in string
hexadecimal form in the new-value parameter.
• You can leave the new-value parameter empty at the mime-isup-rule level and create an add rule for an
isup-param-rule.
In this case, the Oracle Communications Session Border Controller creates the corresponding ISUP message
based on the isup-msg-type value and supply all of the parameters with their default values. Since the isup-
msg-type takes a list of values as a valid entry, for this case it only uses the first one. However, the Oracle
Communications Session Border Controller ignores the isup-msg-type value if you set the new-value
parameter. And the isup-param-rule, if configured, overwrite the default value or add a new parameter
based on the defined parameter type.
It is also possible that you might supply a new-value both at the mime-isup-rule level and at the isup-
param-rule level. If you do, the new-value entry from the mime-isup-rule is parsed into an ISUP
object and the isup-param-rule operates on that object.
12. new-value—When the action parameter is set to add or to manipulate, enter the new value that you want to
substitute.
13. isup-spec—Specify how the Oracle Communications Session Border Controller is to parse the binary body;
valid values are the enumerated type. The values for this parameter are these SIP ISUP formats:
• ANSI-2000 (default)—Corresponding to ANSI T1.113-2000
• ITU-99—Corresponding to ITU Q.763
14. isup-msg-type—Identify the specific ISUP message types (such as IAM and ACM) on which to operate. The
Oracle Communications Session Border Controller uses with the msg-type parameter (which identifies the SIP
message) in the matching process. You enter values in this parameters as a list of numbers rather than as an
enumerated value because of the large number of ISUP message type, and the range is between 0 and 255. There
is no default for this parameter.
15. mime-header—Enter the value to be used for comparison with the specific header in the body part of the SIP
message. There is no default for this parameter.
To configure ISUP parameters rules:
16. Follows Steps 1 through 4 above.
17. Type isup-parameter-rules and press Enter.
ORACLE(sip-mime-isup-rules)# isup-param-rules
ORACLE(sip-isup-param-rules)#
18. name—Enter a name for this ISUP parameter rule. This parameter is required and has no default.
19. mime-header—Enter the value to be used for comparison with the specific header in the body part of the SIP
message. There is no default for this parameter.
20. action—Choose the type of action you want to be performed: none, add, delete, manipulate, store,
sip-manip, and find-replace-all. The default is none.
21. comparison-type—Enter the way that you want the header in the body part of the SIP message to be
compared. This choice dictates how the Oracle Communications Session Border Controller processes the match
rules against the SIP header. the default is case-sensitive. The valid values are: case-sensitive,
case-insensitive, boolean, refer-case-sensitive, refer-case-insensitive, and
pattern-rule.
22. match-value—Enter the value to match against the header in the body part of the SIP message. This is where
you can enter values to match using regular expression values. Your entries can contain Boolean operators.
23. new-value—When the action parameter is set to add or to manipulate, enter the new value that you want to
substitute.
24. parameter-type—Using ISUP parameter mapping, enter which of the ISUP parameters on which your want
to perform manipulation. This parameter takes values between 0 and 255, and you must know the correct ISUP
mapping value for your entry. The Oracle Communications Session Border Controller calculates the offset and
location of this parameter in the body. Note that the value returned from the body does not the type or length, only
the parameter value. For example, a parameter-type value of 4 acts on the Called Party Number parameter value.
25. parameter-format—Enter how you want to convert specific parameter to a string representation of that value.
Valid values for parameter-format are: number-param, hex-ascii (default), binary-ascii,
ascii-string, and bcd. Both match and new values are encoded and decoded by the designated parameter-
format type. In this regard, the match-value decodes the parameters and the new-value encodes the ASCII
string into the respective binary format.
26. Save your work.
Configuration Example
This section provides an example of a SIP manipulation configuration that shows MIME rules and MIME ISUP rules.
sip-manipulation
name manip
description
header-rule
v=0
o=- 3462189550 3462189550 IN IP4 192.168.200.49
s=pjmedia
c=IN IP4 192.168.200.49
t=0 0
m=audio 20000 RTP/AVP 0 8 101
When the Oracle Communications Session Border Controller terminates a session it sends a BYE to both the
ingress and egress call legs. If accounting is configured, the Oracle Communications Session Border Controller
also sends a RADIUS stop record with Acct-Terminate-Cause = Session-Timeout. You can enable or disable the
use of the session timers using the ACLI interface at session-router > sip-config > options.
Note: To disable session timers, you must add a minus sign (-) before the session-timers-support value.
When the Oracle Oracle Communications Session Border Controller receives an INFO DTMF request, the SIP
process determines whether or not it needs to perform DTMF-to-RFC2833 translation. If translation is required, the
process forwards the DTMF to the 2833 convert process for translation and transmission to the recipient. Immediately
after off-loading the DTMF, the SIP process sends a 200 OK response for the INFO. As shown in the figure, the 2833
convert process generates a number of RFC2833 packets to represent received DTMF digits.
Specifically, the 2833 convert process generates one RFC 2833 packet every 50 milliseconds for the duration of the
DTMF digit, whose length is specified in the INFO request, and two retransmits of the last packet (known as the end
packet) 50 milliseconds apart.
Consequently, the time interval between the 200 OK and the actual transmission of the RFC 2833 translation is the
sum of the DTMF duration and 100 ms.
Note: This time interval can be shortened to 100 ms by enabling the rfc2833-end-pkts-only-for-non-sig
parameter in media-manger which results in SD only generating the last packet and its two retransmits.
The early 200 OK allows the endpoint to send the next DTMF digit before the SD has sent all the RFC2833 packets,
resulting in the next digit being queued internally by the 2833 convert process before being sent.
A problem arises if the SIP process receives a BYE request from the DTMF originator while queued digits are
awaiting translation and transmission. In such an event, the SIP process immediately forwards the BYE request to the
recipient, ending the session with DTMF digits awaiting translation and transmission.
An alternative DTMF conversion model provides for a feedback mechanism from the 2833 convert process to the SIP
process. With this model enabled, the SIP process buffers a received BYE until it obtains confirmation that all queued
DTMF digits have been translated and transmitted. Only after obtaining confirmation, does it forward the BYE to
terminate the session.
This processing model is enable by a SIP option, sync-bye-and-2833, and requires that rfc2833-mode
parameter on the egress interfaces is NOT set to dual , any value other than dual , is supported.
1. From superuser mode, use the following command sequence to access sip-config configuration mode.
ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# sip-config
ORACLE(sip-config)#
2. Use the SIP option sync-bye-and-2833 to delay BYE processing until DTMF-to-RFC2833 translation has
been completed.
ORACLE(sip-config)# options +sync-bye-and-2833=”enabled”
ORACLE(sip-config)#
3. Use the done and exit commands to complete configuration.
ORACLE(sip-config)# done
ORACLE(sip-config)# exit
ORACLE(session-router)#
A KPML NOTIFY request is sent for each 2833 DTMF entered, until the subscription is terminated.
selection: 1
ORACLE(sip-interface)#
3. kpml-interworking—Set this parameter to enabled to use KPML-2833 interworking.
4. Type done to save your configuration.
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 your work.
When LMSD interworking is configured on a SIP interface, and in the case that an early dialog has been established
(a dialog where the final 2xx class response to INVITE request has not yet arrived), some call flows include an
UPDATE later in the call. The Oracle Communications Session Border Controller now forwards the Update message,
SDP included, directly to the UAC, whereas before it responded to the UAS's UPDATE locally.
UPDATE (SDP2_A)
UPDATE (SDP2_A’)
ACK ACK
force-reinvite—Sets if the Oracle Communications Session Border Controller will send a reINVITE to refresh
the session timer when applicable.
request-refresher—Set on the outbound side of a call what the Oracle Communications Session Border
Controller sets the refresher parameter to. Valid values are uac, uas, or none.
response-refresher—Set on the inbound side the value of the refresher parameter in the 200OK message.
Valid values are uac or uas.
In this section, the notion that a UAC or UAS supports Session Timers is indicated by the presence of the Supported:
timer header and option tag.
Refresher
The initial UAC, the side that sends the INVITE, can set itself to be the refresher (uac) or the Oracle Communications
Session Border Controller as the refresher (uas). Whoever is the refresher is indicated in the 200 OK. If the UAC does
not specify any refresher, the Oracle Communications Session Border Controller uses it’s response-refresher value in
the 200 OK. If that value is set to uas, the Oracle Communications Session Border Controller creates and sends a re-
INVITE toward the UAC with previously negotiated session expiration values.
Once the Oracle Communications Session Border Controller becomes the refresher, it does not relinquish that role.
Then, when the Oracle Communications Session Border Controller sends refresh requests, it does not change any
parameters (refresher role & timers) from the initial request negotiation.
UAC does not Support Session Timers
If the UAC’s initial request does not include a Session-Expires: header, then the 200 OK will include the session-
timer-profile > session-expires value on the ingress leg in the Session-Expires: header.
The Oracle Communications Session Border Controller also inserts the refresher parameter as configured. The
orientation of UAC/UAS on the Oracle Communications Session Border Controller’s view of a call leg can change if
later in the call flow the endpoint designates the Oracle Communications Session Border Controller as the refresher.
Note: When the request doesn't support Session Timers, the Oracle Communications Session Border
Controller’s reply adds session timer support according to configuration.
If the Oracle Communications Session Border Controller receives a message with a Require: timer header, and the
inbound SIP interface or the final UAS do not support session timers, a 420 (Bed Extension) is returned to the UAC.
Session Refreshes
On either side of the call, the Oracle Communications Session Border Controller can be responsible for initiating the
session refreshes or responding to the session refreshes.
Timer Expiration
If the Oracle Communications Session Border Controller fails to receive a session refresh request before the session
expiration, the session will be terminated before the full session time. This is computed according to:
After the real expiration time elapses, the Oracle Communications Session Border Controller sends a BYE request in
both directions to terminate the session.
Examples
Require: timer
SE: 500; refresher=uac
ACLI Configuration
To configure a session timer profile object:
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-timer-profile and press Enter. The system prompt changes to let you know that you can
begin configuring individual parameters.
ORACLE(session-router)# session-timer-profile
ORACLE(session-timer-profile)#
4. name—Enter a name for this session timer profile.
5. session-expires—Enter the session timer value in seconds you wish this object to use natively.
6. min-se—Enter the minimum session timer value in seconds for this object.
7. force-reinvite—Leave the default of enabled for the Oracle Communications Session Border Controller to
always use reINVITEs for session refreshes. Set this parameter to disabled for the Oracle Communications
Session Border Controller to try using UPDATEs for session refreshes.
8. request-refresher—Set this to the value to insert in the refresher parameter in the Session-Expires: header
on the originating call leg that the Oracle Communications Session Border Controller includes in the 200 OK
response message. Valid values are uac and uas.
9. response-refresher—Set this to the value to insert in the refresher parameter in the Session-Expires:
header on the terminating call leg that the Oracle Communications Session Border Controller includes in the
INVITE message. Valid values are uac, uas, none.
10. Type done to save your work and continue.
To apply a session timer profile to a SIP interface:
11. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
12. Type session-router and press Enter.
ORACLE(configure)# session-router
ORACLE(session-router)#
13. Type sip-interface and press Enter.
ORACLE(session-router)# sip-interface
ORACLE(sip-interface)#
If you are adding this feature to an existing configuration, then you will need to select the configuration you want
to edit.
14. session-timer-profile—Enter the name of a session timer profile object you have configured and want
applied to this SIP interface.
15. Type done to save your work and continue.
show registration
The show registration command displays the total number of endpoints associated with secondary
interfaces, and the total number of endpoints marked to receive a 305 response.
Note: The total number of SIP calls to receive a 305 response are included in the Registrations marked for
305 counter.
The total number of SIP calls associated with secondary realms are included in this count.
AcmePacket# show registration
11:02:13-102
SIP Registrations -- Period -- -------- Lifetime --------
Active High Total Total PerMax High
User Entries 1 1 1 1 1 1
...
Secondary Interface Registrations=NNN
Registrations marked for 305=MMM
access1: N1
access2: N2
SNMP Configuration
To configure the threshold for the number of registrations on secondary SIP interfaces in order to generate a trap:
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 sip-config and press Enter. The system prompt changes to let you know that you can begin
configuring individual parameters.
ACMEPACKET(session-router)# sip-config
ACMEPACKET(sip-config)#
4. options—Type sec-reg-threshold =X, where X equals the number of registrations received on all
secondary interfaces. Once that number has been reached, the apSipSecInterfaceRegThresholdExceededTrap is
generated.
ACMEPACKET(session-router)# options secondary
5. options—Type sec-reg-threshold-clear =Y. When the number of registrations received on all
secondary interfaces drop below Y, the apSipSecInterfaceRegThresholdExceededClearTrap is generated.
Note: The value of sec-reg-threshold-clear =Y must be less than sec-reg-threshold =. The values cannot be
equal.
ACMEPACKET(session-router)# options secondary
SNMP
The apSipSecInterfaceRegThresholdExceededTrap trap is generated when the total count of all registrations on the
secondary interfaces cross sec-reg-threshold-exceed is exceeded.
An alarm is also generated for this event. The severity of the alarm is configured in the sec-reg-threshold-
alarm-severity option.
Hardware Alarms
APP_ALARM_SEC 0X5001 Minor by The total Number of apSyslogMessageGenerated
_INTF_REG_EXCE 8 default. The number of Secondary
(ap-slog.mib)
ED severity is registrations on Interface
configurable. all secondary registrations apEnvMonStatusChangeNot
SIP interfaces <total> has ification
exceeds the exceeded the (ap-env-monitor.mib)
configured secondary
apSysMgmtFanTrap
threshold. interface
(ap-smgmt.mib)
registration
threshold of
<max>.
The configuration information shown in the diagram can help you to understand how some basic Oracle
Communications Session Border Controller concepts work. The providers in this depiction are configured as realms,
and the strategies you see are for session agent group. What you do not see in this diagram is the fact that the Oracle
Communications Session Border Controller is configured with sets of H.323 interfaces within it. These interfaces are
internal (for an internal provider) and external (for the external providers you see).
Overview
Using H.323 on your Oracle Communications Session Border Controller, you can implement different signaling
modes and use features to enhance H.323 capabilities. In the information that follows, you will find detailed
explanations of the H.323 signaling mode and of the features available. This chapter gives operational details and
later outlines the steps you need to take when features require configuration.
When configured as a B2BGW, the Oracle Communications Session Border Controller appears as multiple H.323
gateways to multiple networks. You can think of the Oracle Communications Session Border Controller as having
virtual gateways, that discovers and registers with a gatekeeper in its respective domain. In this configuration, you
need to set the service mode (isgateway) parameter for the H.323 interface to enabled for two H.323 interfaces.
These interfaces are related either through their outgoing interface (assoc-stack) parameters or through routing
policies.
If you configure your Oracle Communications Session Border Controller to operate in this mode, it does not issue or
respond to LRQs by either confirming them or rejecting them.
In the diagram above, the Oracle Communications Session Border Controller sends ARQs to the corresponding
gatekeeper in its zone when a call is received on the associated interface. In this behavior, the Oracle Communications
Session Border Controller acts as a gateway, complying with the H.323 standard, and registers with the configured
gatekeeper in its assigned zone. You set all parameters related to the gateway registrations, such as gateway prefix
numbers, in the H.323 interface configuration.
In this mode, you can also configure the Oracle Communications Session Border Controller to run like a gateway
without a gatekeeper by turning off automatic discovery (auto-gk-discovery) for the remote gatekeeper. When the
Oracle Communications Session Border Controller receives a Setup message, it does not send an ARQ and there is no
registration for admission requests. Without automatic gateway discovery, the Oracle Communications Session
Border Controller uses the local policy to find the appropriate destination for the call. This destination is normally the
IPv4 address of the endpoint or gateway, using the well-known port 1720.
If you enable this capability, then the Oracle Communications Session Border Controller finds a gatekeeper.
In this application, with the service mode (isgateway) parameter set to disabled, the Oracle Communications
Session Border Controller responds to LRQs and issues LCFs and LRJs. It sends LRQs and LCFs/LRJs to the local
IPv4 address for the H.323 interface. The Oracle Communications Session Border Controller responds to the LRQs
by providing a signaling address that performs gateway functions.
When you use it as a back-to-back gatekeeper proxy and gateway, the Oracle Communications Session Border
Controller does not issue ARQs. In addition, all parameters related to registration, such as gateway prefix numbers,
are ignored.
When you do not configure a gatekeeper, the Oracle Communications Session Border Controller uses the local policy
to find the appropriate destination for the call. If there is a matching local policy, the Oracle Communications Session
Border Controller returns an LCF to the originating gateway. If no local policy matches, the Oracle Communications
Session Border Controller rejects the call by sending an LRJ.
Interworking Gatekeeper-Gateway
This section explains how signaling takes place when the Oracle Communications Session Border Controller
functions as an interworking gatekeeper-gateway for H.323. The following diagram shows the Oracle
Communications Session Border Controller acting as an interworking gatekeeper-gateway.
When you configure your Oracle Communications Session Border Controller for interworking gatekeeper-gateway
mode, one H.323 interface behaves as a B2BGW and its associated interface for the corresponding network behaves
like a gatekeeper proxy and gateway. The interface for the gatekeeper proxy and gateway issues and responds to LRQ
messages on its network. If the Oracle Communications Session Border Controller knows the gatekeeper in the
network of the gateway interface (Zone 2), it sends an LRQ to that gatekeeper. If the gatekeeper responds with an
LCF or LRJ, the Oracle Communications Session Border Controller forwards it.
If the gatekeeper (in Zone 2) is unknown, then the Oracle Communications Session Border Controller responds to
LRQs on the gatekeeper-gateway network (Zone 1) by using the local policy to determine the appropriate destination
for the LRQ. If there is no local policy that matches, then the Oracle Communications Session Border Controller
sends an LRJ.
For this configuration, the gateway interface has its service mode (isgateway) set to enabled, and the gatekeeper
interface has its service mode (isgateway) set to disabled.
You should also decide how you want to set up realms and routing (including the use of session agents and session
agent groups) to support H.323 operations.
Receiving a Proceeding or Alert message from the endpoint does not keep this timer from expiring.
4. options—Set any options for H.323 features that you want to use. This parameter has a global impact on H.323
behavior, rather that being applied on a per-interface basis.
If you do not configure options for global H.323 behavior, none appears in the configuration display.
5. log-level—Set the process log level for monitoring all H.323 activity on the Oracle Communications Session
Border Controller. The default is INFO and leaving this parameter set to this value provides an intermediate
amount of detail in the logs. Other valid values are:
Note: Any log level you set here overrides the log level you set in the system configuration’s process log
level parameter.
H.323 Interfaces
You need to configure H.323 interfaces for inbound and outbound traffic. When you configure H.323 interfaces, you
can set:
• Identity and state
• Realm and H.323 interface associations
• H.323 interface settings for the interface’s IPv4 address, RAS and Q. 931 ports, maximum number of Q.931 ports
to allow, and any Annex E support you need
• H.323 system resource allocation
• Maximum—65535
If you set this parameter to 0, the Oracle Communications Session Border Controller uses a port assigned by
the operating system.
3. q931-port—Enter the number for the port on the local IP address for the Q.931 call signaling port. We
recommend that you leave this parameter set to its default, 1720. The valid range is:
• Minimum—0
• Maximum—65535
4. q931-max-calls—Enter the maximum number of concurrent Q.931 calls you want to allow. The default value
is 200; however, this value should be less than the maximum number of calls you set when configuring H.323
features. The valid range is:
• Minimum—0
• Maximum—65535
If the number of received Q.931 calls exceeds this number, the H.323 interface returns a busy state.
5. alternate-transport—Enter a list of one or more Annex E IPv4 address and port combinations for
alternate transport. If you do not configure this list, then the Oracle Communications Session Border Controller
does not listen for incoming Annex E requests. You must enter the IPv4 address and port combination in the
following format, where the two are separated by a colon: IPv4Address:Port.
1. process-registration—To have the Oracle Communications Session Border Controller drop all RRQs,
meaning that it does not acknowledge any requests, leave this parameter set to disabled, its default. To have
the Oracle Communications Session Border Controller process any RRQs that arrive on this H.323 interface, set
this parameter to enabled. Valid values are:
• enabled | disabled
When registration processing is enabled and the Oracle Communications Session Border Controllerreceives an
RRQ on this H.323 interface, it will route the request to the appropriate gatekeeper. After the gatekeeper
confirms that registration with an RCF, the Oracle Communications Session Border Controller also confirms it
with the endpoint that sent the RRQ. Then the registration becomes part of the Oracle Communications
Session Border Controller’s registration cache. If this endpoint does not confirm the registration, then the
Oracle Communications Session Border Controller will reject the registration with an RRJ and will not cache
it.
2. proxy-mode—Set this field to the proxy mode that you want to use for the signaling only operation mode. Valid
values are:
• H.225 | H.245
You can leave this field blank (default) if you are not using a proxy mode.
3. h245-stage—Set this field to the stage at which the Oracle Communications Session Border Controller
transfers the H.245 address to the remote side of the call, or acts on the H.245 address sent by the remote side. The
default value is connect. Valid values are:
• Setup | Alerting | Connect | Proceeding | Early | Facility | noh245 | Dynamic
H.323 Features
This section provides general descriptions of the H.323 features available on the Oracle Communications Session
Border Controller and instructs you in how to configure them. Not all of the features described in that chapter require
configuration.
In a Fast Start call, the originating H.323 endpoint sends a fastStart element in its Setup message. This element
contains H.245 OLC messages that allow Fast Start endpoints to establish a media stream when the call is connected.
As a result fewer messages are exchanged between the H.323 endpoints than there would be for a Slow Start call
(where the fastStart element does not appear). Because media information is sent in the Setup request for the session,
there is no need to use the media profiles when converting a Fast Start call to Slow Start.
When you enable the slow start option in the H.323 stack configuration, the Oracle Communications Session Border
Controller performs Fast Start to Slow Start conversion. During the translation, the Oracle Communications Session
Border Controller retains the media information included in the incoming Fast Start call as it negotiates a connection
with the Slow Start endpoint. After a connection with the Slow Start endpoint has been established, the Oracle
Communications Session Border Controller negotiates the media capabilities.
Communications Session Border Controller Feature chapter describes how the media profiles are used. The list
contains the names of media profiles that you configure in the media profile configuration.
Some media profiles are configured by default. If the information you have configured for a media profile collides
with the defaults, then your configured ones are loaded. If there are no collisions, then the Oracle Communications
Session Border Controller loads the configured and default profiles. The default media profiles are:
audio 0 PCMU 0
audio 2 G726-32 0
audio 4 G723 0
audio 8 PCMA 0
audio 9 G722 0
audio 15 G728 0
audio 18 G729 0
audio 101 telephone-events 0
Ensure that you use the name of a configured media profile when you enter values in the media profiles list.
Note: When you use the RTP/AVP transport method, this value must be numeric.
7. transport—Enter the type of transport protocol used in the SDP rtpmap attribute. The default is RTP/AVP.
Valid values are:
• RTP/AVP | UDP
8. req-bandwidth—Enter the total bandwidth in kilobits that the media requires. The default value is 0. The
valid range is:
• Minimum—0
• Maximum—4294967295
9. frames-per-packet—Enter the maximum number of frames to use per RTP packet. Leaving this parameters
set to 0, its default value means that it is not being used. The valid range is:
• Minimum—0
• Maximum—256
The interpretation of this value varies with codec type and with specific codec.
• For frame-based codecs, the frame size is specific to each. For example, a G.729 frame contains ten
milliseconds of audio, while a G.723.1 codec frame contains thirty milliseconds.
• For sample-based codecs such as G.711, each frame contains one millisecond of audio.
10. parameters—Enter additional codec information. For example, the G.723.1 codec can have an additional
silenceSuppression parameter.
11. average-rate-limit—Enter the maximum speed in bytes per second for the flow that this media profile
applies to. The default value is 0. The valid range is:
• Minimum—0
• Maximum—125000000
12. peak-rate-limit—Enter the peak rate for RTP flows in bytes per seconds. The default is 0. The valid range
is:
• Minimum—0
• Maximum—125000000
13. max-burst-size—Enter the maximum data size at peak rate in bytes. The default is 0. The valid range is:
• Minimum—0
• Maximum—125000000
14. sdp-bandwidth—Enable this parameter to use the AS bandwidth modifier in the SDP in the conditions for the
application specific bandwidth modifier. The default is disabled. Valid values are:
• enabled | disabled
15. sdp-rate-limit-headroom—Specify the percentage of headroom to be added while using the AS
bandwidth parameter while calculating the average-rate-limit (rate limit for the RTP flow). The default is
0. The valid range is:
• Minimum—0
• Maximum—100
H.235 Encryption
Following the ITU-T H.235 encryption standard, the Oracle Communications Session Border Controller allows media
(audio, video, and data) media that has already been encrypted by endpoints to pass through it, thereby supporting
videoconferencing applications where media confidentiality is key. The ITU-T standard provides a profile with key
management using Diffie-Hellman keys and the specification of an encryption algorithm.
Specifically, the Oracle Communications Session Border Controller permits the following:
• H.225 Setup and connect—The tokens parameter and its subfields in H.225 Setup and Connect message to pass
transparently through the Oracle Communications Session Border Controller
• H.245Teminal CapabilitySet—The H.245 TerminalCapabilitySet messages to pass transparently through the
Oracle Communications Session Border Controller, including:
• Audio, video, and data capabilities
You do not need to follow special configuration steps to enable this functionality; it works automatically.
• Preferred: the Oracle Communications Session Border Controller only generates and detects 2833 for endpoints if
they negotiate support for 2833 through signaling
• Transparent: the Oracle Communications Session Border Controller behaves as it has prior to this release, offering
and answering based on end-to-end signaling and transparently relaying 2833
method. The Oracle Communications Session Border Controller transparently relays the DTMF as it has in previous
releases.
With transparent 2833, the Oracle Communications Session Border Controller acts as a typical B2BUA or
B2BGW/GK. However when the target of the call is configured as preferred 2833, the Oracle Communications
Session Border Controller:
• Relays the 2833 packets if the originating endpoint signals 2833 and the next-hop endpoint for the preferred target
signals 2833
• Performs 2833 translation if the originating endpoint does not signal 2833 and the next-hop endpoint for the
preferred target does signal 2833
• Does not perform 2833 translation or transparently relay 2833 if the originating endpoint signals 2833 and the
next-hop endpoint for the preferred target (or even a transparent 2833 target) does not signal 2833.
If the Oracle Communications Session Border Controller is the answering device, configured for preferred support,
and the calling device sends 2833, the Oracle Communications Session Border Controller accepts the 2833 regardless
of the next-hop’s DTMF capabilities. The received dynamic RTP payload type is used for detecting 2833 packets,
while the response dynamic payload type is used for generating 2833 packets.
The Oracle Communications Session Border Controller supports:
• RFC-2833 audio telephony events in the version 4 H.323/H.245 TCS as the H.323 calling gateway, when the
Oracle Communications Session Border Controller calls an H.323 endpoint configured for preferred RFC 2833
support. The Oracle Communications Session Border Controller sends 2833 to the called party regardless of
whether the calling party sends it.
• H.245 UII and RFC-2833 packets sent at the same time, to the same endpoint, even if only half of the call is being
provided 2833 support by the Oracle Communications Session Border Controller.
If one half of the call supports H.245 UII, and the other half is being provided 2833 translation by the system, the
Oracle Communications Session Border Controller can also forward the H.245 UII it receives to the 2833
endpoint. For example, when the signaling goes through a gatekeeper or third party call control, sending the H.245
UII in the signaling path allows those devices to learn the DTMF digits pressed.
H.323 Endpoints
Because there are different H.323 endpoints based on different versions of H.323, the DTMF can be either be
transferred out-of-band as UII or in-band using RFC 2833. Most H.323 endpoints:
• version 4 and above support RFC 2833
• version 2 and pre-version 4 support UII-Signal
• version 1 and pre-version 2 support UII-Alphanumeric
• preferred—The H323 stack uses 2833 for DTMF transfer, which it signals in its TCS. However, the
remote H323 endpoint makes the decision. If the endpoint supports 2833, 2833 is used. If not, the H.323 stack
reverts back to using UII. You configure the payload format by configuring the h323-config element.
• preferred:—2833 for DTMF transfer is preferred, which is signaled in the TCS. If the endpoint supports
2833, 2833 is used. If not, the H.323 stack configured as preferred will revert back to using UII. This overrides
any configuration in the h323-stack even if the stack is configured for transparent mode.
5. rfc2833-payload—Enter a number that indicates the payload type the session agent will use for RFC 2833
packets while interworking 2833 and UII. The default value is 0. The valid range is:
• Minimum—0, 96
• Maximum—127
To use virtual call signaling addresses, you specify a Q.931 port range from which the Oracle Communications
Session Border Controller can allocate ports. This port range is associated with the virtual call signal IPv4 address
you specify. To bind dynamic TCP connections to aport within a port range, you configure a dynamic H.245 port
range. The dynamic H.245 port range refers to the separate TCP connection for H.245 that takes place when tunneling
is not being used. This enables the Oracle Communications Session Border Controller to select the port to which the
TCP socket is bound. These two port ranges cannot overlap.
When a new RRQ has to be forwarded to the gatekeeper, the Oracle Communications Session Border Controller
caches the registration and then forwards a modified copy of the RRQ. The Oracle Communications Session Border
Controller allocates a virtual call signal address on the gateway stack and uses it to replace the CSA of the registering
endpoint in the forwarded RRQ.
• It allows the gatekeeper stack to use the registration information to route calls from other realms to the endpoints
in its realm.
For registration caching, you need to configure at least two H.323 interfaces:
• One gatekeeper interface to receive registrations
• One gateway interface to proxy registrations
The Oracle Communications Session Border Controller caches all successful registrations, using the cache to route
calls back to the associated endpoint.
The following diagram shows how RRQs flow during registration caching.
Configuration Requirements
For the Oracle Communications Session Border Controller to determine where to route an RRQ, either the associated
stack parameter or the gatekeeper identifier field is used.
First, the Oracle Communications Session Border Controller uses the associated interface (assoc-stack) of the
gatekeeper interface to find the interface for the outgoing RRQ. If you do not configure an associated interface and
the incoming RRQ has a gatekeeperIdentifier field, the Oracle Communications Session Border Controller finds a
configured gateway interface with a matching gk-identifier field and use it as the outgoing interface. If the incoming
RRQ does not have a gatekeeperIdentifier field and the gatekeeper interface has a configured gatekeeper identifier,
the Oracle Communications Session Border Controller finds a gateway interface with a gatekeeper identifier that
matches the one set for the gatekeeper interface and then use it as the outgoing interface. If an outgoing interface
cannot be determined, the Oracle Communications Session Border Controller rejects the RRQ with the reason
discoveryRequired.
A configured H.323 interface can be the gateway interface for more than one gatekeeper interface. If a call is received
on the gateway interface, the registration cache will be queried to find a registration matching the call’s destination. If
a registration is found, the interface on which the registration was received will be used as the outgoing interface for
the call.
Subsequent ARQ or URQ messages coming from a registered endpoint will be proxied to the gatekeeper using the
outgoing gateway interface established during registration. If a registration is not found, an ARJ or a URJ will be sent
to the endpoint originating the ARQ or URQ.
A gatekeeper interface can respond to a GRQ if the GRQ is received on its RAS interface. The Oracle
Communications Session Border Controller supports GRQ on a multicast address.
H.245 Stage
The Oracle Communications Session Border Controller allows you to set the earliest stage in an H.323 call when the
Oracle Communications Session Border Controller initiates the procedure to establish an H.245 channel for the call.
If you have enabled H.245 tunneling by setting the h245-tunneling parameter to enabled, then you do not need to
configure your system for this feature.
The Oracle Communications Session Border Controller initiates the H.245 procedure by either:
Message Received with H.245 Address Message Sent with H.245 Address
Progress Progress
Alerting Alerting
Connect Connect
Facility Facility
When it receives the first H.225/Q.931 message with an H.245 address in the outgoing call, the Oracle
Communications Session Border Controller creates a listening socket on the incoming interface. It also includes the
socket address and port in the H.245 address of the next H.225/Q.931 message that it sends. If there is no pending H.
225/Q.931 message for the Oracle Communications Session Border Controller to send, it instead sends a Facility
message with the reason startH245. Then the H.245 channel is established when a TCP connection is made to the
listening socket.
For the outgoing leg of a call that came in on the H.323 stack configured for H.245 dynamic stage support, the Oracle
Communications Session Border Controller starts establishing the H.245 channel when it receives the first H.225/Q.
931 message with H.245 address information. It also starts to establish a TCP connection to the address and port
specified in the H.245 address information. The H.245 channel for the outgoing call is established while the H.245
address (h245Address) is sent in the incoming call as described above.
H.323 HNT
This section explains how H.323 hosted NAT traversal (HNT) works and how to enable this capability on your Oracle
Communications Session Border Controller.
The feature enables endpoints behind NATs to originate and terminate calls by resolving the address differences
between the NAT and the actual endpoint.
H.323 communication through a NAT becomes an issue when engaging in RAS messaging. While the H.323 standard
specifies specific information elements in the RAS messages that indicate the address to which the replies should be
sent, these addresses will be behind the NAT and therefore unroutable. The Oracle Communications Session Border
Controller solves this problem by sending RAS replies to the layer 3 address from which the associated RAS request
was received.
A second issue exists for media channels as the address specified in the H.323 OLC message will be behind the NAT
and likewise unroutable. This is resolved by relying on the fact that the forward and reverse channels will utilize the
same address and port on the endpoint. By sending media packets to the same address from which the packet are
received, media and flow through the NAT.
If you do not use H.323 HNT, the following behavior will occur:
• When an H.323 endpoint is behind a NAT and it registers with a gatekeeper through the Oracle Communications
Session Border Controller, the Oracle Communications Session Border Controller tries to send a response back to
the endpoint’s RAS address rather than to the NAT from which the request was received.
• The same is true for LRQ and IRQ messages because responses without H.323 HNT for outbound sessions,
responses were being sent back to the replyAddress or the rasAddress.
• In addition, the Oracle Communications Session Border Controller always induces one-way media because it tries
to send the RTP to the media IP address and port it receives in the OLC messages rather than the ephemeral port
on the intermediary NAT.
With this ability enabled, however, the Oracle Communications Session Border Controller sends RAS responses back
to the address from which the request was received (the NAT). It does not send responses to the endpoint’s rasAddress
or replyAddress mentioned in the signaling message. The same is true for RTP. With H.323 HNT for outbound
sessions enabled, the Oracle Communications Session Border Controller sends RTP to the IP address and port from
which it receives the RTP packets (the NAT).
The call flow below illustrates how this feature works:
Caveats
Keep in mind the following caveats when you are enabling H.323 HNT for outbound sessions on your Oracle
Communications Session Border Controller:
• This capability does not apply to calls that require IWF translation between SIP and H.323.
H.245
When in H.245 proxy mode, the Oracle Communications Session Border Controller proxies or passes through the call
signaling (H.225) messages and the call control (H.245) messages. It allows media to flow between the two H.323
endpoints, as shown in the following diagram.
In some deployments, the media might be treated by a NAT device. When the Oracle Communications Session
Border Controller is in H.245 proxy mode, any tunneled H.245 message on the ingress side is tunneled in the egress
side. However, if the tunneling is refused on the egress side, a separate H.245 session is established.
H.245 proxy mode support is defined in the following table.
Ingress Egress
Tunneled Tunneled
Tunneled Separate H.245 session
Separate H.245 session Tunneled
Separate H.245 session Separate H.245 session
H.225
When in H.225 proxy mode, the Oracle Communications Session Border Controller only proxies call signaling (H.
225 messages). The call control (H.245 messages) and the media associated with the session do not go through the
Oracle Communications Session Border Controller. Instead, they flow directly between the two H.323 endpoints.
Note: H.225 proxy mode is only used in specific applications and should not be enabled without consultation
from your Acme Packet Systems Engineer.
The following diagram shows the flow.
In certain deployments, the call control message and media are exchanged between the two H.323 endpoints
themselves. When the Oracle Communications Session Border Controller is in H.225 proxy mode, any tunneled H.
245 message on the ingress side is tunneled in the egress side; this is irrespective of the value configured in the value
you set for the h.245-tunneling parameter in the H.323 stack configuration.
6. multicast—Set this parameter to the address and port where the RAS Multicast Group listens. Your entries in
this field will be comprised of an IPv4 address and port values separated by a colon. The default value is
0.0.0.0:0.
• Minimum—0
• Maximum—999999999
6. connect-tmo—Enter the time in seconds for the connect time-out (or T301 timer). This is the amount of time
allowed to elapse during which the Oracle Communications Session Border Controller should receive a Connect
message.
For alternate routing, this parameter is also used to limit the number of next hops that are tried and the length of
time they are tried in case the first next hop fails. The call needs to be established before this timer expires; the
call will fail after maximum of 5 retries.
The default for this parameter is 32.
• Minimum—0
• Maximum—999999999
• in-service-period—Amount of time that elapses before a session agent is put back in service after the
ttr-no-response period has passed
By default, the Oracle Communications Session Border Controller continues to send LRQ messages to a session agent
even if the session agent has already sent an LRJ. However, you might want to place a session agent out of service
when it has sent a certain number of LRJs; doing so allows alternate routing to take place faster, but this is an optional
feature.
To configure an LRJ threshold, you add the max-lrj value to an H.323 session agent’s options parameter;
instructions for how to set it and the required syntax appear below. If you do not set this option, then the Oracle
Communications Session Border Controller will not put session agents out of service for matters related to LRJs.
If you do set this option (to a non-zero value), then the Oracle Communications Session Border Controller keeps a
count of the LRJs received from a session agent. When it receives an LCF from a session agent, the Oracle
Communications Session Border Controller resets the counter to zero. This count is used internally only and is not
accessible through statistics displays.
If a session agent exceeds the maximum number of LRJs and goes out of service, it remains in that state until the
ttr-no-response period has passed and it has transitioned through the in-service-period time. If the
ttr-no-response period is zero, then the session agent is never put out of service.
Caveats
The Oracle Communications Session Border Controller does not support H.323 LRQ alternate routing for these
scenarios:
• Calls that require translation between SIP and H.323 (IWF calls)
• For pure H.323 calls where the ingress H.323 interface (stack) is associated with another H.323 interface (stack)
that has a valid gatekeeper defined; if there is no valid gatekeeper for the egress interface (stack), this feature may
apply.
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 option to the h323 configuration’s options list, you
must prepend the new option with a plus sign as shown in the previous example.
You can use the ACLI show monthly minutes <realm-id> command (where <realm-id> is the realm
identifier of the specific realm for which you want data) to see how many minutes are configured for a realm, how
many of those are still available, and how many calls have been rejected due to exceeding the limit.
Caveats
Note: this feature is not supported for HA nodes running H.323.
However, not all H.323 elements comply with the ITU recommendation. Since some network elements do modify the
packetization rate in the dataType element, this behavior is now configurable.
When you enable media sample size preservation, the Oracle Communications Session Border Controller allows the
packetization rate to be modified and forwards on the modified dataType element to the calling gateway. In the
following example, you can see that the Oracle Communications Session Border Controller forwards the called
gateway’s Alerting with the packetization interval of 20 despite the fact that the calling gateway’s Setup specified 30.
Note that the calling endpoint might or might not work with the modified dataType.
You can enable this feature for the global H.323 configuration so that it applies to all H.323 fastStart calls, or you can
enable it on a per-H.323 interface (stack) basis. When you enable this feature for an individual H.323 interface
(stack), the Oracle Communications Session Border Controller performs media sample size preservation for calls
egressing on that interface.
structure. H.264 and G.722.1 are the first codecs the Oracle Communications Session Border Controller offers that
use this mechanism.
To set a media profile for generic video support:
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
3. Type media-profile and press Enter.
ORACLE(session-router)# media-profile
ORACLE(media-profile)#
4. name—Set the name of the generic video media profile to genericVideo. There is no default for this parameter.
5. media-type—Set the media type to use for this media profile; for generic video, set this parameter to video.
6. payload-type—Set the payload type to use for the generic video media profile.
7. transport—Set the transport type to use for the generic video media profile.
8. Complete the rest of the media profile configuration as needed.
9. Save and activate your configuration.
The following is a sample of a generic video media profile configuration:
media-profile
name genericVideo
media-type video
payload-type 99
transport RTP/AVP
req-bandwidth 0
frames-per-packet 0
parameters
average-rate-limit 0
sdp-rate-limit-headroom 0
sdp-bandwidth disabled
7. transport—Set the type of transport protocol to use for the generic audio media profile. The default value is
RTP/AVP.
• UPD | RTP/AVP
8. Complete the rest of the media profile configuration as needed.
9. Save and activate your configuration.
The following is a sample of a generic audio media profile configuration:
media-profile
name genericAudio
media-type audio
payload-type 104
transport RTP/AVP
req-bandwidth 0
frames-per-packet 0
parameters
average-rate-limit 0
sdp-rate-limit-headroom 0
sdp-bandwidth disabled
5. Set the options parameter by typing options, a Space, the option name cpnType=x with a plus sign in front of
it, and then press Enter.
ORACLE(h323-stack)# options +cpnType=x
If you type options without the plus sign, you will overwrite any previously configured options. In order to
append the new options to the h323-stack’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.
Options
The options parameter in the global H.323 and H.323 interface configurations allows you to establish the use of
specific features; most of those features are customer specific.
You should exercise caution when you apply options because of the fact that many of them are for customer-specific
applications. Consult with your Acme Packet systems engineering to find out if using a particular option would be an
advantage to you.
Under no circumstance do we recommend that you configure options without Oracle consultation. There is the chance
that you could set an option that might harm an otherwise sound configuration.
Some of the options described below are only applicable to IWF calls. However, you need to establish them in your
H.323 configuration.
Options Description
NoDynamicMSD Oracle Communications Session Border Controller forcefully assumes the “master” role
for an outgoing call, and the slave role for an incoming call.
AllowOLCWoMSD Oracle Communications Session Border Controller sends OLC before master/slave
determination is complete.
Causes the Oracle Communications Session Border Controller to be noncompliant with
the H.323 recommendation, which does not permit an OLC to be sent prior to MSD
completion.
ModifyMediaInAck Oracle Communications Session Border Controller accepts and propagates changes to
media presented in an OLC Ack.
Applies only to Fast Start OLC/OLC Ack messages embedded in H.225/Q.931
messages during call setup.
Causes Oracle Communications Session Border Controller to be noncompliant with the
H.323 recommendation, which does not permit media characteristic to be specified in
an OLC to be changed in an OLCAck.
MapG729 Oracle Communications Session Border Controller maps H.245 G.729 to SDP G.729
with Annex B and vice versa. Applicable only to IWF calls.
ColonG729 Oracle Communications Session Border Controller uses the : (colon) instead of the =
(equal sign) in the media attribute line a=fmtp:18 annexb=yes/no when mapping H.245
G.729 or SDP G.729 with Annex B. Applicable only to IWF calls.
IwfLRQ Oracle Communications Session Border Controller sends an INVITE (with no SDP) to
a redirect server in response to an incoming LRQ received on an H.323 interface. If a
3xx message with a redirected contact header is returned, the Oracle Communications
Session Border Controller will send an LCF in response to the LRQ. Otherwise, it will
send an LRJ.
NoG729AnnexB SDP received by the IWF with H.729 and no FMTP will be mapped to G.729 on the H.
323 side of the call. Can also be set in the session agent options parameter.
sameT38Port Oracle Communications Session Border Controller does not allocates separate ports for
audio and T.38. Oracle Communications Session Border Controller will send the same
audio port in the OLCAck that it sees in a request mode for T.38 and a new OLC for T.
38.
pvtStats Oracle Communications Session Border Controller includes program value tree (PVT)
statistics in the show h323d display that are a sum of the PVT statistics for all H.323
interfaces. Used for debugging purposes.
strayARQTimer Required the syntax "strayARQTimer=x," where x is the number of seconds the system
waits before tearing down an unsuccessful call in the case of stray ARQs.
forceMediaProfileInOLC Reverts to older OLC Behavior.
Option Description
stackAliasWins Oracle Communications Session Border Controller will replace the sourceAddress of
the incoming Setup message with the terminal alias of the egress interface when
copying the incoming sourceAddress to the outgoing Setup message.
uniqueRRQRASAddress Oracle Communications Session Border Controller will generate unique rasAddress
for each RRQ that it sends to a gatekeeper in response to an incoming RRQ received
on an H.323 interface configured for process registration. The IP address will be the
local-ip of the outgoing interface, so the port is the unique portion of the rasAddress.
nonV4AdditiveRRQ Gatekeeper associated with the H.323 interface support additive registration even
though it does not set the additiveRegistration field in the RRQ message. When
sending in the additive mode, the H.323 interface only sends with the RRQ new
terminal aliases that need to be registered. In non-additive mode, the interface sense
all the terminal aliases that have been registered, plus the new aliases.
cachedTerimnalAlias Oracle Communications Session Border Controller copies the terminal alias(es) of
the registered endpoint to the asourceAddress field of the Setup message. Terminal
alias(es) are changed after the system successfully processes an RRQ from the
endpoint.
proxySrcInfo Oracle Communications Session Border Controller copies the sourceInfo from the
incoming Setup message to the outgoing Setup message. Otherwise, Oracle
Communications Session Border Controller uses its own endpointType for the
sourceInfo field.
noAliasinRCF Oracle Communications Session Border Controller does not include any terminal
alias in the RCF.
forceH245 Oracle Communications Session Border Controllerinitiates an H.245 connection
after the call is connected. Otherwise, Oracle Communications Session Border
Controller listens for an H.245 connection to be initiated by a remote endpoint.
useCPNInRAS Oracle Communications Session Border Controller uses the calling party number
(CPN) IE of the incoming call as the srcInfo of a RAS message sent in the outgoing
call (such as an ARQ).
maintenanceProxy Oracle Communications Session Border Controller registers interfaces on the
enterprise side with a gatekeeper on the carrier side, and registers endpoints through
the Oracle Communications Session Border Controller with a unique rasAddress.
Interfaces on the enterprise side are associated with the carrier interfaces; you set this
option on the carrier side.
convertPNToE164 Oracle Communications Session Border Controller converts the address type
partyNumber to dialedDigits (E.164). Conversion applies to sourceAddress,
destinationAddress, and destExtraCallInfo aliases in Setup messages.
useCalledPNAsDestInfo Oracle Communications Session Border Controller uses the H.225 called party
number IE as the destinationInfo in ARQ and LRQ requests. Since translation rules
can be applied to the Called Party Number, the option enables digit normalization for
RAS requests.
When not used, Oracle Communications Session Border Controller derives the
destinationInfo field in RAS requests from the DestnationAddress field of the
incoming Setup.
waitForIncomingH245 On the incoming leg, the Oracle Communications Session Border Controller does
not send out its h245Address, but waits for the calling endpoint to send its
H245Address.Applies to the outgoing call led as well: The Oracle Communications
Option Description
Session Border Controller does not send out a Facility with startH245 reason and
waits for the called endpoint to send its H245Address.
uniqueRRQSrcPort Enables H.323 RAS Port Mapping. The Oracle Communications Session Border
Controller uses the RAS port that it assigned in the rasAddress parameters of an
RRQ message as the UDP source port of the outgoing RRQ. Because this feature is
linked to the unique RRQ functionality, be aware of the following before you enable
the feature:
• Enabling H.323 RAS Port Mapping automatically enables the Oracle
Communications Session Border Controller’s unique RRQ functionality,
eliminating the need for you to configure the latter as a separate option.
• Enabling the unique RRQ functionality (by setting the uniqueRRQRASAddress
option) does not automatically enable H.323 RAS Port Mapping.
srcCallSignallingPort Enables use of the Q.931 port value for the port field in the sourceCallSignalAddress
parameter in an H.225 Setup message. Useful for customers who configure a
separate H.323 interface (stack) on the core side for each external IP-PBX.
4. Type h323-stack and press Enter. If you are adding H.323 stack monitoring to
an existing H.323 stack configuration, then remember you must select the
stack you want to edit.
ORACLE(h323)# h323-stack
ORACLE(h323-stack)#
5. Type alarm-threshold and press Enter to configure this feature.
ORACLE(h323-stack)# alarm-threshold
ORACLE(alarm-threshold)#
6. severity—Enter the type of severity level for the alarm you want to define. Choose from: critical,
major, or minor. This value is required, and defaults to minor.
7. value—Enter the percentage of the number of calls defined in the max-calls parameter that triggers the
alarm. For example, if you want to set a minor alarm to fire when the call rate through the stack reaches half the
max-calls value, enter 50 (meaning 50%). The default value for this parameter is 0, which disables the alarm.
Remember that if the number of calls falls to below 1% of the max-calls threshold you set, the clear trap fires.
8. Save your work. You can see the data related to this feature using the ACLI display-alarms and show
h323 stack stack-alarms commands.
Alias Mapping
Alias mapping permits destination addresses to be modified by a gatekeeper.
When sending an ARQ or an LRQ message to a gatekeeper, the Oracle Communications Session Border Controller
sets the canMapAlias field in that message to true. This setting indicates that the Oracle Communications Session
Border Controller accepts modified destination information from the gatekeeper. If the resulting ACF or LCF contains
destinationInfo and/or destExtraCallInfo fields, then the Oracle Communications Session Border Controller copies
that information respectively to the destinationAddress and destExtraCallInfo fields of the Setup message. In addition,
if the destinationInfo is either type e164 or type partyNumber, the Oracle Communications Session Border Controller
copies the information into the calledPartyNumber information element (IE) of the Setup message, replacing the
existing calledPartyNumber IE.
You do not need to configure special parameters for this feature; it is enabled automatically.
message, it is unaware of whether the call will become hairpinned or if media release will occur. Because it does not
yet have this information, the Oracle Communications Session Border Controller sets the Network Address and the
TSAP identifier in the OLC structures to the ingress IP address and port of a corresponding media flow allocated for
media traveling between the calling and called endpoints. So if the called endpoint accepts the fastStart the Oracle
Communications Session Border Controller proposes, the called endpoint would send its media to the Oracle
Communications Session Border Controller. After acceptance, the system starts H.245 procedures on the slow-start
side of the call to set up logical channels on that side. Then the Oracle Communications Session Border Controller
updates the IP address and port of the media flows using OLC and OLCAck messages received from the calling
endpoint.
This procedure works well for endpoints that are not in the same realm, or that are in the same realm for which media
management is disabled, because each endpoint must send its media through the Oracle Communications Session
Border Controller. When the endpoints are in the same realm and when media management is enabled, however, the
Oracle Communications Session Border Controller must perform additional steps for media release in slow-start to
fast-start calls.
To support media release in slow-start to fast-start calls, the Oracle Communications Session Border Controller
performs a hold-and-resume procedure on the fast-start side. After it establishes channels on the slow-start side and if
it detects media release being enabled, the Oracle Communications Session Border Controller sends and empty TCS
to the fast-start side to put that side on hold. Then the called endpoint closes all the logical channels it previously
opened in the Fast Connect procedure and stops transmitting to them. And the Oracle Communications Session
Border Controller also closes it logical channels. Once the channels are closed, the Oracle Communications Session
Border Controller resumes the call by sending a new, restricted TCS to the fast-start side. The restricted TCS only
contains the receive and transmit capabilities of the codecs types that the called endpoint accepted in the Fast Connect
procedure, and it forces the called endpoint to re-open logical channels of the same codec types accepted in the Fast
Connect procedure. Once it receives and OLC from the called endpoint, the Oracle Communications Session Border
Controller sends on OLCAck with the Network Address and TSAP identifier for the logical channel from the calling
endpoint. Then the Oracle Communications Session Border Controller re-opens logical channels (of the same codec
types that it open in the Fast Connect procedure). If the called endpoint has not changed its Network Address and
TSAP identifier for its logical channels, media is re-established after the Oracle Communications Session Border
Controller and the called endpoint exit the hold state. The last steps is for the Oracle Communications Session Border
Controller to re-sends the full TCS message from the calling to the called endpoint to inform the called endpoint of
the full capabilities of the calling endpoint.
Dependencies
This feature depends on the following assumptions:
• The H.323 endpoint supports the third-party-initiated pause and re-routing feature.
• The H.323 endpoint does not change its Network Address and TSAP identifier when it re-opens the logical
channels.
• The H.323 endpoint does not immediately tear down the call when there is not established logical channel in the
call.
Hold-and-Resume Procedure
The hold-and-resume procedure has three states:
• Media Hold—Starts when the Oracle Communications Session Border Controller sends the empty TCS to the
called endpoint to put it on hold.
When it detects media release, the Oracle Communications Session Border Controller puts the called endpoint on
hold. It can only do so if it has exchanged the TCS/TCSAck messages and completed master-slave determination
with the calling endpoint.
When the Oracle Communications Session Border Controllerreceives a TCSAck in response to the empty TCS
that it sent to the called endpoint, it closes the logical channels it opened as part of the Fast Connect procedure; the
called endpoint likewise closes its logical channels. The two then exchange CLC and CLCAck messages, which
signals the start of the Media Resume state.
• Media Resume—Starts when the Oracle Communications Session Border Controllersends a restricted TCS to
resume the call.
The restricted TCS the Oracle Communications Session Border Controller sends contains only the receive/
transmit capabilities of the codec types previously accepted by the called endpoint in the Fast Connect procedure.
This forces the called endpoint to re-open logical channels of the same codec type that were previously accepted
in the Fast Connect procedure.
After sending this TCS, the system is ready (as specified in the ITU-T recommendations) to take part on the
master-slave determination (MSD) process. However, the called party and not the Oracle Communications
Session Border Controller initiates the MSD if it is required. The MSD is completed if necessary. Alternately, the
called endpoint can start to re-open its logical channels. When it receives the first OLC from the called endpoint,
the Oracle Communications Session Border Controller also starts to re-open its logical channels.
• Media Complete—Starts when all the logical channels that the Oracle Communications Session Border Controller
re-opens are acknowledged by the called endpoint.
When it enters the Media Complete state, the Oracle Communications Session Border Controller updates the called
endpoint with the full capabilities of the calling endpoint by sending the full TCS.
Previous Behavior
Prior to Release 4.1, the Oracle Communications Session Border Controller did not forward calls when the remote H.
323 endpoint sent a Facility message with Call deflection as the reason and an alternate address for forwarding.
Instead, it would either:
• Fail to release the initial call and initiate the forwarded call
• Drop the entire call when the remote endpoint for the call tore down the session
New Behavior
In the diagram below, you can see that the Oracle Communications Session Border Controller sends the initial Setup
message to the gateway, and the gateway returns the Facility message with an alternate address for forwarding. Rather
than engaging in its former behavior, the Oracle Communications Session Border Controller now releases the call
with the gateway and sends a new Setup to the alternate address from the Facility message.
This new Setup up has no effect on the first call leg, which remains connected.
When it receives a Facility message with the reason CallForwarded, the Oracle Communications Session Border
Controller looks for an alternate transport address in the Facility’s alternativeAddress or alternativeAliasAddress
element. The Oracle Communications Session Border Controller releases the egress call with the reason
facilityCallDeflection. Then it takes one of two courses of action:
• If it does not find an alternative address, the Oracle Communications Session Border Controller releases the
ingress call (with the reason facilityCallDeflection).
• If it finds an alternative address and the egress call has not been alerted or answered, the Oracle Communications
Session Border Controller at this point tries to initiate a new egress call. The Oracle Communications Session
Border Controller uses the alternative alias address to populate the calledPartyNumber information element (IE)
and the destination address of the new Setup.
Caveats
The Oracle Communications Session Border Controller does not support interworking the NOTIFY message to a SIP
message for calls that require interworking between H.323 and SIP; this support is for pure H.323 calls only.
Interworking Gatekeeper-Gateway
This example provides is a sample for the Interworking Gatekeeper-Gateway mode of operation.
h323-config
state enabled
log-level INFO
response-tmo 4
connect-tmo 32
h323-stack
name zone1
state enabled
isgateway disabled
realm-id zone1realm
assoc-stack zone2
local-ip x.x.x.x(IP address of VGW-A/GK-A)
max-calls 200
max-channels 10
registration-ttl 0
terminal-alias
h323-ID=private
ras-port 1719
auto-gk-discovery disabled
multicast 0.0.0.0:0
gatekeeper x.x.x.x(IP address of GkZone1)
gk-identifier gk-zone1.acme.com
q931-port 1720
alternate-transport
q931-max-calls 200
h245-tunneling enabled
fs-in-first-msg disabled
call-start-fast disabled
call-start-slow disabled
Additional Information
This section contains detailed tables to use as a reference when you are learning about H.323 features or when you are
configuring them.
Payload Type Encoding Name Audio (A)/Visual (V) Clock Rate (Hz)
0 PCMU A 8000
Payload Type Encoding Name Audio (A)/Visual (V) Clock Rate (Hz)
1 1016 A 8000
2 G721 A 8000
3 GSM A 8000
4 G723 A 8000
5 DVI4 A 8000
6 DVI4 A 16000
7 LPC A 8000
8 PCMA A 8000
9 G722 A 8000
10 L16 A 44100
11 L16 A 44100
12 QCELP A 8000
13 reserved A
14 MPA A 90000
15 G728 A 8000
16 DVI4 A 11025
17 DVI4 A 22050
18 G729 A 8000
19 reserved A
20 unassigned A
21 unassigned A
22 unassigned A
23 unassigned A
dyn GSM-HR A 8000
dyn GSM-EFR A 8000
dyn L8 A var.
dyn RED A
dyn VDVI A var.
24 unassigned V
25 CelB V 90000
26 JPEG V 90000
27 unassigned V
28 nv V 90000
29 unassigned V
Payload Type Encoding Name Audio (A)/Visual (V) Clock Rate (Hz)
30 unassigned V
31 H261 V 90000
32 MPV V 90000
33 MP2T AV 90000
34 H263 V 90000
35-71 unassigned ?
72-76 reserved for RTCP conflict N/A N/A
avoidance
77-95 unassigned ?
96-127 dynamic ?
dyn BT656 V 90000
dyn H263-1998 V 90000
dyn MP1S V 90000
dyn MP2P V 90000
dyn BMPEG V 90000
setup X FALSE
callProceeding X FALSE
connect X FALSE
alerting X FALSE
information X FALSE
releaseComplete X FALSE
facility X FALSE
progress X FALSE
empty X FALSE
..., X FALSE
status X FALSE
statusInquiry X FALSE
setupAcknowledge
notify
This section’s call flow diagrams show how SIP and H.323 messages flow between SIP UA/GW and an H.323
GK/GW, with the Oracle Communications Session Border Controller positioned between the two entities so it can
perform translations. Two sample scenarios with Slow Start appear in the diagrams below:
• SIP being interworked to Slow Start H.323
• Slow Start H.323 being interworked to SIP
Code Description
403 Forbidden
406 Not Acceptable
408 Request Timeout
410 Gone
420 Bad Extension
480 Temporarily Unavailable
486 Busy Here
487 Request Terminated
500 Server Internal Error
503 Service Unavailable
504 Server Time-out
600 Busy Everywhere
603 Decline
4. options—Set the options parameter by typing options, a Space, the option name preceded by a plus sign (+)
(iwfRegFailCode=X), and then press Enter. X is the SIP response code that you want to use; the table above
lists the supported response codes that are supported.
ORACLE(h323)# options +iwfRegFailCode=503
If you type options iwfRegFailCode=X, you will overwrite any previously
configured options. In order to append the option to the options list, you
must prepend the new option with a plus sign as shown in the previous
example.
Codec Mapping
The Oracle Communications Session Border Controller uses the following mapping scheme when converting media
specifications between H.245 (used in H.323) and SDP (used in SIP).
Media coming into the Oracle Communications Session Border Controller one way exits the system in the
corresponding way as specified in the following table. For example, media coming into the Oracle Communications
Session Border Controller as H.245 type g711Ulaw64k exits the system as media type PCMU.
g711Ulaw64k PCMU
g711Ulaw56k PCMU
g711Alaw64k PCMA
g711Alaw56k PCMA
g726 G726-32
g7231 G723
g722 G722
g728 G728
g729wAnnexB G729
g729 G729
fmtp:18 annexb=no
h261VideoCapability H261
h263VideoCapability H263
Early Media
For call that require the IWF, the Oracle Communications Session Border Controller supports a cut-through for early
media for calls that originate in SIP or H.323.
For a session originating in SIP, the provisional message will contain the SDP information if a Fast Start OLC was
received in the Call Proceeding, Alerting, or Progress messages. The same SDP will be sent in the SIP 200 OK.
For a session that starts in H.323, the Oracle Communications Session Border Controller translates the SDP it
receives in SIP messages (either a 180 or a 183) into the appropriate H.323 Fast Start elements: Alerting or Progress.
If the Alerting or Progress messages contain Fast Start elements, the Progress Indicator Q.931 information element
(IE) will also be included in the message with Progress Descriptor 8, indicating that in-band information or an
appropriate pattern is now available. This causes the call party to enable end-to-end early media in the reverse
direction in accordance with H.323 v4.
In addition, the Oracle Communications Session Border Controller allows early media to flow in the forward
direction for a call that requires the IWF starting in H.323 that is being translated to SIP. This happens after the Oracle
Communications Session Border Controller has received provisional response with SDP and has sent Alerting or
Progress message with Fast Start to the calling party. Similarly, early media in the forward direction is enabled for a
call that requires the IWF starting in SIP and being translated to H.323. This happens after the Oracle
Communications Session Border Controller received Alerting or Progress messages with Fast Start and maps the
Alerting or Progress to SIP 180 or 183 provisional response with the SDP answer.
For each of the mappings listed in the following table, this section provides a sample call flow.
No Message CallProceeding
No Message Progress without PI
183 with SDP Progress with PI
180 w/o SDP Alert without PI
180 with SDP Alert with PI
In the following diagram, a call that requires the IWF passes through the Oracle Communications Session Border
Controller twice, creating two call legs. The call originates from H.323 GW1 and terminates in Phone 1 or Phone 2.
Basic Call
In the following sample basic call, IP PBX A sends an H.323 Slow Starts message ultimately destined for the PSTN
through the Oracle Communications Session Border Controller . The Oracle Communications Session Border
Controller performs translation to SIP and inserts default information about media. Once the PSTN gateway responds
with a 183 containing SDP, the Oracle Communications Session Border Controller sends that information to IP PBX
A. Then the Oracle Communications Session Border Controller and the IP PBX exchange TCS- and OLC-related
messages, and they negotiate master-slave determination. The Oracle Communications Session Border Controller also
sends IP PBX A a Call Progress message with a progress indicator of 8.
After the ringback tone, the proxy sends a 200 OK message with SDP to the system. The Oracle Communications
Session Border Controller sends a Connect message to the IP PBX A, and then it sends another SIP INVITE to the
proxy that contains amended SDP (if that information about media is different from the default). After 200 OK and
ACK messages are exchanged, media (RTP/RTCP) flow takes place.
Hold
This sample call flow assumes that the IWF call is established and that the RTP/RTCP flow is already in progress.
The hold button is pushed, and IP PBX A sends an empty TCS to the Oracle Communications Session Border
Controller . The Oracle Communications Session Border Controller puts the called party on hold by sending an
INVITE message with 0.0.0.0 SDP to the SIP side of the call. Using 0.0.0.0 as the media address effectively stops the
media flow. This INVITE is acknowledged, and the Oracle Communications Session Border Controller closes the
channels on the H.323 side, halting the RTP/RTCP flow.
When the caller on the H.323 side takes the call off hold, it resumes with a TCS that the Oracle Communications
Session Border Controller receives and then translates on the SIP side as an INVITE with SDP. After that INVITE is
acknowledged and received, the Oracle Communications Session Border Controller opens logical channels on the H.
323 side and RTP/RTCP flows resume.
Music On Hold
This scenario is similar to the hold feature enabled for calls that require the IWF, except that after the RTP/RTCP flow
between the H.323 and SIP sides stops, the call is sent to music on hold. Before the announcement or music plays, the
Oracle Communications Session Border Controller sets up the necessary support for media to be exchanged.
Transfer
The call flow described in this section recalls the diagram at the top of the H.323 Endpoint-Originated Call Hold and
Transfer section, where endpoints A, B, and C are H.323 devices and endpoint D is a SIP device. When you follow
the signaling and media flows, note that there are two Oracle Communications Session Border Controller s in the call
transfer and two sets of SIP/H.323 translations that take place. The first Oracle Communications Session Border
Controller translates H.323 to SIP, and the second performs the same operations with the protocols reversed.
In the scenario pictured, Party A is on a call with Party D, but wants to transfer Party C to Party D. Party A places
Party D on hold, and then makes the call to Party C. Party A then puts Party C on hold, pressing the transfer button.
You can see that Oracle Communications Session Border Controller 1 receives a TCS from the IP PBX, which is then
translated to SIP. Oracle Communications Session Border Controller 2 receives it, performs the required protocol
translations, and then opens a session with Party C via another IP PBX. Once this session is up and Party D is
awakened, channels are established for media exchange.
In order to redirect the media so that it flows between Party C and Party D, the Oracle Communications Session
Border Controller 1 and IP PBX C exchange OLC and OLC Ack messages that contain address information for Party
C and for Party D. Address information for both parties is contained in the OLC Ack messages that the Oracle
Communications Session Border Controller exchanges with the IP PBX. IP PBX A does not move forward with the
call until it has the necessary address information.
Even though Party A’s participation in the call stops early in this scenario, the IP PBX with which it is associated
keeps the signaling sessions with the Oracle Communications Session Border Controller alive to manage the transfer.
Conference
To conference a call that requires the IWF that starts in H.323, the Oracle Communications Session Border Controller
uses a scenario much like the one used for holding a call that requires the IWF. Here again, the INVITE with 0.0.0.0
as the media address and the closing of logical channels stops the flow of RTP/RTCP. After signaling and SDP/media
information are re-established, RTP/RTCP for the conference flows.
New Behavior
In the diagram below, you can see that the Oracle Communications Session Border Controller sends the initial Setup
message to the gateway, and the gateway returns the Facility message with an alternate address for forwarding. Rather
than engaging in its former behavior, the Oracle Communications Session Border Controller now releases the call
with the gateway and sends a new Setup to the alternate address from the Facility message.
This new Setup up has no effect on the first call leg, which remains connected.
When it receives a Facility message with the reason CallForwarded, the Oracle Communications Session Border
Controller looks for an alternate transport address in the Facility’s alternativeAddress or alternativeAliasAddress
element. The Oracle Communications Session Border Controller releases the egress call with the reason
facilityCallDeflection. Then it takes one of two courses of action:
• If it does not find an alternative address, the Oracle Communications Session Border Controller releases the
ingress call (with 486 BUSY HERE for a call being interworked from SIP to H.323).
If it finds an alternative address and the egress call has not been alerted or answered, the Oracle Communications
Session Border Controller at this point tries to initiate a new egress call. The Oracle Communications Session Border
Controller uses the alternative alias address to populate the calledPartyNumber information element (IE) and the
destination address of the new Setup.
H.323
For H.323 calls, the Oracle Communications Session Border Controller establishes media using the H.245 procedures
described in the H.245 ITU-T recommendation: control protocol for multimedia communication. It also uses the Fast
Connect procedure defined in the H.323 ITU-T recommendation: packet-based multimedia communication systems.
The latter ITU-T recommendation allows a calling endpoint to send a Setup message that contains a fastStart element,
a sequence of OLC structures that describe the calling endpoint’s proposed forward/reverse logical channels. If the
called endpoint accepts this proposal, then logical channels are established.
When the Oracle Communications Session Border Controller translates a call originating in slow-start to fast-start, it
uses a Fast Connect procedure in the outgoing leg by sending an outgoing Setup that includes a fastStart element with
one or more OLC structures. But when the Oracle Communications Session Border Controller constructs this
message, it is unaware of whether the call will become hairpinned or if media release will occur. Because it does not
yet have this information, the Oracle Communications Session Border Controller sets the Network Address and the
TSAP identifier in the OLC structures to the ingress IP address and port of a corresponding media flow allocated for
media traveling between the calling and called endpoints. So if the called endpoint accepts the fastStart the Oracle
Communications Session Border Controller proposes, the called endpoint would send its media to the Oracle
Communications Session Border Controller . After acceptance, the system starts H.245 procedures on the slow-start
side of the call to set up logical channels on that side. Then the Oracle Communications Session Border Controller
updates the IP address and port of the media flows using OLC and OLCAck messages received from the calling
endpoint.
This procedure works well for endpoints that are not in the same realm, or that are in the same realm for which media
management is disabled, because each endpoint must send its media through the Oracle Communications Session
Border Controller . When the endpoints are in the same realm and when media management is enabled, however, the
Oracle Communications Session Border Controller must perform additional steps for media release in slow-start to
fast-start calls.
To support media release in slow-start to fast-start calls, the Oracle Communications Session Border Controller
performs a hold-and-resume procedure on the fast-start side. After it establishes channels on the slow-start side and if
it detects media release being enabled, the Oracle Communications Session Border Controller sends and empty TCS
to the fast-start side to put that side on hold. Then the called endpoint closes all the logical channels it previously
opened in the Fast Connect procedure and stops transmitting to them. And the Oracle Communications Session
Border Controller also closes it logical channels. Once the channels are closed, the Oracle Communications Session
Border Controller resumes the call by sending a new, restricted TCS to the fast-start side. The restricted TCS only
contains the receive and transmit capabilities of the codecs types that the called endpoint accepted in the Fast Connect
procedure, and it forces the called endpoint to re-open logical channels of the same codec types accepted in the Fast
Connect procedure. Once it receives and OLC from the called endpoint, the Oracle Communications Session Border
Controller sends on OLCAck with the Network Address and TSAP identifier for the logical channel from the calling
endpoint. Then the Oracle Communications Session Border Controller re-opens logical channels (of the same codec
types that it open in the Fast Connect procedure). If the called endpoint has not changed its Network Address and
TSAP identifier for its logical channels, media is re-established after the Oracle Communications Session Border
Controller and the called endpoint exit the hold state. The last steps is for the Oracle Communications Session Border
Controller to re-sends the full TCS message from the calling to the called endpoint to inform the called endpoint of
the full capabilities of the calling endpoint.
Hold-and-Resume Procedure
The hold-and-resume procedure has three states:
• Media Hold—Starts when the Oracle Communications Session Border Controller sends the empty TCS to the
called endpoint to put it on hold.
When it detects media release, the Oracle Communications Session Border Controller puts the called endpoint on
hold. It can only do so if it has exchanged the TCS/TCSAck messages and completed master-slave determination
with the calling endpoint.
When theOracle Communications Session Border Controller receives a TCSAck in response to the empty TCS
that it sent to the called endpoint, it closes the logical channels it opened as part of the Fast Connect procedure; the
called endpoint likewise closes its logical channels. The two then exchange CLC and CLCAck messages, which
signals the start of the Media Resume state.
• Media Resume—Starts when the Oracle Communications Session Border Controller sends a restricted TCS to
resume the call.
The restricted TCS the Oracle Communications Session Border Controller sends contains only the receive/
transmit capabilities of the codec types previously accepted by the called endpoint in the Fast Connect procedure.
This forces the called endpoint to re-open logical channels of the same codec type that were previously accepted
in the Fast Connect procedure.
After sending this TCS, the Oracle Communications Session Border Controller is ready (as specified in the ITU-T
recommendations) to take part on the master-slave determination (MSD) process. However, the called party and
not the Oracle Communications Session Border Controller initiates the MSD if it is required. The MSD is
completed if necessary. Alternately, the called endpoint can start to re-open its logical channels. When it receives
the first OLC from the called endpoint, the Oracle Communications Session Border Controller also starts to re-
open its logical channels.
• Media Complete—Starts when all the logical channels that the Oracle Communications Session Border Controller
re-opens are acknowledged by the called endpoint.
When it enters the Media Complete state, the Oracle Communications Session Border Controller updates the
called endpoint with the full capabilities of the calling endpoint by sending the full TCS.
Dependencies
This feature depends on:
• The H.323 endpoint supports the third-party-initiated pause and re-routing feature.
• The H.323 endpoint does not change its Network Address and TSAP identifier when it re-opens the logical
channels.
• The H.323 endpoint does not immediately tear down the call when there is not established logical channel in the
call.
• The fact that the SIP endpoint supports the UPDATE message if the noReInvite option is enabled.
H.323 Configuration
You must have a complete configuration to support H.323 traffic on your Oracle Communications Session Border
Controller , including any required support for H.323 Fast Start or Slow Start.
In the H.323 interface configuration, you are able to configure interfaces that enable communication between H.323
devices (for audio, video, and/or data conferencing sessions).
If you know that your Oracle Communications Session Border Controller will be handling traffic originating in Slow
Start H.323, you must establish the appropriate list of media profiles in the IWF configuration. Handling Slow Start
traffic also requires that you establish appropriate local policy (and local policy attribute) configurations, but
configuring session agents and session agent groups is optional.
SIP Configuration
SIP functionality must also be configured on your Oracle Communications Session Border Controller that will
perform IWF translations. You must use appropriate local policy (and local policy attribute) configurations, but
configuring session agents and session agent groups is optional. If you use session agents, then you must also
configure the information you need for media profiles.
Figure 1a Endpoint B calling Endpoint A (H.323 endpoint does not have “Dynamic Payload Type Replacement”
Capability)
The H.323 Endpoint B is not H.245 v16 compliant, and hence payload type replacement needs to be done in the RTP
packets.
Figure 1b Endpoint A calling Endpoint B (H.323 endpoint does not have Dynamic Payload Type Replacement
Capability)
The H.323 Endpoint B is not H.245 v16 compliant, and therefore payload type replacement needs to be done in the
RTP packets.
There is no concept of H.245 compliance for the SIP Endpoint A.
Figure 2a shows the call flow of SIP Endpoint A calling an H.323 Endpoint B using slow start. The Oracle
Communications Session Delivery Manager modifies the dynamic payload type in the OLC-ACK based on payload
type received in the incoming SDP OFFER in the "INVITE" message.
Figure 2a Endpoint A calling Endpoint B (H.323 endpoint has TCS with Dynamic Payload Type Replacement
Capability)
Configuring Interworking
If you have already completed the steps outlined in this chapter’s IWF Service Enhancements section, then enabling
the IWF is a simple process. This section shows you how to enable the IWF, and how to enable certain features that
you can use to supplement basic IWF functionality.
An IWF configuration might appear like this in the ACLI:
iwf-config
state enabled
media-profiles
PCMU
telephone-event
logging disabled
Configure IWF
To enable the Inter-working Function (IWF) on your Oracle Communications Session Border Controller :
1. Access the iwf-config configuration element.
ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# iwf-config
ORACLE(iwf-config)#
2. state—Enable this parameter if you want to translate SIP and H.323 sessions on your Oracle Communications
Session Border Controller . The default value is disabled. Valid values are:
• enabled | disabled
3. media-profiles—Enter the name of the media profiles you want to use for IWF translations. This name is either
the name of an SDP codec (such as PCMU), or it can be telephone-event if you are configuring your system for
DTMF support.
If you want to use more than one media profile for SIP/H.323 translations, enter the names in quotation marks
with a space between each one.
ORACLE(iwf-config)# media-profiles "PCMU telephone-event"
4. logging—Enable this parameter if you want the Oracle Communications Session Border Controller to log SIP
messages that are related to the IWF. The default value is disabled. Valid values are:
• enabled | disabled
5. forward source call—Type enable if you want to the Oracle Communications Session Border Controller to add
the h225SourceCallSignalAddress header to the egress SIP INVITE.
6. Type done to save your configuration.
Allow IP address from home realm H.255 Calling Party IP/Port No Option Set
of SD SIP Config
Allow IP address from home realm IP address of Home Realm NoPAssertedID
of SD SIP Config SIP-Interface
Allow IP address from home realm IP address of Home Realm replace-call-origin-ip
of SD SIP Config SIP-Interface
Allow IP address from home realm IP address of Home Realm replace-call-origin-ip,
of SD SIP Config SIP-Interface NoPAssertedID
Restricted PAI Header not present Anonymous No Option Set
Restricted PAI Header not present Anonymous NoPAssertedID
Restricted PAI Header not present Anonymous replace-call-origin-ip
Restricted PAI Header not present Anonymous NoPAssertedID,
replace-call-origin-ip
DTMF Support
For calls that require the IWF, you can enable support for the relay of RFC 2833 DTMF digits. The availability of this
feature means that the Oracle Communications Session Border Controller is compliant with RFC 2833, which defines
two payload formats for DTMF digits. To learn more about this RFC, refer to http://www.ietf.org/rfc/rfc2833.txt.
Until the exchange of TCS messages with the H.323 endpoint, the Oracle Communications Session Border Controller
has no information about the endpoint’s RFC 2833 capabilities. The Oracle Communications Session Border
Controller adds telephone-event to the SDP on the SIP side of the call.
For calls that require SIP/H.323 translation, you can enable support for the relay of RFC 2833 DTMF digits.
To use this feature, you need to configure a media profile called telephone-event and set relevant parameters for it.
Application of the media profile can happen either in a session agent configuration or in the IWF configuration.
• The name parameter in the media profiles configuration
• The media-profiles list in the IWF configuration
• The media-profiles list in the session agent configuration
All of the scenarios outlined here assume that you have established a telephone-event media profile configuration.
You can configure DTMF support using the following parameters. The way that the Oracle Communications Session
Border Controller uses these values is described below. The payload type, part of the media profiles configuration, is
dynamic and varies with different endpoints, so there is no default configuration for the telephone-event media
profile.
The telephone-event media profile is used as follows in these types of IWF sessions:
• Calls that require the IWF originating in H.323 Slow Start—There is no channel
(media) information available on the H.323 side.
• If the incoming H.323 endpoint is configured as a session agent on the Oracle Communications Session Border
Controller , then the telephone-event parameter in the media profiles set for that session agent configuration
will be used in the SDP on the SIP side of the session.
• If the H.323 endpoint is not a session agent or the telephone-event media profile is not configured in the
session agent configuration corresponding to the endpoint, then the Oracle Communications Session Border
Controller refers to the media profile information configured for the IWF configuration.
• Calls that require the IWF originating in SIP—If the TCS was not exchanged before a 200
OK was sent on the SIP side, the Oracle Communications Session Border Controller will behave in one of these
two ways.
• If the outbound H.323 endpoint is configured as a session agent, then the media profiles from that session
agent configuration will be used.
• If the outbound H.323 endpoint is not configured as a session agent, the media profile configured within the
IWF configuration with the telephone-event value will be used.
As mentioned above, DTMF support is configured by using a combination of the telephone-event media profile and
either the session agent or IWF configuration. First you set up the media profile, then you apply it to a session agent
or to the IWF configuration.
DTMF Configuration
DTMF support requires you to configure a media profile named telephone-event. This section shows you how to set it
up.
To configure a telephone-event media 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-related configurations.
ORACLE(configure)# session-router
3. Type media-profile and press Enter. The system prompt changes to let you know that you can begin
configuring individual parameters.
ORACLE(session-router)# media-profile
From this point, you can configure parameters for media profiles. To view see all media profile configuration
parameters, enter a ? at the system prompt.
4. name—Enter the name telephone-event and press Enter.
5. parameters—Enter the parameters to be applied for the codec; these are the digits that endpoints can support.
6. media-type—Leave the default media type set to audio.
7. payload-type—Set the payload type to 101, which is the dynamic payload type needed to support this
feature.
8. transport—Leave the default transport protocol set to RTP/AVP.
9. frames-per-packet—You can leave this parameter set to 0 (default).
10. req-bandwidth—You can leave this parameter set to 0 (default).
5. When you want to add DTMF support to an H.323 session agent that you have already configured, you need to
select that session agent, add the media profile, and save your work.
ORACLE(session-agent)# select
<hostname>:
1: 192.168.1.48 realm= ip=
2: 192.168.1.49 realm= ip=
3: 192.168.1.50 realm=external ip=
selection:3
ORACLE(session-agent)# media-profiles "telephone-event g711Ulaw64k"
ORACLE(session-agent)# done
Performs 2833 translation for an endpoint when the originating side requests 2833 but the target does not negotiate
2833
Allows 2833 to pass through if the originating side and target of the call are configured as preferred and negotiate
2833
• When the Oracle Communications Session Border Controller manages calls originating from a preferred source
going to a transparent target, it:
Performs 2833 translation when the originating side requests 2833 but the target is configured as transparent and
does not negotiate 2833.
Allows 2833 to pass through if the originating side and the target of the call are configured as transparent and
negotiate 2833. The Oracle Communications Session Border Controller does not perform active translation
because both ends support 2833.
If one SIP endpoint does not signal 2833 capability, but the other SIP or H.323 endpoints do, the Oracle
Communications Session Border Controller does not perform 2833 translation.
• Performs 2833 translation if the originating endpoint does not signal 2833 and the next-hop endpoint for the
preferred target does signal 2833
• Does not perform 2833 translation or transparently relay 2833 if the originating endpoint signals 2833 and the
next-hop endpoint for the preferred target (or even a transparent 2833 target) does not signal 2833.
• H.245 signal type UII for DTMF for H.323 endpoints that do not signal 2833, but do signal explicit H.245 UII
capability, for stacks configured for transparent 2833 support.
When the other half of the call is an H.323 endpoint of a stack configured for preferred 2833, the Oracle
Communications Session Border Controller translates incoming H.245 signaled UII on the transparent side, to
2833 packets on the preferred side, and vice versa. If the other half of the call is an H.323 endpoint of a
transparent stack, the Oracle Communications Session Border Controller relays the H.245 UII messages if both
sides support it.
SIP Endpoints
SIP endpoints include those that support:
• RFC 2833
• SIP INFO method
From this point, you can configure SIP interface parameters. To view all sip-interface parameters, enter a ? at the
system prompt.
4. rfc2833-payload—Enter a number that indicates the payload type the SIP interface will use for RFC 2833
packets while interworking 2833 and UII. The default value is 101.The valid range is:
• Minimum—96
• Maximum—127
5. rfc2833-mode—Set the RFC 2833 mode for the SIP interface. The default value is transparent. Valid
values are:
• transparent—The SIP INFO and RFC 2833 translation is transparent to the Oracle Communications
Session Border Controller.
• preferred—The RFC 2833 transfer method is the preferred method for sending DTMF, and a telephone
event is inserted in the SDP of the outgoing offer. The actual method of transfer, however, depends on the SDP
offer/answer exchange that occurs between the Oracle Communications Session Border Controller and remote
endpoint. If the remote endpoint supports RFC 2833, the Oracle Communications Session Border Controller
performs SIP INFO—RFC 2833 conversion.
• dual—The Oracle Communications Session Border Controller behaves the same as it does when set to
preferred mode, and it forwards both the original DTMF mechanism and the translated one to the remote
endpoint.
Note: Timestamp changes and duration changes only take effect when the 2833 timestamp (rfc-2833-
timestamp) is enabled in the media manager configuration.
Enhancements Configuration
This section shows you how to configure enhancements for H.245 UII/SIP INFO—2833 DTMF interworking.
To enable the Oracle Communications Session Border Controller to calculate the timestamp based on the current
time:
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
3. Type media-profile and press Enter.
ORACLE(media-manager)# media-manager
ORACLE(media-manager-config)#
4. rfc-2833-timestamp—Enable this parameter to use a timestamp value calculated using the actual time
elapsed since the last RTP packet. The default is disabled. Valid values are:
• enabled | disabled
5. Save and activate your configuration.
To configure a duration for the 2833 event:
6. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
7. Type media-manager and press Enter.
ORACLE(configure)# media-manager
8. Type media-profile and press Enter.
ORACLE(media-manager)# media-manager
ORACLE(media-manager-config)#
9. default-2833-duration—Set this parameter to the time value in milliseconds for the Oracle
Communications Session Border Controller to use when it receives an alphanumeric UII or a SIP INFO with no
specified duration; then the three end-event packets are sent. The default value is 100. The valid range is:
• Minimum—50
• Maximum—5000
10. Save and activate your configuration.
4. options—Set the options parameter by typing options, a Space, the option name min-signal-
duration=x (where x is the value in milliseconds you want to use for the threshold) with a plus sign in front
of it. Then press Enter.
ORACLE(media-manager-config)# options +min-signal-duration=200
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 option 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.
When the Oracle Oracle Communications Session Border Controller receives an INFO DTMF request, the SIP
process determines whether or not it needs to perform DTMF-to-RFC2833 translation. If translation is required, the
process forwards the DTMF to the 2833 convert process for translation and transmission to the recipient. Immediately
after off-loading the DTMF, the SIP process sends a 200 OK response for the INFO. As shown in the figure, the 2833
convert process generates a number of RFC2833 packets to represent received DTMF digits.
Specifically, the 2833 convert process generates one RFC 2833 packet every 50 milliseconds for the duration of the
DTMF digit, whose length is specified in the INFO request, and two retransmits of the last packet (known as the end
packet) 50 milliseconds apart.
Consequently, the time interval between the 200 OK and the actual transmission of the RFC 2833 translation is the
sum of the DTMF duration and 100 ms.
Note: This time interval can be shortened to 100 ms by enabling the rfc2833-end-pkts-only-for-non-sig
parameter in media-manger which results in Oracle Communications Session Border Controller only
generating the last packet and its two retransmits.
The early 200 OK allows the endpoint to send the next DTMF digit before the SD has sent all the RFC2833 packets,
resulting in the next digit being queued internally by the 2833 convert process before being sent.
A problem arises if the SIP process receives a BYE request from the DTMF originator while queued digits are
awaiting translation and transmission. In such an event, the SIP process immediately forwards the BYE request to the
recipient, ending the session with DTMF digits awaiting translation and transmission.
An alternative DTMF conversion model provides for a feedback mechanism from the 2833 convert process to the SIP
process. With this model enabled, the SIP process buffers a received BYE until it obtains confirmation that all queued
DTMF digits have been translated and transmitted. Only after obtaining confirmation, does it forward the BYE to
terminate the session.
This processing model is enable by a SIP option, sync-bye-and-2833, and requires that rfc2833-mode
parameter on the egress interfaces is NOT set to dual, any value other than dual, is supported.
1. From superuser mode, use the following command sequence to access sip-config configuration mode.
ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# sip-config
ORACLE(sip-config)#
2. Use the SIP option sync-bye-and-2833 to delay BYE processing until DTMF-to-RFC2833 translation has
been completed.
ORACLE(sip-config)# options +sync-bye-and-2833=”enabled”
ORACLE(sip-config)#
3. Use the done and exit commands to complete configuration.
ORACLE(sip-config)# done
ORACLE(sip-config)# exit
ORACLE(session-router)#
rtpmap Attribute
The rtpmap attribute takes the form:
a=rtpmap:<payloadType> <encodingName>/<clockRate>[/audioChannels]
payloadType: contains a dynamically-assigned RTP payload type as specified in RFC 3551, RTP Profile for Audio
and Video Conferences with Minimal Control. The Internet Assigned Numbers Authority (IANA) has designated RTP
payload types 96 through 127 as available for dynamic assignment.
encodingName: contains the codec identifier (AMR or AMR-WB in the following tables).
clockRate: contains the sampling rate.
audioChannels: (used only for audio streams, and optional) contains the number of audio channels — not used in
transcoding decisions.
fmtp Attribute
The fmtp attribute shown in the following tables takes the form:
a=fmtp:<amrParameter> <parameterValues>
amrParameter contains one of the AMR/AMR-WB RTP-specific parameters listed below.
channels
crc
interleaving
max-red
maxtime
mode-change-capability
mode-change-neighbor
mode-change-period
mode-set
octet-align
ptime
robust-sorting
parameterValue: contains the value of the specified parameter.
Basic Scenarios
Examples provided in this section are supported by the following codec policy and media profiles.
codec-policy
name net192
allow-codecs *
add-codecs-on-egress AMR::PT96 AMR-WB::PT97 AMR::PT98
AMR-WB::PT99
order-codecs
force-ptime disabled
packetization-time 30
dtmf-in-audio disabled
media-profile
name AMR
subname PT96
media-type audio
payload-type 96
transport RTP/AVP
req-bandwidth 0
frames-per-packet 0
parameters
average-rate-limit 0
peak-rate-limit 0
max-burst-size 0
sdp-rate-limit-headroom 0
sdp-bandwidth disabled
police-rate 0
standard-pkt-rate 0
media-profile
name AMR-WB
subname PT97
media-type audio
payload-type 97
transport RTP/AVP
req-bandwidth 0
frames-per-packet 0
parameters
average-rate-limit 0
media-profile
name AMR
subname PT98
media-type audio
payload-type 98
transport RTP/AVP
req-bandwidth 0
frames-per-packet 0
parameters mode-set="0,1,2,3"
average-rate-limit 0
peak-rate-limit 0
max-burst-size 0
sdp-rate-limit-headroom 0
sdp-bandwidth disabled
police-rate 0
standard-pkt-rate 0
media-profile
name AMR-WB
subname PT99
media-type audio
payload-type 99
transport RTP/AVP
req-bandwidth 0
frames-per-packet 0
parameters mode-set="0,1,2,3"
average-rate-limit 0
peak-rate-limit 0
max-burst-size 0
sdp-rate-limit-headroom 0
sdp-bandwidth disabled
police-rate 0
standard-pkt-rate 0
The following SDP reflects the case where the session responder answers with the same codec and payload type as
presented by the session initiator.
Here, given the identical offer and answer, neither transcoding nor payload type mapping is required.
The following SDP reflects the case where the session responder answers with the codec offered by the session
initiator, but with a different payload type.
Here, given the identical offer/answer except for the payload type, transcoding is not required; payload type mapping
is used.
The following SDP reflects the case where the session responder answers with a codec not offered by the session
initiator.
a=rtpmap:96 AMR/8000
INVITE SDP (partial, codec information only)
Offer sent to responder (per the net192 codec policy) m=audio xx RTP/AVP 97 98 99 96
from AMR-WB/PT97 media profile a=rtpmap:97 AMR-WB/16000/1
from AMR-WB/PT98 media profile a=rtpmap:98 AMR/8000
a=fmtp:98 mode-set=0,1,2,3
from AMR-WB/PT99 media profile a=rtpmap:99 AMR-WB/16000/1
a=fmtp:99 mode-set=0,1,2,3
initiator offer a=rtpmap:96 AMR/8000
Answer received from responder m=audio xx RTP/AVP 97
a=rtpmap:97 AMR/16000
Answer sent to initiator m=audio xx RTP/AVP 96
a=rtpmap:96 AMR/8000
Here, given that the offer and answer codecs (AMR and AMR-WB) are not identical, transcoding is required.
The following SDP reflects the case where the offer specifies the inclusive mode-set, and the answer specifies a non-
inclusive mode-set.
Here, given that the answer mode-set (0,1,2,3) intersects with the offered mode-set (0,1,2,3,4,5,6,7), transcoding is
not required; payload type mapping is used.
The following SDP reflects the case where the offer specifies a non-inclusive mode-set, and the answer specifies the
inclusive mode-set.
Here, given that the offer mode-set (0,1,2,3) intersects with the answer mode-set (0,1,2,3,4,5,6,7), transcoding is not
required; payload type mapping is used.
Advanced Scenarios
Examples provided in this first section are supported by the following codec policy and media profile.
codec-policy
name net182
allow-codecs *
add-codecs-on-egress AMR::PT97-5-6-7
order-codecs
media-profile
name AMR
subname PT97-5-6-7
media-type audio
payload-type 97
transport RTP/AVP
req-bandwidth 0
frames-per-packet 0
parameters mode-set="5,6,7"
average-rate-limit 0
peak-rate-limit 0
max-burst-size 0
sdp-rate-limit-headroom 0
sdp-bandwidth disabled
police-rate 0
standard-pkt-rate 0
The following SDP reflects the case where the offer and answer specify non-matching mode-sets.
Here, given that the offer mode-set (1,2,3,4) does not intersects with the answer mode-set (5,6,7), transcoding is
required.
The following SDP reflects the case where the offer and answer specify intersecting mode-sets.
Here, given that the offer mode-set (1,2,3,4) intersects with the answer mode-set (4,5,6,7), transcoding is not required;
payload type mapping is used.
Examples provided in this next section are supported by the following codec policy and media profiles.
codec-policy
name net192
allow-codecs *
add-codecs-on-egress AMR::PT96-MAXRED AMR::PT97-BE-0257
AMR::PT98-OA AMR::PT99-OA-0257
order-codecs
force-ptime disabled
packetization-time 20
dtmf-in-audio disabled
media-profile
name AMR
subname PT96-MAXRED
media-type audio
payload-type 96
transport RTP/AVP
req-bandwidth 0
frames-per-packet 0
parameters max-red=220
average-rate-limit 0
peak-rate-limit 0
max-burst-size 0
media-profile
name AMR
subname PT97-BE-0257
media-type audio
payload-type 97
transport RTP/AVP
req-bandwidth 0
frames-per-packet 0
parameters mode-set="0,2,5,7"
average-rate-limit 0
peak-rate-limit 0
max-burst-size 0
sdp-rate-limit-headroom 0
sdp-bandwidth disabled
police-rate 0
standard-pkt-rate 0
media-profile
name AMR
subname PT98-OA
media-type audio
payload-type 98
transport RTP/AVP
req-bandwidth 0
frames-per-packet 0
parameters octet-align=1
average-rate-limit 0
peak-rate-limit 0
max-burst-size 0
sdp-rate-limit-headroom 0
sdp-bandwidth disabled
police-rate 0
standard-pkt-rate 0
media-profile
name AMR
subname PT99-OA-0257
media-type audio
payload-type 99
transport RTP/AVP
req-bandwidth 0
frames-per-packet 0
parameters mode-set="0,2,5,7",octet-align=1
average-rate-limit 0
peak-rate-limit 0
max-burst-size 0
sdp-rate-limit-headroom 0
sdp-bandwidth disabled
police-rate 0
standard-pkt-rate 0
The following SDP reflects the case where the offer and answer differ only in the inclusion of an AMR/AMR-WB
parameter in the answer.
a=rtpmap:96 AMR/8000
INVITE SDP (partial, codec information only)
Offer sent to responder (per the net192 codec policy) m=audio xx RTP/AVP 97 98 99 96
from AMR/PT97-BE-0257 media profile a=rtpmap:97 AMR/8000
a=fmtp:97 mode-set=0,2,5,7
from AMR/PT98-OA media profile a=rtpmap:98 AMR/8000
a=fmtp:98 octet-align=1
from AMR/PT99-OA-0257 media profile a=rtpmap:99 AMR/8000
a=fmtp:99 mode-set=0,2,5,7 octet-align=1
initiator offer a=rtpmap:96 AMR/8000
Answer received from responder m=audio xx RTP/AVP 96
a=rtpmap:96 AMR/8000
a=fmtp:96 max-red=220
Answer sent to initiator m=audio xx RTP/AVP 96
a=rtpmap:96 AMR/8000
a=fmtp:96 max-red=220
Here, given that the offer/answer are identical except for the AMR max-red parameter, neither transcoding nor
payload type matching is required.
The following SDP reflects the case where the offer and answer differ only in the inclusion of an AMR/AMR-WB
parameter in the offer.
Here, given that the offer/answer are identical except for the AMR max-red parameter, neither transcoding nor
payload type matching is required.
ACLI Configuration
To enable AMR Mode-set payload type SDP rewriting:
1. Navigate to the media-manager-config element.
ACMEPACKET# configure terminal
ACMEPACKET(configure)# media-manager
ACMEPACKET(media-manager)# media-manager-config
ACMEPACKET(media-manager-config)#
2. options—Set the options parameter by typing options, a Space, the option-name audio-payload-type-mapping=yes
with a “plus” sign in front of it, and then press Enter.
ACMEPACKET(media-manager-config)# options +audio-payload-type-mapping=yes
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.
3. Save and activate your configuration.
As specified in RFC 3326, the Oracle Communications Session Border Controller sends SIP responses to the
softswitch that contain the received Q.850 cause code and the reason.
Though the Oracle Communications Session Border Controller can generate RFC 3326 headers, the default behavior
for this feature is disabled. Furthermore, the Oracle Communications Session Border Controller can receive and pass
SIP error messages (4xx, 5xx, and 6xx) that contain the SIP reason header with a Q.850 cause code and reason (as
specified in RFC 3326). If the Oracle Communications Session Border Controller receives an error message without
the Reason header, then the Oracle Communications Session Border Controller is not required to insert one.
In calls that require IWF, the Q.850 cause generated in the SIP response are the same as the cause received in the
following H.225 messages: Disconnect, Progress, Release, Release Complete, Resume Reject, Status, and Suspend
Reject. In addition, the Q.850 cause codes that the Oracle Communications Session Border Controller receives in
RFC 3326 headers are passed to the H.323 part of the call unmodified; the H.323 call leg uses this cause code for
releasing the call.
For interworking calls between SIP and H.323, you can configure:
• Mappings for SIP status codes to Q.850 values
• Mappings for particular Q.850 cause codes to SIP status codes
If it cannot find the appropriate mapping, then the Oracle Communications Session Border Controller uses default
mappings defined in the Default Mappings table below.
The following describes how the Oracle Communications Session Border Controller handles different IWF call
scenarios:
• SIP request containing a Reason header—When it receives a request containing a Reason header, the Oracle
Communications Session Border Controller determines if the request is a SIP BYE or SIP CANCEL message.
RFC 3326 states that the Reason header is mainly used for these types of requests. If there is a Reason header and
it contains the Q.850 cause value, then the Oracle Communications Session Border Controller releases the call on
the H.323 side using the specified cause value.
• SIP response—When it receives the error response to an initial SIP INVITE, the Oracle Communications Session
Border Controller uses its SIP-Q.850 map to determine the Q.850 that it will use to release the call. If there is not
a map entry, then the Oracle Communications Session Border Controller uses the default mappings shown in the
Default Mappings table.
• Active call released from the H.323 side—If an active call is released from the H.323 side, the Oracle
Communications Session Border Controller checks the outgoing realm (the SIP side) to see if the addition of the
Reason header is enabled. If it is, then the Oracle Communications Session Border Controller adds the Reason
header in the SIP BYE request with the Q.850 value it received from the H.323 side.
• Error during setup of the call on the H.323 side—In the event of an error during setup on the H.323 side of the
call, the Oracle Communications Session Border Controller needs to send:
• An error response, if this is a SIP to H.323 call
• A SIP CANCEL, if this is a H.323 to SIP call and the H.323 side hangs up before the call is answered on the
SIP side
In this case, the Oracle Communications Session Border Controller checks to see if adding the Reason header
is enabled in the IWF configuration. If it is, then the Oracle Communications Session Border Controller adds
the Reason header with the Q.850 cause value it received from the H.323 side.
• Call released due to a Oracle Communications Session Border Controller error—If the call is released due a
Oracle Communications Session Border Controller error and adding the Reason header is enabled in the IWF
configuration, the error response to the initial INVITE contains the Reason header. The Oracle Communications
Session Border Controller checks the SIP to Q.850 map configurations to determine whether or not the SIP error
response code it is generating is configured. If it is, then the system maps according to the configuration. If if it
not, the Oracle Communications Session Border Controller derives cause mapping from the default table.
Like the configuration for SIP-only calls that enable this feature, you can set a parameter in the IWF configuration
that enables adding the Reason header in the SIP requests or responses.
Default Mappings
This table defines the default mappings the Oracle Communications Session Border Controller uses when it cannot
locate an appropriate entry that you have configured.
5. sip-status—Set the SIP response code that you want to map to a particular Q.850 cause code and reason.
There is no default, and the valid range for values is:
• Minimum—100
• Maximum—699
6. q850-cause—Set the Q.850 cause code that you want to map to the SIP response code that you set in step 5.
There is no default.
7. q850-reason—Set the Q.850 reason corresponding to the Q.850 cause code that you set in step 6. There is no
default. If your value has spaces between characters, then your entry must be surrounded by quotation marks.
8. Repeat this process to create the number of local response map entries that you need.
9. Save and activate your configuration for changes to take effect.
To configure a Q.850 cause to a SIP status with reason mapping:
10. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
11. Type session-router and press Enter.
ORACLE(configure)# session-router
12. Type sip-q850-map and press Enter.
ORACLE(session-router)# q850-sip-map
ORACLE(q850-sip-map)#
13. Type entries and press Enter.
ORACLE(q850-sip-map)# entries
ORACLE(q850-sip-map-entry)#
From here, you can view the entire menu for the Q.850 cause to a SIP response code with reason mapping entries
configuration by typing a ?.
14. q850-cause—Set the Q.850 cause code that you want to map to a SIP status with reason. There is no default.
15. sip-status—Set the SIP response code to which you want to map the Q.850 cause that you set in step 5.
There is no default, and the valid range for a value is
• Minimum—100
• Maximum—699
16. sip-reason—Set the reason that you want to use with the SIP response code that you specified in step 6. There
is no default. If your value has spaces between characters, then your entry must be surrounded by quotation marks.
17. Repeat this process to create the number of local response map entries that you need.
To enable the Oracle Communications Session Border Controller to add the Reason header for calls that require
IWF:
18. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
19. Type session-router and press Enter.
ORACLE(configure)# session-router
20. Type iwf-config and press Enter.
ORACLE(session-router)# iwf-config
ORACLE(iwf-config)#
21. add-reason-header—Enable this parameter to add the Reason header to IWF calls. The default is
disabled. Valid values are:
• enabled | disabled
SIP to H.323
For a SIP to H.323 call, the Oracle Communications Session Border Controller must recognize the caller’s Privacy
request and set the presentation bits accordingly when constructing the outbound RAS/SETUP message. It must
check SIP calls for the Privacy header (with value set to id). If this header is present, the SETUP’s octet 3a’s
presentation bits must be set to restricted.
The Oracle Communications Session Border Controller does not support any other value for the Privacy header. For
those calls, the SETUP will not include a presentation indicator.
H.323 to SIP
When h323d receives a SETUP with the calling party’s information element presentation indicator set to allowed, the
Oracle Communications Session Border Controller will add the P-Asserted-Identity header to the INVITE. The P-
Asserted-Identity is very similar to the FROM header, except for the tag.
SIP to H.323
When the sipd receives an INVITE with the P-Asserted-Identity header but without the Privacy header, the Oracle
Communications Session Border Controller will set the presentation indicator to allowed in H.323’s SETUP.
When the Privacy header is present with the value id, the presentation indicator will be set to restricted. The Oracle
Communications Session Border Controller does not support any other value for the Privacy header and so for those
call flows, the presentation indicator will be absent in the SETUP.
• IWF caller privacy on secure connections—When the H.323 endpoint sends a SETUP with presentation indicator
set to allowed, the Oracle Communications Session Border Controller does not insert the P-Asserted-Identity in
the INVITE. The SIP INVITE needs the P-Asserted-Identity header to support calling line identification
presentation (CLIP) to calling line identification restriction (CLIR) in an IP multimedia subsystem (IMS) solution.
This feature allows the Oracle Communications Session Border Controller to insert the P-Asserted-Identity in the
INVITE when the presentation indicator is set to allowed.
Now the Oracle Communications Session Border Controller supports an enhancement to IWF caller privacy where
the P-Preferred-Identity is inserted instead of the P-Asserted-Identity.
In this implementation, when the incoming H.323 Setup message has a presentation indicator set to restricted and the
ingress H.323 session agent has the new PPreferredId option configured, the Oracle Communications Session Border
Controller sends the Privacy header with P-Preferred-Identity (instead of P-Asserted-Identity).
P-Preferred-Identity Configuration
To enable the inclusion of P-Preferred-Identity:
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.
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: 204.12.60.5 realm=private
Sample INVITE from the Oracle Communications Session Border Controller to the
SIP Endpoint
May 5 15:11:51.996 On [0:0]192.168.200.68:5060 sent to 192.168.200.6:5060
INVITE sip:780@192.168.200.6:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.200.68:5060;branch=z9hG4bK00020a20eg11s94pg700.1
Contact: "jdoe"<sip:42343@192.168.200.68:5060;transport=udp>
Supported: 100rel
From: "jdoe"<sip:42343@192.168.200.68:5060>;tag=SDetur801-00000194000e2ce8
To: <sip:780@192.168.200.6:5060>
Call-ID: SDetur801-231c7b30909ca525ce12cbfeb57754ea-06ahc21
CSeq: 2 INVITE
Privacy: id
Content-Length: 231
Content-Type: application/sdp
Max-Forwards: 70
v=0
o=IWF 2 2 IN IP4 192.168.200.65
s=H323 Call
c=IN IP4 192.168.200.65
t=0 0
Sample INVITE from a SIP Endpoint to the Oracle Communications Session Border
Controller
May 5 14:41:54.513 On [0:0]192.168.200.68:5060 received from
192.168.200.6:5060
INVITE sip:800@192.168.200.68:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.200.6:5060
From: sipp <sip:sipp@192.168.200.6:5060>;tag=1
To: sut <sip:800@192.168.200.68:5060>
Call-ID: 1.3068.192.168.200.6@sipp.call.id
Cseq: 1 INVITE
Contact: sip:sipp@192.168.200.6:5060
Privacy: id
P-Asserted-Identity: sipp <sip:1234@192.168.200.6:5060>
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: 136
v=0
o=user1 53655765 2353687637 IN IP4 127.0.0.1
s=-
t=0 0
c=IN IP4 127.0.0.1
m=audio 10000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Sample SETUP from the Oracle Communications Session Border Controller to the H.
323 Endpoint
Q.931
Protocol discriminator: Q.931
Call reference value length: 2
Call reference flag: Message sent from originating side
Call reference value: 44B0
Message type: SETUP (0x05)
Bearer capability
Information element: Bearer capability
Length: 3
...1 0000 = Information transfer capability: 3.1 kHz audio (0x10)
.00. .... = Coding standard: ITU-T standardized coding (0x00)
1... .... = Extension indicator: last octet
...1 0000 = Information transfer rate: 64 kbit/s (0x10)
.00. .... = Transfer mode: Circuit mode (0x00)
1... .... = Extension indicator: last octet
allowCPN Configuration
You can set both of these options in the same H.323 session agent.
To set the allowCPN option for an H.323 session agent:
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 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
4. Use the ACLI select command so that you can work with the session agent configuration to which you want to
add this option.
ORACLE(session-agent)# select
5. options—Set the options parameter by typing options, a Space, the option name allowCPN with a plus
sign in front of it, and then press Enter.
ORACLE(session-agent)# options +allowCPN
If you type options allowCPN (without the plus sign), 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.
To set the NoPAssertedId option for an H.323 session agent:
Terminology
The following IPTEL terms are used in the descriptions of and instructions for how to configure this feature:
• Trunk—In a network, a communication path connecting two switching systems used in the establishment of an
end-to-end connection; in selected applications, it may have both its terminations in the same switching system
• Trunk group—A set of trunks, traffic engineered as a unit, for the establishment of connections within or between
switching systems in which all of the paths are interchangeable except where sub-grouped
• Trunk group name—Provides a unique identifier of the trunk group; referred to as tgrp
• Trunk group context—Imposes a namespace by specifying a domain where the trunk groups are; also referred to
simply as context
There are two available formats for the originating trunk group URIs:
1. In compliance with the IPTEL draft, the first format has two parameters: tgrp (identifier of the specific trunk
group) and trunk-context (defines the network domain of the trunk group). These appear in the following formats:
• tgrp=”trunk group name”
• trunk-context=”network domain”
The URI BNF for would appear as it does in the example directly below, where the tgrp is tg55 and the trunk-
context is trunk-context is telco.example.com:
tel:+15555551212;tgrp=tg55;trunk-context=telco.example.com
2. The second format is customized specifically for access URIs and contains two provisioned parameters: tgrp (or
tgname) and context (or provstring). This appears as tgrp.context, where these definitions apply:
• tgrp (tgname)—Provisioned trunk group name for the originating session agent; this value must have at least
one alphabetical character, cannot contain a period (.), and can contain a hyphen (-) but not as the first or the
last character
• context (provstring)—Name of the originating trunk group context; this value must have at least one
alphabetical character in the top label
This format conforms to format for a hostname in the SIP URI as specified in RFC 3261, such that a trunk
group identifier would appear as:
custsite2NY-00020.type2.voip.carrier.net
where the tgrp is custsite2NY-00020, and the context is type2.voip.carrier.net.
The BNF for an access URI conforms to the following:
SIP-URI = "sip:" [userinfo ] hostport uri-parameters [headers ]
uri-parameters = *( ";" uri-parameter )
uri-parameter = transport-param / user-param / method-param
/ ttl-param / maddr-param / lr-param / other-param
other-param = accessid / pname [ '=' pvalue ]
accessid = "access=" accessURI
accessURI = scheme tgname ["." provstring]
scheme = "sip:" / token
tgname = ALPHA / *(alphanum) ALPHA *(alphanum / "-") alphanum /
alphanum *(alphanum / "-") ALPHA *(alphanum) # up to 23 characters
provstring = *(domain ".") toplabel # up to 24 characters
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
domain = alphanum/ alphanum *( alphanum / "-" ) alphanum
In the absence of official SIP standards for transporting trunk groups between signaling elements, the Oracle
Communications Session Border Controller allows you to define the URI parameters used in terminating trunk
groups.
There are two available formats for the terminating trunk group URIs:
1. In compliance with the IPTEL draft, the first format has two parameters: tgrp (which can be either a trunk group
name or an IP address) and trunk-context (defines the network domain of the trunk group). These appear in the
following formats:
• tgrp=”trunk group name”
• trunk-context=”network domain”
An example R-URI with terminating trunk group parameters appears as follows, where the tgrp is TG2-1 and
the context is isp.example.net@egwy.isp.example.net:
INVITE sip:+15555551212;tgrp=TG2-1;trunk-
context=isp.example.net@egwy.isp.example.net SIP/2.0
2. The second format is customized specifically for egress URIs and contains two provisioned parameters: tgrp (or
tgname) and context (or tgdomain). This appears as tgrp.context (or tgname.tgdomain), where definitions apply:
• tgrp (tgname)—Provisioned trunk group name for the originating session agent; this value must have at least
one alphabetical character, cannot contain a period (.), and can contain a hyphen (-) but not as the first or the
last character
• context (tgdomain)—Name of the terminating trunk group context; this value can be up to twenty-four
characters
The use of multiple terminating trunk groups is not supported.
The BNF for a single, egress URI with trunk group information conforms to:
SIP-URI = "sip:" [userinfo ] hostport uri-parameters [headers ]
uri-parameters = *( ";" uri-parameter )
uri-parameter = transport-param / user-param / method-param
• If the terminating trunk group URI parameters do not identify a local Oracle Communications Session Border
Controllersession agent or session agent group, then the Oracle Communications Session Border Controller
returns a SIP final response of 488 Not Acceptable Here.
• If the Oracle Communications Session Border Controller receives a SIP INVITE with terminating trunk group
URI parameters that do not match the specified syntax, the Oracle Communications Session Border
Controllerreturns a 400 final response with the reason phrase Bad Egress=Parameters.
4. trunk-group—In either IPTEL or custom format, enter the trunk group names and trunk group contexts to
match. If you do not set the trunk group context, then the Oracle Communications Session Border Controller will
use the one you set in the realm for this session agent group.
Your ACLI entries for this list must take one of these formats: tgrp:context or tgrp.context.
To make multiple entries, surround your entries in parentheses and separate them from each other with spaces. For
example:
ORACLE(session-agent-group)# trunk-group (tgrp1:context1 tgrp2:context2)
• Network provided
• User-provided, verified and passed
Then the Oracle Communications Session Border Controller adds a SIP PAI header (with URI value) to the 200 OK
message that it sends in the SIP call leg. The user part of the URI is set to the value of the Q.931 Connected Number
IE’s numberDigits field, or to dialDigits value from the Connected Address alias. When the number type is a national
number, the Oracle Communications Session Border Controller adds a plus sign (+) and the IWF country code (that
you configure) to the beginning of the user part. If the number type is an international number, the Oracle
Communications Session Border Controller only adds a plus sign (+). And when the Connected Number is empty, the
Oracle Communications Session Border Controller sets the user part of the PAI header URI to anonymous. When the
value in the presentation indicator is Presentation restricted, the Oracle Communications Session Border Controller
adds the SIP Privacy header (with the value id) to the 200 OK.
In cases when it does not find a screening indicator, the Oracle Communications Session Border Controller will not
perform the conversion from the H.323 Connected Number IE to the SIP P-Asserted-Identity (PAI) header.
H.323 SA Options
Options Description
MapG729 Oracle Communications Session Border Controller maps H.245 G.729 to SDP G.729
with Annex B and vice versa. Applicable only to calls that require the IWF.
ColonG729 Oracle Communications Session Border Controller uses the : (colon) instead of the =
(equal sign) in the media attribute line a=fmtp:18 annexb=yes/no when mapping H.245
G.729 or SDP G.729 with Annex B. Applicable only to calls that require the IWF.
IwfLRQ Oracle Communications Session Border Controller sends an INVITE (with no SDP) to
a redirect server in response to an incoming LRQ received on an H.323 interface. If a
3xx message with a redirected contact header is returned, the Oracle Communications
Session Border Controller will send an LCF in response to the LRQ. Otherwise, it will
send an LRJ.
Options Description
NoG729AnnexB SDP received by the IWF with H.729 and no FMTP will be mapped to G.729 on the H.
323 side of the call. Can also be set in the session agent options parameter.
sameT38Port Oracle Communications Session Border Controller’s H.323 process does not allocate
separate ports for audio and T.38. Oracle Communications Session Border Controller
will send the same audio port in the OLCAck that it sees in a request mode for T.38 and
a new OLC for T.38.
pvtStats Oracle Communications Session Border Controller includes program value tree (PVT)
statistics in the show h323d display that are a sum of the PVT statistics for all H.323
interfaces. Used for debugging purposes.
acceptAl Oracle Communications Session Border Controller accepts all the codecs received in
the SIP 200OK and builds the TCS accordingly.
suppress100rel Configuration
To suppress the SIP 100rel option tag:
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 h323 and press Enter.
ORACLE(session-router)# h323
ORACLE(h323)#
4. Type h323-stacks and press Enter.
ORACLE(h323)# h323-stacks
ORACLE(h323-stack)#
If you are adding support for this feature to a pre-existing H.323 interface (stack), then you must select (using the
ACLI select command) the configuration that you want to edit.
5. options—Set the options parameter by typing options, a Space, the option name suppress100rel with a
plus sign in front of it, and then press Enter.
ORACLE(h323-stack)# options +suppress100rel
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 option to this configuration’s options list, you must prepend the new option
with a plus sign as shown in the previous example.
To support G.726 for IWF calls, the Oracle Communications Session Border Controller converts the G726-X value in
the SDP of SIP messages to a GenericCapability structure in H.323/H.245 messages, and the conversion works the
same way in reverse.
• payload-type—For each media profile (G.729a and G.729ab), DO NOT use payload type 18, which is the
static payload type used for G729.
Identifier Description
maxBitRate This field shall be included, in units of 100 bit/s. This field represents the
maximum bitrate of the H.264 Type II bitstream as defined in Annex C/H.
264.
collapsing This field shall contain the H.264 Capability Parameters as given below.
Capabilities
The H.264 capability set is structured as a list of one or more H.264 capabilities, each of which has:
• Profile (mandatory)
• Level (mandatory)
• Zero or more additional parameters
These capabilities communicate the ability to decode using one or more H.264 profiles contained in a
GenericCapability structure. For each H.264 capability, optional parameters can appear. These parameters permits a
terminal to communicate that it has capabilities in addition to meeting the support requirements for the signaled
profile and level.
H.264 in SIP
H.264 in SIP can contain these optional parameters, which be included in the "a=fmtp" line of SDP if they appear:
profile-level-id, max-mbps, max-fs, max-cpb, max-dpb, maxbr, redundant-pic-cap, sprop-parameter-sets, parameter-
add, packetization-mode, spropinterleaving-depth, deint-buf-cap, sprop-deint-buf-req, sprop-init-buf-time, sprop-
max-dondiff, and max-rcmd-nalu- size.
The profile-level-id parameter is a base 16[6] hexidecimal representation of the following three bytes in sequence:
1. profile_idc
2. profile_oip—Composed of the values from constraint_set0_flag, constraint_set1_flag, constraint_set2_flag, and
reserved_zero_5bits—in order of bit significance, starting from the most significant bit.
3. level_idc—Note that reserved_zero_5bits is required to be equal to 0 in [1], but other values for it may be
specified in the future by ITU-T or ISO/IEC.
H264_PROFILE_STR_BASELINE 66 64
H264_PROFILE_STR_MAIN 77 32
H264_PROFILE_STR_EXTENDED 88 32
1 10 15 0x00
1b 11 19 0x10
1.1 11 22 0x00
1.2 12 29 0x00
1.3 13 36 0x00
2 20 43 0x00
2.1 21 50 0x00
2.2 22 57 0x00
3 30 64 0x00
3.1 31 71 0x00
3.2 32 78 0x00
4 40 85 0x00
4.1 41 92 0x00
4.2 42 99 0x00
5 50 106 0x00
5.1 51 113 0x00
iPpacketization(0) RFC3984Interleaved(2)}
H.263+ in H.323
This section describes the H.264 capabilities and media packetization in H.323. Capability exchange signaling looks
like this:
. . . . . capability . CHOICE [EMPTY -1] ...
. . . . . . receiveVideoCapability . CHOICE [EMPTY -1] ...
. . . . . . . h263VideoCapability . SEQUENCE [EMPTY -1] ...
. . . . . . . . sqcifMPI = 1 . INTEGER [EMPTY -1] (1..32)
. . . . . . . . qcifMPI = 1 . INTEGER [EMPTY -1] (1..32)
. . . . . . . . cifMPI = 1 . INTEGER [EMPTY -1] (1..32)
. . . . . . . . maxBitRate = 1000 . INTEGER [EMPTY -1] (1..192400)
. . . . . . . . unrestrictedVector = 0 . BOOLEAN [EMPTY -1]
. . . . . . . . arithmeticCoding = 0 . BOOLEAN [EMPTY -1]
. . . . . . . . advancedPrediction = 0 . BOOLEAN [EMPTY -1]
. . . . . . . . pbFrames = 0 . BOOLEAN [EMPTY -1]
. . . . . . . . temporalSpatialTradeOffCapability = 0 . BOOLEAN [EMPTY -1]
. . . . . . . . errorCompensation = 0 . BOOLEAN [EMPTY -1]
. . . . . . . . h263Options . SEQUENCE [EMPTY -1] ...
. . . . . . . . . advancedIntraCodingMode = 1 . BOOLEAN [EMPTY -1]
. . . . . . . . . deblockingFilterMode = 1 . BOOLEAN [EMPTY -1]
. . . . . . . . . improvedPBFramesMode = 0 . BOOLEAN [EMPTY -1]
. . . . . . . . . unlimitedMotionVectors = 0 . BOOLEAN [EMPTY -1]
. . . . . . . . . fullPictureFreeze = 1 . BOOLEAN [EMPTY -1]
. . . . . . . . . partialPictureFreezeAndRelease = 0 . BOOLEAN [EMPTY -1]
. . . . . . . . . resizingPartPicFreezeAndRelease = 0 . BOOLEAN [EMPTY -1]
. . . . . . . . . fullPictureSnapshot = 0 . BOOLEAN [EMPTY -1]
. . . . . . . . . partialPictureSnapshot = 0 . BOOLEAN [EMPTY -1]
. . . . . . . . . videoSegmentTagging = 0 . BOOLEAN [EMPTY -1]
. . . . . . . . . progressiveRefinement = 0 . BOOLEAN [EMPTY -1]
. . . . . . . . . dynamicPictureResizingByFour = 0 . BOOLEAN [EMPTY -1]
. . . . . . . . . dynamicPictureResizingSixteenthPel = 1 . BOOLEAN [EMPTY -1]
. . . . . . . . . dynamicWarpingHalfPel = 0 . BOOLEAN [EMPTY -1]
. . . . . . . . . dynamicWarpingSixteenthPel = 0 . BOOLEAN [EMPTY -1]
. . . . . . . . . independentSegmentDecoding = 0 . BOOLEAN [EMPTY -1]
. . . . . . . . . slicesInOrder-NonRect = 0 . BOOLEAN [EMPTY -1]
. . . . . . . . . slicesInOrder-Rect = 0 . BOOLEAN [EMPTY -1]
. . . . . . . . . slicesNoOrder-NonRect = 0 . BOOLEAN [EMPTY -1]
. . . . . . . . . slicesNoOrder-Rect = 0 . BOOLEAN [EMPTY -1]
. . . . . . . . . alternateInterVLCMode = 1 . BOOLEAN [EMPTY -1]
. . . . . . . . . modifiedQuantizationMode = 1 . BOOLEAN [EMPTY -1]
. . . . . . . . . reducedResolutionUpdate = 0 . BOOLEAN [EMPTY -1]
. . . . . . . . . separateVideoBackChannel = 0 . BOOLEAN [EMPTY -1]
. . . . . . . . . videoBadMBsCap = 0 . BOOLEAN [EMPTY -1]
. . . . . . . . . h263Version3Options . SEQUENCE [EMPTY -1] ...
. . . . . . . . . . dataPartitionedSlices = 0 . BOOLEAN [EMPTY -1]
. . . . . . . . . . fixedPointIDCT0 = 0 . BOOLEAN [EMPTY -1]
. . . . . . . . . . interlacedFields = 0 . BOOLEAN [EMPTY -1]
H.263+ in SIP
H.263+ in SIP appears looks like this:
a=rtpmap:100 H263-1998/90000
a=fmtp:100 CIF=1; QCIF=1; SQCIF=1; D=1; F=1; I=1; J=1; L=1; S=1; T=1
a=rtpmap:34 H263/90000
a=fmtp:34 CIF=1; QCIF=1; SQCIF=1
sqcifMPI SQCIF
qcifMPI QCIF
cifMPI CIF
CIF4
CIF16
maxBitRate
unrestrictedVector D
arithmeticCoding E
advancedPrediction F
pbFrames G
temporalSpatialTradeOffCapability
errorCompensation H
h263Options
advancedIntraCodingMode I
deblockingFilterMode J
improvedPBFramesMode
unlimitedMotionVectors
fullPictureFreeze L
partialPictureFreezeAndRelease
resizingPartPicFreezeAndRelease
fullPictureSnapshot
partialPictureSnapshot
videoSegmentTagging
progressiveRefinement
dynamicPictureResizingByFour P=1
dynamicPictureResizingSixteenthPel P=2
dynamicWarpingHalfPel P=3
DynamicWarpingSixteenthPel P=4
independentSegmentDecoding R
slicesInOrder-NonRect K=1
slicesInOrder-Rect K=2
slicesNoOrder-NonRect K=3
slicesNoOrder-Rect K=4
alternateInterVLCMode S
modifiedQuantizationMode T
reducedResolutionUpdate Q
separateVideoBackChannel
videoBadMBsCap
PAR
CPCF
CUSTOM
h263Version3Options
There is no configuration required for the interworking between these two messages to work.
Exceptional Cases
When the relevant option in enabled, the Oracle Communications Session Border Controller can handle properly the
following cases of codec change:
• When the H.323 side rejects the request mode change, the Oracle Communications Session Border Controller
response to the SIP side with a 488 Not Acceptable. Session description and state remain unchanged, and the call
continues using the original session description.
• When the H.323 side does not respond to the request mode change within the timeout limitation, the Oracle
Communications Session Border Controller releases the call on both sides.
• When the SIP side does not respond to the ReINVITE within in the timeout limitation, the Oracle
Communications Session Border Controller releases the call on both sides.
• When the intersection of codec is empty, the Oracle Communications Session Border Controller rejects the codec
change on the SIP side with a 488 Not Acceptable and on the H.323 side with an H.245 RequestModeReject.
Session description and state remain unchanged, and the call continues using the original session description.
• If the Oracle Communications Session Border Controller does not receive any of the LogicalChannel request or
acknowledgement messages, the Oracle Communications Session Border Controller releases the call on both
sides.
Note that for protocol timeout errors, the preferred behavior is to release the call on both sides. Timeout errors usually
indicate network problems, such as an endpoint being unreachable.
DNS ALG
The Oracle Communications Session Border Controller’s DNS Application Layer Gateway (ALG) feature provides
an application layer gateway for DNS transactions on the Oracle Communications Session Border Controller. With
DNS ALG service configured, the Oracle Communications Session Border Controller can support the appearance of
multiple DNS servers on one side and a single DNS client on the other.
Overview
DNS ALG service provides an application layer gateway for use with DNS clients. DNS ALG service allows a client
to access multiple DNS servers in different networks and provides routing to/from those servers. It also supports
flexible address translation of the DNS query/response packets. These functions allow the DNS client to query many
different domains from a single DNS server instance on the client side of the network.
The Oracle Communications Session Border Controller’s DNS ALG service is commonly used when a DNS client
(such as a call agent) needs to authenticate users. In this case, the DNS client that received a message from a certain
network would need to authenticate the endpoint in a remote network. Since the DNS client and the sender of the
message are on different networks, the Oracle Communications Session Border Controller acts as an intermediary by
interoperating with both.
In the following diagram, the DNS client has received a message from an endpoint in Network A. Since the DNS
client is in a different realm, however, the DNS client receives the message after the Oracle Communications Session
Border Controller has performed address translation. Then the DNS client initiates a DNS query on the translated
address. The Oracle Communications Session Border Controller forwards the DNS request to the DNS server in
Network A, using the domain suffix to find the appropriate server. Network A’s DNS server returns a response
containing its IPv4 address, and then the Oracle Communications Session Border Controller takes that reply and
performs a NAT on the private address. The private address is turned into a public one that the DNS client can use to
authenticate the endpoint.
If you do not specify the number of bits, then all 32 bits of the IPv4 address will be used for matching. If you
set the number of bits to 0, then the address will simply be copied.
For example, if you set the server prefix to 10.3.17.2/16 and the client prefix to 192.168.0.0/16, then the
Oracle Communications Session Border Controller will return an address of 192.168.17.2 to the DNS client.
ORACLE(server-dns-attributes)# address-translation
ORACLE(address-translation)# server-prefix 10.3.17.2/16
ORACLE(address-translation)# client-prefix 192.168.0.0/16
Maximum Latency
The max-latency parameter sets a threshold under which requests must be responded to. If this value is exceeded, the
DNS server is put into the Constraints Exceeded State.
6. max-burst-rate—Enter the maximum number of messages that can pass through the system in the burst rate
window before setting the element to Constraints Exceeded.
7. max-inbound-burst-rate—Enter the maximum number of inbound messages received by the referencing
element within the burst rate window before setting the element to Constraints Exceeded.
8. max-outbound-burst-rate—Enter the maximum number of outbound messages forwarded from the
referencing element within the burst rate window before setting the element to Constraints Exceeded.
9. burst-rate-window—Enter the number of seconds during which to count messages toward a maximum
burst rate.
10. max-sustain-rate—Enter the maximum number of messages that can pass through the system in the
sustained rate window before setting the element to Constraints Exceeded.
11. max-inbound-sustain-rate—Enter the maximum number of inbound messages received by the
referencing element within the sustained rate window before setting the element to Constraints Exceeded.
12. max-outbound-sustain-rate—Enter the maximum number of outbound messages forwarded from the
referencing element within the sustained rate window before setting the element to Constraints Exceeded.
13. sustain-rate-window—Enter the number of seconds during which to count messages toward a maximum
sustained rate.
14. max-latency—Enter the time the Oracle Communications Session Border Controller waits to receive a
response to a request. After this value is exceeded, the DNS server is placed in Constraints Exceeded state.
15. time-to-resume—Enter the number of seconds that the referencing element stays in Constraints Exceeded
state and rejects messages before it returns to service.
16. Type done when finished.
Traps Description
apDnsAlgStatusChangeTrap This trap is set and clears when any DNS-config object
apDnsAlgStatusChangeClearTrap changes its operating status.
apDnsAlgConstraintStateChangeTrap This trap is set and clears when any dns-config object
apDnsAlgConstraintStateChangeClearTrap enters constraints exceeded state.
apDnsAlgSvrConstraintStateChangeTrap This trap is set and clears when any single DNS server
apDnsAlgSvrConstraintStateChangeClearTr enters constraints exceeded state.
ap
Refer to the MIB ZIP archive to view the AP-DNSALG-MIB MIB file.
Routing Overview
This section provides an overview of routing SIP and H.323 sessions when using the Oracle Communications Session
Border Controller. The Oracle Communications Session Border Controller chooses the next hop through the network
for each SIP and H.323 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 Communications Session
Border Controller to load balance and route around softswitch failures.
When a call request arrives at the Oracle Communications Session Border Controller, a decision making process then
occurs to determine whether the message is coming from a session agent. If so, the Oracle Communications Session
Border Controller checks whether that session agent is authorized to make the call. Local policy is then checked to
determine where to send the message on to.
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).
request. If it receives any response from the session agent, then the Oracle Communications Session Border
Controller 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 Communications Session Border Controller’s ping
request.
Details of this feature are as follows:
• The Oracle Communications Session Border Controller 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 Communications Session Border Controller 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 Communications Session Border Controller 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 Communications Session Border
Controller 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
Communications Session Border Controller’s ping request. Furthermore, the Oracle Communications Session
Border Controller 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
Communications Session Border Controller’s ping request or any dialog-creating request.
When the Oracle Communications Session Border Controller receives a session agent’s response to its ping request, it
first checks to see if there is an in-service list of responses configured for that session agent. If the list is configured
and the Oracle Communications Session Border Controller determines that there is a match, the session agent is
deemed in service. Otherwise it takes the session agent out of service. In this way, the in-service list takes precedence
over the out-of-service list. If you configure the in-service list, then the Oracle Communications Session Border
Controller ignores the out-of-service list.
If there is no list of in-service responses for the session agent, then the Oracle Communications Session Border
Controller checks the out of service list. If it is configured and the Oracle Communications Session Border Controller
determines that there is a match, the Oracle Communications Session Border Controller removes that session agent
from service. If there is no match, then the session agent is deemed in service.
By sending ping messages, the Oracle Communications Session Border Controller 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
Communications Session Border Controller starts sending a configured ping message to a session agent when traffic
for that session agent has become irregular. The Oracle Communications Session Border Controller 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-service-
response-codes parameter and takes the session agent sending it OOS. Because this parameter is blank by
default, the Oracle Communications Session Border Controller considers any SIP response code successful.
• Transaction timeout—A transaction timeout happens when the session agent fails to send a response to the Oracle
Communications Session Border Controller’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 Communications Session Border
Controller 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 Communications Session Border Controller 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 Communications Session Border Controller 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.
Maximum burst rate Maximum burst rate Maximum burst rate Session agent is Burst rate in
exceeded exceeded in current exceeded in current declared in constraint subsequent window
window. window. violation state. drops below
maximum burst rate.
If the session agent is a
gatekeeper and
gatekeeper routed
mode is not used, this
constraint is an
aggregate of all the
destination gateways.
Only maximum
outbound sessions are
measured.
Maximum sustained Maximum sustained Maximum burst rate Session agent is Sustained rate in
rate exceeded rate exceeded in exceeded in current declared in constraint subsequent window
current window. window. violation state. drops below the
maximum sustained
If the session agent is a
rate.
gatekeeper and
gatekeeper routed
mode is not used, this
constraint is an
aggregate of all the
destination gateways.
Only maximum
outbound sessions are
measured.
Session agent SIP transaction Response timer Session agent is Time to resume
unavailable or expire timer expires expires. The default is declared in constraint timer expires and the
unresponsive for any out-of- T301=4 seconds. violation state or out- Oracle
dialogue request. For of-service. The time Communications
Connect timer expires.
example, INVITE, to resume timer Session Border
The default is
REGISTER, or ping. starts. Controller declares
T303=32 seconds.
the session agent in-
If the session agent is a service.
peer gatekeeper, the
or
LRQ response time is
used to determine Session agent
availability. The RAS responds to
response timer is 4 subsequent pings
seconds. (SIP only).
Hunt Oracle Communications Session Border Controller 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 Communications Session Border Controller selects each session
agent in the order in which it is configured, routing a session to each session
agent in turn.
Least busy Oracle Communications Session Border Controller 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 Communications Session Border Controller 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.
unresolved ENUM queries, or SIP 4xx/5xx/6xx failure responses) after it has checked constraints. So the Oracle
Communications Session Border Controller only re-routes if there are additional matching local policies.
When you enable SIP SAG recursion, the Oracle Communications Session Border Controller 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
Communications Session Border Controller’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
Communications Session Border Controller selects session agents when this feature enabled:
• Round robin and hunt—The Oracle Communications Session Border Controller 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 Communications Session Border
Controller 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.
The following examples show how the Oracle Communications Session Border Controller 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 Communications Session Border Controller 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 Communications Session Border Controller 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 Communications Session Border Controller selects the first local policy based on the From
address value of 12.
Route Preference
The Oracle Communications Session Border Controller builds a list of possible routes based on the source realm and
the From-address (From-URI) and To-address (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 Communications Session Border Controller 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.
In addition, before performing the lookup match, the Oracle Communications Session Border Controller strips
characters that provide ease-of-reading separation. For example, if the Oracle Communications Session Border
Controller were to receive a req-uri containing tel:a-#1-781-328-5555, it would treat it as tel:a#17813285555.
SIP Routing
This section describes SIP session routing. When routing SIP call requests, the Oracle Communications Session
Border Controller 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 Communications Session Border
Controller 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.
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.
H.323 Routing
This section describes H.323 routing.
Controller’s configuration that has a realm ID value matching the identifier field of the realm with the appropriate
address prefix.
In the following example, the local policy matching yields a local policy with a next hop value of 169.125.4.1, which
corresponds to RealmB. The outgoing stack selected is Stack 3 because it is the first stack to have been configured
with RealmB as the realm ID.
Registration Caching
The Oracle Communications Session Border Controller can cache and proxy an H.225 RegistrationRequest (RRQ)
between an H.323 endpoint and a gatekeeper. Registration caching serves two functions:
• It allows aggregation of RRQs sent to a gatekeeper stack and proxies those requests through the gateway stack. If
the external gatekeeper associated with the gatekeeper stack supports additive registration, the requests will be
consolidated. Furthermore, if the gatekeeper supports additive registration, the Oracle Communications Session
Border Controller will register in an additive manner, meaning that will send additive RRQs.
• It allows the gatekeeper stack to use the registration information to route calls from other realms to endpoints in its
realms.
To perform registration caching, the Oracle Communications Session Border Controller must be configured with at
least two stacks. One of these stacks will receive registrations (gatekeeper stack), and one stack will proxy
registrations (gateway stack). The Oracle Communications Session Border Controller caches all successful
registrations and uses the cache to route calls to the endpoints.
Back-to-Back Gateway
When the Oracle Communications Session Border Controller is functioning as a back-to-back gateway (B2BGW), it
appears as multiple H.323 gateways to multiple networks. Each Oracle Communications Session Border Controller
virtual gateway discovers and registers with a gatekeeper in its respective domain. Each gateway relies on its
gatekeeper for admission and location services through the ARQ/ACF exchange. H.225 call control and H.245
messages are exchanged directly with the terminating gateway or gatekeeper. Routing policies are used to associate
one virtual gateway with another.
The following diagram illustrates the back-to-back gateway.
Load Balancing
This section describes Oracle Communications Session Border Controller 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.
Configuring Routing
This section explains how to configure routing on the Oracle Communications Session Border Controller.
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.
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-of-
service. 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.
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 Communications Session Border Controller 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 Communications Session Border Controller 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. app-protocol—Enter the protocol on which you want to send the message. The default value is SIP.
Available values are:
• SIP | H.323
9. app-type—If configuring H.323, indicate whether the application type is a gateway or a gatekeeper. Available
values include:
• H.323-GW—gateway
• H.323-GK—gatekeeper
10. 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 high-
level 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.
11. 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 Communications Session Border Controller, 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.
12. description—Optional. Enter a descriptive name for this session agent.
13. 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.
14. allow-next-hop-lp—Indicate whether this session agent can be used as a next hop in the 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
15. 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.
16. 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:
• minimum: zero (0) is the default value and means there is no limit
• maximum: 4294967295
maximum outbound sessions Maximum number of simultaneous outbound sessions (outbound from
the Oracle Communications Session Border Controller) 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.
Constraint Description
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.
For the sustained rate, the Oracle Communications Session Border
Controller 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.
Constraint Description
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:
• 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.
17. 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 Communications Session Border Controller 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.
send media session on session agents that support SIP-to-H.323 IWF call flows. This can cause call
failure.
22. 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.
23. 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 Communications Session Border Controller.
24. 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 Communications Session Border Controller
to wait between pings to this session agent. The default value is 0. The valid range is:
• Minimum: 0
• Maximum: 999999999
The Oracle Communications Session Border Controller only sends the ping if no SIP transactions (have
occurred to/from the session agent within the time period you enter here.
25. 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.
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.
26. 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 Communications Session Border Controller’s ping
request. The Oracle Communications Session Border Controller takes the session agent out of service should a
response code be used that does not appear on this list. Default is none.
27. 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 Communications Session Border Controller’s
ping request or any in-dialog creating request (such as an INVITE, SUBSCRIBE, etc.). The Oracle
Communications Session Border Controller ignores this list if an in-service list exists.
28. 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 Communications Session Border
Controller 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.
29. media-profiles—Optional and for H.323 only. You can enter a list of media profiles to open logical channels
when starting an outgoing call as a Fast Start H.323 call.
Values you enter here must start with either an alphabetical character from A through Z (A-Za-z) or with an
underscore (_). After the first character, each list entry can contain any combination of alphabetical or numerical
characters (0-9A-Za-z), as well as the period (.), the dash (-), and the underscore (_). For example,
netnet_mediaprofile1.
You can enter 1 to 24 characters.
Note: The values you enter here must correspond to a valid name you entered when you configure the
media profile.
30. 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.
31. 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 Communications Session Border Controller 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.
32. trust-me—Indicate whether this session agent is a trusted source, which the Oracle Communications Session
Border Controller 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.
session-agent
hostname 192.168.1.10
ip-address 192.168.1.10
port 5060
state enabled
app-protocol SIP
app-type
5. application-protocol—Indicate the signaling protocol you want to use with the session agent group. The default
value is SIP. The valid values are:
• SIP | H.323
6. 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-outbound-
sessions 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).
7. 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.
8. trunk-group—Enter trunk group names and trunk group contexts to match in either IPTEL or custom format. If
left blank, the Oracle Communications Session Border Controller 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.
9. 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
10. 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 Communications Session Border Controller returns a final
response to the UAC. You can enter the response codes as a comma-separated list or as response code ranges.
11. Type done to save your configuration.
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
• H.323 CalledPartyAddress
The system 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:
• 123*456
Note: After entering the to-address value, the Oracle Communications Session Delivery Manager
automatically saves it to the configuration when exiting from local policy.
6. source-realm—Enter the realm, or list of realms, you want the Oracle Communications Session Border
Controller 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
• 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 Communications Session Border Controller
local policy recursion), this terminates local policy recursion and immediately fails the request. In these cases,
the system responds a request with a 404 Not Found.
12. realm—Identify the egress realm (the realm used to reach the next hop) if the system 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. In H.323, the next hop address is matched against the realm’s address prefix to determine the
realm.
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 (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.
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:
• 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. app-protocol—Enter the signaling protocol to use when sending messages to the next hop. The valid values
are:
• H.323 | SIP
20. state—Indicate whether you want to enable or disable the local policy. The default value is enabled. The
valid values are:
• enabled | disabled
21. media-profiles—Configure a list of media profiles if you want the local policy to route SIP and H.323
traffic by the codecs specified in the SDP. The list of media profiles entered here are matched against the SDP
included in SIP or H.323 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
192.168.1.10
source-realm *
activate-time 2005-01-20 20:30:00
deactivate-time N/A
state enabled
last-modified-date 2005-01-10 00:36:29
policy-attribute
next-hop SAG:gw-sag2
realm
replace-uri enabled
carrier
start-time 0000
end-time 2400
The Oracle Communications Session Border Controller will provide a new parameter ping-all-addresses in
session-agent configuration mode to enable internal load balancing and RFC 3263 compliance. The Oracle
Communications Session Border Controller 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 Communications Session Border
Controller only pings the first available resolved IP addresses.
With status of each resolved IP addresses above, the Oracle Communications Session Border Controller 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 Communications
Session Border Controller 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 Communications Session Border Controller will provide the similar functionality as that listed above for
A-records, the Oracle Communications Session Border Controllerwill select first available routing destinations
because there is no priority/weight contained in A-records.
versions of the SBC software, only when a 503 failure from the SA was received would the SBC resend the session
request to the next dynamically resolved IP address (on the SRV/A record list).
By adding the recurse-on-all-failures option to a session agent, the Oracle Communications Session Border
Controller will resend a session request to the next address on the list after a 4xx or 5xx failure response has been
received from a session agent.
SA
UAC SBC (test.com)
192.168.1.1
INVITE sip:1234@test.com
100 Trying
INVITE
ACK
INVITE
ACK
INVITE
200 OK
200 OK
ACK
ACK
If the SBC receives a failure response from the session agent, and the number of that failure is configured in the stop-
recurse parameter, no further session requests will be forwarded to additional addresses from the SRV/A record list.
The error message will be forwarded back to the UA.
SA
UAC SBC (test.com)
192.168.1.1
INVITE sip:1234@test.com
100 Trying
INVITE
ACK
INVITE
ACK
This functionality is useful when large numbers of SRV records will be returned in a DNS query thereby eliciting a
large-sized DNS response. This behavior should be configured on the realm where the DNS servers are located.
To extend the valid DNS response size, add the dns-max-response-size option to the realm configuration. If this
option is not configured, the Oracle Communications Session Border Controller uses the default maximum response
size of 512 bytes, and information past the 512th byte will be ignored.
Do not add the dns-max-response-size option to realms where DNS queries are not being performed. Ensure that the
realm where this option is configured is referenced in a transport realm's dns-realm parameter. Only the local value
of the dns-max-response-size option is used for the realm; there is no inheritance of this value.
selection: 1
ORACLE(realm-config)#
3. Add the dns-max-response-size option to the realm with a value between 513 — 65535.
ORACLE(realm-config)#options dns-max-response-size=4196
4. Type done to save your configuration.
INVITE
INVITE
488
ACK
INVITE
480
ACK
488
ACK
488
ACK
SIP recursion policy can also terminate recursion based on identifying one or more specific 3xx, 4xx, or 5xx response
messages received from all targets in response to the request. The Oracle Communications Session Border Controller
can consider the number of responses per response code that were received before terminating recursion.
In absolute mode, the Oracle Communications Session Border Controller stops recursing after the total configured
number of responses (sip-response-code > attempts) for a configured sip-response-code subelement has been
received. When the number of attempts per response code is received, recursion stops and the final response is
forwarded to the requestor. Considering the previous call flow, in the following configuration example, after the
Oracle Communications Session Border Controller receives the 2nd 488 response from among all targets, it
terminates recursion and forwards the last 488 to the requester:
sip-response-code
response-code 488
attempts 2
Consecutive mode sets the Oracle Communications Session Border Controller to stop recursing after the total
configured number of responses (sip-response-code > attempts) for a configured sip-response-code subelement has
been received consecutively. When the number of attempts per response code is received, recursion stops and the final
response is forwarded to the requestor. Considering the previous example's configuration set to consecutive mode, the
Oracle Communications Session Border Controller will need to receive two 488 responses in a row before recursion
terminates and the last 488 is forwarded back to the requester.
Final Configuration
In order to use a sip-recursion-policy, it must be configured within a session agent or session agent group. Populate a
session-agent-group > sip-recursion-policy or session-agent > sip-recursion-policy parameter with the name of
the SIP recursion policy you wish to apply.
Feature Interactions
The existing SIP Configurable Route Recursion feature takes higher precedence than this feature. If the stop-recurse
parameter is configured in the SIP interface, session agent, or SAG, the Oracle Communications Session Border
Controller checks each response against that list, before any SIP recursion policy.
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.
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 Communications Session Border Controller 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 Communications Session Border Controller add the OPT
pseudo-RR to the ENUM query—without which the ENUM server will truncate the response.
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
• 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.
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.
ENUM Configuration
This section shows you how to configure ENUM on your Oracle Communications Session Border Controller.
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 Communications Session Border Controller 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:
ORACLE(enum-config)# service-type E2U+sip,sip+E2U,E2U+voicemsg
9. query-method—Set the strategy the Oracle Communications Session Border Controller 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 Communications Session Border Controller 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 Communications Session Border Controller 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.
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 Communications Session Border
Controller 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 Communications Session Border
Controller 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 enumconfig
top-level-domain
realm-id public
enum-servers 10.10.10.10:3456
10.10.10.11
service-type E2U+sip,sip+E2U
query-method hunt
timeout 11
cacheInactivityTimer 3600
max-response-size 512
health-query-number +17813245678
health-query-interval 0
failover-to enumconfig2
cache-addl-records enabled
include-source-info disabled
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.
The Oracle Communications Session Border Controller 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 Communications Session Border Controller uses local policy attributes to
determine if a local route table lookup is required. If a lookup is needed, the Oracle Communications Session Border
Controller 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.
• Actual performance that affects the interaction among the three performance attributes varies with system memory
and configuration.
IWF Considerations
When the system performs a local policy lookup for an incoming SIP or H.323 call and determines an ENUM/LRT
server is the next hop, it queries that ENUM/LRT server. The response will include the URI scheme, indicating the
next hop protocol and the hostname/IP address representing the next hop. For cases where the incoming call signaling
protocol and the URI scheme of the ENUM/LRT response are the same, the call requires no interworking. The Oracle
Communications Session Border Controller can simply route the egress call leg to the specified next hop.
Interworking is required when the incoming signaling protocol and the URI scheme of the ENUM/LRT response do
not match. When the responses do not match, the Oracle Communications Session Border Controller interworks
between SIP and H.323 to route the call to the appropriate next hop.
The Oracle Communications Session Border Controller also compares the URI scheme returned in the ENUM/LRT
response to the application protocol specified in the policy attributes. If the URI scheme is SIP, but the policy
attributes indicate H.323, the route is deemed invalid. The same is true for an H.323 URI scheme and SIP route.
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>
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.
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.
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 Communications
Session Border Controller 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 Communications Session Border Controller routes requests and the original Request-URI was not
the Oracle Communications Session Border Controller 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 Communications Session Border Controller re-targets or routes a request depends on the
following:
• The target (Request-URI) of the received request
• The presence of Route headers
• Local Policy Attributes,
• Registration Cache matching.
If the original target is the Oracle Communications Session Border Controller 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 Communications Session Border Controller 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.
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 Communications Session Border Controller 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 Communications Session Border Controller 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.
Network Applications
The following are typical applications of multistage routing:
• An operator might need to query an ENUM server for a destination number. Based on the NAPTR result of the
ENUM query, the Oracle Communications Session Border Controller 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.
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 Communications Session Border Controller will try the other next hops
until a route succeeds or all next-hops have been exhausted
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.
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 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
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 Communications Session Border Controller 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.
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 Communications Session Border Controller 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 Communications Session Border Controller 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 Communications
Session Border Controller with only audio codecs, the Oracle Communications Session Border Controller
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
Communications Session Border Controller 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:
• 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
Communications Session Border Controller 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)
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 private
allow-codecs g723:no pcmu video:no
order-codecs pcmu
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:
• Average QoS RFactor (0-93)
• Maximum QoS RFactor (0-93)
• Current QoS Major Exceeded
• Total QoS Major Exceeded
• Current QoS Critical Exceeded
• Total QoS Critical Exceeded
The following table shows you which parameters to apply a session translation ID in order to affect the corresponding
leg of the call as shown in the illustration.
A IN Translation ID IN Translation ID
B OUT Translation ID OUT Translation ID
Translation Rules
The translation rules subelement is where the actual translation rules are created. The fields within this element
specify the type of translation to be performed, the addition or deletion to be made, and where in the address that
change takes place. Translations are not applied to any realm or session agent in this element.
When creating translation rules, first determine the type of translation to perform. The following table lists and
describes the three types of number translations.
add This translation type adds a character or string of characters to the address.
delete This translation type deletes a character or string of characters from the address.
replace This translation type replaces a character or string of characters within the
address. Replace works by first applying the delete parameter then by applying
the add parameter.
After you set the translation type, you define the string to add or delete. The wildcard term for a string to delete is the
at-sign, @. Finally, you specify the character position in the address to make the addition or deletion.
The character position where an add or delete occurs is called an index. The index starts at 0 (immediately before the
leftmost character) and increases by 1 for every position to the right you move. In order to specify the final position in
an address, use the dollar-sign, $.
To create a translation rule that deletes a string:
Session Translation
A session translation defines how translation rules are applied to calling and called numbers. Multiple translation
rules can be referenced and applied using this element, which groups rules together and allows them to be referenced
by one identifier.
There are two parameters in the session translation element. The rules calling parameter lists the translation rules to
be applied to the calling number. The rules called parameter lists of translation rules to be applied to the called
number.
The Oracle Communications Session Border Controller applies the translation rules in the order in which they are
entered. They are applied cumulatively. For example, if this field is configured with a value of rule1 rule2 rule3, rule1
will be applied to the original number first, rule2 second, and rule3 last.
To configure the session translation element:
1. Enter a descriptive name for this session translation in the ID field.
2. Enter the IDs of existing translation rules in the rules calling parameter. Multiple rules can be entered in this field.
The order you enter them in is the order in which they are applied.
3. Enter the IDs of existing translation rules in the rules called parameter. Multiple rules can be entered in this field.
The order you enter them in is the order in which they are applied.
Session Agent
To configure number translation for a session agent:
In the session agent element, set the in translation ID and/or the out translation ID to the appropriate ID you
configured in the session translation element. There can be only one entry in each of these fields.
Realm
To configure number translation for a realm:
In the realm configuration element, set the in translation ID and/or the out translation ID to the appropriate ID you
configured in the session translation element. There can be only one entry in each of these fields.
Translation Rules
Set the following parameters to configure a translation rule:
1. ID—Set a descriptive ID name for this translation rule.
2. type—Set the type of translation rule you want to configure. The default value is none. The valid values are:
• add—Adds a character or string of characters to the address
• delete—Deletes a character or string of characters from the address
• replace—Replaces a character or string of characters within the address
• none—Translation rule is disabled
3. add-string—Enter the string to be added during address translation to the original address. The value in this
field should always be a real value; i.e., this field should not be populated with at-signs (@) or dollar-signs ($).
The default value is a blank string.
4. add-index—Enter the position, 0 being the left most position, where you want to add the string defined in the
add-string parameter. The default value is zero (0). The valid range is:
• Minimum—0
• Maximum—999999999
5. delete-string—Enter the string to be deleted from the original address during address translation.
Unspecified characters are denoted by the at-sign symbol (@).
The @ character only works if the type parameter is set to delete. This parameter supports wildcard characters or
digits only. For example, valid entries are: delete-string=@@@@@, or delete-string=123456. An invalid entry is
delete-string=123@@@. When the type is set to replace, this value is used in conjunction with the add-string
value. The value specified in the delete-string field is deleted and the value specified in the add-string field is
inserted. If no value is specified in the delete-string parameter and the type field is set to replace, then nothing will
be inserted into the address. The default value is a blank string.
6. delete-index—Enter the position, 0 being the left most spot, where you want to delete the string defined in
the delete-string parameter. This parameter is only used if the delete-string parameter is set to one or
more at-signs. The default value is zero (0). The valid range is:
• Minimum—0
• Maximum—999999999
Session Translation
To configure session translations:
1. Exit out of the translation rules element and enter the session translation element.
ORACLE(translation-rules)# exit
ORACLE(session-router)# session-translation
ORACLE(session-translation)#
From this point, you can configure the session translation element. To view all session translation parameters,
enter a ? at the system prompt. The following is an example of what a session translation configuration might look
like:
session-translation
id lrules-out
rules-calling rule1 rule2 rule3
rules-called addplus1
2. ID—Set a descriptive ID name for this session translation.
3. rules-calling—Enter the rules calling in the order in which they should be applied. Multiple rules should be
included in quotes and separated by spaces.
ORACLE(session-translation)# rules-calling "rule1 rule2 rule3"
4. rules-called—Enter the rules called in the order in which they should be applied. Multiple rules should be
included in quotes and separated by spaces.
Other Translations
FQDN Mapping
The Oracle Communications Session Border Controller maps FQDNs that appear in certain headers of incoming SIP
messages to the IPv4 address that the Oracle Communications Session Border Controller inserts in outgoing SIP
contact headers. The mapped FQDNs are restored in the SIP headers in messages that are sent back to the originator.
This feature is useful to carriers that use IPv4 addresses in the SIP From address to create trunk groups in a PSX for
routing purposes. When the carrier’s peer uses FQDNs, the carrier is forced to create trunk groups for each possible
FQDN that it might receive from a given peer. Similarly, this can apply to SIP Contact and P-asserted-identity
headers.
To accomplish this task, the system checks the media profile values and reserves the bandwidth required for flows. If
the required bandwidth for the new flow exceeds the available bandwidth at the time of the request, the Oracle
Communications Session Border Controller rejects the session.
With these mechanisms, the Oracle Communications Session Border Controller provides bandwidth-based admission
control.
In DSL access networks, ATM network bandwidth is typically oversubscribed at rates up to 400/1. At Level 3
(above), hundreds of users virtual circuits (VCs) are aggregated to a smaller set of virtual paths (VPs) at each
DSLAM. At Level 2, many virtual paths are aggregated at the first ATM switch. Finally, at Level 1, all traffic from all
subscribers in the access network is aggregated at the BRAS. Each level of aggregation is oversubscribed, creating the
need to perform admission control at each level.
From a Oracle Communications Session Border Controller perspective, multiple tiers of realms are supported, each
with its unique bandwidth policy. Only the lowest order realm (Level 3) requires an address prefix (that assigned to
the DSLAM) that must be used by the Oracle Communications Session Border Controller to determine in which
realm a user resides. When a call request to or from a particular user is received, the Oracle Communications Session
Border Controller checks each realm in the path to determine whether sufficient bandwidth is available to place the
call.
With this feature addition, you can now enable your Oracle Communications Session Border Controller to handle
non-AVT media types like image and text, and use application and data type for policing purposes. Bandwidth CAC
support has also been added for non-AVT media types, as has support for the application specific (AS) bandwidth
modifier (b=AS:<value>) in the SDP with specification of a defined amount of headroom for that value.
If the fallback amount is less than the max-bandwidth value, the Oracle Communications Session Border
Controller might start to reject calls. It does so until enough calls are released to free adequate bandwidth to stay
under the fallback limit and still accept calls.
8. Save and activate your configuration.
8. max-burst-rate—Enter a number to set how many SIP session invitations or H.323 SETUPs this session
agent can send or receive (per second) within the configured burst rate window value. The default value is zero
(0). The valid range is:
• Minimum—0
• Maximum—4294967295
For the sustained rate, the Oracle Communications Session Border Controller 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 50 here and a value of 60 (seconds) for the burst rate window constraint,
no more than 300 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 300 are rejected.
9. max-inbound-burst-rate—Enter the maximum burst rate (number of session invitations per second) for
inbound sessions from this session agent. The default value is zero (0). The valid range is:
• Minimum—0
• Maximum—999999999
10. max-outbound-burst-rate—Enter the maximum burst rate (number of session invitations per second) for
outbound sessions to this session agent.The default value is zero (0). The valid range is:
• Minimum—0
• Maximum—999999999
11. max-sustain-rate—Enter a number to set the maximum rate of session invitations (per second) this session
agent can send or receive within the current window. The default value is zero (0). The valid range is:
• Minimum—zero (0)
• Maximum—4294967295
The number you enter here must be larger than the number you enter for max-burst-rate.
For the sustained rate, the Oracle Communications Session Border Controller 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 50 here and a value of 36 (seconds) for the sustain rate window constraint,
no more than 1800 session invitations can arrive at or leave from the session agent in any given 36 second time
frame (window). Within that 36 second window, sessions over the 1800 limit are rejected.
12. max-inbound-sustain-rate—Enter the maximum sustain rate (of session invitations allowed within the
current window) of inbound sessions from this session agent. This value should be larger than the max-
inbound-burst-rate value. The default value is zero (0). The valid range is:
• Minimum—0
• Maximum—999999999
13. max-outbound-sustain-rate—Enter the maximum sustain rate (of session invitations allowed within the
current window) of outbound sessions to this session agent. This value should be larger than the max-
outbound-burst-rate value. The default value is zero (0). The valid range is:
• Minimum—0
• Maximum—999999999
14. burst-rate-window—Enter a number to set the 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. The default value
is zero (0). The valid range is:
• Minimum—0
• Maximum—4294967295
15. sustain-rate-window—Enter a number to set the sustained window period (in seconds) that is used to
measure the sustained rate. The default value is zero (0), which disables the functionality. The valid range is:
• Minimum—10
• Maximum—4294967295
The value you set here must be higher than or equal to the value you set for the burst rate window.
Note: If you are going to use this parameter, you must set it to a minimum value of 10.
The following example shows session agent constraints that are enabled and the session capacity parameters have
been configured. Other session agent parameters have been omitted for brevity.
session-agent
constraints enabled
max-sessions 355
max-inbound-sessions 355
max-outbound-sessions 355
The following example shows session agent constraints are enabled and the session rate parameters have been
configured. Other session agent parameters have been omitted for brevity.
When you configure minimum reserved bandwidth for session agent to a non-zero value, the Oracle Communications
Session Border Controller allocates a separate pipe for per session agent. This is achieved by setting up an access
control configuration in a specific way, instructing the Oracle Communications Session Border Controller to use a
minimum number of transmission timeslots the individual pipe is guaranteed to receive.
This feature works across both signaling services: SIP and H.323. No more than 4000 session pipes are supported.
9. max-burst-rate—Enter the maximum burst rate (invites per second) allowed for this constraint. This value
should be the sum of the max-inbound-burst-rate and the max-outbound-burst-rate. The default
value is zero (0). The valid range is:
• Minimum—0
• Maximum—999999999
10. max-sustain-rate—Enter the maximum rate of session invitations per second allowed within the current
window for this constraint. The default value is zero (0). The valid range is:
• Minimum—0
• Maximum—999999999
For the sustained rate, the Oracle Communications Session Border Controller 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.
11. max-inbound-burst-rate——Enter the maximum inbound burst rate (number of session invitations per
second) for this constraint. The default value is zero (0). The valid range is:
• Minimum—0
• Maximum—999999999
12. max-inbound-sustain-rate—Enter the maximum inbound sustain rate (of session invitations allowed
within the current window) for this constraint. The default value is zero (0). The valid range is:
• Minimum—0
• Maximum—999999999
For the sustained rate, the Oracle Communications Session Border Controller 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.
13. max-outbound-burst-rate——Enter the maximum outbound burst rate (number of session invitations per
second) for this constraint. The default value is zero (0). The valid range is:
• Minimum—0
• Maximum—999999999
14. max-outbound-sustain-rate—Enter the maximum outbound sustain rate (of session invitations allowed
within the current window) for this constraint. The default value is zero (0). The valid range is:
• Minimum—0
• Maximum—999999999
For the sustained rate, the Oracle Communications Session Border Controller 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.
15. time-to-resume—Enter the number of seconds after which the SA (Session Agent) is put back in service
(after the SA is taken OOS (Out Of Service) because it exceeded some constraint). The default value is zero (0).
The valid range is:
• Minimum—0
• Maximum—999999999
16. ttr-no-response—Enter the time delay in seconds to wait before the SA (Session Agent) is put back in
service (after the SA is taken OOS (Out Of Service) because it did not respond to the Oracle Communications
Session Border Controller). The default value is zero (0). The valid range is:
• Minimum—0
• Maximum—999999999
17. in-service-period—Enter the time in seconds that elapses before an element (like a session agent) can
return to active service after being placed in the standby state. The default value is zero (0). The valid range is:
• Minimum—0
• Maximum—999999999
18. burst-rate-window—Enter the time in seconds that you want to use to measure the burst rate; the window is
the time over which the burst rate is calculated, and is used for the over all burst rate as well as the inbound and
outbound burst rates. The default value is zero (0). The valid range is:
• Minimum—0
• Maximum—999999999
19. sustain-rate-window—Enter the time in seconds used to measure the sustained rate; the window is the
time over which the sustained rate is calculated, and is used for the over all sustained rate as well as the inbound
and outbound sustained rates. The default value is zero (0). The valid range is:
• Minimum—0
• Maximum—999999999
• If the amount of required bandwidth is not specified in the media profile (req-bandwidth) for the media type
in the m= line of the SDP, then the value specified in the AS modifier is used. The Oracle Communications
Session Border Controller only uses the AS value if you set the new sdp-bandwidth to enabled.
• If the average rate limit value for RTP flows is not specified in the media profile (average-rate-limit) for
the media type in the m= line of the SDP, then the value specified in the AS modifier is used. The system only
uses the AS value if you set the new sdp-bandwidth to enabled. When calculating the average rate rate limit
that it will use based on the AS modifier, the Oracle Communications Session Border Controller applies the
percentage set in the sdp-rate-limit-headroom parameter.
• The Oracle Communications Session Border Controller uses the value specified in the AS modifier (if sdp-
bandwidth is enabled, and req-bandwidth is set to 0) along with the user-cac-bandwidth value set in
the realm configuration; this works the same way that the req-bandwidth parameter does.
• The system uses the value specified in the AS modifier (if sdp-bandwidth is enabled, and req-bandwidth
is set to 0) along with the max-bandwidth value set in the realm configuration; this works the same way that
the req-bandwidth parameter does.
You can, however, enable the system to enforce CAC limits only once for SIP forked calls as long as the calls are
identified as such, meaning that they will use the same bandwidth resources. The Oracle Communications Session
Border Controller counts the forked call’s most bandwidth-hungry codec at the time it arrives at the Oracle
Communications Session Border Controller. In the above diagram, with shared bandwidth for forked calls enabled,
the Oracle Communications Session Border Controller counts 30 kbps against the realm’s total bandwidth after that
INVITE arrives, even after the first two INVITES have passed into the final realm.
• sip-interface
• session-agent
To apply a SIP profile to a SIP interface:
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-interface and press Enter.
ORACLE(session-router)# sip-interface
ORACLE(sip-interface)#
4. sip-profile—Enter the name of SIP profile configuration that includes the forked-cac-bandwidth parameter
configured.
5. Save your work.
Monitoring
Using the ACLI show sipd forked command, you can display the total number of forked sessions the Oracle
Communications Session Border Controller received and the total number it rejected. The Oracle Communications
Session Border Controller counts forked sessions when it receives a dialog-creating INVITE and is enabled to shared
bandwidth. Further, it counts as forked all session with the P-Multiring-Correlator header.
ORACLE# show sipd forked
11:19:20-116
Forked Sessions ---- Lifetime ----
Recent Total PerMax
Forked Sessions 0 0 0
Forked Sessions Rej 0 0 0
one side of the Oracle Communications Session Border Controller is only media-released when that INVITE is routed
back through the Oracle Communications Session Border Controller as a hairpin or other multi-system media release.
So there has to be enough bandwidth for the initial INVITE; otherwise, and even if the INVITE is a candidate for
media release, it will be rejected.
When there is a significant volume of such calls—ones that are candidates for media release, but cannot be admitted
because of CAC limits—it becomes important to admit them so long as they truly end in media release. This feature
thus allows admission of SIP calls that might otherwise be rejected because of bandwidth limitations when the far-end
of the call causes media to be released.
• mm-in-realm
• mm-in-network
• mm-same-ip
• mm-in-system
and the following parameter is set to enabled:
• msm-release
If the call, as received by the second system is not considered a candidate for release, the INVITE or UPDATE is
failed with a 503 Insufficient Bandwidth message.
After the INVITE has been processed by the Oracle Communications Session Border Controller, the Require: header
is removed upon egress from the system.
The following diagram shows the two-system scenario:
apSipSaCacBurstRateUtilLevel OBJECT-TYPE
SYNTAX Gauge32
UNITS "percentage"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Current burst rate utilization level."
::= { apSipSaCacStatsEntry 2 }
The MIB objects containing CAC utilization data for Realms are listed below.
The object establishing the statistics table for realm CAC utilization follows:
--apSig Realm Connection Admission Control Stats Table
apSigRealmCacStatsTable OBJECT-TYPE
SYNTAX SEQUENCE OF ApSigRealmCacStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Realm Connection Admission Control Stats Table."
::= { apSipMIBTabularObjects 6 }
The object establishing the realm CAC utilization statistics objects follows:
apSigRealmCacStatsEntry OBJECT-TYPE
SYNTAX ApSigRealmCacStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Connection Admission Control Statistics."
AUGMENTS { apSigRealmStatsEntry }
::= { apSigRealmCacStatsTable 1 }
The session agent CAC utilization statistics values include:
ApSigRealmCacStatsEntry ::= SEQUENCE {
apSigRealmCacSessionUtilLevel Gauge32,
apSigRealmCacBurstRateUtilLevel Gauge32
}
The above objects, specifying the CAC utilization value for sessions and burst rate utilization for realms include:
apSigRealmCacSessionUtilLevel OBJECT-TYPE
SYNTAX Gauge32
apSigRealmCacBurstRateUtilLevel OBJECT-TYPE
SYNTAX Gauge32
UNITS "percentage"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Current burst rate utilization level."
::= { apSigRealmCacStatsEntry 2 }
selection: 1
ORACLE(session-agent)#
3. cac-trap-threshold—Set the threshold when reached, expressed as a percentage of max-sessions, when the CAC
trap is sent.
4. Type done to save your configuration.
Overview
When a conversation is established between two endpoints, two flows are present in each direction:
• RTP flow carries traffic between endpoints with a predictable packet arrival rate. The packets headers have
sequence numbers that are used to determine whether packets are missing or lost.
• RTCP flow carries information about the RTP flow and keeps a different record. The RTCP packets contain
timestamps based on Network Time Protocol (NTP).
QoS Statistics
Reported QoS data includes the following per-flow statistics:
• RTP and RTCP lost packets—Count of lost packets for both RTP and RTCP based on comparing the sequence
numbers since the beginning of the call or the last context memory poll.
• RTP and RTCP average jitter—Incremental number of packets for both RTP and RTCP that have been used to
generate the total and max jitter since the beginning of the call or the last context memory poll. The incremental
accumulated jitter (in milliseconds) over all the packets received.
• RTP and RTCP maximum jitter—Maximum single jitter value (in milliseconds) for both RTP and RTCP from all
the packets since the beginning of the call or the last context memory poll.
• RTCP average latency—Number of RTCP frames over which latency statistics have been accumulated and the
incremental total of latency values reported since the beginning of the call or the last context memory poll.
• RTCP maximum latency—Highest latency value measured since the beginning of the call or the last context
memory poll.
• RTP packet count
• RTP bytes sent and received
• RTCP lost packets—RTP lost packets reported in RTCP packets.
• ATP lost packets—Lost packets determined by monitoring RTP sequence numbers.
• R-Factor and MOS data—R-Factor and MOS data for the calling and called segments at the end of a session
RADIUS Support
All the QoS statistics go into the RADIUS CDR. If a RADIUS client is configured on the Oracle Communications
Session Border Controller, any time a call occurs a record is generated and sent. Only Stop RADIUS records contain
the QoS statistic information.
Only RADIUS Stop records contain QoS information. For non-QoS calls, the attributes appear in the record, but their
values are always be zero (0). When you review the list of QoS VSAs, please note that “calling” in the attribute name
means the information is sent by the calling party and called in the attribute name means the information is sent by the
called party.
The following example shows a CDR that includes QoS data:
Wed Jun 13 18:26:42 2007
Acct-Status-Type = Stop
NAS-IP-Address = 127.0.0.100
NAS-Port = 5060
Acct-Session-Id = "SDgtu4401-c587a3aba59dcae68ec76cb5e2c6fe6f-v3000i1"
Acme-Session-Ingress-CallId =
"8EDDDC21D3EC4A218FF41982146844310xac1ec85d"
Acme-Session-Egress-CallId = "SDgtu4401-
c587a3aba59dcae68ec76cb5e2c6fe6f-v3000i1"
Acme-Session-Protocol-Type = "SIP"
Calling-Station-Id = ""9998776565" <sip:
9998776565@10.10.170.2:5060>;tag=2ed75b8317f"
Called-Station-Id = "<sip:7143221099@10.10.170.2:5060>"
Acct-Terminate-Cause = User-Request
Acct-Session-Time = 7
h323-setup-time = "18:24:36.966 UTC JUN 13 2007"
h323-connect-time = "18:24:37.483 UTC JUN 13 2007"
h323-disconnect-time = "18:24:44.818 UTC JUN 13 2007"
h323-disconnect-cause = "1"
Acme-Session-Egress-Realm = "peer"
Acme-Session-Ingress-Realm = "core"
Acme-FlowID_FS1_F = "localhost:65544"
Acme-FlowType_FS1_F = "PCMA"
Acme-Flow-In-Realm_FS1_F = "core"
Configuring QoS
This section explains how to configure QoS. To generate QoS metrics, you need to enable QoS for the realm of the
originating caller. The ingress realm determines whether QoS is turned on for a specific flow.
Note: If you run with QoS turned on one side only and disabled on the other you lose the ability to measure
latency through the use of RTCP timestamps.
QoS Configuration
To enable QoS:
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. The system prompt changes to let you know that you can begin
configuring individual parameters.
ORACLE(media-manager)# realm-config
ORACLE(realm-config)#
4. qos-enable—Enable this parameter. The default value is disabled.
key specifies information about the destination, which can be an IP address, an FQDN, a destination (called) number,
or destination prefix. You configure the classification key as part of the control rule.
Matching is performed from left to right, starting at the left-most character. A wildcard matches any digit.
The Oracle Communications Session Border Controller compares the following information from the SIP INVITE or
H.323 Setup for matching:
• SIP INVITE—User part of the Request URI, or the host part of the Request URI
• H.323 Setup—Q.931 Called Party Number IE
With Release 6.0, the Oracle Communications Session Border Controller now normalizes the user-part of the
Request-URI prior to performing any matching for NMC based on the dialed number. A departure from this feature’s
prior implementation, this normalization strips out any of the visual-separator characters.
Note that normalization occurs only for NMC look-up purposes, and it does not alter the actual Request-URI. For
previous releases, NMC rule matching based on the dialed number fails when the dialed number has visual separators
or additional parameters such as: rn, npdi, cic, postd, etc. If multiple rules match an incoming call, then the Oracle
Communications Session Border Controller gives first priority to destination number or the destination prefix. Next, it
tries to match based on the IP address, and finally it looks to the domain (lowest priority).
Specifically, the Oracle Communications Session Border Controller supports the following:
• The user-part can contain escaped sequences that the Oracle Communications Session Border Controller
normalizes to their unescaped representation. For examples %23(358)555.1234567 would be normalized to
#3585551234567.
• The Oracle Communications Session Border Controller parses the user-part of the Request-URI up to the first
semicolon (;). For example, the user-part in tel:+358-555-1234567;postd=pp22 will be +358-555-12134567.
• CPU constraints
The Oracle Communications Session Border Controller will not bypass licensing constraints, however.
Treatment Methods
You can choose from two different treatment methods:
• Call rejection—The Oracle Communications Session Border Controller rejects the call.
• For SIP, the Oracle Communications Session Border Controller sends a response messages with the status code
of the control rule. This response message also includes a Reason header with the Q.850 cause code that you
configure as part of the control rule; it contains only the Q.850 cause code, and there is no reason-text
included. For example:
Reason: Q.850; cause=63
• For H.323, the Oracle Communications Session Border Controller sends a releaseComplete message with the
Q.850 cause code (that you configure as part of the control rule) of the control rule as the Q.931 Cause IE.
• Call diversion—The Oracle Communications Session Border Controller routes the call to the location you specify
in the control rule’s next hop parameter.
Except for this routing, the call proceeds as normal. Local treatments such as number translation apply to the call,
as do local controls such as licensing. Note the following:
• If the next hop is an FQDN, the Oracle Communications Session Border Controller performs DNS queries to
resolve the next hop to an IP address so that it can route the call properly.
DNS queries only apply to pure SIP or IWF calls that originate in H.323 and are interworked to SIP.
• If the next hop is a session agent group, the Oracle Communications Session Border Controller selects a
session agent from the group according to the selection strategy you set for the group. Then the Oracle
Communications Session Border Controller uses the IP address of the selected session agent.
This parameter can accommodate a list of entries so that, if necessary, you can specify multiple classification keys.
You can edit the list of classification keys using the ACLI add-destination-identifier and remove-
destination-identifier commands from within the network management controls configuration.
7. type—Enter the control type that you want to use. The valid values are:
• GAP-RATE—Controls the maximum sustained rate of calls that match the classification key.
• GAP-PERCENT—Controls the percentage of calls matching the classification key you set for the control rule.
• PRIORITY—Exempts calls to a destination (like 911) from local network management controls. Use this
value if you want to enable Priority Call Exemption from Policy Server Approval.
8. value—When you set the control type to either GAP-RATE or GAP-PERCENT, enter the maximum sustained
rate of calls or the percentage of calls to which you want the control rule applied. The default value is zero (0).
The valid values are:
• GAP-RATE—Maximum is 2147483647 (which you can set by entering -1 as the value, an option provided for
ease of use)
• Using the minimum value (0) means that the Oracle Communications Session Border Controller treats all
calls
• Using the maximum value means that the Oracle Communications Session Border Controller treats no calls
• GAP-PERCENT—Maximum is 100
•Using the minimum value (0) means that the Oracle Communications Session Border Controller treats no
calls
• Using the maximum value (100%) means that the Oracle Communications Session Border Controller treats
all calls
9. treatment—Enter the treatment method that you want to use. The default value is none. The valid values are:
• reject—The Oracle Communications Session Border Controller rejects the call.
• divert—The Oracle Communications Session Border Controller routes the call to the location you specify
in the control rule’s next hop parameter.
10. next-hop—Enter the next hop for the Oracle Communications Session Border Controller to use when the
treatment method is DIVERT. The valid values are:
• hostname(:port)
• IP address(:port)
• Name of a valid, configured session agent
• Name of a valid, configured session agent group—When you set this parameter to a session agent group, you
must specify that it is a session agent group by prepending the name of the group with either SAG: or sag:. For
example, the entry for a session agent group with Group2 as its name would be SAG:Group2 or sag:Group2.
11. realm-next-hop—Enter the realm identifier to designate the realm of the next hop when the treatment type is
DIVERT.
12. protocol-next-hop—Enter the signaling protocol for the next hop when the treatment type is DIVERT.
13. status-code—Enter the SIP response code that you want the Oracle Communications Session Border
Controller to use when the treatment method is REJECT. The default value is 503 (Service Unavailable). The
valid range is:
• Minimum—1
• Maximum—699
14. cause-code—Enter the Q.850 cause code that you want the Oracle Communications Session Border Controller
to use when the treatment method is REJECT. The default value is 63 (Service or option not available). The valid
range is:
• Minimum—1
• Maximum—999999999
For a SIP call, the Oracle Communications Session Border Controller replaces the cause code in the Reason
header of the SIP response.
For a H.323 call, the Oracle Communications Session Border Controller converts the cause code to a Q.931
cause code in the Q.931 Cause IE in the releaseComplete message.
Account Configuration
You set the account configuration parameters to indicate where you want accounting messages sent, when accounting
messages you want them sent, and the strategy you want used to select account servers.
To configure the account configuration:
1. hostname—Enter a name for the host associated with the Oracle Communications Session Border Controller in
hostname (FQDN) format. The default value is the name of the local host.
The value you enter here must match the configured physical interface’s operation type control or
maintenance, to determine on which network to send RADIUS messages.
2. port—Enter the number of the UDP port associated with the Oracle Communications Session Border Controller
from which RADIUS messages are sent.The default value is 1813. The valid range is:
• Minimum—1025
• Maximum—65535
3. strategy—Indicate the strategy you want used to select the accounting servers to which the Oracle
Communications Session Border Controller will send its accounting messages. The default value is hunt. The
following table lists the available strategies:
• hunt—Selects accounting servers in the order in which they are listed.
If the first accounting server is online, working, and has not exceeded any of the defined constraints, all traffic
is sent to it. Otherwise the second accounting server is selected. If the first and second accounting servers are
offline or exceed any defined constraints, the third accounting server is selected. And so on through the entire
list of configured servers
• failover—Uses the first server in the list of predefined accounting servers until a failure is received from that
server. Once a failure is received, it moves to the second accounting server in the list until a failure is received.
And so on through the entire list of configured servers.
• roundrobin—Selects each accounting server in order, distributing the selection of each accounting server
evenly over time.
• fastestrtt—Selects the accounting server that has the fastest round trip time (RTT) observed during
transactions with the servers (sending a record and receiving an ACK).
• fewestpending—Selects the accounting server that has the fewest number of unacknowledged accounting
messages (that are in transit to the Oracle Communications Session Border Controller).
4. state—Enable this parameter if you want the account configuration active on the system. Disable it if you do not
want the account configuration active on the system. The default value is enabled. The valid values are:
• enabled | disabled
5. max-msg-delay—Indicate the length of time in seconds that you want the Oracle Communications Session
Border Controller to continue trying to send each accounting message. During this delay, the Oracle
Communications Session Border Controller can hold a generic queue of 4096 messages. The default value is 60.
• Minimum—zero (0)
• Maximum—4294967295
6. max-wait-failover—Indicate the maximum number of accounting messages the Oracle Communications Session
Border Controller can store its message waiting queue for a specific accounting server, before it is considered a
failover situation.
Once this value is exceeded, the Oracle Communications Session Border Controller attempts to send it accounting
messages, including its pending messages, to the next accounting server in its configured list. The default value is
100. The valid range is:
• Minimum—1
• Maximum—4096
7. trans-at-close—Disable this parameter if you do not want to defer the transmission of message information to the
close of a session. Enable it if you want to defer message transmission. The default value is disabled. The valid
values are:
• disabled—The Oracle Communications Session Border Controller transmits accounting information at the
start of a session (Start), during the session (Interim), and at the close of a session (Stop). The transmitted
accounting information for a single session might span a period of hours and be spread out among different
storage files.
• enabled—Limits the number of files on the Oracle Communications Session Border Controller used to store
the accounting message information for one session. It is easiest to store the accounting information from a
single session in a single storage file.
8. generate-start—Select the type of SIP event that triggers the Oracle Communications Session Border Controller
to transmit a RADIUS Start message. The default value is ok. The valid values are:
• start—RADIUS Start message should not be generated
• invite—RADIUS Start message should be generated once the Oracle Communications Session Border
Controller receives a SIP session INVITE.
• ok—RADIUS Start message is generated once the Oracle Communications Session Border Controller receives
an OK message in response to an INVITE.
9. generate-interim—Retain the default value reinvite-response to cause the Oracle Communications
Session Border Controller to transmit a RADIUS Interim message. (A RADIUS Interim message indicates to the
accounting server that the SIP session parameters have changed.)
To disable interim message generation, enter a pair of quotes as the value for this parameter. Otherwise, select one
or more than one of the following values:
• ok—RADIUS Interim message is generated when the Oracle Communications Session Border Controller
receives an OK message in response to an INVITE.
• reinvite—RADIUS Interim message is generated when the Oracle Communications Session Border Controller
receives a SIP session reINVITE message.
• reinvite-response—RADIUS Interim message is generated when the Oracle Communications Session Border
Controller receives a SIP session reINVITE and responds to it (for example, session connection or failure).
• reinvite-cancel—RADIUS Interim message is generated when the Oracle Communications Session Border
Controller receives a SIP session reINVITE, and the Reinvite is cancelled before the Oracle Communications
Session Border Controller responds to it.
10. account-server—Create the account server list to store accounting server information for the account
configuration. Each account server can hold 100 accounting messages.
Account server entries are specific to the account configuration. They cannot be viewed or accessed for editing
outside of the account configuration.
Note: RADIUS will not work if you do not enter one or more servers in a list.
Account Server
You must establish the list of servers to which the Oracle Communications Session Border Controller can send
accounting messages.
1. hostname—Name of the host associated with the account server as an IP address.
2. port—Enter the number of the UDP port associated with the account server to which RADIUS messages are
sent. The default value is 1813. The valid range is:
• Minimum—1025
• Maximum—65535
3. state—Enable or disable the account servers on the system. The default value is enabled. The valid values
are:
• enabled | disabled
4. min-round-trip—Indicate the minimum round trip time of an accounting message in milliseconds. The
default value is 250. The valid range is:
• Minimum—10
• Maximum—5000
A round trip consists of the following:
The system sends an accounting message to the account server.
The account server processes this message and responds back to the Oracle Communications Session Border
Controller.
If the fastest RTT is the strategy for the account configuration, the value you enter here can be used to
determine an order of preference (if all the configured account servers are responding in less than their
minimum RTT).
5. max-inactivity—Indicate the length of time in seconds that you want the Oracle Communications Session
Border Controller with pending accounting messages to wait when it has not received a valid response from the
target account server. The default value is 60. The valid range is:
• Minimum—1
• Maximum—300
Once this timer value is exceeded, the Oracle Communications Session Border Controller marks the
unresponsive account server as disabled in its failover scheme. When a server connection is marked as
inactive, the Oracle Communications Session Border Controller attempts to restart the connection and transfers
pending messages to another queue for transmission. RADIUS messages might be moved between different
account servers as servers become inactive or disabled.
6. restart-delay—Indicate the length of time in seconds you want the Oracle Communications Session Border
Controller to wait before resending messages to a disabled account server. The default value is 30. The valid
range is:
• Minimum—1
• Maximum—300
7. bundle-vsa—Retain the default enabled if you want the account server to bundle the VSAs within RADIUS
accounting messages. Enter disabled if you do not want the VSAs to be bundled. (Bundling means including
multiple VSAs within the vendor value portion of the message.) The valid values are:
• enabled | disabled
In a bundled accounting message, the RADIUS message type is vendor-specific, the length is determined for
each individual message, and the vendor portion begins with a 4-byte identifier, and includes multiple vendor
type, vendor length, and vendor value attributes.
8. secret—Enter the secret passed from the account server to the client in text format. Transactions between the
client and the RADIUS server are authenticated by the shared secret; which is determined by the source IPv4
address of the received packet.
9. NAS-ID—Enter the NAS ID in text format (FQDN allowed). The account server uses this value to identify the
Oracle Communications Session Border Controller for the transmittal of accounting messages.
The remote server to which the account configuration sends messages uses at least one of two potential
pieces of information for purposes of identification. The Oracle Communications Session Border Controller
accounting messages always includes in the first of these:
• Network Access Server (NAS) IP address (the IP address of the Oracle Communications Session Border
Controller’s SIP proxy)
• NAS ID (the second piece of information) provided by this value. If you enter a value here, the NAS ID is
sent to the remote server.
What is a Whitelist
A whitelist is an approved list of entities for which equipment provides particular privileges, access, and recognition.
The Oracle Communications Session Border Controller can use configured whitelist profiles to control and accept
specific inbound SIP headers and URI parameters that are being passed-through the Oracle Communications Session
Border Controller. When you configure this feature, the Oracle Communications Session Border Controller rejects
requests not matching the configured profile, or removes the unspecified headers or URI parameters not in the
configured profile.
Whitelists Configuration
You can configure whitelist profiles or rules that allow the Oracle Communications Session Border Controller to only
accept inbound SIP headers and URI parameters that are configured in this whitelist, using the parameter allowed-
elements-profile. You can configure the settings for this parameter using the ACLI interface at session-
router>enforcement-profile. Since the enforcement-profile object also pertains to session agents, realms, and
SIP interfaces, you can also apply the profiles you configure to these remote entities using the ACLI interface at
session-router>session-agent, session-router>sip-interface, and media-manager>realm-config.
In the following configuration example, it is assumed that your baseline configuration passes SIP traffic, with the
Oracle Communications Session Border Controller in the role of an Access SBC. Use this procedure to configure a
whitelist for the session router and optionally apply the specific whitelists to the session agent and SIP interface, as
well as the media manager’s realm configuration.
To configure a whitelist for the session router:
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 configurations.
ORACLE(configure)# session-router
3. Type allowed-elements-profile and press Enter to access the enforcement profile-related parameters.
ORACLE(session-router)# allowed-elements-profile
ORACLE(allowed-elements-profile)#
4. Type allowed-elements-profile and press Enter to access the whitelist-related parameters. The system
prompt changes to let you know that you can begin configuring individual parameters for this object.
ORACLE(enforcement-profile)# allowed-elements-profile
ORACLE(allowed-elements-profile)#
5. name — Enter a unique name for the whitelist you are creating. This name can be referenced when configuring
the enforcement-profiles for session-agent, SIP interface, and realm-config.
ORACLE(allowed-elements-profile)# name whitelist1
6. description — Enter a description that explains the purpose of creating this whitelist. You can use any
alpha-numeric characters when entering the description.
ORACLE(allowed-elements-profile)# description Basic Whitelist
7. Type rule-sets and press Enter to specify the rules to match against specific incoming SIP headers and/or
URI parameters. The system prompt changes to let you know that you can begin configuring individual
parameters for this object.
ORACLE(allowed-elements-profile)# rule-sets
ORACLE(rule-sets)#
8. unmatched-action — Select the action for the Oracle Communications Session Border Controller to
perform when a header does not exist in an incoming message. The default value is reject. The valid values
are:
• reject — Rejects all incoming messages that do not contain a header.
• delete — Deletes all incoming message that do not contain a header.
Note: This parameter applies to non-matching header names only (not non-matching URI parameters).
• delete — Deletes all incoming messages that have header parameters that do not match the parameters
specified in this header-name.
Note: This parameter applies to non-matching header names only (not non-matching URI parameters).
Configuration Exception
There are specific instances in incoming Request-URI messages where the Oracle Communications Session Border
Controller ignores specific parameters and automatically adds header-rules.
In a Request-URI, all parameters are URI parameters, and URI headers are not allowed. If you define values for the
“allow-header-param”, “allow-uri-header-name”, and “allow-uri-param”, the Oracle Communications Session Border
Controller ignores these parameters in the Request-URI. Instead the Oracle Communications Session Border
Controller automatically adds header-rules for incoming “Via”, “From”, To”, “Call-ID”, and “CSeq” messages. These
are explicit header rules and cannot be deleted. Each header-rule in a Request-URI has parameters populated with the
value of *. If required, a user can change the header-rule parameter values with the values identified in the following
table.
To allow-header-param • tag
Whitelist Learning
You can build your whitelist configuration based on the learning capabilities of the Oracle Communications Session
Border Controller. When you enable the Oracle Communications Session Border Controller learning mode, it
acquires the knowledge of the allowable elements (headers and parameters) currently incoming to your network. The
Oracle Communications Session Border Controller collects the information about the headers received and the
parameters that exist within each header. The information continues to be gathered until you disable the learning
mode.
Once you disable the learning mode, the Oracle Communications Session Border Controller prompts you to enter a
name for the allowed-elements-profile. If the profile name you entered does not exist, the captured information is
written to the new allowed-elements-profile configuration. The administrator can then make changes to the
configuration as applicable, save the configuration, and apply it to a logical remote entity.
The new allowed-elements-profile does not contain any wildcard rules. The Oracle Communications Session Border
Controller cannot generate wildcard headers and parameters during the learning mode. The Methods object is
populated from the list of methods seen by the Oracle Communications Session Border Controller while learning.
Note: Oracle recommends running the learning mode during off-peak and/or light traffic times. This mode
can operate in conjunction with the execution of an allowed-elements-profile. The learning occurs just before
any configured allowed-elements-profile configuration.
Command Description
start <argument> <options> Starts whitelist learning on the Oracle Communications Session Border
Controller.
You must specify the argument learn-allowed-elements with this command
to start the learning operation.
Optionally, you can use method, msg-type, and params after the argument.
stop <argument> <identifier> Stops the whitelist learning on the Oracle Communications Session Border
Controller and writes the learned configuration to the editing configuration
on the Oracle Communications Session Border Controller where it is saved
and activated.
You must specify the argument learn-allowed-elements with this command
to stop the learning operation.
You must specify a unique identifier that identifies the allowed-elements-
profile name.
If you specify an identifier name that already exists as a profile, the ACLI
returns an error message and prompts you to enter a different name.
You can use these commands at the top level ACLI prompt as required on the Oracle Communications Session Border
Controller.
You use these commands with the argument, learn-allowed-elements to start/stop the whitelist learning feature. By
default, the learning mode creates a single rule-set under which all of the headers and their respective parameters are
stored.
For example:
In addition to the rejected messages being logged to the “matched.log” file, the rejected messages are also sent
through a burst counter that keeps track of the amount of messages rejected. You can enter the show sipd to display
the number of rejected messages. The counter is titled Rejected Message.
A static flow entry watches for traffic with specific criteria on a specified ingress realm; that traffic consists of the
following criteria:
• The packet enters the Oracle Communications Session Border Controller on the specified ingress realm.
• The packet contains matching source address, subnet, and port criteria, field 1.
• The packet contains matching destination address, subnet, and port criteria, field 2.
• The packet contains a matching transport protocol, field 3.
If the above conditions are met, then the Oracle Communications Session Border Controller does the following:
• The IPv4 traffic is forwarded out of the Oracle Communications Session Border Controller on the specified egress
realm.
• The configured source address, subnet, and port criteria are written to the exiting packet, field 4.
• The configured destination address, subnet, and port criteria are written to the exiting packet, field 5.
• The original transport protocol and its contents remain unchanged as the packet exits into the egress realm.
NAPT
The NAPT ALG functionality is the same as that found in commercially available enterprise and residential NAT
devices. The Oracle Communications Session Border Controller watches for packets entering a media interface that
match source and destination IP address criteria. Matching packets are then redirected out of the egress interface,
through a specified port range, toward a destination address.
TFTP
The TFTP ALG is implemented as an extension of the NAT ALG. It works slightly differently than traditional NAPT.
In a TFTP session, the first packet is sent from a source endpoint to port 69 on the TFTP server. The TFTP server
responds from another port. This port, from which the TFTP response originates, is used for the remainder of the
TFTP session.
To act as a TFTP ALG, the Oracle Communications Session Border Controller will latch on the first return packet
from the server to learn the server's port. The ingress-side destination port of the Oracle Communications Session
Border Controller is changed to reflect the new communications port for the TFTP session. This process takes place
without any user intervention.
1. Set the static flows’ incoming traffic-matching criteria. First set the ingress realm where you expect to receive
traffic that will be routed via a static flow. Second, set the traffic’s source IP address, source subnet, and source
port or port range criteria. Third, set the traffic’s destination IP address, destination subnet, and destination port
criteria. This is usually an external address on theOracle Communications Session Border Controller.
2. Set the criteria that describes how traffic should be translated on the egress side of the Oracle Communications
Session Border Controller. First set the egress realm where you want to send the traffic to be routed by this static
flow. Second, set the traffic’s source IP address, source subnet, and source port or port range criteria. This is
usually an external address on the Oracle Communications Session Border Controller. Third, set the traffic’s
destination IP address, destination subnet, and destination port criteria.
3. Set the protocol this static flow entry acts upon. This type of packet, as the payload of the IP packet, remains
untouched as traffic leaves the Oracle Communications Session Border Controller . Specifying a layer 4 protocol
here acts as another criteria to filter against for this static flow.
The combination of entries in the ingress realm, ingress source address, ingress destination address, and protocol
fields must be unique. For bidirectional traffic, you need to define a separate static flow in the opposite direction.
• initial-guard-timer—Initial flow guard timer for an ALG dynamic flow in seconds. The default is 0; no
limit.
• susbsq-guard-timer—Subsequent flow guard timer for an ALG dynamic flow in seconds. The default is 0;
no limit.
Finally, you can set the optional bandwidth policing parameter for static flows (with or without NAT ALG applied).
• average-rate-limit—Sustained rate limit in bytes per second for the static flow and any dynamic ALG
flows. The default is 0; no limit.
To configure static flow:
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 static-flow and press Enter. The system prompt changes to let you know that you can begin
configuring individual parameters.
ORACLE(media-manager)# static-flow
From this point, you can configure media policing parameters.
4. in-realm-id—Enter the ingress realm or interface source of packets to match for static flow translation. This
in-realm-id field value must correspond to a valid identifier field entry in a realm-config. This is a required
field. Entries in this field must follow the Name Format.
5. in-source—Enter the incoming source IP address and port of packets to match for static flow translation. IP
address of 0.0.0.0 matches any source address. Port 0 matches packets received on any port. The port value has no
impact on system operation if either ICMP or ALL is the selected protocol. This parameter takes the format:
in-source <ip-address>[:<port>]
The default value is 0.0.0.0. The valid port range is:
• Minimum—0
• Maximum—65535
6. in-destination—Enter the incoming destination IP address and port of packets to match for static-flow
translation. An IP address of 0.0.0.0 matches any source address. Port 0 matches packets received on any port. The
port value has no impact on system operation if either ICMP or ALL is the selected protocol. The in-source
parameter takes the format:
in-destination <ip-address>[:<port>]
The default value is 0.0.0.0. The valid port range is:
• Minimum—0
• Maximum—65535
7. out-realm-id—Enter the defined realm where traffic leaving this NAT ALG exits theOracle Communications
Session Border Controller .
8. out-source—Enter the egress IPv4 address. This is the IPv4 address of the network interface where traffic
subject to the NAT ALG you are defining leaves the Oracle Communications Session Border Controller . Do not
enter a port number for this parameter. The default value is 0.0.0.0.
9. out-destination—Enter the IPv4 address and port number of the server or other destination to which traffic
is directed. The default value is 0.0.0.0. The valid port range is:
• Minimum—0
• Maximum—65535
10. protocol—Enter the protocol this NAPT ALG acts upon. The default value is UDP. The valid values are:
• TCP | UDP | ICMP | ALL
11. alg-type—Enter the type of NAT ALG to use. The default value is none. The valid values are:
• none—No dynamic ALG functionality
• NAPT—Configure as NAPT ALG
• TFTP—Configure as TFTP ALG
12. start-port—Enter the beginning port number of the port range that the Oracle Communications Session
Border Controller allocates on the egress side for flows that this NAPT ALG redirects. The default value is 0. The
valid range is:
• Minimum—0, 1025
• Maximum—65535
13. end-port—Enter the ending port number of the port range that the Oracle Communications Session Border
Controller allocates on the egress side for flows that this NAPT ALG redirects. The default value is 0. The valid
range is:
• Minimum—0, 1025
• Maximum—65535
14. flow-time-limit—Enter the total time limit for a flow in seconds. A value of 0 means there is no limit. The
valid range is:
• Minimum—0
• Maximum—999999999
15. initial-guard-timer—Enter the initial guard timer value in seconds. A value of 0 means there is no limit.
The valid range is:
• Minimum—0
• Maximum—999999999
16. subsq-guard-timer—Enter the subsequent guard timer value in seconds. A value of 0 means there is no
limit. The valid range is:
• Minimum—0
• Maximum—999999999
17. average-rate-limit—Enter a maximum sustained rate limit in bytes per second. The default value is 0; no
limit. The valid range is:
• Minimum—0
• Maximum—125000000
The following example shows a static-flow configuration element configured for a NAPT ALG.
in-realm-id access
in-source 172.16.0.0/16
in-destination 172.16.1.16:23
out-realm-id backbone
out-source 192.168.24.16
out-destination 192.168.24.95:23
protocol TCP
alg-type NAPT
start-port 11000
end-port 11999
flow-time-limit 0
initial-guard-timer 60
subsq-guard-timer 60
average-rate-limit 0
The following lines present the example configuration for the access to core side.
static-flow
in-realm-id access
description
in-source 0.0.0.0
in-destination 10.1.215.63
out-realm-id core
out-source 10.2.214.63
out-destination 10.2.214.51
protocol ICMP
alg-type none
start-port 0
end-port 0
flow-time-limit 0
initial-guard-timer 60
subsq-guard-timer 60
average-rate-limit 0
The following lines present the example configuration for the core to access side.
static-flow
in-realm-id core
description
in-source 10.2.214.51
in-destination 10.2.214.63
out-realm-id access
out-source 10.1.215.63
out-destination 0.0.0.0
protocol ICMP
alg-type none
start-port 0
end-port 0
flow-time-limit 0
initial-guard-timer 60
subsq-guard-timer 60
average-rate-limit 0
Overview
To produce seamless switchovers from one Oracle Communications Session Border Controller to the other, the HA
node uses shared virtual MAC and virtual IP addresses for the media interfaces in a way that is similar to VRRP
(virtual router redundancy protocol). When there is a switchover, the standby Oracle Communications Session Border
Controller sends out a gratuitous ARP messages using the virtual MAC address, establishing that MAC on another
physical port within the Ethernet switch. To the upstream router, the MAC and IP are still alive, meaning that existing
sessions continue uninterrupted.
Within the HA node, the Oracle Communications Session Border Controller s advertise their current state and health
to one another in checkpointing messages; each system is apprised of the other’s status. Using Oracles HA protocol,
the Oracle Communications Session Border Controller s communicate with UDP messages sent out and received on
the rear interfaces.
The standby Oracle Communications Session Border Controller shares virtual MAC and IPv4 addresses for the media
interfaces (similar to VRRP) with the active Oracle Communications Session Border Controller . Sharing addresses
eliminates the possibility that the MAC and IPv4 address set on one Oracle Communications Session Border
Controller in an HA node will be a single point of failure. The standby Oracle Communications Session Border
Controller sends ARP requests using a utility IPv4 address and its hard-coded MAC addresses to obtain Layer 2
bindings.
The standby Oracle Communications Session Border Controller assumes the active role when:
• It has not received a checkpoint message from the active Oracle Communications Session Border Controller for a
certain period of time.
• It determines that the active Oracle Communications Session Border Controller ’s health score has decreased to an
unacceptable level.
• The active Oracle Communications Session Border Controller relinquishes the active role.
Health Score
HA Nodes use health scores to determine their active and standby status. Health scores are based on a 100-point
system. When a Oracle Communications Session Border Controller is functioning properly, its health score is 100.
Generally, the Oracle Communications Session Border Controller with the higher health score is active, and the
Oracle Communications Session Border Controller with the lower health score is standby. However, the fact that you
can configure health score thresholds builds some flexibility into using health scores to determine active and standby
roles. This could mean, for example, that the active Oracle Communications Session Border Controller might have a
health score lower than that of the standby Oracle Communications Session Border Controller , but a switchover will
not take place because the active Oracle Communications Session Border Controller ’s health score is still above the
threshold you configured.
Alarms are key in determining health score. Some alarms have specific health score value that are subtracted from the
Oracle Communications Session Border Controller ’s health score when they occur. When alarms are cleared, the
value is added back to the Oracle Communications Session Border Controller ’s health score.
You can look at a Oracle Communications Session Border Controller ’s health score using the ACLI show health
command.
Switchovers
A switchover occurs when the active Oracle Communications Session Border Controller stops being the active
system, and the standby system takes over that function. There are two kinds switchovers: automatic and manual.
Automatic Switchovers
Automatic switchovers are triggered without immediate intervention on your part. Oracle Communications Session
Border Controller s switch over automatically in the following circumstances:
• When the active Oracle Communications Session Border Controller ’s health score of drops below the threshold
you configure.
• When a time-out occurs, meaning that the active Oracle Communications Session Border Controller has not has
not sent checkpointing messages to the standby Oracle Communications Session Border Controller within the
allotted time.
The active Oracle Communications Session Border Controller might not send checkpointing messages for various
reasons such as link failure, communication loss, or advertisement loss. Even if the active Oracle Communications
Session Border Controller has a perfect health score, it will give up the active role if it does not send a checkpoint
message or otherwise advertise its status within the time-out window. Then the standby Oracle Communications
Session Border Controller takes over as the active system.
When an automatic switchover happens, the Oracle Communications Session Border Controller that has just become
active sends an ARP message to the switch. This message informs the switch to send future messages to its MAC
address. The Oracle Communications Session Border Controller that has just become standby ignores any messages
sent to it.
Manual Switchovers
You can trigger a manual switchover in the HA node by using the ACLI notify berpd force command. This
command forces the two Oracle Communications Session Border Controller s in the HA node to trade roles. The
active system becomes standby, and the standby becomes active.
In order to perform a successful manual switchover, the following conditions must be met.
• The Oracle Communications Session Border Controller from which you trigger the switchover must be in one of
the following states: active, standby, or becoming standby.
• A manual switchover to the active state is only allowed on a Oracle Communications Session Border Controller in
the standby or becoming standby state if it has achieved full media, signaling, and configuration synchronization.
• A manual switchover to the active state is only allowed on a Oracle Communications Session Border Controller in
the standby or becoming standby state if it has a health score above the value you configure for the threshold.
State Transitions
Oracle Communications Session Border Controller s can experience series of states as they become active or become
standby.
Note: Packet processing only occurs on an active Oracle Communications Session Border Controller .
State Description
HA Features
HA nodes support configuration checkpointing, which you are required to set up so that the configurations across the
HA node are synchronized. In addition, you can set up the following optional HA node features:
• Multiple rear interface support
• Gateway link failure detection and polling
Configuration Checkpointing
During configuration checkpointing, all configuration activity and changes on one Oracle Communications Session
Border Controller are automatically mirrored on the other. Checkpointed transactions include adding, deleting, or
modifying a configuration on the active Oracle Communications Session Border Controller . This means that you
only need to perform configuration tasks on the active Oracle Communications Session Border Controller because the
standby system will go through the checkpointing process and synchronize its configuration to reflect activity and
changes.
Because of the way configuration checkpointing works, the ACLI save-config and activate-config
commands can only be used on the active Oracle Communications Session Border Controller .
• When you use the ACLI save-config command on the active Oracle Communications Session Border
Controller , the standby Oracle Communications Session Border Controller learns of the action and updates its
own configuration. Then the standby Oracle Communications Session Border Controller saves the configuration
automatically.
• When you use the ACLI activate-config command on the active Oracle Communications Session Border
Controller , the standby Oracle Communications Session Border Controller learns of the action and activates its
own, updated configuration.
The ACLI acquire-config command is used to copy configuration information from one Oracle
Communications Session Border Controller to another.
Oracle recommends that you use NTP to synchronize your Oracle Communications Session Border Controllers, so
that they have a common stratum time source.
3. HA nodes use ports 1 and 2 as the HA interfaces. Set port 0 on the rear panel of the Oracle Communications
Session Border Controller chassis as the boot and management interface. You configure the rear interfaces during
the physical interface configuration.
4. For ACLI configuration, you need to know the target names of the Oracle Communications Session Border
Controllers making up the HA node. The target name of the system is reflected in the ACLI’s system prompt. For
example, in the ORACLE# system prompt, ORACLE is the target name.
You can also see and set the target name in the Oracle Communications Session Border Controller boot
parameters.
Note: The target name is case sensitive.
5. Devise virtual MAC addresses so that, if a switchover happens, existing sessions are not interrupted.
HA Node Connections
To use HA, you must establish Layer 2 and Layer 3 networks that interconnect two Oracle Communications Session
Border Controllers and support HA with the required physical network connections. The basic network set-up in the
following diagram shows an HA node deployment where each system is connected to its own Layer 2 switch. This
set-up provides a measure of added redundancy in the event that one of the switches fails.
Here, the active system is using the virtual MAC and IP addresses.
In the second diagram, the same network is shown with the HA node having experienced a switchover. The
previously standby Oracle Communications Session Border Controller has taken over the active role in the HA node
and is using the virtual IP and MAC addresses.
Note: Switches should never be in master-slave mode. If they are, HA will not work correctly.
The following are hardware set-up and location considerations for placing an HA Node:
• You must set up each Oracle Communications Session Border Controller according to the requirements and safety
precautions set out in the Oracle Communications System Hardware Installation Guide.
• Each Oracle Communications Session Border Controller’s media interfaces must be connected to the same
switches (or other network entities), as shown in the diagram above.
• The length of the shielded crossover 10/100 category 5 Ethernet cable that connects the Oracle Communications
Session Border Controllers from the rear interfaces must be able to reach from the configured rear interface on one
Oracle Communications Session Border Controller to the configured rear interface on the other.
HA nodes use Oraclerder element redundancy protocol for its tasks. This protocol uses a connection between the rear
interfaces of two Oracle Communications Session Border Controllers to checkpoint the following information: health,
state, media flow, signaling, and configuration.
We recommend that you use shielded category 5 (RJ45) crossover cables for all 10/100 Ethernet connections used for
HA.
You can set up either single or multiple rear interface support for your HA node. For single interface support, one
cable connects the two Oracle Communications Session Border Controllers; for multiple interface support, two cables
are used. However, the software configurations for each type of connection mode are different.
When you make these connections, do not use port 0 (wancom0) on the rear interface of the Oracle Communications
Session Border Controller chassis; that port should only be used for Oracle Communications Session Border
Controller management. Instead, use ports 1 and 2 (wancom1 and wancom2).
To cable Oracle Communications Session Border Controllers using single rear interface support:
1. Using a 10/100 category 5 crossover cable, insert one end into either port 1 (wancom1) or port 2 (wancom2) on
the rear interface of the first Oracle Communications Session Border Controller.
2. Insert the other end of the cable into port 1 or port 2 on the rear interface of the second Oracle Communications
Session Border Controller. We recommend that you use corresponding ports on the two systems. That is, use port
1 on both systems or use port 2 on both systems.
3. Perform software configuration for these interfaces as described in this chapter.
To cable Oracle Communications Session Border Controllers using multiple rear interface support:
4. Using a 10/100 category 5 crossover cable, insert one end into port 1 on the rear interface of the first Oracle
Communications Session Border Controller.
5. Insert the other end of that cable into port 1 on the rear interface of the second Oracle Communications Session
Border Controller to complete the first physical connection.
6. Using a second 10/100 category 5 cable, insert one end into port 2 on the rear interface of the first Oracle
Communications Session Border Controller.
7. Insert the other end of this second cable in port 2 on the rear interface of the second Oracle Communications
Session Border Controller to complete the second physical connection.
8. Perform software configuration for these interfaces as described in this chapter.
HA Node Connections
You can begin software configuration for your HA node after you have:
• Completed the steps for physical set-up and connection.
• Noted the target name of the Oracle Communications Session Border Controllers that make up the HA node.
• Configured the virtual MAC addresses that you need, according to the type of physical interface cards installed on
your Oracle Communications Session Border Controller.
Rear Interfaces
You can use port 1 (wancom1) or port 2 (wancom2) as interfaces to support HA. Do not use port 0 (wancom 0) as that
port is reserved for carrying management traffic.
Make sure that the physical connections you have made on the rear panel of your Oracle Communications Session
Border Controllers correspond to the configurations you enter for physical interfaces. You can connect Oracle
Communications Session Border Controllers through multiple rear interfaces. For multiple rear interface connectivity,
cable both port 1 and port 2 (wancom1 and wancom2) on one Oracle Communications Session Border Controller to
port1 and port 2 on the other Oracle Communications Session Border Controller in the HA node.
The Oracle Communications Session Border Controller’s HA function depends heavily on health scores to determine
the active and standby roles in an HA node. You can set the amount that will be subtracted from a Oracle
Communications Session Border Controller’s health score in the event that a management interface fails for any
reason. For example, a connection might become invalid or a cable might be removed inadvertently.
The following example shows how a configured physical interface will appear in the ACLI for an HA node:
phy-interface
name wancom1
operation-type Control
port 1
slot 0
virtual-mac
wancom-health-score 20
To establish rear interfaces for use in an HA node using the ACLI:
1. Access the physical interface menu.
2. name—Set a name for the interface using any combination of characters entered without spaces. For example:
wancom1.
3. operation-type—Set this parameter to Control.
4. slot—Set this parameter to 0.
5. port—Set this parameter to 1 or 2.
6. wancom-health-score—Enter the number value between 0 and 100. This value will be subtracted from the
Oracle Communications Session Border Controller’s health score in the event that a rear interface link fails. We
recommend that you change this value from its default (50), and set it to 20.
This value you set here is compared to the active and emergency health score thresholds you establish in the
Oracle Communications Session Border Controller HA node (redundancy) configuration.
7. For multiple rear interface support, configure the remaining, unused rear interfaces with the appropriate values.
The following example shows configuration for multiple rear interface support.
ORACLE(system)# phy-interface
ORACLE(phy-interface)# name wancom1
ORACLE(phy-interface)# operation-type control
ORACLE(phy-interface)# port 1
ORACLE(phy-interface)# wancom-health-score 20
ORACLE(phy-interface)# done
ORACLE(phy-interface)# name wancom2
ORACLE(phy-interface)# operation-type control
ORACLE(phy-interface)# port 2
ORACLE(phy-interface)# wancom-health-score 20
ORACLE(phy-interface)# done
HA Node Parameters
To establish a pair of Oracle Communications Session Border Controllers as an HA node, you need to configure basic
parameters that govern how the Oracle Communications Session Border Controllers:
• Transition on switchover
• Share media and call state information
• Checkpoint configuration data
The following example shows what an HA configuration might look like in the ACLI.
redundancy-config
state enabled
log-level WARNING
health-threshold 75
emergency-threshold 50
port 9090
advertisement-time 500
percent-drift 210
initial-time 1250
becoming-standby-time 45000
becoming-active-time 100
You need to configure the two Oracle Communications Session Border Controllers to be HA node peers. To enable
configuration checkpointing, you must to configure two peers in the ACLI, one for the primary and one for the
secondary Oracle Communications Session Border Controller. The HA node peers configuration also allows you to
configure destinations for where to send health and state information. Unless you create Oracle Communications
Session Border Controller peers and destinations configurations, HA will not work properly.
The following example shows what an HA configuration might look like in the ACLI.
peer
name netnetsd1
state enabled
If the standby Oracle Communications Session Border Controller has a health score below the emergency
threshold and the active Oracle Communications Session Border Controlleris unhealthy, the active Oracle
Communications Session Border Controller will not give up its active role.
8. advertisement-time—Enter the number of milliseconds to set how often Oracle Communications Session
Border Controllers in an HA node inform each other of their health scores.
We recommend you leave this parameter set to it’s default, 500. The valid range is:
• Minimum—50
• Maximum—999999999
9. percent-drift—Enter the percentage of the advertisement time that you want one member of the HA node to
wait before considering the other member to be out of service. For the standby Oracle Communications Session
Border Controller, this is the time it will wait before taking the active role in the HA node. The default value is
210. The valid range is:
• Minimum—100
• Maximum—65535
10. initial-time—Enter the number of milliseconds to set the longest amount of time the Oracle
Communications Session Border Controller will wait at boot time to change its state from initial to either
becoming active or becoming standby. The default value is 1250. The valid range is:
• Minimum—5
• Maximum—999999999
11. becoming-standby-time—Enter the number of milliseconds the Oracle Communications Session Border
Controller waits before becoming standby, allowing time for synchronization. If it is not fully synchronized within
this time, it will be declared out of service.
We recommend that you do not set this parameter below 45000. If a large configuration is being processed, we
recommend setting this parameter to 180000 to allow enough time for configuration checkpointing. The default
value is 45000. The valid range is:
• Minimum—5
• Maximum—999999999
12. becoming-active-time—Enter the number of milliseconds that the standby Oracle Communications
Session Border Controller takes to become active in the event that the active Oracle Communications Session
Border Controller fails or has an intolerably decreased health score. The default value is 100. The valid range is:
• Minimum—5
• Maximum—999999999
Note: You must change this field from unknown, its default. The valid values are:
• primary—Set this type if you want the Oracle Communications Session Border Controller to use the
primary utility address.
• secondary—Set this type if you want the Oracle Communications Session Border Controller to use the
secondary utility address.
• unknown—If you leave this parameter set to this default value, configuration checkpointing will not work.
Synchronizing Configurations
You can synchronize the Oracle Communications Session Border Controllers (SBC) in your High Availability (HA)
node in the following ways:
• Automatically — Set up configuration checkpointing within the HA node.
• Manually — Check whether or not configurations in the HA node are synchronized, and then copy configuration
data from one SBC to the other.
When you initially configure a new HA node, copy the configuration data manually from one SBC to the other. When
you complete the process, you can configure your HA node to automatically synchronize configurations.
Oracle recommends that you configure the HA node for configuration checkpointing because that is the most reliable
way to ensure that both systems have the same configuration.
Synchronize HA Peers
The process for synchronizing the peers in a High Availability (HA) node for the first time by way of the ACLI
includes the following steps.
1. Create a complete configuration on the active Oracle Communications Session Border Controller (SBC). Include
all HA node parameters and all rear interface configurations. Confirm that the rear interfaces are configured to
send and receive information across the HA node.
2. On the active SBC, save the configuration.
3. On the active SBC, reboot to run the new configuration.
Use the ACLI show health command to see that the active SBC booted without a peer. This changes after you
copy the configuration to the standby SBC and activate the configuration.
4. On the standby SBC, perform the ACLI acquire-config command to copy the configuration from the active
SBC. Use the acquire-config command with the IPv4 address of wancom 0 on the active SBC.
ACMEPACKET2# acquire-config 192.168.12.4
The IPv4 address of wancom 0 on the active SBC is the IPv4 address portion of the value displayed for the inet on
ethernet boot parameter. The following codeblock shows an example of the inet on ethernet value that the system
displays when you view the boot parameters:
inet on ethernet (e) : 192.168.12.4:ffff0000
5. When the copying process (acquire-config) is complete, reboot the standby SBC to activate the
configuration. The system boots and displays start-up information.
6. Confirm that the HA node synchronized the configurations by using the ACLI display-current-cfg-
version and display-running-cfg-version commands:
ORACLE# display-current-cfg-version
Current configuration version is 3
ORACLE# display-running-cfg-version
Running configuration version is 3
ORACLE# display-current-cfg-version
Current configuration version is 3
ORACLE# display-running-cfg-version
Running configuration version is 3
In the preceding example, all configuration versions—current and running—are the same number (3).
HA Configuration Checkpointing
You need to first set applicable network interface configuration parameters, and then establish applicable parameters
in the Oracle Communications Session Border Controller HA node (redundancy) configuration.
We recommend that you do not change the configuration checkpointing parameters in the redundancy configuration.
Using the defaults, this feature will function as designed.
Note: Remember to set the appropriate type parameter in the HA node redundancy peers configuration.
For the network interface, these parameters appear as they do in the following example when you use the ACLI. This
example has been shortened for the sake of brevity.
pri-utility-addr 169.254.1.1
sec-utility-addr 169.254.1.2
For the Oracle Communications Session Border Controller HA node (redundancy) configuration, these parameters
appear as they do in the following example when you use the ACLI. This example has been shortened for the sake of
brevity. You should not change these values without consultation from Oracle Technical Support or your Oracle
Systems Engineer.
8. cfg-port—Enter the port number for sending and receiving configuration checkpointing messages. Setting this
to zero (0) disables configuration checkpointing. The default value is 1987. The valid values are:
• Minimum—0, 1025
• Maximum—65535
9. cfg-max-trans—Enter the number of HA configuration checkpointing transactions that you want to store.
The active Oracle Communications Session Border Controller maintains the transaction list, which is acquired by
the standby Oracle Communications Session Border Controller. Then the standby system uses the list to
synchronize its configuration with active system. The default value is 10000. The valid range is:
• Minimum—0
• Maximum—4294967295
Transactions include: modifications, additions, and deletions. If the maximum number of stored transactions is
reached, the oldest transactions will be deleted as new transactions are added.
10. cfg-sync-start-time—Enter the number of milliseconds before the Oracle Communications Session
Border Controller tries to synchronize by using configuration checkpointing. On the active Oracle
Communications Session Border Controller, this timer is continually reset as the Oracle Communications Session
Border Controller checks to see that it is still in the active role. If it becomes standby, it waits this amount of time
before it tries to synchronize.
We recommend you leave this field at its default value, 5000, so that configuration checkpointing can function
correctly. The valid range is:
• Minimum—0
• Maximum—4294967295
11. cfg-sync-comp-time—Enter the number of milliseconds that the standby Oracle Communications Session
Border Controller waits before checkpointing to obtain configuration transaction information after the initial
checkpointing process is complete.
We recommend you leave this field at its default value, 1000, so that configuration checkpointing can function
correctly. The valid range is:
• Minimum—0
• Maximum—4294967295
12. Save your work and exit the redundancy configuration.
ORACLE(redundancy)# done
ORACLE(redundancy)# exit
ORACLE(system)#
time-out retry field is exceeded, this amount will be subtracted from the system’s overall health score. The default
value is 0. The valid range is:
• Minimum—0
• Maximum—100
Signaling Checkpointing
You can configure your HA node to checkpoint signaling for SIP.
Controller to obtain the latest SIP signaling information. The first interval occurs after initial synchronizations of
the systems.
We recommend that you leave this parameter set to its default, 1000. The valid range is:
• Minimum—0
• Maximum—999999999
When you enable the media interface keepalive, the standby system in the HA node sends ARP requests to determine
if the media interfaces’ virtual IP address are active. There are two possible outcomes:
• If it receives responses to its ARP requests, the standby takes itself out of service—to prevent a conflict with the
active.
• If it does not receive responses to its ARP requests within a timeout value you set, then standby assumes the active
role in the HA node.
RTC Notes
Starting in Release 4.1, the HA configuration is supported for real-time configuration (RTC). However, not all of the
HA-related parameters are covered by RTC because of the impact on service it would cause to reconfigure these
parameters dynamically.
This section sets out what parameters you should not dynamically reconfigure, or should dynamically reconfigure
with care.
HA
Changes to the following ACLI parameters will have the noted consequences when dynamically reconfigured:
• cfg-max-trans—Changing this value could cause the activation time to lengthen slightly
Parameter Impact
Security Overview
Oracle Communications Session Border Controller security includes the Net-SAFE framework’s numerous features
and architecture designs. Net-SAFE is a requirements framework for the components required to provide protection
for the Session Border Controller (SBC), the service provider’s infrastructure equipment (proxies, gateways, call
agents, application servers, and so on), and the service itself.
The following diagrams illustrate Net-SAFE:
• Topology hiding and privacy: complete infrastructure topology hiding at all protocol layers for confidentiality and
attack prevention security. Also, modification, removal or insertion of call signaling application headers and
fields. Includes support for the SIP Privacy RFC.
• VPN separation: support for Virtual Private Networks (VPNs) with full inter-VPN topology hiding and separation,
ability to create separate signaling and media-only VPNs, and with optional intra-VPN media hair-pinning to
monitor calls within a VPN.
• Service infrastructure DoS prevention: per-device signaling and media overload control, with deep packet
inspection and call rate control to prevent DoS attacks from reaching service infrastructure such as SIP servers,
softswitches, application servers, media servers or media gateways.
• Fraud prevention: session-based authentication, authorization, and contract enforcement for signaling and media;
and service theft protection.
• Monitoring and reporting: audit trails, event logs, access violation logs and traps, management access command
recording, Call Detail Records (CDRs) with media performance monitoring, raw packet capture ability and lawful
intercept capability. The monitoring method itself is also secured, through the use of SSH and SFTP, and through
the ability to use a separate physical Ethernet port for management access.
Trusted Path
Packets from trusted devices travel through the trusted pipe in their own individual queues. In the Trusted path, each
trusted device flow has its own individual queue (or pipe). The Oracle Communications Session Border Controller
can dynamically add device flows to the trusted list by promoting them from the Untrusted path based on behavior; or
they can be statically provisioned.
Trusted traffic is put into its own queue and defined as a device flow based on the following:
• source IP address
• source UDP/TCP port number
• destination IP address
• destination UDP/TCP port (SIP interface to which it is sending)
• realm it belongs to, which inherits the Ethernet interface and VLAN it came in on
For example, SIP packets coming from 10.1.2.3 with UDP port 1234 to the Oracle Communications Session Border
Controller SIP interface address 11.9.8.7 port 5060, on VLAN 3 of Ethernet interface 0:1, are in a separate Trusted
queue and policed independently from SIP packets coming from 10.1.2.3 with UDP port 3456 to the same Oracle
Communications Session Border Controller address, port and interface.
Data in this flow is policed according to the configured parameters for the specific device flow, if statically
provisioned. Alternatively, the realm to which endpoints belong have a default policing value that every device flow
will use. The defaults configured in the realm mean each device flow gets its own queue using the policing values. As
shown in the previous example, if both device flows are from the same realm and the realm is configured to have an
average rate limit of 10K bytes per second (10KBps), each device flow will have its own 10KBps queue. They are not
aggregated into a 10KBps queue.
The individual flow queues and policing lets the Oracle Communications Session Border Controller provide each
trusted device its own share of the signaling, separate the device’s traffic from other trusted and untrusted traffic, and
police its traffic so that it can’t attack or overload the Oracle Communications Session Border Controller (therefore it
is trusted, but not completely).
Untrusted Path
Packets (fragmented and unfragmented) that are not part of the trusted or denied list travel through the untrusted pipe.
In the untrusted path, traffic from each user/device goes into one of 2048 queues with other untrusted traffic. Packets
from a single device flow always use the same queue of the 2048 untrusted queues, and 1/2048th of the untrusted
population also uses that same queue. To prevent one untrusted endpoint from using all the pipe’s bandwidth, the
2048 flows defined within the path are scheduled in a fair-access method. As soon as the Oracle Communications
Session Border Controller decides the device flow is legitimate, it will promote it to its own trusted queue.
All 2048 untrusted queues have dynamic sizing ability, which allows one untrusted queue to grow in size, as long as
other untrusted queues are not being used proportionally as much. This dynamic queue sizing allows one queue to use
more than average when it is available. For example, in the case where one device flow represents a PBX or some
other larger volume device. If the overall amount of untrusted packets grows too large, the queue sizes rebalance, so
that a flood attack or DoS attack does not create excessive delay for other untrusted devices.
In the usual attack situations, the signaling processor detects the attack and dynamically demotes the device to denied
in the hardware by adding it to the deny ACL list. Even if the Oracle Communications Session Border Controller does
not detect an attack, the untrusted path gets serviced by the signaling processor in a fair access mechanism. An attack
by an untrusted device will only impact 1/1000th of the overall population of untrusted devices, in the worst case.
Even then there’s a probability of users in the same 1/1000th percentile getting in and getting promoted to trusted.
• Uses this new queue to prevent fragment packet loss when there is a flood from untrusted endpoints.
When you set up a queue for fragment packets, untrusted packets likewise have their own queue—meaning also that
the max-untrusted-signaling and min-untrusted-signaling values are applied to the untrusted
queue.
Traffic Promotion
Traffic is promoted from untrusted to trusted list when the following occurs:
• successful SIP registration for SIP endpoints
• successful session establishment for SIP calls
Blocking Actions
Blocking actions include the following:
• Dynamic deny entry added, which can be viewed through the ACLI.
• SNMP trap generated, identifying the malicious source
Dynamically added deny entries expire and are promoted back to untrusted after a configured default deny period
time. You can also manually clear a dynamically added entry from the denied list using the ACLI.
of endpoints behind a single NAT that have been labeled untrusted. It shuts off the NAT’s access when the number
reaches the limit you set.
The demoted NAT device then remains on the untrusted list for the length of the time you set in the deny-period.
Configuration Overview
Configuring Oracle Communications Session Border Controller DoS protection includes masking source IP and port
parameters to include more than one match and configuring guaranteed minimum bandwidth for trusted and untrusted
signaling path. You can also configure signaling path policing parameters for individual source addresses. Policing
parameters are defined as peak data rate (in bytes/sec), average data rate (in bytes/sec), and maximum burst size.
You can configure deny list rules based on the following:
• ingress realm
• source IP address
• source port
• transport protocol (TCP/UDP)
• application protocol (SIP or H.323)
Adding this ACL causes the Oracle Communications Session Border Controller to also add a permit trusted ACL with
a source prefix of 12.34.0.0/16 for each signaling interface/port of the access realm. This ACL is added because the
trust level of the ACL you just added is high and the realm’s trust level is set to low. The trust levels must match to
remove the global permit trusted ACL.
• Maximum—999999999
15. nat-trust-threshold—Enter the number of endpoints behind a NAT that must be denied for the Oracle
Communications Session Border Controller to demote the NAT device itself to denied (dynamic demotion of NAT
devices). The default is 0, meaning dynamic demotion of NAT devices is disabled. The range is from 0 to 65535.
The following example shows access control configured for a host in the external realm.
access-control
realm-id external
source-address 192.168.200.215
destination-address 192.168.10.2:5000
application-protocol SIP
transport-protocol ALL
access permit
average-rate-limit 3343
trust-level low
invalid-signal-threshold 5454
maximum-signal-threshold 0
untrusted-signal-threshold 0
deny-period 0
The following example of how to configure a black-list entry:
access-control
realm-id external
source-address 192.168.200.200
destination-address 192.168.10.2:5000
application-protocol SIP
transport-protocol ALL
access deny
average-rate-limit 0
trust-level none
invalid-signal-threshold 0
maximum-signal-threshold 0
untrusted-signal-threshold 0
deny-period 0
5. max-untrusted-signaling—Set the percentage of the maximum signaling bandwidth you want to make
available for messages coming from untrusted sources. This bandwidth is only available when not being used by
trusted sources. The default value is 100 The valid range is:
• Minimum—1
• Maximum—100
6. min-untrusted-signaling—Set the percentage of the maximum signaling bandwidth you want reserved
for the untrusted sources. The rest of the bandwidth is available for trusted resources, but can also be used for
untrusted sources (see max-untrusted-signaling). The default value is 30 The valid range is:
• Minimum—1
• Maximum—100
7. fragment-msg-bandwidth—Enter the amount of bandwidth to use for the fragment packet queue. If you
leave this parameter set to 0, then the Oracle Communications Session Border Controller will use the same queue
for and share bandwidth between untrusted packets and fragment packets. The default value is zero (0). The valid
range is:
• Minimum—0
• Maximum—10000000
8. tolerance-window—Set the size of the window used to measure host access limits. The value entered here is
used to measure the invalid message rate and maximum message rate for the realm configuration. The default
value is 30. The valid range is:
• Minimum—0
• Maximum—999999999
The following example shows a host access policing configuration.
media-manager
state enabled
latching enabled
flow-time-limit 86400
initial-guard-timer 300
subsq-guard-timer 300
tcp-flow-time-limit 86400
tcp-initial-guard-timer 300
tcp-subsq-guard-timer 300
tcp-number-of-ports-per-flow 2
hnt-rtcp disabled
algd-log-level WARNING
mbcd-log-level WARNING
home-realm-id
red-flow-port 1985
red-max-trans 10000
red-sync-start-time 5000
red-sync-comp-time 1000
max-signaling-bandwidth 1000000
max-untrusted-signaling 50
min-untrusted-signaling 30
tolerance-window 30
rtcp-rate-limit 0
• Minimum—0
• Maximum—4294967295
7. register-burst-window—Define the window size in seconds for the maximum number of allowable SIP
registrations. 0 is the minimum and default value for this parameter; the maximum value is 999999999.
8. max-register-burst-rate—Enter the maximum number of new registrations you want this session agent
to accept within the registration burst rate window. If this threshold is exceeded, the Oracle Communications
Session Border Controller will respond to new registration requests with 503 Service Unavailable messages. 0 is
the minimum and default value for this parameter; the maximum value is 999999999.
9. Save and activate your configuration.
selection: 1
ORACLE(realm-config)#
3. max-endpoints-per-nat— Set the maximum number of endpoints that can exist behind a NAT before
demoting the NAT device. Valid values are 0-65535, with 0 disabling this feature. This parameter is also found in
the access control configuration element.
Syslog Support
Set the syslog-on-demote-to-deny parameter in the media-manager-config to enabled to generate syslog on endpoint
demotion from untrusted to deny. NAT device demotion will also generate a unique syslog message with
accompanying text explaining that it is the NAT device demotion event.
Debugging
The show sip acl command now includes counts of Blocked NAT devices.
Media Policing
Media policing controls the throughput of individual media flows in the Oracle Communications Session Border
Controller, which in turn provides security and bandwidth management functionality. The media policing feature
works for SIP, H.323 and SIP-H.323 protocols. The media policing feature also lets you police static flows and RTCP
flows.
The term media policing refers to flows that go through the Oracle Communications Session Border Controller. Flows
that are directed to the host application are not affected by media policing.
You can use media policing to protect against two potential security threats that can be directed against your Oracle
Communications Session Border Controller:
• Media DoS—Once media flows are established through the Oracle Communications Session Border Controller,
network resources are open to RTP media flooding. You can eliminate the threat of a media DoS attack by
constraining media flows to absolute bandwidth thresholds.
• Bandwidth Piracy—Bandwidth policing ensures that sessions consume no more bandwidth than what is signaled
for.
Policing Methods
The Oracle Communications Session Border Controller polices real-time traffic by using Constant Bit Rate (CBR)
media policing. CBR policing is used when a media flow requires a static amount of bandwidth to be available during
its lifetime. CBR policing best supports real-time applications that have tightly constrained delay variation. For
example, voice and video streaming are prime candidates for CBR policing.
Configuration Notes
Review the following information before configuring your Oracle Communications Session Border Controller to
perform media policing.
Payload Type Encoding Name Audio (A) / Video (V) Clock Rate
0 PCMU A 8000
4 G723 A 8000
8 PCMA A 8000
9 G722 A 8000
15 G728 A 8000
18 G729 A 8000
If you configure any payload type to encoding name mappings, the default mappings will be ignored. You must then
manually enter all payload type mappings you use in the media-profile configuration element.
ITU-T IANA
g711Ulaw64k PCMU
g711Alaw64k PCMA
g726 G726
G7231 G723
g728 G728
g729wAnnexB G729
g729 G729 fmtp:18 annexb=no
H261VideoCapability H261
H263VideoCapability H263
t38Fax T38
SDP Anonymization
In order to provide an added measure of security, the Oracle Communications Session Border Controller’s topology-
hiding capabilities include SDP anonymization. Enabling this feature gives the Oracle Communications Session
Border Controller the ability to change or modify certain values in the SDP so that malicious parties will be unable to
learn information about your network topology.
To do this, the Oracle Communications Session Border Controller hides the product-specific information that can
appear in SDP o= lines and s= lines. This information can include usernames, session names, and version fields. To
resolve this issues, the Oracle Communications Session Border Controller makes the following changes when you
enable SDP anonymization:
• Sets the session name (or the s= line in the SDP) to s=-
• Sets the username in the origin field to -SBC
• Sets the session ID in the origin field to an integer of incrementing value
Note that for mid-call media changes, the session identifier is not incremented.
To enable this feature, you set a parameter in the media manager configuration.
About SYN
SYN is used by TCP when initiating a new connection to synchronize the sequence numbers on two connecting
computers. The SYN is acknowledged by a SYN-ACK by the responding computer. After the SYN-ACK, the client
finishes establishing the connection by responding with an ACK message. The connection between the client and the
server is then open, and the service-specific data can be exchanged between the client and the server.
A SYN flood is a series of SYN packets from forged IP addresses. The IP addresses are chosen randomly and do not
provide any hint of the attacker’s location. The SYN flood keeps the server's SYN queue full. Normally this would
force the server to drop connections. A server that uses SYN cookies, however, will continue operating normally. The
biggest effect of the SYN flood is to disable large windows.
Server Vulnerability
Vulnerability to attack occurs when the server has sent a SYN-ACK back to client, but has not yet received the ACK
message; which is considered a half-open connection. The server has a data structure describing all pending
connections built in its system memory. This data structure is of finite size, and it can be made to overflow by
intentionally creating too many partially-open connections.
The attacking system sends SYN messages to the server that appear to be legitimate, but in fact reference a client that
is unable to respond to the SYN-ACK messages. The final ACK message is never sent to the server.
The half-open connections data structure on the server fills and no new incoming connections are accepted until the
table is emptied out. Typically there is a timeout associated with a pending connection (the half-open connections will
eventually expire and the server will recover). But the attacking system can continue sending IP-spoofed packets
requesting new connections faster than the server can expire the pending connections. The server has difficulty in
accepting any new incoming network connections.
Supported Encryption
The Oracle Communications Session Border Controller provides support for TLSv1.2, TLSv1.1, TLSv1.0, and SSLv3
encryption.
Note: Oracle does not support RC4 ciphers.
TLSv1 Ciphers
The Oracle Communications Session Border Controller supports the TLS v1 cipher suites listed in this section.
For encryption, the Oracle Communications Session Border Controller supports: AES-128, AES-256, 3DES, DES
and ARC4 (40 and 128 bit) algorithms. It also supports:
• TLS_RSA_WITH_NULL_MD5
• TLS_RSA_WITH_NULL_SHA
• TLS_RSA_WITH_RC4_128_MD5
• TLS_RSA_WITH_RC4_128_SHA
• TLS_RSA_WITH_DES_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_RSA_WITH_DES_CBC_SHA
• TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
• TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
• ALL [default]
• NONE
SSL3 TLSv1
SSL_RSA_WITH_NULL_MD5 TLS_RSA_WITH_NULL_MD5
SSL_RSA_WITH_NULL_SHA TLS_RSA_WITH_NULL_SHA
SSL_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_DES_CBC_SHA TLS_RSA_WITH_DES_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA TLS_DHE_RSA_WITH_DES_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
Note: The Oracle Communications Session Border Controller supports TLS_RSA_WITH_NULL_MD5 and
TLS_RSA_WITH_NULL_SHA although neither does any encryption. These ciphers might be used for
debugging purposes, and should not be deployed.
In security-config, the sslmin option values can be: sslv3, tls1.0, tls1.1 or tls1.2. This change is platform-independent
and applies to all Oracle Communications Session Border Controller.
ORACLE(security-config)#
3. options— Set the options parameter by typing options, a space, a plus sign, the option name sslmin= and then
one of the valid values. Valid values are:
• sslv3
• tls1.0
• tls1.1
• tls1.2
ORACLE(security-config)#options +sslmin=sslv3
4. Type done to save your configuration.
Signaling Support
The Oracle Communications Session Border Controller ’s TLS functionality supports SIP and SIPS. In addition, the
Oracle Communications Session Border Controller can accommodate a mixture of TLS and non-TLS sessions within
a realm as because a request for TLS is controlled by the endpoint (TLS UA).
DoS Protection
The Oracle Communications Session Border Controller provides the following forms of DoS protection from:
• Too many simultaneous TLS connections being requested by a single IP address.
The Oracle Communications Session Border Controller limits the number of TLS connections from a single IP
address; you can set a maximum simultaneous number of TCP/TLS connections a SIP interface will allow from a
single IP address.
• Too many simultaneous TLS connections being requested by limiting the maximum number of connections for a
SIP interface.
In other words, the maximum simultaneous TCP/TLS connections a SIP interface will allow in aggregate from all
IP addresses served by that signaling interface.
• Endpoints establishing TCP/TLS connections that never send any messages (application layer messages; once the
TLS handshake completes).
This protection is triggered by inactivity, measured by lack of any message from a peer. The value specified for
this timer is in seconds.
• Endpoints requesting an initial registration that never send messages thereafter.
Note: It is expected that whenever an endpoint establishes a TCP/TLS connection, it will keep the
connection active by sending additional messages or by using the NAT interval configuration. Whenever a
connection is torn down because of inactivity, a log at the level "ERROR" is generated.
• Malformed packets by counting and limiting the maximum number of malformed packets.
Whenever the Oracle Communications Session Border Controller receives an invalid TLS message, it increments
the internal invalid signalling threshold counter. When that counter reaches the configured value, the Oracle
Communications Session Border Controller denies the endpoints for the configured deny period. This also
requires configuration of tolerance window in media manager.
Endpoint Authentication
The Oracle Communications Session Border Controller does not operate as a CA. Instead, the Oracle
Communications Session Border Controller ’s TLS implementation assumes that you are using one of the standard
CAs for generating certificates:
• Verisign
• Entrust
• Thawte
• free Linux-based CA (for example, openssl)
Note: Self-signed certificates are available only as an option for MSRP connections
The Oracle Communications Session Border Controller can generate a certificate request in PKCS10 format and to
export it. It can also import CA certificates and a Oracle Communications Session Border Controller certificate in the
PKCS7/X509 PEM format.
The Oracle Communications Session Border Controller generates the key pair for the certificate request internally.
The private key is stored as a part of the configuration in 3DES encrypted form (with an internal generated password)
and the public key is returned to the user along with other information as a part of PKCS10 certificate request.
The Oracle Communications Session Border Controller supports the option of importing CA certificates and marking
them as trusted. However, the Oracle Communications Session Border Controller only authenticates client certificates
that are issued by the CAs belonging to its trusted list. If you install only a specific vendor's CA certificate on the
Oracle Communications Session Border Controller , it authenticates that vendor's endpoints. Whether the certificate is
an individual device certificate or a site-to-site certificate does not matter because the Oracle Communications
Session Border Controller authenticates the signature/public key of the certificate.
Value Description
digitalSignature Used when the subject public key is used with a digital signature
mechanism to support security services other than non-repudiation,
(default with keyEncipherment)
certificate signing, or revocation information signing. Digital signature
mechanisms are often used for entity authentication and data origin
authentication with integrity.
nonRepudiation Used when the subject public key is used to verify digital signatures that
provide a non-repudiation service protecting against the signing entity
falsely denying some action, excluding certificate or CRL signing.
keyEncipherment Used with the subject public key is used for key transport. (For example,
when an RSA key is to be used for key management.)
(default with digitalSignature)
dataEncipherment Used with the subject public key is used for enciphering user data other
than cryptographic keys.
keyAgreement Used with the subject public key is used key agreement. (For example,
when a Diffie-Hellman key is to be used for a management key.)
encipherOnly The keyAgreement type must also be set.
Used with the subject public key is used only for enciphering data while
performing key agreement.
Value Description
serverAuth Used while the certificate is used for TLS server authentication. In Oracle
Communications Session Border Controller access-side deployments, the
(default)
system typically acts as a TLS server accepting TLS connections. You
might use this setting while generating the end-entity-cert.
clientAuth Used while the certificate is used for TLS client authentication. In Oracle
Communications Session Border Controller core-side deployments, the
system typically acts as a TLS client initiating TLS connections. You
might use this setting while generating the end-entity-cert.
Configuring TLS
This section explains how to configure your Oracle Communications Session Border Controller for TLS support.
Process Overview
In summary, you need to take the following steps to enable your Oracle Communications Session Border Controller
for TLS.
1. Make sure that your Oracle Communications Session Border Controller has the appropriate hardware installed and
that you have obtained an enabled the licenses related to TLS support. (Note that the Acme Packet 4250 does not
require an additional license for TLS support.)
2. Configure certificates.
3. Configure the specific parameters related to TLS.
Configuring Certificates
Configuring certificates is a three-step process:
1. Create a certificate record configuration on the Oracle Communications Session Border Controller
2. Generate a certificate request by the Oracle Communications Session Border Controller and save the configuration
3. Import the certificate record into the Oracle Communications Session Border Controller and save the
configuration
4. key-size—Enter the size of the key for the certificate. The default value is 1024. The valid range is:
• 512 | 1024 (default) | 2048
5. alternate-name—Optionally provide one or more alternative names for the certificate holder. The Subject
Alternative Name certificate extension is defined in section 4.2.1.6 of RFC 5280, Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List (CRL) Profile. This extension allows one or more
identities to be bound to the subject of a certificate. As a result, each subject alternative name is considered as an
alias for the certificate subject. These aliases may be included in addition to, or in place of the identity in the
subject field of the certificate, meaning that a certificate can contain a subject name and one or more aliases, or no
subject name and one or more aliases. A certificate cannot lack both a subject name and an alias. As specifically
defined in RFC 5280, subject alternative names can take the form of an e-mail address, an IP address (IPv4 or
IPv6), a DNS address, a Registered ID (RID), a Distinguished Name (DN), or a URI.
RFC also 5280 allows future support for other alternative name forms, but only if such forms are specified in an
IETF RFC.
Most alternative names take one of the following three formats: IP address (which requires an IP: prefix),
DNS (which requires a DNS: prefix), or email (which requires an email: prefix).
Example:
CMEPACKET(certificate-record)# alternate-name IP:192.168.12.101
ACMEPACKET(certificate-record)#
• Non-conforming endpoints have short NAT interval, where the HNT application with the TCP connection for TLS
operates as it does for regular TCP. We give the UA a shorter expires time so that it refreshes frequently, implicitly
forcing the UA to keep the TVP socket open and reuse it for further requests (in-dialog or out-of-dialog). Regular
requests using TLS sent from the Oracle Communications Session Border Controller to the UA reuse the same
TCP connection so that further TLS certificate exchanges are not required.
Viewing Certificates
You can view either a brief version or detailed information about the certificates.
Brief Version
Obtaining the brief version uses this syntax, and will appear like the following example:
ORACLE# show security certificates brief acmepacket
certificate-record:acmepacket
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
02:13:02:50:00:84:00:71
Issuer:
C=US
ST=California
L=San Jose
O=sipit
OU=Sipit Test Certificate Authority
Subject:
C=US
ST=MA
L=Burlington
O=Engineering
CN=acme
ORACLE#
Detailed Version
Obtaining the detailed version uses this syntax, and will appear like the following example:
ORACLE# show security certificates detail acmepacket
certificate-record:acmepacket
Certificate:
Data:
4. inactive-dynamic-conn—Enter the time in seconds after which the Oracle Communications Session
Border Controller tears down inactive dynamic TCP connections. Inactive is defined as not transporting any
traffic. This protects against endpoints establishing TCP/TLS connections and then not sending messages. The
default value is 32. The valid range is:
• Minimum—0
• Maximum—999999999
Note: Setting this parameter to 0 disables this parameter.
Because the Oracle Communications Session Border Controller first establishes a TCP connection, then the TLS
connection it waits twice the value entered here after the initiation of a TLS connection before tearing down the
connection.
After an endpoint establishes a TCP/TLS connection, it is supposed to keep the connection active by sending
messages or by using the NAT interval configuration. Whenever a connection is torn down because of inactivity, a
log at the level ERROR is generated.
6. access-control-trust-level—Set the trust level for the host within the realm. The default value is
none. The valid values are:
• none—Host is always untrusted. It is never promoted to the trusted list or demoted to the deny list.
• low—Host can be promoted to the trusted list or demoted to the deny list.
• medium—Host can be promoted to the trusted list but is only demoted to untrusted. It is never added to the
deny list.
• high—Host is always trusted.
7. Save and activate your configuration.
If you set this parameter to 0, then cache entries will never age (and not be deleted from the cache unless you
use the clear-cache tls command to delete all entries from the TLS cache). RFC 2246, The TLS
Protocol Version 1.0, recommends that you set this parameter at the maximum, 24.
The peer certificate from the calling party during the TLS handshake with the Oracle Communications Session
Border Controller looks like the following example.
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 9 (0x9)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=MA, L=Woburn, O=Smith Securities, OU=Certificate
Authority Dept, CN=Smith Certificate Authority/emailAddress=Smith@CA.com
Validity
Not Before: Dec 10 21:14:56 2009 GMT
Not After : Jul 11 21:14:56 2019 GMT
Subject: C=US, ST=MA, L=Burlington, O=Acme Packet, OU=Certificate
Authority Dept, CN=*.acme.com/emailAddress=ph1Client@acme.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Issuer Alternative Name:
email:Smith@CA.com
X509v3 Subject Alternative Name:
DNS:gw1.acme.com, DNS:gw3.ano.com, DNS:gw2.some.com
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
Signature Algorithm: sha1WithRSAEncryption
The outgoing SIP INVITE (INVITE 2 in the diagram) looks like the following sample. Bold text shows where the
Oracle Communications Session Border Controller uses information from the certificate.
INVITE sip:222222@acme.com:5060 SIP/2.0
Via: SIP/2.0/UDP 172.16.27.113:5060;branch=z9hG4bK4jmg29cmm8l0cg7smmrn85o4q7
From: 111111 <sip:111111@acme.com>;tag=_ph1_tag
To: 222222 <sip:222222@acme.com>
Call-ID: _1-2_call_id-10147@acme.com-1-
CSeq: 1 INVITE
Contact: <sip:111111@172.16.27.113:5060;transport=udp>
P-Certificate-Subject-Common-Name: *.acme.com
P-Certificate-Subject-Alternative-Name: gw1.acme.com
P-Certificate-Subject-Alternative-Name: gw3.ano.com
P-Certificate-Subject-Alternative-Name: gw2.some.com
Max-Forwards: 69
Subject: TBD
Content-Type: application/sdp
Content-Length: 138
Route: <sip:222222@172.16.27.188:5060;lr>
v=0
o=user1 53655765 2353687637 IN IP4 172.16.27.113
s=-
c=IN IP4 172.16.27.113
t=0 0
m=audio 20000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
• Compares this host (exact or wildcard match) with the Certificate Common Name or Certificate Subject
Alternative name of the certificate it has received
• Sends out an INVITE if the Certificate Common Name or Certificate Subject Alternative name match; Sends a
403 Forbidden rejection to the endpoint from it received the INVITE if there is no match
Wildcard matching applies only to the prefix of the Request-URI:
*.acme.com
*.*.acmepacket.com
This diagram shows a peering scenario where the Oracle Communications Session Border Controller receives an
INVITE from the calling party, which it processes and prepares to send out INVITE 2. After establishing a TLS
connection with the called party and caching the required information, the Oracle Communications Session Border
Controller validates the Request-URI. Once validation occurs, the Oracle Communications Session Border Controller
sends INVITE 2.
The peer certificate from the called party during the TLS handshake with the Oracle Communications Session Border
Controller would look like this. Relevant information in the sample appears in bold font.
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 9 (0x9)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=MA, L=Woburn, O=Smith Securities, OU=Certificate
Authority Dept, CN=Smith Certificate Authority/emailAddress=amith@CA.com
Validity
Not Before: Dec 10 21:14:56 2009 GMT
Not After : Jul 11 21:14:56 2019 GMT
Subject: C=US, ST=MA, L=Woburn, O=Acme Packet, OU=Certificate
Authority Dept, CN=*.acme.com/emailAddress=ph2Server@acme.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Issuer Alternative Name:
email:Smith@CA.com
X509v3 Subject Alternative Name:
DNS:gw1.acme.com, DNS:*.ano.com, DNS:*.some.com
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
Signature Algorithm: sha1WithRSAEncryption
The outgoing SIP INVITE (INVITE 2 in the diagram) would then look like the sample below. The INVITE is sent
because smith.acme.com matches the common name *.acme.com. Other valid SIP Request-URIs would be:
222222@gw1.acme.com
222222@smith.ano.com
222222@amith.some.com
You can see where the system uses information from the certificate; the text is bold.
INVITE sip:222222@smith.acme.com:5060 SIP/2.0
Via: SIP/2.0/UDP 172.16.27.113:5060;branch=z9hG4bK4jmg29cmm8l0cg7smmrn85o4q7
From: 111111 <sip:111111@acme.com>;tag=_ph1_tag
To: 222222 <sip:222222@acme.com>
Call-ID: _1-2_call_id-10147@acme.com-1-
CSeq: 1 INVITE
Contact: <sip:111111@172.16.27.113:5060;transport=udp>
Max-Forwards: 69
Subject: TBD
Content-Type: application/sdp
Content-Length: 138
Route: <sip:222222@172.16.27.188:5060;lr>
v=0
o=user1 53655765 2353687637 IN IP4 172.16.27.113
s=-
c=IN IP4 172.16.27.113
t=0 0
m=audio 20000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
ORACLE(enforcement-profile)#
3. add-certificate-info—Enter a list of one or more certificate attribute names to enable TLS certificate
information caching and insertion of cached certificate information into a customized SIP INVITEs. This
parameter is empty by default.
If you want to list more than one value, enclose the value in quotation marks (“ “) and separate the values with
Spaces.
ORACLE(enforcement-profile)# add-certificate-info "sub-common-name sub-alt-
name-DNS"
4. certificate-ruri-check—Change this parameter from disabled, its default, to enabled if you want
your Oracle Communications Session Border Controller to cache TLS certificate information and use it to validate
Request-URIs. Enabling this parameter also means the Oracle Communications Session Border Controller will use
the cached TLS certificate information in a customized SIP INVITE.
5. Type done to save your configuration.
Using its ability to promote endpoints to a trusted status, the Oracle Communications Session Border Controller now
closes TCP/TLS connections for endpoints that do not enter the trusted state within the period of time set for the
untrusted connection timeout. The attacking client is thus no longer able to keep connections alive by sending invalid
messages.
This feature works by setting a value for the connection timeout, which the Oracle Communications Session Border
Controller checks whenever a new SIP service socket for TCP or TLS is requested. If the timer’s value is greater than
zero, then the Oracle Communications Session Border Controller starts it. If the timer expires, then the Oracle
Communications Session Border Controller closes the connection. However, if the endpoint is promoted to the trusted
state, then the Oracle Communications Session Border Controller will cancel the timer.
Caveats
This connection timeout is intended for access applications only, where one socket is opened per-endpoint. This
means that the timeout is not intended for using in peering applications; if this feature were enabled for peering, a
single malicious SIP endpoint might cause the connection to be torn down unpredictably for all calls.
• revoked
• unknown
good indicates a positive response to the status inquiry. At a minimum, this positive response indicates that the
certificate is not revoked, but does not necessarily mean that the certificate was ever issued or that the time at which
the response was produced is within the certificate’s validity interval.
revoked indicates that the certificate has been revoked, either permanently or temporarily.
unknown indicates that the responder cannot identify the certificate.
Caveats
OCSP is currently supported only on TLS interfaces; it is not currently supported for use with IKEv1 and IKEv2.
Unreachable OCSR
With OCSP enabled, the client implementation running on the Oracle Communications Session Border Controller
supports message exchange between the Oracle Communications Session Border Controller and an OCSR as
specified in RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. The
Oracle Communications Session Border Controller contacts the OCSR whenever a remote client attempts to establish
an SSL/TLS connection with the Oracle Communications Session Border Controller. The Oracle Communications
Session Border Controller sends a request to the OCSR to check the current status of the certificate presented by the
remote client. The Oracle Communications Session Border Controller suspends processing of the SSL/TLS
connection request pending receipt of the OCSR response. In previous releases (prior to Version S-CX6.3.0), a good
OCSR response resulted in the establishment of a secure SSL/TLS connection. A revoked or unknown OCSR
response, or the failure to reach an OCSR, resulted in the rejection of the connection attempt.
This behavior, which adheres to the requirements of RFC 2560, conflicts with the requirements of Section
5.4.6.2.1.6.4.a.i of UCR 2008 which requires an OCSP client to attempt authentication of remote clients in the event
of an unreachable OCSR.
Release S-CX6.3F1 adds a new attribute (ignore-dead-responder) to the TLS profile configuration element to
provide compliance with DISA/DoD requirements specifying OCSP client operations when faced with unreachable
OCSRs. By default, the attribute is disabled meaning that all client connections will be disallowed in the event of
unreachable OCSRs.
In DISA/DoD environments ignore-dead-responder should be enabled, allowing local certificate-based
authentication by the Oracle Communications Session Border Controller in the event of unreachable OCSRs.
Successful authentication is achieved if the certificate presented by the remote client was signed by a Certificate
Authority (CA) referenced by the trusted-ca-certificates attribute. If the local authentication succeeds, the
secure TLS/SSL connection is established; otherwise the connection is rejected.
request, the Oracle Communications Session Border Controller returns the OCSR to the reachable status, and
generates an SNMP trap and log entry indicating that status change.
Use the following procedure to enable monitoring of individual OCSRs.
1. Navigate to the new security-config configuration element.
ORACLE# configure terminal
ORACLE(configure)# security#
ORACLE(security)# security-config
ORACLE(security-config)#
2. Enable monitoring of individual OCSRs by setting the ocsr-monitoring-traps attribute to enabled; this
attribute is disabled by default.
ORACLE(security-config)# ocsr-monitoring-traps enabled
ORACLE(security-config)#
3. Use done, exit, and verify-config to complete required configuration.
Reachability status of individual OCSRs is aggregated to monitor the overall availability of OCSR service. Using
the procedure explained above, the Oracle Communications Session Border Controller maintains a count of all
OCSRs, and of all reachable OCSRs.
• If all OCSRs are reachable, the Oracle Communications Session Border Controller generates a trap and log
entry noting this optimal state.
• If all OCSRs are unreachable, the Oracle Communications Session Border Controller generates a trap and log
entry noting this erroneous state.
• When the Oracle Communications Session Border Controller transitions from either of the two states
described above (in the optimal state, when an OCSR becomes unreachable; in the erroneous state, when an
unreachable OCSR becomes reachable), the Oracle Communications Session Border Controller generates a
trap and log entry indicating that an unspecified number of OCSRs are reachable.
Monitoring of OCSR service availability is a by-product of enabling SNMP; no further configuration is required.
In such cases the verify-config command issues a warning and notes that
IP address-based access will be used.
Release S-CX6.3F1 continues support for the direct trust model, while also supporting an alternative delegated trust
model as described in Section 5.4.6.2.1.6.1.e.3.c of UCR 2010. The delegated trust model requires that OCSR be
authenticated by a trusted CA. Within the DISA/DoD delegated trust model, an OCSR certificate is appended to every
response, thus eliminating the need for a pre-provisioned responder certificate. The appended certificate is a signing
certificate issued and signed by a DoD-approved CA that issued the certificate that is being validated. These OCSR
certificates have a short lifespan and are reissued regularly.
RFC 2560 does not require the digital signature of OCSP requests. OCSRs, however, can impose signature
requirements.
If a signed request is required by the OCSR, provide the name of the certificate configuration element that
contains the certificate used to sign OCSP requests.
9. The responder-cert attribute identifies the certificate used to validate signed OCSP response — a public key
of the OCSR.
In DISA/DoD environments that support the direct trust model, optionally provide the name of the certificate
configuration element that contains the certificate used to validate the signed OCSP response.
If a responder-cert is provided, it is only used if the OCSP response has no appended certificates, in which
case the OCSP client attempts to validate the response signature. Depending on the validation failure or success,
the response is rejected or accepted.
If the OCSP response has an appended certificate or certificate chain, the responder-cert is ignored, and the
trusted-cas list is used to validate the appended certificate(s).
10. The trusted-cas attribute (a list of certificate configuration objects) identifies the approved DoD-approved
CAs that sign OCSR certificates.
In DISA/DoD environments that support the delegated trust model, you must provide a list of CAs used to
validate the received certificate.
If a certificate or a certificate chain is appended to the OCSP response, the OCSP client verifies that the first
certificate signed the response, and that the CA is trusted by the Oracle Communications Session Border
Controller (that is, the CA certificate is contained in the trusted-cas list. The client then walks through each
additional certificate (if any exist) ensuring that each certificate is also trusted. If all certificates are trusted, the
OCSP response is accepted; otherwise, it is rejected.
11. The retry-count attribute specifies the maximum number of times to retry an OCSP responder in the event of
connection failure.
If the retry counter specified by this attribute is exceeded, the OCSP requester contacts another responder (if
multiple responders have been configured) and quarantines the unavailable responder for a period defined the
dead-time attribute.
In the absence of an explicitly configured value (an integer within the range 0 through 10), the Oracle
Communications Session Border Controller provides a default value of 1 (connection retries).
12. The dead-time attribute specifies the quarantine period imposed on an unavailable OCSR.
In the absence of an explicitly configured value (an integer within the range 0 through 3600 seconds), the Oracle
Communications Session Border Controller provides a default value of 0 (no quarantine period).
Customer implementations utilizing a single OCSP responder are encouraged to retain the default value, or to
specify a brief quarantine period to prevent lengthy service outages.
13. Use done, exit, and verify-config to complete configuration of this cert-status-profile instance.
14. Repeat Steps 1 through 13 to configure additional cert-status-profile configuration elements.
IPv6-IPv4 Internetworking
The Oracle Communications Session Border Controller supports the following internetworking environments:
SIP-TLS IPv6 endpoints with SIP-TLS IPv4 endpoints
SIP-TLS IPv6 endpoints with SIP-TLS IPv6 endpoints
SIP-TLS IPv6 endpoints with non-SIP-TLS (unencrypted) IPv4 endpoints
SIP-TLS IPv6 endpoints with non-SIP-TLS (unencrypted) IPv6 endpoints
SIP-TLS IPv4 endpoints with non-SIP-TLS (unencrypted) IPv6 endpoints
Note: Previously delivered TLS functionality, for example, support for certificate extensions, and support for
certificate chain processing, is not affected by IPv6-IPv4 internetworking.
Supported Topologies
The following internetworking topologies are supported:
• SRTP IPv6 endpoints with SRTP IPv4 endpoints
• SRTP IPv6 endpoints with SRTP IPv6 endpoints
• SRTP IPv6 endpoints with RTP (unencrypted) IPv4 endpoints
• SRTP IPv6 endpoints with RTP (unencrypted) IPv6 endpoints
• SRTP IPv4 endpoints with RTP (unencrypted) IPv6 endpoints
IPv6 support must be globally enabled to support SRTP internetworking as listed above.
If IPv6 has not been globally enabled, use the following procedure to do so. If IPv6 is currently enabled, no additional
configuration is required.
1. Navigate to the system-config configuration element.
ORACLE# configure terminal
ORACLE(configure)# system
ORACLE(system)# system-config
ORACLE(system-config)#
2. Enable IPv6 by setting the ipv6-support attribute to enabled; this attribute is disabled by default.
ORACLE(system-config)# ipv6-support enabled
ORACLE(system-config)#
3. Use done, exit, and verify-config to complete required configuration.
4. Reboot the Oracle Communications Session Border Controller.
Hardware Requirements
SRTP IPv4 and IPv6 internetworking requires the Enhanced Traffic Controller (ETC) NIU.
Supported Topologies
The following internetworking topologies are supported and illustrated below
SRTP IPv4 endpoints with SRTP IPv4 endpoints
SRTP IPv4 endpoints with RTP (unencrypted) IPv6 endpoints
SRTP IPv6 endpoints with SRTP IPv6 endpoints
SRTP IPv6 endpoints with RTP (unencrypted) IPv4 endpoints
SRTP IPv6 endpoints with RTP (unencrypted) IPv6 endpoints
Configuration
IPv6 support must be globally enabled to support SRTP internetworking as described above. If IPv6 is currently
enabled, no additional configuration is required.
IKEv1 Protocol
IKEv1 is specified by a series of RFCs, specifically RFCs 2401 through 2412. The most relevant are:
• RFC 2407, The Internet IP Security Domain of Interpretation for ISAKMP
• RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP)
• RFC 2409, The Internet Key Exchange (IKE)
• RFC 2412, Oakley Key Determination Protocol
IKEv1 combines features of the Internet Security Association and Key Management Protocol (ISAKMP) and Oakley
Key Determination Protocol in order to negotiate Security Associations (SA) for two communicating peers. IKEv1
also provides for key agreement using Diffie-Hellman.
IKEv1 uses two phases. Phase 1 is used to establish an ISAKMP Security Association for IKEv1 itself. Phase 1
negotiates the authentication method and symmetric encryption algorithm to be used. Phase 1 requires either six
messages (main mode) or three messages (aggressive mode).
Phase 2 negotiates the SA for two IPsec peers and is accomplished with three messages.
The initial IKEv1 implementation supports RFC 2409, Internet Key Exchange, and RFC 3706, A Traffic-Based
Method of Detecting Dead Internet Key Exchange (IKE) Peers.
IKEv1 Configuration
IKEv1 configuration consists of five steps.
1. Configure IKEv1 global parameters.
2. Optionally, enable and configure Dead Peer Detection (DPD) Protocol.
3. Configure IKEv1 interfaces.
4. Configure IKEv1 Security Associations (SA).
5. Assign the IKEv1 SA to an IPsec Security Policy.
6. Use the load-max-loop parameter to specify the maximum number of endpoints examined every dpd-
time-interval when the CPU is under load, as specified by the max-cpu-limit parameter.
Allowable values are within the range 1 through 999999999 (endpoints) with a default of 40. Ensure that the
configured value is less than the value assigned to max-loop.
7. Use the load-max-endpoints parameter to specify the maximum number of simultaneous DPD Protocol
negotiations supported when the CPU is under load, as specified by the max-cpu-limit property.
Allowable values are within the range 1 through 999999999 (endpoints) with a default of 5. Ensure that the
configured value is less than the value assigned to max-endpoints.
8. Use done, exit, and verify-config to complete configuration of the DPD template instance.
9. Repeat Steps 1 through 8 to configure additional DPD templates.
Authentication Header (AH) — the default value — as defined by RFC 4302, IP Authentication Header, which
provides authentication integrity to include the mutual identification of remote peers, non-repudiation of received
traffic, detection of data that has been altered in transit, and detection of data that has been replayed, that is copied
and then re-injected into the data stream at a later time. Authentication services utilize the authentication
algorithm specified by the auth-algo property.
Encapsulating Security Payload (ESP) as defined by RFC 4303, IP Encapsulating Security Payload, which
provides both authentication and privacy services. Privacy services utilize the encryption algorithm specified by
the encryption-algo property.
ESP-AUTH (also RFC 4303-based), which supports ESP’s optional authentication.
ESP-NULL (also RFC 4303-based) which proves NULL encryption as described in RFC 2410, The NULL
Encryption Algorithm and Its Use With IPsec. This option provides no privacy services, and is not recommended
for production environments.
Refer to the following figures for additional details.
AH Transport Mode
AH Tunnel Mode
Protocol Overview
While the RFC 3711 framework provides encryption and authentication procedures and defines a set of default
cryptographic transforms required for RFC compliance, it does not specify a key management protocol to securely
derive and exchange cryptographic keys. RFC4568, Session Description Protocol (SDP) Security Description for
Media Streams, defines such a protocol specifically designed to exchange cryptographic material using a newly
defined SDP crypto attribute. Cryptographic parameters are established with only a single message or in single round-
trip exchange using the offer/answer model defined in RFC 3264, An Offer/Answer Model with the Session
Description Protocol.
Release S-C6.2.0 provides support for an initial SDP Security Descriptions (SDES) implementation that generates
keys used to encrypt SRTP/SRTCP packets. Authentication of packets will be added to a subsequent release.
The MKI is used only when the offer contains multiple keys; it provides a means to differentiate one key from
another. The MKI takes the form of an integer, followed by its byte length when included in SRTP/SRTCP packets.
In the sample offer the MKI value is 1 with a length of 4 bytes.
The session-parameters field contains a set of optional parameters that may override SRTP session defaults for the
SRTP and SRTCP streams.
UNENCRYPTED_SRTP — SRTP messages are not encrypted
UNENCRYPTED_SRTCP — SRTCP messages are not encrypted
UNAUTHENTICATED_SRTP — SRTP messages are not authenticated
When generating an initial offer, the offerer must ensure that there is at least one crypto attribute for each media
stream for which security is desired. Each crypto attribute for a given media stream must contain a unique tag. The
ordering of multiple crypto attributes is significant — the most preferred crypto suite is listed first.
Upon receiving the initial offer, the answerer must either accept one of the offered crypto attributes, or reject the offer
in its entirety.
When an offered crypto attribute is accepted, the crypto attribute in the answer MUST contain the tag and crypto-suite
from the accepted crypto attribute in the offer, and the key(s) the answerer will be using for media sent to the offerer.
The crypto-suite is bidirectional and specifies encryption and authentication algorithms for both ends of the
connection. The keys are unidirectional in that one key or key set encrypts and decrypts traffic originated by the
offerer, while the other key or key set encrypts and decrypts traffic originated by the answerer. The use of symmetric
keying, where the same key is used for both encryption and decryption, mandates the key exchange between the
offerer and the answerer.
Key exchange via text-based SDP is unacceptable in that malicious network elements could easily eavesdrop and
obtain the plaintext keys, thus compromising the privacy and integrity of the encrypted media stream. Consequently,
the SDP exchange must be protected by a security protocol such as IPsec or TLS.
Operational Modes
SRTP topologies can be reduced to three basic topologies which are described in the following sections.
Security Associations and updates the SDP by removing the crypto attribute and inserting possibly NAT’ed media
addresses and ports. At the same time, the original crypto attribute is also removed from the SDP.
Once the reply from the called party is received, the Oracle Communications Session Border Controller inserts
appropriate crypto attribute(s) to form a new SDP, and forward the response back to the calling party.
SRTP Pass-Thru
SRTP pass-thru is illustrated in the following figure.
SRTP Pass-Thru
If the media security policy specifies pass-through mode, the Oracle Communications Session Border Controller does
not alter the crypto attribute exchange between the calling and the called party; the attribute is transparently passed.
SDES Configuration
SDES configuration consists of the following steps.
1. Create one or more SDES profiles which specify parameter values negotiated during the offer/answer exchange.
2. Create one or more Media Security Policies that specify key exchange protocols and protocol-specific profiles.
3. Assign a Media Security Policy to a realm.
4. Create an interface-specific Security Policy.
mode identifies the transport protocol (RTP or SRTP) accepted in an SDP offer when this media-security-policy is
in effect.
13. Use done, exit, and verify-config to complete configuration of this media security policy instance.
14. Repeat Steps 1 through 13 to configure additional media-security policies.
Security Policy
A Security Policy enables the Oracle Communications Session Border Controller to identify inbound and outbound
media streams that are treated as SRTP/SRTCP. The high-priority Security Policy, p1, (shown below) allows signaling
traffic from source 172.16.1.3 to destination 172.16.1.10:5060. The lower-priority Security Policy, p2, (also shown
below) matches media traffic with the same source and destination, but without any specific ports. Consequently, SIP
signaling traffic (from local port 5060) go through, but the media stream will be handled by appropriate SRTP SA.
security-policy
name p1
network-interface private:0
priority 0
local-ip-addr-match 172.16.1.3
remote-ip-addr-match 172.16.1.10
local-port-match 5060
remote-port-match 0
trans-protocol-match UDP
direction both
local-ip-mask 255.255.255.255
remote-ip-mask 255.255.255.255
action allow
ike-sainfo-name
outbound-sa-fine-grained-mask
local-ip-mask 255.255.255.255
remote-ip-mask 255.255.255.255
local-port-mask 0
remote-port-mask 0
trans-protocol-mask 0
valid enabled
vlan-mask 0xFFF
last-modified-by admin@console
last-modified-date 2009-11-09 15:01:55
security-policy
name p2
network-interface private:0
priority 10
local-ip-addr-match 172.16.1.3
remote-ip-addr-match 172.16.1.10
local-port-match 0
remote-port-match 0
trans-protocol-match UDP
direction both
Protocol Overview
While the RFC 3711 framework provides encryption and authentication procedures and defines a set of default
cryptographic transforms required for RFC compliance, it does not specify a key management protocol to securely
derive and exchange cryptographic keys. RFC3830, Multimedia Internet Keying, defines such a protocol that
transmits cryptographic material using an exchange of a MIKEY initiation message (referred to as an I_MESSAGE)
and a MIKEY response message (referred to an as a R_MESSAGE).
Release S-C6.2.0 provides support for an initial MIKEY implementation, based on RFC 3830, and RFC 4567, Key
Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP).
The MIKEY I_MESSAGE takes the following format.
HDR, T, RAND, [IDi], [IDr], {SP}, KEMAC
where
HDR (defined in section 6.1 of RFC 3830) contains the common MIKEY header.
T (defined in section 6.6 of RFC 3830) contains a timestamp.
RAND (defined in section 6.11 of RFC 3830) contains a pseudo-random string used in the generation of TEKs (traffic
encryption keys).
IDi and IDr (defined in section 6.7 of RFC 3830) optionally contain the initiator and responder ID.
SP (defined in sections 6.10 and 6.10.1of RFC 3830) contains a list of security parameters. Pertinent parameters
include encryption algorithm, encryption key length, authentication algorithm, authentication key length, salt key
length, pseudo random function, key derivation rate, SRTP encryption switch, SRTCP encryption switch, and SRTP
authentication switch).
KEMAC (defined in sections 6.2 and 6.13 of RFC 3830) contains TGK (TEK Generation Key) material that generates
TEKs.
The MIKEY R_MESSAGE takes the following format.
HDR, T, [IDr], V
where
HDR (defined in section 6.1 of RFC 3830) contains the common MIKEY header.
T (defined in section 6.6 of RFC 3830) contains a timestamp.
[IDr] (defined in section 6.7 of RFC 3830) optionally contains the responder ID.
V (defined in section 6.9 of RFC 3830) contains verification/authentication data.
MIKEY I and R MESSAGES are conveyed in base64-encoded format via SDP using the key management extensions
specified in RFC 4567, Key Management Extensions for Session Description Protocol (SDP) and Real Time
Streaming Protocol (RTSP). A sample initiation/response exchange follows.
MIKEY I_MESSAGE
v=0
o=alice 2891092738 2891092738 IN IP4 w-land.example.com
s=Cool stuff
e=alice@w-land.example.com
t=0 0
c=IN IP4 w-land.example.com
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyONQ6gAAAAAGEE
oo2pee4hp2UaDX8ZE22YwKAAAPZG9uYWxkQGR1Y2suY29tAQAAAAAAAQAk0JKpgaV
kDaawi9whVBtBt0KZ14ymNuu62+Nv3ozPLygwK/GbAV9iemnGUIZ19fWQUO
SrzKTAv9zV
m=audio 49000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
m=video 52230 RTP/SAVP 31
a=rtpmap:31 H261/90000
The initiator proposes to establish one audio stream and one video stream running SRTP (signaled by the use of the
SAVP profile). The initiator offers a session based key to encrypt both audio and video streams by locating the key
management a line above the m lines that describe the audio and video streams. The initiator uses MIKEY to set up
the security parameters for SRTP. The MIKEY_I message contains the security parameters, together with the
necessary key material.
Upon receiving the offer, the responder validates the MIKEY_I message, and, assuming support for the specified
crypto suite and security parameters, accepts the offer and returns a MIKEY_R MESSAGE to the initiator (conveyed
via the 200 OK response).
MIKEY R_MESSAGE
v=0
o=bob 2891092897 2891092897 IN IP4 foo.example.com
s=Cool stuff
e=bob@foo.example.com
t=0 0
c=IN IP4 foo.example.com
a=key-mgmt:mikeyAQEFgM0XflABAAAAAAAAAAAAAAYAyONQ6gAAAAAJAA
AQbWlja2V5QG1vdXNlLmNvbQABn8HdGE5BMDXFIuGEga+62AgY5cc=
m=audio 49030 RTP/SAVP 98
a=rtpmap:98 AMR/8000
m=video 52230 RTP/SAVP 31
a=rtpmap:31 H261/90000
Key exchange via text-based SDP is unacceptable in that malicious network elements could easily eavesdrop and
obtain the plaintext keys, thus compromising the privacy and integrity of the encrypted media stream. Consequently,
the SDP exchange must be protected by a security protocol such as IPsec or TLS.
Operational Modes
SRTP topologies can be reduced to three basic topologies which are described in the following sections.
SRTP Pass-Thru
SRTP pass-thru is illustrated in the following figure.
SRTP Pass-Thru
If the media-sec-policy for the ingress and the egress realms specifies pass-thru mode, the Oracle Communications
Session Border Controller does not intercept the SDES/MIKEY exchange between the caller and the callee. The
SDES/MIKEY will be forwarded as it is from the caller to the callee, or vice versa.
MIKEY Configuration
MIKEY configuration consists of the following steps.
1. The creation of one or more MIKEY profiles which specify parameter values negotiated during the MIKEY
message exchange.
2. The creation of one or more Media Security Policies that specify key exchange protocols and protocol-specific
profiles.
3. The assignment of a Media Security Policy to a realm.
4. The creation of an interface-specific Security Policy.
• If MIKEY is used in the incoming direction the same encryption algorithm is used for the outgoing direction.
• If the incoming direction does not have SRTP, then AES-CM is used as the encryption algorithm.
When NULL is used RTP and RTCP packets are not encrypted.
5. Use the auth-algorithm parameter to select the encryption algorithm that is offered when acting in the
initiator role, or accepted when acting in the responder role.
Allowable values are any, NULL, HMAC-SHA1-32, HMAC-SHA1-80
As a MIKEY initiator, select the authentication algorithm to be included in the I_MESSAGE.
As a MIKEY responder, select the authentication algorithm to by accepted from the I_MESSAGE.
The default value, any, indicates that the Oracle Communications Session Border Controller accepts the
authentication algorithm specified in the MIKEY_I MESSAGE, as long as it is within the valid range. For the
outgoing direction (that is calls originated by the Oracle Communications Session Border Controller), the
selection of the authentication algorithm for any is as follows:
• If MIKEY is used in the incoming direction the same encryption algorithm is used for the outgoing direction.
• If the incoming direction does not have SRTP, then HMAC-SHA1-80 is used as the encryption algorithm.
When NULL is used RTP and RTCP packets are not authenticated.
6. The shared-secret parameter contains the shared secret.
A shared secret is not required as MIKEY messages are not protected in this initial implementation.
7. Use the mki parameter to enable or disable the inclusion of the MKI:length field in the SDP key-management
attribute.
The master key identifier (MKI) is an optional field within the SDP key-management attribute that differentiates
one key from another. MKI is expressed as a pair of decimal numbers in the form: |mki:mki_length| where mki is
the MKI integer value and mki_length is the length of the MKI field in bytes.
The MKI field is necessary only in topologies that may offer multiple keys within the key-management attribute.
Allowable values are enabled and disabled (the default).
enabled – an MKI field is sent within the crypto attribute (16 bytes maximum, dependent on hardware)
disabled – no MKI field is sent
8. Use done, exit, and verify-config to complete configuration of this MIKEY profile instance.
9. Repeat Steps 1 through 8 to configure additional MIKEY profiles.
With pass-thru mode enabled, the User Agent (UA) endpoints negotiate security parameters between each other;
consequently, the Oracle Communications Session Border Controller simply passes SRTP traffic between the two
endpoints.
With pass-thru mode disabled, the Oracle Communications Session Border Controller disallows end-to-end
negotiation — rather the Oracle Communications Session Border Controller initiates and terminates SRTP tunnels
with both endpoints
In the absence of an explicitly configured value, the default value, disabled, is used.
4. Use the outbound navigation command to move to media-sec-outbound configuration mode. While in this
configuration mode you specify security parameters applied to the outbound call leg, that is calls sent by the
Oracle Communications Session Border Controller.
5. Use the protocol parameter to select the key exchange protocol.
Allowable values are mikey and sdes.
Select mikey for MIKEY key exchange.
6. Use the profile parameter to specify the name of the MIKEY profile associated with the outbound leg of this
media-security-policy.
7. Use the mode parameter to select the real time transport protocol.
Allowable values are rtp and srtp (the default).
mode identifies the transport protocol (RTP or SRTP) included in an SDP offer when this media-security-policy is
in effect.
As an initiator, the Oracle Communications Session Border Controller send a MIKEY I_MESSAGE with media
descriptions that have the transport protocol specified in this field.
As a responder, the Oracle Communications Session Border Controller accepts a MIKEY I_MESSAGE with
media descriptions that have the transport protocol specified in this field If a media description has no transport
protocol that matches the value of this field, the INVITE message is rejected with the 488 Not Acceptable Here
response.
8. Use the done and exit parameters to return to media-sec-policy configuration mode.
9. Use the inbound navigation command to move to media-sec-inbound configuration mode. While in this
configuration mode you specify security parameters applied to the inbound call leg, that is calls received by the
Oracle Communications Session Border Controller.
10. Use the protocol parameter to select the key exchange protocol.
Allowable values are mikey and sdes.
Select mikey for MIKEY key exchange.
11. Use the profile parameter to specify the name of the MIKEY profile associated with the inbound leg of this
media-security-policy.
12. Use the mode parameter to select the real time transport protocol.
Allowable values are rtp and srtp (the default).
mode identifies the transport protocol (RTP or SRTP) included in an SDP offer when this media-security-policy is
in effect.
As an initiator, the Oracle Communications Session Border Controller sends a MIKEY I_MESSAGE with media
descriptions that have the transport protocol specified in this field.
As a responder, the Oracle Communications Session Border Controller accepts a MIKEY I_MESSAGE with
media descriptions that have the transport protocol specified in this field. If a media description has no transport
protocol that matches the value of this field, the INVITE message is rejected with the 488 Not Acceptable Here
response.
13. Use done, exit, and verify-config to complete configuration of this media security policy instance.
14. Repeat Steps 1 through 13 to configure additional media-security policies.
Security Policy
A Security Policy enables the Oracle Communications Session Border Controller to identify inbound and outbound
media streams that are treated as SRTP/SRTCP. The high-priority Security Policy, p1, (shown below) allows signaling
traffic from source 172.16.1.3 to destination 172.16.1.10:5060. The lower-priority Security Policy, p2, (also shown
below) matches media traffic with the same source and destination, but without any specific ports. Consequently, SIP
signaling traffic (from local port 5060) go through, but the media stream will be handled by appropriate SRTP SA.
security-policy
name p1
network-interface private:0
priority 0
local-ip-addr-match 172.16.1.3
remote-ip-addr-match 172.16.1.10
local-port-match 5060
remote-port-match 0
trans-protocol-match UDP
direction both
local-ip-mask 255.255.255.255
remote-ip-mask 255.255.255.255
action allow
ike-sainfo-name
outbound-sa-fine-grained-mask
local-ip-mask 255.255.255.255
remote-ip-mask 255.255.255.255
local-port-mask 0
remote-port-mask 0
trans-protocol-mask 0
valid enabled
vlan-mask 0xFFF
last-modified-by admin@console
last-modified-date 2009-11-09 15:01:55
security-policy
name p2
network-interface private:0
priority 10
local-ip-addr-match 172.16.1.3
remote-ip-addr-match 172.16.1.10
local-port-match 0
remote-port-match 0
trans-protocol-match UDP
direction both
local-ip-mask 255.255.255.255
remote-ip-mask 255.255.255.255
action srtp
ike-sainfo-name
outbound-sa-fine-grained-mask
• If the value is same-as-ingress (default), the Oracle Communications Session Border Controller
leaves the profile of the media lines unchanged.
• If the value is simultaneous-best-effort, the Oracle Communications Session Border Controller
inspects the incoming offer SDP and:
• Adds an RTP/SAVP media line for any media profile that has only the RTP/AVP media profile
• Adds an RTP/AVP media line for any media profile that has only the RTP/SAVP media profile
17. Type done to save your work and continue.
To set the egress offer format for an SDES profile configuration:
18. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
19. Type security and press Enter.
ORACLE(configure)# security
ORACLE(security)#
20. Type media-security and press Enter.
ORACLE(security)# media-security
ORACLE(media-security)#
21. Type mikey-profile and press Enter. If you are editing a pre-existing configuration, you needs to select it
before you can make changes.
ORACLE(media-security)# mikey-profile
ORACLE(mikey-profile)#
22. egress-offer-format—Choose an egress offer format for this profile to use
when you set the outbound mode in the media security policy to any. You can
select one of two values:
• If the value is same-as-ingress (default), the Oracle Communications Session Border Controller
leaves the profile of the media lines unchanged.
• If the value is simultaneous-best-effort, the Oracle Communications Session Border Controller
inspects the incoming offer SDP and:
• Adds an RTP/SAVP media line for any media profile that has only the RTP/AVP media profile
• Adds an RTP/AVP media line for any media profile that has only the RTP/SAVP media profile
23. Type done to save your work and continue.
Refining Interoperability
To refine any remaining interoperability issues, you can use the options parameter in these configurations: media-
sec-policy, sdes-profile, and mikey-profile.
Commons value to configure an option are include-local-id and include-remote-id. By default, the
Oracle Communications Session Border Controller does not include the IDi or IDr when sending the MIKEY
I_MESSAGE. And it does not set the IDr in the MIKEY R_MESSAGE. Using the options provides these results:
• include-local-id—The Oracle Communications Session Border Controller includes the IDi in the
I_MESSAGE and the IDr in the R_MESSAGE.
When used for the outbound direction of a media security policy, the IDi is included in the I_MESSAGE the
Oracle Communications Session Border Controller sends. The content of the IDi is the value of the Contact header
found in the INVITE message.
When configured for the mikey-profile associated with the inbound media security policy, the Oracle
Communications Session Border Controller includes the IDr in the R_MESSAGES it sends in response to
incoming I_MESSAGES. The content of the IDr is the value of the Contact header found in the 200 OK response.
• include-remote-id—The system includes the IDr in the I_MESSAGE.
When configured for the mikey-profile associated with the outbound media security policy, the Oracle
Communications Session Border Controller includes the IDr in I_MESSAGES it initiates. The content of the IDr
is the value of the Request-URI from the INVITE message.
License Requirements
Multi-system Selective SRTP Pass-through requires only the SIP license.
Hardware Requirements
On the Acme Packet 4600 and Acme Packet 4500 platforms, Multi-system Selective SRTP Pass-through requires an
SSM2 (for SIP/TLS signalling), and either an IPsec/SRTP NIU, or an ETC NIU.
Constraints
Multi-system Selective SRTP Pass-through support has the following constraints:
1. The realm, or realms in which the calling and called parties are located are configured for Multi-system Selective
SRTP Pass-through support.
2. The call session does not require SIP—INFO to RFC 2833 tone translation.
3. The call session does not require SDES/MIKEY internetworking. Both SDES and MIKEY can be used for the
exchange of SRTP keying material. Both the calling and called parties must support the same key exchange
protocol.
4. Multi-system Selective SRTP Pass-through support should not be enabled in topologies where core-side
application servers may change the c-line to inject a media server or some other media device in the media path.
In such cases, SRTP should be terminated at the SD for each endpoint, so that the media server receives
unencrypted media. In the other case, where the c-line is not subject to modification, Multi-system Selective SRTP
Pass-through can be enabled.
If any of these conditions are not met, Multi-system Selective SRTP Pass-through processing cannot be provided,
and the call is serviced as specified by SRTP Media Proxy Mode.
Operational Overview
To set up Multi-system Selective SRTP Pass-through, the ingress and egress Oracle Communications Session Border
Controllers (which can, in fact, be a single Oracle Communications Session Border Controller) exchange the SDES or
MIKEY keying material that they receive from their respective endpoint so that the Oracle Communications Session
Border Controller peer can pass the material to its adjacent endpoint. The endpoint to endpoint exchange of keying
material enables the endpoints themselves to generate encryption/decryption keys.
The actual exchange of keying material takes place in SIP messages (specifically, INVITE, 200 OK, and ACK) that
carry offer or answer SDPs. Encrypted keying material is conveyed within a media attribute for each SRTP session.
The name of the media attribute is configurable.
When either Oracle Communications Session Border Controller receives the encrypted keying material sent by its
remote peer, it decrypts the media attribute and passes the plaintext attribute to its endpoint. Consequently, subsequent
SRTP packets from the endpoints pass through the Oracle Communications Session Border Controllers without being
decrypted and encrypted because both endpoints (now is possession of each others keying material) are able to
decrypt the SRTP packets received from the other.
Call Flows
The following three sections describe call signalling for common scenarios.
Call Setup
A: The calling party sends an INVITE with SDP to SBC-A. The offer SDP contains an SDES crypto attribute within
the SRTP media line.
B: Since Multi-system Selective SRTP Pass-through is enabled within the ingress realm, SD-A adds an a=X-acme-
srtp-msm media attribute. The a=X-acme-srtp-msm attribute contains a cookie that includes an encryption of the
SDES crypto attribute present in the SDP. The encryption is done using the shared secret configured for encrypting
SRTP Pass-through information.
C: SBC-B receives the offer SDP that has the cookie sent by SBC-A. It is assumed that the proxies that forward the
offer SDP sent by SBC-A preserve and forward the cookie added by SBC-A.
D: SBC-B checks if the egress realm has Multi-system Selective SRTP Pass-through enabled. If so, SBC-B decrypts
the cookie using the shared secret to retrieve the SDES crypto attribute. SBC-B adds the SDES crypto attribute
retrieved from the cookie to the offer SDP sent to UA-B.
E: The called party sends an answer SDP with a SDES crypto attribute on the SRTP media line to SBC-B.
F: SBC-B checks if it has received a cookie in the offer SDP and adds the cookie to the answer SDP. The cookie
contains an encryption of the SDES crypto attribute received in the answer SDP from UA-B. SBC-B does not install
any SA or media policy so that SRTP packets from/to UA-B can pass through SBC-B without any decryption/
encryption.
G: SBC-A receives the answer SDP that has the cookie sent by SBC-B.
H: SBC-A decrypts the cookie using the shared secret to retrieve the SDES crypto attribute. SBC-A adds the SDES
crypto attribute retrieved from the cookie to the answer SDP. SBC-A does not install any SA or media policy so that
SRTP packets from/to UA-A can pass through SBC-A without any decryption/encryption.
Music on Hold
After a call is established, one of the endpoints can put the other endpoint on hold. An application server might
intercept the re-INVITE from one endpoint (for putting the other on hold) and implement MoH as follows.
C: SBC-B receives an offer SDP that is addressed to the MS without any cookie.
D: Because there is no cookie in the ingress offer SDP, SD-B generates its own SDES crypto attributes for the egress
offer SDP sent to UA-B.
E: SBC-B receives am answer SDP from UA-B.
F: SBC-B sends its answer SDP without any cookie and encrypts SRTP packets going to UA-B. Note that there will
be no SRTP packets going from UA-B to SBC-B.
As a result, MoH is heard by UA-B as it decrypts SRTP packets encrypted by SBC-B. When UA-A resumes, the steps
to establish media between UA-A and UA-B will be the same as the steps used for call setup.
Once the media is reestablished between UA-A and UA-B media travelling between the two UAs will not be
decrypted by either SBC.
Call Transfer
A call transfer can also happen after a call is established. For example, endpoint UA-B can transfer UA-A to another
endpoint, UA-C. UA-B can make a blind transfer or an attended transfer. The following diagram describes a blind call
transfer with SRTP Pass-through enabled. Note it does not show the SIP message exchange between UA-B and the
Application Server to facilitate the call transfer (i.e. the INVITE from UA-B to put the call on hold and the REFER/
NOTIFY message exchange between UA-B and the Application Server). After UA-A is put on hold and the transfer
target (that is, UA-C) is received from UA-B, the Application Server attempts to establish a call to UA-C. After the
call to UA-C is established, the Application Server takes UA-A off hold and connects its media session to that of UA-
C.
A: SBC-B receives an INVITE (from the Application Server to invite UA-C) without an offer SDP.
B: SBC-B sends an INVITE without an offer SDP to UA-C.
C: SBC-B receives a 200 OK response with an offer SDP that has a SDES crypto attribute on the SRTP media line
from UA-C.
D: Since Multi-system Selective SRTP Pass-through is enabled within the ingress realm, SBC-B adds a cookie to the
egress offer SDP that is sent to the core realm.
E: SBC-A receives a re-INVITE to UA-A with the offer SDP that has the cookie sent by SBC-B.
F: Since Multi-system Selective SRTP Pass-through is enabled within the ingress realm, SBC-A adds the SDES
crypto attribute retrieved from the cookie to the offer SDP sent to UA-A.
G: SBC-A receives an answer SDP that has a SDES crypto attribute on the SRTP media line from UA-A.
H: SBC-A checks if it has a cookie in the offer SDP and adds the cookie to the answer SDP that is sent to the core
realm. The cookie contains an encryption of the SDES crypto attribute received in the answer SDP from UA-B. SBC-
A stops the encryption of any SRTP packets going to UA-B (set up for MoH) so that SRTP packets from/to UA-B can
now pass through SBC-A without any decryption/encryption.
I: SBC-B receives the answer SDP that has the cookie sent by SBC-A.
H: SBC-B decrypts the cookie using the shared secret to retrieve the SDES crypto attribute. SBC-B adds the SDES
crypto attribute retrieved from the cookie to the answer SDP.
After the call to UA-C is established and the call to UA-A is resumed (with the resulted media going between UA-A
and UA-C) the Application Server disconnects the call with UA-A. Note that steps C-J are essentially the same steps
as steps A-H in the Call Setup example. The difference is that the offer SDP from C comes to SD-B in a 200 OK
response and the answer SDP sent by SBC-B to C is in the ACK.
Early Media
Different application servers may implement early media in different ways. In general, the SBC supports early media
in the following way.
If the SBC receives an SDP without any cookie in a provisional response, the SBC generates its own SRTP crypto
context and exchanges it with the caller via the SDP included in the provisional response. The SBC continues to
decrypt and encrypt early media packets going to and from the caller. The SBC stops decrypting and encrypting only
if it receives a final response with an answer SDP that signals that SRTP Pass-through should be enabled.
3. Use done, exit, and verify-config to complete enabling Multi-system Selective SRTP Pass-through
within the current realm.
verify-config checks that the srtp-msm-password parameter has been configured, and outputs an error
if it has not been configured. verify-config also checks other configuration settings that conflict with Multi-
system SRTP Pass-through operation. Among these possible mis-configurations are the following.
rfc2833-mode set to preferred on a SIP interface within a realm that has srtp-msm-passthrough enabled
rfc2833-mode set to preferred and app-protocol set to SIP on a session-agent within a realm that has srtp-msm-
passthrough enabled.
4. If required, repeat Steps 1 through 3 to enable Multi-system Selective SRTP Pass-through on additional realms.
Use the following procedure to specify values need to support the exchange of SDES or MIKEY keying
information.
5. Use the following command sequence to move to security Configuration Mode.
ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)#
6. Use the srtp-msm-attr-name parameter to specify the name of the media attribute used to convey SDES or
MIKEY keying information within a SDP media description.
A valid attribute name must consist of characters from the US-ASCII subset of ISO-10646/UTF-8 as specified in
RFC 2327, SDP: Session Description Protocol. IANA-registered names should not be used. Values should begin
with an X-1 prefix to prevent collision with registered values.
In the absence of a specified attribute name, the SD provides a default value of X-acme-srtp-msm.
ORACLE(security)# srtp-msm-attr-name X-key-material
ORACLE(security)#
7. Use the srtp-msm-password parameter to provide the shared secret used to derive the key for encrypting
SDES or MIKEY keying material that is placed in the media attribute of an SDP media description. Ingress
keying material is encrypted using this shared secret before being forwarded to the network core. On egress, the
encrypted keying material is decrypted with this same key.
Allowable values are characters strings that contain a minimum of 8 and a maximum of 16 characters.
ORACLE(security)# srtp-msm-password IsHeEleemosynary
ORACLE(security)#
8. Use done, exit, and verify-config to complete necessary configuration.
verify-config checks that the srtp-msm-password parameter has been configured, and outputs an error
if it has not been configured. verify-config also checks other configuration settings that conflict with Multi-
system SRTP Pass-through operation. Among these possible mis-configurations are the following.
rfc2833-mode set to preferred on a SIP interface within a realm that has srtp-msm-passthrough enabled
rfc2833-mode set to preferred and app-protocol set to SIP on a session-agent within a realm that has srtp-msm-
passthrough enabled.
Statistics
The number of media sessions set up with Multi-systems Selective SRTP Pass-through is tracked and included in the
output of the show mbcd statistics command.
As of this release of the software, SRTP and transcoding may be combined for the same call. This behavior is
available by default and no extra configuration is required.
SRTP Re-keying
Initialization of SRTP re-keying is supported by the Oracle Communications Session Border Controller.
The Oracle Communications Session Border Controller can generate a new outbound crypto attribute in the SDP offer
in a SIP re-INVITE when the srtp-rekey-on-reinvite parameter is set to enabled. The system generates the attribute
regardless of the state of the flow, active or not.
This capability is important for some clients that reside on the SRTP side in a single SRTP termination mode
configuration. Any media changes that happen in the RTP side are hidden by the Oracle Communications Session
Border Controller. This concealment may cause issues in some configurations, where media servers are involved.
When the media changes from media server to called phone, the SRTP endpoint is not aware the media source
changed because the SDP offer from the Oracle Communications Session Border Controller is the same as original
invite. The result is that some devices drop packets because of Synchronization Source Identifier (SSRC) values
mismatch, unexpected jumps in sequence number, sequence number reversions back to 1 triggering replay attack
defense, and so forth. In certain environment is has been found that re-keying on every re-invite eliminates all these
issues especially in customer setups that use Microsoft Lync products.
The processing of standard RE-INVITES (those containing an SDP offer) and offerless RE-INVITES is shown below.
With SDP:
No SDP:
If the re-invite message is a refresh and srtp-rekey-on-reinvite is enabled, the outbound crypto will change but the
SDP version will not be incremented on the outgoing invite. If this scenario causes incompatibility issues with
customer equipment then add the unique-sdp-id option to media-manager->option configuration so the Oracle
Communications Session Border Controller increments the SDP version in the outgoing invite.
selection: 1
ORACLE(sdes-profile)#
3. srtp-rekey-on-reinvite—Set this parameter to enabled for re-keying upon the receipt of an SIP reINVITE that
contains SDP.
4. Type done to save your configuration.
IPSec Support
The Oracle Communications Session Border Controller offers IPSec for securing signaling, media, and management
traffic at the network layer.
Supported Protocols
The Oracle Communications Session Border Controller's IPSec implementation supports all required tools for
securing Internet communication via the IPSec protocol suite. The following paragraphs list and explain the protocols
within the IPSec suite that the Oracle Communications Session Border Controller supports. This chapter does not
explain how to design and choose the best protocols for your application.
AH vs. ESP
The Oracle Communications Session Border Controller supports the two encapsulations that IPSec uses to secure
packet flows. Authentication Header (AH) is used to authenticate and validate IP packets. Authentication means that
the packet was sent by the source who is assumed to have sent it.
Note: AH is incompatible with NAT. Validation means that the recipient is assured that the packet has arrived
containing the original, unaltered data as sent.
ESP (Encapsulating Security Payload) provides AH's authentication and validations and extends the feature set by
ensuring that the IP packet's contents remain confidential as they travel across the network. Using an encryption
algorithm that both peers agree upon, ESP encrypts a full IP packet so that if intercepted, an unauthorized party
cannot read the IPSec packet's contents.
Cryptographic Algorithms
IPSec works by using a symmetric key for validation and encryption. Symmetric key algorithms use the same shared
secret key for encoding and decoding data on both sides of the IPSec flow. The Oracle Communications Session
Border Controller's IPSec feature supports the following encryption algorithms:
• DES
• 3DES
• AES128CBC
• AES256CBC
• AES128CTR
• AES256CTR
The Oracle Communications Session Border Controller can quickly generate keys for all of the above mentioned
algorithms from the CLI. It can additionally support HMAC-SHA1 or HMAC-MD5 keyed-hash message
authentication codes. Only manual keying is currently supported for both hash authentication and data encryption.
Therefore, all keys must be provisioned on the Oracle Communications Session Border Controller by hand.
IPSec Implementation
The Oracle Communications Session Border Controller uses separate logic for processing IPSec packets based on
whether the traffic is inbound or outbound. The configuration is divided into two pieces, the security policy and the
security association (SA). Both the SA and security policies have a directional attribute which indicates if they can be
used and/or reused for inbound and outbound traffic.
Security Policy
The Oracle Communications Session Border Controller first performs a policy lookup on outbound traffic to test if it
should be subjected to IPSec rules. A security policy, local policy applicable for IPSec functionality, defines the
matching criteria for outgoing network traffic to secure. It is configured on a network interface basis.
Configuring a security policy is similar to a local policy, with additional IPSec-specific parameters. Unlike a local
policy, used for routing, a security policy is used for packet treatment. As with a local policy, a set of selector values
is matched against the outbound flow's following characteristics:
• VLAN
• Source IP address (plus mask)
• Source IP port
• Destination IP address (plus mask)
• Destination IP port
• Transport Protocol
Each of these selection criteria can be defined by a wildcard except for the VLAN ID, which can be ignored. This
flexibility aids in creating selection criteria that ranges from highly restrictive to completely permissive. In addition to
the main traffic matching criteria, a priority parameter is used to prioritize the order that configured security policies
are checked against. The #0 policy is checked first, #1 policy is checked next, continuing to the lowest prioritized
policy being checked last.
Once the outbound traffic matches a policy, the Oracle Communications Session Border Controller proceeds to the
next step of outbound IPSec processing. If no matching security policy is found, the default pass-through policy
allows the packet to be forwarded to the network without any security processing.
Fine-grained policy selection works by performing a logical AND between outbound traffic's fine-grained selectors
and the traffic's corresponding attributes. The result is then used to find the matching SA. Applying a fine-grained
mask has the effect of forcing a contiguous block of IP addresses and/or ports to appear as one address and or port.
During the next step of IPSec processing, when an SA is chosen, the Oracle Communications Session Border
Controller in effect uses one SA lookup for a series of addresses. Without fine-grained policy selection, unique SAs
must always be configured for outbound packets with unique security policy selectors.
Security Associations
After the Oracle Communications Session Border Controller determines that outgoing traffic is subject to IPSec
processing, and optionally applies fine-grained masking, an SA lookup is performed on the traffic. An SA is the set of
rules that define the association between two endpoints or entities that create the secured communication. To choose
an SA, the Oracle Communications Session Border Controller searches for a match against the outgoing traffic's SA
selectors. SA selectors are as follows:
• VLAN
• Source IP address
• Source IP port
• Destination IP address
• Destination IP port
• Transport Protocol
If there is a match, the Oracle Communications Session Border Controller secures the flow according to security
parameters defined in the SA that the Oracle Communications Session Border Controller chooses. The packet is then
forwarded out of the Oracle Communications Session Border Controller. If no match is found, the packets are
discarded, and optionally dumped to secured.log if the log-level is set to DEBUG.
The authentication algorithm and the authentication key must always be configured. The Oracle Communications
Session Border Controller supports hmac-md5 or hmac-sha1 authentication algorithms. Because only manual keying
is supported, the key must be entered by hand. When encryption is required, the encryption algorithm and the
encryption key must be configured. The Oracle Communications Session Border Controller supports des, 3des,
aes-128-cbc, aes-256-cbc, aes-128-ctr, and aes-256-ctr encryption algorithms. When using the two encryption
protocols that operate in AES counter mode (RFC 3686), an additional nonce value is required. In addition, the
security parameter index (SPI) must be configured for each SA. All SPI values mst be unique as well, across all SAs.
IP Header Inspection
Processing inbound IPSec packets begins by the Oracle Communications Session Border Controller inspecting an
inbound IP packet's headers. If the packet is identified as IPSec traffic, as determined by the presence of an AH or
ESP header, an SA policy lookup is performed. If the traffic is identified as non-IPSec traffic, as determined by the
lack of an IPSec-type (AH or ESP) header, it still is subject to a policy lookup. However, due to the default allow
policy, the packet is forwarded directly to the NP, without any security processing.
SA Matching
The Oracle Communications Session Border Controller proceeds to match the inbound IPSec traffic's selectors
against configured SAs. Inbound selector masking is performed where noted. These selectors are:
• VLAN (plus mask)
• Source IP address (plus mask)
• Source IP port
• Destination IP address (plus mask)
• Destination IP port
• Transport Protocol
• SPI
If no matching SA is found, the packets are discarded, and optionally dumped to secured.log if the log-level is set to
DEBUG. When the Oracle Communications Session Border Controller finds a matching SA, the packet is
authenticated and decrypted according to the configuration and sent to the Oracle Communications Session Border
Controller's NP for continued processing.
HA Considerations
Anti-replay mechanisms, running on IPSec peers, can cause instability with the Oracle Communications Session
Border Controllers configured in an HA pair. The anti-replay mechanism ensures that traffic with inconsistent (non-
incrementing) sequence numbers is labeled as insecure, assuming it could be part of a replay attack. Under normal
circumstances, this signature causes the remote endpoint to drop IPSec traffic.
When a failover occurs between HA peers, the newly-active system starts sending traffic with the IPSec sequence
number starting at 0. A remote system's anti-replay mechanism observes this and labels the traffic as insecure. It is
therefore recommended that anti-replay protection not be used with Oracle Communications Session Border
Controllers in an HA configuration. This situation does not create any problems as long as IPSec peers are not
configured to use anti-replay mechanisms.
Without the fine-grained option (or alternatively IKE), an SA entry would need to be configured for each of the three
phones, communicating over the IPSec tunnel (resulting in 3 tunnels).
This does not scale for manual-keying with a large number of endpoints. Using the fine-grained configuration as well
as the inbound SA mask allows any number of endpoints on the 10.1.1.X network to use a single security association
(a coarse-grain configuration). The configuration in this example follows:
A packet sent from the Oracle Communications Session Border Controller to any of the phones will match the policy
pol1. The remote-ip-mask parameter of the fine-grained configuration will then be masked against the remote-ip,
resulting in a SA selector value of 10.1.1.0. This matches security-association sa1, and the packet will be secured and
sent over the tunnel. The tunnel-mode addresses in the security-association represent the external, public addresses of
the termination points for the IPSec tunnel.
Packets returning from the 10.1.1.0 side of the IPSec tunnel will first match the tunnel-mode local-ip-addr of
218.100.1.1. The packets will then be decrypted using the SA parameters, and the tunneled packet will be checked
against the remote-ip-addr field of the SA.
If the fine-grained mask had not been used, three discrete SAs would have to be configured: one for each of the three
phones.
ORACLE(manual)# show
manual
name assoc1
spi 1516
network-interface lefty:0
local-ip-addr 100.20.50.7
remote-ip-addr 100.25.56.10
local-port 60035
remote-port 26555
trans-protocol ALL
ipsec-protocol esp
IPSec Configuration
The following example explains how to configure IPSec on your Oracle Communications Session Border Controller.
Note: If you change the phy-interface slot and port associated with any SAs or SPDs, the Oracle
Communications Session Border Controller must be rebooted for the changes to take effect.
10. local-ip-addr-match—Enter the source IP address to match. The default value is 0.0.0.0.
11. remote-ip-addr-match—Enter the destination IP address to match. The default value is 0.0.0.0.
12. local-port-match—Enter the source port to match. A value of 0 disables this selector. The default value is
zero (0). The valid range is:
• Minimum—0
• Maximum—65535
13. remote-port-match—Enter the destination port to match. A value of 0 disables this selector. The default
value is zero (0). The valid range is:
• Minimum—0
• Maximum—65535
14. trans-protocol-match—Enter the transport protocol to match. The default value is all. The valid values
are:
• UDP | TCP | ICMP | ALL
15. local-ip-mask—Enter the source IP address mask, in dotted-decimal notation. The default value is
255.255.255.255.
16. remote-ip-mask—Enter the remote IP address mask, in dotted-decimal notation. The default value is
255.255.255.255.
17. Save your work using the ACLI done command.
Configuring an IPSec SA
To configure an IPSec SA:
• Minimum—256
• Maximum—2302
9. ipsec-mode—Enter the IPSec mode of this SA. The default value is transport. The valid values are:
• tunnel | transport
10. auth-algo—Enter the IPSec authentication algorithm for this SA. The default value is null. The valid values
are:
• hmac-md5 | hmac-sha1 | null
11. auth-key—Enter the authentication key for the previously chosen authentication algorithm for this SA.
Note: The specified auth-key value will be encrypted in the configuration and will no longer be visible in
clear-text.
12. encr-algo—Enter the IPSec encryption algorithm for this SA. The default value is null. The valid values are:
• des | 3des | aes-128-cbc | aes-256-cbc | aes-128-ctr | aes-256-ctr | null
13. encr-key—Enter the encryption key for the previously chosen encryption algorithm for this SA.
Note: The specified encr-key value will be encrypted in the configuration and will no longer be visible in
clear-text.
14. aes-ctr-nonce—Enter the AES nonce if aes-128-ctr or aes-256-ctr were chosen as your encryption
algorithm. The default value is 0.
Key Generation
The generate-key command generates keys for the supported encryption or authentication algorithms supported
by the Oracle Communications Session Border Controller's IPSec implementation. The generate-key commands
generate random values which are not stored on the Oracle Communications Session Border Controller, but are only
displayed on the screen. This command is a convenient function for users who would like to randomly generate
encryption and authentication keys. The generate-key usage is as follows:
IDS Reporting
The Oracle Communications Session Border Controller supports a wide range of intrusion detection and protection
capabilities for vulnerability and attack profiles identified to date. The IDS reporting feature is useful for enterprise
customers requirement to report on intrusions and suspicious behavior that it currently monitors.
IDS Licensing
This feature requires the IDS Reporting license.
Note: The following capabilities and restrictions of the license:
• The following configuration parameters located in the access control and media manager
configuration elements are only visible after installing the license:
• trap-on-demote-to-deny
• syslog-on-demote-to-deny
• cac-failure-threshold
• untrust-cac-failure-threshold
• Endpoint demotions based on admission control failures are only a valid option with the IDS License.
• The presence of the IDS license makes the apSysMgmtInetAddrWithReasonDOSTrap trap available and the
apSysMgmtExpDOSTrap unavailable. WIthout an IDS licence installed, only the apSysMgmtExpDOSTrap trap is
available.
• The Trust->Untrust and Untrust-Deny counters in the SIP ACLs’ statistics are visible regardless of the
IDS license’s presence.
• The Demote Trust-Untrust and Demote Untrust-Deny collect records in the SIP ACL HDR groups
are visible regardless of the IDS license’s presence.
• A GET operation can be preformed on the two MIB entries to view the global endpoint counter for Demotions
from Trusted to Untrusted and from Untrusted to Deny regardless of the IDS license’s presence
• On Acme Packet 3820 systems, the DOS license must be installed in addition to the IDS license in order to enable
all features described in this section.
SNMP Reporting
These per-endpoint counters are available under APSYSMGMT-MIB -> acmepacketMgmt ->
apSystemManagementModule -> apSysMgmtMIBObjects -> apSysMgmtMIBGeneralObjects.
HDR Reporting
The SIP (sip-ACL-oper) HDR ACL status collection groups include the following two metrics:
• Demote Trust-Untrust (Global counter of endpoint demotion from trusted to untrusted queue)
• Demote Untrust-Deny (Global counter of endpoint demotion from untrusted to denied queue)
SNMP Reporting
Endpoint state transitions continue to be tracked by two counters available under APSYSMGMT-MIB ->
acmepacketMgmt -> apSystemManagementModule -> apSysMgmtMIBObjects -> apSysMgmtMIBGeneralObjects.
The sip-error HDR collection group contains a new reporting field, Call Rejects, which contains the value of the
global rejected calls counter.
The ACLI command show sipd errors displays the contents of the rejected calls counter.
ORACLE# show sipd errors
12:29:13-131
SIP Errors/Events ---- Lifetime ----
Recent Total PerMax
SDP Offer Errors 0 0 0
SDP Answer Errors 0 0 0
Drop Media Errors 0 0 0
Transaction Errors 0 0 0
Application Errors 0 0 0
Media Exp Events 0 0 0
Early Media Exps 0 0 0
Exp Media Drops 0 0 0
Expired Sessions 0 0 0
Multiple OK Drops 0 0 0
Multiple OK Terms 0 0 0
Media Failure Drops 0 0 0
Non-ACK 2xx Drops 0 0 0
Invalid Requests 0 5 2
Invalid Responses 0 0 0
Invalid Messages 0 0 0
CAC Session Drop 0 0 0
Nsep User Exceeded 0 0 0
Nsep SA Exceeded 0 0 0
CAC BW Drop 0 0 0
Calls Rejected 0 0 0 <--
Denied Endpoints
IDS Phase 2 provides a denied endpoint counter that includes SIP endpoints. The global counter value is available via
SNMP or HDR.
The global counter value is available to SNMP under APSYSMGMT-MIB -> acmepacketMgmt ->
apSystemManagementModule -> apSysMgmtMIBObjects -> apSysMgmtMIBGeneralObjects.
The system HDR collection group contains a new reporting field, Current Deny Entries Allocated, which contains the
value of the global endpoints denied counter.
Recommendations
Calls may be lawfully intercepted by different devices in the service provider's network based on specific call flows,
involvement of the device in the invoked service and where devices sit in the flow. Oracle recommends that you
contact our Professional Services department to plan your use of the lawful intercept feature on your Oracle
Communications Session Border Controller. Oracle Professional services can assist you with network/call flow
analysis to determine which types of calls will involve the Oracle Communications Session Border Controller as an
intercept access point and to recommend proper configuration.
Interoperability Using X1 X2 X3
This document describes how the Oracle Communications Session Border Controller supports X1, X2, and X3
interfaces for lawful interception of SIP calls. In this deployment, the Oracle Communications Session Border
Controller acts as an interception point that receives provisioning information from an administrative function and,
based on that information, provides call data and content. As with the other LI interoperability solutions that the
Oracle Communications Session Border Controller supports, the X1, X2, and X3 interfaces ensure unobtrusive call
intercept by hiding network-based intercept of call data and content. The Oracle Communications Session Border
Controller supports intercept of call data only, or of call data and call content.
Diameter Connection
The Oracle Communications Session Border Controller supports Diameter (RFC 3588) connections to a Diameter
server over TCP. The base Diameter protocol runs on TCP port 3868. Diameter-based RACF and CLF are available
from the media interfaces on the Oracle Communications Session Border Controller.
The Diameter connection is always initiated from the Oracle Communications Session Border Controller to the
Diameter server. The Oracle Communications Session Border Controller begins the connection by sending a
Capabilities-Exchange-Request (CER) to the server, which replies with Capabilities-Exchange-Answer (CEA)
message.
HA Support
The Oracle Communications Session Border Controller's high availability (HA) capabilities support CAC. When one
Oracle Communications Session Border Controller in an HA configuration goes out of service, the MAC addresses
are reassigned to a healthy Oracle Communications Session Border Controller. IP addresses follow the MAC
addresses to provide a seamless switchover between HA nodes.
After an HA failover, the Diameter connection on the primary Oracle Communications Session Border Controller is
either gracefully torn down, or times out depending on behavior of the PDP. The backup Oracle Communications
Session Border Controller attempts to create a new Diameter connection with the PDP.
FQDN Support
FQDNs are configured in the address parameter in the external policy server configuration element. These FQDNs
must conform to RFC 1035. If the port parameter in external policy server configuration element is not zero, then it
will be used to connect to the group of applicable external policy servers. If the port parameter is set to zero, then the
port number returned in SRV RR from the DNS server will be used. When the Oracle Communications Session
Border Controller queries a DNS server for an FQDN configured in the external policy server, it always appends the
_diameter._tcp. to request only TCP based Diameter servers.
IPv6 Support
An external policy server configuration element with an application mode parameter set to Rx may be configured
with an IPv6 address in the address parameter (in addition to an IPv4 address or FQDN).
Diameter Heartbeat
Device-Watchdog-Request (DWR) and Device-Watchdog-Answer (DWA)messages are used to detect transport
failures at the application layer between the Oracle Communications Session Border Controller communicating with a
policy server via Diameter. The request/answer message pair forms a heartbeat mechanism that can alert the
requesting side if the answering side is not reachable.
The Oracle Communications Session Border Controller always responds to a DWR by replying with a DWA message.
In addition, the Oracle Communications Session Border Controller can be configured to initiate DWR messages
toward a policy server or other Diameter-based network device.
You configure the watchdog ka timer with a timeout value that determines the number of seconds a DWA is
expected in response to the Oracle Communications Session Border Controller sending a DWR.
If the Oracle Communications Session Border Controller fails to receive a DWA response from a Policy Server within
the configured interval, then the connection towards that Policy Server is considered failed and torn down. The Oracle
Communications Session Border Controller attempts to recreate the TCP connection, followed by the recreating the
Diameter connection by issuing a CEA toward the policy server.
Diameter Failures
During periods of application inactivity on the Diameter interface, Device-Watchdog-Request (DWR) and Answer
(DWA) messages are exchanged between the client and server to provide an application-level heartbeat. DWRs may
be sent toward the Oracle Communications Session Border Controller, which responds with a DWA message.
Prior to establishing a connection, the system tries to connect to a configured Diameter server using the default TCP
retry interval of 10 seconds. This is also true if either side of the connection receives a TCP FIN or RST. The Oracle
Communications Session Border Controller labels a connection as failed when it does not receive a DWR from the
Diameter server within the guard timer period.
If an operational Diameter connection fails, the Oracle Communications Session Border Controller tries to re-open
the TCP socket and Diameter connection to the Diameter server at 30 second intervals, and increases its retry interval
to 5 minutes until a successful Diameter connection is made.
Reference Point/ Gq Rx Rq e2
Standards Body 3GPP R6 29.209 3GPP R7 29.214 ETSI 283 026 ETSI 283 035
You also set the application mode to specify the interface more precisely. Doing so avoids the potential for collision
between interface types that can occur when you only configure the application identifier. By setting both the
application mode and application identifier for the interface, you tell the Oracle Communications Session Border
Controller the format for Diameter messages it sends and receives.
The following table describes the application mode settings.
Rq As the default mode for the interface, Rq is the Oracle Communications Session
Border Controller’s base RACF interface. Even when you leave the application mode
set to none (default), the Oracle Communications Session Border Controller runs in
Rq mode. The only exception to this rule is if you set the application identifier to
16777236 and leave the application mode set to none; in this instance, the interface
runs in Rx mode.
Rx The interface runs in Rx mode when you either:
Set the application mode to Rx and the application identifier to 16777236
Leave the application mode set to none, and set the application identifier to 16777236
Gq The interface runs in Gq mode when you set the application mode to Gq.
Note: The application identifier 1677722 is no longer unique, but applies
both to Rq and Gq interface modes.
e2 The interface runs in e2 mode, the base CLF interface, when you set the application
mode to e2. Even if you leave the application mode set to none, the interface will run
in e2 mode when the external policy server is configured as a CLF interface.
none The interface runs in Rq mode when you do not configure an application identifier, or
in Rx mode if you set the application identifier to 16777236.
IPv6 Support
The Oracle Communications Session Border Controller supports Diameter-based CLF and RACF external policy
servers in both IPv4 and IPv6 networks. There are three areas of enhanced functionality where the Oracle
Communications Session Border Controller’s Diameter external policy server offerings have changed.
• AVP support of IPv6 addresses encoded in UTF-8 format
• Extra bandwidth allocation in policed flows to compensate for longer addresses
• Framed-IPv6-Prefix AVP (97) support
Framed-IPv6-Prefix AVP
The Oracle Communications Session Border Controller supports the Framed-IPv6-Prefix AVP (97) as defined in
RFC4005.
The Diameter interface on the Oracle Communications Session Border Controller substitutes this AVP for the
Framed-IP-Address AVP (8) in a Diameter message when carrying IPv6 addresses in the AVP.
The IP Address is encoded as Octet-String. Although the IPv6 address is a 128 bit number, it will not fall on a 4 byte
boundary due to the formatting of this particular AVP. Additional whitespace will be added per RFC 3588 to the end
of the octet-string to pad the ending of the AVP.
Diameter: RACF
As the Oracle Communications Session Border Controller proxies and forwards calls, caller media information is
known before the INVITE reaches the callee. The Oracle Communications Session Border Controller, acting as a P-
CSCF, requests a specific amount of bandwidth for a call, and the RACF can reserve this amount of bandwidth for a
call before the called phone rings. A call's required bandwidth can also be reserved by network devices along the path
from the caller to callee if the QoS admission criteria is pushed from the RACF to other edge nodes (PEPs) such as
routers, along this path to the callee.
Implementation Features
Bandwidth-based CAC is performed according to the following typical scenario. When the Oracle Communications
Session Border Controller, known as the Policy Enforcement Point (PEP), receives a SIP INVITE, it sends a
Diameter Authentication Authorization Request (AAR) message to the Policy Decision Point (PDP) or Resource and
Admission Control Function (RACF). The Oracle Communications Session Border Controller does not forward the
INVITE to its destination at this point.
The AAR message includes call identification information and the SDP-based bandwidth requirements for the call.
The RACF responds with a Diameter Authentication Authorization Answer (AAA) message to either the install or
remove the call. An install command directs the Oracle Communications Session Border Controller to forward the
INVITE to the next SIP device. A remove command directs the Oracle Communications Session Border Controller
send a SIP 503 Service Unavailable message sent back to the UA and reject the call.
When the RACF is unreachable, incoming calls are rejected by default with a 503 message, as bandwidth can not be
reserved. It is possible to configure the Oracle Communications Session Border Controller to allow all calls when the
RACF is unreachable if this is the desired behavior.
The Oracle Communications Session Border Controller can be configured so that both sides of a call, based on realm,
are subject to bandwidth enforcement. Each flow is treated as a unique call/event, because from a media and signaling
perspective, they are distinct. As the Oracle Communications Session Border Controller functions as one side of a
call, its IP address is inserted into the AAR message regardless of whether it is the calling or called party. This allows
for the Diameter install or remove decision to be made before the Oracle Communications Session Border Controller
receives the 200 OK response, and before ringing the far-end phone. Only one external policy server can be used
within a single realm.
When a call ends, either with the expected SIP BYE or CANCEL methods, or due to other error conditions, the
Oracle Communications Session Border Controller alerts the RACF by sending it a Diameter Session Termination
Request (STR) message. All ended calls must be deleted from the RACF in order to accurately track used and
available bandwidth.
The RACF can apply its hosted policies for calls originating at SIP UAs located behind NATs. This is a standard part
of the Oracle Communications Session Border Controller's ability to provide seamless HNT.
Bandwidth Negotiation
Because the decision whether to admit or reject a call is made before the INVITE is forwarded to the called party,
some information is not available to the PDP at the initial request. The final IP Address, UDP port number, that
transport the RTP flow, and the codec used are not known by the Oracle Communications Session Border Controller
until the called party responds with its own SDP information (either in the 180 or 200 response).
The Oracle Communications Session Border Controller examines the Session Description Protocol (SDP) value in the
body of the SIP INVITE to determine what codecs are available for the call. If the INVITE specifies more than one
codec, the Oracle Communications Session Border Controller bases its request to the RACF on the most bandwidth-
hungry codec to ensure that all bandwidth requests will succeed or fail on the first attempt.
Note: The amount of bandwidth requested depends on the configured media profiles.
If the call is admitted, and when the called party returns finalized SDP information, the Oracle Communications
Session Border Controller modifies the original reservation with the chosen codec's bandwidth requirements. This
ensures the RACF has current and accurate information with which to make policy decisions.
Session Lifetime
When receiving a successful Diameter response message for bandwidth from the RACF, a session lifetime timer may
be included in the message. If included, this timer states how long the session can last. If the session continues past
3/4 of session lifetime, the Oracle Communications Session Border Controller sends another bandwidth request for
that session to ultimately refresh the lifetime timer. If the RACF grants this bandwidth request, the Oracle
Communications Session Border Controller continues to allow the session to proceed uninterrupted. If a lifetime
timer for a session is not returned to the Oracle Communications Session Border Controller by the RACF, the Oracle
Communications Session Border Controller assumes the session can last forever and never issues a refresh in this
manner.
RACF-only AVPs
Diameter AAR Query Post SDP Exchange
The Oracle Communications Session Border Controller supports sending the Authentication-Authorize-Request
(AAR) query upon SDP answer instead of the SDP offer. This change can useful in WiMax environments where
mobile phones go idle and become semi-detached from their base stations and from the WiMax access controller
(WAC). In such a case, the WAC receives an AAR from the idle user but, because it cannot determine that user’s base
station, rejects the request.
You enable this behavior by setting the reserve-incomplete parameter to orig-realm-only.
Transport-Class AVP
When the Oracle Communications Session Border Controller, running as a Diameter-based RACF, receives a SIP
INVITE triggering external bandwidth management, the Oracle Communications Session Border Controller performs
SDP stripping and—through internal processes—selects an external bandwidth manager to use. If the options
parameter in the selected external bandwidth manager is set to transport-class, the Oracle Communications Session
Border Controller’s Diameter RACF interface will issue authentication authorization requests (AARs) with the
transport class AVP. The Oracle Communications Session Border Controller does not insert the transport-class AVP
messages when the option is not configured.
The transport-class AVP will:
• Be identified with the AVP code 311
• Always have the vendor (V) bit set in the AVP flags
• Never have the mandatory (M) bit set in the AVP flags
• Have the Vendor-Id field set to 13019 (a value specified by ETSI TISPAN)
• Be formatted as an unsigned integer
• Reside in the Media-Component AVP, a grouped AVP
In addition, the transport-class AVP’s payload field will be a 32-bit unsigned integer corresponding to a specific
media type. The Oracle Communications Session Border Controller learns the specific media type from the m-line of
the SDP it received. The following table shows how the Oracle Communications Session Border Controller evaluates
the SDP’s m= lines and concludes a default service type classification.
After the service class classification has been chosen, the Oracle Communications Session Border Controller inserts
the corresponding default transport class value in the transport-class AVP to send to the RACF.
The Oracle Communications Session Border Controller can be configured with an option, include-gua , to retain
the previous behavior of sending an incoming SIP message’s realm to a policy server. This is accomplished by
sending the Globally Unique AVP in the AAR message to the policy server, by adding an option parameter to the
external policy server configuration.
The following table summarizes the effect of provisioning the external policy server with the Globally Unique AVP
option on each Diameter interface, as configured.
Rq AAR sends Globally Unique Address AVP AAR sends Globally Unique Address AVP
Rx AAR does not send Globally Unique Address AAR will contain Globally Unique Address
AVP AVP
Gq AAR does not send Globally Unique Address AAR will contain Globally Unique Address
AVP AVP
E2 AAR sends Globally Unique Address AVP AAR sends Globally Unique Address AVP
Format Description
<user>@<realm> <user>—IP address of the endpoint initiating the call with the Oracle Communications
Session Border Controller
<realm>—Name of the realm on which the Oracle Communications Session Border
Controllerreceived the INVITE from a user
<user> <user>—IP address of the endpoint initiating the call with the Oracle Communications
Session Border Controller
<realm> <realm>—Name of the realm on which the Oracle Communications Session Border
Controller received the INVITE from a user
When either the Diameter CLF or RACF interface sends any message with the Destination-Realm AVP, it determines
from the external policy server configuration how to construct the payload string for this AVP.
You can set the format to use in the dest-realm-format parameter in the external policy server configuration.
The parameter can be set to any value in the table above and defaults to <user>@<realm>. By treating the format this
way, the policy server and the Oracle Communications Session Border Controller can easily communicate this value;
if sent to the policy server in any AVP, the policy server can simply return the full value.
Origin-Host AVP
The Diameter CLF and RACF interfaces can change the suffix for Origin-Realm and Origin-Host AVPs that have a
payload string constructed as a domain name.
You can set the suffix you want appended to payload strings using the domain-name-suffix parameter in the
external policy server configuration. This parameter can be set to any string (default is .com), and the Oracle
Communications Session Border Controller automatically adds a dot (.) to the front of this entry if you do not include
one. The policy server and the Oracle Communications Session Border Controllercan easily communicate this value;
if sent to the policy server in any AVP, the policy server can simply return the full value.
When you enable the wildcard-transport-protocol parameter, however, you can essentially format the
Flow-Description AVP to suit your network.
For sessions that need to allocate media and have applicable external bandwidth management associations, the Oracle
Communications Session Border Controller’s Diameter interface checks for the necessary bandwidth. The Diameter
interface, with an Rx or Rq application mode, constructs an AAR with Flow-Description AVP of ip when the
wildcard-transport-protocol parameter is enabled. The flow description would look like this:
<Flow-Description-AVP(507) | Avp Flags=128 | AVP Length=72 | Vendor-Id=10415
Data = permit out ip from 168.192.24.20 49500 to 168.192.24.0 8000
<Flow-Description-AVP(507) | Avp Flags=128 | AVP Length=72 | Vendor-Id=10415
Data = permit in ip from 168.192.24.0 8000 to 168.192.24.20 49500
With the wildcard-transport-protocol set to disabled, the Oracle Communications Session Border
Controller does not use the ip wildcard keyword. Instead, it uses the specific media stream transport protocol in the
Flow-Description AVP—and only falls by to the ip keyword when the transport protocol is unknown. The flow
description with this parameter disabled would look like this:
<Flow-Description-AVP(507) | Avp Flags=128 | AVP Length=72 | Vendor-Id=10415
Data = permit out 17 from 168.192.24.20 49500 to 168.192.24.0 8000
<Flow-Description-AVP(507) | Avp Flags=128 | AVP Length=72 | Vendor-Id=10415
Data = permit in 17 from 168.192.24.0 8000 to 168.192.24.20 49500
9. port—Enter the port number the diameter connection connects to on the RACF. The default value is 80. The
valid range is:
• Minimum—0
• Maximum—65535
10. realm—Enter the name of the Realm in which this Oracle Communications Session Border Controller defines
the RACF to exist. This is NOT necessarily the Realm where the Oracle Communications Session Border
Controller performs admission control.
11. permit-conn-down—Enter enabled if this external policy server configuration can permit new calls into
the network when the policy server connection is down. The default value is disabled. The valid values are:
12. product-name—Enter text string that describes the vendor-assigned name for the RACF. This parameter is
required.
13. application-mode—Enter the type of interface you want to use. Your choices are: Rq, Rx, Gq, e2, and
none.
14. application-id—Enter a numeric application ID that describes the interface used to communicate with the
RACF. The default value is zero (0). The valid range is:
• Minimum—0
• Maximum—999999999
15. framed-ip-addr-encoding—Enter the format of the Frame-IP-Address (AVP 8) value in Diameter
messages. The default value is octet-string. The valid values are:
• ascii-string—Example: 192.168.10.1
• octet-string—Example: 0xC0A80A01
16. dest-realm-format—Enter the format you want to use for the Destination-Realm AVP. The default value is
user_with_realm. The valid values are:
• user_with_realm | user_only | realm_only
17. domain-name-suffix—Enter the suffix you want to use for Origin-Realm and Origin-Host AVPs that have a
payload string constructed as a domain name Your value can be any string, to which the system will prepend with
a dot if you do not include one. The default value is .com.
18. allow-srv-proxy—Set to enabled in order to include the proxy bit in the header. The presence of the proxy
bit allows the Oracle Communications Session Border Controller to tell the external policy server whether it wants
the main server to handle the Diameter message, or if it is okay to proxy it to another server on the network
(disabled). The default is enabled. The valid values are:
• enabled | disabled
19. wildcard-trans-protocol—Set this parameter from enabled if you want to use transport protocol
wildcarding for Rx/Rq Flow-Description AVP (507) generation. Enabled sends a flow description of ip. Set this
parameter to disabled if you want to use the specific media stream transport protocol.
20. reserve-incomplete—Set this parameter to enabled when communicating with a PDP via Diameter. The
parameter allows the Oracle Communications Session Border Controller to make admission requests before
learning all the details of the flows and devices (e.g., not knowing the final UDP port numbers for the RTP media
streams until after the RTP has begun). The default value is enabled. The valid values are:
• enabled (default)—This mode supports the usual behavior when the AAR is sent upon SDP offer as well as
SDP answer. This mode ensures backwards compatibility.
• orig-realm-only—This mode allows calls originating from a realm with a policy server associated with
it to send the AAR upon SDP offer. However, calls terminating at a realm with a policy server associated with
it send the AAR post SDP exchange.
• disabled—This mode allows no bandwidth reservation for incomplete flows.
21. include-rtcp-in-request—Change this parameter from disabled (default), to enabled so the
Oracle Communications Session Border Controller will include RTCP information in AARs. RTCP information is
the number of the RTP port plus one (RTP port + 1 = RTCP ports) for all sessions.
22. trans-expires—Set the amount of time, in seconds, that the Oracle Communications Session Border
Controller waits before performing an expiration if a Diameter base protocol transaction does not occur. The
default value is 15 seconds. Valid values range between 1 and 15.
23. Save your work using the ACLI done command.
CAC Debugging
A new argument has been added to the show command for viewing CAC statistics. From the user prompt, type show
ext-band-mgr.
ORACLE# show ext-band-mgr
10:11:38-194
EBM Status -- Period -- -------- Lifetime --------
Active High Total Total PerMax High
Client Trans 0 0 0 0 0 0
Server Trans 0 0 0 0 0 0
Sockets 1 1 1 1 1 1
Connections 0 0 0 0 0 0
---- Lifetime ----
Recent Total PerMax
Reserve 0 0 0
Modify 0 0 0
Commit 0 0 0
Remove 0 0 0
EBM Requests 0 0 0
EBM Installs 0 0 0
EBM Errors 0 0 0
EBM Rejects 0 0 0
Subscription-ID AVP
The Subscription-Id AVP (AVP Code 443) includes a Subscription-Id-Data AVP that holds the identifier and a
Subscription-Id-Type AVP that defines the identifier type. The external policy server configuration element is
configured with an option to enable sending the Subscription-Id AVP to the policy server in an AA-Request (AAR)
message.
Subscription-Id-Type
The Oracle Communications Session Border Controller can send a Subscription-Id-Types AVP to an external policy
server:
To send the Subscription-ID-Types AVP in an AAR, you must add the include-sub-info option in the external policy
server configuration element. If this option is enabled, and you do not configure a subscription-id-type in
the realm-config, the request line’s Request URI of the received message is sent in the AAR.
You can also set the Subscription-ID-Type on a per-realm basis by configuring the parameter subscription-id-
type in the realm-config element to determine the value of the Subscription ID in the AAR.
The default value for subscription-id-type is END_USER_NONE. If the value of subscription-id-type is set
to END_USER_NONE, and the external policy server option is enabled to send the Subscription ID AVP, then the
Oracle Communications Session Border Controller relies on the request line’s Request URI of the received message.
If the value for subscription-id-type is set to one format, such as END_USER_IMSI, but the request line’s
Request URI is set to another format, such as END_USER_SIP_URI, the value of subscription-id-type is
used to send in the AAR message.
• RECOVERY OF BEARER
• RELEASE OF BEARER
• OUT OF CREDIT
• SUCCESSFUL RESOURCES ALLOCATION
• FAILED RESOURCES ALLOCATION
When no subscription types are configured, the Oracle Communications Session Border Controller does not include
the Specific-Action AVP in its AAR.
Specific Action AVP subscription is configured in the Specific action subscription parameter located in
the External policy server configuration element.
selection: 1
ACMEPACKET(ext-policy-server)#
3. specific-action-subscription - Configure 1 or more specific actions. When configuring 2 or more specific actions,
enclose them in quotation marks, with the values separated by spaces. The following are valid specific actions:
loss-of-bearer, recovery-of-bearer, release-of-bearer, out-of-credit, successful-resources-allocation, failed-
resources-allocation
ACMEPACKET(ext-policy-server)# specific-action-subscription "loss-of-bearer
recovery-of-bearer"
4. Type done to save your work.
5. Save and activate your configuration to begin using this feature.
Gq Interface Features
The Oracle Communications Session Border Controller can run the Gq interface over a Diameter connection and act
as a P-CSCF (AF) communicating with a PDF. The application ID field must be set to 16777222 to run the Gq
reference point.
Rx Interface Features
The Oracle Communications Session Border Controller can run the Rx interface over a Diameter connection and act
as a P-CSCF communicating with a PCRF. The application ID field must be set to 16777236 to run the Rx reference
point. When running in this mode, the Oracle Communications Session Border Controller will send two AVPs, in
addition to other information:
• The Codec-Data AVP is then included for non-priority calls. This AVP is one of several that together comprise a
Group AVP structure.
• The Reservation-Priority AVP is included for priority calls. This AVP will be the main AVP within the AAR
message.
Line 1 Must specify the direction of the flow by including the ASCII “uplink” or downlink:
uplink—Identifies the SDP as having come from the UE and sent to the network
downlink—Identifies the SDP as having come from the network and sent to the UE
Line 2 Must specify whether the offer or answer codec is at issue by including the ASCII “offer”
(from an SDP offer according to RFC 3264) or answer (from an answer according to RFC
3264)
Remainder of the AVP Must include lines found in the signaling SDP, formatted in ASCII and separated by new-
line characters; the first line of this section must be the m line, followed by any “a” or “b”
lines related to that m line
• INDICATION_OF_FAILED_RESOURCES
AA-Request (AAR) messages are sent, via the Rx Interface, by an Access Function (AF) to a Policy and Charging
Rules Function (PCRF) in order to provide it with the session information. Among other fields, these messages
contain a Media-Component-Number AVP and a Flow-Number AVP, used to identify specific media sessions, and the
individual IP flows associated with these sessions.
The values assigned to the Media-Component-Number and Flow-Number AVPs are not derived in compliance with
3GPP standards.
Release S-CZ7.2.0 provides a new option that enables compliance with 3GPP requirements. Note that this support is
limited to the Rx Interface
Media-Component-Number AVP
The Media-Component-Number AVP (AVP code 518) is of type Unsigned32; it contains the ordinal number of the
media component (the SDP m= line) as specified in 3GPP TS 29.214. When this AVP refers to AF signalling, it
contains the value 0. The Media-Component-Number AVP provides an index to the grouped Media-Component-
Description AVP (AVP code 517).
3GPP compliance requires that:
1. Number should start from 1
2. It should contain the ordinal number of the position of the m= line in the SDP.
3. When this AVP refers to AF Signalling, this is indicated by using the value 0.
4. The ordinal number of a media component shall not be changed when the session description information is
modified.
Flow-Number AVP
The Flow-Number AVP (AVP code 509) is of type Unsigned32; it contains the ordinal of the IP flows created to
support a specific SDP m= line as specified in 3GPP TS 29.214. The Flow-Number AVP provides an index to the
grouped Media-Sub-Component AVP (AVP code 519).
3GPP compliance requires that:
1. Number should start from 1
2. It should contain the ordinal number of the IP flow(s) within the m= line assigned in the order of increasing
downlink destination port numbers, if downlink destination port numbers are available.
3. It should contain the ordinal number of the IP flow(s) within the m= line assigned in the order of increasing uplink
destination port numbers, if no downlink destination port numbers are available.
4. The ordinal number assigned should not be changed when the session description information is modified.
Flow Examples
The following example illustrates the derivation of flow identifiers from SDP as specified by 3GPP TS 29.214 3rd
Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging
Control over Rx reference point (Version 9.3.0).
A flow identifier consists of two digits in the form #,# with the digit identifying a specific SDP m= line (defining a
media session), and the second digit identifying a specific IP flow (for example, an RTP stream) supporting the media
session. 3GPP standards require that the Media-Component-Number AVP be populated with the first digit if the flow
identifier and the Flow-Number AVP be polulated with the second digit.
A UE, as the offerer, sends a SDP session description (relevant sections shown below) to an application server.
v=0
o=ecsreid 3262464865 3262464868 IN IP6 2001:0646:00F1:0045:02D0:59FF:FE14:F33A
s=MM01
Order of m= line Type of IP Flows Destination IP Address/Port Number of Flows Flow Identifier
1 RTP (Video) DL 2001:0646:00F1:0045:02D0:59FF:FE14:F33A / 50230 <1,1>
1 RTCP DL 2001:0646:00F1:0045:02D0:59FF:FE14:F33A / 50231 <1,2>
1 RTCP UL 2001:0646:000A:03A7:02D0:59FF:FE40:2014 / 51373 <1,2>
2 RTP (Audio) UL 2001:0646:000A:03A7:02D0:59FF:FE40:2014 / 49170 <2,1>
2 RTCP DL 2001:0646:00F1:0045:02D0:59FF:FE14:F33A / 50331 <2,2>
2 RTCP UL 2001:0646:000A:03A7:02D0:59FF:FE40:2014 / 49171 <2,2>
3 UDP (application) DL 2001:0646:00F1:0045:02D0:59FF:FE14:F33A / 50430 <3,1>
3 UDP (application) UL 2001:0646:000A:03A7:0250:DAFF:FE0E:C6F2 / 32416 <3,1>
selection: 1
ORACLE(ext-policy-server)#
3. format-flow-id—Add this option to enable 3GPP compliance.
ACMEPACKET(ext-policy-server)# options +format-flow-id
4. Type done to save your configuration.
Specific-Action AVP
The Specific-Action AVP (AVP code 513) is of type Enumerated.
Within a PCRF initiated Re-Authorization Request, the Specific-Action AVP determines the type of the action.
The following reported disconnected events can be mapped to SIP Reason headers using the corresponding value to
configure in a local-response-map-entry > local-error.
Abort-Action AVP
The Specific-Action AVP (AVP code 500) is of type Enumerated.
Within a PCRF initiated Abort Session Request (ASR), the Abort-Cause AVP identifies the cause of the ASR.
The following reported disconnected events can be mapped to SIP Reason headers using the corresponding value to
configure in a local-response-map-entry > local-error.
Message Flows
Mapped headers will appear in either a BYE or a CANCEL message from the P-CSCF. As shown in the following
illustrations, a BYE message is issued when the disconnect event occurs after establishing the SIP session. A
CANCEL message is issued when the disconnect event occurs before establishing the SIP session.
Basic Implementation
Basic Phase 1 NPLI support is provided with Version S-CZ7.2.0.
While implementation details and the granularity of provided services differ among IMS providers, Phase 1 NPLI
implementation triggered by an originating mobile device typically involves a message exchange similar to the
following.
1. Upon receiving the initial INVITE from the mobile handset, the P-CSCF sends an AA-Request (AAR) command
to the Policy Charging/Rule Function (PCRF) via the Rx interface.
2. The P-CSCF buffers the INVITE pending the receipt of an AA-Answer (AAA) command from the PCRF.
Assuming NPLI is provided by the IMS core, the AAA contains a 3GPP-User-Location-Info Attribute Value Pair
(AVP) along with a RAT-Type AVP. Depending upon network equipment, the AAA may also contain a proprietary
MSISDN (Mobile Subscriber Integrated Services Digital Network Number), AVP although this is not usually the
case.
3. Upon receiving the AAA, the P-CSCF, using values contained in the 3GPPUser-Location-Info attribute, and the
RAT-Type attribute, adds an abbreviated P-Access-Network-Info (PANI) header to the buffered INVITE. If an
MSISDN is included within the AAA, the P-CSCF also adds a P-Subscription-MSISDN header to the buffered
INVITE.
4. The P-CSCF caches received attribute values, and forwards the altered INVITE to the IMS core.
5. All subsequent re-INVITES and UPDATES contain the PANI and P-Subscription-MSISDN headers populated
with the cached values.
NPLI provisioning triggered by a terminating mobile device typically involves a message exchange similar to the
following.
1. Upon receiving the initial INVITE from the IMS core, the P-CSCF sends an AAR command to the PCRF via the
Rx interface.
2. The P-CSCF buffers the INVITE pending the receipt of an AAA command from the PCRF. Assuming NPLI is
provided by the IMS core, the AAA contains the 3GPP-User-Location-Info and RAT-Type AVPs. Depending upon
network equipment, the AAA may also contain a proprietary MSISDN AVP although this is not usually the case.
3. Upon receiving the AAA, the P-CSCF, using values contained in the 3GPPUser-Location-Info attribute, and RAT-
Type attributes, adds a PANI header to the buffered INVITE. If an MSISDN is included within the AAA, the P-
CSCF also adds a P-Subscription-MSISDN to the buffered INVITE.
4. The P-CSCF caches received attribute and MSISDN values, and forwards the altered INVITE to the mobile
handset.
5. All subsequent 1xx and 200OK, and all subsequent re-INVITES and UPDATES that are generated by the mobile
handset contain the PANI and P-Subscription-MSISDN headers populated with the cached values.
Enhanced Implementation
Enhanced Phase 2 NPLI support is provided by Version S-CZ7.2.0, and later releases. Phase 2 provides for an explicit
subscription to NPLI changes resulting in the dynamic update of NPLI as opposed to the single static transaction
provided by the initial Phase 1.
Phase 2 NPLI implementation triggered by an originating mobile device typically involves a message exchange
similar to the following.
1. Upon receiving the initial INVITE from the mobile handset, the P-CSCF sends an AAR command to the PCRF
via the Rx Interface. This AAR contains a Required-Access-Info AVP that requests user location reports as they
become available to the PCRF.
2. The P-CSCF buffers the INVITE pending the receipt of an AAA command from the PCRF. The AAA contains a
3GPP-User-Location-Info AVP along with a RAT-Type AVP. Depending upon network design, the AAA may also
contain a proprietary MSISDN AVP, although this is not usually the case.
3. Upon receiving the AAA, the P-CSCF, using values contained in the 3GPP-User-Location-Info attribute, and the
RAT-Type attribute, adds an extended PANI header to the buffered INVITE. If an MSISDN is included within the
AAA, the P-CSCF also adds a P-Subscription-MSISDN header to the buffered INVITE.
4. The P-CSCF caches received attribute values, and forwards the altered INVITE to the IMS core.
5. At any point during the call (from initial session establishment to session termination) the PCRF can send a Re-
Auth Request (RAR) that contains updated NPLI conveyed by the 3GPP-User-Location-Info, RAT-Type, IP-CAN-
Type, or MSISDN AVPs.
6. After receiving the RAR, the P-CSCF updates the cached attribute values.
7. All subsequent re-INVITES and UPDATES contain the PANI and P-Subscription-MSISDN headers populated
with the most recent cache values.
The following call flow depicts a successful, mobile-originated call containing a Re-INVITE. NPLI updates are
requested in the initial AAR (P-CSCF-to-PCRF). NPLI is first provided with the initial AAA (PCRF-to-P-CSCF).
Updated NPLI is provided with the initial RAR (PCRF-to-P-CSCF). All requests/responses toward the IMS core
contain the latest available NPLI.
3GPP-User-Location-Info Attribute
Phase I Implementation
The 3GPP-User-Location-Info Attribute (sub-attribute number 22) is defined in section 16.4.7.2, Coding 3GPP
Vendor-Specific RADIUS attributes, of 3GPP TS29.061, Interworking between the Public Land Mobile Network
(PLMN) supporting packet based services and Packet Data Networks (PDN). This AVP contains the location type, for
example a cell global identifier (CGI), and the actual location data for the specified cell.
Phase II Implementation
The 3GPP-User-Location-Info AVP (type 22) is defined in section 16.4.7.2, Coding 3GPP Vendor-Specific RADIUS
attributes, of 3GPP TS29.061, Interworking between the Public Land Mobile Network (PLMN) supporting packet
based services and Packet Data Networks (PDN).
3GPP-User-Location-Info contains the location type, for example a cell global identifier (CGI), and the actual
location data for the specified cell.
This attribute is supported by both the Phase 1 and Phase 2 implementations. It occurs in AAR and RAR messages
received by the P-CSCF.
The AVP consists of four fields.
The 1-octet 3GPP-type field contains the value 22.
The 1-octet 3GPP-length field contains the attribute length in octets.
The 1-octet Geographic Location Type field identifies the equipment type whose location is being provided.
0 = CGI
1 = SAI
2 = RAI
128 = TAI
129 = ECGI
130 = TAI and ECGI
Other values are reserved for future use.
The variable length Geographic Location field contains the geographic coordinates of the equipment specified in the
Geographic Location Type field.
MSISDN AVP
The Vodafone proprietary MSISDN AVP is supported in both NPLI Phases 1 (Release S-CZ7.1.2) and 2 (Release s-
CZ7.2.0 and later).
This attribute can be found in AAR and RAR messages received by the P-CSCF. It is constructed as follows.
<Name>MSISDN-VF:21274</Name>
<AvpName>MSISDN-VF</AvpName>
<AvpCode>3701</AvpCode>
RAT-Type Attribute
Phase I Implementation
The RAT-Type Attribute (attribute type 1032) specifies the radio access technology type. For purposes of NPLI, the
following values are supported:
• 1000 — Universal Terrestrial Radio Access Network (UTRAN)
• 1001 — SMS Edge Radio Access Network (GERAN)
• 1004 — Evolved UMTS Radio Access Network (EUTRAN)
In the event that a received RAT-Type attribute contains an unsupported type (something other that 1000, 1001, or
1004), an error condition is declared and the default PANI is used.
Phase II Implementation
This attribute is supported by both the Phase 1 and Phase 2 implementations.
It occurs in AAR and RAR messages received by the P-CSCF.
The following values are supported.
0 - WLAN
1 - Virtual (indicates that RAT is unknown)
1000 — Universal Terrestrial Radio Access Network (UTRAN)
1001 — GSM Edge Radio Access Network (GERAN)
1002 - GAN (Generic Access Network)
1003 - HSPA_EVOLUTION (Evolved High Speed Packet Access)
1004 — Evolved UMTS Radio Access Network (EUTRAN)
2000 - CDMA2000_1X (core CDMA2000 wireless air interface)
2001 - HRPD (High Rate Packet Data)
2002 - UMB (Ultra Mobile Broadband)
2003 - EHRPD (Enhanced High Rate Packet Data)
In the event that a received RAT-Type attribute contains an unsupported type, an error condition is declared and the
default PANI is used.
ACMEPACKET(ext-policy-server)#
3. Use the specific-action-subscription parameter to specify one or more specific actions. When
designating 2 or more actions, enclose them in quotation marks, with the values separated by spaces. Use
access-network-info-report to enable NPLI support.
ACMEPACKET(ext-policy-server)# specific-action-subscription
access-network-info-report
ACMEPACKET(ext-policy-server)#
4. Use done, exit and verify-config to complete configuration.
location information (if available, and if configured to do so). If location information is unavailable, the P-CSCF
forwards the INVITE without a PANI header.
Use the following procedure to configure a hold-timer that specifies the time (in seconds) that emergency INVITES
are buffered while waiting for NPLI from the PCRF. Such a timer ensures compliance with BNetzA regulations.
Users who are not subject to BNetzA authority can choose to implement a minimum timer value, which provides the
network some period of time to report possibly more accurate location information.
Caveats
Within environments that provide NPLI support:
• reserve-incomplete (ext-policy-srv mode) — set to enabled
• optimize-aar (ext-policy-srv mode) — set to disable
Rf Interface Features
Node-Functionality AVP Support
The Oracle Communications Session Border Controller sends the Node-Functionality (862) AVP in all Rf ACR
messages.
The Node-Functionality AVP indicates the function that the message’s source plays in the network. The CDF/CGF
function that collects the ACR messages can use the information in the Node Functionality AVP for billing or analysis
purposes.
In an IMS network, theOracle Communications Session Border Controller may perform the following functions: P-
CSCF, E-CSCF, IBCF, BGCF (when configured as an Oracle Communications Session Router). In fact, the system
might perform different roles simultaneously, so that on a call-by-call basis, the value in the Node-Functionality might
change.
To accurately reflect multiple, simultaneous functions that the Oracle Communications Session Border Controller
performs, the value inserted into the Node-Functionality AVP may be defined per realm. The node functionality value
for a call’s ACR is taken from the configuration in the ingress realm. Each realm may only be marked with a single
Node Functionality value.
The system can still be configured with a single, global Node Functionality value. This is done in the SIP config’s
node functionality parameter. When configured, all system-generated ACRs include this value. However, if the node
functionality parameter is also configured in a realm config, the ingress realm’s node functionality value supersedes
the global value.
The node-functionality in the realm-config may be configured with an empty string (). This indicates that this realm
should revert to the global node-functionality value.
3. node-functionality — Enter a global value to insert into the Node-Functionality AVP when the system
sends ACRs over the Rf interface to an appropriate destination. The default is P-CSCF. Valid values are:
• P-CSCF
• BGCF
• IBCF
• E-CSCF
4. Save and activate your configuration.
• the originating INVITE does not contain a proxy-authorization header, except for INVITE messages coming from
IMS AKA users
• the codec & bandwidth provided in the m-line of an SDP response, and media IP address and port have not
changed since the last SDP message
• In the MTC scenario, AAR is suppressed on reception of the originating non-IMS-AKA INVITE with no NPLI
configured
IMS
UE P-CSCF PCRF
Core
INVITE
Proxy-Authentication Header
m=audio [media_port] RTP/AVP 0
Diameter AAA
INVITE
Proxy-Authentication Header
m=audio [media_port] RTP/AVP 0
183
m=audio [media_port] RTP/AVP 0
183 a=sendonly
m=audio [media_port] RTP/AVP 0
a=sendonly NO AAR SENT
PRACK
PRACK
200 (PRACK)
200 (PRACK)
200 INVITE
200 INVITE
The Oracle Communications Session Border Controller can be configured to allow the generation of an AAR in these
cases by adding the optimized-aar=supplementary-service option to the ext-policy-server configuration element.
(You may also configure the option as optimized-aar= supplementry resulting in identical behavior.) The following
call flow reflects this optimized behavior.
IMS
UE P-CSCF PCRF
Core
INVITE
Proxy-Authentication Header
m=audio [media_port] RTP/AVP 0
Diameter AAA
INVITE
Proxy-Authentication Header
m=audio [media_port] RTP/AVP 0
183
m=audio [media_port] RTP/AVP 0
a=sendonly
Diameter AAR
183
m=audio [media_port] RTP/AVP 0 Diameter AAA
a=sendonly
PRACK
PRACK
200 (PRACK)
200 (PRACK)
200 INVITE
200 INVITE
selection: 1
ORACLE(ext-policy-server)#
3. optimize-aar—Set this parameter to enabled to optimize the use of AAR messages.
4. reserve-incomplete—Set this parameter to enabled in conjunction with optimize-aar set to enabled for the
system to not send an AAR to the PCRF if the Proxy-authorization header is absent from the INVITE.
5. Type done to save your configuration.
selection: 1
ORACLE(ext-policy-server)#
3. options—Set the options parameter by typing options, a space, +optimized-aar=supplementary-service to
generate an AAR when a reINVITE or UPDATE contains SDP that changes an a=sendonly |recvonly | inactive
parameter.
ORACLE(ext-policy-server)# options +optimized-aar=supplementary-service
Note: You may also configure the option as optimized-aar=supplementry resulting in identical behavior.
If this option is not configured and optimize-aar is enabled, changes to these SDP parameters will not generate an
AAR.
4. Type done to save your configuration.
Examples
Example 1:
Example 2:
Example 3:
Example 4:
Example 5:
Example 6:
• P-Assured-Service
• P-Preferred-Service
• Accept-Contact
If none of the above three headers are present, the default value of AF-Application-Identifier shall be used.
If the Oracle Communications Session Border Controller is not configured to send an AAR on receipt of an INVITE,
the value from the 3 headers will be cached for later AF-Application-Identifier generation.
Example 2:
Example 3:
Example 4:
Example 5:
Example 6:
Diameter: CLF
The Oracle Communications Session Border Controller supports the e2 interface over a Diameter connection acting
as a P-CSCF communicating with a CLF. The application ID field must be set to 16777231 to run the e2 reference
point.
A Connectivity Location Function (CLF) maintains mappings between endpoints with dynamically assigned IP
addresses and their physical location. The Oracle Communications Session Border Controller, acting as a P-CSCF, is
the intermediary device between a registering endpoint and a CLF. The CLF thus validates and tags a registering
endpoint, and the Oracle Communications Session Border Controller applies the CLF's actions.
CLF Behavior
The Oracle Communications Session Border Controller and a CLF only interact with each other when an endpoint
registers or re-registers. The Oracle Communications Session Border Controller, acting as the P-CSCF, is the first SIP
device that the REGISTER message reaches. Upon receiving the REGISTER message(1), the Oracle
Communications Session Border Controller queries the CLF using the Diameter protocol. The endpoint's (public) IP
address and port, and the Oracle Communications Session Border Controller's IP information are sent to the CLF in a
Diameter User-Data-Request (UDR) message(2).
The CLF responds to the Oracle Communications Session Border Controller with a Diameter User-Data-Answer
(UDA) message(3). If the request is approved, then the CLF also sends a location-string value to be inserted in one of
the SIP headers. The Oracle Communications Session Border Controller inserts a P-Access-Network-Info header
containing the location-string into the incoming REGISTER message and forwards this message(4) to the SIP
registrar/I/S-CSCF.
The Oracle Communications Session Border Controller inserts this P-Access-Network-Info header into all subsequent
SIP messages from this endpoint as they are forwarded into the core network. The P-Access-Network-Info header is
inserted into all SIP requests and responses except for ACK and CANCEL messages. For all boundaries where SIP
messages pass from trusted to untrusted SIP interfaces or session agents, the Oracle Communications Session Border
Controller will strip out the P-Access-Network-Info header as expected.
If the CLF responds with a Reject UDA message, the Oracle Communications Session Border Controller rejects the
registration, and sends a 503 - Service Unavailable message back to the registering endpoint. In this way, the CLF can
be used for admission control.
The Oracle Communications Session Border Controller communicates with the CLF solely for retrieving location
information from the CLF, and not for notifying the CLF about an endpoint's registration state or activity. When an
endpoint's registration ends, either through a normal expiration, getting rejected by the registrar, or through specific
de-registering or error conditions, the Oracle Communications Session Border Controller deletes the locally cached
registration location string. The Oracle Communications Session Border Controller does not inform the CLF about
any registrations that have been deleted.
1. If the CLF returns an Accept UDA message with a location string, the Oracle Communications Session Border
Controller inserts the location string into a P-Access-Network-Info header in the outgoing REGISTER message.
2. If the CLF returns an Accept UDA message without a location string, the Oracle Communications Session Border
Controller inserts the configured default string into a P-Access-Network-Info header in the outgoing REGISTER
message.
3. If the CLF returns an Accept UDA message without a location string and no location string is configured on
Oracle Communications Session Border Controller, the outgoing REGISTER message is forwarded out of the
Oracle Communications Session Border Controller, but no P-Access-Network-Info header is created for the
REGISTER message.
CLF Re-registration
The Oracle Communications Session Border Controller will send a new UDR message to the CLF to request a new
location string if any of the following events occur:
1. The endpoint's contact address changes.
2. The SIP Register message's Call-ID header changes.
3. The endpoint's public IP Address or UDP port changes.
4. The endpoint connects to a different SIP interface, port, or realm on the Oracle Communications Session Border
Controller than it did in the initial REGISTER message.
5. The registration expires in the Oracle Communications Session Border Controller's registration cache.
CLF Failures
If a Diameter connection fails, the Oracle Communications Session Border Controller will continually try to re-
establish the connection. Endpoints that are already registered will stay registered unless they timeout or if the
registrar rejects their refreshes. When the Diameter connection has not been established, and an endpoint registers on
a SIP interface that is configured to use CLF, the Oracle Communications Session Border Controller forwards new
REGISTER messages to the registrar using the default location string.
If the Diameter connection to the CLF is down, emergency calls from un-registered endpoints are still allowed into
the network using the default string inserted into the emergency messages.
Result-Code AVP
If the CLF sends a Result-Code AVP in a UDA message with a value of DIAMETER_UNABLE_TO_COMPLY
(5012), the Oracle Communications Session Border Controller forwards the REGISTER message using the default
configured location string in the P-Access-Network-Info header. If the configured default string is left blank the
Oracle Communications Session Border Controller forwards the SIP REGISTER message without the P-Access-
Network-Info header.
Experimental-Result-Code AVP
If the CLF sends a grouped Experimental Result AVP in a UDA message that is not successful, as per RFC 3588, the
Oracle Communications Session Border Controller performs the following actions with respect to receipt of these two
result code values:
• DIAMETER_ERROR_USER_UNKNOWN(5001): The Oracle Communications Session Border Controller
inserts the configured default-string in for the P-Access-Network-Info header when forwarding the SIP message.
• DIAMETER_ USER_DATA_NOT_AVAILBLE (4100): The Oracle Communications Session Border Controller
inserts the configured default-string in for the P-Access-Network-Info header when forwarding the SIP message.
For both cases, if the configured default string is left blank the Oracle Communications Session Border Controller
forwards the SIP REGISTER message without the P-Access-Network-Info header. For all other failure result codes,
the Register is rejected.
CLF-only AVPs
Globally-Unique-Address AVP
When endpoints registering through the Oracle Communications Session Border Controller reside in nested realms,
the Oracle Communications Session Border Controller allows you to set the realm that appears in the Globally-
Unique-Address AVP in Diameter UDR messages destined for a CLF.
The ingress-realm-location parameter in the external policy server configuration specifies whether to use
the realm on which a signaling message arrived, or to use that realm’s parent. If you choose to use the parent realm,
the Oracle Communications Session Border Controller uses the one associated with the SIP interface on which the
REGISTER request arrived.
e2 Interface
You can configure a value to be sent in the Address-Realm AVP (communicated in the Globally-Unique-Address
AVP) for the Diameter e2 interface. This AVP is sent on a per-realm basis in the Location Information Query (UDR)
query the Oracle Communications Session Border Controller (as a P-CSCF) sends to the CLF.
The CLF maintains details about IP connectivity access sessions associated with user equipment connected in the
network. This CLF supports the standardized Diameter e2 interface with an Application Function; from it, the
application function (i.e., the Oracle Communications Session Border Controller in the role of P-CSCF) retrieves
location information and other data related to the access session. To do so, the AF sends a UDR containing Global-
Unique-Address and Requested Information attributes. Then the CLF returns a Location Information Response
(UDA) containing either a success result code with location information or an error result code.
In the UDR’s Global-Unique-Address, the Oracle Communications Session Border Controller currently supports the
mandatory parameters: the Framed-IP-Address AVP and the Address-Realm AVP. The address realm AVP is the
realm address in FQDN form, populated based on the realm on which a REGISTRATION arrived or the SIP interface.
With nested realms configured, using a realm for this value can quickly become complicated.
You can configure the value sent in the Address-Realm AVP on a per-realm basis. You set the external policy server’s
ingress-realm-location parameter to the diam-address-realm value, pointing the Oracle
Communications Session Border Controller to the associated realm from which it will learn Address-Realm AVP
information. This access realm (or child realm, the realm on which enter registration came in) has its diam-e2-
address-realm value set to the value with which to populate the Address-Realm AVP for the outgoing UDR
message.
• Registering users—When it receives a registration request, the Oracle Communications Session Border Controller
checks the incoming SIP interface to determine CLF use. If CLF use is unnecessary, the Oracle Communications
Session Border Controller forwards the registration message to its destination.
When CLF is required, the Oracle Communications Session Border Controller selects the AVPs to send the CLF,
including the User-Name AVP before sending it a UDR. A none setting for this parameter means the Oracle
Communications Session Border Controller does not include the User-Name AVP in any UDRs. The Oracle
Communications Session Border Controller adds the User-Name AVP to the UDR if the user-name-mode
parameter in the external policy server configuration is set to:
• endpoint-id—IP address of the registering endpoint is sent as the payload for the User-Name AVP
• public-id—SIP-URI portion of the TO header from the register message is sent as the payload for the
User-Name AVP
• auth-user—Username attribute of the Authorization header from the register is sent as the payload for the
User-Name AVP; if there is no authorization header, the Oracle Communications Session Border Controller
will not consult the CLF and will forward the registration message
• Unregistered users—When it receives an INVITE request, the Oracle Communications Session Border Controller
checks the incoming SIP interface to determine if it should use an external policy server. If it does not need to use
an external policy server, the Oracle Communications Session Border Controller forwards the INVITE message to
its destination.
When the Oracle Communications Session Border Controller does need to use an external policy server, it also
checks to determine if the INVITE is in a registration and if location data in the registration cache is avaible for
that endpoint. These requirements being met, the Oracle Communications Session Border Controller inserts the P-
Access-Network-Info header with the location string into the INVITE it forwards to the destination. If these
requirements are not met, the Oracle Communications Session Border Controller consults the CLF before
forwarding the INVITE. The following describe the impact of the user-name-mode setting in such instance:
• endpoint-id—IP address of the endpoint that issued the INVITE is sent as the payload for the User-Name
AVP
• public-id and auth-user—SIP-URI portion of the INVITE is sent as the payload for the User-Name
AVP:
With a P-Asserted-Id header present in the INVITE, the Oracle Communications Session Border Controller
uses the first PAID header (if there are multiple PAID headers)
Without a P-Asserted-Id header present in the INVITE’s P-Preferred-Identity header, the Oracle
Communications Session Border Controller uses the first PPI (if there are multiple PPI headers)
With neither P-Asserted-Id nor P-Preferred-Identity header present, the Oracle Communications Session
Border Controller uses the From header
HA Functionality
The location strings generated by the CLF are replicated on the standby Oracle Communications Session Border
Controller in an HA pair. This is required so that a Oracle Communications Session Border Controller in an HA pair
can instantly continue processing calls using the previously learned CLF information.
• none—the system does not include the User-Name AVP in any UDRs (default)
• endpoint-ip—IP address of the registering endpoint is sent as the payload for the User-Name AVP
• public-id—SIP-URI portion of the TO header from the register message is sent as the payload for the User-
Name AVP
• auth-user—Username attribute of the Authorization header from the register is sent as the payload for the
User-Name AVP; if there is no authorization header, the Oracle Communications Session Border Controller
will not consult the CLF and will forward the registration message
21. domain-name-suffix—Enter the suffix you want to use for Origin-Realm and Origin-Host AVPs that have a
payload string constructed as a domain name Your value can be any string, to which the Oracle Communications
Session Border Controller will prepend with a dot if you do not include one. The default value is .com.
22. gate-spec-mask—With this parameter, you can configure the Oracle Communications Session Border
Controller to use a mask comprised entirely of zeros (0). The default value is 255. This parameter sets the value to
use for the COPs pkt-mm-3 interface. This interface maintains a persistent TCP connection to the external policy
server, even without repsonses to requests for bandwidth. This permits calls to traverse the Oracle
Communications Session Border Controller even though the external policy server either fails to respond, or
rejects the session.
• Default 255
• Values Min: 0 / Max: 255
23. allow-srv-proxy—Set to enabled in order to include the proxy bit in the header. The presense of the proxy
bit allows the Oracle Communications Session Border Controller to tell the external policy server whether it wants
the main server to handle the Diameter message, or if it is okay to proxy it to another server on the network
(disabled). The default is enabled. The valid values are:
• enabled | disabled
24. reserve-incomplete—Set this parameter to enabled if you want the Oracle Communications Session
Border Controller to send a message to the CLF that does not include the endpoint’s true port number. A value of
0 will be used for the port number. The default value is enabled. The valid values are:
• enabled | disabled
25. watchdog-ka-timer—Enter the interval in seconds of Oracle Communications Session Border Controller-
initiated watchdog/keep-alive messages. Valid values range between 0 and 65535 seconds.
26. trans-expires—Set the amount of time, in seconds, that the Oracle Communications Session Border
Controller waits before performing an expiration if a Diameter base protocol transaction does not occur. The
default value is 15 seconds. Valid values range between 1 and 15.
27. Save your work using the ACLI done command.
CLF Debugging
A new argument has been added to the show command for viewing CLF statistics. From the user prompt, type show
ext-clf-svr.
ORACLE# show ext-clf-svr
14:17:14-114
EBM Status -- Period -- -------- Lifetime --------
Active High Total Total PerMax High
Client Trans 0 0 0 0 0 0
Server Trans 0 0 0 0 0 0
Sockets 0 0 0 0 0 0
Connections 0 0 0 0 0 0
---- Lifetime ----
Recent Total PerMax
CLF Requests 0 0 0
CLF Admits 0 0 0
CLF Errors 0 0 0
CLF Rejects 0 0 0
The number of servers maintained in the HA cluster is configured with the max connections parameter. Thus if
the max connections parameter is set to 3, the Oracle Communications Session Border Controller maintains 1
active external policy server with 2 back up servers.
Server States
An HA cluster can contain up to 4 Policy Servers, where the TCP/Diameter connection is established and monitored.
Diameter session traffic is only sent to the active policy server in the cluster. The policy servers exist in the following
states:
• active-TCP and Diameter connection established. Oracle Communications Session Border Controller using this
server for policy decisions. The policy server with the highest priority/weight begins in this state.
• standby- TCP and Diameter connection established. Server in standby mode.
• inactive - Diameter connection not successfully established. Oracle Communications Session Border Controller
tries to reconnect to inactive servers.
HA Cluster Refresh
The Oracle Communications Session Border Controller sends follow-up SRV queries to the DNS server to refresh the
list of available policy servers in the cluster in the following instances:
• DNS cache expires after the TTL is exceeded
• a new policy server with FQDN for an address is configured, saved, and activated on the Oracle Communications
Session Border Controller
• after an SPU switchover, the newly active SPU performs a DNS query
When the Oracle Communications Session Border Controller re-queries the DNS server for Diameter external policy
servers, the cluster is refreshed with the new/changed servers. Policy server priority is also reconfigured based on
newly returned priorities and weights. Upon a cluster refresh, the Oracle Communications Session Border Controller:
• closes connections with standby policy servers that are no longer in the cluster
• creates connections with policy servers which are new in the set
If the currently active policy server remains a member of the cluster after a refresh, it remains active even if its
priority has changed. If the active-before-the-refresh policy server is not a member of the cluster after a DNS refresh,
the Oracle Communications Session Border Controller gracefully closes the connection to this server. The Oracle
Communications Session Border Controller then installs the highest priority server as the active policy server
DNS Failure
If the Oracle Communications Session Border Controller fails to get a response from the DNS server or does not
receive at least one IP address in the SRV RR, it continues to send SRV queries periodically, starting with 5 seconds
and doubling the interval for every sequential failure, until it receives a valid response. While waiting for a successful
DNS response, the Oracle Communications Session Border Controller uses the existing Diameter servers in the DNS
cache.
The following call flow is an example two tiered PS support for user registration. While the initial AAR’s
Destination-Host AVP is empty, the system inserts the value of the received Origin-Host AVP into the registration-
terminating STR.
The following call flow is an example of a two tiered PS support for a call. If this call occurs within the scope of the
previous registration, the value inserted into the Destination-Host AVP will still be unique per session. Therefore, it is
not the value learned from the AAA in the REGISTER, previously illustrated; it is the value learned from the AAA
responding to the INVITE setting up the call.
In the case of a reINVITE changing an aspect of the call like the codec use, foo1 is inserted into the AAR’s
Destination-Host AVP. If the Origin-Host AVP value, as received by the system, changes mid session for a call, all
subsequent Destination-Host AVP values are updated with the change.
A diameter manipulation configuration element is defined by a name parameter. You can optionally add a description
field to the diameter manipulation. Within each diameter manipulation you can configure multiple diam manipulation
rule subelements. The manipulation rule subelements are the configuration where AVPs are identified, searched, and
in which the data is replaced.
The user applies diameter manipulations to external policy servers. These manipulations affect traffic between the
Oracle Communications Session Border Controller and the applicable policy server.
Manipulation Rule
Creating a manipulation rule is divided into three parts, defining the message type and AVP where the manipulation is
performed, defining how the search on the AVP is performed, and defining what to replace the found string with.
You must first define the name parameter of the diam manipulation rule configuration element. Optionally you can
add a descr avp code parameter that is a description of this manipulation rule.
Finally, the match operation is configured by defining a match value, which is the string to find. The Oracle
Communications Session Border Controller evaluates if the match value is found in the avp code AVP. You may also
leave the match value empty for the DMR to be applied on the AVP without testing for a match.
Reserved Keywords
The Oracle Communications Session Border Controller employs certain reserved keywords as a short hand for
configuration/message parameters. These keywords are as follows:
HOSTNAME—This keyword refers to the agent hostname this rule is being referenced by. If the rule is applied to a
realm/interface then the value of the hostname keyword will be an empty string. If the rule is applied to the group,
then the hostname for the agent picked will be used.
ORIGINREALM—This keyword refers to the Origin-Realm value for the configured realm/interface. If the rule is
applied to a Diameter Director Agent, then the origin-realm value is derived from the Diameter Director Interface the
agent belongs to.
ORIGINHOST—This keyword refers to the Origin-Host value for the configured realm/interface. If the rule is
applied to a Diameter Director Agent, then the origin-host value is derived from the Diameter Director Interface the
agent belongs to.
none
None disables a manipulation rule.
add
This action inserts the value from the new value parameter, creates a new AVP of the specified type and adds it to
the list of AVPs at the specified position.The message length and padding are re-computed to account for this newly
added AVP.
delete
This action removes the specified AVP from the list of AVPs being operated on. The message length and padding will
be re-computed to account for this deleted AVP.
replace
This action substitutes the existing value with the new value parameter. The message length and padding and AVP
length and padding will be re-computed to account for changes. This is mostly applicable to variable length AVP
types such as octet-string.
store
Each manipulation rule has the ability to store the data that was contained in the AVP as a string. This is useful for
creating conditional logic to make decisions whether to execute other manipulation rules or to duplicate information
within the Diameter message.
Every manipulation rule performs an implicit store operation prior to executing the specified action type. All store
operations are based on regular expression patterns configured in the match value. The information that is stored
in the rule is the resultant of the regular expression applied against the specified string. The comparison-type is
ignored when the action is set to store as the Oracle Communications Session Border Controller assumes that the
match value is a regular expression. Conditional logic cannot be used to make a decision whether to perform a
store operation or not; storing always occurs. Values stored in a manipulation rule are referred to as user defined
variables.
diameter-manip
When the action is set to diameter-manip, the Oracle Communications Session Border Controller executes the
diameter-manipulation name configured in the new value. The diameter-manipulation name in the new value
must match another diameter-manipulation name exactly (case is sensitive).
diameter-manip action type is primarily to reuse diameter-manipulations that may be common to other use cases. A
diameter-manip action should never call back to itself either directly or indirectly through a different diameter-
manipulation.
find-replace-all
The find-replace-all action searches the object's string for the regular expression defined in the match-value
and replaces every matching occurrence of that expression with the value supplied in the new value. If the regular
expression contains sub-groups, a specific sub-group can be specified to be replaced by adding the syntax [[:n:]] at the
end of the expression, where n is the sub-group index (zero-based). When the action is find-replace-all, the
comparison-type is ignored and the match-value is always treated as a regular expression.
group-manip
The group manip action is used to manipulate AVPs inside grouped AVPs. For this diameter manipulation, you
must set the avp-type to grouped.
The group manip action is similar to the diameter manip action in that the Oracle Communications Session
Border Controller executes the diameter-manipulation configured in the new value.
There is an important difference between group manip and diameter manip. The diameter-manip action is
context insensitive, meaning when it jumps from one diameter-manipulation to the next diameter-manipulation, it
starts looking for the specified AVP from the top of the message.
The group manip action is context sensitive, meaning when the processing jumps from one diameter-manipulation
to the next diameter-manipulation, it will look for the specified AVP within the grouped AVP. In short, the group
manip works at an AVP level. All actions are allowed in the subsequent manipulations that are invoked, with the key
difference being that those manipulation rules will be applied to the current grouped AVP in the chain. Thus it is
possible to apply manipulation to an AVP at any level in the hierarchy.
Consider the following examples:
In order to replace the experimental-result > experimental-result-code AVP value from 5002 to 3002, a group
manip can be configured as follows:
diam-manipulation
name manipExpRslt
description
diameter-manipulation-rule
name expRslt
avp-code 297
descr-avp-code
avp-type grouped
action group-manip
comparison-type case-sensitive
msg-type response
msg-cmd-codes 316,317,318
match-value
new-value expRsltCode
last-modified-by admin@console
last-modified-date 2011-09-13 18:50:33
diam-manipulation
name expRsltCode
description
vendor-id Manipulation
You can manipulate the Vendor ID value in the AVP header by configuring the header-type parameter to avp-
vendor-id. This performs the DMR manipulation on the 4-byte vendor-id in the AVP header. AVP vendor id is
present in the AVP header only when the ‘V’ bit is set in the flags. This is important because the DMR application
relies upon the bit being set to determine where the data payload begins.
The avp-vendor-id search invokes an unsigned integer comparison between the received value and the match-
value. If the match-value is empty, the configured action is performed without doing any match.
For the case where match-value is non-empty, as in the following example, the DMR engine checks whether the
‘V’ bit is set in the received header. If not, then the vendor id is not present either and the comparison is unsuccessful.
If the ‘V’ bit is set, and the match succeeds, the match is successful. (An unsuccessful match has the DMR proceed to
the next header-rule.)
avp-header-rules
name replaceAvpFlags
header-type avp-vendor-id
action add
match-value 9148
new-value 10415
When the match is successful (or if the match value is left empty), the configured action is performed.
Consider all following actions:
ACLI Instructions
Diameter Manipulation
To configure a diameter manipulation configuration element:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type session-router and press Enter to access the media-related configurations.
ORACLE(configure)# session-router
3. Type diameter-manipulation and press Enter. The system prompt changes to let you know that you can
begin configuring individual parameters.
ORACLE(session-router)# diameter-manipulation
ORACLE(diameter-manipulation)#
4. name—Enter the name of this Diameter manipulation element.
5. description—Enter an optional description for this Diameter manipulation.
6. Type done and continue.
Manipulation Rule
1. Type diameter-manip-rules to continue and enter individual policy attributes. The system prompt changes
to let you know that you can begin configuring individual parameters.
2. name—Enter the name of this manipulation rule. This value will be referenced in when creating a chain of rules.
3. descr-avp-code—Enter a description of the AVP code to manipulate.
4. msg-cmd-code—Enter the command code number of the message to execute the manipulation on.
5. msg-type—Set this to the type of message this manipulation applies to as request, response, or all.
6. avp-code—Enter the AVP by code number where this manipulation applies. You can add a multi instance
identifier to the end of the avp code value, enclosed in brackets.
7. avp-type—Set this to the data type of the content of the match field. Refer to the Diameter standards document
for the encodings of individual AVPs. Valid values are:
none | octet-string | octet-hex | integer32 | unsignedint32 | address | diameteruri | enumerated | grouped
8. match-value—Enter the value within the match-field to find and make a positive match on.
9. action—Enter either none, add, delete, store, diameter-manip, group-manip, find-
replace-all, or replace as the action to take after making a positive match on the previously entered
match-value.
10. new-value—Enter the value that should be added or replaced in the old match-value’s position.
11. Type done and continue.
This second rule, which defines a new value for the first rule, builds the Feature-List-ID and Feature-List AVPs to be
included within the context of the Supported Features group.
diameter-manipulation
name diamManip2
COPS Connection
The COPS session is established over a persistent TCP connection between the PDP and PEP. A COPS Client-Open
(OPN) message is sent from the Oracle Communications Session Border Controller to the RACF, which responds
with a COPS Client-Accept (CAT) message. A COPS Client-Close (CC) message is sent to either side to gracefully
close the persistent connection. This COPS connection is expected to never close, unless an error occurs.
COPS Failures
Connection failures are discovered through a keep alive mechanism. Keep alive (KA) messages are periodically sent
by the Oracle Communications Session Border Controller to the RACF regardless if any other COPS messages have
been exchanged. When a KA message is not received, a connection failure is flagged. If the COPS connection fails,
the Oracle Communications Session Border Controller will continually try to re-establish the connection to the PDP.
Previously established calls will continue unaffected, but the Oracle Communications Session Border Controller will
deny new calls from being established until the COPS connection is restored.
Failure Detection
A COPS connection failure is triggered by one of the three following events:
1. COPS KA timeout. The Oracle Communications Session Border Controller flags a COPS KA timeout when it
does not receive a response for the KA it sent to the PDP. The PDP flags a COPS KA timeout when it does not
receive the KA message within its requested timer time from the Oracle Communications Session Border
Controller. At a minimum, when the COPS KA message times out, the TCP socket is closed.
2. Explicit COPS CC. The Oracle Communications Session Border Controller closes a COPS connection if it
receives a COPS CC message from the PDP. The PDP closes a COPS connection if it receives a CC message from
the Oracle Communications Session Border Controller. After the COPS layer connection is closed, then the TCP
socket is closed too.
3. TCP socket termination. If either side receives a TCP FIN or RST, the TCP socket closes as expected. The COPS
layer then detects that the socket has been closed before sending any further messages, and thus the COPS
connection is closed.
Failure Recovery
The Oracle Communications Session Border Controller assumes that the PDP has a mechanism that re-uses the same
logical IP Address, restarts itself in a timely manner, or fails over to another PDP. Therefore, no backup PDP IP
address is configured on the Oracle Communications Session Border Controller.
The Oracle Communications Session Border Controller will try to re-open the COPS connection to recover from a
connection failure. The PDP is never the device to initiate a connection. The Oracle Communications Session Border
Controller increases its retry interval after successive reconnect failures. Once the retry interval has grown to every
five minutes, the Oracle Communications Session Border Controller continues to retry to open the COPS connection
at the five minute interval.
HA Support
The Oracle Communications Session Border Controller's high availability (HA) capabilities have been extended to
support COPS. When one Oracle Communications Session Border Controller in an HA configuration goes down, the
MAC addresses are reassigned to a healthy Oracle Communications Session Border Controller. IP addresses "follow"
the MAC addresses to provide a seamless switchover between HA nodes.
After an HA failover, the COPS connection on the primary Oracle Communications Session Border Controller is
either gracefully torn down, or times out depending on behavior of the PDP. The backup Oracle Communications
Session Border Controller attempts to create a new COPS connection with the PDP. The OPN message uses the same
PEPID and Client Type as in the previous pre-failover session.
Application Types
The Oracle Communications Session Border Controller supports the following COPS-based methods for interfacing
with a RACF:
• PKT-MM3 (PacketCable™ Specification Multimedia Specification PKT-SP-MM-I03-051221) (client type:
0x800A)
• Acme Packet proprietary (client type: 0x7926)
The Oracle Communications Session Border Controller supports the following COPS-based methods for interfacing
with a CLF:
• Oracle proprietary (client type: 0x7929)
COPS: RACF
CAC is performed according to the following typical scenario. When the Oracle Communications Session Border
Controller receives a SIP INVITE, it sends a COPS request (REQ) message to the PDP. The REQ message includes
the call ID, the SIP client's IP address, the Oracle Communications Session Border Controller’s IP address and port
number of the ingress interface for the call, and SDP based bandwidth requirements. The PDP responds with a COPS
Decision (DEC) message with either the Install or Remove command. An Install command directs the Oracle
Communications Session Border Controller to forward the INVITE to the next SIP device. A Remove command
directs the Oracle Communications Session Border Controller send a SIP 503 Service Unavailable message sent back
to the UA and reject the call.
The Oracle Communications Session Border Controller can be configured so that both sides of a call, based on realm,
are subject to COPS bandwidth enforcement. Each flow is treated as a unique call/event, because from a media and
signaling perspective, they are distinct. As the Oracle Communications Session Border Controller functions as one
side of a call, its IP address is inserted into the REQ message regardless of whether it is the calling or called party.
This allows for the COPS install or remove decision to be made before the Oracle Communications Session Border
Controller receives the 200 OK response, and before ringing the far-end phone. Only one external policy server can
be used within a single realm.
When a call ends, either with the expected SIP BYE or CANCEL methods, or due to other error conditions, the
Oracle Communications Session Border Controller will delete the reservation on the PDP by sending a COPS delete
request state (DRQ) message to the PDP. All ended calls must be deleted from the PDP in order to accurately track
used and available bandwidth.
Implementation Features
As the Oracle Communications Session Border Controller proxies and forwards calls, caller media information is
known before the INVITE reaches the callee. The PEP can request a specific amount of bandwidth for a call, and the
PDF can reserve this amount of bandwidth for a call before the called phone rings. A call's required bandwidth can
also be reserved by network devices along the path from the caller to callee if the QoS admission criteria is pushed to
PEPs such as routers, along this path to the callee.
The RACF can apply its hosted policies for calls originating at SIP UAs located behind NATs. This is a standard part
of the Oracle Communications Session Border Controller's ability to provide seamless HNT.
Bandwidth Negotiation
Because the decision whether to admit or reject a call is made before the INVITE is forwarded to the called party,
some information is not available to the PDP at the initial request. The final IP Address, UDP port number, that
transport the RTP flow, and the codec used are not known by the Oracle Communications Session Border Controller
until the called party responds with its own SDP information (either in the 180 or 200 response).
The Oracle Communications Session Border Controller sends a request to the PDP requesting as much bandwidth as
the codec with the highest bandwidth in the SDP message requires. If the call is admitted, and when the called party
returns finalized SDP information, the Session Director will modify the original reservation with the chosen codec's
bandwidth requirements. This ensures the PDP has current and accurate information with which to make policy
decisions.
This diagram shows a call flow where the Gate-Set times out. It assumes an access-to-core configuration, where the
external bandwidth management configuration shows:
• disconn-on-timeout=disabled
• permit-conn-down=enabled
•
COPS Debugging
A new argument has been added to the show command for viewing COPS and CAC statistics. From the user prompt,
type show ext-band-mgr.
ORACLE# show ext-band-mgr
10:11:38-194
EBM Status -- Period -- -------- Lifetime --------
Active High Total Total PerMax High
Client Trans 0 0 0 0 0 0
Server Trans 0 0 0 0 0 0
Sockets 1 1 1 1 1 1
Connections 0 0 0 0 0 0
---- Lifetime ----
Recent Total PerMax
Reserve 0 0 0
Modify 0 0 0
Commit 0 0 0
Remove 0 0 0
EBM Requests 0 0 0
EBM Installs 0 0 0
EBM Errors 0 0 0
EBM Rejects 0 0 0
EBM Expires 0 0 0
EBMD Errors 0 0 0
You can also refer to the log.ebmd log file located in the /ramdrv/logs/ directory on the Oracle Communications
Session Border Controller . This file must be retrieved via FTP or SFTP.
Realm Configuration
To configure the realm configuration for COPS support in a CAC scenario:
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)#
4. Type select and the number of the pre-configured sip interface you want to configure.
ORACLE(realm-config)# select 1
ORACLE(realm-config)#
5. mm-in-realm—Set this parameter to enabled so that calls from devices in the same realm have their media
flow through the Oracle Communications Session Border Controller to be subject to COPS CAC. The default
value is disabled. The valid values are:
• enabled | disabled
6. mm-in-network—Set this parameter to enabled so that the Oracle Communications Session Border
Controller will steer all media traveling between two endpoints located in different realms, but within the same
network. If this field is set to disabled, then each endpoint will send its media directly to the other endpoint
located in a different realm, but within the same network. The default value is enabled. The valid values are:
• enabled | disabled
7. ext-bw-manager—Enter the name of the external bandwidth manager configuration instance to be used for
external CAC for this Realm.
8. Save your work using the ACLI done command.
COPS: CLF
A Connectivity Location Function (CLF) maintains mappings between endpoints with dynamically assigned IP
addresses and their physical location. The Oracle Communications Session Border Controller , acting as a P-CSCF, is
the intermediary device between a registering endpoint and a CLF. The CLF thus validates and tags a registering
endpoint, and the Oracle Communications Session Border Controller applies the CLF's actions. The Oracle
Communications Session Border Controller and the CLF maintain a connection with each other using the COPS
protocol.
CLF Behavior
The Oracle Communications Session Border Controller and a CLF only interact when an endpoint registers or re-
registers. The Oracle Communications Session Border Controller , acting as the P-CSCF, is the first SIP device that
the REGISTER message reaches. Upon receiving the REGISTER message(1), the Oracle Communications Session
Border Controller queries the CLF using the COPS protocol. The endpoint's (public) IP address and port, and the
Oracle Communications Session Border Controller 's IP information are sent to the CLF in a COPS REQ message(2).
The CLF responds to the Oracle Communications Session Border Controller with an Approve or Reject COPS DEC
message(3). If the request is approved, then the CLF also sends a location-string value to be inserted in one of the SIP
headers. The Oracle Communications Session Border Controller inserts a P-Access-Network-Info header containing
the location-string into the incoming REGISTER message and forwards this message(4) to the SIP registrar/I/S-
CSCF.
The Oracle Communications Session Border Controller will insert this P-Access-Network-Info header into all
subsequent SIP messages from this endpoint as they are forwarded into the core network. The P-Access-Network-Info
header is inserted into all SIP requests and responses except for ACK and CANCEL messages. For all boundaries
where SIP messages pass from trusted to untrusted SIP interfaces or session agents, the Oracle Communications
Session Border Controller will strip out the P-Access-Network-Info header as expected.
If the CLF responds with a Reject DEC message, the Oracle Communications Session Border Controller rejects the
registration, and sends a 503 - Service Unavailable message back to the registering endpoint. In this way, the CLF can
be used for admission control.
The Oracle Communications Session Border Controller communicates with the CLF solely for retrieving location
information from the CLF, and not for notifying the CLF about an endpoint's registration state or activity. When an
endpoint's registration ends, either through a normal expiration, getting rejected by the registrar, or through specific
de-registering or error conditions, the Oracle Communications Session Border Controller deletes the locally cached
registration location string. The Oracle Communications Session Border Controller does not update the CLF about
any registrations that have been deleted.
CLF Re-registration
The Oracle Communications Session Border Controller will send a new REQ message to the CLF to request a new
location string if any of the following events occur:
• The endpoint's contact address changes.
• The SIP Register message's Call-ID header changes.
• The endpoint's public IP Address or UDP port changes.
• The endpoint connects to a different SIP interface, port, or realm on the Oracle Communications Session Border
Controller than it did in the initial REGISTER message.
• The registration expires in the Oracle Communications Session Border Controller 's registration cache.
CLF Failures
If a COPS connection fails, the Oracle Communications Session Border Controller will continually try to re-establish
the connection. Endpoints that are already registered will stay registered unless they timeout or if the registrar rejects
their refreshes. When the COPS connection has not been established, and an endpoint registers on a SIP interface that
is configured to use CLF, the Oracle Communications Session Border Controller forwards new REGISTER messages
to the registrar using the default location string.
REGISTER message toward the registrar. For emergency calls where the endpoint has already successfully registered,
the call will be routed into the network using the expected methods for emergency call routing.
If the COPS connection to the CLF is down, emergency calls from un-registered endpoints are still allowed into the
network using the default string inserted into the emergency messages.
HA Functionality
The location strings generated by the CLF are replicated on the standby Oracle Communications Session Border
Controller in an HA pair. This is required so that a Oracle Communications Session Border Controller in an HA pair
can instantly continue processing calls using the previously learned CLF information.
CLF Debugging
A new argument has been added to the show command for viewing CLF statistics. From the user prompt, type show
<space> ext-clf-svr <return>.
ORACLE# show ext-clf-svr
14:17:14-114
EBM Status -- Period -- -------- Lifetime --------
Active High Total Total PerMax High
Client Trans 0 0 0 0 0 0
Server Trans 0 0 0 0 0 0
Sockets 0 0 0 0 0 0
Connections 0 0 0 0 0 0
---- Lifetime ----
Recent Total PerMax
CLF Requests 0 0 0
CLF Admits 0 0 0
CLF Errors 0 0 0
CLF Rejects 0 0 0
CLF Expires 0 0 0
CLFD Errors 0 0 0
You can also refer to the log.ebmd log file located in the /ramdrv/logs/ directory on the Oracle Communications
Session Border Controller . This file must be retrieved via FTP or SFTP.
• A-COPS—Vendor specific protocol. COPS client type is 0x4AC0 for admission-control operation-type.
15. address—Set this parameter to the IP address or FQDN of the CLF.
16. port—Set this parameter to the port which the CLF uses for COPS transactions. The standard port for COPS is
3288. The default value is 80. The valid range is:
• Minimum—0
• Maximum—65535
17. realm—Set this parameter to the realm in which the CLF exists.
18. num-connections—Set this parameter to the number of connections the Oracle Communications Session
Border Controller will create with the CLF. The default value is 1. The valid range is:
• Minimum—0
• Maximum—65535
19. reserve-incomplete—Set this parameter to enabled if you want the Oracle Communications Session
Border Controller to send a COPS REQ message to the CLF that does not include the endpoint’s true port number.
A value of 0 will be used for the port number. The default value is enabled. The valid values are:
• enabled | disabled
20. Save your work using the ACLI done command.
P-CSCF Functions
The Oracle Communications Session Border Controller performs the following functions in the role of P-CSCF:
• Forwards SIP REGISTER messages and maintains a cached mapping of the user info and the UE's Address of
Record (AoR), including the far-end NAT address in the case of hosted NAT traversal (HNT).
• Forwards SIP messages to a S-CSCF based on service route discovery procedures.
• Performs local emergency session handling—Local routing policy is used by the Oracle Communications Session
Border Controller to identify emergency sessions and provide unique routing (e.g. can route to a dedicated S-
CSCF function for emergency session handling).
• Operates as a UA (B2BUA) for generating independent SIP transactions for security purposes and handling of
abnormal conditions.
• Offers current session timers which are used to monitor for media faults and abandoned calls.
• Generation of CDRs—The Oracle Communications Session Border Controller generates real-time accounting
records via RADIUS.
• Authorization of bearer resources and QoS management—With integrated BGF capabilities, the Oracle
Communications Session Border Controller allocates bearer resources (NAPT flows) and applies QoS policies
(including packet marking) based on local policies and/or policies acquired via interaction with the A-RACF
(PDF).
• Interaction with the A-RACF (PDF) for session-based policy enforcement and admission control—The Oracle
Communications Session Border Controller PDF interface options include COPS and SOAP/XML.
• Traffic Policing—Traffic is policed at the session and media/transport layer. At the signaling layer, the Oracle
Communications Session Border Controller polices at a number of levels including:
• Capacity—Total number of concurrent calls to/from each realm
• Session set-up rate—Maximum rate of call attempts to/from each signaling element
• Signaling message rate—Each endpoint’s signaling message rate is monitored and policed
• Signaling bandwidth—each endpoint’s signaling bandwidth is policed individually
A-BGF Functions
The Oracle Communications Session Border Controller performs the following IMS BGF functions:
• Opening and closing gates/packet filtering—The Oracle Communications Session Border Controller opens and
closes gates (media pinholes) on a session-by-session basis. Packet filtering rules include full source and
destination IP address and port number.
• Per-session DiffServ or ToS marking—Media flows destined for the IMS core network can be explicitly marked
using ToS or DiffServ. Media packets can be marked by VPN, by codec (voice, video) or by E.164 phone number
prefix.
• NAPT-PT and topology hiding—The Oracle Communications Session Border Controller provides NAPT for all
media flows associated with a session on a per session-basis. Double NATing, NATing both source and destination
sides, is utilized to fully hide topology in each direction for RTP and RTCP. Local IP addresses and port resources
are dynamically allocated from steering pools provisioned on the Oracle Communications Session Border
Controller.
• Hosted NAT traversal—The Oracle Communications Session Border Controller supports HNT function that
allows media flow traversal through the CPE firewall/NAT without upgrading the CPE equipment. The system
interacts with the endpoints to dynamically establish and maintain bindings in the CPE firewall/NAT that allow
the signaled communications to pass through. The Oracle Communications Session Border Controller's
registration management and media relay functions make CPE-based NATs transparent to the service delivery
elements.
• Traffic Policing—Traffic is policed at the session and media/transport layer. At the signaling layer, the Oracle
Communications Session Border Controller polices at a number of levels including:
• Policing of Media (e.g. RTP & RTCP) traffic on a per-flow basis—CBR policing is applied to each flow based
on negotiated offered and negotiated media codecs.
The Oracle Communications Session Border Controller, acting as the SPDF, interfaces with the PDF (A-RACF policy
decision function) for resource authorization and admission control on a call-by-call basis. COPS is the supported
PDF interface.
Path Header
When a UE registers to an S-CSCF, the Oracle Communications Session Border Controller adds the Path header in
the REGISTER message as it is proxied to the S-CSCF. The Path header includes the SIP URIs that form the route
vector which describes how the UE reaches the Oracle Communications Session Border Controller, through a specific
series of proxies. This route vector is saved in the Oracle Communications Session Border Controller's registration
entry for the UE, routing all subsequent SIP messages from the S-CSCF to the UE. As the Path header is sent to the S-
CSCF, the Oracle Communications Session Border Controller, as P-CSCF, inserts the SIP URI of itself as the top
entry in the Path header.
The Path header only appears in SIP messages exchanged during the registration process.
If the REGISTER request already contains a Path header, the Oracle Communications Session Border Controller
stores the contents of the Path header(s) for this endpoint for routing back to the endpoint in subsequent messages.
The manner in which passing or stripping of Service-Route headers sent from the S-CSCF is done is determined by
local configuration on the Oracle Communications Session Border Controller. There is no verification of configured
local policy against the route included in the stored service route. The Service-Route header, as created by the Oracle
Communications Session Border Controller, and exiting back to the UE, contains a SIP URI pointing to itself as the
topmost entry. This is used so that other proxies can learn the route back to the Oracle Communications Session
Border Controller.
Summary
If a request originates at the UE, the routes enumerated in the Service-Route header are used to route the request to
the S-CSCF. If a request is meant to terminate at a UE, the routes enumerated in the Path header are used to route the
response to the UE. Service-Route routes take priority over configured local policy.
Path headers received in a 200 OK response from the registrar are transmitted to the UE unchanged. If you want them
stripped as the SIP message leaves the Oracle Communications Session Border Controller, you can use the SIP
Header Manipulation function.
If a registration refresh is received before the half time of the registration expiration interval then the registration
cache is not updated and the Oracle Communications Session Border Controller sends a 200 OK to the UE. No AAR
is sent to the PCRF.
Figure 2: Re-Register before Half Time of Expiration
De-Register
Figure 4: De-Registration
If the AAA is not received before the timeout, the AAA returns with an error, or the AAA is missing the required
location information, then the Oracle Communications Session Border Controller will search the NPLI cache for
cached location information to construct the PANI header to forward to the Registrar. If there is no cached location
information, then the default-location-string configuration parameter will be used to create the PANI header. The
default-location-string is obtained from the configuration in either the Realm or the SIP interface, with the Realm
taking precedence; in both cases the value will be taken from the Access Realm. If the default-location-string is not
set, then the REGISTER will be forwarded to the core without a PANI header.
Figure 5: AAA Timeout/Error or AAA does not have Location Information
ORACLE(sip-config)#
3. npli-upon-register— Enable to allow capture of Network Provided Location Information (NPLI) during the
registration process
• enabled | disabled
4. Type done to save your configuration.
MESSAGE
AAR
Required-Access-Info AVP = USER_LOCATION
Specific-Action AVP = ACCESS_NETWORK_INFO_REPORT
AAA
RAR
NPLI is cached
RAA
MESSAGE
PANI: NPLI NPLI is derived
from AAA and RAR
200OK
200OK
Figure 7: MO Message with AAR/AAA and RAR/RAR and within Holding Period
The below example shows a MO MESSAGE with NPLI information provided in the AAA, but the RAR arrives after
the holding period expires. The NPLI value is present in the PANI header
Figure 8: MO Message with AAR/AAA but RAR arrives after Holding Period
MO MESSAGE with no NPLI or cached NPLI. Both AAA and RAR arrive after the holding period expires.
Figure 9: MO Message with no/cached NPLI; both AAR and RAR arrive after Holding
Period
MT MESSAGE with NPLI provided in AAA and later updated with RAR. Both AAA and RAR arrive within the
holding period. The NPLI value is present in the PANI header in 200OK response.
Figure 10: MT Message with NPLI in both AAR/AAA and RAR/RAA within the
Holding Period
MT MESSAGE with NPLI provided in AAA, RAR arrives after the holding period expires. The NPLI value is
present in the PANI header in 200OK response.
Figure 11: MT Message with NPLI provided in AAR/AAA, RAR arrives after Holding
Period
MT MESSAGE with neither NPLI nor cached NPLI. Both AAA and RAR arrive after the holding period expires.
Figure 12: MT Message with no NPLI; both AAA and RAR arrive after the Holding
Period
UE P-CSCF(SBC) CORE
MESSAGE
MESSAGE
PANI: NPLI
Cached NPLI
200OK
200OK
Mobile terminated(MT) MESSAGE cached NPLI included in PANI header as the cached NPLI is current. Note that
there is no AAR/AAA/RAR/RAA exchange
UE P-CSCF(SBC) CORE
MESSAGE
MESSAGE
200OK
200OK
PANI: NPLI Cached NPLI
ORACLE(sip-config)#
3. msg-hold-for-loc-info— maximum number of seconds that the Oracle Communications Session Border
Controller will hold MESSAGEs for location information.
• 1-30— seconds
• 0— disabled; default
4. cache-loc-info-expire— number of seconds after which the Oracle Communications Session Border Controller
will drop network location information.
• 1-4294967295— seconds
• 32— default
5. keep-cached-loc-info-after-timeout— If this option is enabled, the location information will be left in the cache
and used in subsequent MESSAGEs after the cache-loc-info-expire time expires.
options +keep-cached-loc-info-after-timeout
6. Type done to save your configuration.
Path Header
The Path header is defined in RFC 3327, Session Initiation Protocol (SIP) Extension Header Field for Registering
Non-Adjacent Contacts. The Path header enables the accumulation and transfer of a list of proxies between a SIP UA
and a REGISTER. Its operation is very similar to the Record-Route header in dialog initiating request. Within the
context of support for wildcarded PUIs, the Path header is used to ensure that REGISTER responses containing an
wildcard ERE transit the P-CSCF, thus enabling the implicit registration of PBX extensions.
P-Profile-Key Header
The P-Profile-Key header is defined in RFC 5002, The Session Initiation Protocol (SIP) P-Profile-Key Private Header
(P-Header).If the identity of the server user of the request was via a wildcarded PUI, that wildcarded PUI is included
in the P-Profile-Key header in the outgoing request to the core. This Header will be included for requests like
INVITE, SUBSCRIBE, and so on that match the registered wildcarded PUI. The header will occur in all subsequent
requests to the core as well.
For this header to be present, the request needs to be going from access to core and the ims-feature must be enabled
on both the access and core SIP interfaces.
</registration>
<ere:wildcardedIdentity>sip:ep_user!.*!@home1.net</
ere:wildcardedIdentity>
</registration>
</reginfo>
If a </wildcardedIdentity> sub-element is included in the <registration> element (as in the second </registration>, the
wildcarded PUI is taken from the </wildcardedIdentity> sub-element, and that wildcarded PUI replaces any
previously stored wildcarded PUIs in the registration.
In the absence of </wildcardedIdentity> sub-element(as in the first registration), the PUI is taken from the ‘aor’
attribute of the registration element, and the registration cache is left unchanged.
Message Flows
A basic registration exchange with support for PUIs enabled.
From UA to P-CSCF
REGISTER sip:192.168.1.232:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.231:5060;branch=z9hG4bK-13794-1-0
From: <sip:7818888@hxu.com;tag=1
To: sut <sip:7818888@hxu.com>
Call-ID: 1-13794@192.168.1.231
CSeq: 1 REGISTER
Contact: <sip:7818888@192.168.1.231:5060>;expires=3600
Content-Length: 0
From P-CSCF to Registrar
If reg-cache-route is enabled on egress sip-interface, P-CSCF provides Path support with a value of P-CSCF-contact,
so INVITE from core will have route header with value of this path per RFC 3327.
REGISTER sip:192.168.200.231:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.200.232:5060;branch=z9hG4bK0g6tnu200o10tfgl0641.1
From: <sip:7818888@hxu.com;tag=1
To: sut <sip:7818888@hxu.com>
Call-ID: 1-13794@192.168.1.231
CSeq: 1 REGISTER
Contact: <sip:7818888-
rrbgth3ot667c@192.168.200.232:5060;transport=udp>;expires=3600
Content-Length: 0
Supported: path
Path: <sip:7818888-rrbgth3ot667c@192.168.200.232:5060; lr>
Max-Forwards: 70
From Registrar to P-CSCF
v=0^M
o=user1 53655765 2353687637 IN IP4 192.168.200.231
s=-
c=IN IP4 192.168.200.231
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
outgoing Request INVITE
For outgoing Request from access side, the Register Cache entry will be found by reg-via-key, when options ‘reg-via-
key’ and ‘reg-via-match’ are set, P-CSCF will have wildcarded PAU checking for allow-anonymous (or registered)
verification if option wildcard-puid-match is set.
INVITE sip:service@192.168.1.232:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.231:5060;branch=z9hG4bK-11911-1-0
From: sipp <sip:7816666@hxu.com>;tag=1
To: sut <sip:service@192.168.1.232:5060>
Call-ID: 1-11911@192.168.1.231
Supported: 100rel,timer,resource-priority,replaces
CSeq: 1 INVITE
Contact: sip:781666@192.168.1.231:5060
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 137
v=0
HA Configurations
Support for wildcarded PUIs requires checkpointing two new data points that need to be replicated in HA
configurations.
• the P-Profile-Key in the sip session so that subsequent requests in a session can take the cached value and include
that value in egress requests to core
• Upon SUB-NOT-200OK, the active P-CSCF replicates the subscribe session to the standby. This information is
required to replicate the new PAU list of the associated SIP User if the </wildcardedIdentity> element arrives in
the NOTIFY XML and has wildcarded entities.
P-Associated-URI Header
In the SIP registration process, the registrar often returns a set of associated URIs for a registering AoR. When the
Oracle Communications Session Border Controller receives the list of associated URIs, it stores them in the
registration entry for the registering endpoint. The service provider allocates one or more associated URIs per user for
his or her own usage. After an endpoint successfully registers, the P-Associated-URI header returned in a 200 OK
message informs the UE of all URIs associated with the AoR.
When the Oracle Communications Session Border Controller receives a request from a UE, the URI in the From
header is matched against the registration cache for that endpoint. If the registering endpoint matches an associated-
URI already in the registration table, the Service-Route associated with this endpoint is used to create the route for
originating transactions associated with the endpoint to the S-CSCF.
The inclusion or exclusion of the P-Associated-URI header is not dependent on the trust level of an ingress or egress
realm.
P-Asserted-Identity Header
The Oracle Communications Session Border Controller inserts a P-Asserted-Identity header into any initial request
for a dialog or standalone transaction sourced by the UE.
The inclusion or exclusion of the P-Asserted-Identity header is dependent on the trust level of an egress realm.
2. When the P-Preferred-Identity header is present in an INVITE sourced by the UE, and the SIP URI contained in
this header is also present in the UE's associated URI list, then this SIP URI is inserted in the P-Asserted-Identity
header as the SIP message enters the core network.
3. When the P-Asserted-Identity header is present in an INVITE sourced by the UE, and the SIP URI contained in
this header is also present in the UE's associated URI list, then the original P-Asserted-Identity header and SIP
URI is passed unchanged into the core network.
4. When the From header is present in an INVITE sourced by the UE, and the SIP URI contained in this header
appears in the UE's Associated URI list, then this SIP URI is inserted into the P-Asserted-Identity header as the
SIP message enters the core network.
5. When the P-Asserted-Identity header is present in an INVITE sourced by the UE, and the SIP URI contained in
this header is not present in the Associated URI list, the Oracle Communications Session Border Controller acts
like no P-Asserted-Identity was received from the UE.
6. When no P-Asserted-Identity can be derived from an INVITE sourced by the UE, the P-Asserted-Identity is based
on the first URI in the Associated URI list.
7. The P-Asserted-Identity header will be removed from SIP messages sent and received from a UE if either the
ingress or egress side is untrusted and the UE’s Privacy header’s contents is id.
8. If no P-Associated-URI exists for a registered endpoint, the Oracle Communications Session Border Controller
will use the configured default P-Asserted-Identity found on the sourcing session agent. This feature works with
both SIP and H.323 session agents.
9. If the session agent that originates a message does not include a P-Asserted-Identity header or the request is not
originated from the session agent, and the P-CSCF has not received P-Associated-URI list from the registrar for a
particular user, no P-Asserted-Identity will be created.
10. The P-Preferred-Identity header will never be passed to the S-CSCF.
If the above steps fail to insert a P-Asserted-Identity header, you can manually configure a value to be inserted
into a P-Asserted-Identity header. The sip-ims-feature parameter must still be enabled to use the P-Asserted-
Identity header override.
P-Called-Party-ID Header
The Oracle Communications Session Border Controller transparently passes the P-Called-Party-ID header between
the S-CSCF and a UA.
P-Charging-Vector
You can configure the Oracle Communications Session Border Controller to processes the P-Charging Vector header
in three different ways.
• If a P-Charging-vector header is present in an incoming SIP request, the Oracle Communications Session Border
Controller can pass the header untouched, as part of the full SIP message that is forwarded out of an egress
interface.
• If a P-Charging-vector header is present in an incoming SIP request, the Oracle Communications Session Border
Controller can delete the header and forward the full SIP message out of an egress interface.
• If an incoming SIP request does not contain a P-charging-vector header, the Oracle Communications Session
Border Controller can create and insert the header and forward the full SIP message out of an egress interface.
Likewise, if an incoming SIP request contains an existing P-Charging-Vector header, the Oracle Communications
Session Border Controller can overwrite this header with the values generated internally.
The P-Charging-Vector header is composed of four parameters: icid-value, icid-gen-addr, orig-ioi, term-ioi. See RFC
3455, Section 4.6 for more information.
1. The Oracle Communications Session Border Controller constructs the icid-value in the following format:
string2@string1 where:
String 1 is the IP address of the egress SIP interface.
String 2 is a unique string value created by the Oracle Communications Session Border Controller and based on
the realm, local IP port, time, and a sequence number.
2. The icid-gen-addr parameter's value is the IP address of the egress SIP interface. This value is generated by the
Oracle Communications Session Border Controller.
3. The orig-ioi parameter's value is set manually using the operator-identifier field located in the SIP interface
configuration element.
4. The term-ioi parameter's value is set manually using the operator-identifier field located in the SIP interface
configuration element.
You configure charging vector handling on the Oracle Communications Session Border Controller interface that
receives the SIP request by turning on the switches that enable charging vector processing on the ingress interface
for the call. Based on the direction of the call, the Oracle Communications Session Border Controller will insert
the operator-identifier configuration parameter into the orig-ioi and the term-ioi parameters. The orig-ioi
parameter takes the value of the operator-identifier configuration parameter of the SIP interface that receives the
SIP request. The term-ioi parameter takes the value of the operator-identifier configuration parameter of the SIP
interface that sends the SIP request to its next hop.
P-Charging-Function-Address
The P-Charging-Function-Address header is composed of two configurable parameters: ccf, ecf. You can configure
the Oracle Communications Session Border Controller to processes the P-Charging-Function-Address header in four
different ways.
• If a P-Charging-Function-Address header is present in an incoming SIP request, the Oracle Communications
Session Border Controller can be set to pass the header, untouched, as the full SIP request is forwarded out of an
egress interface.
• If a P-Charging-Function-Address header is present in an incoming SIP request, the Oracle Communications
Session Border Controller can be set to delete the header and forward the SIP request out of an egress interface.
• If an incoming SIP request does not contain a P-Charging-Function-Address header, the Oracle Communications
Session Border Controller can be set to create and insert the header and forward the SIP message out of an egress
interface.
• If an incoming SIP request contains a P-Charging-Function-Address header, and the Oracle Communications
Session Border Controller is set to insert a configured P-Charging-Function-Address header, the new parameters
will be appended before the existing parameters in the header. The Oracle Communications Session Border
Controller will then forward the SIP request out of an egress interface.
In addition, the Oracle Communications Session Border Controller can also be configured to perform insertion and
caching for the PCFA header in dialog-creating or stand-alone messages. The following diagram illustrates how this
works:
For this scenario, there are two main functions, PCFA insertion and PCFA caching:
• PCFA insertion—Using the insert-reg-cache and delete-and-respond configuration values, the Oracle
Communications Session Border Controller adds the PCFA to all SIP requests and to the response on the S-CPCF
facing the SIP interface. However, only dialog-creating and standalone requests, and responses to each of those,
update the Oracle Communications Session Border Controller and accounting information. Such requests do not
have a To tag, and responses do not appear in established dialogs. The Oracle Communications Session Border
Controller inserts the PCFA into provisional (1XX) and success (2XX) responses, with the exception of the 100
Trying response.
You can use SIP header manipulation rules (HMR) to remove any unwanted headers.
• PCFA caching—When you use either of the insert-reg-cache and delete-and-respond configuration values, the
Oracle Communications Session Border Controller uses the latest cached copy of a PCFA header to insert into
requests and responses. The Oracle Communications Session Border Controller does not cache any PCFA headers
it receives on SIP interfaces using the none, insert, or insert-reg-cache modes because this type of SIP interface
faces the UE making its replacement headers ones from the core.
Though there can be various sources for the latest cached copy, the PCFA header received as part of a dialog-
creating or standalone request has highest precedence. This PCFA header is then stored as the latest cached value
for that dialog. That is, for each specific dialog, the Oracle Communications Session Border Controller the PCFA
is cached separately so it can add the most specific PCFA to the message—and is added to any message for the
dialog.
When there is no cache PCFA for a specific dialog, the Oracle Communications Session Border Controller uses
the registration cache entry as the latest cached copy. And when there is no entry in the registration, the PCFA
uses the ccf-address and ecf-address values from the SIP interface.
The latest cached copy or the ccf-address is the value reported in the RADIUS VSA Acme-Session-
Charging-Function-Address; this VSA is used for both of the new modes.
Note: Only the ccf-address is reported in RADIUS records; the ecf-address is not.
Acme-Session-Charging-Vector 54 string
Acme-Session-Charging-Function-Address 55 string
• delete-and-respond—To be configured on the SIP interface facing the S-CPCF, configures the Oracle
Communications Session Border Controller to strip out the latest cached PCFA from the core side. The Oracle
Communications Session Border Controller then remembers this PCFA and uses it in communications sent to
the core.
5. operator-identifier—Set the operator identifier value to be inserted into a P-Charging-Vector header. The
direction of the call determines whether this value is inserted into the orig-ioi or the term-ioi parameter in the P-
Charging-Vector header. This string MUST begin with an alphabetical character.
6. charging-function-address-mode—Set the charging function address mode you want to use. The
default value is pass. The valid values are:
• none—Pass the P-Charging-Function-Address header received in an incoming SIP message untouched as the
message is forwarded out of the Oracle Communications Session Border Controller , but does not include icid-
value in accounting records.
• pass—Pass the P-Charging-Function-Address header received in an incoming SIP message untouched as the
message is forwarded out of the Oracle Communications Session Border Controller , includes icid-value in
accounting records.
• delete—Delete the P-Charging-Function-Address header received in an incoming SIP message before it is
forwarded out of the Oracle Communications Session Border Controller .
• insert—Insert the P-Charging-Function-Address header in an incoming SIP message that does not contain
the P-Charging-Function-Address header. If the incoming message contains the P-Charging-Function-Address
header, the Oracle Communications Session Border Controller will overwrite the P-Charging-Function-
Address header with its values. This option always uses the ccf-address and ecf-address static
values.
• insert-reg-cache—To be configured on the SIP interface facing the UE, configures the Oracle
Communications Session Border Controller to replace the PCFA with the most recently cached value rather
than the ccf-address and ecf-address you set to be static in your configuration. The cached values
come from one of the following that the Oracle Communications Session Border Controller has received most
recently: request, response, registration, or local configuration.
• delete-and-respond—To be configured on the SIP interface facing the S-CPCF, configures the Oracle
Communications Session Border Controller to strip out the latest cached PCFA from the core side. The Oracle
Communications Session Border Controller then remembers this PCFA and uses it in communications sent to
the core.
Note: The default settings for this parameter and for charging-vector-mode are pass for new
SIP interface configurations. If you are upgrading and there are pre-existing SIP interfaces in your
configuration, the defaults become none.
7. ccf-address—Set the CCF address value that will be inserted into the P-
Charging-Function-Address header.
8. ecf-address—Set the ECF address value that will be inserted into the P-
Charging-Function-Address header.
9. Save your work using the ACLI done command.
Charging Correlation
IMS is based on a distributed architecture that can result in multiple network entities becoming involved in providing
access and services. Operators require the ability to charge for the access and services as they provide. This
necessitates coordination among the network entities (for example, SIP proxies), which includes correlating charging
records generated from different entities that are supporting the same session.
Charging correlation is supported in Release SC-X7.1.2 and later.
During initial provisioning of session information, the Oracle Communications Session Border Controller,
functioning as a P-CSCF, indicates its support for charging correlation by subscribing to access network charging
information from the PCRF (Policy Charging Rule Function). In a typical exchange, the subscription is requested
with an AA-Request (AA-R) command that contains the Specific-Action (Type 513) and AF-ChargingIdentifier (Type
505) AVPs. The Specific-Action AVP is set to 1, (CHARGING_CORRELATION_EXCHANGE), requesting that the
PCRF provide new and updated charging information as such information becomes available.
The PCRF responds with an AA-Answer (AA-A) that usually contains one or more associated Access-Network-
Charging-Identifier (Type 502) and an Access-Network-Charging-Address (Type 501) AVPs. The Access-Network-
Charging-Address AVP contains the IP address of a network entity that is charging for session services. The Access-
Network-Charging-Identifier associated with the entity identified by the Access-Network-Charging-Address AVP.
This identifier is applied to all traffic/media flows within the current session.
The AA-A can contain an IP-CAN-Type (Type 1027) AVP that indicates the type of Connectivity Access Network
and an associated RAT-Type AVP that provides more specific information as to the access technology. For IMS
charging correlation, the IP-CAN-Type AVP can contain one or two values: 0 (3GPP), or 5 (3GPP-EPS).
In some cases, the PCRF may not have the requested charging information at the time of the initial AA-R. When
information becomes available, the PCRF sends the data to the P-CSCF via a Re-Auth-Request (RAR) command,
which is then acknowledged by the P-CSCF with a Re-Auth-Answer (RAA) command.
Upon receiving charging information from the PCRF, the P-CSCF saves the data in the context of the associated SIP
session. Saved data is used to populate the P-Charging-Vector SIP header.
that have unknown, untrusted, or different policies regarding early media; and it has the capability to gate (enable/
disable) the flow of early media to/from user equipment.
P-Early-Media-Header Usage
The syntax of the P-Early-Media header field is as follows.
P-Early-Media = "P-Early-Media" HCOLON[ em-param *(COMMA em-param) ]
em-param = "sendrecv" / "sendonly" / "recvonly" / "inactive" /
"gated" /
"supported" / token
The P-Early-Media header is used for requesting and authorizing requests for backward and/or forward early media.
The P-Early-Media header field in an INVITE request contains the "supported" parameter. If P-CSCF is part of the
trusted domain, then it must decide whether to insert or delete the P-Early-Media header field before forwarding the
INVITE. The P-CSCF upon receiving the P-Early-Media header field in a message towards the UAC needs to verify
that the early media request comes from an authorized source. If a P-Early-Media header field arrives from either an
untrusted source, a source not allowed to send backward early media, or a source not allowed to receive forward early
media, then it may remove the P-Early-Media header field or alter the direction parameter(s) of the P-Early-Media
header field before forwarding the message, based on local policy.
The P-Early-Media header field with the "supported" parameter in an INVITE request indicates that the P-CSCF on
the path recognizes the header field. The P-Early-Media header field includes one or more direction parameters where
each has one of the values: "sendrecv", "sendonly", "recvonly", or "inactive", following the convention used for SDP
stream directionality. Each parameter applies, in order, to the media lines in the corresponding SDP messages
establishing session media. The parameter value "sendrecv" indicates a request for authorization of early media
associated with the corresponding media line, both from the UAS towards the UAC and from the UAC towards the
UAS. The value "sendonly" indicates request for authorization of early media from the sender to the receiver and not
in the other direction. The value "recvonly" indicates a request for authorization of early media from the receiver, and
not in the other direction. The value "inactive" indicates either a request that no early media associated with the
corresponding media line be authorized, or a request for revocation of authorization of previously authorized early
media. Each parameter applies, in order, to the media lines in the corresponding SDP lines. Unrecognized parameters
are discarded and non-direction parameters are ignored. If there are more direction parameters than media lines, the
excess are silently discarded. If there are fewer direction parameters than media lines, the value of the last direction
parameter applies to all remaining media lines. The P-Early-Media header field in any message within a dialog
towards the sender of the INVITE request can also include the non-direction parameter "gated" to indicate that a
network entity on the path towards the UAS is already gating the early media, according to the direction parameter(s).
As defined in 3GPP TS 24.229, IP multimedia call control protocol based on Session Initiation Protocol (SIP) and
Session Description Protocol (SDP); Stage 3 both the P-CSCF and IBCF may add, remove, or modify, the P-Early-
Media header field within forwarded SIP requests and responses according to procedures in RFC 5009.
The P-CSCF can use the P-Early-Media header field for the gate control procedures, as described in 3GPP TS 29.214.
Prior to Version S-CZ7.2.0, this capability was based on policy configuration, not examination of the P-Early-Media
header.
In the current implementation, if the configuration option “early-media-allow” is set to none, the Oracle
Communications Session Border Controller will send the Flow-Status AVP in any AAR request set to disable until the
final response.
Functional Design
Acceptance of and authorization for early media is accomplished with two new ACLI parameters -- p-early-media-
header and p-early-media-direction, which are added to SIP interface configuration in Version S-CZ7.2.0 and later
releases.
The p-early-media-header parameter will enable the feature when the value is set to either “add” or “modify”. The
p-early-media-header and p-early-media-direction should be configured on egress interface of the incoming
message. The values for parameter p-early-media-direction are “sendrecv, sendonly, recvonly, inactive”. It is a list
and each configured value corresponds to the m-line in the SDP. If the number of configured values is more than the
number of m-lines in the SDP, the excess configured values are ignored. If the number of configured value is less than
the number of m-lines in the SDP, the last configured value is used for all the m-lines.
The following illustrations show the ingress and egress sip-interface configuration.
P-Early-Media headers in Re-Invites are ignored. If the SDP contains Content-Disposition: early-session the P-Early-
Media header is ignored.
Endpoint is considered trusted or untrusted based on the configuration on the ingress sip-interface of the P-CSCF. Sip-
interface has the configuration parameter “trust-mode”. If the “trust-mode” is set to “none” then nobody is trusted in
sip-interface. By default the value is “all”. Possible values are <all, agents-only, realm-prefix, registered, none>.
For multiple dialogs due to forking, P-CSCF will identify the media associated with a dialog, and then setup early
media flow for the selected media. The configuration elements restricted-latching in realm-config, and latching in
media-router should be enabled.
The following 3 tables detail early media implementation details.
Message --> INVITE (no INVITE 18x (no 18x (with UPDATE/ UPDATE/ INVITE/18x
PEM) (with PEM) PEM) PEM) PRACK (no PRACK /UPDATE/
PEM) (with PEM) PRACK
p-early-media- Add header Add Add header Add the Add header Add the Discard the
header-“add” with "supported" with "gated" with "gated" header
"supported" value if not configured value. Setup configured value . Setup
p-early-media-
value. Setup present. value and the flows value and the flows
direction -
flows based Setup flows "gated" based on the "gated" based on the
“sendonly
on based on value. value in the value. Setup value in the
configured the value in header. flows based header
value. the header on
configured
value.
p-early-media- Pass the Add Pass the Modify Pass the Modify Discard the
header-"modify" message "supported" message header with message header with header
transparently. value if not transparently. configured transparently. configured
p-early-media-
present. value and value and
direction
Setup flows add "gated" add "gated"
-"sendonly"
based on value. Setup values. Setup
the value in flows based flows based
the header. on on
configured configured
value. value.
p-early-media- Add header Add Add header Pass the Add header Pass the Discard the
header-"add" with "supported" with default message with default message header
"supported" value if not value and transparently. value and transparently.
No p-early-
value. Setup present. "gated" "gated"
media-direction
flows based Setup flows value. Setup value. Setup
on default based on flows based flows based
value. the value in on default on default
the header. value. value.
p-early-media- Pass the Add Pass the Modify Pass the Modify Discard the
header-"modify" message "supported" message header with message header with header
transparently. value if not transparently. default value transparently. configured
No p-early-
present. and "gated" value and
media-direction
Setup flows values. Setup add "gated"
based on flows based values. Setup
the value in on flows based
the header. configured on
value. configured
value.
Message --> INVITE (no INVITE 18x (no 18x (with UPDATE/ UPDATE/ INVITE/18x
PEM) (with PEM) PEM) PEM) PRACK (no PRACK /UPDATE/
PEM) (with PEM) PRACK
p-early-media- Add header Discard the Add header Discard the Add header Discard the Discard the
header-“add” with header. with header. with header. header .
"supported" configured configured
p-early-media- .
value. Setup value and value and
direction -
flows based "gated" "gated"
“sendonly
on value. Setup value. Setup
configured the flows flows based
value. based on on
configured configured
value. value.
p-early-media- Pass the Discard the Pass the Discard the Pass the Discard the Discard the
header-"modify" message header. message header. message header. header.
transparently. transparently. transparently.
p-early-media-
direction
-"sendonly"
p-early-media- Add header Discard the Add header Discard the Add header Discard the Discard the
header-"add" with header. with default header. with default header. header.
"supported" value and value and
No p-early-
value. Setup "gated" "gated"
media-direction
flows based value. Setup value. Setup
on default flows based flows based
value. on default on default
value. value.
p-early-media- Pass the Discard the Pass the Discard the Pass the Discard the Discard the
header-"modify" message header. message header. message header. header.
transparently. transparently. transparently.
No p-early-
media-direction
Message --> INVITE (no INVITE 18x/UPDATE/ 18x (with UPDATE/ INVITE/18
PEM) (with PEM) PRACK (no PEM) PRACK (no x/
PEM) PEM) UPDATE/
PRACK
Parameters
configured on egress
interface
p-early-media-header- Pass the Delete the Pass the Delete the Delete the N/A
“add” message header from message header from header from
transparently. the transparently the the message.
p-early-media-
message. message.
direction -“sendonly
p-early-media- Pass the Delete the Pass the Delete the Delete the N/A
header-"modify" message header from message header from header from
transparently. the transparently. the the message.
p-early-media-
message. message.
direction -"sendonly"
p-early-media- Pass the Delete the Pass the Delete the Delete the N/A
header-"add" message header from message header from header from
transparently. the transparently the the message.
No early-media-
message. message.
direction
p-early-media- Pass the Delete the Pass the Delete the Delete the N/A
header-"modify" message header from message header from header from
transparently. the transparently. the the message.
No early-media-
message. message.
direction
selection: 1
ORACLE(sip-interface)#
3. Use the p-early-media-header parameter to enable P-Early-Media SIP header support. This parameter is disabled
by default.
• disabled—(the default value) disables support
• add—enables support and allows the Oracle Communications Session Border Controller to add the P-Early-
Media header to SIP messages.
• modify—enables support and allows the Oracle Communications Session Border Controller to modify or
strip the P-Early-Media header in SIP messages.
P-Visited-Network-ID Header
The Oracle Communications Session Border Controller's IMS support also includes the insertion of a P-Visited-
Network-ID header into SIP messages when applicable. When a UE sends a dialog-initiating request (e.g.,
REGISTER or INVITE message) or a standalone request outside of a dialog (e.g., OPTIONS) to the P-CSCF, the
Oracle Communications Session Border Controller inserts the P-Visited-Network-ID header into the SIP message as
it enters into the destination network.
The P-Visited-Network ID header will be stripped from SIP messages forwarded into untrusted networks as expected.
The content of a P-Visited-Network-ID header is a text string that identifies the originating UE's home network. This
string is user-configurable.
4. Type select and the number of the pre-configured sip interface you want to configure.
ORACLE(sip-interface)# select 1
5. Type network-id <space> <network ID string> and press Enter. This completes the configuration of the P-
Visited-Network-ID string for a given SIP interface.
ORACLE(sip-interface)# network-id examplenetworkid
6. Save your work using the ACLI done command.
Inbound INVITE Contains: Validate Against Implicit Outbound Invite Created With:
Registration Set (all P-Preferred-Identity headers
are removed)
The Oracle Communications Session Border Controller can create a second P-Asserted-Identity header by
configuring the add-second-pai option in the SIP config. Once a combination of SIP URIs and/or TEL URIs in the
inbound P-Preferred-Identity header are validated against the IRS, the Oracle Communications Session Border
Controller forwards the emergency INVITEs with two P-Asserted-Identity headers to the E-CSCF. The behavior is
based upon the URI type received in the P-Preferred-Identity header and whether those values validate against the
IRS list.
Inbound INVITE Contains: Validate Against Implicit Outbound Invite Created With:
Registration Set (all P-Preferred-Identity headers
are removed)
Inbound INVITE Contains: Validate Against Implicit Outbound Invite Created With:
Registration Set (all P-Preferred-Identity headers
are removed)
If the INVITE does not include a P-Preferred-Identity header and does not include a P-Asserted-Identity header, or
the value in the original P-Preferred-Identity or P-Asserted- Identity header is not contained in the IRS, or the URI
from the From: header is not the in the IRS, then default public user identity is inserted into a P-Asserted- Identity
header in the egress message. (The default public user identity is the first on the list of URIs in the P-Associated-URI
header.)
If the strict-3gpp-pai-compliance option is configured in the outbound SIP interface, the first P-Asserted-Identity
header also includes the display name.
Inbound Invite Contains Validate Against Implicit Outbound Invite Created With:
Registration Set:
Old Behavior
Before the introduction of this change, the Oracle Communications Session Border Controller associated the PAU
only with the first IMPU request. The Oracle Communications Session Border Controller considered any request
made from that PAU to be a request from the first user, regardless of the request’s originating IP.
When the SIP interface facing the UE had the reg-via-key and reg-via-match options configured, the Oracle
Communications Session Border Controller rejected the request from the second user with the PAU as the From or the
PPI. Because it only associates the PAU with the first user, the Oracle Communications Session Border Controller
issued a 403 message.
New Behavior
Your Oracle Communications Session Border Controller now associates the PAU with both the first and second
IMPU. The Oracle Communications Session Border Controller considers any request made from that PAU to be a
request from the user at the top of its registration cache table irrespective of where the request originated (the IP).
When the SIP interface facing the UE has the reg-via-key and reg-via-match options configured, and the
request from the user with the PAU as the From or with PPI, the Oracle Communications Session Border
Controllermatches to the proper user based on the source IP.
Surrogate Registration
The Oracle Communications Session Border Controller surrogate registration feature lets the Oracle Communications
Session Border Controller explicitly register on behalf of a Internet Protocol Private Branch Exchange (IP-PBX).
After you configure a surrogate agent, the Oracle Communications Session Border Controller periodically generates a
REGISTER request and authenticates itself using a locally configured username and password, with the Oracle
Communications Session Border Controller as the contact address. Surrogate registration also manages the routing of
class from the IP-PBX to the core and from the core to the IP-PBX.
The Oracle Communications Session Border Controller registers on behalf of the IP-PBXes and then stores the
associated URIs returned by the Serving Call Session Control Function (S-CSCF). The calls from the phones behind
the IP-PBX can be routed based on the cache entry the Oracle Communications Session Border Controller creates
after it receives each phone’s associated URI. Calls are routed using the service route, local policy or any other
routing mechanism based on the associated session agent or session agent group. The Oracle Communications
Session Border Controller also supports multiple registrations on behalf of a IP-PBX because the IP-PBX can support
thousands of phones, but the registrar might only be able to send 10 to 20 associated URIs in response to a single
registration.
The Oracle Communications Session Border Controller replaces the Contact URI for requests from the IP-PBX to the
core to match the registered value. For calls from the IMS core to the IP-PBX, the Oracle Communications Session
Border Controller replaces the Request-URI username with P-Called-Party-ID/To-URI username. The IMS cores
sends INVITES for the phones behind the IP-PBX with the registered Contact URI as the Request-URI instead of the
AoR of the phones. The IP-PBX needs to see the phone’s AoR in the Request-URI.
Registration
The Oracle Communications Session Border Controller uses the configuration information of the surrogate agent that
corresponds to a specific IP-PBX. After the surrogate agents are loaded, the Oracle Communications Session Border
Controller starts sending the REGISTER requests on their behalf. (You can configure how many requests are sent.)
The SIP surrogate agent supports the ability to cache authorization or proxy-authorization header values from a
REGISTER 401, 407, and 200 OK messages and reuse it in subsequent requests, such as in an INVITE. This allows
the Oracle Communications Session Delivery Manager to support authorization of subsequent requests in cases such
as, when a customer PBX doesn't support registration and authentication. It also supports the generation of
authorization/proxy-authorization header if subsequent requests get challenged with a 401/407 response.
If the Oracle Communications Session Border Controller receives 401 or 407 responses to REGISTER, requests, it
will use the Message Digest algorithm 5 (MD5) digest authentication to generate the authentication information. You
need to specify the password. The Oracle Communications Session Border Controller also supports authentication
challenge responses with the quality of protection code set to auth (qop=auth), by supporting the client nonce
(cnonce) and nonce count parameters.
The Oracle Communications Session Border Controller creates a registration cache entry for each of the AoRs for
which it is sending the REGISTER requests. When the Oracle Communications Session Border Controller receives
the associated URIs, it checks whether the customer host parameter is configured. If it is configured, the Oracle
Communications Session Border Controller changes the host in the received Associated-URI to the customer host. If
it is not configured, the Oracle Communications Session Border Controller does not change the Associated-URI. It
makes the registration cache entries that correspond to each of the Associated-URIs. The From header in the INVITE
for calls coming from the IP-PBX should have one of the Associated-URIs (URI for a specific phone). If the Oracle
Communications Session Border Controller receives a Service-Route in the 200 (OK) response, it stores that as well.
The Oracle Communications Session Border Controller uses the expire value configured for the REGISTER requests.
When it receives a different expire value in the 200 OK response to the registration, it stores the value and continues
sending the REGISTER requests once half the expiry time has elapsed.
REGISTER requests are routed to the registrar based on the configuration. The Oracle Communications Session
Border Controller can use the local policy, registrar host and the SIP configuration’s registrar port for routing.
If the Oracle Communications Session Border Controller is generating more than one register on behalf of the IP-
PBX, the user part of the AoR is incremented by 1 and the register contact-user parameter will also be incremented by
1. For example, if you configure the register-user parameter as caller, the Oracle Communications Session Border
Controller uses caller, caller1, caller2 and so on as the AoR user.
mechanism it should use to route this INVITE to the IP-PBX. It uses the customer-next-hop configuration parameter
to determine if it routes this call to the session agent, the session agent group, or directly to a particular IP address.
SIP
If the customer-next-hop parameter points to a SIP session agent or the SIP session agent group, the Oracle
Communications Session Border Controller creates a Route header using the session agent and modifies the Request-
URI. It changes the user portion of the Request-URI to either the user portion of the P-Called-Party-ID header, if
present, or to the user portion of the To header. The Oracle Communications Session Border Controller also changes
the host portion of the Request-URI to the hostname configured in the customer-host configuration parameter. It
makes the change because the domain name on the core side can be different than the domain name on the access IP-
PBX side. The Oracle Communications Session Border Controller then uses the added Route header to properly route
the call.
H.323
If the session agent or the session agent group configured for the customer-next-hop parameter references an H.323
device, the Oracle Communications Session Border Controller sends the INVITE to its interworking task. If a session
agent group is being used, the parameter containing the session agent group name is added to the Request-URI. The
host portion of the Request-URI will point to the interworking IP address and the port is changed to 1720.
If a session agent is used, the Oracle Communications Session Border Controller uses it to route the call properly to
the interworking task to take care of the H.323 call setup.
Note: Even though the customer-next-hop field allows specification of a SAG or FQDN, the functionality
will only support these values if they resolve to a single IP address. Multiple IP addresses, via SAG, NAPTR,
SRV, or DNS record lookup, are not allowed.
3. Type surrogate-agent and press Enter. The prompt changes to indicate you can configure individual parameters.
ORACLE(session-router)# surrogate-agent
ORACLE(surrogate-agent)#
From this point, you can configure surrogate agent parameters. To view all surrogate agent configuration
parameters, enter a ? at the system prompt.
4. register-host—Enter the registrar’s hostname to be used in the Request-URI of the REGISTER request.
This name is also used as the host portion of the AoR To and From headers.
5. register-user— Enter the user portion of the AoR (Address of Record).
6. state—Set the state of the surrogate agent to indicate whether the surrogate agent is used by the application.
The default value is enabled. The valid values are:
• enabled | disabled
7. realm-id— Enter the name of realm where the surrogate agent resides (where the IP-PBX proxy resides).
There is no default.
8. description—Optional. Enter a description of this surrogate agent.
9. customer-host—Optional. Enter the domain or IP address of the IP-PBX, which is used to determine whether
it is different than the one used by the registrar.
10. customer-next-hop—Enter the next hop to this surrogate agent:
• session agent group:
SAG: <session agent group name>
• session agent:
<hostname> or <IPV4>
• specific IP address:
<IPV4> or <IPV4: port>
11. register-contact-host—Enter the hostname to be used in the Contact-URI sent in the REGISTER
request. This should always point to the Oracle Communications Session Border Controller. If specifying a IP
address, use the egress interface’s address. If there is a SIP NAT on the registrar’s side, use the home address in
the SIP NAT.
12. register-contact-user—Enter the user part of the Contact-URI that the Oracle Communications Session
Border Controller generates.
13. password—If you are configuring the auth-user parameter, you need to enter the password used in case the
registrar sends the 401 or 407 response to the REGISTER request.
14. register-expires—Enter the expires in seconds to be used in the REGISTER requests. The default value is
600,000 (1 week). The valid range is:
• Minimum—0
• Maximum—999999999
15. replace-contact—This specifies whether the Oracle Communications Session Border Controller needs to
replace the Contact in the requests coming from the surrogate agent. If this is enabled, Contact will be replaced
with the Contact-URI the Oracle Communications Session Border Controller sent in the REGISTER request. The
default value is disabled. The valid values are:
• enabled | disabled
16. route-to-registrar—This indicates whether requests coming from the surrogate agent should be routed to
the registrar if they are not explicitly addressed to the Oracle Communications Session Border Controller. The
default value is enabled. The valid values are:
• enabled | disabled
17. aor-count—Enter the number of registrations to do on behalf of this IP-PBX. If you enter a value greater than
1, the Oracle Communications Session Border Controller increments the register-user and the register-contact-
user values by that number. For example, if this count is 3 and register-user is john then users for three different
register messages will be john, john1, john2. It does the same for the register-contact-user values. The default
value is 1. The valid range is:
• Minimum—0
• Maximum—999999999
18. options—Optional. Enter non-standard options or features.
19. auth-user—Enter the authentication user name you want to use for the surrogate agent. This name is used
when the Oracle Communications Session Border Controller receives a 401or 407 response to the REGISTER
request and has to send the REGISTER request again with the Authorization or Proxy-Authorization header. The
name you enter here is used in the Digest username parameter. If you do not enter a name, the Oracle
Communications Session Border Controller uses the value of the register-user parameter.
20. Save and activate your configuration.
Example
The following example shows the surrogate agent configuration.
surrogate-agent
register-host acmepacket.com
register-user 234567
state enabled
realm-id public
description
customer-host acmepacket.com
customer-next-hop 111.222.333.444
register-contact-host 111.222.5.678
register-contact-user eng
password
register-expires 600000
replace-contact disabled
route-to-registrar enabled
aor-count 1
options
auth-user
last-modified-date 2006-05-04 16:01:35
Without Enhancements
Without the enhancements configured, the Oracle Communications Session Border Controller’s surrogate agent
performs a series of registrations based on count when the system boots or when its configuration changes. It only
attempts to register each user once. Although the surrogate agent uses the same retry mechanism used for SIP client
transactions, it does not attempt further if it receives a failure response until the entry expires. When it receives 401,
403, or 407 responses to requests that include authentication, the surrogate agent’s automatic incrementing
mechanism appends a number to the end of each registered username. Always starting at one, this number cannot
appear in any other position in the username.
With Enhancements
With the enhancements configured, the Oracle Communications Session Border Controller supports:
• Registration retry—You can configure the surrogate agent to retry registration when after a failure, timeout, or
transport error. You can set how many times the Oracle Communications Session Border Controller will attempt to
register each user; a setting of zero means retries are umlimited. You can also define the number of seconds to
wait before initiating a retry. The Oracle Communications Session Border Controller tracks each registration retry
count and timers, and sends an SNMP trap when it reaches the maximum number of retries, which signifies failed
registration.
• Authentication loop prevention—Authentication loops can occur in previous releases when the Oracle
Communications Session Border Controller resends a registration request with authentication in response to 401,
403, or 407 responses (indicating, for example, that there might be a password error). Using the new
enhancements, the Oracle Communications Session Border Controller only allows permits the retransmission of
one request. It now considers further 401, 403, or 407 responses to be errors and initiates the retry mechanism.
• Automatic increment enhancements—Now, the automatic increment works with the caret (^) in the register-user
and register-contact-user fields. These carets define where the automatically generated incrementing number is
inserted in the username. You can also use multiple carets to define leading zeroes to insert; for example, the entry
user^^^^ will become user0001. You can also define the starting integer for the incrementing registrations. For
example, setting the AoR count to 20, the count start to 5, and using the value user^^^^ for register-user and
register-contact-user results in the incremented user registrations user0005 through user0025.
4. count-start—Change this parameter from its default of 1 if you want the automatic increment count to start
at any other number when the Oracle Communications Session Border Controller performs multiple registrations.
The default value is 1. The valid range is:
• Minimum—0
• Maximum—999999999
User Contacts Displays the registered SIP URI for the surrogate agent. In case of surrogate agents configured with
block of numbers, one user contact (SIP NUI) for each number within the block of numbers.
Last Registered at Displays the last time when the agent registered with the Registrar. This time will change with
every renewal registry at expiration. If the surrogate user has not successfully registered, this
field will say never registered
State Displays the current state of the surrogate agent. This State field confirms the state of two timers used when a
surrogate agent is being configured: 1. register-expires and 2. register-retry-time. When the register-retry-
time expires, the state will be set to unregistered as it continues to try to register. When the register-expires
time expires and max-register-attempts is exhausted, the state is set to failed.
When there are no surrogate agents configured on the Oracle Communications Session Border Controller , the output
for show registration sipd surrogate-agents, show registration sipd surrogate-agents by-realm <realm-id> and
show registration sipd surrogate-agents unregistered shows "No matching entries found!".
When all the surrogate agents are registered and none in an unregistered state, the output for show registration sipd
surrogate-agents unregistered shows "No matching entries found!".
Existing ACLI command clear-cache registration sipd restarts the registration process for the surrogate agent.
• You can configure the Oracle Communications Session Border Controller with an option to keep it from using the
Service-Route header for REGISTER requests when sent to an out-of-service session agent. The enhancements
make this behavior the default—because otherwise these REGISTER requests fail.
• If the initial re-registration is challenged, the subsequent REGISTER will be sent to the same target as its prior
REGISTER.
When implicit service route support is enabled, the Oracle Communications Session Border Controller stores the
Service Route URIs from the Service-Route headers that are included in 200 OK responses to REGISTER messages.
The Service Route URIs are included in the Route headers in subsequent Request messages, except for REGISTER
messages.
The Oracle Communications Session Border Controller also supports the ability to keep the loose-route parameter
from being included in the implicit Route URI that the Oracle Communications Session Border Controller generates
and includes as a Route header in the Request messages.
Once an endpoint registers successfully, the Oracle Communications Session Border Controller caches the Service-
Route header (if any) to use for routing all subsequent requests from the endpoint—with the exception of any
subsequent REGSITER requests.
You can set whether or not you want the Oracle Communications Session Border Controller to route subsequent
REGISTER requests using the cached Service Route, and whether the endpoint is engaged in an active session
through the Oracle Communications Session Border Controller. If you decide not to use the Service Route for
endpoints engaged in active sessions, then the Oracle Communications Session Border Controlleruses the local policy
to make routing decisions.
For endpoints not in found in the Oracle Communications Session Border Controller’s registration cache, the Oracle
Communications Session Border Controller again uses the local policy to make routing decisions.
You must save your configuration for these changes to take place, allowing you to fall back to the previous software
image.
4. options—Set the options parameter by typing options, a Space, the option name reg-via-match with a
plus sign in front of it, and then press Enter.
ORACLE(sip-interface)# options +reg-via-match
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 option to this 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.
IMS-AKA
The Oracle Communications Session Border Controller supports IP Media Subsystem-Authentication and Key
Agreement (IMS-AKA).
Defined in 3GPPr7 (specifications in TS 33.203 and call flows in TS 24.228), IMS-AKA can be used as a framework
for authentication and for securing the signaling path between a UE and the Oracle Communications Session Border
Controller (when the Oracle Communications Session Border Controller is acting as a P-CSCF or as a B2BUA)
across the Gm interface.
In addition, the Oracle Communications Session Border Controller’s serving as an IMS-AKA termination point is
valuable because it allows IMS-AKA use behind by multiple endpoints sitting behind a NAT device. IMS-AKA
support also works when there are no NAT devices between endpoints and the Oracle Communications Session
Border Controller acting as a P-CSCF, and when the Oracle Communications Session Border Controller sits behind a
third-party P-CSCF. In addition, you can use IMS-AKA when the endpoint uses SIP UDP.
Requirements
IMS-AKA use assumes that you have installed the appropriate IPSec module on your Oracle Communications
Session Border Controller, or that it has come from Oraclewith those modules pre-installed. IMS-AKA will not work
without this hardware.
In addition, your configuration must have SIP registration caching enabled.
Monitoring
The ACLI show sipd endpoint-ip command is updated to show the IMS-AKA parameters corresponding to
each endpoint. The display shows the algorithms used, the ports used, and the security parameter indexes (SPIs) used.
In addition, the show sa stats command now shows the security associations information for IMS-AKA.
IPSec IMS-AKA
Compliance with the VoLTE specification (GSMA PRD IR.92) requires cluster member support for IPsec IMS-AKA
(IP Multimedia Services Authentication and Key Agreement) as defined in 3GPP TS 24.299, IP Multimedia Call
Control Protocol Based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP): Stage 3, and TS
33.203, 3G Security: Access Security for IP-based Services.
Support for IMS-AKA requires no new additional configuration elements.
Sec-Agree
Version S-CZ7.2.0 introduces support for RFC 3329, Security Mechanism Agreement for the Session Initiation
Protocol, commonly referred to as Sec-Agree. The RFC defines three SIP headers, Security-Client, Security-Server,
and Security-Verify that provide the ability for SIP UAs and other SIP entities (servers, proxies, and registrars) to
negotiate next-hop security mechanisms. Note that this initial implementation does not provide support for server-
initiated security negotiation, nor does it support media-plane security. That is, support is limited to client-initiated
negotiation during initial registration, and to signalling security.
Currently the P-CSCF functionality includes support for IMS-AKA feature for VoLTE deployments. In order to
support RCS clients along with VoLTE P-CSCF functionality needs to be enhanced to support RFC 3329, Security
Mechanism Agreement for the Session Initiation Protocol (commonly referred to as Sec-Agree), which includes
support for TLS as security mechanism.
Sec-Agree defines three SIP headers, Security-Client, Security-Server and Security-Verify, to negotiate security
agreements during initial REGISTER transactions. Header definitions are as follows:
security-client = "Security-Client" HCOLON
sec-mechanism *(COMMA sec-mechanism)
security-server = "Security-Server" HCOLON
sec-mechanism *(COMMA sec-mechanism)
security-verify = "Security-Verify" HCOLON
sec-mechanism *(COMMA sec-mechanism)
sec-mechanism = mechanism-name *(SEMI mech-parameters)
mechanism-name = ( "digest" / "tls" / "ipsec-ike" /
"ipsec-man" / token )
mech-parameters = ( preference / digest-algorithm /
digest-qop / digest-verify / extension )
preference = "q" EQUAL qvalue
qvalue = ( "0" [ "." 0*3DIGIT ] )/ ( "1" [ "." 0*3("0") ] )
digest-algorithm = "d-alg" EQUAL token
digest-qop = "d-qop" EQUAL token
digest-verify = "d-ver" EQUAL LDQUOT 32LHEX RDQUOT
extension = generic-param
The Security-Client header contains one or more security mechanisms and associated parameters proposed by the
initiating client. This initial implementation supports two security mechanisms: TLS and ipsec-3gpp.
The Security-Server header contains the security mechanism chosen by the server from those mechanisms proposed
by the client.
The Security-Verify header contains the contents of the Security-Server header.
Two additional header fields, Require and Proxy-Require, are also used in support of Sec-Agree negotiations. Both
headers are required in client transmissions.
(1) REGISTER
Proxy-Require:sec-agree
Security-Client: ipsec-3gpp;alg=hmac-md5-96;ealg=aes-
cbc;prot=esp;mod=trans;spi-c=8765423;port-c=7524;spi-s=1234563;port-s=1358,
ipsec-3gpp;alg= hmac-sha-1-96;ealg=aes-cbc;prot=esp;mod=trans;spi-
c=8765423;port-c=7524;spi-s=1234563;port-s=1358, tls
(2) REGISTER
Authorization: Digest
uri="sip:ims.mnc007.mcc262.3gppnetwork.org",username="262073900320132@ims.mnc0
07.mcc262.3gppnetwork.org",response="",realm="ims.mnc007.mcc262.3gppnetwork.or
g",nonce=""
(No integrity-protected field will be present if TLS is selected as the
security mechanism)
(3) 401
Security-Server: tls
(4) REGISTER
Proxy-Require: sec-agree
Security-Verify: tls
(5) REGISTER
Authorization: Digest
username="262073900320132@ims.mnc007.mcc262.3gppnetwork.org",realm="imstest1.t
elefonica.de",uri="sip:ims.mnc007.mcc262.3gppnetwork.org",qop=auth,nonce="Ms8l
2xeF3l4lb0VO8fK3KFMSKLv1sQAATdN2NpFUCgU=",nc=00000001,cnonce="3063397945",algo
rithm=AKAv1-MD5,response="3779ff40a057f999a2f8288bbfafc10d", integrity-
protected=tls-pending
(1) REGISTER
(No Security-Client or Proxy-Require header present)
(2) REGISTER
Authorization: Digest
uri="sip:ims.mnc007.mcc262.3gppnetwork.org",username="262073900320132@ims.mnc0
07.mcc262.3gppnetwork.org",response="",realm="ims.mnc007.mcc262.3gppnetwork.or
g",nonce=""
(No integrity-protected field will be present)
(3) 401
(No Security-Server header present)
(4) REGISTER
(No Security-Client, or Security-Verify or Proxy-Require header present)
(5) REGISTER
Authorization: Digest
username="262073900320132@ims.mnc007.mcc262.3gppnetwork.org",realm="imstest1.t
elefonica.de",uri="sip:ims.mnc007.mcc262.3gppnetwork.org",qop=auth,nonce="Ms8l
2xeF3l4lb0VO8fK3KFMSKLv1sQAATdN2NpFUCgU=",nc=00000001,cnonce="3063397945",algo
rithm=AKAv1-MD5,response="3779ff40a057f999a2f8288bbfafc10d", integrity-
protected=tls-pending
Regardless of TLS Session setup procedure, if the newly added configurable item sec-agree feature is enabled, any
messages on unprotected port will be rejected except REGISTER messages or messages related to emergency
services.
For refresh registration, if the Sec_Agree occurred during Registration, it verifies for the presence or change of
Security-Client & Security-Verify headers, if they differ it will be rejected with 4xx response and also Authorization
header fields are verified irrespective of the above methods and if they differ with previous association it will be
rejected with 403 (Forbidden) response. Also when the refresh REGISTER is being forward to the core, it will set the
integrity-protected field to "tls-yes".
SEC-agree Configuration
1. Access the sip-interface configuration element.
ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# sip-interface
ORACLE(sip-interface)#
2. Select the sip-interface object to edit.
ORACLE(sip-interface)# select
<RealmID>:
1: realm01 172.172.30.31:5060
selection: 1
ORACLE(sip-interface)#
3. sec-agree-feature—Set this parameter to enable or disable for Sec-Agree support. By default, support is disabled.
4. sec-agree-pref—Configure this parameter to specify security protocol preferences.
• ipsec3gpp — support only IMS-AKA protocol
• tls — support only TLS protocol
• ipsec3gpp-tls — support both IMS-AKA and TLS, preferred protocol is IMS-AKA
• tls-ipsec3gpp — support both TLS and IMS-AKA, preferred protocol is TLS
5. Type done to save your configuration.
sip-ports
address sd-ip-address
port 5060
transport-protocol TCP
tls-profile
multi-home-addrs
allow-anonymous registered
ims-aka-profile profile
The ims-aka-profile configuration element defines the protected-server-port (PORT-SDS) and protected-client-port
(PORT-SDC). The protected-server-port is opened for both inbound TCP and UDP traffic. For example:
ims-aka-profile
name profile
protected-client-port PORT-SDC
1. If the TCP connection over a secure channel does not exist, the Caller will establish it.
2. The Caller initiates the call by sending SIP INVITE from its PORT-UEC to the P-CSCF's PORT-SDS.
3. The P-CSCF forwards the INVITE to the Caller. If not present, it will create a secure TCP connection from its
PORT-SDC to the callee's PORT-UES.
4. The INVITE is then forwarded to the Callee securely.
If the UE has an already active pair of security associations, then it shall use this to protect the REGISTER message.
If the S-CSCF is notified by the P-CSCF that the REGISTER message from the UE was integrity-protected it may
decide not to authenticate the user by means of the AKA protocol. However, the UE may send unprotected
REGISTER messages at any time. In this case, the S-CSCF shall authenticate the user by means of the AKA protocol.
In particular, if the UE considers the SAs no longer active at the P-CSCF, e.g., after receiving no response to several
protected messages, then the UE should send an unprotected REGISTER message.”
Prior releases failed to change the protected client ports after a successful re-registration.
Protected Ports
Within IMS networks, the P-CSCF provides the network access point and serves as the outbound proxy server for
user equipment -- smart phones, tablets, and similar devices. The UE must connect to the P-CSCF prior to registration
and initiation of SIP sessions. Connection to the P-CSCF, which can be in the user's home network, or in a visited
network if the UE is roaming, is accomplished using Dynamic Host Control Protocol (DHCP) P-CSCF discovery
procedures.
After successful discovery, the P-CSCF and UE negotiate IPSec security associations (SAs) which are used to
establish four protected (authenticated and encrypted using Encapsulating Security Payload protocol) ports between
the UE and the P-CSCF.
The four protected ports are shown in the following illustration:
As required by Section 7.4 of 3GPP TS 33.203, the protected client ports, one on the UE and the other on the Oracle
Communications Session Border Controller, must be changed after each successful re-registration.
To fulfill this requirement, this release adds a new attribute to the existing ims-aka-profile configuration object. This
attribute (end-protected-client-port) works in conjunction with start-protected-client-port
(protected-client-port in previous releases) to enable the identification of a pool of protected client ports,
which will be used for re-registration scenarios where the Oracle Communications Session Border Controller is
required to change the client port.
The Oracle Communications Session Border Controller creates new protected client ports, one on the UE and the
other on the Oracle Communications Session Border Controller, after every re-registration. Old protected client ports,
along with their associated SAs, are maintained for 30 seconds after re-registration to ensure correct handling or any
pending responses to previously transmitted messages.
After successful re-registration, the Oracle Communications Session Border Controller updates the registration cache
with updated port information and checkpoint with the HA peer, if present.
client-port. Note that the maximum supported pool contains 5 entries. Like the protected server port, the
protected client port pool should not overlap with the port range defined in the steering ports configuration using
the same IP address and the SIP interface. If there is overlap, the NAT table entry for the steering port used in a
call will prevent SIP messages from reaching the system’s host processor.
This parameter defaults to 0, which disables the function associated with the parameter. The valid range for values
is 1025 to 65535.
6. encr-alg-list—Enter the list of encryption algorithms. You enter more than one value by separating the
algorithms by <Spaces> and enclosing all values in quotations marks:
This parameter defaults to the following three values: aes-cbc, des-ede3-cbc, and null.
7. auth-alg-list—Enter the list of authentication algorithms. You enter more than one value by separating the
algorithms by <Spaces> and enclosing all values in quotations marks:
This parameter defaults to hmac-sha-1-96.
Important Notes
Note the following:
• The endpoint to which the response is being sent must be a trusted endpoint. The option disable-ppi-to-
pai should not be configured in the global SIP configuration’s options list.
• If the P-Preferred-Identity header is present in the response, the Oracle Communications Session Border
Controller will delete the header.
• If the P-Asserted-Identity header is present in the response, the Oracle Communications Session Border Controller
will overwrite that -Asserted-Identity.
Behavior Configuration
You can configure the Oracle Communications Session Set the applicable session agent’s port to 0 and its
Border Controller to resolve the P-CSCF for a registering transport-method to *.
UE using a DNS NAPTR query.
You can configure the system to resolve the P-CSCF for a Set the applicable session agent’s port to 0 and its
registering UE using a DNS SRV query. transport-method to a value other than *.
You can configure the system to resolve the P-CSCF for a Set the applicable session agent’s port to value greater
registering UE using a DNS A-query. than 0.
When you have configured the Oracle Communications No special configuration is required.
Session Border Controller to resolve the P-CSCF for a
registering UE using a DNS NAPTR query, you can
establish the way it learns the next hop that will handle the
UE’s signaling. If multiple NAPTR RRs result or if the
order values is the same, the one with the lowest order
value becomes the target for registration. If there is no in-
service destination available, the NAPTR RR with lowest
preference of the remaining options becomes the target.
When you can configure the Oracle Communications To support the round-robin method, you can set the
Session Border Controller to resolve the P-CSCF for a applicable session agent’s load-balance-dns-query to
registering UE using a DNS SRV query, you can establish round robin. Or, you can leave that parameter set to
the way it learns the next hop that will handle the UE’s hunt (its default).
signaling. If the SRV target is an FQDN host that resolves
Note that the round robin method does not work then
to multiple A RRs, the Oracle Communications Session
the session agent has the dns-load-balance option
Border Controller either selects a single A RR by hunting
configured. That option distributed requests to IP
or round robins across multiple A RRs.
address resolved from SRV responses with the same
weight and priority.
Note that if the ping is enable for the session agent and
load-balance-dns-query is set to round robin, the
Behavior Configuration
NAPTR
The Oracle Communications Session Border Controller performs resolution of the P-CSCF for a registering UE using
a DNS NAPTR query. This happens when a session agent is defined with its port set to 0 and its transport method set
either to any or *, or when there is no session agent defined. When no session agent is defined, the system performs
the NAPTR query according to the registering UE’s URI domain. And if no transport method is defined for the
session agent, the default query type is DNS NAPTR. Note that the configuration of how to resolve the P-CSCF is
defined for a specific session agent.
When it receives a UE’S initial registration message, the system performs an NAPTR DNS query for the next hop
that will handle the UE’s signalling. The Oracle Communications Session Border Controller selects the NAPTR
resource record (RR) with the lowest order value as the target for the registration when multiple RRs are returned. If
the order value is the same, the system uses the lowest preference RR AS THE target. And if no in-service destination
is available, the system selects the RR with the lowest preference from the remaining RRS as the target registration.
DNS SRV
The Oracle Communications Session Border Controller performs resolution of the P-CSCF for a registering UE,
starting with a DNS SRV query for a session agent with its port set to 0 and transport method given a setting other
than any or *. Note the system provides this support with DNS SRV-based session agents.
When it receives a UE’S initial registration message, the Oracle Communications Session Border Controller performs
a DNS SRV query for the next hop target that will handle the UE’s signalling. If the SRV target is an FQDN host that
then resolves to multiple A RRs, the system then:
• Selects a single A RR through hunting if the load-balance-dns-query parameter is set to hunt (i.e., the
first of several A RRs will always be selected unless it goes out of service)
• Round-robins across multiple A RRs for a given SRV target (if the load-balance-dns-query parameter is
set to round-robin)
By default, the system hunts for and selects a single A RR. If the dns-load-balance option is configured, then
round-robin will not work. This option distributes the requests to IP addresses that are resolved from SRV responses
with the same weight and priority. Also, if you enable the session agent ping and set the load-balance-dns-
query to round-robin, then all IP addresses resolved through the DNS query will be pinged.
Note that when no session agent exists, standard SRV ordering and A record hunting are used.
DNS
The Oracle Communications Session Border Controller generates a DNS query to resolve the P-CSCF for a
registering UE if the session is with a port greater than zero (0).
Acting as a P-CSCF
This section describes the support DNS load balancing provides for an Oracle Communications Session Border
Controller acting as a P-CSCF.
For each UE registering through the system as a P-CSCF and using any of the three defined methods, the top service
route resolved for the UE using DNS is used for subsequent refreshed and INVITE messages without querying DNS
or using any selection method. DNS is used in these instances:
• The DNS result TTL expires and the new results are different or changed.
• The cached target associated with the UE is out of service.
For SIP messages the UE initiates other than a REGISTER, the system routes the messages according to the top
service route. The DNS-resolved target is used for such messaging.
NAPTR
The Oracle Communications Session Border Controller performs resolution of the I-CSCF for a registering UE with
an NAPTR query for a session agent with its port set to 0 and transport method given a setting other than any or *.
When no session agent is defined, the system performs the NAPTR query according to the registering UE’s URI
domain. And if no transport method is defined for the session agent, the default query type is DNS NAPTR. Note that
the configuration of how to resolve the P-CSCF is defined for a specific session agent.
When it receives a UE’S initial registration message, the Oracle Communications Session Border Controller performs
an NAPTR DNS query for the next hop that will handle the UE’s signalling. The system selects the NAPTR resource
record (RR) with the lowest order value as the target for the registration when multiple RRs are returned. If the order
value is the same, the system uses the lowest preference RR AS THE target. And if no in-service destination is
available, the system selects the RR with the lowest preference from the remaining RRS as the target registration.
DNS SRV
The Oracle Communications Session Border Controller performs resolution of the I-CSCF for a registering UE,
starting with a DNS SRV query for a session agent with its port set to 0 and transport method given a setting other
than any or * or *. Note that the system provides this support with DNS SRV-based session agents.
When it receives a UE’S initial registration message, the system performs a DNS SRV query for the next hop target
that will handle the UE’s signaling. If the SRV target is an FQDN host that then resolves to multiple A RRs, the
Oracle Communications Session Border Controller then:
• Selects a single A RR through hunting if the load-balance-dns-query parameter is set to hunt (i.e., the
first of several A RRs will always be selected unless it goes out of service)
• Round-robins across multiple A RRs for a given SRV target (if the load-balance-dns-query parameter is
set to round-robin)
By default, the system hunts for and selects a single A RR. If the dns-load-balance option is configured, then
round-robin will not work. This option distributes the requests to IP addresses that are resolved from SRV responses
with the same weight and priority. Also, if you enable the session agent ping and set the load-balance-dns-
query to round-robin, then all IP addresses resolved through the DNS query will be pinged.
Note that when no session agent exists, standard SRV ordering and A record hunting are used.
DNS
The system generates a DNS query to resolve the I-CSCF for a registering UE if the session is with a port greater than
zero (0).
S-CSCF Configuration
To set the port, transport-method, and load-balance-query parameters for a session agent:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type and session-router press Enter.
ORACLE(configure)# session-router
3. Type session-agent and press Enter. If you are editing a pre-existing configuration, you need to select the
configuration before making changes.
ORACLE((session-router)# session-agent
ORACLE((session-agent)#
4. port—Change this parameter to the port value you want, or leave it set to 5060 (default).
5. transport-method—Leave this parameter set to UDP (default), or enter an asterisk (*) to support all
transport methods.
6. load-balance-dns-query—To perform load balancing across multiple A RRs, change this value from
hunt (default) to round-robin.
7. Save and activate your configuration.
E-CSCF Support
An Emergency Call Session Control Function (E-CSCF) is an IMS core element that aids in routing emergency calls
to an appropriate destination, such as a PSAP. E-CSCF functionality can be performed by the Oracle Communications
Session Border Controller with appropriate local policy and network management control configuration.
The E-CSCF feature let the Oracle Communications Session Border Controller internally prioritize and route
emergency calls to the corresponding Emergency Service Center, based either on the calling party’s request URI, or
based on location information retrieved from a CLF (Connectivity Location Function) for wireline/TISPAN networks.
By integrating E-CSCF functionality into the P-CSCF (Oracle Communications Session Border Controller ),
networks can satisfy the common local requirement that certain telephony elements be deployed locally, rather than
use single, centralized elements. Funcitons like the E-CSCF likely fall into this category.
CLF Connectivity
The Oracle Communications Session Border Controller must be configured with Diameter-based CLF support. This is
accomplished by creating an appropriate external policy server configuration.
When the Oracle Communications Session Border Controller requests authorization from the CLF server, a Line-
Identifier AVP which includes a location string is expected to be returned for the call. The returned location string will
be used later for an LRT query.
configuration must have its next hop parameter left blank. This lets the Oracle Communications Session Border
Controller route the emergency call with local policies.
For example, if urn:service:sos is the configured value in the NMC’s destination identifier, and an
INVITE arrives on the Oracle Communications Session Border Controller with urn:service:sos in the request URI, the
call will be flagged for emergency handling. The next step in call processing is for the INVITE to be evaluated by
local policy.
Local Policy
Local policies must be configured to match and then route an incoming emergency call. Once a local policy match is
made, the Oracle Communications Session Border Controller looks to the configured policy attributes for where to
forward the INVITE. A matching policy attribute’s next hop should be configured to point to an emergency LRT that
contains specific destinations for emergency calls. In addition, the elec str lkup parameter must be set to
enabled so the Oracle Communications Session Border Controller will perform an LRT lookup based on the location
string returned in the CLF response.
The eloc str match parameter identifies the attribute, whose value in the location string will be used as the
lookup key in the emergency LRT. For example, if the returned location string is:
loc=xxx;noc=yyyy;line-code=zzzz
and the eloc str match parameter is set to noc, then when the Oracle Communications Session Border
Controller performs a local policy route search, it will search the LRT for yyyy. If the eloc str match parameter
left empty or if there is no match when eloc str lkup is enabled, the entire location string is used as the lookup
key.
Emergency LRT
The Oracle Communications Session Border Controller needs to be configured with an emergency LRT to route
emergency calls to their destination.
As stated in the previous section, when searching an emergency LRT, any user defined parameter within a Location
String may be used as the key to look up next-hop routing information.
LRT files support <user type = string> which enables the Oracle Communications Session Border Controller to
perform searches on free form attributes that may appear in the returned location-string. The <user type = string>
value for an entry in the emergency LRT should be set to a part or whole value returned in the CLF’s location string.
For example:
<?xml version="1.0" encoding="UTF-8" ?>
<localRoutes>
<route>
<user type="string">1234</user>
<next type="regex">!^.*$!sip:911@192.168.200.140:5060!</next>
</route>
<route>
<user type="string">loc=xxx;noc=yyyy;line-code=zzzz</user>
<next type="regex">!^.*$!sip:911@192.168.1.139:5060!</next>
</route>
</localRoutes>
Note: Given that the Location String is not a well-defined string, care should be taken when defining and
configuring the LRT tables.
LRTs must be individually uploaded to both the active and standby systems in an HA node; LRTs are not
automatically replicated across nodes.
PANI header. The emergency call proceeds normally using this location string’s information for emergency LRT
lookups.
E-CSCF Configuration
This procedure assumes that the Oracle Communications Session Border Controller is configured to communicate
with a CLF. In addition, this procedure assumes an the Oracle Communications Session Border Controller is
configured and loaded with an appropriate LRT for E-CSCF Use.
To configure an NMC for E-CSCF use (baseline parameters are not mentioned):
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 net-management-control and press Enter.
ORACLE(session-router)# net-management-control
4. name—Enter the name of this network management control rule; this value uniquely identifies the control rule.
There is no default for this parameter.
5. state—Enable or disable this network management control rule. The default value is enabled. The valid
values are:
• enabled | disabled
6. type—Set this parameter to priority so that the Oracle Communications Session Border Controller will flag
incoming calls with a matching destination identifier as a priority calls.
7. treatment—Set this parameter to divert.
8. next-hop—Leave this parameter blank so that the call’s processing will go directly to local policy.
9. destination-identifier—Enter the service URN that endpoints in your network include in their request
URIs to identify themselves as emergency calls.
10. Save your configuration.
To configure local policy for E-CSCF use (baseline parameters are not mentioned):
11. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
ORACLE(configure)#
12. Type session-router and press Enter.
ORACLE(configure)# session-router
ORACLE(session-router)#
13. 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)#
14. to-address—Set this parameter to the lookup key for matching emergency calls. You can now use a service
URN as lookup key criteria.
15. Save your configuration.
To configure policy attributes for E-CSCF use (baseline parameters are not mentioned):
16. 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)#
17. next-hop—Set this parameter to lrt: name-of-elrt-file.gz for this policy attribute to lookup routes
in the named lrt file.
18. eloc-str-lkup—Set this parameter to enabled for the Oracle Communications Session Border Controller
to parse the emergency location string, as received in a CLF Line Identifyier AVP, for emergency LRT lookup.
19. eloc-str-match—Set this parameter to the attribute name found in the location string whose value will be
used as a lookup key in the LRT named in the next-hop parameter. Common values include “loc” or noc.
20. Save and activate your configuration.
Initial Registration
When an endpoint registers, the Oracle Communications Session Border Controller creates and sends an AAR
message to a PCRF which includes the following information:
<AA-Request>::= < Diameter Header: 265, REQ, PXY >
Media-Component-Number 0
Media-Sub-Component Grouped AVP description follows
Flow-Number 1
Flow-Description Permit in <ip> from <Endpoint IP:Port> to <SBC Sip Interface IP:Port>
Permit out <ip> from <SBC SIP Interface IP:Port> to <Endpoint IP:Port>
Where <ip> is (UDP: 17, TCP: 6) if wildcard-trans-protocol = disabled.
Register Refresh
When a registration Refresh is received before the half time of the registration expiry, the registration cache is not
updated and the Oracle Communications Session Border Controller responds with 200OK to the UE. This is standard
registration cache functionality. No additional AAR is sent to the PCRF.
If a registration Refresh is received after the half time of the registration expiry, or if any registration information
changes, the Oracle Communications Session Border Controller sends an AAR to the PCRF after it receives and
forwards a 200 OK response from registrar. The AAR includes the same session-id as the initial AAR that was to
PCRF. This lets PCRF correlate the AAR with the earlier AAR that it received.
De-Registration
When an contact de-registers with expires=0, it means that the endpoint is removing all of its contacts from
registration. When this occurs, the Oracle Communications Session Border Controller sends an STR message to the
PCRF to terminate the session. If the de-registration message does not reflect a complete de-registration, the Oracle
Communications Session Border Controller does not send the STR message to the PCRF. The STR message includes
the following information:
<ST-Request> ::= < Diameter Header: 275, REQ, PXY >
Troubleshooting
Upon receipt of AAA response from PCRF for the AAR sent, the Oracle Communications Session Border Controller
logs the status of the AAA received. Successful AAAs are noted by session-ID in EBMD logs. The log will look like:
Provision of SIP Signaling Flow (<session-ID>) via Diameter Rx on realm
<realm-id> successful.
Failed AAA response are noted at NOTICE level EBMD logs citing the failure response to AAR request with the
session-ID sent. An a MINOR non-health-affecting alarm is also raised with the following text:
Provision of SIP Signaling Flow (<session-ID>) via Diameter Rx on realm
<realm-id> failed.
show ext-band-mgr
The show ext-band-mgr command has been augmented to include the Register and DeRegister counts. For example:
ORACLE# show ext-band-mgr
13:55:49-166
EBM Status -- Period -- -------- Lifetime --------
Active High Total Total PerMax High
Client Trans 0 0 0 7 4 1
Server Trans 0 0 0 0 0 0
Sockets 1 1 0 1 1 1
Connections 0 0 0 1 1 1
---- Lifetime ----
Recent Total PerMax
Reserve 0 0 0
Modify 0 0 0
Commit 0 4 2
Remove 0 2 1
Register 1 1 1
DeRegister 1 1 1
EBM Requests 0 6 3
EBM Installs 0 6 3
EBM Req. Errors 0 0 0
EBM Rejects 0 0 0
EBM Expires 0 0 0
EBMD Errors 0 0 0
selection: 1
ORACLE(ext-policy-server)#
3. specific-action-sig-flow-subscription—Signaling path status changes information available for
notification
• loss of bearer— Within a Re-authorization Request (RAR), this value shall be used when the server
reports a loss of a bearer (e.g. in the case of General Packet Radio Service - Packet Data Protocol (GPRS PDP)
context bandwidth modification to 0 kbit) to the Application Function (AF). The Service Data Flows (SDFs)
that are deactivated as a consequence of this loss of bearer shall be provided within the Flows Attribute Value
Pair (AVP). In the Authentication-Authorixation Request (AAR), this value indicates that the AF requests the
server to provide a notification at the loss of a bearer.
• release of bearer— Within a RAR, this value shall be used when the server reports the release of a
bearer (e.g. PDP context removal for GPRS) to the AF. The SDFs that are deactivated as a consequence of this
release of bearer shall be provided within the Flows AVP. In the AAR, this value indicates that the AF requests
the server to provide a notification at the removal of a bearer.tate where the bearer connection has been
released.
4. Type done to save your configuration.
RR-Bandwidth and RS-Bandwidth AVPs are not created in AAR messages sent to the PCRF. The sip-config > get-
bw-from-sdp option must be configured to enable creation of these AVPs.
Flow-status AVP
The Flow-status AVP (511) is based on SDP direction. Tests for SDP are performed in the following order:
Session Border Controller will use the value of the sip-interface's send-380-response as the reason or the default
message if the value is empty. The valid values for send-380-response are any string. It is not required.
This functionality is configured through the sip-380-reason parameter in the net-management-ctrl object.
selection: 1
ORACLE(net-management-control)#
3. sip-380-reason — Enter a reason phrase enclosed in quotes.
4. Type done to save your configuration.
selection: 1
ORACLE(sip-interface)#
3. options +reject-unreg-priority-calls—Add this option to require compliance with Section 5.1.6.2 of 3GPP
TS24.229 . If this option is enabled, emergency calls from unregistered or roaming UEs are rejected with a 380,
Alternative Service response, and the UE is required to perform an emergency registration prior to sending an
emergency message. If this option is not present, emergency calls, by default, are processed and routed regardless
of registration status.
ORACLE(sip-interface)# options +reject-unreg-priority-calls
4. disallow-priority-calls—ensure that this option has not been enabled on the current SIP interface because it
summarily rejects all emergency calls on the current SIP interface. Ensure that this option is NOT present to
ensure compliance with 3GPP TS24.229.
ORACLE(sip-interface)# options -disallow-priority-calls
5. options send-380-response—ensure that this option has not been enabled on the current SIP interface.
The send-380-response option provides the text for the Reason header. The correct text is supplied by the
380 Alternative Service message. Ensure that this option is NOT present to ensure compliance with 3GPP
TS24.229.
ORACLE(sip-interface)# options -send-380-response
6. Type done to save your configuration.
IR.94 Support
The Oracle Communications Session Border Controller supports IR.94 (IMS Profile for Conversational Video
Service) for use in an IMS and LTE environment.
The Oracle Communications Session Border Controller supports both video and audio and can keep a call up by
switching to audio mode when the video session is dropped. The Oracle Communications Session Border Controller
receives a Specific-Action AVP in the RAR from the PCRF indicating the loss of video bearer. The Oracle
Communications Session Border Controller then replies with a RAA, and finally sends a STR failing the call.
This behavior contradicts TS 29.214 that indicates the P-CSCF should wait for an ASR from the PCRF (indicating the
bearer has been removed), and should not fail the call until all bearers have been removed.
The following behaviors enable IR.94 Support:
• The Oracle Communications Session Border Controller supports the IR.94 re-INVITE procedures for adding or
removing video mid-call.
• The Oracle Communications Session Border Controller recognizes that a UE is capable of handling video calls
when in the REGISTER message, the sip.video media feature is present in the Contact: header.
• The Oracle Communications Session Border Controller supports Audio-Video Profile with Feedback (AVPF) and
SDP Capability Negotiation (RFC 5939) as documented in TS 26.114 section 6.2.1a.
• When the Oracle Communications Session Border Controller supports sessions (200 OK received after an
INVITE) with a single media stream throughout the session duration, it may receive any of the following
notifications in the Specific-Action AVP of the RAR from the PCRF:
• INDICATION_OF_LOSS_OF_BEARER (2)
• INDICATION_OF_RELEASE_OF_BEARER (4)
• INDICATION_OF_OUT_OF_CREDIT (7)
• INDICATION_OF_FAILED_RESOURCES_ALLOCATION (9)
The Oracle Communications Session Border Controller then:
1. Replies with an RAA acknowledging the RAR
2. Sends a BYE to both the UE and the Core, then
3. Sends an STR to the PCRF indicating the session has been terminated.
• When the Oracle Communications Session Border Controller supports sessions (200 OK received after an
INVITE) with multiple simultaneous media streams sometime during the session, it may receive any of the
following notifications in the Specific-Action AVP of the RAR from the PCRF:
• INDICATION_OF_LOSS_OF_BEARER (2)
• INDICATION_OF_RELEASE_OF_BEARER (4)
• INDICATION_OF_OUT_OF_CREDIT (7)
• INDICATION_OF_FAILED_RESOURCES_ALLOCATION (9)
The Oracle Communications Session Border Controller then:
1. Sends an RAA acknowledging the RAR, and no further action is required When an eSR-VCC handover
occurs, the ATCF (Oracle Communications Session Border Controller) sends a INVITE/UPDATE without
video (voice-only SDP) toward the target UE.
selection: 1
ORACLE(ext-policy-server)#
3. Use options terminate-on-voice-bearer-release to enable I.94 compliance.
ACMEPACKET(ext-policy-server)# options +terminate-on-voice-bearer-release+
ACMEPACKET(ext-policy-server)#
4. Type done to save your configuration.
Pooled Transcoding
The term pooled transcoding refers to a deployment model for IMS environments involving two or more Oracle
Communications Session Border Controllers. The first is an A-SBC acting as the P-CSCF, and the others are one or
more Acme Packet 4600s or Acme Packet 4500s equipped with transcoding hardware (referred to as T-SBCs). The T-
SBC provides transcoding resources—a pool—that the A-SBC can invoke on-demand.
In the pooled transcoding model, the A-SBC sits between realms or between user endpoints that require transcoding
between their preferred codecs to communicate. This deployment model conserves resourses on both the A-SBC and
the T-SBC. While the A-SBC serves as the access function with encryption support, the T-SBC supports transcoding
in a tunneling gateway (TG) configuration to meet high-density transcoding requirements.
The following diagram shows an A-SBC positioned between an access UE and the IMS core. The A-SBC compares
SDP offers and answers from the elements it sits between, and uses the results to determine whether or not a given
session requires transcoding. If transcoding is required, the A-SBC invokes T-SBC’s services. Acting as a B2BUA, T-
SBC uses information from the P-CSCF’s SIP messaging to transcode between the applicable codecs and then to
route SIP signaling back to the P-CSCF on the egress.
The following diagram shows what a call flow between entities in such a deployment model looks like:
Supported Codecs
This is a list of supported transcodable codecs Oracle Communications Session Border Controller that may be used
within the pooled transcoding deployment model.
• PCMU
• CMA
• G729
• G729A
• iLBC
• telephone-event
• G726
• G726-16
• G726-24
• G726-32
• G726-40
• G722
• G723
• GSM
• AMR
• AMR-WB
Implementation Details
From the A-SBC/P-CSCF perspective, the T-SBC is represented as a transcoding agent whose services the P-CSCF
can invoke when offer-answer exchanges reveal transcoding is required. Once that determination is made, the P-
CSCF initiates communication with the T-SBC. The P-CSCF uses its public SIP interface and a corresponding realm
reserved for communication with a T-SBC, which is configured as a transcoding agent on the P-CSCF. Multiple
transcoding agents can be configured, and can be IP addresses, session agents, or session agent groups (SAGs).
If there is more than one transcoding agent for the P-CSCF to choose from, the P-CSCF bases its selection on the
order in which the transcoding agents were entered in the list. When conditions call for it, the P-CSCF will try each
transcoding agent listed one by one until it:
• Receives a 2xx response from a transcoding agent,
• The list is exhausted, or
• The original transaction times out.
If the transcoding agents are session agents with hostnames, the P-CSCF uses DNS to resolve the hostnames and then
tries the hosts in order. In the case when transcoding agents are SAGs, the P-CSCF selects the session agent according
to the selection strategy configured for the SAG. The P-CSCF will recurse through all members of the SAG when
SAG recursing is enabled. Whenever session agents and SAGs do not have ports or transport protocols specified, the
defaults are 5060 and UDP respectively.
Once it identifies a transcoding agent, the P-CSCF sends an INVITE to which the transcoding agent—the T-SBC—
responds with a 2xx message. Configuring the P-CSCFs as a session agent and disabling dialog transparency (in
global SIP configuration) on the T-SBC allows it to accept SIP messages from the P-CSCF. Then the T-SBC acts as a
B2BUA, using the information received in the P-CSCF’s INVITEs to invoke transcoding and to route SIP signaling
back to the P-CSCF on the egress.
Application Scenarios
This section discusses two application scenarios for pooled transcoding, one for how the P-CSCF handles an INVITE
with SDP and one for how it handles an INVITE without SDP.
The P-CSCF receives an answer to this INVITE, and if it contains the added codec, the P-CSCF invokes the T-SBC’s
transcoding services using an INVITE with the same SDP as the INVITE received on ingress. The communication
between the P-CSCF and the T-SBC is a stand-alone dialog, and a new media session is associated with it.
This is an example of what the INVITE the P-CSCF sends to the T-SBC looks like:
INVITE sip:192.168.101.78:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.101.18:5060;branch=z9hG4bK10dspa3058b1io4rk721
Max-Forwards: 70
When it receives an answer in either a PRACK or ACK message, the P-CSCF compares the offer and answer. An
answer containing the codec added in the egress offer causes the P-CSCF to invoke the T-SBC and create a standalone
UAC dialog, just as in Scenario 1.
Since the P-CSCF advertised its media address in the egress offer to the calling UE, the original media session is used
by the UAC dialog.
eSRVCC Support
For enhanced Signal Radio Voice Call Continuity (eSRVCC), the pooled transcoding deployment model supports
instances when:
• Original call is not transcoded, but the handover call is
• Original call is transcoded, but the handover call is not
• Original call is transcoded, and so is handover call
•
T-SBC Requirements
A valid T-SBC configuration must include the following:
• A global SIP configuration, with dialog-transparency set to disabled—Dialog transparency must be disabled on
the T-SBC so the T-SBC’s INVITE will have a different call ID and From tag.
• A public realm with codec-manip-in-realm set to enabled, because the same realm is used for transcoding. In
addition, the mm-in-realm parameter must be enabled.
Configuration Verification
You can verify your configuration using the ACLI verify-config command. When verifying your configuration
on the A-SBC, errors messages will appear if:
• The transcoding-realm value configured is not a valid realm.
• Either one of the transcoding-realm or transcoding-agents parameters is not configured.
• One or more session agent names defined in the transcoding-agents list is not a valid session agent.
• If the IP address version for a agent in the transcoding-agents list is not supported in the transcoding realm
you identify; e.g., if you list an IPv6 agent in the list and the transcoding realm does not support IPv6, the system
will return an error when you verify your configuration.
• If the transcoding agent is a hostname and not a valid session agent.
ACLI Configuration
This section shows you how to configure a transcoding realm and transcoding agents on your A-SBC, acting as the P-
CSCF in a pooled transcoding deployment model. You set these as part of the global SIP configuration.
To configure a transcoding realm and transcoding agents for the P-CSCF:
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.
ORACLE(session-router)# sip-config
ORACLE(sip-config)#
If you are adding this support to a pre-existing SIP configuration, you have to select the configuration before you
make changes.
4. transcoding-realm—Enter the name of a configured realm designated as the separate realm for the public
SIP interface, to be used only for communication with the T-SBC in pooled transcoding deployments.
ORACLE(sip-config)# transcoding-realm net157
ORACLE(sip-config)#
5. transcoding-agents—Enter the IP address, IP address and port combination, session agent hostname, or
SAG name in this list if you want them to be used as transcoding agents. You can make multiple entries in any
combination of these values. For example, you might list an IPv6 address and port, a session agent, and a SAG.
• To make multiple entries in the list using in one command line, enclose the entire list of value in parentheses
( ( ) ), separating each with a Space as in the example below.
• To add a transcoding agent to an existing list, put a plus sign before the value you want to add, e.g.
+154.124.2.8.
• To remove a transcoding agent from an existing list, put a minus sign before the value you want to remove,
e.g. -154.124.2.8.
ORACLE(sip-config)# transcoding-agent (sag:sag1 192.168.4.7.3
192.168.2.6:5061)
ORACLE(sip-config)#
6. Save and activate your configuration.
Per-Method Statistics
If you set extra-method-stats to disabled in your global SIP configuration, you can display the P-CSCF’s
per-method statistics for the public transcoding-realm.
Accounting
There is no difference between an ACR record for a typical SIP session and one for a transcoded section, except that
the direction of the forward codec (Acme-FlowType_FS1__F) and the reverse codec (Acme-FlowType_FS1__R). For
both RADIUS and DIAMETER records, the IP address and port corresponding to the original two endpoints will be
reflected; the T-SBC’s details will not appear in the records.
Discovery
The Oracle Communications Session Border Controller, acting as a P-CSCF, can discover remote S-CSCFs using
Service-Route header that returns with a 200 OK response from the registrar for a REGISTER request from the
endpoint. The system takes the top Service Route from the response and uses it as the first hop in the egress route for
the endpoint. Because the creation of dynamic session agents is based on the Service Route returned in the 200 OK,
there is no impact to handling AoRs with multiple contacts.
In addition, the system stores the Service Route header data with the endpoint’s registration cache. If the Service
Route is an FQDN, a DNS look-up is used to provide the route to the S-CSCF.
Creation
For your Oracle Communications Session Border Controller to create session agents dynamically, you must enable
the create-dynamic-sa in the global SIP configuration. This parameter defaults to disabled, meaning that no
dynamic session agents will be created.
When you set the parameter to enabled, the Oracle Communications Session Border Controller decides whether or
not to create dynamic session agents in the following ways. The system will create up to five (5) dynamic session
agents.
• If the Service Route is an IP address, the Oracle Communications Session Border Controller attempts to find an
exact match for that IP address against pre-existing session agents. If no exact match appears, the system will not
create dynamic session agents.
• If the Service Route is an FQDN and matches an existing session agent, the Oracle Communications Session
Border Controller assigns the remote S-CSCF to that session agent.
Service Routes with FQDNs might not match any session agents. However, the Service Route’s FQDN can match
the DNS suffix of a wildcard session agent. When this wildcard matching occurs, the Oracle Communications
Session Border Controller creates a new dynamic session agent with the original wildcard session agent as its
parent. The new dynamic session agent inherits all configuration properties of the parent session agent.
• If the Service Route is neither an IP address nor an FQDN and the system is unable to match any statically defined
or wildcard session agents, then the Service Route is not associated with any session agents.
Property Inheritance
Because dynamic session agents are created on the basis of static or wildcarded session agents, you can think of them
as children of the original--or parent--session agent. This relationship means that the child, dynamic session agent
inherits the configuration properties of its parent, static or wildcard session agent.
These inherited configuration properties and their effects are:
• The FQDN’s DNS resolution of the new dynamic session agent to IP addresses.
• Monitoring for liveliness via your configuration settings for the ping method and interval, transaction timeout, or
OOS response. The dynamic session agent also inherits its parent’s criteria for being taken out of service, with the
exception that a dynamic session agent will not be taken out of service until it expires on its own. This gives the
dynamic session agent time to return to service.
• The setting for ping-all-address, which when enabled causes new routes (internal session agents) fork and
makes the dynamic session agent the parent. The system caps the limit of five routes (or internal session agents)
per dynamic session agent. If the FQDN resolves to more than five IP addresses, the system only uses the first five
to create routes (internal session agents), and then pings the internal session agents.
• Suppression of the heartbeat (or ping) of the IP address in the presence of traffic. If traffic to a specific IP address
stops, then the Oracle Communications Session Border Controller resumes pinging within the time you set for the
ping-interval.
• The setting for the invalidate-registration option. If the dynamic child session agent goes out of
service, the corresponding registration cache entries of users that have the Service Route pointing to this session
agent will be invalidated.
This invalidation means that the next REGISTER request from that user will not receive a local response. Any
other services this user requires will not use the Service Route information stored in its registration cache. Instead,
the system will route it to the next hop as determined by other means, such as the local policy. At this time, the
user would must be re-registered by the registrar, a process that might return a new Service Route to be updated in
the registration cache.
Deletion
The Oracle Communications Session Border Controller needs to delete dynamic session agents no longer in use. But
dynamic session agents should not be deleted too soon, in case they return to service. So, deletion occurs according to
the process this section describes.
For each dynamically created session agent, the Oracle Communications Session Border Controller assigns and tracks
the last registration expiry time. It determines this time by doubling the registered endpoint’s core side expiry. Where
X is the last registration expiry value and Y is the registered endpoint’s core side expiry, the Oracle Communications
Session Border Controller performs checks according to this criteria:
X > (2 * Y)
The the system updates the expiry time with the greater value. This way, whenever the dynamic session agent re-
registers, it will have an updated expiry timer value.
Timeouts can also cause dynamic session agents to be deleted. Pings, status changes, transaction timeouts, DNS
expiries and other system occurrences can trigger timeouts. When the Oracle Communications Session Border
Controller detects that a timeout has occurred, the dynamic session agent is deleted.
• state — The value "enabled" triggers the feature and adds the Feature-Caps header to messages. The default value
is "disabled".
• atcf-management-uri — identifies the feature capability indicator that will be used to transport the ATCF
management URI. Possible values are "management" and "psi". The default value is "management". When the
value is "management" and the value of state is "enabled", the Feature-Caps header “g.3gpp.atcf-mgmt-uri” is
added and the value is the value of atcf-psi-dn in the sip-config configuration element. When the value is "psi"
and the value of state is "enabled", the Feature-Caps header “g.3gpp.atcf-psi” is added and the value is the value
of atcf-psi-dn in the sip-config configuration element.
• atcf-alerting — The value "enabled" adds the Feature-Caps header to messages and turns on the alerting feature.
The default value is "disabled".
When state is set to “enabled”, atcf-management-uri is empty, and atcf-alerting is set to "disabled", then the
Feature-Caps header is added with:
• g.3gpp.atcf : value is configured STN-SR in sip-config
• g.3gpp.atcf-mgmt-uri: the value is atcf-psi-dn in sip-config
• g.3gpp.atcf-path: value is the ATCF URI for terminating requests
• g.3gpp.mid-call capability indicator
When state is set to “enabled”, atcf-management-uri is set to "psi", and atcf-alerting is set to "disabled", then the
Feature-Caps header is added with:
• g.3gpp.atcf : value is configured STN-SR in sip-config
• g.3gpp.atcf-psi: the value is atcf-psi-dn in sip-config
• g.3gpp.atcf-path: value is the ATCF URI for terminating requests
• g.3gpp.mid-call capability indicator
When state is set to “enabled”, atcf-management-uri is set to "management", and atcf-alerting is set to "disabled",
then the Feature-Caps header is added with:
• g.3gpp.atcf : value is configured STN-SR in sip-config
• g.3gpp.atcf-mgmt-uri: the value is atcf-psi-dn in sip-config
• g.3gpp.atcf-path: value is the ATCF URI for terminating requests
• g.3gpp.mid-call capability indicator
When state is set to “enabled”, atcf-management-uri is set to "management", and atcf-alerting is set to "enabled",
then the Feature-Caps header is added with:
• g.3gpp.atcf : value is configured STN-SR in sip-config
• g.3gpp.atcf-mgmt-uri: the value is atcf-psi-dn in sip-config
• g.3gpp.atcf-path: value is the ATCF URI for terminating requests
• g.3gpp.mid-call capability indicator
• g.3gpp.srvcc-alerting capability indicator
When state is set to “enabled”, atcf-management-uri is set to "psi", and atcf-alerting is set to "enabled", then the
Feature-Caps header is added with:
• g.3gpp.atcf : value is configured STN-SR in sip-config
• g.3gpp.atcf-psi: the value is atcf-psi-dn in sip-config
• g.3gpp.atcf-path: value is the ATCF URI for terminating requests
• g.3gpp.mid-call capability indicator
• g.3gpp.srvcc-alerting capability indicator
selection: 1
ORACLE(sip-interface)#
sip-feature-caps in session-router
The sip-feature-caps element lets the ATCF announce a feature capability in a message by transporting the
information in the Feature-Caps header . The element has three parameters:
• state — The value "enabled" triggers the feature and adds the Feature-Caps header to messages. The default value
is "disabled".
• atcf-management-uri — identifies the feature capability indicator that will be used to transport the ATCF
management URI. Possible values are "management" and "psi". The default value is "management". When the
value is "management" and the value of state is "enabled", the Feature-Caps header “g.3gpp.atcf-mgmt-uri” is
added and the value is the value of atcf-psi-dn in the sip-config configuration element. When the value is "psi"
and the value of state is "enabled", the Feature-Caps header “g.3gpp.atcf-psi” is added and the value is the value
of atcf-psi-dn in the sip-config configuration element.
• atcf-alerting — The value "enabled" adds the Feature-Caps header to messages and turns on the alerting feature.
The default value is "disabled".
When state is set to “enabled”, atcf-management-uri is empty, and atcf-alerting is set to "disabled", then the
Feature-Caps header is added with:
• g.3gpp.atcf : value is configured STN-SR in sip-config
• g.3gpp.atcf-mgmt-uri: the value is atcf-psi-dn in sip-config
• g.3gpp.atcf-path: value is the ATCF URI for terminating requests
• g.3gpp.mid-call capability indicator
When state is set to “enabled”, atcf-management-uri is set to "psi", and atcf-alerting is set to "disabled", then the
Feature-Caps header is added with:
• g.3gpp.atcf : value is configured STN-SR in sip-config
• g.3gpp.atcf-psi: the value is atcf-psi-dn in sip-config
• g.3gpp.atcf-path: value is the ATCF URI for terminating requests
• g.3gpp.mid-call capability indicator
When state is set to “enabled”, atcf-management-uri is set to "management", and atcf-alerting is set to "disabled",
then the Feature-Caps header is added with:
• g.3gpp.atcf : value is configured STN-SR in sip-config
• g.3gpp.atcf-mgmt-uri: the value is atcf-psi-dn in sip-config
• g.3gpp.atcf-path: value is the ATCF URI for terminating requests
atcf-icsi-match in sip-interface
The atcf-icsi-match element lets the system check, on reception of an INVITE on an ingress sip-interface that has a
configured ATCF and before applying any of the already implemented logic, whether the incoming INVITE includes
the ICSI (Instantaneous Channel-State Information) of the requested service. The ATCF will be involved in the call
flow when the configured ICSI value matches the ICSI value in the original INVITE; otherwise the handoff call will
be rejected with code 404 (not found). The system looks for the ICSI string in the following headers:
• P-Preferred-Service
• P-Asserted-Service
• Feature-Caps (within the "g.3gpp.icsi-ref" feature-capability indicator)
• Accept-Contact (within the tag-value within the g.3gpp.icsi-ref media feature tag)
An example of the ICSI string in the P-Preferred-Service or P-Asserted-Service header is "urn:urn-7:3gpp-
service.ims.icsi.mmtel". Examples of the ICSI string in the Feature-Caps or Accept-Contact headers are "+g.
3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel" and "g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-
service.ims.icsi.mmtel". The ATCF will be involved in the call flow only when the ICSI matches. If atcf-icsi-match
is blank, the check is not done and the behavior remains the same as before.
• ATCF—A signaling anchor point co-located with the UE access network. The ATCF is responsible for:
• Allocating the Session Transfer Number for Single Radio (STN-SR).
• Instructing the ATGW to anchor the media path for originating and terminating sessions.
• Tracking sessions (in alerting, active, or held states) so it can perform the access transfer of the selected
session. Tracking this information allows the ATCF to support transferring the first session.
• Performing Access Transfer and updating the ATGW with the new media path for the access call leg, without
requiring updating from the remote leg.
• After the access transfer, updating the Service Centralization and Continuity Application Server (SCC AS) that
the transfer has taken place, ensuring that the Terminating Access Domain Selection (T-ADS) has updated
information about the access currently used.
• Handling failures during the access transfer.
• Handling mid-call support for the access transfer using MSC server-assisted mid-call support.
• Access Transfer Gateway (ATGW)—A media anchor point co-located with the UE access network. Controlled by
the ATCF, the ATGW anchors media both for the duration of a call and after the access transfer, based on the local
configuration in the serving network.
Originating and terminating sessions are anchored in the ATCF and ATGW already during session set-up. For the first
transferred session and the second established session, the SCC-AS provides session state information for the alerting,
held, and conference states.
When a UE makes or receives a call, signaling and media are anchored at the ATCF and ATGW. At the point call
handover point, the Visited-Mobile Switching Center (V-MSC) receives the handover message from Mobility
Management Entity (MME, an EPC network element). The V-MSC then sends a call request to the local ATCF rather
than sending the call request home or to the SCC-AS, as defined in 3GPP Release 8. Sending the call request to the
ATCF reduces the number of hops required to initiate a media stream change to a new access network.
Acting as the ATGW, the Oracle Communications Session Border Controller can immediately affect media
switchovers without further core signaling. In this role, the Oracle Communications Session Border Controller keeps
RTP media continuity between endpoints using its Hide Media Update (HMU) functionality: The elements on the
core side of the eSRVCC update will not see changes to SDP sources and destinations because the Synchronization
Source identifiers (SSRCs) are masked. Media can thus flow directly to and from the 3G-attached MSC and onward
to the UE with minimal interruption.
Note that if the MSC server-assisted mid-call feature is not supported or MSC server is not enhanced for ICS support,
the interface between the MSC server and the ATCF will be Mw. If the MSC server-assisted mid-call feature is
supported or the MSC server is enhanced for ICS, the interface between the MSC server and the ATCF will be I2.
Architectural View
This diagram is an architectural view of the control and user planes, depicting communication both before and after
transfer. This depiction assumes the PGW and the P-CSCF are in the serving network and support IMS voice roaming
(if not the home network). So, the ATCF resides in the serving networking (home network if not roaming). The access
leg of the session is divided into the serving leg and home leg. In an actual network, there might be other server IMS
nodes.
• The ATCF will associate the session being established with the C-MSISDN and ATU-STI bound to the
registration.
• The ATCF will replace the SDP offer in the originating SIP INVITE with updated SDP the ATGW provides.
Replacement occurs if the originating SIP INVITE contains SDP and a determination to anchor media has
been made (according to the operator policy as specified in the 3GPP standard).
• SIP BYE request on the Source Access Leg containing a Reason header field containing a SIP 503 (Service
Unavailable) response code, that is terminating an established dialog or an early dialog on the Source Access Leg
• SIP CANCEL request on the Source Access Leg with the Reason header field containing a SIP 503 (Service
Unavailable) response code then, that is terminating an early dialog on the Source Access Leg originated by the
SC UE, or
• SIP 503 (Service Unavailable) response on the Source Access Leg, that is terminating an early dialog on the
Source Access Leg terminating at the SC UE
Then -- The ATCF shall retain session state information and ATGW resources associated with the session until either
it receives a SIP INVITE request due to STN-SR, or a specified time period elapses (default value is 8 seconds).
The session remains recognizable for SRVCC access transfer as described in Section 12.7.2.1.
The SIP BYE request is forwarded to the SCC AS, which also delays release of the session, as described in Section
12.3.3.2.
Requirement 2: If the transferable session set determined in Section 12.7.2.1 does not contain any sessions and the
identity in the P-Asserted-Identity header field is a C-MSISDN that is not bound to a registration path in the ATCF,
the ATCF shall respond with a SIP 404 (Not Found) response.
Requirement 3: When the ATCF receives a SIP re-INVITE request containing Reason header field containing
protocol “SIP” and reason parameter “cause” with value “487” on the original source access leg,
• after having initiated an access transfer that was triggered by a SIP INVITE request due to STN-SR, and
• the SIP INVITE request due to ATU-STI transaction is not yet completed
Then -- The ATCF shall wait until this transaction has completed and then continue with the steps described in
Requirement 4.
Requirement 4: When the ATCF receives a SIP re-INVITE request(s) containing protocol “SIP” and reason parameter
“cause” with value “487” after having performed an access transfer that was triggered by a SIP INVITE request due
to STN-SR,
Then -- The ATCF shall act as B2BUA as described in Section 5.6 and shall.
1. Interact with ATGW to provide information needed in the procedures below and to request ATGW to start
forwarding the media from the remote UE to the local UE. The details of interaction between ATCF and ATGW
are out of scope of this document.
2. Send a SIP 200 (OK) response to the received SIP re-INVITE request. The SIP 200 (OK) response contains the
SDP answer that includes the ATGW ports and the IP addresses as provided by the ATGW and the media used on
the original source access leg as before the access transfer; and
3. Forward the received reINVITE with the Reason header intact to the SCC AS on the existing source dialog with
the SDP offer containing the ATGW IP addresses and ports towards the remote UE as provided by the ATGW.
This proposed behavior, which requires no user configuration) is implemented in Version S-CX7.2.0 and later
releases.
Related call flows are shown below.
BYE before handover INVITE
BYE
(REASON UNAVAILABLE)
BYE
(REASON, UNAVAILABLE)
7. Response + SSI
2. reINVITE
(REASON, CANCELLATION)
3. Configure ATGW
4. Configure ATGW
Ack
5. Response
7. Response
When the ATCF receives an SDP answer and if media is anchored at the ATGW for the session being transferred, the
ATCF directs the ATGW to start sending and receiving media to/from the remote UE according to the newly received
answer.
If it receives a BYE with a 503 Service Unavailable header on the source access leg, the ATCF retains session state
information and ATGW resources associated with the session until either:
• The ATCF receives an INVITE request because of STN-SR, or
• An operator-defined time period elapses. The default value for the operator-defined time period is eight (8)
seconds.
Thus, the session remains recognizable for SRVCC transfer for a time. Release of the session is also delayed by the
ATCF’s forwarding the BYE to the SCC AS. If the transferrable session cannot progress, the ATCF responds with a
404 Not Found. For transfer cases when only hold or alerting sessions exist and the session in question is an early
dialog or a confirmed dialog with inactive media, the ATCF replaces the Request-URI received in the original
INVITE with the ATU-STI associated with a session in the transferrable set before forwarding the request; this proxy-
role behavior complies with the 3GPP standard.
The MSC server initiates a transfer and (if supported) indicates its support for the MSC server-assisted mid-call
feature. The MSC server also provides all voice codecs it supports in the Access Transfer message.
The following shows a sample INVITE from the MSC server to the ATCF. Note the following:
• The Request-URI header contains the STN-SR, as routed to the ATCF.
• The P-Asserted-Identity header reflects the C-MSISDN of the UE being served.
• The From header reflects the C-MSISDN of the serving UE.
• The SDP contains a pre-configured set of codecs the MGW supports.
Upon receiving the Access Transfer message, the ATCF identifies the correct anchored session and proceeds with the
transfer of the most recently active session. Using a Configure ATGW message, the ATCF replaces the existing PS
access leg media path information with new CS access leg media path information for the ATGW. However, the
ATCF might instruct the ATGW to continue using the local port of the PS access leg media path. Once the ATGW
acknowledges the ATCF’s Configure message, the ATCF sends the MSC server an Access Transfer response and the
media path is moved to the CS when receiving SDP information.
Voice break interruption starts either when media moves to the CS MGW (controlled by the MSC server enhanced for
SRVCC) or when the UE relocates to the target—whichever comes first. When the UE tunes to the target or media
switches to the CS MGW (whichever is last), the voice break interruption ends. The assumption is that media is
switched to the CS MGW during the time to UE tunes to the target.
After receiving the Access Transfer message, the ATCF re-establishes communication with the SCC AS and updates
the SCC AS. When the MSC server supports the mid-call feature, the ATCF also communicates this fact to the SCC
AS. The ATU message initiates a new dialog between the ATCF and SCC AS, a dialog the CSS AS associates with
the old dialog using the C-MSISDN. This new dialog is necessary because it replaces the old dialog set up over PS
access, thereby assuring that if the PS user registration expires the new home leg will not be released or even affected.
The following shows a sample INVITE request the ATCF sends to the S-CSCF. Note the following:
• The Request-URI header contains the ATU-STI, as routed to the SCC AS.
• The Target dialog header specifies the existing dialog is associated with this request.
• The P-Asserted-Identity header reflects the C-MSISDN of the UE being served.
• The From header reflects the C-MSISDN of the serving UE.
• The SDP reflects the media information at the ATGW.
The SCC AS sends the ATCF a confirmation, including the session state information (SSI) if the SCC AS and the
MSC server support the mid-call feature. The MSC server receives the SSI from the ATCF; the access leg for the
control has moved to the CS access. When MSC server receives SSI for more multiple active or inactive speech
sessions, it initiates transfer directed at the SSC AS for the additional sessions.
The following diagram shows a call session in the active phase for MSC server assisted mid-call feature when
supported by the CSS AS.
This diagram shows an incoming call session during the alerting phase.
This diagram shows an outgoing call session during the alerting phase.
Confirmed Dialogs
When an SC UE is engaged in one or more ongoing IMS sessions, it will send a re-INVITE containing:
• An SDP offer, including the media characteristics used in the existing dialog, and
• A Reason header field containing the protocol SIP and reason parameters cause with the value 487 (as specified in
RFC 3326 [57]), with reason text reading either Handover cancelled or Failure to transition to CS domain.
In all other ways, confirmed dialogs behave in accordance with TS 24.229 [2].
Early Dialogs
If the SC UE engages in a session which is in early dialog state, it will send a SIP UPDATE containing:
• An SDP offer, including the media characteristics used in the existing dialog, and
• A Reason header field containing the protocol SIP and reason parameters cause with the value 487 (as specified in
RFC 3326 [57]), with reason text reading either Handover cancelled or Failure to transition to CS domain.
In all other ways, confirmed dialogs behave in accordance with TS 24.229 [2].
TS 24.237 Release 10, and has added the sip-feature-caps configuration element to align with Release 12. The
element has three parameters:
• state — The value "enabled" triggers the feature and adds the Feature-Caps header to messages. The default value
is "disabled".
• atcf-management-uri — identifies the feature capability indicator that will be used to transport the ATCF
management URI. Possible values are "management" and "psi". The default value is "management". When the
value is "management" and the value of state is "enabled", the Feature-Caps header “g.3gpp.atcf-mgmt-uri” is
added and the value is the value of atcf-psi-dn in the sip-config configuration element. When the value is "psi"
and the value of state is "enabled", the Feature-Caps header “g.3gpp.atcf-psi” is added and the value is the value
of atcf-psi-dn in the sip-config configuration element.
• atcf-alerting — The value "enabled" adds the Feature-Caps header to messages and turns on the alerting feature.
The default value is "disabled".
To ensure that calls in an alerting phase are transferred between PS and CS networks, set the value of state to
“enabled”, set the value of atcf-management-uri to "management", and set the value of atcf-alerting to "enabled".
The Feature-Caps header is then added with:
• g.3gpp.atcf : value is configured STN-SR in sip-config
• g.3gpp.atcf-mgmt-uri: the value is atcf-psi-dn in sip-config
• g.3gpp.atcf-path: value is the ATCF URI for terminating requests
• g.3gpp.mid-call capability indicator
• g.3gpp.srvcc-alerting capability indicator
For more information, refer to the SIP Feature Capabilities section.
Accounting
eSRVCC calls involve two SIP sessions, the accounting records for which need clear association. To correlate the
records, the Oracle Communications Session Border Controller performs these actions for eSRVCC calls:
• When it detects a session handover, the system generates an Interim accounting record for the initial SIP session.
This way, the records provide the exact time of the handover (i.e., the timestamp of the Interim record).
• The Oracle specific AVP Generic-ID will appear in Start, Interim, and Stop records for the handover SIP session.
The Generic-ID contains the Call ID of the initial SIP session, which helps to correlate the two SIP sessions.
• For RADIUS accounting records, refer to Oracle specific VSA 40.
• For DIAMETER accounting records, refer to Oracle specific VSA 30.
• The Stop record for the initial SIP session will not have media flow information because the media session is
considered part of the handover SIP session.
• If you are using QoS, the Stop records for the handover SIP session reflects the cumulative QoS statistics for both
the initial SIP session and the handover SIP session.
ATCF Configuration
ATCF functionality requires configuration in the sip-config and sip-interface configuration elements.
1. Access the sip-config configuration element.
selection: 1
ORACLE(sip-interface)#
6. sip-atcf-feature—Change this parameter from disabled (default) to enabled to turn on ATCF functionality
for the ingress SIP interface.
7. Type done to save your configuration.
Local Policy
The Oracle Communications Session Border Controlleri performs all expected processing on an incoming message
and begins a local policy lookup. When it encounters a policy attribute with a next hop in the form of cx:element-
name, it will perform an LIR/LIA transaction over the Cx Diameter interface to the home subscriber server referenced
as element-name.
The Oracle Communications Session Border Controlleri forwards the initial INVITE to the address in the Server-
Name AVP returned by the HSS in the LIA message.
LIR Format
The LIR contains the following information:
Vendor-Id: 9148
Supported-Vendor-Id: 10415
Supported-Vendor-Id: 13019
Vendor-Specific-Application-Id (grouped):
Vendor-ID: 10415
Vendor-ID: 13019
LIA Format
The LIA is expected to contain:
Server-Name: S-CSCF address to forward this message
Statistics
The show home-subscriber command displays detailed information about HSS transactions. For example:
ORACLE## show home-subscriber-server
17:54:58-186
HSS Status -- Period -- -------- Lifetime --------
Active High Total Total PerMax High
Client Trans 0 0 0 12 4 1
Server Trans 0 0 0 1 1 1
Sockets 1 1 0 1 1 1
Connections 1 1 0 1 1 1
---- Lifetime ----
Recent Total PerMax
LIR 0 0 0
Sent Req Accepted 0 11 3
Sent Req Rejected 0 0 0
Sent Req Expired 0 0 0
Sent Req Error 0 0 0
Internal Errors 0 0 0
Note the following statistics provided for Recent and Lifetime periods:
• LIR—Number of LIR requests sent
• Sent Req Accepted—Number of requests for which we got success response (2xxx)
• Sent Req Rejected—Number of permanent failures (5xxx)
• Sent Req Expired—Number of requests for which there was no response
• Sent Req Error—Number of protocol errors/bad requests (1xxx, 3xxx, 4xxx)
The EATF checks the E-STN-SR to determine that handoff to the circuit-switched network is requested and proceeds
with the access transfer of the active session. The EATF associates the received SIP INVITE with an existing SIP
session already anchored at the EATF using the instance-id feature tag. The EATF then sends a re-INVITE to the E-
CSCF, which terminates the emergency session.
Once the session modification procedures are complete, as indicated by the reception of the SIP ACK request from
the target access leg, the source access leg, previously established via IMS, is released.
Restoration Procedures
When functioning as a P-CSCF within an IMS network, an SBC is required to conform to Restoration Procedures as
defined in 3GPP TS 23.380, IMS Restoration Procedures, and 3GPP TS 24.229, IP Multimedia Call Control Protocol
Based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP).
TS 23.380 defines a set of standardized procedures for automatic restoration of connectivity after node or link failure.
Section 4.4.3 of TS 23.380 imposes a specific injunction requiring that if the UE initiates an originating service
request different from SIP REGISTER and the P-CSCF is unable to contact the S-CSCF in the Route, the P-CSCF
shall return a specific error response to the UE to trigger a new registration. Section 5.2.6.3.2A of the related 3GPP
TS 24.229 defines the structure and content of the required error response.
In the event of a P-CSCF failure to forward a request to the next hop device (whatever the reason), TS 24.229
mandates that the P-CSCF shall reject the call by returning a 504 (Server Time-out) response to the user endpoint.
The 504 response must contain:
• a Content-Type header field with the value "application/3gpp-ims+xml"
• a P-Asserted-Identity header field set to the value of the SIP URI of the P-CSCF included in the Path header field
during registration of the user whose UE sent the request causing this response
• an attached XML node-set (specified in Section 4.4.1 of 3GPP TS 24.615, Communication Waiting (CW) using IP
Multimedia (IM) Core Network (CN) subsystem, containing a child element that conveys the reason for requiring a
new registration
After issuing the 504 Server Time-out, the P-CSCF must reject any messages from the user endpoint except for
registration requests.
Introduction
Transcoding is the ability to convert between media streams that are based upon disparate codecs. The Oracle
Communications Session Border Controller supports IP-to-IP transcoding for SIP sessions, and can connect two voice
streams that use different coding algorithms with one another.
This ability allows providers to:
• Handle the complexity of network connections and the range of media codecs with great flexibility
• Optimize bandwidth availability by enforcing the use of different compression codecs
• Normalize traffic in the core network to a single codec
• Enact interconnection agreements between peer VoIP networks to use approved codecs
By providing transcoding capabilities at the network edge rather than employing core network resources for the same
functions, the Oracle Communications Session Border Controller provides cost savings. It also provides a greater
degree of flexibility and control over the codec(s) used in providers’ networks and the network with which they
interconnect.
In addition, placing the transcoding function in the Oracle Communications Session Border Controller and at the
network edge means that transcoding can be performed on the ingress and egress of the network. The Oracle
Communications Session Border Controller transcodes media flows between networks that use incompatible codecs,
and avoids back-hauling traffic to a centralized location, alleviating the need for multimedia resource function
processors (MRFPs) and media gateways (MGWs) to support large numbers of codecs. This maximizes channel
density usage for the MRFPs and MGWs so that they can reserve them for their own specialized functions.
Transcoding Hardware
A transcoding Network Interface Unit ( NIU) provides the DSP resources that enable transcoding on the Oracle
Communications Session Border Controller.
• The Acme Packet 6300 and Acme Packet 4600 can accept 1-24 transcoding modules to provide increasing
transcoding capacity.
• The Acme Packet 3820 and the Acme Packet 4500 can accept 1-12 transcoding modules to provide increasing
transcoding capacity.
Transcoding Capacity
Transcoding capacity depends on the following:
Codec Supported Bit Rate (kbps) RTP Default Supported Ptime (ms)
Payload Ptime (ms)
Type
The following table lists the supported codecs, bit rates, RTP payload number, default ptime, and supported ptimes for
codecs available only on the Oracle Communications Session Border Controller 4600 and 6300.
Codec Supported Bit Rate RTP Payload Type Default Ptime (ms) Supported Ptime
(kbps) (ms)
Session Licensing
AMR/AMR-WB and EVRC/EVRC-B audio codecs require extra licenses while all other codecs are implicitly
licensed by installation of a transcoding NIU. These codecs are under royalty agreements which necessitates their
own special licenses.
Licenses for AMR/AMR-WB and EVRC/EVRC-B transcoding sessions are installed by groups of 25.
Transcoding Configuration
The Oracle Communications Session Border Controller performs transcoding functions— allowing the entities with
incompatible codecs to communicate with each other— between two call legs. The two endpoints can be located in
one or two realms or networks. The Oracle Communications Session Border Controller decides to transcode a call by
evaluating messages in the SDP offer-answer transaction with respect to system configuration. An SDP offer can be
in a SIP message such as an INVITE or a reINVITE, and contains information about the codecs the offerer would like
to use. The answerer answers the SDP offer with its own set of supported codecs. reINVITEs are treated as new
negotiations, with respect to the actual SDP offerer and answerer. The Oracle Communications Session Border
Controller can manipulate an SDP message by reordering codec preference, and by adding and deleting codecs.
Signaling Codecs—Non-audio codecs that are interleaved into a media stream but cannot be used on their own. The
only codecs designated as Signaling Codecs by the Oracle Communications Session Border Controller are telephone-
event and CN (comfort noise).
Disabling an m= line—This is in reference to an m= line in an SDP message. It means setting the m= line’s port to 0
(RFC 3264). Enabling an m= line means it has a non-zero port. The m= line’s mode attribute (sendrecv/inactive/
rtcponly, etc) is not considered.
A codec policy is created by configuring the following information:
• Which Codecs are allowed and which are denied in a realm.
• Which Codecs should be added to the SDP m= lines for an egress realm.
• The preferred order of codecs to indicate in an SDP m= line.
• The packetization time which should be enforced within a realm.
Ingress Policy
Incoming SDP is first subject to the ingress codec policy. If no codec policy is specified in the realm config for the
ingress realm, or the m= lines in the SDP offer are disabled (by a 0 port number), the SDP is transformed to O1
unchanged.
The ingress codec policy first removes all un-allowed codecs, as configured in the allow-codecs parameter
(<codec>:no). For each un-allowed codec removed, its rtpmap and fmtp attributes are also removed from SDP. Next,
the remaining codecs are ordered with the order-codecs parameter. Ordering is when the codec policy
rearranges the codecs in the SDP m= line. This is useful to suggest the codec preferences to impose within the egress
realm. O1 is then processed by the egress codec policy after a realm is chosen as the destination.
In practical terms, the ingress policy can be used for filtering high-bandwidth codecs from the access realm. It can
also be used for creating a suggested, prioritized list of codecs to use in the ingress realm.
Egress Policy
The Oracle Communications Session Border Controller applies egress codec policy to the SDP that has already been
processed by ingress policy. The egress policy is applied before the SDP exits the system into the egress realm. If no
egress codec policy is defined, or the SDP’s m= lines are disabled (with a 0 port), the SDP is passed untouched from
the ingress policy into the egress network.
The egress codec policy first removes all un-allowed codecs in the allow-codecs parameter (<codec>:no).
Codecs on the add-codecs-on-egress list are not removed from the egress policy regardless of the how the
allow-codecs parameter is configured. If the result does not contain any non-signaling codecs, the ptime attribute
is removed from the SDP. Codecs not present in O1 that are configured in the add-codecs-on-egress
parameter are added to the SDP, only if O1 contains one or more transcodable codecs.
Note: Transcoding can only occur for a call if you have configured the add-codecs-on-egress parameter in an
egress codec policy.
If codecs with dynamic payload types (those between 96 and 127, inclusive) are added to the SDP, the lowest unused
payload number in this range is used for the added codec.
The following rules are also applied for egress policy processing:
If O1 contains at least one transcodable codec, the codecs listed in the Egress policy are added to the SDP.
• telephone-event, as configured in add-codecs-on-egress will only be added if O1contains at least one DTMFable
codec.
• T.38, as configured in add-codecs-on-egress will only be added if there is no T.38 and there is at least one
FAXable codec (G711Fall Back (FB)) in O1. T.38 will then be added as a new m= image line to the end of SDP.
If G711FB is not allowed in the egress policy, the Oracle Communications Session Border Controller disables the
m= line with the FAXable codec. Otherwise if G711FB is allowed, pass it through the regular offer processing
allowing/adding only FAXable codecs.
• G711FB, as configured in add-codecs-on-egress will only be added if there is no G711FB and there is T.38 in O1.
G711FB will then be added as a new m= audio line to the end of SDP.
If T.38 is not allowed in the egress policy, the Oracle Communications Session Border Controller disables the m=
image line. Otherwise if T.38 is allowed, pass it through the regular offer processing.
If the result of the egress policy does not contain any non-signaling codecs, audio or video, the m= line is disabled, by
setting the port number to 0.
The m= line is next ordered according to rules for the order-codecs parameter.
Finally, all attributes, a= lines, ptime attribute, and all other unrecognized attributes are maintained from O1.
Likewise, appropriate attributes for codecs added by the add on egress parameter are added to SDP. Finally, rtpmap
and fmtp parameters are retained for codecs not removed from the original offer. The result of all this is O2, as shown
in the overview diagram.
In practical terms, codec policies can be used to normalize codecs and ptime in the core realm where the network
conditions are clearly defined.
Codec policies can also be used to force the most bandwidth-conserving codecs anywhere in the network.
Post Processing
If any errors are encountered during the Ingress and Egress policy application, or other violations of RFC3264 occur,
the call is rejected. If O2 does not contain any enabled m= lines at the conclusion of the initial call setup, the call is
rejected. If O2 does not contain any enabled m= lines at the conclusion of a reINVITE, the reINVITE is rejected and
the call reverts back to its previous state.
Syntax
The following parameters are used to create a codec policy. Their syntax is described inline.
allow-codecs
allow-codecs—The allow-codecs parameter configures the codecs that are allowed and/or removed from the
SDP. A blank list allows nothing, * allows all codecs, none removes all codecs, the :no designation blocks the
specific codec or class of media, and the :force designation is used to remove all non-forced codecs.
The allow-codecs parameter is configured in the following way:
• <codec>:no—blocks the specific codec
• *—allow all codecs.
• <codec>:force—If any forced codec is present in an SDP offer, all non-forced codecs are stripped from the m-
line.
• audio:no—audio m= line is disabled
• video:no—video m= line is disabled
For example, if you configure PCMU in the allow-codecs parameter, the PCMU codec, received in an SDP message
is allowed on to the next step of transcoding processing, and all other codecs are removed.
The order of precedence is for removing codecs according to codec policy is:
1. <codec>:no—Overrides all other allow-codecs parameter actions.
2. audio:no / video:no. An allow-codecs line like “allow-codecs PCMU audio:no” disables the PCMU m= line
because audio:no has a higher precedence than the specific codec.
3. <codec>:force
4. <codec> Specific codec name and those codecs configured in the add-codecs-on-egress list.
5. * has the lowest precedence of all flags. For example "allow-codecs * PCMU:no" allows all codecs except
PCMU.
order-codecs
order-codecs—The order-codecs parameter is used to re-order the codecs in the m= line as the SDP is passed on
to the next step. This parameter overwrites the order modified by the add-codecs-on-egress command, when
relevant. The following is valid syntax for this parameter:
• <blank>—Do not re-order codecs
• *—You can add a <codec> before or after the * which means to place all unnamed codecs before or after (the
position of the *) the named codec. For example:
• <codec> *—Puts the named codec at the front of the codec list.
• * <codec>—Puts the named codec at the end of the codec list.
• <codec1 > * <codec2>—Puts <codec1> first, <codec2> last, and all other unspecified codecs in between them.
• <codec>—When the * is not specified, it is assumed to be at the end.
Any codec name is allowed in the order-codecs parameter, even those not defined or not transcodable. An * tells
the order-codecs parameter where to place unspecified codecs with respect to the named codecs. Refer to the
examples below.
• <blank>—do not reorder m= line
• PCMU *—Place PCMU codec first, all others follow
• * PCMU—Place PCMU codec last, all others proceed PCMU
• G729 * PCMU—Place G729 codec first, PCMU codec last, all others remain in between
• PCMU—If * is not specified, it is assumed to be at the (PCMU *).
Add on Egress
add-codecs-on-egress—This parameter adds a codec to the SDP’s m= line only when the codec policy is
referenced from an egress realm (except in one 2833 scenario). Codecs entered for this parameter are added to the
front of the m= line. Signaling codecs are added to the end of the m= line.
Transcoding can only occur if this parameter is configured. There is a special case for 2833 support where the add-
codecs-on-egress parameter is configured for an ingress realm. See RFC 2833 Scenario 2 for details.
Packetization Time
packetization-time—This parameter specifies a media packetization time in ms to use within the realm
referencing this codec policy. Packetization time You must also enable the force ptime parameter to enable transrating
in conjunction with configuring the packetization time. See the Transrating section for more information.
Non-transcoded Call
The decision to transcode is based on the top non-signaling codec in A1. If the top A1 codec is present in O1, the call
proceeds, non-transcoded. This is the rule for non-signaling codecs (i.e., not RFC 2833 nor FAX).
Transcoded Call
The following two conditions must then be met to transcode the call’s non-signaling media:
• The top A1 codec is not present in the O1 m= line
• The top A1 codec was added by the egress policy
If these rule are met, the Oracle Communications Session Border Controller will transcode between the top A1 codec
and the top transcodable, non-signaling O1 codec.
Voice Transcoding
The following examples use the ingress and egress codec policies listed at the top of each scenario. The examples use
changing SDP offers and answers, which contribute to unique results, per example. The effects of the SDP offers and
answers are explained in each example.
Voice Scenario 1
The following ingress and egress policies are used for scenario 1.
Note: The codec in the ingress policy’s add-codecs-on-egress parameter has no effect in the following
examples. Its presence would have an effect if a reINVITE was initiated from egress realm, effectively
reversing the roles of the codec policies.
1. In the following diagram, PCMU and G729 are offered. Ingress policy removes G729 and allows PCMU. The
egress policy adds G729 and strips PCMU from offered SDP and forwards it on to the answerer (ptime is also
removed because the last codec was removed).
The SDP answer agreed to use G729 and adds PCMA. The egress policy then strips PCMA from the SDP answer.
At this point, the top codec in A1, G729 is checked against O1. Since G729 is not present in O1, it is transcoded to
PCMU.
2. In the following diagram, GSM is in the original SDP offer. It is then passed through to O1. Egress policy adds
G729 and retains ptime from GSM and sends this to the answerer as O2.
The SDP answer agrees to use G729 and GSM, but prioritizes GSM. The egress policy allows both codecs
through, unchanged. Because A1 and O1 both have GSM, it is used for the non-transcoded call. Ptime is copied
from A0 to the result.
3. In the following diagram, G729 in the original SDP offer. Because once G729 is removed, no non-signaling are
left in O1, thus the call is rejected.
4. In the following diagram, GSM is in the original SDP offer. It is then passed through to O1. Egress policy adds
G729 and retains ptime from O1 and sends this to the answerer as O2.
The SDP answer states that the answerer wants to use PCMU. This is a violation of the RFC3264. Therefore the
call is rejected.
In this example, when the negotiation fails, the Oracle Communications Session Border Controller sends a 500
message to the offerer and a BYE message to the answerer.
5. In the following diagram, GSM is in the original SDP offer. It is then passed through to O1. Egress policy adds
G729 and retains ptime from O1 and sends this to the answerer as O2.
The SDP answer replies with G722 G729 GSM and PCMU. PCMU is stripped by policy, G722 is moved to the
back of the answer because it was not offered. The top A1 codec was not in O1, and was added by egress policy,
therefore the call is transcoded between GSM and G729.
Voice Scenario 2
The following ingress and egress policies are used for scenario 2.
1. In the following diagram, a video m= line is offered. The ingress policy disables the video m= lines. With no
enabled m= lines left, the call is rejected.
2. In the following diagram, G729 and video are offered to the Oracle Communications Session Border Controller.
Ingress policy allows G729 and disables the video m= line. The egress policy adds iLBC and G726-16, and then
orders the codecs according to the order-codecs parameter. The ptime is maintained between O0 and O2. Both
added codecs are allocated dynamic payload types in the order they appear in their m= line. A disabled Video m=
line is passed on to the answerer.
The SDP answer agreed to use iLBC, G729, and adds PCMU, and reorders them as stated. The disabled video m=
line is maintained. At this point, the top codec in A1, iLBC is used and transcoded with the top codec in O1,
G729.
3. In the following diagram, G729 and video are offered to the Oracle Communications Session Border Controller.
Ingress policy allows G729 and disables the video m= line. The egress policy adds iLBC and G726-16, and then
orders the codecs according to the order-codecs parameter. The ptime is maintained between O0 and O2. Both
added codecs are allocated dynamic payload types in the order they appear in their m= line.
The SDP answer only wants to use PCMU and PCMA. The egress policy removes PCMA and passes only PCMU
to the offerer. Because PCMU was in O1 and is now the only codec in A1, it is used, and no transcoding is used
between the endpoints.
4. In the following diagram, G726-16 and telephone-event are offered to the Oracle Communications Session Border
Controller. Ingress policy allows both codecs. The egress policy adds iLBC, and then orders the codecs according
to the order-codecs parameter.
The SDP answer agreed to use all codecs, but reorders them with G726-16 in the top position. Because G726-16 is
the top codec in A1, and it is also present in O1, it is used for this call without any transcoding.
Voice Scenario 3
Voice scenario 3 involves reINVITEs. The following ingress and egress policies are used for scenario 3.
order-codecs order-codecs
force-ptime disabled force-ptime disabled
packetization-time packetization-time
In the following diagram, the answerer sends a reINVITE after a previous transcoding session was established.
The original offerer and answerer swap roles. The new offerer rejects the SDP offer and the call reverts to the state
negotiated in the original SDP negotiation.
The following two scenarios describe when telephone-event to DTMF transcoding takes place:
1. In the following diagram, telephone event was offered by the offerer but was stripped by ingress policy. telephone-
event was not added by the egress policy because the remaining audio codec in O1 was not DTMFable. G729 was
the only codec forwarded on to the answerer.
The SDP answer agreed to use the remaining audio codec, G729. A0 is unaltered by egress policy, and forwarded
as the Result to the offerer. Therefore, G729 is used in both the ingress and egress realms, the call does not support
RFC 2833, and the call is not transcoded.
2. In the following diagram, telephone event was offered by the offerer but was stripped by ingress policy. telephone-
event was added by the egress policy because the remaining audio codec in O1 was DTMFable. PCMU and
telephone-event are then forwarded on to the answerer. Note that the telephone-event payload type is added with
the lowest available dynamic type number.
This case illustrates when the answerer supports audio and RFC 2833, but the offerer supports audio with inband
DTMF. The Oracle Communications Session Border Controller transcodes between RFC2833 in the egress realm
to in-band DTMF on the ingress realm.
3. In the following diagram, telephone event was offered by the offerer but was stripped by ingress policy. telephone-
event is added by the egress policy because the remaining audio codec in O1 was DTMFable. PCMU and
telephone-event are then forwarded on to the answerer. Note that the telephone-event payload type is added with
the lowest available dynamic type number.
The SDP answer only agreed to use PCMU. When A0 reaches the egress policy, it is passed along through the
Oracle Communications Session Border Controller to the offerer. Because telephone-event was not answered by
the answerer and not supported in O1, it can’t be used. Transcoding is therefore not used for this call.
4. In the following diagram, telephone event was offered by the offerer and was stripped by ingress policy. Since
PCMA was also stripped by the egress policy, leaving no non-signaling codecs, the call is rejected. A 500 message
is sent back to the offerer.
allow-codecs * allow-codecs *
add-codecs-on- telephone-event add-codecs-on-egress PCMU
egress
order-codecs order-codecs
force-ptime disabled force-ptime disabled
packetization-time packetization-time
dtmf-in-audio preferred dtmf-in-audio preferred
1. In the following diagram, telephone event and PCMU are offered by the offerer. They are both passed to O1, and
PCMA is added as it is sent to the answerer. The SDP answer, A0 disables all codecs but PCMU.
The Oracle Communications Session Border Controller adds telephone-event to the result because it is listed on
the ingress policy’s add-codecs-on-egress parameter and present in the offerer’s SDP.
Note: This is the only time the add list of an ingress policy is utilized as a check.
The result SDP includes PCMU and telephone-event in the ingress realm, which is transcoded to PCMU with in-
band DTMF in the egress realm.
2. In the following diagram, telephone event and PCMU are offered by the offerer. They are both passed to O1, and
PCMA is added as it is sent to the answerer. The SDP answer supports all three codecs offered, with PCMA added
on top.
The answerer responds with PCMA as the preferred codec in A0. The Oracle Communications Session Border
Controller compares A1 to O1 to make the transcoding decision. PCMA is the top codec in A1 and is transcoded
to PCMU, the top codec in O1. Also, because telephone-event is supported by both sides of the call, it is passed
through without any transcoding necessary.
This case illustrates when both endpoints are capable of sending and receiving telephone-event. Regardless of
whether the audio portion of the call is transcoded, the telephone-event messages are passed through the system
untouched, thus not requiring transcoding resources. This is known as telephone-event pass-through.
FAX Transcoding
FAXes are transmitted in a call as either T.30 and T.38 media. T.30 FAX is binary in-band media carried over G.711.
The Oracle Communications Session Border Controller can transcode between T.38 and a faxable codec. The
supported faxable codecs are PCMU and PCMA.
T.30 can only be transported in non-compressed codecs. The two non-compressed codecs supported by the Oracle
Communications Session Border Controller are PCMU (G711µ) and PCMA (G711A). If a transcoding realm does not
support an uncompressed codec, T.30 can not be supported in that realm. Alternatively, G711FB may be allowed
specifically for FAX only.
The Oracle Communications Session Border Controller uses an internal codec called G711FB (G711 - Fall Back) that
is an umbrella codec of all FAXable codecs. G711FB will default to PCMU for the purpose of offering a faxable
codec. You can remap G711FB to PCMA by configuring the media-profile for it appropriately. G711FB’s only use is
for FAX transcoding.
FAX transcoding is triggered when you configure the add on egress parameter with either T.38 or G711FB. In a FAX
scenario, when the codec policy adds either T.38 or G711FB, a new m= line is added to the SDP. When adding T.38,
the new m= line specifies the T.38 codec. When adding G711FB, the new m= line specifies PCMU (or alternatively
PCMA).
Once added, m= lines can not be deleted in the context of a call. The Oracle Communications Session Border
Controller maintain all m= lines between itself and an endpoint throughout the course of call. All m= lines not in use
can be disabled by setting their receive port to 0, but they can not be removed from the SDP.
Defining G711FB
G711 Fall Back (G711FB) is an internal codec that encompasses PCMU and PCMA for carrying fax information
FAXable codecs. The G711FB codec must be configured either way for when the Oracle Communications Session
Border Controller inserts a FAXable codec in SDP. G711FB is only used for FAX transcoding scenarios.
To define G711 FB, create a media profile configuration element named g711fb and set the payload-type to 0 or 8.
Codec (supported bit rates) RTP Payload Type Default Ptime (ms) Supported Ptime (ms)
FAX Scenario 1
The following ingress and egress policies are used for this FAX scenario.
In the following diagram, there are three offer-answer exchanges. Initially a PCMU-to-PCMU session is
negotiated. Next, a T.38 to PCMU session is negotiated. Finally, the session reverts to non-transcoded PCMU to
PCMU state.
FAX Scenario 2
The following ingress and egress policies are used for this FAX scenario.
allow-codecs * allow-codecs *
add-codecs-on- add-codecs-on-egress G711FB
egress
order-codecs order-codecs
force-ptime disabled force-ptime disabled
packetization-time packetization-time
1. In the following diagram, T.38 is offered to the Oracle Communications Session Border Controller. A second m=
line was added to O1 that included a G711FB codec (PCMU).
The SDP answer agreed to PCMU, but disabled T.38. When the Oracle Communications Session Border
Controller forwarded the SDP in A1 to the answerer, it stripped the second m= line. Because A1 rejects T.38 m=
line, but accepts the PCMU m= line, FAX transcoding is enabled.
2. In the following diagram, T.38 is offered to the Oracle Communications Session Border Controller. A second m=
line was added to O1 that included a G711FB codec (PCMU).
The SDP answer agreed to PCMU and T.38. Because both O1 and A1 support T.38, the call proceeds without
transcoding.
FAX Scenario 3
The following ingress and egress policies are used for this FAX scenario.
allow-codecs * allow-codecs *
add-codecs-on- add-codecs-on-egress PCMU, G729 ,T.38
egress
order-codecs order-codecs
force-ptime disabled force-ptime disabled
packetization-time packetization-time
1. In the following diagram, PCMU and telephone-event codecs are received by Oracle Communications Session
Border Controller .The egress codec policy has PCMU, G729 and T.38 add-codecs-on-egress.
Since there is a faxable codec in the SDP offer and T.38 in add-on-egress, the non-faxable codec G729 is stripped
and T.38 is added to egress offer.
In the A0 answer the audio m-line is zero indicating disabled and the port for the image m-line is non-zero
(20000) so the called party has selected T.38. Hence PCMU in realm A is transcoded to T.38 in realm B.
O2 : m1=PCMU
m2=T.38
T.38 is added on egress Egress Realm
Ingress Realm O1 : m1= PCMU
Ingress Egress
Offer (O0) O1 Offer (O2)
Policy Policy
m=audio 6000 RTP/AVP 0 101 m=audio 20056 RTP/AVP 0
m=image 20058 udptl t38
Offerer a=rtpmap 101 Answerer
OCSBC
Egress
Result A1 Answer (A0)
Policy
m=audio 15058 RTP/AVP 0 m=audio 0 RTP/AVP 0
a=rtpmap:0 PCMU/8000 m=image 20000 udptl t 38
Result: Fax
transcoded call A1 : m1=PCMU
PCMU from T.38
2. In the following diagram, PCMU and T38 are received by the Oracle Communications Session Border Controller.
The egress codec policy has PCMU, G729, and T.38 add-codecs-on-egress.
T.38 is present in the O0 offer, and therefore will not be explicitly added by the egress codec policy to the O2
Offer. The logic to remove non-faxable codecs is only invoked when T.38 is added by the add-codecs-on-egress
parameter. In this example, T.38 is not added since is already present in SDP. With PCMU and T.38 received,
G729 as a non-faxable codec is not removed. Therefore, PCMU, T.38, and G729 are all present in the O2 SDP
offer sent to the answerer.
In the A0 answer, the audio m-line port is 0 indicating that audio is disabled, and the port for the image m-line is
nonzero (20000), thus the called party has selected T.38. In the A1 answer the OCSBC send the audio m-line port
as 0 indicating that audio is disabled, and the port for the image m-line is nonzero (20000). This set-up results in a
non-transcoded T.38 -OCSBC -T.38 fax call.
Ingress Egress
Offer (O0) O1 Offer (O2)
Policy Policy
m=PCMU
m=image 49156 udptl t38
Offerer m=audio 20064 RTP/AVP 8 18 0 Answerer
OCSBC m=image 20066 udptl t38
Egress
Result A1
Policy Answer (A0)
m=image 15066 udptl t38
Transrating
The Oracle Communications Session Border Controller can transrate media as it exits the Oracle Communications
Session Border Controller into the network. Transrating is also known as forced packetization time (ptime), and is
used to enforce a configured ptime within a realm. Transrating is often desirable when devices in a realm can only
accept media with a specific ptime, or to optimize bandwidth.
If this feature is configured, the media portion of a call is transrated regardless of which codecs are ultimately chosen
for each realm as long as they are transcodable. This allows realms that have devices that can only use a single
packetization interval to interwork with devices that may or may not have the same packetization capabilities.
You must enable force-ptime in the egress codec policy and then specify the packetization time to force. When force
ptime is enabled, it implicitly masks all codecs not of the specified packetization time that are listed in that codec
policy’s allow codecs and add codecs on egress parameters. For example, if force ptime is enabled with a
packetization time of 20 ms, then no G723 codecs (which are only available at 30, 60, and 90 ms) may be active via
codec policy in that realm.
Transrating occurs when forced-ptime is enabled and the offered and answered ptimes do not match and the top non-
Signaling codec of A1 and top non Signaling codec of O1 are Transcodable.
Note: Answered ptime A1 does not have to be equal to the ptime inserted into the outgoing offer O2, it just
has to be different than the offer the Oracle Communications Session Border Controller received (O1).
Please refer to Transcodable Codecs for current list of ptimes per codec supported by the DSPs.
Transrating Scenario 1
The following ingress and egress policies are used for this FAX scenario.
allow-codecs * allow-codecs *
add-codecs-on- add-codecs-on-egress PCMA
egress
order-codecs G723 * order-codecs
force-ptime disabled force-ptime enabled
packetization-time packetization-time 40
1. In the following diagram, PCMU is offered in the ingress realm with 30ms ptime, and the egress realm is forced to
use 40ms ptime. PCMA is added as the top codec for the egress realm.
The Oracle Communications Session Border Controller enables transcoding between the ingress realm (PCMU)
and the egress realm (PCMA) and the ptimes as negotiated are also maintained.
2. In the following diagram, PCMU is offered in the ingress realm with a ptime of 30ms, and forced to 40 ms in the
egress realm by policy.
The answerer chooses to use PCMU with a 20 ms ptime. Thus the call is not transcoded, but it is transrated from
30ms in the ingress realm to 20ms in the egress realm.
3. In the following diagram, PCMU and G723 are offered in Realm A. The top codec’s ptime (30ms) is implied as
the one for the ingress realm. The Oracle Communications Session Border Controller adds PCMA to the SDP
offer with a 40ms ptime.
The answerer chooses to use PCMU with a 40 ms ptime. Thus the call is transrated from 30ms in the ingress realm
to 40ms in the egress realm.
Transcodable Codecs
The following list shows the transcodable codecs which the Oracle Communications Session Border Controller can
add to SDP. These codecs all reflect default media profiles for their given names. Enter codecs in the configuration
exactly as below.
• PCMU
• PCMA
• G729
• G729A
• iLBC
• telephone-event
• T.38
• G711FB
• G726
• G726-16
• G726-24
• G726-32
• G726-40
• G722
• G723
• GSM
• AMR
• AMR-WB
• EVRC0
• EVRC
• EVRC1
• EVRCB0
• EVRCB
• EVRCB1
When creating an override media profile from the previously listed codec, case is ignored. Also, GSM is GSM-FR.
EVRC Configuration
In the ACLI, refer to EVRC codecs exactly as follows:
• hangover
The payload type is dynamic for this codec. Only the 20 ms ptime is supported for transcoding. The media rate will be
fixed to either full or half rate depending on the fixedrate parameter (half rate is default).
EVRCB Configuration
In the ACLI, refer to EVRCB codecs exactly as follows:
EVRCB0
EVRCB
EVRCB1
SBC
Call is established
T.140
The system's transcoding hardware detects baudot tones in the incoming audio stream and generates T.140 packets on
an outbound text stream. In the reverse direction T.140 packets will be detected on the text stream and Baudot tones
will be generated on the appropriate outgoing audio stream.
T.140 to Baudot relay is invoked when an outbound codec-policy removes any text "m=" line from the egressing
offer. The processing also removes all non-Baudot-tone capable codecs from the egress SDP offer. If at this point no
Baudot-capable codecs remain in the SDP, the call is torn down.
Baudot Tones capable codecs:
• PCMA
• PCMU
• EVRC
• EVRC0
• EVRC1
• EVRCB
• EVRCB0
• EVRCB1
Limitations
The following scenarios are not supported:
• Configuration of T.140 in add-codes-on-egress
• Hairpin calls (T.140 - Baudot Relay - T.140)
• Lawful Intercept
• SRTP for T.140
c ode c - pol i c y
n a me T1 4 0 - t o - t o n e s
a l l ow t e xt : no *
a d d - c o d e c s - o n - e g r e s s PCMU
non-relevant parameters omitted
This diagram shows the baseline implementation of T.140 to Baudot tones. The UE sends an INVITE into the core,
via the Oracle Communications Session Border Controller. Codec-policy indicates Oracle Communications Session
Border Controllerto remove all text codecs (including T.140), it also indicates to add PCMU. All non-Baudot codecs
are removed from the egress invite - AMR in this case. The core confirms PCMU in a 200 OK. The Oracle
Communications Session Border Controller forwards the 200 OK to the UE confirming the initially-offered codecs
(AMR and T.140).
The call is set up so that the Oracle Communications Session Border Controller will transcode audio between AMR
and PCMU, and seamlessly relay T.140 to and from Baudot tones.
SBC core
INVITE
m=audio (AMR)
m=text (T.140) INVITE
m=audio (PCMU)
200 OK
200 OK m=audio (PCMU)
m=audio (AMR)
m=text (T.140)
AMR Audio
In this example, the call is initiated from the core. The Oracle Communications Session Border Controller transcodes
between PCMU and AMR via expected means. Then, in the same dialog, the access side then sends a reINVITE
adding T.140 and AMR. Codec policy dictates to accept T.140 on the UE-side and strip the text codec and all non-
Baudot capable codecs from the core side. Additionally, the Oracle Communications Session Border Controller is
ready for T.140 / Baudot relay (transcoding). Thus when the UE begins sending T.140, they are transcoded into tones
within the PCMU stream.
SBC core
INVITE
INVITE m=audio (PCMU)
m=audio (AMR)
200 OK
m=audio (AMR)
200 OK
m=audio (PCMU)
INVITE
m=audio (AMR) INVITE
m=text (T.140) m=audio (PCMU)
200 OK
m=audio (PCMU)
200 OK
m=audio (AMR)
m=text (T.140)
AMR Audio
Figure 16: Call Initiated fom the Core with T.140 reINVITE
Parameter Value
name opus
subname WB
media-type audio
payload-type 104
transport RTP/AVP
clock-rate 48000
req-bandwidth 0
frames-per-packet 0
parameters maxplaybackrate=16000
sprop-maxcapturerate=16000
usedtx=0
average-rate-limit 5000
peak-rate-limit 0
max-burst-size 0
sdp-rate-limit-headroom 0
sdp-bandwidth enabled
police-rate 0
standard-pkt-rate 0
Transcoding the SILK codec requires a special license as it is subject to a royalty agreement. Licensing supports up to
the full density for this codec in bins of 25. A feature bit is required as well as a field for the capacity limit. The
capacity limit is stored in 12 bits per codec allowing up to 102,375 licensed sessions. This limit is sufficient for future
hardware iterations’ projected session densities.
Parameter Value
name SILK
subname wideband
media-type audio
payload-type 103
transport RTP/AVP
clock-rate 16000
req-bandwidth 0
frames-per-packet 0
parameters
average-rate-limit 5000
peak-rate-limit 0
max-burst-size 0
sdp-rate-limit-headroom 0
sdp-bandwidth enabled
police-rate 0
standard-pkt-rate 0
Configuring Transcoding
Codec Policy Configuration
Transcoding is configured by creating codec policies and referencing them from a realm configuration.
• allow-codecs—The allow-codecs parameter takes a list of codecs that you want to pass through the Oracle
Communications Session Border Controller and can explicitly allow them to remain in the SDP for the next step;
codecs not matching the items on this list are removed. This parameter is required.
• add-codecs-on-egress—The add-codecs-on-egress parameter sets the codecs that the Oracle
Communications Session Border Controller adds to an offer if that codec is not already there. This parameter
applies only to the egress policy.
For allow-codecs, order-codecs, and add codecs to codec policies:
You can configure and edit these two transcoding parameters as ACLI lists, meaning that there are add and delete
commands associated with each. You type the name of the parameter, choose the operation you want to perform on
the list (adding or deleting), and then specify the data that you want to add or remove.
The examples in the procedure that follows show you how to add to the lists you are configuring. To remove items
from the allow-codecs list, simply replace the add command you see in these example with delete and the
items you want to remove.
If you want to overwrite previous values, you can enter the command, a Space and the items in the list enclosed in
quotes (“).
1. allow-codecs—Enter a list of codecs that are allowed to pass through the Oracle Communications Session
Border Controller. Use the syntax in the Transcodable Codecs section of this chapter. To allow all codecs, enter an
asterisk (*).
ORACLE(codec-policy)# allow-codecs *
When multiple items are added, enclose them in quotes. For example:
ORACLE(codec-policy)# allow-codecs G729 G711 AMR
2. add-codecs-on-egress—Enter the codecs that you want added to the SDP offer for the egress codec policy.
If you leave this parameter blank, then the Oracle Communications Session Border Controller will not add codecs
to the SDP answer. This parameter cannot be wildcarded; other possible value are listed in the Transcodable
Codecs section of this chapter.
ORACLE(codec-policy)# add-codecs-on-egress G729
If you need to modify the list of configured codecs, you must enter the complete list at once.
Ordering Codecs
Codec policy can specify the order that codecs appear in the SDP offer or answer. Refer to the Codec Policy
Definition section of this chapter for configuration information.
To configure an order which codecs appear in the offer:
order-codecs—Enter the order in which you want codecs to appear in the SDP offer or answer. You can enter
them in any of the ways described in the preceding explanation.
ORACLE(codec-policy)# order-codecs G711 * G729
Transrating Configuration
The following procedure explains how to configure transrating for a codec policy. This codec policy must be applied
as an egress codec policy.
To configure forced ptime for a codec policy:
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 network-parameters and press Enter.
<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>::* PCMU::* Matches any and all media profiles with the name value
configured as PCMU with any and all subname configured.
<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
Wildcarding add-codecs-on-egress
It is important to note that you may not configure add-codecs-on-egress with a wildcarded subname in a
codec policy. You may only add a specific instance of a media type.
Valid:
add-codecs-on-egress PCMU
add-codecs-on-egress PCMU::customer1
Invalid:
add-codecs-on-egress PCMU::*
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 Communications Session Border Controller 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.
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 Communications Session Border Controller 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 Communications Session Border Controller to allow all codecs except the one(s)
you specify.
ORACLE(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 Communications
Session Border Controller with only audio codecs, the Oracle Communications Session Border Controller
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.
ORACLE(codec-policy)# allow-codecs (* audio:no)
• Order—List of the codecs where you specify their preferred order in the outgoing media offer. The Oracle
Communications Session Border Controller 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:
• For an order rule set this way
ORACLE(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:
ORACLE(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
ORACLE(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
Communications Session Border Controller will select a non-forced codec for the outgoing offer.
ORACLE(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.
ORACLE(codec-policy)# allow (* PCMA:no)
continuous character string (no spaces allowed) that starts with the :( character sequence and is terminated by a
closing parenthesis. For example,
ORACLE(codec-policy)# allow-codecs PCMU:(!G729)
which can be interpreted as — allow PCMU if the G729 codec is not in the SDP offer after ingress codec policy
processing.
An example of using add-codecs-on-egress is:
ORACLE(codec-policy)# add-codecs-on-egress PCMU:(PCMA)
which can be interpreted as — add PCMU if PCMA codec is in the SDP offer after ingress codec policy processing.
If PCMA is in the SDP offer after ingress codec policy processing, the add-codecs-on-egress ACLI command
is treated as add-codecs-on-egress PCMU. If PCMA is not in the SDP offer after ingress codec policy
processing, add-codecs-on-egress is treated as empty.
Both the conditioned codec and/or the condition itself can contain subnames. For example,
ORACLE(codec-policy)# add-codecs-on-egress AMR::ONE:(AMR::TEST0)
which can be interpreted as — add AMR::ONE if AMR::TEST0 codec is in the SDP offer after ingress codec policy
processing.
Codecs contained in the condition can be wildcarded. For example,
ORACLE(codec-policy)# add-codecs-on-egress AMR::ONE:(AMR::*)
which can be interpreted as — add AMR::ONE if any AMR codec is in the offer after ingress codec policy
processing.
An example of using order-codecs is:
ORACLE(codec-policy)# order-codecs (PCMU:(PCMU) *)
which can be interpreted as — set the codec order to PCMU followed by the list after ingress codec policy processing
if PCMU is not present. When the system adds a codec, the codec goes to the end of the offered list. This conditional
format may be used to place an added codec at the front of list.
6. add-codecs-on-egress—Enter the codecs that the Oracle Communications Session Border Controller adds
to an egress SDP offer if that codec is not already there. This parameter applies only to egress offers. For more
information, refer to the Manipulation Modes section above.
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. For details of
conditional codec policies, refer to 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 ( ( ) ). For more information, refer to the Manipulation
Modes section above.
The codecs that you enter here must have corresponding media profile configurations.
order-codecs can be used to construct ingress, egress, or conditional codec policies. For details of conditional
codec policies, refer to Conditional Codec Policies.
8. Save and activate your configuration.
Your codec policy configuration will resemble the following example:
codec-policy
name private
allow-codecs g723:no pcmu video:no
order-codecs pcmu *
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.
SBC Answerer
EVRC pt=99
EVRC0 pt=100
EVRC1 pt=101 SDP negotiates as both
EVRC pt=99 sides using EVRC/99
EVRC pt=103
EVRC0 pt=104 reINVITE Answerer can not
EVRC1 pt=105 change RTP it sends with
EVRC pt=99 respect to initial INVITE
For transcoded calls, enabling this feature places no additional load on the system. But for calls that are not
transcoded, this feature consumes transcoding resources.
ORACLE(media-manager-config)#
3. Use the options +audio-allow-asymmetric-pt command to enable support for asymmetric payload
types.
ACMEPACKET#(media-manager) options +audio-allow-asymmetric-pt
ACMEPACKET#(media-manager)
4. Type done to save your configuration.
Controller can be configured to behave in an RFC-compliant manner, which is to support the asymmetric case.
Symmetric-only cases are enforced by default.
Since ingress-side behavior is to reply with the payload type offered, it expects payload type 99 and sends payload
type 99. Thus to facilitate RFC2833 interworking, the payload types will be remapped from 99 -> 101 in the
eastbound direction and 101 -> 99 in the westbound direction.
Therefore, the Oracle Communications Session Border Controller being able to support asymmetric payload types for
RFC2833 packets, will remap from 99 ->101 in the eastbound direction and not have to remap the payload type value
in the westbound direction.
The rfc2833-allow-asymmetric-pt option can be configured on a sip-interface or session-agent where this behavior
is desired.
KPML to RFC2833
KPML to RFC2833 interworking requires that the INVITE request or response's SDP does not contain telephone-
event, and is received from
• A session agent with kpml-2833-interworking set to enabled
• A session agent with kpml-2833-interworking set to inherited from the SIP interface (with kpml-2833-
interworking set to enabled)
• A previous hop that is not a session agent, and the SIP interface the message received on has kpml-2833-
interworking set to enabled.
The egress side of the call must have rfc2833-mode set to preferred in either the SIP interface or session agent, so
that the Oracle Communications Session Border Controller inserts telephone-event in the SDP. Setting rfc2833-mode
to dual is unsupported. The answerer must respond to the invite accepting of telephone-event media. The Allow-
Event: kpml header is removed from the INVITE request or response when KPML-interworking is not set to enabled
on the next hop.
If the INVITE succeeds, the Oracle Communications Session Border Controller replies with a SUBSCRIBE request
for the KPML event to the caller.
If the caller replies to the SUBSCRIBE with a 2xx, all subsequent NOTIFY request received on the dialog are
processed and replied to with a 200 OK. Each digit in the NOTIFY request will generate a telephone-event on the
egress side of the call.
The Oracle Communications Session Border Controller generates a refresh SUBSCRIBE before the subscription
expires.
If the call negotiates to RFC 2833 to RFC 2833, no KPML interworking will be performed.
The following diagram shows the standard case where KPML to RFC 2833 interworking is performed.
INVITE w/SDP
Allow Events:KPML
NO 2833 INVITE w/SDP
2833
200 OK w/SDP
2833
200 OK w/SDP
NO 2833
ACK
ACK
SUBSCRIBE
Expires=3600
Event=kpml
200 OK
NOTIFY
XML: with Digit 1
Event: kpml
200 OK 200 OK
KPML to RFC 2833 translation is also supported when used in conjunction with SDP insertion on the KPML side of
the call. For example:
SBC
Access side
Access endpoint: Core side
kpml-2833-interworking=enabled rfc2833-mode=preferred Core endpoint:
only supports add-sdp-invite=enabled RFC2833 support
KPML for DTMF add-sdp-profiles=xxx
NOTIFY
XML: with Digit 1
Event: kpml
200 OK 200 OK
INVITE w/SDP
2833
INVITE w/SDP
Allow-Events:kpml
200 OK w/SDP
200 OK
2833
ACK
ACK
SUBSCRIBE
Expires=3600
Event=kpml
200 OK
selection: 1
ORACLE(sip-interface)#
3. kpml-interworking—Set this parameter to enabled to use KPML-2833 interworking.
4. Type done to save your configuration.
selection: 1
ORACLE(session-agent)#
3. kpml-interworking—Set this parameter to enabled for the Oracle Communications Session Border Controller to
interwork RFC2833 from the other call leg to the call leg running through this session agent. This parameter may
be set to inherit to use the kpml-interworking value configured on the receiving SIP interface.
4. Type done to save your configuration.
If the session originator and terminator in the previous diagram exist in two different realms, you must execute the
show sidp codecs command twice, once for each realm. A single PCMU count will be reflected in each
respective query because only one m= line emanates from each realm.
If the session originator and terminator in the previous diagram exist in two different realms, you must execute the
show sidp codecs command twice, once for each realm. A single PCMU count and a single PCMA count will
be reflected in each respective query because two m= lines emanate from each realm.
If the session originator and terminator in the previous diagram exist in two different realms, you must execute the
show sidp codecs command twice, once for each realm. A single PCMU count appears in one query and a
single PCMA count appears in the other query because only one m= line emanate from each realm.
An example show sipd codecs <realm ID> command follows:
Logs
A log file named log.xserv can be used for debugging the transcoding feature. This log records the API between
the host software and the DSPs and any errors that are encountered.
Alarms
The transcoding feature employs several hardware and software alarms to alert the user when the system is not
functioning properly or overload conditions are reached.
Monitored Transcoding SNMP Object & OID in Trap Sent Clear Trap Sent
Resource apSysMgmtTrapType
Monitored Transcoding SNMP Object & OID in Trap Sent Clear Trap Sent
Resource apSysMgmtTrapType
The following SNMP Objects are inserted into the apSysMgmtTrapType when sending and clearing a transcoding
capacity trap. You mayt query them individually with an SNMP GET.
• apSysXCodeCapacity (1.3.6.1.4.1.9148.3.2.1.1.34)
• apSysXCodeAMRCapacity (1.3.6.1.4.1.9148.3.2.1.1.35)
• apSysXCodeAMRWBCapacity (1.3.6.1.4.1.9148.3.2.1.1.36)
• apSysXCodeEVRCCapacity (1.3.6.1.4.1.9148.3.2.1.1.39)
• apSysXCodeEVRCBCapacity(1.3.6.1.4.1.9148.3.2.1.1.40)
SNMP
The following sections have been removed from this document. Their content has been reformatted and appears in the
MIB Reference guide in the Codec and Transcoding MIB (ap-codec.mib) section:
• SNMP Retrieval of Transcoding Statistics
• Acme Packet Codec and Transcoding MIB (ap-codec.mib)
• Acme Packet System Management MIB (ap-smgmt.mib)
Generating RTCP
The Oracle Communications Session Border Controller is capable of creating and sending RTCP reports using
Transcoding resources. This produces RFC 3550 compliant RTCP report information on media traffic for active
sessions. The system calculates these statistics using measurements on traffic between a target end station and itself.
With respect to a given media session, the system does not produce end-to-end reports. In addition, the system can
drop RTCP reports generated upstream so target stations don't receive RTCP reports that are redundant to its own.
RTCP reporting generated at the Oracle Communications Session Border Controller provides the following benefits:
• Provide RTCP reporting to core applications that may otherwise not be receiving this data.
• Provide RTCP reporting to access elements, including mobile client applications, that may otherwise not be
receiving this data.
• Generate valid RTCP data for transcoded calls.
• Generate RTCP data from the Oracle Communications Session Border Controller's perspective.
• Applicable RTCP reports continue to be sent when a call is muted or placed on-hold.
The user enables and specifies the type of calls on which the system generates RTCP reports via configuration.
Applicable configuration includes creating rtcp-policy objects and applying them to realms. These objects specify
whether to issue reports for transcoded or all calls traversing the realm. There is also a configuration to disable the
policy.
How it Works
The Oracle Communications Session Border Controller generates RTCP by sending RTCP sender report information
to the media termination point within 5 seconds after an RTP session starts, per RFC 3550. All RTCP messaging
includes Sender Reports and, if the end station is receiving media, statistics corresponding to the received media. This
messaging persists, within 5-second windows for the duration of the session. The system sends a goodbye message no
more than 20 ms after the call is complete. The network administrator should note this timing and ensure that network
NAT configuration does not block these final messages. Depending on call type and configuration, the system listens
for and drops RTCP reports generated upstream. RTCP reports generated prior to transcoding provide unreliable
information.
All reports include the source description with a CNAME string. The CNAME string is the IP address and port
number used for the corresponding media stream's RTCP in the format:
<UDP Local Port Num for RTCP>@<IP address of the applicable steering pool>
The system sources this data from the applicable steering pool configuration.
Before proceeding, make sure you know whether your platform supports transcoding. As described in the section on
RTCP generation, this can affect your configuration and operational results.
To have your Oracle Communications Session Border Controller generate RTCP traffic statistics reporting:
1. In Superuser mode, use the following command sequence to access the rtcp-policy element.
ORACLE# configure terminal
ORACLE(configure)# media-manager
ORACLE(media-manager)# rtcp-policy
From this point, you can configure a new RTCP policy or select an existing policy for editing.
2. name—Name your policy for use when applying it to a realm-config.
ORACLE(rtcp-policy)# name report-allcalls
3. rtcp-generate—Enter the desired setting to generate RTCP. The effect of these settings is dependent on the
platform and the presence of specific hardware on that platform. See the section on Generating RTCP in the ACLI
Configuration Guide for these details.
• none—Disables this policy.
• all-xcoded-calls—The system generates RTCP report information only for the transcoded calls that pass
through the realm.
• all-calls—The system generates RTCP report information for all calls that pass through the realm.
ORACLE(rtcp-policy)# rtcp-generate all-calls
4. Type done and exit to retain your configuration.
5. Access the realm to which you want to apply this rtcp-policy.
ORACLE(media-manager)# realm-config
ORACLE(realm-config)# select
6. Apply the rtcp-policy to your realm.
ORACLE(realm-config)# rtcp-policy report-allcalls
7. Type done and exit configuration mode. Save and activate your configuration.
1. Working from the back of the chassis, carefully open the NIU's latch. The hotswap LED placed directly above the
NIU will transition from green (present/latch close/ready) to blinking blue. After 10 seconds it will stop blinking
and remain blue (present/latch open/not ready)
2. You can now safely remove the NIU. To replace an NIU, insert an NIU of the same type as the one used before.
Removing the NIU generates a critical alarm notifying the user that the NIU has been removed. Additionally, the
VFD displays a hardware alarm and starts blinking
To see the alarm use: "display-alarms" from the ACLI.
The alarm manager clears the critical alarm, and issues a new minor alarm to alert the user that an NIU was inserted
after the boot sequence. At this point the system is still OOS.
From the ACLI, issue a "reboot force" command.
After rebooting the standby, it will revert to standby mode.
DTMF Interworking
Multimedia devices and applications can exchange user-input DTMF information end-to-end over IP networks. The
Oracle Communications Session Border Controller provides the capabilities required to interconnect networks and
devices that use different DTMF indication signaling protocols.
DTMF Indication
There are three ways to convey DTMF information for packet-based communications:
• DTMF audio tones: DTMF digit waveforms are encoded inline with voice packets. This method only works with
uncompressed audio codecs like G.711. Compressed audio codecs like G.729 and G.723 are incompatible with
DTMF audio. DTMF audio is also referred to as in-band tones.
• Out-of-band signaling events:
SIP INFO messages with Content-Type: application/dtmf-relay define out-of-band signaling events for
transmitting DTMF information. SIP INFO messages separate DTMF digits from the voice stream and send them
in their own signaling message.
• RTP named telephony events (NTE): RFC 2833 telephone-events are a standard that describes how to transport
DTMF tones in RTP packets according to section 3 of RFC 2833. Of the three RTP payload formats available, the
Oracle Communications Session Border Controller supports RTP NTE.
reference time for subsequent RFC 2833 packets for that same event. For events that span multiple RTP packets, the
RTP timestamp identifies the beginning of the event. As a result, several RTP packets might carry the same
timestamp.
Capability Negotiation
SDP capability negotiation is the first phase of enabling DTMF transfer. The completion of the SDP offer/answer
exchange yields a set of supported codecs between each UA and the Oracle Communications Session Border
Controller .
For DTMF transfer consideration, SDP manipulation is directed by parameters set in one of three configuration
elements:
• codec policy
• signaling interface’s RFC 2833 mode
• session agent’s RFC 2833 mode
The Oracle Communications Session Border Controller performs SDP manipulation (addition, removal, or
modification of supported codecs) toward the called party first by any applicable codec policies. If one or more of the
actions which define telephone-event Modification by Codec Policy occurs, then SDP manipulation is only performed
by the codec policy configuration, not by RFC 2833 mode parameters in the signaling interface or session agent.
If a codec policy attached to either the ingress or egress realm triggers SDP manipulation, then the other realm uses
codec policy for any telephone-event SDP manipulation; none of the RFC 2833 Mode configurations are used for
SDP manipulation.
Note: If the call does not trigger the evaluation of any codec policies, all DTMF transfer processing is only
subject to RFC 2833 Mode rules.
If none of the telephone-event Modification by Codec occur, then the Oracle Communications Session Border
Controller performs SDP manipulation according to the RFC 2833 Mode parameters in the signaling interface or
session agent.
2. telephone-event maintained in SDP: The codec policy maintains the offered telephone-event in the SDP sent into
the egress realm. Although telephone-event was not answered in the egress realm, telephone-event is added back
to the offerer-side SDP because of the add-on-egress setting in the ingress realm.
3. telephone-event removed from SDP: codec policy removes telephone-event from the initial SDP offer. telephone-
event is not forwarded to the Answerer, and subsequently not returned from the answerer, or forwarded again to
the offerer.
2. In the following example, RFC 2833 is set to preferred mode on the SDP offer side of the call. The Oracle
Communications Session Border Controller maintains the telephone-event support even though telephone-event is
not supported on the SDP answerer’s side of the call.
Translation Evaluation
After SDP has been negotiated, the Oracle Communications Session Border Controller determines what types of
DTMF translation takes place for the call. The Oracle Communications Session Border Controller sequentially
evaluates the following rules for each call leg to determine what DTMF indication type it will forward to an endpoint.
1. RFC 2833—When the SDP offer/answer exchange resolves to both the Oracle Communications Session Border
Controller and the endpoint supporting RFC 2833 on one side of the call, the Oracle Communications Session
Border Controller will send DTMF indications in RFC 2833 format.
2. DTMF audio tones—Three conditions must be met for the Oracle Communications Session Border Controller to
support DTMF audio tones, as transcoded from another DTMF indication form:
• The applicable codec policy’s dtmf in audio parameter is set to preferred
• The endpoint and Oracle Communications Session Border Controller have negotiated to a DTMFable codec
(G711)
• Transcoding resources are available
Note: Because of rule number one, rule number two can not happen if RFC 2833 is supported in SDP
—Only one media-based DTMF transfer method, RFC 2833 or DTMF audio tones may be used on a
call leg.
3. If neither RFC 2833 nor DTMF Audio tones are supported on a call leg, as a result of SDP negotiation, then the
Oracle Communications Session Border Controller forwards DTMF indication messages to that side in signaling
message format (SIP INFO).
In the following images that illustrate DTMF transfer scenarios, a gears icon appears when relevant. This icon
indicates that the Oracle Communications Session Border Controller performs DTMF indication processing,
creating DTMF audio tones or RFC 2833 telephone-event messages from another form of DTMF indication.
A SIP INFO message received from either the offerer or answerer is forwarded unconverted to the other side of the
call.
If there is no audio transcoding enabled for this call, and the egress side is set to dual, a received SIP INFO message
will not be converted to both RFC 2833 and SIP INFO messaged for sending to the other side of the call.
If DTMF audio tones are received from either the offerer or answer, they are forwarded unconverted to the other side
(when the audio portion of the call is not transcoded).
A SIP INFO message received by the Oracle Communications Session Border Controller from either the offerer or
answerer is converted into the DTMF transfer method that the previous diagram shows for the egress side of the
message. In this case, transcoding resources are used.
If a SIP message is received from the offerer, it is forwarded unconverted to the answerer.
If the two sides of the call support DTMF audio tones, but use different audio codecs, and the SDP answer side
supports the three DTMF Audio Tone conditions and does not support RFC 2833 then the Oracle Communications
Session Border Controller will preserve DTMF audio tone indication across the call.
Transcoding resources are used only if different audio codecs are used or the Override Preferred DTMF Audio feature
is enabled.
Dual Mode
Dual mode is used to send both RFC 2833 and the protocol-specific DTMF indication to a UA when possible: SIP
INFO from a SIP interface.
To consider dual mode scenarios, the Oracle Communications Session Border Controller sets up the call SDP. At the
conclusion of the capability negotiation, the Oracle Communications Session Border Controller is configured to
support DTMF Audio tones or RFC 2833 independently for each side of the call.
When the call leg supports RFC 2833 as the means of DTMF transfer, the Oracle Communications Session Border
Controller checks if the SIP interface’s (or session agent’s) RFC 2833-mode parameter is configured to dual. If it is,
the Oracle Communications Session Border Controller sends both RFC 2833 and SIP INFO messages to the UA on
this side of the call.
Note: Whether RFC 2833 support was initiated between the Oracle Communications Session Border
Controller and the UA by a codec policy or by the rfc2833-mode parameter, the Oracle Communications
Session Border Controller looks to the rfc-2833 parameter to consider if dual mode is supported.
When the call leg supports DTMF audio tones as the means of DTMF transfer, the Oracle Communications Session
Border Controller checks if the codec policy’s dtmf-in-audio parameter is configured to dual. If it is, the Oracle
Communications Session Border Controller sends both DTMF audio tones and SIP INFOmessages to the UA on this
side of the call.
P-Dual-Info Header
When the Oracle Communications Session Border Controller forward both media DTMF indication and signaling
based DTMF indication for the same received DTMF indication, a P-Dual-Info header is added to the forwarded
signaling message. You can configure the appearance of the header with the dual-info option. The default header
appearance is:
P-dual-info: true
P-Dual-Info headers are only inserted into SIP INFO messages.
Example 1
In this example, RFC 2833 is supported on the egress side of the call. The egress SIP interface or session agent’s
rfc2833-mode is set to dual mode. When the Oracle Communications Session Border Controller forwards RFC 2833
to the SDP answerer, it also creates and forwards a corresponding SIP INFO message toward the target.
Example 2
In this example RFC 2833 telephone-event is not supported on the egress side of the call, but DTMF audio tones are.
If the Oracle Communications Session Border Controller receives an RFC 2833 message, it is converted to DTMF
audio tones. When the Oracle Communications Session Border Controller forwards DTMF audio tones to the SDP
answerer, it also creates and forwards a corresponding SIP INFO message toward the target.
Note: Enabling one or both of these exceptions can cost DTMF translation resources whether they occur in
the network processors or on transcoding modules. The translate-non-inband-event exception is especially
costing because it reserves transcoding for all calls that resolve to support for DTMFable to DTMFable
codecs.
DTMF indication processing, only the call legs between the endpoints and Oracle Communications Session Border
Controller are considered.
The Oracle Communications Session Border Controller evaluates that the signaling path to and from the call server
terminates on the same IP address and port on the Oracle Communications Session Border Controller. This means
that it’s a spiral call. In addition, the media IP addresses and ports in the SDP indicate that the Oracle
Communications Session Border Controller does not need to send the media into the call server’s realm.
An issue occurs when DTMF indication is relayed either by RFC 2833 or DTMF audio tones for a spiral call. Since
the DTMF indication is in the media path, the call server remains unaware of the signaling; no media-based DTMF
indication digits will ever reach the call server. In order to include the call server in the DTMF-indication signaling,
you should set the dtmf-in-audio and/or rfc-2833 mode used for the realm or signaling interface where the call server
is to dual.
P-Dual-Info Header
The P-Dual-Info header is used in a spiral call scenario, when the call leg to (and from) the call server is set to dual.
While the media portion of a spiral call goes from endpoint to endpoint through the Oracle Communications Session
Border Controller, the signaling portion of the call loops through a call server.
The Oracle Communications Session Border Controller inserts a P-Dual-Info header into a SIP info message sent to
the call server, which in turn forwards the SIP INFO message back to the Oracle Communications Session Border
Controller. Seeing the P-Dual-Info header, the Oracle Communications Session Border Controller knows not to
forward this SIP INFO message to the target endpoint because it would be a duplication of DTMF indication already
sent to the endpoint in media format.
SIP Interface
To configure the RFC 2833 mode on a SIP interface:
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 sip-interface and press Enter.
ORACLE(session-router)# sip-interface
4. If you are adding support for this feature to a pre-existing SIP interface, then you must select the specific
configuration instance, using the ACLI select command.
5. rfc2833-mode—Set this parameter to either transparent, preferred, or dual based upon the behavior
your want for this SIP interface.
• transparent—does not add RFC 2833 telephone-event into SDP if not present, and does not prefer.
• preferred—adds RFC 2833 telephone-event media type into SDP and prefers to use this method for DTMF
indication.
• dual—adds RFC 2833 telephone-event media type into SDP and sends both SDP and signaling-based DTMF
indications if possible.
6. rfc2833-payload—Set this parameter to the media-type value you wish to use when inserting RFC 2833
telephone-events into an SDP offer. 101 is the generally accepted media type for RFC 2833 telephone-events.
7. Save and activate your configuration.
Session Agent
Session agent RFC 2833 mode configurations override those on the signaling interface where they exit. The none
parameter is used to defer to the signaling interface.
To configure the RFC 2833 mode on a session agent:
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.
Codec Policy
To configure a codec policy to support DTMF audio tones, as transcoded:
1. In Superuser mode, type configure terminal and press Enter.
ORACLE# configure terminal
2. Type media-manager and press Enter.
configure# media-manager
3. Type codec-policy and press Enter.
ORACLE(media-manager)# codec-policy
ORACLE(codec-policy)#
4. If you are adding support for this feature to a pre-existing configuration, then you must select the specific
configuration instance, using the ACLI select command.
ORACLE(codec-policy)# select
<name>:
1: private
2: public
selection:1
ORACLE(codec-policy)#
5. dtmf-in-audio—Set this parameter to disabled, preferred, or dual based upon how the Oracle
Communications Session Border Controller should support the conversion of signaling messages or RFC 2833 to
DTMF Audio tones in the realm where this codec policy is active.
• disabled—does not support DTMF audio tones as transcoded in this realm.
• preferred—supports DTMF audio tones as transcoded in this realm.
• dual—supports both transcoded DTMF audio tones and signaling-based DTMF indications if possible.
6. Save and activate your configuration.
egress. At the conclusion of the DTMF indication, the three end-event packets are sent. The packet arrangement when
the user presses the digit 5 for 160ms, with the default 50ms interval follows:
When either no DTMF event duration is specified, or the event duration is less than the 50ms default minimum, you
can set the default RFC 2833 telephone-event duration using default-2833-duration parameter in the media
manager configuration. This is the value that the Oracle Communications Session Border Controller, uses for the
duration of a telephone event when none is specified in the incoming message. The default-2833-duration’s
valid range is 50-5000ms. The Oracle Communications Session Border Controller, also uses this configured value
when it receives a SIP INFO message with a duration less than the minimum signal duration.
You can configure the minimum duration at which RFC 2833 telephone-events are generated by the Oracle
Communications Session Border Controller, using the min-signal-duration option in the media manager
configuration, thus changing the lower threshold of the default-2833-duration parameter from 50 ms to your
own value. If the duration the Oracle Communications Session Border Controller, receives is less than the threshold,
it uses the value configured in the default-2833-duration parameter.
Note: Timestamp changes and duration changes only take effect when the 2833 timestamp (rfc-2833-
timestamp) is enabled in the media manager configuration. If you enable the rfc-2833-timestamp parameter,
but do not configure the default-2833-duration parameter, the default-2833-duration parameter defaults to 100
ms.
5. default-2833-duration—Set this parameter to the default value you wish to use when the Oracle
Communications Session Border Controller, creates or generates DTMF-indication messages.
6. rfc2833-end-pkts-only-for-non-sig—Set this parameter to enabled for the Oracle Communications
Session Border Controller, to only send the three RFC 2833 telephone-event end-packets to indicate a total event
duration, rather than the running total from time=0.
7. options—Set the options parameter by typing options, a Space, the option name min-signal-
duration=x (where x is the value in milliseconds you want to use for the threshold) with a plus sign in front
of it. Then press Enter.
8. Save and activate your configuration.
TSM/TSCF Overview
Tunnel Session Management (TSM) is based upon an existing 3rd Generation Partnership Project (3GPP) Technical
Requirement, TR 33.8de V0.1.3 (2012-05) that seeks to define a standardized approach for overcoming non-IMS
aware firewall issues. Within the 3GPP, TSM is referred to as Tunneled Services Control Function or TSCF. Oracle
uses the 3GPP terminology: TSCF.
TSCF improves firewall traversal for over-the-top (OTT) Voice-over-IP (VoIP) applications, and reduces the
dependency on SIP/TLS and SRTP by encrypting access-side VoIP within standardized Virtual Private Network
(VPN) tunnels. As calls or sessions traverse a TSCF tunnel, the Oracle Communications Tunneled Session Controller
forwards all SIP and RTP traffic from within the TSCF tunnel to appropriate servers or gateways within the secure
network core. Operating in a TSM topology, the SBC provides exceptional tunnel performance and capacity, as well
as optional high availability (HA), DoS protection and tunnel redundancy that improves audio quality in lossy
networks.
As implemented by Oracle Communications, TSM/TSCF terminology includes:
• TSC client—Sometimes referred to as a Tunneled Service Element (TSE). It facilitates TSCF tunnel creation and
management within client applications residing on network elements.
• TSC server—The SBC that is used to terminate TSC tunnels.
• Tunnel Session Management (TSM)— The overall solution that covers both the TSC Server and TSC Client.
• TSCF (Tunneled Services Control Function)—The actual function that runs on the SBC. TSCF is often used in the
naming of the ACLI configuration and management objects.
A TSC client runs within client applications residing on network elements — for example: workstations, laptops,
tablets and mobile devices (Android, iPhone, Windows, or iPad). Oracle provides a software development kit (SDK)
that facilitates TSCF tunnel creation and management. Refer to the companion document, the TSE SDK Guide, or to
the SDK on-line Help system for information on client-side programming, and to access reference applications that
provide client-specific coding examples for supported operating systems.
To deploy TSC clients, customers and 3rd party Independent Software Vendors (ISVs) need to link the open source
TSC client libraries with their applications, which can then initiate and establish SSL VPNs (TLS or DTLS) to the
TSC server.
In contrast to a TSC client, a TSC server resides on the Oracle Communications Session Boarder Controller
(OCSBC), and provides server-side functions that accept, establish, and manage tunnel connections between remote
TSC-client-enabled applications and core Proxy-Call Session Control Function and SIP proxies (P-CSCFs/SIP
proxies). The following illustration shows various ways in which TSC clients can be deployed across different
network segments (WiFi, LAN, WAN, LTE) and interface with common network elements (firewalls, HTTP proxies,
and radio access network equipment).
TSCF Entitlements
In order to use correct feature of TSCF, the below entitlement commands need to be used to apply correct setup.
If this is your first time use the TSCF entitlement, you first need to setup product as below.
ORACLE# setup entitlements
Product not initialized; Please use 'setup product'
--------------------------------------------------------------
WARNING:
Alteration of product alone or in conjunction with entitlement
changes will not be complete until system reboot
Last Modified
--------------------------------------------------------------
1 : Product : Uninitialized
Product
1 - Session Border Controller
2 - Session Router - Session Stateful
3 - Session Router - Transaction Stateful
4 - Peering Session Border Controller
Enter choice :
enable TSCF
entitlement.
Use setup entitlements to change entitlements for your TSCF enabled status, as below.
ORACLE# setup entitlements
-----------------------------------------------------
Entitlements for Session Border Controller
Last Modified: 2015-05-19 22:07:05
-----------------------------------------------------
1 : Session Capacity : 32000
2 : Accounting : enabled
3 : IPv4 - IPv6 Interworking : enabled
4 : IWF (SIP-H323) : enabled
5 : Load Balancing : enabled
6 : Policy Server : enabled
7 : Quality of Service : enabled
8 : Routing : enabled
9 : SIPREC Session Recording : enabled
10: Admin Security with ACP/NNC :
11: IMS-AKA Endpoints : 0
12: IPSec Trunking Sessions : 0
13: MSRP B2BUA Sessions : 0
14: SRTP Sessions : 0
15: TSCF Tunnels : 10000
License Requirements
TSCF availability is dependant on the acquisition and installation of a TSCF license.
The TSCF license supports distinct tunnel tiers (counts) as follows: 1K, 5K 10K, 20K, 30K, 40K, 50K, 60K, 70K,
80K, 90K, 100K, 110K, 120K, 130K, 140K, 150K, 160K, 170K, 180K, 190K, 200K.
TSCF also requires the TLS license, and standard protocol-based licenses (for example, SIP) based on network traffic
requirements. The Denial of Service detection/prevention capability described in Denial of Service, requires a DoS
license.
Use the show features ACLI command to display a list of installed licenses. The resulting display will resemble the
following example that displays a superset of available licenses.
ORACLE# show features
Total session capacity: 32000
TSCF tunnel capacity : 200000
Enabled features:
SIP, H323, IWF, QOS, ACP, Routing,
Load Balancing, Accounting, High Availability,
PAC, LI, External BW Mgmt, TLS, Software TLS,
External CLF Mgmt, External Policy Services, ENUM, H248,
H248 SCF, H248 BGF, NSEP RPH, LI Debug,
Session Replication for Recording, Transcode Codec AMR,
Transcode Codec EVRC, DoS, IKE, IPv4-v6 Interworking, RTSP,
IDS, Transcode Codec EVRCB, Software PCOM, Security Gateway,
SIP Authorization/Authentication,
Database Registrar (0 contacts), IDS Advanced,
SLB (2000000 endpoints), Allow Unsigned SPL files,
Session Recording, Policy Director,
TSCF (200000 TSCF tunnels), Transcode Codec AMR-WB, CX
ORACLE#
Deployment Models
Based on local network topology and requirements, TSM service can be deployed in two ways:
• Decomposed model
• Combined model
Decomposed Model
The decomposed model provides TSC functionality on an Oracle server (for example, a Multiprotocol Security
Gateway or a generic SBC). Regardless of the supporting platform, the TSC server acts as a pass through server,
using a data-flow (refer to TSCF Data Flow Configuration) to forward all tunnel traffic to a pre-determined IP
address. In the simplest topology, this address would access a gateway providing the protocol support required to
route the previously tunneled traffic to its ultimate destination. Alternatively, the data-flow could direct tunneled
traffic to another SBC that provides P-CSCF (Proxy-Call Session Control Function) services as shown in the
following illustration.
Combined Model
The combined model involves deploying both the TSCF and P-CSCF on the same Oracle SBC. With this model, the
TSCF can be configured to pass SIP traffic to the co-located P-CSCF (thus providing standard SIP processing), and to
use a data-flow to pass all non-SIP traffic to a designated destination, most often a gateway that provides the protocol
support required to route the previously tunneled data traffic to its ultimate destination.
The following figure illustrates traffic pass-through within the Combined model.
Within this combined TSC server:
• 192.168.10.10 (a SIP interface) provides a TSCF interface to the access realm (refer to TSCF Interface
Configuration for procedural details)
• The tunnel client sends SIP messages to 182.168.55.55 (a SIP interface not resident on the Oracle SBC)
• In this case, all traffic is subject to the data-flow, which directs both SIP signalling and media streams to a
gateway for routing to the destination IP address
Tunnel Establishment
Tunnel creation is initiated by the client application that first establishes a TLS and/or DTLS tunnel between the TSC
client and the TSC server. Tunnel creation is completed with a single exchange of configuration data accomplished by
a TSC client request and TSC server response. Refer to the TSE SDK Guide for detailed information on tunnel set-up
procedures.
The following illustration briefly explains the IP addresses used during TSM tunnel establishment and operation.
• TSCF External IP—This public IP address is visible to any endpoint; TSC client requests for tunnel establishment
are directed to this address (refer to TSCF Interface Configuration for procedural details).
• TC source IP—This public IP address identifies either the source address of the TSC client in its respective access
network, or the IP address of an intervening proxy, firewall, or NAT device.
• Internal Tunnel IP—This private address will be assigned to the TSC client (assuming authentication is
successful) from a configured pool of IP addresses on the TSC server. Refer to TSCF Address Pool Configuration
for procedural details.
• TC Application IP—This private IP address identifies a specific application (SIP/RTP/etc.) at the TSC client site.
All packets between the client application on the TSC client and the TSC server are comprised of inner and outer
parts separated by a TLS header. All data after the TLS header is encrypted.
• Outer headers contain TSC client and TSC server addresses
• Inner headers contain application and P-CSCF addresses
• Payload packets carry application data between the TSC client and the TSC server
• Control payloads support tunnel management and configuration activities such as the assignment of a TSC client
inner IP address, and the exchange of keepalive messages
The following two illustrations depict simplified packet formats.
The following illustrations provide a more detailed view of packet structure and addressing. The first figure provides
a network reference model.
These two figures show a client-initiated and a server-initiated packet with sample addresses.
Tunnel Redundancy
The ability to establish parallel, redundant tunnels improves media quality under adverse network packet loss
conditions (defined as packet loss within the 5% to 25% range). As the name implies, tunnel redundancy creates
secondary TSCF tunnels that replicate signaling and media transport between the TSC client and the TSC server.
Tunnel redundancy is one of the assigned services, along with ddt, server-keepalive, and sip, that can be enabled or
disabled on a TSCF interface; by default, tunnel redundancy is disabled. This service is enabled by including the
string redundancy in the comma-separated assigned-services list (refer to TSCF Interface Configuration for
procedural details).
With tunnel redundancy enabled, as packets traverse networks and encounter packet loss and drop, the TSC client and
TSC server choose the most available and timely packet from the duplicative tunnels. Within redundant tunnels,
packets are slightly offset (as shown in the following figure), so as a gateway or other intervening network elements
drop packets, the same packet that was dropped in one tunnel remains in another tunnel. When the packets reach their
destination in the core, or on the client, the media stream is reformed as if packet loss never happened.
Tunnel redundancy works in concert with RTP redundancy and packet loss concealment algorithms that are often
implemented by advanced variable bit rate codecs such as SPEEX, SILK or iSAC. Like RTP redundancy, defined in
RFC 6354, Forward Shifted RTP Redundancy Payload Support, tunnel redundancy does increase bandwidth usage by
replicating signaling and media but also maximizes the chances of packet delivery. In addition to packet loss, tunnel
redundancy can also mitigate the effects of jitter (variable packet delay), a common network impairment that can
result in significant speech quality degradation.
A TSC client can initiate tunnel redundancy at call establishment or, in response to current network conditions, at any
time within an established call session. Depending on the transport protocol (TCP or UDP) a TSC client can request
one of three available tunnel redundancy modes:
• TLS/TCP Load Balancing
• TLS Fan-Out
• DTLS/UDP Redundancy
This illustration provides a sample message flow for TLS/TCP load balancing negotiation.
Denial of Service
Denial of Service (DoS) protection is a licensed capability that adds preliminary access control and bandwidth control
for tunneled traffic.
Because tunneled traffic is confined to a small number of well-defined ETC-based ports, traffic processing can be
streamlined. Incoming traffic is directed to one of two pipes, each supported by dedicated queues, for transmission
toward the network core. A larger pipe provides maximal bandwidth for trusted tunnel endpoints, while a smaller pipe
provides minimal bandwidth for untrusted tunnel endpoints.
Tunnels can be promoted to the trusted level, or demoted to the untrusted level.
Initially all incoming traffic is treated as untrusted and directed to the untrusted pipe. When the TLS handshake is
successfully completed (meaning that the two peers have mutually authenticated) the tunnel transitions to the trusted
state. The tunnel remains in the trusted state until the expiration of the tunnel persistence timer, as described in TSCF
Global Configuration.
Server-Initiated Keepalive
For some TSC client devices, such as IPhones or iPads, operating system constraints can prevent the transmission of
timely keepalive messages required to refresh an existing TSCF tunnel connection or to maintain current NAT
bindings. To address this problem the TSC server can be configured to issue periodic server-initiated keepalive (SIK)
messages to clients who require such service.
SIK is one of the assigned services, along with ddt, redundancy, and sip, that can be enabled or disabled on a TSCF
interface; by default, SIK is disabled. SIK is enabled by including the string server-keepalive in the comma-separated
assigned-services list (refer to TSCF Interface Configuration for procedural details).
SIK services are provided only in response to a TSC client request. The client requests SIK services during the
configuration process. Upon receiving such a request, the TSC server checks the status of SIK on the interface on
which the service request was received. If SIK is enabled, the request is accepted; if SIK is disabled (the default
state), the request is denied.
The show tscf statistics, show tscf tunnel all, and show tscf tunnel detailed ACLI commands all provide various
counts of HA tunnel restoration operations.
request, and awaits the response to the outstanding request; if the request does not match a list entry, TSCF sends a
new OCSP request to a responder.
changes are required or encouraged at the TSCF global configuration level. If local network conditions require
modification, adjust the keepalive-timer, keepalive-timer-datagram, and tunnel-persistence-time parameters as
described below.
TSCF global configuration also enables and manages high-availability (HA) topologies — topologies in which a pair
of SBCs operate in tandem, one in the active and the other in the backup role to provide reliable redundant operational
availability. By default, HA is disabled. If your SBC operates in standalone mode (not part of an HA pair), you can
safely ignore all HA parameters and simply retain default values. If operating as part of an HA pair, use the red-port
parameter to enable HA as described in the following procedure. After enabling HA, Oracle Communications
recommends the retention of default values for other HA parameters (red-max-trans, red-sync-start-time, and red-
sync-comp-time) unless unusual local conditions require otherwise. Prior to modifying HA parameters, you should
refer to the ACLI Configuration Guide for more detailed HA information.
Use the following procedure to perform TSCF global configuration.
1. From superuser mode, use the following command sequence to access tscf-config configuration mode.
ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# tscf
ORACLE(tscf)# tscf-config
ORACLE(tscf-config)#
ORACLE(tscf-config)#
2. Use the keepalive-timer, keepalive-timer-datagram, and tunnel-persistence-time parameters to specify
handling of idle tunnels.
The timing of SIK transmissions is defined by the TSCF global parameters, keepalive-timer-datagram and
keepalive-timer. keepalive-timer-datagram is used for datagram-based (UDP) tunnels, while keepalive-timer is
used for stream-based (TCP) tunnels. In the absence of a user-supplied value for keepalive-timer-datagram,
keepalive-timer provides a default timer value for all tunnels regardless of the underlying transport protocol.
With SIK enabled, the server sends a keepalive message when no data is received from the client within the
keepalive interval. The keepalive is sent approximately 15 seconds before timer expiration to ensure that it reaches
the client before the client closes the tunnel for not receiving a keepalive message. For a datagram-based tunnel
the TSC server waits 5 seconds for a keepalive response or other data from the client. If no response is received,
the server sends another keepalive message. This sequence is repeated until the server receives a keepalive
response or other tunnel data, or a total of 3 keepalive messages has been sent, whichever occurs first. If no
keepalive response or other data is received from a client (either connection-based or datagram-based) within 15
seconds from the time the first keepalive message is sent, the server will tear down the tunnel, while saving the
tunnel configuration if the if tunnel-persistence-timer registers a non-zero value.
keepalive-timer specifies the maximum idle time (defined as no transmission activity within the tunnel) before
the TSC server transitions a stream-based (TCP) tunnel from the active to the persistent state. Supported values
are 0 and integers within the range 30 - 550 (seconds), with a default value of 300. The special value 0 specifies
that a keepalive mechanism is not employed. The integer values 30 through 550 specify the maximum size of the
tolerated idle period for stream-based tunnels.
When keepalive-timer-datagram is set to its default value (0), keepalive-timer provides the default timer value
for all tunnels, without regard to the transport protocol (TCP or UDP).
When keepalive-timer is set to a non-zero value, the TSC client must initiate a keepalive message exchange
before an idle period exceeds the assigned non-zero value. Failure of the client to transmit a keepalive prior to the
timer expiration results in the server placing the tunnel in the persistent state.
The complete keepalive message exchange consists of a client-generated Keep_Alive_Request and a server-
generated Keep_Alive_Response—essentially empty control messages consisting only of address fields and a
common message header.
The periodic exchange of keepalive messages not only verifies the presence of the remote tunnel peer, but also
facilitates the maintenance of NAT bindings through strict firewalls.
keepalive-timer-datagram specifies the maximum idle time (defined as no transmission activity within the
tunnel) before the TSC server transitions a datagram-based (UDP) tunnel from the active to the persistent state.
Supported values are 0 and integers within the range 30 - 550 (seconds), with a default value of 0. The special
value 0 specifies that a keepalive mechanism is not employed. The integer values 30 through 550 specify the
maximum size of the tolerated idle period for datagram-based tunnels.
tunnel-persistence-time specifies the additional idle time tolerated before the TSC server transitions an idle
tunnel from the persistent to the closed state and tears down the tunnel.
Allowed values are 0 and integers within the range 10 - 600 (seconds), with a default value of 330.
The value 0 specifies that the TSC server tears down the tunnel immediately upon expiration of the keep-alive
timer. The integer values 10 through 600 specify the idle period, between transition from the persistent to the
closed state.
During this interval, TSC clients, currently in the persistent state, can initiate a keepalive message exchange which
serves to reset the keepalive timer and return the client to the active state. During this same interval, recently
disconnected clients, who are still in the persistent state, can re-connect and request their previous tunnel
configuration.
For efficient and predictable operation, ensure that the value assigned to tunnel-persistence-time exceeds the
value assigned to keepalive-timer.
ORACLE(tscf-config)# keepalive-timer 30
ORACLE(tscf-config)# tunnel-persistence-time 40
ORACLE(tscf-config)#
3. Use the element-id parameter to assign a unique identifier to this TSC server.
Allowed values are 0 (the default) or an integer within the range 1 - 1023.
element-id can be safely ignored within network topologies that contain a single TSC server. However, in
topologies that contain multiple TSC servers, each server must be assigned a unique network-wide identifier,
provided by this parameter.
The assignment of a unique TSC server guarantees unique tunnel identifiers regardless of the number of TSC
servers within the network.
ORACLE(tscf-config)# element-id 10
ORACLE(tscf-config)#
4. In HA topologies use the red-port, red-max-trans, red-sync-start-time, and red-sync-comp-time parameters to
configure reliable redundant operations.
Use the red-port parameter to specify the UDP port number that supports TSCF synchronization message
exchanges.
The default value (0) disables redundant HA configurations. Use a port value of 2004 to enable HA operations.
Use the red-max-transparameter to specify the maximum number of retained TSCF synchronization messages.
Allowed values are integers within the range 0 through 999999999 (messages) with a default of 10000.
Use the red-sync-start-time parameter to set the timer value (in milliseconds) for transition from the standby to
the active role — that is the maximum period of time that the standby SBC waits for a heartbeat signal from the
active SBC before assuming the active role.
Allowed values are integers within the range 0 through 999999999 (milliseconds) with a default of 5000.
Use the red-sync-comp-time attribute to specify the interval between synchronization attempts after the
completion of a TSCF redundancy check.
Allowed values are integers within the range 0 through 999999999 (milliseconds) with a default of 1000.
ORACLE(tscf-config)# red-port 2004
ORACLE(tscf-config)# red-trans 15000
ORACLE(tscf-config)# red-sync-start-time 2500
ORACLE(tscf-config)# red-sync-comp-time 750
ORACLE(tscf-config)#
5. Use done, exit, and verify-config to complete TSCF global configuration.
6. Optionally, for all packets that meet the matching criteria specified by the ip-address, port, and transport-type
parameters, the tunneled packets will be forwarded to the configured remote-ip-address. The destination IP
address of the detunneled packet will be changed to this value.
When the packets are coming from non-tunneled side to tunneled side, the source IP address must match the
remote-ip-address. The source IP address will be changed back to the original destination IP address within the
tunneled packet
7. Use done, exit, and verify-config to complete configuration of this tscf-protocol-policy.
8. Repeat Steps 1 through 7 to configure additional tscf-protocol-policies if necessary.
For instructions on how to assign a TSCF protocol policy to a TSCF address pool, see the section TSCF Address
Pool Configuration in this document. The parameter is called protocol-policy,and appears in Step 1 and Step 9.
ORACLE(tscf-address-pool)#
2. Use the name parameter to provide a unique identifier for this tscf-address-pool.
ORACLE(tscf-address-pool)# name tscf-lap-1
ORACLE(tscf-address-pool)#
3. Retain the default value (an empty string) for the dns-realm-id parameter.
4. Use the address-range parameter to access address-range sub-configuration mode. While in this mode, you
compile an IP address list, and assign contiguous ranges of IP addresses to the list.
ORACLE(tscf-address-pool)# address-range
ORACLE(tscf-address-range)# ?
network-address base network address for this range
subnet-mask subnet mask for address range
batch enter all arguments on one line
select select a local address pool address range to edit
ORACLE(tscf-address-range)#
5. Use the network-address and subnet-mask ACLI parameters to specify a contiguous range of IP addresses
assigned to this tscf-address-pool.
network-address can take any valid IP address value. subnet-mask values should take into consideration the
projected number of tunnels to be supported by TSCF ports. To ensure that IPv4 address lists do not exceed the
maximum supported value (262,144), mask values must begin with the initial 14 bits set to 1. The following table
lists supported subnet-mask values along with the size of the resulting address pool.
Supported subnet-mask Values Address Pool Size
255.252.0.0 262,144
255.254.0.0 131,072
255.255.0.0 65,536
255.255.128.0 32,768
255.255.192.0 16,384
255.255.224.0 8,192
255.255.240.0 4,096
255.255.248.0 2,048
255.255.252.0 1,024
255.255.254.0 512
255.255.255.0 256
255.255.255.128 128
255.255.255.192 64
255.255.255.224 32
255.255.255.240 16
255.255.255.248 8
255.255.255.252 4
255.255.255.254 2
255.255.255.255 1
This command example allocates the maximum allowed address range to current the IPv4 address list.
ORACLE(tscf-address-pool)# network-address 10.244.0.0
ORACLE(tscf-address-pool)# subnet-mask 255.252.0.0
ORACLE(tscf-address-pool)#
This command example allocates 4096 IP addresses to the IPv4 address list.
ORACLE(tscf-address-pool)# network-address 10.244.0.0
ORACLE(tscf-address-pool)# subnet-mask 255.255.240.0
ORACLE(tscf-address-pool)#
6. Use done and exit to add the address range to the IPv4 address list, and to return to tscf-address-pool
configuration mode.
7. If necessary, repeat Steps 5 and 6 to add additional contiguous address ranges to the IPv4 address list.
This command example allocates a second range of 16,384 IPv4 addresses, to the IPv4 address list.
ORACLE(tscf-address-pool)# network-address 172.16.240.0
ORACLE(tscf-address-pool)# subnet-mask 255.255.192.0
ORACLE(tscf-address-pool)#
8. Use the data-flow parameter to assign a specific tscf-data-flow to this tscf-address-pool.
Refer to TSCF Data Flow Configuration for configuration details.
ORACLE(tscf-address-pool)# data-flow tscf-df-1
ORACLE(tscf-address-pool)#
9. Use the protocol-policy parameter to assign specific protocol traffic to the pool. Use the name of the policy that
was assigned to it when it was created. If assigning multiple policies, use a comma separated list.
ORACLE(tscf-data-flow)#
2. Use the name parameter to provide a unique identifier for this tscf-data-flow instance.
ORACLE(tscf-data-flow)# name tscf-dt-01
ORACLE(tscf-data-flow)#
3. Use the realm-id parameter to identify the egress realm.
ORACLE(tscf-data-flow)# realm-id core-1
ORACLE(tscf-data-flow)#
4. Use the group-size parameter to specify the size and number of address blocks supported by this data-flow
instance.
The size of the associated tscf-address-pool (defined as the number or IPv4 addresses contained in the pool), is
divided by the group-size value to segment the address pool into smaller address blocks. After determining the
start address for each block, the SBC establishes two static flows for each of the address blocks — a downstream
flow, in the access direction, and an upstream flow generally toward a core application server gateway/router that
provides forwarding service for pass-thru data-flow.
As a result of the static-flow establishment, each address block consumes 4 NAT entries, 2 for the downstream
flow and 2 for the upstream flow. Because the current software release imposes a maximum restriction of 4096
NAT entries per data-flow instance, dividing 4096 by 4 provides the largest number of supported address blocks,
1024.
Use the following table to associate supported group-size values with address pool size.
For example, for IPv4 addressing:
The largest supported address pool (262,144 addresses) requires a group size of 256 addresses, which produces the
maximum 1,024 address blocks with each block containing 256 addresses.
An address pool containing 131,072 addresses can be segmented as 512 address blocks, with each block
containing 256 addresses, or as 256 blocks, with each block containing the maximum 1,024 addresses.
An address pool containing 1,024 addresses can be segmented as follows:
1 block containing 1,024 addresses
2 blocks containing 512 addresses
4 blocks containing 256 addresses
8 blocks containing 128 addresses
16 blocks containing 64 addresses
32 blocks containing 32 addresses
64 blocks containing 16 addresses
128 blocks containing 8 addresses
256 blocks containing 4 addresses
Address Pool Size Supported group-size Values
262,144 256
131,072 128, 256
65,536 64, 128, 256
32,768 32, 64, 128, 256
16,384 16, 32, 64, 128, 256
8,192 8, 16, 32, 64, 128, 256
4,096 4, 8, 16, 32, 64, 128, 256
2,048 2, 4, 8, 16, 32, 64, 128, 256
1,024 1, 2, 4, 8, 16, 32, 64, 128, 256
512 1, 2, 4, 8, 16, 32, 64, 128, 256
256 1, 2, 4, 8, 16, 32, 64, 128, 256
128 1, 2, 4, 8, 16, 32, 64, 128
64 1, 2, 4, 8, 16, 32, 64
32 1, 2, 4, 8, 16, 32
16 1, 2, 4, 8, 16
8 1, 2, 4, 8
4 1, 2, 4
2 1, 2
1 1
ORACLE(tscf-data-flow)# group-size 128
ORACLE(tscf-data-flow)#
5. Use the upstream-rate parameter to specify the allocated upstream (core-side) bandwidth.
Allowable values are integers within the range 0 (the default) through 122070 (KB/s).
The 0 value allocates all available upstream bandwidth.
ORACLE(tscf-data-flow)# upstream-rate 100
ORACLE(tscf-data-flow)#
6. Use the downstream-rate parameter to specify the allocated downstream (access-side) bandwidth.
Allowable values are integers within the range 0 (the default) through 122070 (KB/s).
The 0 value allocates all available downstream bandwidth.
ORACLE(tscf-data-flow)# downstream-rate 100
ORACLE(tscf-data-flow)#
7. Use done, exit, and verify-config to complete configuration of this tscf-data-flow instance.
verify-config confirms that the total number of IPv4 addresses assigned to the data-flow instance does not exceed
262,144 and that the total number of NAT entries consumed by the data-flow instance does not exceed 4,096. In
the event of discrepancies, verify-config issues an error message recording the actual number of IPv4 addresses
and/or the number of NAT entries.
ORACLE(tls-profile)#
2. Use the name parameter to provide a unique identifier for this tls-profile.
ORACLE(tls-profile)# name tscfTls01
ORACLE(tls-profile)#
3. Use the required end-entity-certificate parameter to supply the unique name of a certificate-record configuration
element referencing the identification credential (specifically, an X509.v3 certificate) offered by the TSC server in
support of its asserted identity.
ORACLE(tls-profile)# end-entity-certificate tscfServerCert01
ORACLE(tls-profile)#
4. Use the required trusted-ca-certificates parameter to compile a list or one or more certificate-record
configuration elements referencing trusted Certification Authority (CA) certificates used to authenticate a client
application.
Provide a comma separated list of existing CA certificate-record configuration elements.
ORACLE(tls-profile)# trusted-ca-certificates verisignClass3-
a,verisignClass3-b,baltimore,thawtePremium
ORACLE(tls-profile)#
5. Retain the default value, all, for the cipher-list parameter.
6. Use the verify-depth parameter to specify the maximum number of chained certificates that will be processed
while authenticating the client application.
Provide an integer within the range 1 through 10 (the default).
The TSC server supports the processing of certificate chains when X.509v3 certificate-based authentication is
used during tunnel establishment. The following process validates a received TLS certificate chain.
a) Check the validity dates (Not Before and Not After fields) of the end certificate. If either date is invalid,
authentication fails; otherwise, continue chain validation
b) Check the maximum length of the certificate chain (specified by verify-depth). If the current chain exceeds this
value, authentication fails; otherwise, continue chain validation.
c) Verify that the Issuer field of the current certificate is identical to the Subject field of the next certificate in the
chain. If values are not identical, authentication fails; otherwise, continue chain validation.
d) Check the validity dates (Not Before and Not After fields) of the next certificate. If either date is invalid,
authentication fails; otherwise, continue chain validation.
e) Check the X509v3 Extensions field to verify that the current certificate identifies a CA. If not so,
authentication fails; otherwise, continue chain validation.
f) Extract the Public Key from the current CA certificate. Use it to decode the Signature field of the prior
certificate in the chain. The decoded Signature field yields an MD5 hash value for the contents of that
certificate (minus the Signature field).
g) Compute the same MD5 hash. If the results are not identical, authentication fails; otherwise, continue chain
validation.
h) If the hashes are identical, determine if the CA identified by the current certificate is a trust anchor by referring
to the trusted-ca-certificates attribute of the associated TLS-profile configuration object. If the CA is trusted,
authentication succeeds. If not, return to Step 2.
ORACLE(tls-profile)# verify-depth 8
ORACLE(tls-profile)#
7. Use the mutual-authenticate parameter to enable or disable (the default) mutual authentication.
Protocol requirements mandate that the server present its certificate to the client application. Optionally, the server
can implement mutual authentication by requesting a certificate from the client application, and authenticating the
certificate offered by the client.
Upon receiving a server certificate request, the client application must respond with a certificate; failure to do so
results in authentication failure.
ORACLE(tls-profile)# mutual-authenticate disabled
ORACLE(tls-profile)#
8. Retain the default value, compatibility, for the tls-version parameter.
9. Retain default values for all other parameters.
10. Use done, exit, and verify-config to complete tls-profile configuration.
11. Repeat Steps 1 through 10 to configure additional tls-profiles as required.
Configure a certificate-status-profile
1. From superuser mode, use the following command sequence to access status-profile. cert-status-profile
configuration mode. While in this mode, you configure a certificate-status-profile, a container for the
information required to access a single, specific OCSP responder.
ACMEPACKET# configure terminal
ACMEPACKET(configure)# security
2. Use the select command to identify a specific tls-profile that will support OCSP requests and responses.
3. Set the mutual-authenticate parameter to enabled.
4. Use the cert-status-check parameter to enable certificate status checking on this tls-profile.
Set this parameter to enabled.
5. Use the cert-status-profile-list parameter to assign an OCSP responder or responders to this TLS profile.
For example, this ACLI sequence assigns a single OCSP responder.
ACMEPACKET(tls-profile)#cert-status-profile-list "OCSP_Symantic OCSP_Thawte
OCSP_Entrust"
ACMEPACKET(tls-profile)#
Each assigned certificate-status-profile contains the data needed to access a single OCSP responder. Responders
are accessed in list order, from first to last. In the above example, the TSC server first contacts the Symantic
OCSP responder. If the responder cannot be contacted within the limits specified by the retry-count parameter of
the certificate-status-profile, the responder is quarantined for the time specified by the dead-time parameter, and
the TSC server moves to the next list entry.
6. Use done, exit, and verify-config to complete this configuration.
7. If necessary, repeat this procedure to prepare other TLS profiles for OCSP-based certificate checking support.
certificate-status-profile configuration
A sample certificate-status-profile configuration follows:
ACMEPACKET# show running-config cert-status-profile
cert-status-profile
name
OCSP_Symantic
ip-address 192.0.2.100
hostname
port 8080
type OCSP
trans-proto HTTP
requestor-cert signOCSP
responder-cert SymanticPublic-1
trusted-cas
realm-id wancom0
retry-count 1
dead-time 60
last-modified-by admin@console
last-modified-date 2014-07-24 18:25:25
ORACLE(tscf-interface)#
2. Use the optional state parameter to select the TSCF interface operational state.
Supported values are enabled (the default) | disabled.
Retain the default value to place the TSCF interface in an active operational state. Use disabled to place the TSCF
interface in a non-operational state.
ORACLE(tscf-interface)# state enabled
ORACLE(tscf-interface)#
3. Use the required realm-id parameter to identify the realm that supports TSC client access to the SBC.
Enter the realm name.
ORACLE(tscf-interface)# realm-id tsmAccess
ORACLE(tscf-interface)#
4. Use the optional nagle-state parameter to select the operational mode of the Nagle algorithm on this TSCF
interface.
Retain the default value (enabled) to support Nagle algorithm operations on this interface; use the alternate value
(disabled) to disable algorithm operations.
ORACLE(tscf-interface)# nagle-state disabled
ORACLE(tscf-interface)#
5. Use the optional assigned-services parameter to enable one of more services supported by this TSCF interface.
Currently supported services are ddt (refer to Dynamic Datagram Tunneling), nagle (refer to The show tscf
statistics, show tscf tunnel all, and show tscf tunnel detailed ACLI commands all provide various counts of HA
tunnel restoration operations.), redundancy (refer to Tunnel Redundancy), server-keepalive (refer to Server-
Initiated Keepalive), and sip.
Retain the default value, sip, to enable tunneling of SIP traffic.
Use the keyword, ddt, to enable the establishment of a linked tunnel pair—a persistent TCP/TLS tunnel to carry
signalling data, and an on-demand UDP/DTLS tunnel for datagram traffic.
Use the keyword, nagle, to support the override of the TSCF-interface-specific Nagle algorithm state (enabled |
disabled) on an individual tunnel.
If nagle is specific as an assigned service, the ACLI verify-config command issues a warning if it fails to find an
existing TCP/TLS port.
Use the keyword, redundancy, to enable tunnel redundancy for improved call quality under adverse packet loss.
Use the keyword, server-keepalive, to enable the periodic generation of TSCF-initiated keepalive messages on an
idle tunnel — defined as no transmission activity within the tunnel.
To enable multiple services, for example SIP and tunnel redundancy, use sip,redundancy. The required comma (,)
serves as an argument delimiter.
ORACLE(tscf-interface)# assigned-services sip,redundancy
ORACLE(tscf-interface)#
To enable dynamic datagram tunneling, use sip,ddt.
ORACLE(tscf-interface)# assigned-services sip,ddt
ORACLE(tscf-interface)#
6. Use the optional max-tunnels parameter to specify the maximum number of concurrent tunnels supported by this
TSCF interface.
This parameter allows available tunnel capacity (specified by the installed TSCF license) to be allocated across
multiple realms. Allowable values are any integer from 0 (the default) to the maximum license capacity.
The special value, 0, indicates that the interface-specific limit is bounded only the licensed value.
ORACLE(tscf-interface)# max-tunnels 20000
ORACLE(tscf-interface)#
7. Use the required local-address-pools parameter to identify the local address pool that provides tunnel addresses to
TSC clients.
A specific address from the address pool will be transmitted to the TSC client as part of the tunnel creation
process. This address provides the inner source address for tunneled packets originated by the TSC client
application.
Refer to TSCF Address Pool Configuration for address pool details.
ORACLE(tscf-interface)# local-address-pools tscfPool172
ORACLE(tscf-interface)#
8. Use the tscf-port parameter to move to tscf-port configuration mode.
ORACLE(tscf-interface)# tscf-port
ORACLE(tscf-port)# ?
address IP Address
port port
transport-protocol transport protocol
tls-profile tls profile name
select select a tscf port to edit
no delete selected tscf port
show show tscf port information
done write tscf port information
exit return to previous menu
ORACLE(tscf-port)#
9. Use the required address and port parameters to specify the IP address and port number monitored for incoming
tunnel client messages.
This address and port number will be transmitted to the TSC client as part of the tunnel creation process. This
address provides the outer destination address for tunneled packets originated by the TSC client application.
The TSCF port IP address must match the address range of the realm designated by the realm-id parameter. As
previously stated, the physical interface must be provided by an ETC NIU.
Enter a currently configured IP address and a port number with the range 1025 through 65535, with a default
value of 5060.
ORACLE(tscf-port)# address 192.168.11.22
ORACLE(tscf-port)# port 443
ORACLE(tscf-port)#
10. Use the optional transport-protocol parameter to identify the tunnel transport protocol.
Supported values are TLS (the default, TCP/TLS) | DTLS (UDP/DTLS) | TCP | UDP.
Note: The unsecured TCP and UDP protocols are only used for debug purposes, and are not intended for
operational environments.
ORACLE(tscf-port)# transport-protocol TLS
ORACLE(tscf-port)#
11. If the transport-protocol parameter is either TLS or DTLS, use the required tls-profile parameter to identify the
TLS profile that specifies the cryptographic resources available to support TLS or DTLS operations.
If the specified tunnel transport protocol is either TCP or UDP (non-operational environments only), this
parameter can be safely ignored.
Refer to TLS Profile Configuration for details.
ORACLE(tscf-port)# tls-profile tscfTLS01
ORACLE(tscf-port)#
12. Use done and exit to return to tscf-interface configuration mode.
13. If required, repeat Steps 7 through 11 to configure additional TSCF ports.
14. Use done, exit, and verify-config to complete tscf-interface configuration.
When validating the tscf-interface configuration verify-config confirms the following:
• the presence of an ETC NIU equipped with a minimum of 8GB of installed DRAM, and issues an ERROR:
MINOR ALARM message if a compliant NIU is absent
• the realm specified by the realm-id parameter actually exists, and issues an error message in the case of a non-
existent realm
• the TSCF port address matches the address specified by the realm-id parameter
• the presence of an associated SIP Interface, and issues an error message in the case of a non-existent realm
• the TSCF address pool specified by the local-address-pool parameter actually exists, and issues an error
message in the case of a non-existent address pool
• the TSCF address pool is not mis-configured, and issues an error message if it is
• the presence of one or more configured tscf-ports, and issues a warning message in the event of a missing port
• if assigned-services is ddt,sip, the configuration of matching (same address and port values) stream-based and
datagram-based tunnels — issues an error message in the case of a missing tunnel
• if transport-protocol is TLS or DTLS, the assignment of a TLS profile to the port — issues an error message in
the case of a no assignment or the assignment of a non-existent profile
verify-config confirms that TSCF and SIP interfaces have not been configured on the same network interface. In
the event of such a conflict, verify-config issues an ERROR message identifying the TSCF interface, the SIP
interface, and the network interface by name. Additionally, verify-config places the TSCF interface in an inactive
state, where it remains until the configuration has been repaired.
15. Repeat Steps 1 through 14 to configure additional tscf-interfaces as required.
22:08:16-133
TSCF Statistics ----- Lifetime ------
Recent Total PerMax
Tunnel Adds 0 0 0
Tunnel Rejects 0 0 0
Tunnel Deletes 0 0 0
Tunnel Errors 0 0 0
ORACLE#
The show tscf statistics command displays verbose TSCF global data.
ORACLE# show tscf statistics
22:08:02-119
Tunnel Capacity=200000
-- Period -- ----- Lifetime ------
Active High Total Total PerMax High
Established Tunnels 0 0 0 0 0 0
22:08:02-119
TSCF Statistics ------ Lifetime -------
Recent Total PerMax
Tunnel Adds 0 0 0
Tunnel Rejects 0 0 0
Tunnel De1etes 0 0 0
Tunnel Errors 0 0 0
=======================================================================
# |Addr Pool Name |Total |In Use |Free |Invalid |
=======================================================================
1 |pool1 |65279 |1500 |63779 |0 |
=======================================================================
ORACLE#
The show tscf address-pool <addressPoolName> command displays data for a single specified address pool.
ORACLE# show tscf address-pool pool1
=======================================================================
# |Addr Pool Name |Total |In Use |Free |Invalid |
=======================================================================
1 |pool1 |65279 |1500 |63779 |0 |
=======================================================================
ORACLE#
Tunnel Statistics
The show tscf tunnel all command displays basic summary information for each tunnel.
ORACLE# show tscf tunnel all
==================================================================
# | Tunnel Id | Inner IP | Outer IP |St |
==================================================================
1| 0000000100000042| 10.10.0.66| 192.168.50.77| A |
2| 0000000100000043| 10.10.0.67| 192.168.50.77| A |
==================================================================
ORACLE#
The show tscf tunnel all detailed command displays verbose information for each tunnel.
ORACLE# show tscf tunnel all detailed
Prot = Protocol
Att = Attributes. [6 Attributes]
[R = Redundancy # = RedundacyFactor, P = Primary, D = DDT, S = Server
Initiated Keepalive/C= client Initiated Keepalive, T/F = Nagle On(T)/Off(F)
H = Created on Standby]
Creation time and date (mm/dd/yy)
T1 = Time (seconds) since last data packet received from TSC
T2 = Time (seconds) since last data packet sent on TSC
T3 = Time (seconds) since last control message received from TSC
T4 = Time (seconds) since last control message sent on TSC
T5 = Time (seconds) in current state (Active or Persistent)
St = State [S=Start No=NoSession I=Init Ne=Negotiating A=Active
P=Persistent R=Released]
RC = Reconnect count
======================================================================
# | Tunnel Id | Inner IP | Outer IP : Port |...
...
======================================================================
# | Tunnel Id | Inner IP | Outer IP : Port |...
======================================================================
1| 0000000100000042| 10.10.0.66| 192.168.50.77: 43354|...
======================================================================
ORACLE#
The show tscf tunnel peer-outer-ip <ipAddress> command displays summary information for a set of tunnels
emanating from the specified client interface address.
ORACLE# show tscf tunnel peer-outer-ip 192.168.50.77
...
======================================================================
# | Tunnel Id | Inner IP | Outer IP : Port |...
======================================================================
1| 0000000100000042| 10.10.0.66| 192.168.50.77: 43354|...
2| 0000000100000043| 10.10.0.67| 192.168.50.77: 54458|...
======================================================================
ORACLE#
The show tscf tunnel state <state> command displays basic tunnel data for all tunnels in the specified state.
<state> can take one of the following values: Established, Finished, Negotiating, NoSession, Released, Start,
Unassigned.
ORACLE# show tscf tunnel state Active
...
======================================================================
# | Tunnel Id | Inner IP | Outer IP : Port |...
======================================================================
1| 0000000100000042| 10.10.0.66| 192.168.50.77: 43354|...
2| 0000000100000043| 10.10.0.67| 192.168.50.77: 54458|...
======================================================================
ORACLE#
The show tscf tunnel tscf-interface <realmID> command displays basic tunnel data for all tunnels supported by a
TSCF port. The TSCF port is identified by the name of its supporting realm.
ORACLE# show tscf tunnel tscf-interface access
...
======================================================================
# | Tunnel Id | Inner IP | Outer IP : Port |...
======================================================================
1| 0000000100000042| 10.10.0.66| 192.168.50.77: 43354|...
2| 0000000100000043| 10.10.0.67| 192.168.50.77: 54458|...
======================================================================
ORACLE#
The show tscf tunnel tunnel-id <tunnelID> command displays basic tunnel data for a specific tunnel identified by
its tunnel ID.
A tunnel ID is assigned by the TSC server during the configuration exchange, and can be most easily obtained with
the show tscf tunnel all command.
ORACLE# show tscf tunnel tunnel-id 0000000100000042
...
======================================================================
# | Tunnel Id | Inner IP | Outer IP : Port |...
======================================================================
1| 0000000100000042| 10.10.0.66| 192.168.50.77: 43354|...
======================================================================
ORACLE#
Tunnel Deletion
ACLI CLI commands provide the ability to delete an individual tunnel, a group of tunnels, or all tunnels.
Use the clear-tunnel tscf all command to delete all tunnels.
ORACLE# clear-tunnel tscf all
WARNING: This will clear all tunnels and may cause service outage!!
Clear all TSCF tunnels ? [y/n]?: y
Command was successful. Deleted 1502 TSCF tunnels.
ORACLE#
Use the clear-tunnel tscf interface ... command to delete a group of tunnels.
This command deletes all tunnels on a specified interface
ORACLE# clear-tunnel tscf M1:1
WARNING: This will clear all tunnels and may cause service outage!!
Clear all TSCF tunnels ? [y/n]?: y
Command was successful. Deleted 753 TSCF tunnels.
ORACLE#
This command deletes all TLS tunnels on a specified TSCF port
ORACLE# clear-tunnel tscf M1:1 tls 192.168.11.22:5060
WARNING: This will clear all tunnels on this port and may cause
service outage!!
Clear all TSCF tunnels ? [y/n]?: y
Command was successful. Deleted 753 TSCF tunnels.
ORACLE#
This command deletes all DTLS tunnels on a specified TSCF port
ORACLE# clear-tunnel tscf M1:1 dtls 192.168.11.22:5060
WARNING: This will clear all tunnels on this port and may cause
service outage!!
Clear all TSCF tunnels ? [y/n]?: y
Command was successful. Deleted 226 TSCF tunnels.
ORACLE#
This command deletes all TCP tunnels on a specified TSCF port
ORACLE# clear-tunnel tscf M1:1 tcp 192.168.11.22:5060
WARNING: This will clear all tunnels on this port and may cause
service outage!!
Clear all TSCF tunnels ? [y/n]?: y
Command was successful. Deleted 10 TSCF tunnels.
ORACLE#
This command deletes all UDP tunnels on a specified TSCF port
media = message
protocol = TCP/MSRP (for an unencrypted connection)
format-list = *
port = the TCP port (7777 in the SDP example, although any valid port number can be specified)
monitored by the message originator for a response to the SDP offer
The required SDP attributes, accept-types and path, are also defined in RFC 4975.
accept-types contains a list of media types that the message originator is willing to receive. It may contain
zero or more registered media-types, or an * wildcard character in a space-delimited string.
path contains the MSRP URI of the message originator. An MSRP URI is constructed as shown below.
Alice->Bob (SIP):
INVITE sip:bob@example.com
SDP:
v=0
o=alice 2890844557 2890844559 IN IP4 alicepc.example.com
SIP/2.0 200 OK
SDP:
v=0
o=bob 2890844612 2890844616 IN IP4 bob.example.com
s=
c=IN IP4 bob.example.com
m=message 8888 TCP/MSRP *
a=accept-types:text/plain
a=path:msrp://bob.example.com:8888/9di4eae923wzd;tcp
3. Alice ACKs Bob’s answer, establishing a SIP session between the two.
Alice->Bob (SIP):
ACK sip:bob@example.com
4. Alice initiates an MSRP session with an MSRP SEND request to Bob.
All MSRP requests begin with the MSRP start line, which contains three elements.
protocol-id = MSRP
transaction-id = an ephemeral transaction identifier (d93kswow in the following MSRP example) used to
correlate MSRP requests and responses, and to frame the contents of the MSRP message
method = SEND (MSRP method that supports data transfer)
The MSRP start line is followed by the To-Path and From-Path headers, which contain destination and source
addresses — the MSRP URIs exchanged during the MSRP negotiation.
The Message-ID header contains a random string generated by the message originator. This ephemeral value
whose lifetime is measured from message start to message end, is used to correlate MSRP status reports with a
specific message, and to re-assemble MSRP message fragments (chunks in MSRP terminology).
The Byte-Range header contains the message length, in bytes, and the specific byte range carried by this message.
Contents of this header are generally of interest only if the message has been fragmented.
The Content-Type header describes the message type, and must conform to the results of the MSRP negotiation.
The actual message follows the Content-Type header.
Finally, the SEND request is closed with an end-line of seven hyphens, the transaction-id, and a
$ to indicate that this request contains the end of a complete message, or
+ to indicate that this request does not contain the message end
Alice->Bob (MSRP):
BYE sip:bob@example.com
7. Bob sends a 200 OK response to Alice.
Bob->Alice (SIP):
SIP/2.0 200 OK
The SIP session and the MSRP session are terminated.
protocol identifies the hashing method used to produce the certificate fingerprint, SHA-1 in the following sample
SDP
hash value a sequence of uppercase hexadecimal bytes separated by colons with the sequence length determined by
the hash function
Connection Negotiation
When making the offer MSRP session, a user agent client can follow RFC 4145, TCP-Based Media Transport in the
Session Description Protocol (SDP), and include an a=setup attribute in a MSRP media line, or it may assume the
default connection direction as specified in section 8.5 of RFC 4975, The Message Session Relay Protocol, which
specifies that the endpoint that sent the original offer is responsible for connecting to its remote peer. The B2BUA, in
contrast, always includes an a=setup attribute in its offer SDP, the attribute value set by the preferred-setup-
role ACLI command.
If the B2BUA receives an answer SDP that does not include an a=setup attribute, it assumes that the user agent server
does not support connection negotiation per RFC 4145. In that case, the B2BUA assumes the active role as specified
in RFC 4975, and makes an outgoing connection.
If the B2BUA receives an offer or answer SDP that does include an a=setup attribute, it follows the connection
negotiation as specified by RFC 4145. When the B2BUA receives an offer SDP with the attribute a=setup:actpass
attribute, it will set the a=setup attribute of the answer SDP to the value set by the preferred-setup-role
ACLI command.
With regard to the above figure, the upper Oracle Communications Session Border Controller’s TCP connection
between Endpoint 1 and the MSRS B2BUA is shared by 2 MSRP sessions. At bottom, each MSRP session uses a
separate TCP connection. When the B2BUA assumes the active role, it always initiate a separate connection to the
MSRP endpoint peers, endpoints 2 and 3 as shown above.
When the list of active MSRP sessions for a shared TCP connection becomes empty as a result of SIP session
terminations or disconnections of peer TCP connections, B2BUA disconnects the shared TCP connection. If the
shared connection is disconnected by the peer, the B2BUA disconnects all the separate TCP connections it initiated
for the MSRP sessions that use the shared connection.
Accepting Connections
When the B2BUA is in passive mode, it listens for incoming connection from the active party, monitoring the port
specified by the listen-port ACLI command.
Making Connections
When the B2BUA is in active mode, it makes the connection to the passive party, selecting a port allocated from the
steering-pool of the applicable realm.
Note that the MSRP-specific timers, the session inactivity timer and the
MSRP delayed-BYE timer, are roughly analogous to two existing TCP timers, the TCP subsequent guard timer and
the TCP flow time limit timer. The following sections summarize timer operations.
If the B2BUA role is in passive mode, and the listen-port ACLI command is non-zero, the B2BUA monitors that
specified port.
If the B2BUA role is in passive mode, and the listen-port ACLI command is zero, the B2BUA selects a port from the
steering pool of the applicable realm and monitors that chosen port.
If the B2BUA role is in active mode, the port is chosen from the steering pool of the applicable realm. Since B2BUA
is active, that port is used only to support the outgoing connection.
Certificate Fingerprint
If the value of the field require-fingerprint in the ingress and/or egress tcp-media-profile is enabled, and the
transport protocol is TCP/TLS/MSRP the B2BUA requires the offer and/or the answer SDPs, respectively, to have an
a=fingerprint attribute as specified in RFC 4572, Connection-Oriented Media Transport over the Transport Layer
Security (TLS) Protocol in the Session Description Protocol (SDP).
If the B2BUA receives an offer SDP without a=fingerprint attribute, it rejects the offer SDP. If the rejected SDP is in
an INVITE request, the B2BUA issues a 488 Not Acceptable Here response. If the rejected SDP is in a 200 OK
response, the B2BUA ACKs that 200 OK, sends a BYE to the server user agent, and a 503 Service Unavailable
response to the client user agent.
If the B2BUA receives an answer SDP without a a=fingerprint attribute, it terminates the related SIP session. If the
rejected SDP is in a 200 OK response, the B2BUA ACKs that 200 OK, sends a BYE to the server user agent, and a
503 Service Unavailable response to the client user agent. If the rejected SDP is in an ACK, the B2BUA simply sends
a BYE to both the server and client user agent.
If the value of the field require-fingerprint in the profile is disabled, the B2BUA accepts offer and answer
SDP that do not include an a=fingerprint attribute.
Because the B2BUA certificate is expected to be signed by a trusted Certification Authority, an a=fingerprint attribute
is not included in offer and answer SDPs sent by the B2BUA.
The B2BUA maintains a fingerprint mismatch counter for each MSRP session. This counter is incremented when the
B2BUA cannot match the certificate it receives during the TLS handshake with the fingerprint it receives in the SDP.
MSRP Configuration
MSRP configuration consists of the following steps.
1. Configure the msrp-config configuration object that governs MSRP global behavior.
2. Configure one or more tcp-media-profile configuration objects that define MSRP operations within a realm.
3. Assign a tcp-media-profile to a target realm.
4. If MSRP sessions are secured with TLS, create and assign tls-profile configuration objects to the tcp-media-profile
of the target realm.
5. Create and assign steering-pools configuration objects to target realms.
msrp-config Configuration
Use the following procedure to perform MSRP global configuration.
1. From superuser mode, use the following command sequence to access
msrp-config configuration mode. While in msrp-config mode, you configure global MSRP behavior.
ORACLE# configure terminal
ORACLE(configure)# media-manager
ORACLE(media-manager)# msrp-config
ORACLE(msrp-config)# ?
state state
uri-translation perform translation of MSRP URI
session-inactivity-timer timer value (seconds) for session inactivity
monitoring period
tcp-media-profile Configuration
Use the following procedure to construct a TCP Media Profile that defines MSRP operations within a realm.
1. From superuser mode, use the following command sequence to access tcp-media-profile configuration mode.
While in tcp-media-profile mode, you begin construction of a TCP Media Profile.
realm Configuration
Use the following procedure to assign a single, specific tcp-media-profile to a target realm.
1. From superuser mode, use the following command sequence to access
realm-config configuration mode. While in realm-config mode, you assign a
tcp-media-profile to a realm.
ORACLE# configure terminal
ORACLE(configure)# media-manager
ORACLE(media-manager)# realm-config
ORACLE(realm-config)#
2. Use the select command to identify the target realm.
3. Use the tcp-media-profile parameter to assign a specific, named
tcp-media-profile to the target realm.
ORACLE(realm-config)# tcp-media-profile tlsMutualAuth
ORACLE(realm-config)#
4. Use done, exit, and verify-config to complete tcp-media-profile assignment.
tls-profile Configuration
Use the following procedure to create a tls-profile configuration object, which specifies cryptographic resources
available in support of TLS operations.
Note: The option allow-self-signed-cert is only available for MSRP connections.
• prefixes
• ras-port
• q931-port
• auto-gk-discovery
• multicast
• gatekeeper
• h245-tunneling
• gk-identifier
• alternate-transport
• q931-max-calls
• filename
Host Route
IPSEC
IWF
Licensing
Local Policy
Local Response Map
Local Routing Config
Media Manager The Media Manager element is supported with the exception of the following
parameters:
• red-flow-port
• red-max-trans
• red-sync-start-time
• red-sync-comp-time
Media Policy
Media Profile
Network Interface
Net Management Control
Network Parameters The Network Parameters element is supported with the exception of the following
parameters:
• SCTP parameters
NTP Sync
Packet Trace Config
Q850 SIP Map
Realm Config
Redundancy Config The Redundancy Config element is supported with the exception of the following
parameters:
• state
• port
• cfg-port
• cfg-max-trans
• cfg-sync-start-time
• cfg-sync-comp-time
Session Agent
Session Group
Session Router
Session Constraints
Session Translation
SIP Config The SIP Config element is supported with the exception of the following
parameters:
• red-sip-port
• red-max-trans
• red-sync-start-time
• red-sync-stop-time
SIP Feature
SIP Interface collect>boot-state
SIP Manipulation
SIP NAT The SIP NAT element is supported with the exception of the following
parameters:
• ext-address
Introduction
This Appendix provides a sample and format of each type of exported file from the Web-based GUI. Sample
information in these files are provided as a reference for your convenience.
Exported file examples include:
• Session Summary exported file (text format)
• Session Details exported file (text format)
• Ladder Diagram exported file (HTML format)
Note: Oracle recommends you open an exported text file using an application that provides advanced text
formatting to make it easier to read.
Exporting Files
The Web-based GUI allows you to export Monitor and Trace information to a text file from the Sessions,
Registrations, Subscriptions and Notable Events Reports, as well as from a specific ladder diagram, or from a page
containing the results of a search. The data exports to a file that you can open and view as required.
You can export any of the following to a file:
From the Sessions, Registrations, Subscriptions, and Notable Events Reports:
• Export session details - Exports the SIP messages and media events associated with the selected
session, to a text file.
• Export summary - Exports all logged session summary records, to a text file. (Exports ALL call session
summary records or the records that matched a search criteria).
From the Ladder Diagram:
• Export diagram - Exports all of the information in the Ladder Diagram to an HTML file (Session Summary,
SIP Message Details, and QoS statistics).
• Export session details - Exports detailed information about the SIP messages and media events in the
Ladder Diagram associated with the selected session, to a text file.
The following example shows the export of a Ladder Diagram to a file called LadderDiagram.html.
Example
----------Session Summary----------
State: TERMINATED-200
Duration: 5
From URI: sipp <sip:sipp@172.16.34.16:5060>;tag=1
To URI: sut <sip:service@172.16.34.225:5060>;tag=13451
Ingress Src Address: 172.16.34.16
Igress Src Port: 5060
Igress Dest Address: 172.16.34.225
Igress Dest Port: 5060
Egress Source Address: 192.168.34.225
Egress Source Port: 5060
Egress Destination Address: 192.168.34.17
Egress Destination Port: 5060
Igress Realm: access
Egress Realm: backbone
Igress NetworkIf: access
Egress NetworkIf: backbone
----------Session Summary----------
Startup Time: 2011-09-20 12:58:05.340
State: TERMINATED-200
Example
Session Details:
----------------------------------------
Nov 3 08:50:56.852 On [2:0]172.16.34.225:5060 received from 172.16.34.16:5060
v=0
o=user1 53655765 2353687637 IN IP4 172.16.34.16
s=-
c=IN IP4 172.16.34.16
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
----------------------------------------
Nov 3 08:50:56.855 On [2:0]172.16.34.225:5060 sent to 172.16.34.16:5060
----MBCD Evt
Nov 3 08:50:56.862 On 127.0.0.1:2945 sent to 127.0.0.1:2944
mbcdEvent=FLOW ADD
FlowCollapsed=enabled
mbcdEvent=FLOW ADD
FlowCollapsed=enabled
FlowDirection=CALLED
FlowID=65542
MediaFormat=0
MediaReleased=disabled
MediaType=audio/PCMU/
OtherFlowID=0
TOSBits=0
InputSourcev4Addr=
InputSourcePort=0
InputDestv4Addr=192.168.34.225
InputDestPort=20004
OutputSourcev4Addr=172.16.34.225
OutputDestv4Addr=172.16.34.16
OutputDestPort=6000
InputRealm=backbone
OutputRealm=access
----------------------------------------
Nov 3 08:50:56.865 On [1:0]192.168.34.225:5060 sent to 192.168.34.17:5060
v=0
o=user1 53655765 2353687637 IN IP4 192.168.34.225
s=-
c=IN IP4 192.168.34.225
t=0 0
m=audio 20004 RTP/AVP 0
a=rtpmap:0 PCMU/8000
----------------------------------------
Nov 3 08:50:56.868 On [1:0]192.168.34.225:5060 received from
192.168.34.17:5060
----------------------------------------
Nov 3 08:50:56.872 On [2:0]172.16.34.225:5060 sent to 172.16.34.16:5060
----------------------------------------
Nov 3 08:50:56.872 On [1:0]192.168.34.225:5060 received from
192.168.34.17:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.34.225:5060;branch=z9hG4bK4od0io20183g8ssv32f1.1
From: sipp <sip:sipp@172.16.34.16:5060>;tag=1
To: sut <sip:service@172.16.34.225:5060>;tag=2578
Call-ID: 1-668@172.16.34.16
CSeq: 1 INVITE
Contact: <sip:192.168.34.17:5060;transport=UDP>
Content-Type: application/sdp
Content-Length: 137
v=0
o=user1 53655765 2353687637 IN IP4 192.168.34.17
s=-
c=IN IP4 192.168.34.17
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
----MBCD Evt
Nov 3 08:50:56.878 On 127.0.0.1:2945 sent to 127.0.0.1:2944
mbcdEvent=FLOW MODIFY
FlowCollapsed=enabled
FlowDirection=CALLING
FlowID=65541
MediaFormat=0
MediaReleased=disabled
MediaType=audio/PCMU/
OtherFlowID=0
TOSBits=0
InputSourcev4Addr=
InputSourcePort=0
InputDestv4Addr=172.16.34.225
InputDestPort=10004
OutputSourcev4Addr=192.168.34.225
OutputDestv4Addr=192.168.34.17
OutputDestPort=6000
InputRealm=access
OutputRealm=backbone
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.34.16:5060;branch=z9hG4bK-1-0
From: sipp <sip:sipp@172.16.34.16:5060>;tag=1
To: sut <sip:service@172.16.34.225:5060>;tag=2578
Call-ID: 1-668@172.16.34.16
CSeq: 1 INVITE
Contact: <sip:service@172.16.34.225:5060;transport=udp>
Content-Type: application/sdp
Content-Length: 138
v=0
o=user1 53655765 2353687637 IN IP4 172.16.34.225
s=-
c=IN IP4 172.16.34.225
t=0 0
m=audio 10004 RTP/AVP 0
a=rtpmap:0 PCMU/8000
----------------------------------------
Nov 3 08:50:56.883 On [2:0]172.16.34.225:5060 received from 172.16.34.16:5060
----------------------------------------
Nov 3 08:50:56.887 On [1:0]192.168.34.225:5060 sent to 192.168.34.17:5060
----------------------------------------
Nov 3 08:51:01.883 On [2:0]172.16.34.225:5060 received from 172.16.34.16:5060
BYE sip:service@172.16.34.225:5060 SIP/2.0
Via: SIP/2.0/UDP 172.16.34.16:5060;branch=z9hG4bK-1-7
From: sipp <sip:sipp@172.16.34.16:5060>;tag=1
To: sut <sip:service@172.16.34.225:5060>;tag=2578
Call-ID: 1-668@172.16.34.16
CSeq: 2 BYE
Contact: sip:sipp@172.16.34.16:5060
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
----------------------------------------
Nov 3 08:51:01.887 On [1:0]192.168.34.225:5060 sent to 192.168.34.17:5060
----------------------------------------
Nov 3 08:51:01.889 On [1:0]192.168.34.225:5060 received from
192.168.34.17:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.34.225:5060;branch=z9hG4bK5oq46d301gv0dus227f1.1
From: sipp <sip:sipp@172.16.34.16:5060>;tag=1
To: sut <sip:service@172.16.34.225:5060>;tag=2578
Call-ID: 1-668@172.16.34.16
CSeq: 2 BYE
Contact: <sip:192.168.34.17:5060;transport=UDP>
Content-Length: 0
----------------------------------------
Nov 3 08:51:01.892 On [2:0]172.16.34.225:5060 sent to 172.16.34.16:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.34.16:5060;branch=z9hG4bK-1-7
From: sipp <sip:sipp@172.16.34.16:5060>;tag=1
To: sut <sip:service@172.16.34.225:5060>;tag=2578
Call-ID: 1-668@172.16.34.16
CSeq: 2 BYE
Contact: <sip:service@172.16.34.225:5060;transport=udp>
Content-Length: 0
----MBCD Evt
Nov 3 08:51:01.891 On 127.0.0.1:2945 sent to 127.0.0.1:2944
mbcdEvent=FLOW DELETE
FlowCollapsed=enabled
FlowDirection=CALLING
FlowID=65541
MediaFormat=0
MediaReleased=disabled
MediaType=audio/PCMU/
OtherFlowID=0
TOSBits=0
InputSourcev4Addr=
InputSourcePort=0
InputDestv4Addr=172.16.34.225
InputDestPort=10004
OutputSourcev4Addr=192.168.34.225
OutputDestv4Addr=192.168.34.17
OutputDestPort=6000
InputRealm=access
OutputRealm=backbone
----MBCD Evt
mbcdEvent=FLOW DELETE
FlowCollapsed=enabled
FlowDirection=CALLED
FlowID=65542
MediaFormat=0
MediaReleased=disabled
----------Session Summary----------
Startup Time: 2012-01-25 10:28:30.394
State: TERMINATED-200
Duration: 5
From URI: sipp <sip:sipp@172.16.34.16:5060>;tag=1
To URI: sut <sip:service@172.16.34.225:5060>;tag=2578
Ingress Src Address: 172.16.34.16
Igress Src Port: 5060
Igress Dest Address: 172.16.34.225
Igress Dest Port: 5060
Egress Source Address: 192.168.34.225
Egress Source Port: 5060
Egress Destination Address: 192.168.34.17
Egress Destination Port: 5060
Igress Realm: access
Egress Realm: backbone
Igress NetworkIf: access
Egress NetworkIf: backbone
Example
Glossary
1364 | Glossary | Oracle® Communications Session Border Controller