H.323 Automatic Features

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® Enterprise Session Border Controller sets the canMapAlias field in that message to true. This setting indicates that the Oracle® Enterprise 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® Enterprise 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® Enterprise 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.

Call Hold and Transfer

The Oracle® Enterprise Session Border Controller’s H.323 call hold and transfer feature supports consultation in addition to call holder and transfer. This feature uses signaling procedures based on the ITU-T recommendations/H.323 specification for what it calls third party initiated pause and rerouting.

The following diagram shows how the Oracle® Enterprise Session Border Controller is positioned to provide call hold and transfer support for H.323.

The OCSBC providing call hold and transfer support for H.323.

Call Hold and Transfer Basic Call

The following diagram show the signaling and media flows between the IP PBX and a softswitch. Note how the Oracle® Enterprise Session Border Controller is position to mediate flows between the two devices.

In the Call Proceeding messages forwarded to the IP PBX, the Oracle® Enterprise Session Border Controller uses a non-zero value to ensure that the IP PBX initiates an H.245 session. A progress indicator does not need to be included if the H.245 address is present in any of the following message types: Alerting, Progress, or Connect.

After the Oracle® Enterprise Session Border Controller receives a Call Proceeding message from the softswitch that contains the H.245 address, the Oracle® Enterprise Session Border Controller sends another Call Proceeding with its own H.245 address.

In the following call flow, the softswitch generates message to the gateway. These messages are:

Initial Address Message (IAM)
Address Complete Message (ACM)
Answer Message (ANM)

The OCSBC supporting call hold and transfer of a basic call.

Call Hold and Transfer Music on Hold

The following diagram begins with the condition that IP PBX A is already connected with a gateway, with the Oracle® Enterprise Session Border Controller and the softswitch positioned between the two.

You can see in the call flow where the channels for transporting media are closed, and where the RTP/RTCP is stopped. This creates a pause for the call. With the Oracle® Enterprise Session Border Controller mediating the process, IP PBX A and the softswitch exchange TCS and OLC messages that allow music on hold (MHO) to flow between IP PBX A and the gateway.

Call Hold and Transfer

The following diagram shows how call transfer works on the Oracle® Enterprise Session Border Controller for H.323. In this diagram, you can see:

Where local ringback occurs
Where the pause begins and ends
Where users and gateways are awakened
Where logical channels are opened and closed

The OCSBC supporting call hold and transfer.

Media Release for SS-FS Calls

When the Oracle® Enterprise Session Border Controller routes a slow-start to fast-start call, it is possible for the same fast-start call to be routed back through the Oracle® Enterprise Session Border Controller making for a hairpin flow. If it does becomes a hairpin flow, then the Oracle® Enterprise Session Border Controller routes it to its destination as a fast-start to fast-start call. This can result in one-way media if:

The destination of the hairpin call is in the same realm as the originating slow-start to fast-start call
The realm reference in the first bullet item is configured to disable in-realm media management
The called endpoint accepts the proposed fast-start logical channels

The enhancements to the Oracle® Enterprise Session Border Controller’s behavior described in this section show how the Oracle® Enterprise Session Border Controller follows additional procedures when setting up a hairpin flow to avoid one-way media when media release occurs.

For H.323 calls, the Oracle® Enterprise Session Border Controllerestablishes 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® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise Session Border Controller proposes, the called endpoint would send its media to the Oracle® Enterprise 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® Enterprise 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® Enterprise Session Border Controller. When the endpoints are in the same realm and when media management is enabled, however, the Oracle® Enterprise 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® Enterprise 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® Enterprise 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® Enterprise Session Border Controller also closes it logical channels. Once the channels are closed, the Oracle® Enterprise 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® Enterprise Session Border Controller sends on OLCAck with the Network Address and TSAP identifier for the logical channel from the calling endpoint. Then the Oracle® Enterprise 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® Enterprise Session Border Controller and the called endpoint exit the hold state. The last steps is for the Oracle® Enterprise 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® Enterprise Session Border Controller sends the empty TCS to the called endpoint to put it on hold.
When it detects media release, the Oracle® Enterprise 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® Enterprise 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® Enterprise Session Border Controllersends a restricted TCS to resume the call.
The restricted TCS the Oracle® Enterprise 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® Enterprise 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® Enterprise Session Border Controller also starts to re-open its logical channels.
Media Complete—Starts when all the logical channels that the Oracle® Enterprise Session Border Controller re-opens are acknowledged by the called endpoint.

When it enters the Media Complete state, the Oracle® Enterprise Session Border Controller updates the called endpoint with the full capabilities of the calling endpoint by sending the full TCS.

H.323 and IWF Call Forwarding

This section describes the Oracle® Enterprise Session Border Controller’s H.323 and IWF Call Forwarding feature, which is supported for H.323 calls and for calls initiated in SIP that require interworking to H.323.

Previous Behavior

Prior to Release 4.1, the Oracle® Enterprise 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® Enterprise 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® Enterprise 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.

The H.323 and IWF Call Forwarding diagram is described above.

When it receives a Facility message with the reason CallForwarded, the Oracle® Enterprise Session Border Controller looks for an alternate transport address in the Facility’s alternativeAddress or alternativeAliasAddress element. The Oracle® Enterprise 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® Enterprise 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® Enterprise Session Border Controller at this point tries to initiate a new egress call. The Oracle® Enterprise 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 Sample Call Flow

The following diagram shows how the H.323 Call Forwarding feature works in a purely H.323 environment.

The OCSBC performing call forwarding in an H.323 environment.

H.323 NOTIFY Support

To inform another call party of a certain event or communicate information to it, and H.323 entity might send a NOTIFY message. For example, a gateway might send a NOTIFY message to inform the calling party of a display name for a transferee. in previous releases, the Oracle® Enterprise Session Border Controller did not process such a NOTIFY message, blocking the message from reaching its intended destination.

The Oracle® Enterprise Session Border Controller supports the NOTIFY message so that it can pass through and reach its intended destination.

Caveats

The Oracle® Enterprise 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.

H.323 H.239 Support for Video+Content

The Oracle® Enterprise Session Border Controller supports multiple media streams for the same payload, generic capabilities, and H.239 generic messages. As a result, these additions broaden the Oracle® Enterprise Session Border Controller’s support for videoconferencing, and free you from have to configure media profiles for H.323 support.

Note:

These additions are supported for H.323-H.323 traffic only. These additions do not support SIP-H.323 interworking (IWF), so you still need to configure media profiles for that application.

Multiple Media Streams with the Same Payload

In releases prior to S-C6.2.0, the Oracle® Enterprise Session Border Controller supports multiple audio-video-data streams only if those streams use different payload types. The Oracle® Enterprise Session Border Controller’s behavior is extended to provide this support as of Release S-C6.2.0. The Oracle® Enterprise Session Border Controller identifies extendedVideoCapability used to establish an additional channel for H.239-compliant endpoints, an OLC that was formerly not supported.

Support for Generic Capabilities

This feature identifies the OIDs, shown in the table below, and uses the dynamicPayload type from the incoming OLC to generate its own OLC. You no longer need media profiles for genericAudio, genericVideo, and genericData.

Capability Name	Capability Class	Capability Identifier
H.283	Data protocol	{itu-t (0) recommendation (0) h (8) 283 generic-capabilities (1) 0}
G.722.1	Audio protocol	{itu-t (0) recommendation (0) g (7) 7221 generic-capabilities (1) 0}
G.722.1 Extension	Audio protocol	{itu-t (0) recommendation (0) g (7) 7221 generic-capabilities (1) extension (1) 0}
H.324	Data protocol	{itu-t (0) recommendation (0) h (8) 324 generic-capabilities (1) http (0)}
H.263	Video protocol	{itu-t (0) recommendation (0) h (8) 263 generic-capabilities (1) 0} Note: Use of this capability to signal H.263 "Profiles and Levels" per Annex X/H.263 should always be accompanied in parallel by the signalling of the same modes in H263VideoCapability. This is necessary to ensure that systems which do not recognize the H.263 generic capabilities continue to interwork with newer systems.
H.224	Data protocol	{itu-t (0) recommendation (0) h (8) 224 generic-capabilities (1) 0}
G.722.2	Audio protocol	{itu-t (0) recommendation (0) g (7) 7222 generic-capabilities (1) 0}
G.726	Audio protocol	{itu-t (0) recommendation (0) g (7) 726 generic-capabilities (1) version2003 (0)}
H.241/H.264	Video protocol	{itu-t (0) recommendation (0) h (8) 241 specificVideoCodecCapabilities (0) h264 (0) generic-capabilities (1)}
H.241/H.264	Video protocol	{itu-t(0) recommendation(0) h(8) 241 specificVideoCodecCapabilities(0) h264(0) iPpacketization(0) RFC3984NonInterleaved(1)}
H.241/H.264	Video protocol	{itu-t(0) recommendation(0) h(8) 241 specificVideoCodecCapabilities(0) h264(0) iPpacketization(0) RFC3984Interleaved(2)}

Support for H.239 Generic Messages

This section describes the Oracle® Enterprise Session Border Controller’s support for H.239 Generic Messages.

Generic Message	Description
Generic Request	flowControlReleaseRequest—Used when a device wants to add a channel toward an MCU that has sent multipointConference, or if the device wants to increase a channel bit rate when the channel is flow-controlled. The message has the channelId, which is the logicalChannelNumber of the channel. The Oracle® Enterprise Session Border Controller proxies this message, replacing the channelId with the logicalChannelNumber of its channel. presentationTokenRequest—Request by the sender to acquire the indicated token. The message has the channelId, which is the logicalChannelNumber of the channel. The Oracle® Enterprise Session Border Controller proxies this message, replacing the channelId with the logicalChannelNumber of its channel.
Generic Response	flowControlReleaseResponse—Sent in response to the flowControlReleaseRequest, either acknowledging or rejecting the request. The “acknowledge” response indicates the far-end device intends to make a best-effort attempt to comply with the request. The exact bit rate requested may not be allocated. The reject response indicates that the far-end device does not intend to comply with the request. The response contains the channelId that was sent in the request. While proxying the response, the Oracle® Enterprise Session Border Controller will replace the channelId with the channelId it received in the request. presentationTokenResponse—Sent in response to the presentationTokenRequest. The response will either confirm or reject the assignment of the indicated token to the sender of the presentationTokenRequest. The response contains the channelId that was received in the request. While proxying the response, the Oracle® Enterprise Session Border Controller will replace the channelId with the channelId it received in the request.
Generic Command	presentationTokenRelease—Sent by the device holding the token in order to relinquish the token. The message has the channelId, which is the logicalChannelNumber of the channel. The Oracle® Enterprise Session Border Controller proxies this message, replacing the channelId with the logicalChannelNumber of its channel.
Generic Indication	presentationTokenIndicateOwner—Indicates who owns the token. The message has the channelId, which is the logicalChannelNumber of the channel. The Oracle® Enterprise Session Border Controller proxies this message, replacing the channelId with the logicalChannelNumber of its channel.

Support for Miscellaneous Indication

An endpoint sends a miscellaneous indication to send (logicalChannelActive) or stop (logicalChannelInactive) live video streams. The message has a channelId, which is the channel’s logicalChannelNumber. The Oracle® Enterprise Session Border Controller proxies this message, replacing the channelId with the logicalChannelNumber of its own channel.