H.323 Automatic Features
This section describes H.323 features that are automatically enabled on your Oracle® Enterprise Session Border Controller. You do not have to configure special parameters to turn them on. Even though you do not have to turn these features on, this section describes what they do and how they work.
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. The OCSBC providing call hold and transfer support for H.323.](img/h323-call-hold-and-trans.png)
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. The OCSBC supporting call hold and transfer of a basic call.](img/h323-call-hold-and-transfer-basic-call-1.png)
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.
![The OCSBC supporting call hold and transfer music on hold. The OCSBC supporting call hold and transfer music on hold.](img/call-hold-and-transfer-music-hold.jpg)
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. The OCSBC supporting call hold and transfer.](img/h323-call-hold-and-transfer-transfer-1.png)
![The OCSBC supporting call hold and transfer. The OCSBC supporting call hold and transfer.](img/h323-call-hold-transfer3.png)
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 (ESBC) sends the
empty TCS to the called endpoint to put it on hold.
When the ESBC detects media release, it puts the called endpoint on hold. It can only do so if it has exchanged the TCS and TCSAck messages and completed primary-secondary determination with the calling endpoint.
When the ESBC receives a TCSAck in response to the empty TCS that it sent to the called endpoint, it closes the logical channels it opened as part of the Fast Connect procedure; the called endpoint likewise closes its logical channels. The two then exchange CLC and CLCAck messages, which signals the start of the Media Resume state.
- Media Resume—Starts when the ESBC sends a restricted TCS to resume the
call.
The restricted TCS the ESBC sends contains only the receive and 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 primary-secondary determination (MSD) process. However, the called party and not the ESBC 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 ESBC also starts to re-open its logical channels.
- Media Complete—Starts when all the logical channels that the ESBC re-opens are acknowledged by the called endpoint.
When it enters the Media Complete state, the ESBC 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. The H.323 and IWF Call Forwarding diagram is described above.](img/h323-and-iwf-call-forwarding.png)
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 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.
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 |
|
Generic Response |
|
Generic Command |
|
Generic Indication |
|
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.