H.323 Features
This section provides general descriptions of the H.323 features available on the Oracle® Enterprise Session Border Controller and instructs you in how to configure them. Not all of the features described in that chapter require configuration.
Fast Start Slow Start Translations
The Oracle® Enterprise Session Border Controller can translate between Fast Start H.323 endpoints and Slow Start H.323 endpoints. Using this feature, you can reduce delay in establishing media, improve performance, and reduce network congestion caused by a high number of messages being exchanged. Fast Start and Slow Start calls handle information about media for a session in different ways. In a Fast Start call, information about the media is contained in the Setup message. In a Slow Start call, that information is exchanged between endpoints after the session has been established.
When you Fast Start/Slow Start translation, the Oracle® Enterprise Session Border Controller can take a Slow Start call from an H.323 endpoint that does not support Fast Start and re-initiate that call as Fast Start. It also allows an H.323 endpoint that does not support Fast Start to receive a Slow Start call from a Fast Start source because the Oracle® Enterprise Session Border Controller performs all necessary translations.
For the ACLI, the following parameters apply:
fs-in-first-msg Fast Start must be sent in 1st response to Setup message call-start-fast Enable outgoing Fast Start call call-start-slow Enable outgoing Slow Start call media-profiles list of default media profiles used for outgoing call
Fast Start to Slow Start Translation
The Oracle® Enterprise Session Border Controller supports translations from H.323 Fast Start to Slow Start. Using this feature, an H.323 endpoint that only supports Slow Start can call from a Fast Start source when that call goes through the Oracle® Enterprise Session Border Controller.
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® Enterprise Session Border Controller performs Fast Start to Slow Start conversion. During the translation, the Oracle® Enterprise 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® Enterprise Session Border Controller negotiates the media capabilities.
Slow Start to Fast Start Translation
When you configure your Oracle® Enterprise Session Border Controller to support H.323 Slow Start to Fast Start translations, you enable an H.323 endpoint that only supports Slow Start to initiate and sustain communication with an H.323 Fast Start endpoint. The Oracle® Enterprise Session Border Controller resolves the Slow Start limitation of exchanging information about media (OLC messages) after the call is connected. The OLC message opens a logical channel, or a unidirectional or bi-directional path used to transmit media packets. Using the Oracle® Enterprise Session Border Controller, you can negotiate the construction of media flows differently, which is described in this section.
When you enable the Fast Start option for calls in the H.323 stack configuration, the Oracle® Enterprise Session Border Controller performs the translation of a Slow Start call into Fast Start. When it receives a Slow Start call, the Oracle® Enterprise Session Border Controller determines its destination and the H.323 stack it uses for the outgoing call.
It is a requirement of this kind of translation that you configure and use media profiles. Since a Slow Start call does not negotiate media until after the call is connected, there needs to be an assumption made about the media to set up a Slow Start to Fast Start call. Media profiles fill this role, and they are assumed to be part of a correct configuration.
The following describes possible scenarios for Slow Start to Fast Start translations.
- When a Slow Start call arrives at the
Oracle® Enterprise Session Border Controller and matches one of the session agents that has a media profiles list configured, the outgoing call is set up as a Fast Start call. The session agent’s media profiles are used for the logical channels. You must configure the media profiles to reference a codec the endpoint accepts.
If there are no media profiles configured for the session agent, then the Oracle® Enterprise Session Border Controller uses the media profiles list in the H.323 stack configuration to open the logical channels.
- If a Slow Start calls arrives at the
Oracle® Enterprise Session Border Controller and its destination does not match one of the session agents, the
Oracle® Enterprise Session Border Controller uses the media profiles list in the H.323 stack configuration for the outgoing call. If there is a list of media profiles, the outgoing call is set up as a Fast Start call with the media profiles list used to open the logical channels.
If there is no list of media profiles for the outgoing H.323 interface, the Oracle® Enterprise Session Border Controller does not perform Slow Start to Fast Start translation. The Slow Start call exits the Oracle® Enterprise Session Border Controller as it arrived—as a Slow Start call.
- If the egress H.323 interface has the Fast Start option disabled, then the outgoing call uses the Slow Start mode, and the Oracle® Enterprise Session Border Controller does not perform Slow Start to Fast Start translation. In this case, the Slow Start call also exits the Oracle® Enterprise Session Border Controller as it arrived—as a Slow Start call.
Slow Start Fast Start Prerequisites
To perform Fast Start/Slow Start translations, you need to have a standard two-interface configuration already in place.
If you are using the Slow Start to Fast Start translations, you must configure appropriate entries in the media profiles list which is part of the translation parameters. The Fast STart/Slow Start Translations section of the Oracle® Enterprise 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 does not match up with the defaults, your configuration takes precedence. If there are no configuration overlaps, then the Oracle® Enterprise Session Border Controller loads the configured and default profiles. The default media profiles are:
| Type | Payload | Encoding | Bandwidth |
|---|---|---|---|
| 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.
Media Profile Configuration
In the ACLI, you can set media profiles that are required for translating H.323 Slow Start to Fast Start. In the ACLI, you set the following:
name encoding name used in sdp rtpmap attribute media-type media type used in sdp m lines payload-type rtp payload type used in sdp m lines transport transport protocol used in sdp rtpmap attribute req-bandwidth amount of bandwidth in kilobits required frames-per-packet maximum number of frames per packet parameters list of <name=value> pairs separated by space average-rate-limit average rate limit of rtp flow
To configure a media profile:
Fast Start/Slow Start Configurations
When you configure an H.323 interface, you configure it for either Fast Start to Slow Start translation or for Slow Start to Fast Start translation. You cannot configure one H.323 interface for both translation modes.
In the ACLI, you will set the following:
fs-in-first-msg Fast Start must be sent in 1st response to Setup message call-start-fast Enable outgoing Fast Start call call-start-slow Enable outgoing Slow Start call media-profiles list of default media profiles used for outgoing call
To configure H.323 interfaces for Fast Start/Slow Start translations:
H.235 Encryption
Following the ITU-T H.235 encryption standard, the Oracle® Enterprise 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® Enterprise 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® Enterprise Session Border Controller
- H.245Teminal
CapabilitySet—The H.245 TerminalCapabilitySet messages to pass transparently
through the
Oracle® Enterprise Session Border Controller, including:
- Audio, video, and data capabilities
- The h235SecurityCapability capability
- H.245 OpenLogicalChannel and
OpenLogicalChannelAck—OLC messages with dataType h235Media to pass
transparently through the
Oracle® Enterprise Session Border Controller; to accomplish this, the
Oracle® Enterprise Session Border Controller uses the mediaType subfield instead of the dataType
field when the dataType is h235Media. The encryptionSync parameter and its
subfields found in OLC and OLCAck messages to pass transparently through the
Oracle® Enterprise Session Border Controller.
You do not need to follow special configuration steps to enable this functionality; it works automatically.
RFC 2833 DTMF Interworking
This section explains the Oracle® Enterprise Session Border Controller’s support of transporting Dual Tone Multi-Frequency (DTMF) in Real-Time Transport Protocol (RTP) packets (as described in RFC 2833) to H.245 User Input Indication (UII).
Multimedia devices and applications must exchange user-input DTMF information end-to-end over IP networks. The Oracle® Enterprise Session Border Controller provides the interworking capabilities required to interconnect networks that use different signaling protocols. Also, the Oracle® Enterprise Session Border Controller provides DTMF translation to communicate DTMF across network boundaries.
The Oracle® Enterprise Session Border Controller supports RFC 2833 to H.245 UII translation for H.323-to-H.323 calls, when one side is a version 4 H.323 device requiring RFC-2833 DTMF event packets, and the other side is a pre-version 4 H.323 device that only uses H.245 UII.
About RFC 2833
RFC 2833 specifies a way of encoding DTMF signaling in RTP streams. It does not encode the audio of the tone itself, instead a signal indicates the tone is being sent. RFC 2833 defines how to carry DTMF events in RTP packets. It defines a payload format for carrying DTMF digits used when a gateway detects DTMF on the incoming messages and sends the RTP payload instead of regular audio packets.
About H.245 UII
H.245 provides a capability exchange functionality to allow the negotiation of capabilities and to identify a set of features common to both endpoints. The media and data flows are organized in logical channels. H.245 provides logical channel signaling to allow logical channel open/close and parameter exchange operations. The H.245 signaling protocol is reliable, which ensures that the DTMF tones will be delivered.
H.245 User Input Indication (UII) plays a key role in all the services that require user interaction. For video messaging, typical uses of UII include selection of user preferences, message recording and retrieval, and typical mailbox management functions. H.245 UII provides two levels of UII, alphanumeric and signal.
About 2833 to H.245 UII Interworking
The Oracle® Enterprise Session Border Controller provides 2833 to H.245-UII interworking by checking 2833-enabled RTP streams for packets matching the payload type number for 2833. It then sends the captured packet to the host for processing and translation to H.245 UII messages. A H.245 UII message received by the Oracle® Enterprise Session Border Controller is translated to 2833 packets and inserted into the appropriate RTP stream.
Flow Control Mapping for Interworking Function (IWF) Video
H.245 is a protocol for the transmission of call management and control signals in networks using H.323 equipment. The H.245 specification is used in audio, video, and data transmissions, as well as in voice over IP (VoIP). H.245 messages are sent over special channels called H.245 control channels.
H.245 signaling is used to manage and control call setup and connection. Functions of H.245 include determining which endpoint is to be the master and which is to be the slave during the call, opening and closing of multiplexed data-transfer paths between the endpoints, establishing an upper limit to the data transfer speed on each logical channel, information exchanges between endpoints concerning the types of data each endpoint can send and receive, requests by the receiving endpoint for changes in the mode of the data sent by the transmitting endpoint, and requests by either endpoint to end the call.
In the H.245 standard, the FlowControlCommand message is used to specify the upper limit of bit rate of either a single logical channel or the whole multiplex. The following is an excerpt from the H.245 standard.
Command Message: Flow Control (from H.245 standard)
===================================================
FlowControlCommand ::= SEQUENCE
{
scope CHOICE
{
logicalChannelNumber LogicalChannelNumber,
resourceID INTEGER (0..65535),
wholeMultiplex NULL
},
restriction CHOICE
{
maximumBitRate INTEGER (0..16777215), -- units 100 bit/s
noRestriction NULL
},
...
}
===================================================
A terminal may send this command to restrict the bit rate that the far-end terminal sends. A receiving terminal must comply with this command.
In an H.323 environment, the Oracle® Enterprise Session Border Controller previously used the FlowControlCommand to map to SIP using either the Real-Time Control Protocol (RTCP) feedback function, or the SIP signaling path (for example, the INFO method).
The Oracle® Enterprise Session Border Controller now supports the SIP counter part of the H.245 FlowControlCommand using the SIP signaling path with the INFO method. The Oracle® Enterprise Session Border Controller sends the SIP INFO message with "change_bitrate" rate parameter that has the value 100* maxBitRate from the corresponding H.245 FlowControlCommnad message. For example, in the following messages, the incoming H.323 message with the H.245 FlowControlCommand, is converted into the outgoing SIP INFO message with the message body.
Incoming H.323 Message with H.245 FlowControlCommand:
H.245
PDU Type: command (2)
command: flowControlCommand (4)
flowControlCommand
scope: logicalChannelNumber (0)
logicalChannelNumber: 102
restriction: maximumBitRate (0)
maximumBitRate: 4480
Outgoing SIP INFO Message:
Message Body
eXtensible Markup Language
<?xml
version="1.0"
encoding="utf-8"
?>
<media_control>
<vc_primitive>
<to_encoder>
<change_bitrate>
4480000
</change_bitrate>
</to_encoder>
</vc_primitive>
</media_control>
About DTMF Transfer
DTMF transfer is the communication of DTMF across network boundaries. It is widely used in applications such as interactive voice response (IVR) and calling card applications.
The multiple ways to convey DTMF information for packet-based communications include:
- In-band audio: DTMF digit waveforms are encoded the same as voice packets. This method is unreliable for compressed codecs such as G.729 and G.723
- Out-of-band signaling events:
H.245 defines out-of-band signaling events (UII) for transmitting DTMF information. The H.245 signal or H.245 alphanumeric methods separate DTMF digits from the voice stream and send them through the H.245 signaling channel instead of through the RTP channel. The tones are transported in H.245 UII messages.
All H.323 version 2 compliant systems are required to support the H.245 alphanumeric method, while support of the H.245 signal method is optional.
- RTP named telephony events (NTE): uses NTE to relay DTMF tones, which provides a standardized means of transporting DTMF tones in RTP packets according to section 3 of RFC 2833.
Of the three RTP payload formats available, the Oracle® Enterprise Session Border Controller supports RTP NTE.
RFC 2833 defines the format of NTE RTP packets used to transport DTMF digits, hookflash, and other telephony events between two peer endpoints. With the NTE method, the endpoints perform per-call negotiation of the DTMF transfer method. They also negotiate to determine the payload type value for the NTE RTP packets.
The NTE payload takes the place of codec data in a standard RTP packet. The payload type number field of the RTP packet header identifies the contents as 2833 NTE. The payload type number is negotiated per call. The local device sends the payload type number to use for 2833 telephone event packets using a SDP or H.245 Terminal Capability Set (TCS), which tells the other side what payload type number to use when sending the named event packets to the local device. Most devices use payload type number 101 for 2833 packets, although no default is specified in the standard.
The 2833 packet’s RTP header also makes use of the timestamp field. Because events often last longer than the 2833 packets sending interval, the timestamp of the first 2833 packet an event represents the beginning reference time for subsequent 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.
See RFC 2833 and draft-ietf-avt-rfc2833bis-07.txt for more information.
Preferred and Transparent 2833
To support preferred (signaled) 2833 and transparent 2833, the Oracle® Enterprise Session Border Controller provides 2833 detection and generation (if necessary) when the endpoint signals support for 2833.
- Preferred: the Oracle® Enterprise Session Border Controller only generates and detects 2833 for endpoints if they negotiate support for 2833 through signaling
- Transparent: the Oracle® Enterprise Session Border Controller behaves as it has prior to this release, offering and answering based on end-to-end signaling and transparently relaying 2833
Preferred 2883 Support
If one side of the call, or a session agent, is configured for preferred 2833, the Oracle® Enterprise Session Border Controller only generates and detects 2833 for endpoints if they signal support for 2833. The Oracle® Enterprise Session Border Controller will offer 2833 in the TCS SDP, even if the originating caller did not.
- When the
Oracle® Enterprise Session Border Controller manages calls originating from a preferred source
going to a preferred target, it:
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® Enterprise 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® Enterprise Session Border Controller does not perform active translation because both ends support 2833.
Transparent 2833 Support
The default configuration of the Oracle® Enterprise Session Border Controller for H.323 is transparent 2833. The Oracle® Enterprise Session Border Controller passes on the offered capabilities to the next-hop signaling element. If the next-hop endpoint is for a transparent 2833 target, typical capability negotiation determines the DTMF method. The Oracle® Enterprise Session Border Controller transparently relays the DTMF as it has in previous releases.
With transparent 2833, the Oracle® Enterprise 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® Enterprise 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.
Basic RFC 2833 Negotiation Support
If H.323 or session agents on either side of the call are configured for preferred 2833 support, the Oracle® Enterprise Session Border Controller supports end-to-end signaled negotiation of DTMF on a call-by-call basis. If the calling party is not configured for preferred support but sends 2833, the Oracle® Enterprise Session Border Controller sends 2833 to the next-hop called party. If the calling party sends H.245 signals or alphanumeric UII, the Oracle® Enterprise Session Border Controller sends H.245 signals or alphanumeric UII to the next-hop called party (if it is an H.323 next-hop).
The Oracle® Enterprise Session Border Controller also supports hop-by-hop negotiation of DTMF capability on a call-by-call basis, if the signaling protocols or session agents on either side of the call are configured for preferred 2833 support.
H.323 to H.323 Negotiation
The Oracle® Enterprise Session Border Controller serves as the H.323 called gateway. It answers RFC 2833 audio telephony event capability in the version 4 H.323/H.245 TCS when it receives a call from an H.323 endpoint configured for preferred RFC 2833.
If the Oracle® Enterprise Session Border Controller is the answering device, configured for preferred support, and the calling device sends 2833, the Oracle® Enterprise 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® Enterprise 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® Enterprise Session Border Controller calls an H.323 endpoint configured for preferred RFC 2833 support. The Oracle® Enterprise 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® Enterprise 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® Enterprise 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.
Signal and Alpha Type Support
The Oracle® Enterprise Session Border Controller supports:
- H.245 signal and alpha type UII in the H.323/H.245 TCS as the H.323 calling gateway when the:
Oracle® Enterprise Session Border Controller calls an H.323 endpoint configured for transparent 2833 support
calling endpoint’s target is configured as preferred
If the originating preferred side also sends 2833, the Oracle® Enterprise Session Border Controller forwards it to the transparent side. The Oracle® Enterprise Session Border Controller sends signal and alpha UII support to the called party regardless of whether the calling party sends it, if the call originates from a preferred side to a transparent side.
- H.245 alphanumeric UII for DTMF for H.323 endpoints that do not signal 2833 or contain 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® Enterprise Session Border Controller translates incoming H.245 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® Enterprise Session Border Controller relays the H.245 UII messages.
- 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® Enterprise 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® Enterprise Session Border Controller relays the H.245 UII messages if both sides support it.
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
Translating H.245 UII to 2833 for H.323 Calls
A majority of H.323 endpoints are not version 4 H.323 compliant and do not support RFC 2833 for DTMF transfer. However, some networks include version 4 H.323 devices that require the DTMF events to be signaled in 2833 packets. Network-based version 4 H.323 gateways use RFC 2833 instead of H.245 UII. (Version 4 H.323 devices should support H.245 UII.)
The Oracle® Enterprise Session Border Controller translates 2833 to H.245 UII for H.323-to-H.323 calls when one side is a version 4 H.323 device requiring RFC-2833 DTMF event packets, and the other side is a pre-version 4 H.323 device which only uses H.245 UII.
The Oracle® Enterprise Session Border Controller can translate H.245 UII to RFC2833 and back, based on the admin configuration and H.245 TCS exchanges. This translation enables DTMF to work end-to-end.
H.323 Registration Proxy
The Oracle® Enterprise Session Border Controller provides a registration proxy feature that allows a gatekeeper to authenticate a registration before accepting it. This feature is key when two factors are present: authentication is required, and an RRQ from an endpoint includes a token and/or cryptographic token. If authentication for that endpoint is to work, the Oracle® Enterprise Session Border Controller must forward the registration requests received from the endpoint to the gatekeeper separately.When you do not use the H.323 registration proxy, the Oracle® Enterprise Session Border Controller combines all registrations received from H.323 endpoints into a single RRQ and sends it to the gatekeeper. Using the H.323 registration proxy, you can configure the Oracle® Enterprise Session Border Controller to use separate forwarding.
When registration requests are forwarded separately, each RRQ must have a unique CSA. This means that the Oracle® Enterprise Session Border Controller must perform a one-to-one translation of the CSA in the incoming RRQ to a distinct transport address. The translated address replaces the endpoint’s CSA in the outgoing RRQ. Then the Oracle® Enterprise Session Border Controller must listen for incoming calls that arrive at this translated transport address for the registered endpoint.
H.235 Authentication Transparency
When operating in this mode, H.235 authentication tokens (cryptotokens) in RAS messages proxied though the Oracle® Enterprise Session Border Controller are passed through transparently.
For applications where Oracle® Enterprise Session Border Controller is between H.323 gateways and a network hosted gatekeeper, the H.235 cryptotokens are passed through unmodified in RAS messages: RRQs, ARQs, and DRQs. This feature allows for secure gateway authentication.
Unique CSA Per Registered Gateway
When operating in this mode, each CSA is mapped to a registered gateway for call routing. The core gatekeeper does not support additive registrations, so a different CSA must be used for each unique registration that goes to the gatekeeper. The gatekeeper does not overwrite previously registered aliases. Also, since the gatekeeper initiates calls to an endpoint on the CSA specified in the RRQ, the Oracle® Enterprise Session Border Controller must listen on the assigned address for incoming calls to that client as long as the client is registered.
Virtual Call Signaling Address
You can configure the Oracle® Enterprise Session Border Controller with:
- A TCP port range for Q.931—Q.931 ports that are frontend ports handled by a real backend socket, and are therefore virtual
- ATCP port range for separate H.245 TCP connections—Actual sockets that the Oracle® Enterprise Session Border Controller handles separately
Virtual call signaling address is an H.323 call signaling address that is registered with a gatekeeper, but does not have a corresponding listening socket in the Oracle® Enterprise Session Border Controller. Using the virtual call signaling address means that numerous network transport addresses do not need to be allocated.
Virtual call signaling addresses work by attaching a range of TCP server ports to a single listening TCP socket. After a connection is accepted, the accepting socket created by the server socket operated normally, as though it were created by the server socket that listens on the same transport address as the destination of the arriving packet.
To use virtual call signaling addresses, you specify a Q.931 port range from which the Oracle® Enterprise 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® Enterprise 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® Enterprise Session Border Controller caches the registration and then forwards a modified copy of the RRQ. The Oracle® Enterprise 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.
Virtual RAS Address
The Oracle® Enterprise Session Border Controller also allocates a virtual RAS address for each endpoint registration. Before forwarding an RRQ from an endpoint, the Oracle® Enterprise Session Border Controller replaces the RAS address of the registering endpoint with the virtual RAS address on the gateway interface.
RAS Message Proxy
When the Oracle® Enterprise Session Border Controller’s registration proxy feature is configured, RAS messages to and from endpoints are forwarded, except for the following: GRQ, GCF, GRJ, IRQ, IRR, IACK, and INACK. If the system receives a valid GRQ on the RAS port of the gatekeeper stack that supports H.323 registration, it responds with a GCF message. Otherwise, it sends a GRJ message.
If the gateway interface receives IRR or IRQ messages, the Oracle® Enterprise Session Border Controller attempts to respond based on the information about the call, and does not forward the messages.
Other RAS messages are forwarded after some modifications:
- Translating the transport address
- Deleting fields that the Oracle® Enterprise Session Border Controller does not support
About Setting Port Ranges
When you configure the H.323 registration proxy feature, you set the Q.931 port range and the dynamic H.245 port range for H.245 connections. If you configure a Q.931 port range, you must also configure a dynamic H.245 port range.
These port ranges cannot overlap because of TCP ports must be unique. The dynamic H.245 port range is used to allocate a real TCP socket, but the Q.931 port range allocates a virtual call signaling address that does not have an associated listening TCP socket.
Note:
You should choose these sockets with future Oracle® Enterprise Session Border Controller features about security in mind because future development will support performing admission control based on these port ranges. You will be able to set up filtering rules to allow only inbound packets to configured port ranges.The following table shows how the Q.931 and dynamic H.245 port ranges work. If you set the start port of 1024 and the number of ports to 1024, you will have configured a port range that starts at 1024 and ends at 2047. So the final port in the range is the start port number added to the number of points, minus 1. Remember that you cannot overlap the Q.931 and dynamic H.245 port ranges. Notice that the higher the number of the start ports, the fewer ranges of ports you have remaining from which to choose.
| Number of Ports | Start Port | n |
|---|---|---|
| 1024 | 1024 * n | 1-63 |
| 2048 | 2048 * n | 1-31 |
| 4096 | 4096 * n | 1-15 |
| 8192 | 8192 * n | 1-7 |
| 16384 | 16384 * n | 1-3 |
| 32768 | 32768 * n | 1 |
H.323 Registration Proxy Configuration
In the ACLI, the parameters that apply to this feature are:
q931-start-port Starting port number for port range used for Q.931 call signalling q931-number-ports Number of ports in port range used for Q.931 call signalling dynamic-start-port Starting port number for port range used for dynamic TCP connections dynamic-number-ports Number of ports in port range used for dynamic TCP connections
To configure the H.323 registration proxy:
H.323 Registration Caching
The Oracle® Enterprise Session Border Controller can cache and proxy an H.225 RRQ between an H.323 endpoint and a gatekeeper. Registration caching has two benefits:
- It allows the aggregation of RRQs sent to a gatekeeper stack and proxies those requests through the gateway stack. If the external gatekeeper associated with the outbound (gateway) interface does not support additive registration, then the Oracle® Enterprise Session Border Controller consolidates the requests by placing them all in the same packet. Otherwise, additive registration is used on the outbound (gateway) interface.
- 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® Enterprise 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.
Caveats for Registration Caching
This feature has the following caveats:
- If a gateway stack receives a URQ message from the gatekeeper, it confirms the request with an UCF message. It flushes all registration caching for that stack. However, the Oracle® Enterprise Session Border Controller does not send URQs to the registered endpoints.
- The Oracle® Enterprise Session Border Controller must be rebooted so that the gateway interface can rediscover the gatekeeper under the following circumstances:
Automatic gateway discovery is turned on for the gateway interface by setting the automatic gateway discovery parameter to enabled.
Configuration Requirements
For the Oracle® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise Session Border Controller supports GRQ on a multicast address.
H.323 Registration Caching Configuration
In the ACLI, the parameters that apply to this feature are:
isgateway Enable the stack to run as a gateway registration-ttl Number of seconds before the registration becomes invalid terminal-alias List of aliases for terminal gatekeeper Gatekeeper's address and port gk-identifier Gatekeeper's identifier
To configure the gateway interface parameters for registration caching:
Configuring the Gatekeeper Interface for Registration Caching
In the ACLI, the parameters that apply to this feature are:
isgateway Enable the stack to run as a gateway gatekeeper Gatekeeper's address and port gk-identifier Gatekeeper's identifier registration-ttl Number of seconds before the registration becomes invalid
To configure the gatekeeper interface parameters for registration caching:
ACLI Registration Caching Configuration Example
In the following example, the H.323 gatekeeper interface (h323-stack) is private and the gateway interface (h323-stack) is public.
h323-config state enabled log-level DEBUG response-tmo 4 connect-tmo 32 h323-stack name private state disabled realm-id private assoc-stack public local-ip 192.168.200.99 max-calls 200 max-channels 4 registration-ttl 120 terminal-alias prefixes ras-port 1719 auto-gk-discovery disabled multicast 0.0.0.0:0 gatekeeper 0.0.0.0:0 gk-identifier q931-port 1720 alternate-transport q931-max-calls 200 h245-tunneling disabled fs-in-first-msg disabled call-start-fast disabled call-start-slow disabled media-profiles process-registration enabled anonymous-connection disabled proxy-mode filename h323-stack name public state enabled isgateway enabled realm-id public assoc-stack private local-ip 192.168.1.99 max-calls 200 max-channels 2 registration-ttl 120 terminal-alias prefixes ras-port 1719 auto-gk-discovery disabled multicast 0.0.0.0:0 gatekeeper 192.168.1.50:1719 gk-identifier gk-public.acme.com q931-port 1720 alternate-transport q931-max-calls 200 h245-tunneling disabled fs-in-first-msg disabled call-start-fast disabled call-start-slow disabled media-profiles process-registration disabled anonymous-connection disabled proxy-mode filename
H.245 Stage
The Oracle® Enterprise Session Border Controller allows you to set the earliest stage in an H.323 call when the Oracle® Enterprise 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® Enterprise Session Border Controller initiates the H.245 procedure by either:
- Sending its H.245 address, or
- Creating a TCP connection to an H.245 address that it has received
You can set this parameter to any of the following stages of an H.323 call: setup, proceeding, alerting, connect, early, facility, noh245, and dynamic. With the exception of early, noh245, and dynamic, these values correspond to types of H.225/Q.931 messages. The dynamic value is described in detail in the next section.
When you configure the early value, your Oracle® Enterprise Session Border Controller begins the H.245 procedure at the time the Setup message is sent or received, or when the Connect message is received.
While these values allows for some flexibility about when the H.245 process is started, they are inherently static. All calls in the H.323 stack configuration use the same value, and it cannot be changed from call to call on that stack.
Dynamic H.245 Stage Support
You can configure your Oracle® Enterprise Session Border Controller for dynamic H.245 support, meaning that the point at which the H.245 process begins can be determined dynamically. To support dynamic H.245, the Oracle® Enterprise Session Border Controller sends its H.245 address in the incoming call when it receives an H.245 address in the outgoing call.
Dynamic H.245 Stage for Incoming Calls
When a call comes in on an H.323 interface that you have configured for dynamic H.245 stage support.
The Oracle® Enterprise Session Border Controller includes its H.245 address in the h245Address field of the first H.225/Q.931 message. The Oracle® Enterprise Session Border Controller does this after it receives the first H.225/Q.931 message with an H.245 address in the outgoing call. Based on the first H.225/Q.931 message received by the Oracle® Enterprise Session Border Controller that has an H.245 address, the Oracle® Enterprise Session Border Controller selects the message in which to include the H.245 address as outlined in the table below.
| Message Received with H.245 Address | Message Sent with H.245 Address |
|---|---|
| Call Proceeding | Call Proceeding, Progress, Alerting, Connect or
Facility.
The H.245 address is sent in the Call Proceeding message if the system has not sent a Call Proceeding message in the incoming call. This is true only when you enable the Fast Start in first message parameter for the incoming stack; this parameter establishes whether or not Fast Start information must be sent in the first response to a Setup message. Otherwise, the message in which the H.245 address is sent depends on what message is received after the Call Proceeding message. This is because the Oracle® Enterprise Session Border Controller sends its Call Proceeding message directly after receiving the Setup message. |
| 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® Enterprise 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® Enterprise 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® Enterprise 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.
Dynamic H.245 Stage for Outgoing Calls
This section describes what happens when a message exits the Oracle® Enterprise Session Border Controller on an H.323 stack that you have configured for dynamic H.245 stage support.
When the Oracle® Enterprise Session Border Controller receives the first H.225/Q.931 message that has H.245 address information, it establishes an H.245 channel. The Oracle® Enterprise Session Border Controller initiates a TCP connection to the address and port specified in the H.245 address information.
If the incoming call for the session is also on an H.323 stack with dynamic H.245 configured, the Oracle® Enterprise Session Border Controller starts the H.245 procedure in the incoming call. Otherwise, the system sends its H.245 address in the incoming call based on the H.245 stage support that you have configured.
The process is different when the Oracle® Enterprise Session Border Controller receives a TCS message on the outgoing call before the incoming call reaches its H.245 stage. In this instance, the Oracle® Enterprise Session Border Controller sends a Facility message with the reason startH245 with its H.245 address in order to start the H.245 procedure. The reason is needed in order for the Oracle® Enterprise Session Border Controller to exchange TCS messages with the incoming side of the call.
H.323 HNT
This section explains how H.323 hosted NAT traversal (HNT) works and how to enable this capability on your Oracle® Enterprise 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® Enterprise 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® Enterprise Session Border Controller, the Oracle® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise 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:
H.323 Party Number-E.164 Support
Some H.323 gateways cannot handle partyNumber alias addresses in H.225 messages. The system lets you convert this address type to dialedDigits (E.164). This conversion applies to sourceAddress, destinationAddress, and destExtraCallInfo aliases in Setup messages.
To enable this feature, use the convertPNToE164 value in the options field of the H.323 stack configuration.
Signaling Only Operation
When you set the Oracle® Enterprise Session Border Controller to operate in signaling-only mode, it acts like a signaling server. It proxies the call signaling messages between two endpoints. Note, however, that the NOracle® Enterprise Session Border Controller does not function as a RAS proxy; it does not proxy RAS messages.
You have two options for the proxy mode:
- H.245 proxy mode—The Oracle® Enterprise Session Border Controller handles call signaling (H.225) and call control (H.245) messages.
- H.225 proxy mode—The Oracle® Enterprise Session Border Controller handles call signaling
To use this feature, you need to set the proxy mode parameter in the H.323 interface configuration to H.225 or H.245.
H.245
When in H.245 proxy mode, the Oracle® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise 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.
Maintenance Proxy Function
The Oracle® Enterprise Session Border Controller supports a maintenance proxy function for H.323 and enhances the way the Oracle® Enterprise Session Border Controller creates unique RAS ports. You can register endpoints through the Oracle® Enterprise Session Border Controller with unique RAS port. You can also set the H.323 interface on the enterprise side to represent enterprise-side endpoints and thereby register on the carrier side.
The maintenance proxy creates a many-to-one association between the enterprise and the carrier side. Interfaces on the enterprise side can be associated with the carrier side interface, which also must be configured to for the maintenance proxy feature.
You configure the maintenance proxy feature by simply setting an option in the H.323 interface configuration.
Applying TCP Keepalive to the H.323 Interface
To apply these settings individually per H.323 interface:
Automatic Gatekeeper Discovery
Available only when the H.323 interface is functioning as a gateway, this feature allows for automatic gatekeeper discovery on start-up.
This feature is based on the Oracle® Enterprise Session Border Controller sending a GRQ to the multicast address of the RAS Multicast Group, which is the device group listening on this address. If you do not configure a multicast address, Oracle® Enterprise Session Border Controller uses the well-known address and port 224.0.1.41:1718 in the address-port combination making up this parameter.
Multicast only functions when the Oracle® Enterprise Session Border Controller is discovering an external gatekeeper. The Oracle® Enterprise Session Border Controller does not respond to multicast gatekeeper queries.
When it receives a GCF message from a gatekeeper, the Oracle® Enterprise Session Border Controller registers with the gatekeeper indicated in the GCF. When it receives an GRJ message that contains optional information about alternative gatekeepers, the Oracle® Enterprise Session Border Controller attempts to register with an alternate.
If you do not use automatic gatekeeper discovery, the Oracle® Enterprise Session Border Controller registers with the gatekeeper you configure in the gatekeeper parameter. In this case, the gatekeeper identifier you configure is included in to the RRQ. No registration a takes place if you do not establish automatic gatekeeper discovery or if you do not configure the gatekeeper and its identifier.
H.323 Alternate Routing
You can configure your Oracle® Enterprise Session Border Controller to try more possible routes within given time constraints and number of retries.
Without Alternate Routing Enabled
If you do not enable H.323 alternate routing, the Oracle® Enterprise Session Border Controller tries one possible next hop gateway when routing H.323 calls even if the applicable local policy has multiple next hops configured. If that next hop gateway fails (either because it is busy or out of service), the Oracle® Enterprise Session Border Controller relays the failure back to the caller, who hears a busy tone.
In addition, the call will only be routed to the other available next hops if the first one is:
- A session agent that has gone out of service because it constraints have been exceeded
- A session agent that has gone out of service because it failed to respond to a Oracle® Enterprise Session Border Controller Setup request
- A session agent group
With Alternate Routing Enabled
When you enable H.323 Alternate Routing on your Oracle® Enterprise Session Border Controller, you enable the use of the other next hops in addition to the first one. The retry, when the other available next hops are used, is transparent to the caller. However, the number of retries is limited by the value you set for the ACLI connect-tmo parameter, and this feature works only if there is more than one matching local policy next hop. If there is not more than one match, even if that match is a session agent group, then the call is only attempted once and the caller must retry it.
If the Oracle® Enterprise Session Border Controller receives a Release Complete message before it receives an Alerting message, then it will try the next hop if there are multiple matches. When there is no more than one match, or if the timer or number of retries is exceeded, the Oracle® Enterprise Session Border Controller proxies the most recently received Release Complete message back to the caller.
The following table shows the cause codes and release complete reasons, and either of the two actions the Oracle® Enterprise Session Border Controller takes:
- Recur—Means that the Oracle® Enterprise Session Border Controller performs (or continues to perform) alternate routing
- Proxy—Means that alternate
routing stops, and the
Oracle® Enterprise Session Border Controller sends a release complete message back to the caller
H.323 Release Complete Reason Q.850 Cause Code Action No Bandwidth 34—No circuit available Recur Gatekeeper Resources 47—Resource unavailable Recur Unreachable Destination 3—No route to destination Recur Destination Rejection 16—Normal call clearing Proxy Invalid Revision 88—Incompatible destination Recur No Permission 111—Interworking, unspecified Recur Unreachable Gatekeeper 38—Network out of order Recur Gateway Resources 42—Switching equipment congestion Recur Bad Format Address 28—Invalid number format Recur Adaptive Busy 41—Temporary Failure Recur In Conference 17—User busy Proxy Undefined Reason 31—Normal, unspecified Recur Facility Call Deflection 16—Normal, call clearing Proxy Security Denied 31—Normal, unspecified Recur Called Party Not Registered 20—Subscriber absent Recur Caller Not Registered 31—Normal, unspecified Recur New Connection Needed 47—Resource Unavailable Recur Non Standard Reason 127—Interworking, unspecified Recur Replace With Conference Invite 31—Normal, unspecified Recur Generic Data Reason 31—Normal, unspecified Recur Needed Feature Not Supported 31—Normal, unspecified Recur Tunnelled Signaling Rejected 127—Interworking, unspecified Recur
H.323 Alternate Routing Configuration
This section describes how to enable H.323 alternate routing. There is a new parameter, and the behavior of the pre-existing response-tmo and connect-tmo parameters change when you enable this feature on your system.
To enable this feature, you need to set the new alternate-routing parameter in the global H.323 configuration to recur. The other option for this parameter is proxy, which means that the Oracle® Enterprise Session Border Controller performs in the way it did prior to Release 4.1, i.e. try only the first matching local policy next hop that it finds.
You configure H.323 alternate for the global H.323 configuration.
To enable H.323 alternate routing:
H.323 LRQ Alternate Routing
There are networks where the Oracle® Enterprise Session Border Controller is positioned so that it needs to send an H.225 LRQ request to one signaling entity, and then fall back to another signaling entity when there are no resources available on the first. This might be the case when network contain elements that have limited amounts of channels and/or ports.
To handle situations like this one, the Oracle® Enterprise Session Border Controller can be configured for H.323 LRQ alternate routing.
Without this feature enabled, the Oracle® Enterprise Session Border Controller performs H.323 alternate routing for an H.323 call by finding the alternate route for a local policy when the call setup using H.225/Q.931 fails. Some network configurations, however, require that an LRQ message be sent to a gatekeeper prior to call setup in order to request the destination call signaling address—meaning that the Oracle® Enterprise Session Border Controller will release the call if it does not receive an LCF for that LRQ.
With H.323 LRQ alternate routing enabled, the Oracle® Enterprise Session Border Controller can route the call even when it does not receive the LCF.
When the Oracle® Enterprise Session Border Controller routes an H.323 call using a local policy and the applicable route specifies gatekeeper/session agent as the next hop, the Oracle® Enterprise Session Border Controller must send that gatekeeper an LRQ to request the destination for the call signaling address. After it sends the LRQ, the Oracle® Enterprise Session Border Controller might receive either an LCF or an LRJ, or it might receive no response at all. Upon failure—either the receipt of an LRJ or no response within a timeout period—the Oracle® Enterprise Session Border Controller tries alternate routes (additional routing policies) until the call is either set up or the routing list ends. For each alternate route, if the next hop is a gatekeeper/session agent, the Oracle® Enterprise Session Border Controller sends an LRQ to the gatekeeper in order to request the destination call signaling address. Otherwise, the Oracle® Enterprise Session Border Controller simply sets up the call.
For a designated period of time, the Oracle® Enterprise Session Border Controller waits for the a response to the LRQ from the gatekeeper. This timeout period is configured by setting two options in the global H.323 configuration: ras-tmo (number of seconds the Oracle® Enterprise Session Border Controller waits before retransmitting a RAS message; default is 4) and maxRasRetries (maximum number of times the Oracle® Enterprise Session Border Controller retransmits the RAS; default is 1). The Oracle® Enterprise Session Border Controller calculates the LRQ timeout period by multiplying the ras-tmo by the maxRasRetries and adding one (ras-tmo x maxRasRetries +1).
If an out of service session agent is part of a route, the Oracle® Enterprise Session Border Controller skips it when using alternate routing and uses other routes for the policy.
A session agent might go out of service when it exceeds the maximum number of consecutive transaction timeouts to the maximum number of allowable transaction timeouts. Applicable session agent constrain parameter of note are:
- trans-timeouts—Maximum number of allowable transaction timeouts (default is 5)
- 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® Enterprise Session Border Controller
- 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® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise 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.
H.323 LRQ RAS Retransmission Configuration
There is no configuration for H.323 LRQ alternate routing; it is enabled by default. You do, however, need to set the ras-tmo and maxRasRetries options to set the timeout period.
If you want to set a maximum number of consecutive LRJs to be received from a session agent, you need to add the max-lrj value to an H.323 session agent’s options parameter.
To configure the number of seconds before the Oracle® Enterprise Session Border Controller retransmits a RAS message:
Set the maxRasRetries option in the same way; here, X is the maximum number of times the Oracle® Enterprise Session Border Controller retransmits the RAS; default is 1).
ORACLE(h323-stack)# options +ras-tmo=6 ORACLE(h323-stack)# options +maxRasRetries=2
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.
H.323 CAC Release Mechanism
When an OLC message is sent to the Oracle® Enterprise Session Border Controller and there is insufficient bandwidth available, the Oracle® Enterprise Session Border Controller will reject the incoming OLC. Normally, endpoints decide whether they want to send new OLCs or if they want to release the call. Some endpoints in this situation do neither. When communicating with the last of endpoints, it is desirable for the Oracle® Enterprise Session Border Controller to take action.
The system supports a option in the H.323 interface called olcRejectTimer. When this option is enabled and an OLC is rejected, the stack will:
- If there is another media channel open, the Oracle® Enterprise Session Border Controller will behave as if the release mechanism had not been enabled
- If there are no media channels open, the
Oracle® Enterprise Session Border Controller starts a timer for 1 second.
- If the call is released by the endpoint before the timer expires or another OLC is received from the endpoint before the timer expires, the Oracle® Enterprise Session Border Controller stops the timer and follows expected call handling
- If the timer expires before either of the above responses from the endpoint occur, the Oracle® Enterprise Session Border Controller releases the call.
H.323 Per-Realm CAC
Building on the Oracle® Enterprise Session Border Controller’s pre-existing call admission control methods, CAC can be performed based on how many minutes are being used by SIP or H.323 calls per-realm for a calendar month.
In the realm configuration, you can now set a value representing the maximum number of minutes to use for SIP and H.323 session using that realm. Although the value you configure is in minutes, the Oracle® Enterprise Session Border Controller performs CAC based on this value to the second. When you use this feature for configurations with nested realms, the parent realm will have the total minutes for all its child realms (i.e., at least the sum of minutes configured for the child realms).
The Oracle® Enterprise 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 (H.323 Connect) and disconnect (H.323 Release Complete), 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® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise 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.
H.323 Per-Realm CAC Configuration
This section shows you how to configure minutes-based CAC for realms and how to display minutes-based CAC data for a specific realm.
Note that setting the new monthly-minutes parameters to zero (0), or leaving it set to its default of 0, disables this feature.
To configure minutes-based CAC:
Use the ACLI show monthly-minutes command to see the following information:
- How many minutes are configured for a realm
- How many of those are still available
- How many calls have been rejected due to exceeding the limit
To view information about SIP per user CAC using the IP address mode: In either User or Superuser mode, type show monthly-minutes <realm-id>, a Space, and the IP address for which you want to view data. Then press Enter. The <realm-id> is the realm identifier for the realm identifier of the specific realm for which you want data.
ORACLE# show monthly-minutes private_realm
H.323 Bearer-Independent Setup
In Release 4.1, the Oracle® Enterprise Session Border Controller supports a new H.323 option that enables H.323 Bearer-Independent Setup (BIS). When enabled, this feature allows exception to slow-start to fast-start conversion on the Oracle® Enterprise Session Border Controller.
H.323 BIS Disabled
Unless you enable this feature, the Oracle® Enterprise Session Border Controller performs slow-start to fast-start conversion when a call entering the system as slow-start was routed to a an outgoing H.323 interface (stack) with call-fast-start set to enabled and there is a list of valid media-profiles in the configuration.
H.323 BIS Enabled
There are certain cases in access deployments where the slow-start to fast-start conversion should not be applied. This is the case when the Setup message contains the Bearer Capability information element (IE), which signals BIS.
When you enable this feature and the Oracle® Enterprise Session Border Controller receives an incoming Setup message that does not contain a fastStart field, the Oracle® Enterprise Session Border Controller checks for the BIS in the incoming Setup before it starts to perform the slow-start to fast-start conversion. If it finds the BIS, then it does not perform the conversion.
This feature can be enabled on a global or a per-interface basis, meaning that you can apply it to your system’s entire H.323 configuration or you can enable it only for the interfaces where you want it applied.
H.323 BIS Global Configuration
This section explains how to add H.323 BIS support to your global H.323 configuration and to specific H.323 interfaces (stacks).
If you set this option on an H.323 interface (stack), you must set it on the interface (stack) that receives the Setup message with BIS in the Bearer Capability IE.
To enable the H.323 BIS feature globally:
TOS Marking for H.323 Signaling
You can configure your Oracle® Enterprise Session Border Controller to perform TOS/DiffServ marking for H.323 signaling packets. This feature enables you to mark H.323 signaling packets so that they receive specific treatment from upstream devices. This feature assists in routing because you can configure the TOS byte inserted in the H.323 packet to mark the traffic for certain destinations. For example, you can prevent unauthorized video transmission through an audio-only session.
The Oracle® Enterprise Session Border Controller also performs TOS/DiffServ marking for media.
H.323 Codec Fallback
In the global H.323 configuration, you can enable a parameter that allows the Oracle® Enterprise Session Border Controller to renegotiate—or fallback—to the preferred codec used in an incoming terminal capability set (TCS) from the slow-start side of a slow-start to fast-start H.323 call. When enabled, the Oracle® Enterprise Session Border Controller performs this renegotiation when it detects a mismatch between the codec used in the open logical channel (OLC) opened on the fast-start side of the call, and the codec specified by the slow-start side.
Codec Fallback Disabled
With codec fallback disabled, the Oracle® Enterprise Session Border Controller opens a channel using the codec specified by the northbound side. Since the call manager had specified another preferred codec, the result is a codec mismatch leading to a dropped call.
The following diagram shows how codec mismatches end in dropped calls.
Codec Fallback Enabled
With H.323 codec fall back enabled, the Oracle® Enterprise Session Border Controller attempts to use the preferred codec that the slow-start side of the call specifies. The Oracle® Enterprise Session Border Controller determines matching based on the incoming TCS from the slow-start side and the OLC on the egress side. If the codecs do not match, the Oracle® Enterprise Session Border Controller sends an empty TCS on the egress side and closes the logical channels on the outgoing side of the call.
To trigger a new capabilities exchange, the Oracle® Enterprise Session Border Controller forwards the TCS from the ingress side of the call to the egress endpoint. Then the TCS from the egress endpoint is propagated to the ingress endpoint, and the logical channels are opened.
The following diagram shows a call scenario using the H.323 codec fallback feature.
H.323 TCS Media Sample Size Preservation
For H.323 fastStart calls, the Oracle® Enterprise Session Border Controller can be configured to preserve the packetization interval from the called gateway if it differs from the one offered in the Setup message the calling gateway sent.
When this feature is disabled and in accordance with the ITU H.323 recommendation, the Oracle® Enterprise Session Border Controller changes the packetization rate to the one used by the calling gateway if the one offered by the called gateway differs. In the following example, this means that the Oracle® Enterprise Session Border Controller replaces the packetization interval of 20 with 30 before it forwards the Alerting message to the calling gateway.
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® Enterprise 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® Enterprise 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® Enterprise Session Border Controller performs media sample size preservation for calls egressing on that interface.
H.323-TCS H.245 Support for H.264 and G722.1
The Oracle® Enterprise Session Border Controller supports the H.264 video codec and the G722.1 audio codec. Especially useful for customer video product offerings in which the Oracle® Enterprise Session Border Controller is deployed, this support further allows the Oracle® Enterprise Session Border Controller to increase ease of use by supporting private addressing. Without this feature enabled (the Oracle® Enterprise Session Border Controller’s previous behavior), the Oracle® Enterprise Session Border Controller required deployment for IANA registered IP addresses—despite the fact that IP VPNs allow for RFC 1918 private addressing.
H.323-TCS Generic Video Configuration
To enable this feature, you need to set up media profile configurations appropriately. Media profiles now allow you to set the configuration either as “generic video” or generic audio.
H.245 provides for defining new capabilities that are described as H.245 generic capabilities (GenericCapability), which the Oracle® Enterprise Session Border Controller now supports using the H.245 GenericCapability structure. H.264 and G.722.1 are the first codecs the Oracle® Enterprise Session Border Controller offers that use this mechanism.
To set a media profile for generic video support:
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
International Peering with IWF and H.323 Calls
When you do not enable this feature, H.323 calls can default to a National Q.931 Number Type and it is not possible to change it to an International number. This feature allows you to override that behavior by configuring the option cpnType=X, where X is an integer that maps to various Q.931 Number Types. When this option is set, Q.931 Number Type for both calling party and called party are updated to the configured value for all outing calls on the h323-stack.
The following is a list of possible cpnType=X option values for X:
- 0—Unknown public number
- 1—International public number
- 2—National public number
- 3—Specific public network number
- 4—Public subscriber number
- 5—Public abbreviated number
- 6—Private abbreviated number
You configure this feature as an option in the h323-stack configuration.
To configure the cpnType=X option for H323-H323 calls:
Default OLC Behavior Changed in Upgrade
You can configure the Oracle® Enterprise Session Border Controller to force media profiles in OLC messages when negotiating H.323 calls. This is the default behavior prior to Release S-C6.1.0.
In Release 6.1.0 and forward the default behavior of OLC is to inherit the values recieved in the signaling message from the remote endpoint.
To enable forced media profiles in OLC:
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.
Global H.323 Options
Note:
Oracle recommends you contact your Oracle account representative before configuring these options.| Options | Description |
|---|---|
| NoDynamicMSD | Oracle® Enterprise Session Border Controller forcefully assumes the “master” role for an outgoing call, and the slave role for an incoming call. |
| AllowOLCWoMSD | Oracle® Enterprise Session Border Controller sends OLC before master/slave determination is
complete.
Causes the Oracle® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise Session Border Controller does not allocates separate ports for audio and T.38. Oracle® Enterprise 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® Enterprise 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. |
H.323 Interface Options
Note:
Oracle recommends that you contact your Oracle account representative before configuring these options.| Option | Description |
|---|---|
| stackAliasWins | Oracle® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise Session Border Controller copies the sourceInfo from the incoming Setup message to the outgoing Setup message. Otherwise, Oracle® Enterprise Session Border Controller uses its own endpointType for the sourceInfo field. |
| noAliasinRCF | Oracle® Enterprise Session Border Controller does not include any terminal alias in the RCF. |
| forceH245 | Oracle® Enterprise Session Border Controllerinitiates an H.245 connection after the call is connected. Otherwise, Oracle® Enterprise Session Border Controller listens for an H.245 connection to be initiated by a remote endpoint. |
| useCPNInRAS | Oracle® Enterprise 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® Enterprise Session Border Controller registers interfaces on the enterprise side with a gatekeeper on the carrier side, and registers endpoints through the Oracle® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise 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:
|
| 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. |
