IWF Service Enhancements
This section describes the Oracle® Enterprise Session Border Controller features that are supported for when the Oracle® Enterprise Session Border Controller performs interworking between SIP and H.323. Enabling these enhancements only requires that you set up a fully functional SIP configuration, a fully functional H.323 configuration, and that you enable IWF on your Oracle® Enterprise Session Border Controller . You do not have to set any special configuration because these enhancements happen automatically.
SIP Redirect—H.323 LRQ Management
When it needs to interact with a SIP Redirect server, the Oracle® Enterprise Session Border Controller can interpret the SIP messages and manage them on the H.323 side of the session. For IWF sessions, the Oracle® Enterprise Session Border Controller handles SIP Redirect and H.323 LRQ messages.
Redirect—LRQ Management Sample 1
This section presents three possible scenarios for SIP Redirect-H.323 LRQ management.
The following diagram shows an established session that uses SIP Redirect—H.323 LRQ management. Here, the Oracle® Enterprise Session Border Controller sends an INVITE to a SIP Redirect Server that responds with a 3xx Redirection message. The Oracle® Enterprise Session Border Controller then sends the gatekeeper/gateway an LCF message that causes an ACF message to be sent to the H.323 endpoint.
Redirect—LRQ Management Sample 2
The following diagram shows how the Oracle® Enterprise Session Border Controller handles the exchange when the SIP Redirect server declares either that there is an error or that there is no such user. These SIP messages come from either the 4xx Request Failure or 5xx Server Failure series. In the example below, the SIP Redirect server returns a 401 Unauthorized message, which the Oracle® Enterprise Session Border Controller interworks and communicates to the H.323 gatekeeper as an LRJ. Then the H.323 gatekeeper/gateway issues an ARJ to the H.323 endpoint.
Redirect—LRQ Management Sample 3
In this call flow, the SIP server issues a 2xx Successful message that is not supposed to be sent (because a 3xx, 4xx, or 5xx message should be sent in response to the Oracle® Enterprise Session Border Controller ’s INVITE). The Oracle® Enterprise Session Border Controller sends a BYE message to the SIP Redirect Server, but it tries to initiate the session again, this time successfully. The final sample call flow shown rarely occurs.
SIP INFO and DTMF UII Management
The Oracle® Enterprise Session Border Controller supports DTMF for that require the IWF, enabling features such as keypress, alphanumeric, and hookflash. Because tones are not transmitted as audio, they must pass as out-of-band signaling information, meaning that the Oracle® Enterprise Session Border Controller needs to convert an H.245 UII (User Input Indication) into SIP.
Depending on the capability of the H.323 endpoint, the Oracle® Enterprise Session Border Controller sends either an alphanumeric or DTMF signal in the H.245 UII. The Oracle® Enterprise Session Border Controller sends nothing if the endpoint does not support an alphanumeric or DTMF signal. The SIP INFO message will have a content type of application/dtmf-relay, and the message body will be in the form Signal=*\r\nDuration=250\r\n. If the duration is absent in the SIP INFO or the UII received on the H.323 side is alphanumeric, the Oracle® Enterprise Session Border Controller uses the a 250 millisecond default value.
Mid-Session Media Change
Mid-session media change happens during a call that requires the IWF when the type of media being sent while a session is in progress changes. For example, a fax transmission might require mid-session media change; besides fax, other applications of this feature are possible. To support the transmission of a T.38 fax sent over an IWF session, some media channels must be opened and others closed. In addition, the Oracle® Enterprise Session Border Controller can accommodate a request for media change from, for example, audio to an image type for T.38 fax.
Because the media requirements are driven by endpoints and Gateways, you do not have to configure the Oracle® Enterprise Session Border Controller s mid-session media change support.
Enhanced Support for FAX Calls
The Oracle® Enterprise Session Border Controller now supports T.38 fax calls in networks containing elements that do not comply with the ITU-T H.323 Annex D recommendation for how to replace an existing audio stream with a T.38 fax stream. This support applies to signaling that requires interworking between SIP and H.323.
In the standard call model following the ITU-T recommendation, the endpoint detecting the fax tone sends an H.245 RequestMode message to its peer with a T.38 data mode. The receiving endpoint returns a RequestMode Ack by way of acknowledgement, triggering the sending endpoint to close its audio channel and open a T.38 fax channel. The receiving endpoint closes and opens the same channels on its end. T.38 fax streams flow upon the acknowledgement of all relevant channels.
However, certain endpoints close their logical channel before sending the H.245 RequestMode message for T.38, leaving the Oracle® Enterprise Session Border Controller with its audio channel still open and without having attempted to open a T.38 fax channel. To overcome this issue, the Oracle® Enterprise Session Border Controller now checks whether or not audio channels have been closed whenever it receives an H.245 RequestMode message for T.38. If it finds a closed audio channel, the Oracle® Enterprise Session Border Controller checks for the presence of a matching outgoing audio channel. A match causes the Oracle® Enterprise Session Border Controller to close the audio channel and continue with the procedure for converting to T.38 fax.
Early Media
For call that require the IWF, the Oracle® Enterprise Session Border Controller supports a cut-through for early media for calls that originate in SIP or H.323.
For a session originating in SIP, the provisional message will contain the SDP information if a Fast Start OLC was received in the Call Proceeding, Alerting, or Progress messages. The same SDP will be sent in the SIP 200 OK.
For a session that starts in H.323, the Oracle® Enterprise Session Border Controller translates the SDP it receives in SIP messages (either a 180 or a 183) into the appropriate H.323 Fast Start elements: Alerting or Progress. If the Alerting or Progress messages contain Fast Start elements, the Progress Indicator Q.931 information element (IE) will also be included in the message with Progress Descriptor 8, indicating that in-band information or an appropriate pattern is now available. This causes the call party to enable end-to-end early media in the reverse direction in accordance with H.323 v4.
In addition, the Oracle® Enterprise Session Border Controller allows early media to flow in the forward direction for a call that requires the IWF starting in H.323 that is being translated to SIP. This happens after the Oracle® Enterprise Session Border Controller has received provisional response with SDP and has sent Alerting or Progress message with Fast Start to the calling party. Similarly, early media in the forward direction is enabled for a call that requires the IWF starting in SIP and being translated to H.323. This happens after the Oracle® Enterprise Session Border Controller received Alerting or Progress messages with Fast Start and maps the Alerting or Progress to SIP 180 or 183 provisional response with the SDP answer.
Display Name Mapping
The Oracle® Enterprise Session Border Controller displays the full name and number of the calling party (for features such as Caller ID) when it handles calls that require the IWF. The Oracle® Enterprise Session Border Controller takes the display name in the From field of the SIP INVITE and maps it to the display IE so that it can show the full name of the calling party.
IWF Ringback Support
When interworking SIP and H.323 to a gateway, PSTN gateway, or other endpoint, the Oracle® Enterprise Session Border Controller uses the mappings shown in the table below. The absence or presence of SDP in the SIP provisional message determines whether the tones are generated in-band or locally.
For each of the mappings listed in the following table, this section provides a sample call flow.
| SIP Message | H.323 Message |
|---|---|
| No Message | CallProceeding |
| No Message | Progress without PI |
| 183 with SDP | Progress with PI |
| 180 w/o SDP | Alert without PI |
| 180 with SDP | Alert with PI |
In the following diagram, a call that requires the IWF passes through the Oracle® Enterprise Session Border Controller twice, creating two call legs. The call originates from H.323 GW1 and terminates in Phone 1 or Phone 2.
Sample 1 In-band Ringback without Progress Message
This sample flow shows how the Oracle® Enterprise Session Border Controller handles a call that requires the IWF where there is no progress message. In this call flow, there is a progress indicator of eight (8), meaning that ringback is in-band.
In this diagram, you can see that the Oracle® Enterprise Session Border Controller maps the progress indicator included in the Alerting message sent from Phone 1 through H.323 GW2 to a SIP 180 message with SDP. When the Progress message appears, it contains the progress indicator rather than the Alerting message containing it.
Sample 2 In-band Ringback with Progress Message
This sample flow shows how the Oracle® Enterprise Session Border Controller handles a call that requires the IWF where there is a progress message. In this call flow, there is a progress indicator of eight (8), meaning that ringback is in-band.
For this call flow, you can see again that the Oracle® Enterprise Session Border Controller maps the progress indicator included in the alerting message sent from Phone 1 through H.323 GW2 to a SIP 180 message with SDP. Note that now the Progress message contains the progress indicator.
Sample 3 In-band Ringback without Alerting Message
This sample flow shows how the Oracle® Enterprise Session Border Controller handles a call that requires the IWF where there is no progress message. In this call flow, there is a progress indicator of eight (8), meaning that ringback is in-band.
In this diagram, you can see that the Oracle® Enterprise Session Border Controller maps the progress indicator included in the Progress message sent from Phone 1 through H.323 GW2 to a SIP 180 message with SDP. When the Alerting message appears, it contains the progress indicator rather than the Progress message containing it.
Sample 4 Out-of-band Ringback without Progress Message
When there is no progress indicator included in the Alerting message, then there is out-of-band ringback. The system maps the Alerting message to a SIP 180, but it it does not include SDP in the SIP 180. This call flow shows that there is no Progress message and that media cannot be set up until after H.323 Connect and SIP messages are sent.
Sample Flow 5 Out-of-band Ringback with Progress Message
When there is no progress indicator included in either the Alerting or Progress messages, then there is out-of-band ringback. The system maps the Alerting message to a SIP 180, but it does not include SDP in the SIP 180. This call flow shows includes the Progress message; still, media cannot be set up until after H.323 Connect and SIP messages are sent.
H.323 Endpoint-Originated Call Hold and Transfer
When calls that require the IWF originating in H.323, the Oracle® Enterprise Session Border Controller supports call hold, transfer, and conference for the H.323 call leg. The call hold and transfer feature uses signaling procedures based on the ITU-T recommendations/H.323 specification for third party initiated pause and rerouting.
You do not have to configure the Oracle® Enterprise Session Border Controller ’s call hold and transfer feature.
The following diagram shows how the Oracle® Enterprise Session Border Controller provides call hold and transfer support for IWF sessions that originate in H.323. As you review this section’s call flow diagrams, you might want to refer back to the following logical diagram directly below to review the network elements involved, and what protocols they use.
Basic Call
In the following sample basic call, IP PBX A sends an H.323 Slow Starts message ultimately destined for the PSTN through the Oracle® Enterprise Session Border Controller . The Oracle® Enterprise Session Border Controller performs translation to SIP and inserts default information about media. Once the PSTN gateway responds with a 183 containing SDP, the Oracle® Enterprise Session Border Controller sends that information to IP PBX A. Then the Oracle® Enterprise Session Border Controller and the IP PBX exchange TCS- and OLC-related messages, and they negotiate master-slave determination. The Oracle® Enterprise Session Border Controller also sends IP PBX A a Call Progress message with a progress indicator of 8.
After the ringback tone, the proxy sends a 200 OK message with SDP to the system. The Oracle® Enterprise Session Border Controller sends a Connect message to the IP PBX A, and then it sends another SIP INVITE to the proxy that contains amended SDP (if that information about media is different from the default). After 200 OK and ACK messages are exchanged, media (RTP/RTCP) flow takes place.
Hold
This sample call flow assumes that the IWF call is established and that the RTP/RTCP flow is already in progress. The hold button is pushed, and IP PBX A sends an empty TCS to the Oracle® Enterprise Session Border Controller . The Oracle® Enterprise Session Border Controller puts the called party on hold by sending an INVITE message with 0.0.0.0 SDP to the SIP side of the call. Using 0.0.0.0 as the media address effectively stops the media flow. This INVITE is acknowledged, and the Oracle® Enterprise Session Border Controller closes the channels on the H.323 side, halting the RTP/RTCP flow.
When the caller on the H.323 side takes the call off hold, it resumes with a TCS that the Oracle® Enterprise Session Border Controller receives and then translates on the SIP side as an INVITE with SDP. After that INVITE is acknowledged and received, the Oracle® Enterprise Session Border Controller opens logical channels on the H.323 side and RTP/RTCP flows resume.
Music On Hold
This scenario is similar to the hold feature enabled for calls that require the IWF, except that after the RTP/RTCP flow between the H.323 and SIP sides stops, the call is sent to music on hold. Before the announcement or music plays, the Oracle® Enterprise Session Border Controller sets up the necessary support for media to be exchanged.
Transfer
The call flow described in this section recalls the diagram at the top of the H.323 Endpoint-Originated Call Hold and Transfer section, where endpoints A, B, and C are H.323 devices and endpoint D is a SIP device. When you follow the signaling and media flows, note that there are two Oracle® Enterprise Session Border Controller s in the call transfer and two sets of SIP/H.323 translations that take place. The first Oracle® Enterprise Session Border Controller translates H.323 to SIP, and the second performs the same operations with the protocols reversed.
In the scenario pictured, Party A is on a call with Party D, but wants to transfer Party C to Party D. Party A places Party D on hold, and then makes the call to Party C. Party A then puts Party C on hold, pressing the transfer button. You can see that Oracle® Enterprise Session Border Controller 1 receives a TCS from the IP PBX, which is then translated to SIP. Oracle® Enterprise Session Border Controller 2 receives it, performs the required protocol translations, and then opens a session with Party C via another IP PBX. Once this session is up and Party D is awakened, channels are established for media exchange.
In order to redirect the media so that it flows between Party C and Party D, the Oracle® Enterprise Session Border Controller 1 and IP PBX C exchange OLC and OLC Ack messages that contain address information for Party C and for Party D. Address information for both parties is contained in the OLC Ack messages that the Oracle® Enterprise Session Border Controller exchanges with the IP PBX. IP PBX A does not move forward with the call until it has the necessary address information.
Even though Party A’s participation in the call stops early in this scenario, the IP PBX with which it is associated keeps the signaling sessions with the Oracle® Enterprise Session Border Controller alive to manage the transfer.
Conference
To conference a call that requires the IWF that starts in H.323, the Oracle® Enterprise Session Border Controller uses a scenario much like the one used for holding a call that requires the IWF. Here again, the INVITE with 0.0.0.0 as the media address and the closing of logical channels stops the flow of RTP/RTCP. After signaling and SDP/media information are re-established, RTP/RTCP for the conference flows.
IWF Call Forwarding
This section describes the Oracle® Enterprise Session Border Controller ’s IWF Call Forwarding feature, which is supported for calls initiated in SIP that require interworking to H.323.
Prior to the implementation of this feature, 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.
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 486 BUSY HERE for a call being interworked from SIP to H.323).
If it finds an alternative address and the egress call has not been alerted or answered, the Oracle® 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.
Media Release for H.323 SS-FS Calls for IWF
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.
H.323
For H.323 calls, the Oracle® Enterprise Session Border Controller establishes media using the H.245 procedures described in the H.245 ITU-T recommendation: control protocol for multimedia communication. It also uses the Fast Connect procedure defined in the H.323 ITU-T recommendation: packet-based multimedia communication systems.
The latter ITU-T recommendation allows a calling endpoint to send a Setup message that contains a fastStart element, a sequence of OLC structures that describe the calling endpoint’s proposed forward/reverse logical channels. If the called endpoint accepts this proposal, then logical channels are established.
When the Oracle® 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.
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 theOracle® Enterprise Session Border Controller receives a TCSAck in response to the empty TCS that it sent to the called endpoint, it closes the logical channels it opened as part of the Fast Connect procedure; the called endpoint likewise closes its logical channels. The two then exchange CLC and CLCAck messages, which signals the start of the Media Resume state.
- Media Resume—Starts when the
Oracle® Enterprise Session Border Controller sends 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 Oracle® Enterprise Session Border Controller is ready (as specified in the ITU-T recommendations) to take part on the master-slave determination (MSD) process. However, the called party and not the Oracle® 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.
Additional IWF Steps
For calls originating in slow-start H.323 that require interworking to SIP, the Oracle® Enterprise Session Border Controller also takes addition steps for media release in hairpinned flows that the Oracle® Enterprise Session Border Controller routes as SIP to fast-start H.323.
For such a call, after the Oracle® Enterprise Session Border Controller has established logical channels on the slow-start H.323 side of the call, it sends a reINVITE on the SIP side. This reINVITE has an updated session description to correct the media connection information. The the Oracle® Enterprise Session Border Controller performs the hold-and-resume procedure on the fast-start side of the call. This procedure re-establishes the logical channels between the Oracle® Enterprise Session Border Controller and the called endpoint, avoiding the one-way media problem.
When you are configuring H.323 globally on your Oracle® Enterprise Session Border Controller , you might choose to set the noReInvite option. This option stops the Oracle® Enterprise Session Border Controller from sending a reINVITE after the logical channels are established on the slow-start H.323 side of the call. Instead, the Oracle® Enterprise Session Border Controller ’s H.323 task communicates internally with its own SIP task a SIP UPDATE message that corrects the SDP; then the SIP task updates media flow destinations. But the Oracle® Enterprise Session Border Controller does not send the UPDATE to the next hop, which can result in the one-way media problem if the call is hairpinned and media release occurs. For such cases, the default behavior for the noReInvite option is overridden. When the Oracle® Enterprise Session Border Controller detects media release in an H.323-SIP call, it forwards the UPDATE to the next hop even when you enable the noReInvite option.
Dependencies
This feature depends on:
- The H.323 endpoint supports the third-party-initiated pause and re-routing feature.
- The H.323 endpoint does not change its Network Address and TSAP identifier when it re-opens the logical channels.
- The H.323 endpoint does not immediately tear down the call when there is not established logical channel in the call.
- The fact that the SIP endpoint supports the UPDATE message if the noReInvite option is enabled.
