Before You Configure

The Oracle Communications Session Border Controller ’s IWF requires that there be complete configurations for both SIP and for H.323. These two sets of configurations function together when the interworking is configured and enabled.

You enable the Oracle Communications Session Border Controller ’s interworking capability when you set the IWF configuration’s state parameter to enabled, and all required H.323 and SIP configurations are established. This means that all of the following configurations must be established:

A full SIP configuration, including SIP interfaces, SIP ports, SIP-NATs (if needed), and SIP features
A full H.323 configuration, including H.323 global and H.323 interface configurations
Local policy and local policy attributes (the IWF will not work without these configurations)
Media profiles
Session agents and, if needed, session agent groups

H.323 Configuration

You must have a complete configuration to support H.323 traffic on your Oracle Communications Session Border Controller , including any required support for H.323 Fast Start or Slow Start.

In the H.323 interface configuration, you are able to configure interfaces that enable communication between H.323 devices (for audio, video, and/or data conferencing sessions).

If you know that your Oracle Communications Session Border Controller will be handling traffic originating in Slow Start H.323, you must establish the appropriate list of media profiles in the IWF configuration. Handling Slow Start traffic also requires that you establish appropriate local policy (and local policy attribute) configurations, but configuring session agents and session agent groups is optional.

SIP Configuration

SIP functionality must also be configured on your Oracle Communications Session Border Controller that will perform IWF translations. You must use appropriate local policy (and local policy attribute) configurations, but configuring session agents and session agent groups is optional. If you use session agents, then you must also configure the information you need for media profiles.

The Role of Local Policy

You must configure local policies (and local policy attributes, if necessary) in order for translations between SIP and H.323 to take place. These local policies determine what protocol is used on the egress side of a session. Local policy and local policy attribute configurations make routing decisions for the session that are based on the next hop parameter that you set. The next hop can be any of the following:

IPv4 address of a specific endpoint
Hostname or IPv4 address of a session agent
Name of a session agent group

You can use the application protocol parameter in the local policy attributes configuration as a way to signal the Oracle Communications Session Border Controller to interwork the protocol of an ingress message into a different protocol as it makes its way to its egress destination (or next hop).

For example, if you set the application protocol parameter to SIP, then an inbound H.323 message will be interworked to SIP as it is sent to the next hop. An inbound SIP message would travel to the next hop unaffected. Likewise, if you set the application protocol parameter to H.323, then an incoming SIP message will be interworked to H.323 before the Oracle Communications Session Border Controller forwards it to the next hop destination.

The following example shows a configured local policy and its attributes used for IWF traffic.

local-policy
        from-address
                                       *
        to-address
                                       444
        source-realm                   *
        state                          enabled
        last-modified-date             2004-04-20 17:43:13
        policy-attribute
                next-hop                       sag:sag_internal
                realm                          internal
                replace-uri                    disabled
                carrier
                start-time                     0000
                end-time                       2400
                days-of-week                   U-S
                cost                           0
                app-protocol                   SIP
                state                          enabled
                media-profiles

Local Policy in an IWF Session Initiated with H.323

In a session where the Oracle Communications Session Border Controller is interworking H.323 to SIP, it internally forwards the session on for interworking when:

The next hop in the local policy is configured as a SIP session agent
The next hop in the local policy is configured as a SIP session agent group
The next hop in the local policy is not configured as a session agent or session agent group, and the application protocol parameter is set to SIP in the local policy attributes configuration.

Local Policy in an IWF Session Initiated with SIP

In a session where the Oracle Communications Session Border Controller is interworking SIP to H.323, it internally forwards the session on for interworking when:

The next hop in the local policy is configured as an H.323 session agent
The next hop in the local policy is configured as an H.323 session agent group
The next hop in the local policy is not configured as a session agent or session agent group, and the application protocol parameter is set to H.323 in the local policy attributes configuration
In this case the local policy should also define the egress realm, which you can set in the realm parameter of the local policy attributes configuration.

SIP-H.323 interworking with Dynamic Payload Types

The SIP and H.323 Protocols use Internet multimedia signaling over IP, and both use the Real-Time Transport Protocol (RTP) for transferring realtime audio/video data. The interworking function (IWF) provides a means of converting translation and signaling protocols and session descriptions between SIP and H.323. However, SIP and H.323 provide different mechanisms when exchanging payload types for media during IWF calls. Therefore, the International Telecomunications Union (ITU) modified the ITU H.245 recommendations in H.245 v16 to include a new “Dynamic Payload Type Replacement” capability that resolves this payload type conflict. This new capability provides a way for an H.323 endpoint to specify the payload type of a media stream for which the endpoint is willing to receive through the OLCacknowledgment (OLC-ACK) message in an audio/video call flow.

The Oracle Communications Session Border Controller supports this new “Dynamic Payload Type Replacement” capability by ensuring interworking of SIP and H.323 when audio/video call flows use dynamic payload types. The Oracle Communications Session Border Controller checks for the presence of this capability in the incoming TCS request. If it finds this capability in the TCS request, it sends an Open Logic Channel Acknowledgement (OLC-ACK) response with the payload type it is willing to receive.

Note:

The Oracle Communications Session Border Controller always returns an OLC-ACK with a dynamic payload type value that it received in the incoming Session Description Protocol (SDP) from the SIP endpoint.

For devices that don't support the H.245 v16 recommendations, the Terminal Capability Set (TCS) request from the H.323 endpoint does not have the "Dynamic Payload Type Replacement" capability present. Therefore, the Oracle Communications Session Border Controller rewrites the payload type within the RTP packets when these packets traverse the Oracle Communications Session Border Controller. When devices in a session negotiate different payload types between SIP and H.323 packets, the RTP streams that they receive, always have the expected payload type in the RTP header.

Note:

The Oracle Communications Session Border Controller always maps the payload type on the RTP stream received from the H.323 endpoint, and sends it to the SIP endpoint for both audio and video. The Oracle Communications Session Border Controller does not support mapping of payload types in audio streams with 2833 DTMF packets.

Figure 1a and 1b below shows the call flow from an H.323 Endpoint B to a SIP Endpoint A, and from a SIP Endpoint A to an H.323 Endpoint B, respectively. These illustrations show the negotiation of different dynamic payload types for the video streams but the Codec negotiated is the same. The Oracle Communications Session Border Controller dynamically replaces the payload type in the RTP header of the video stream received from the H.323 endpoint.

Figure 1a Endpoint B calling Endpoint A (H.323 endpoint does not have “Dynamic Payload Type Replacement” Capability)

SIP-H.323 interworking with dynamic payload types example.

The H.323 Endpoint B is not H.245 v16 compliant, and hence payload type replacement needs to be done in the RTP packets.

Figure 1b Endpoint A calling Endpoint B (H.323 endpoint does not have Dynamic Payload Type Replacement Capability)

The H.323 Endpoint B is not H.245 v16 compliant, and therefore payload type replacement needs to be done in the RTP packets.

There is no concept of H.245 compliance for the SIP Endpoint A.

Figure 2a shows the call flow of SIP Endpoint A calling an H.323 Endpoint B using slow start. The Oracle Communications Session Delivery Manager modifies the dynamic payload type in the OLC-ACK based on payload type received in the incoming SDP OFFER in the "INVITE" message.

Figure 2a Endpoint A calling Endpoint B (H.323 endpoint has TCS with Dynamic Payload Type Replacement Capability)

The H.323 Endpoint B is H.245 v16 compliant.

There is no concept of H.245 compliance for the SIP Endpoint A.

Figure 2b shows the call flow an H.323 Endpoint B using slow start, calling a SIP Endpoint A. The Oracle Communications Session Delivery Manager modifies the dynamic payload type in the OLC-ACK based on payload type received in the incoming SDP ANSWER in the "200 OK" message.

Figure 2b Endpoint B calling Endpoint A (H.323 endpoint here has TCS without “Dynamic Payload Type Replacement” Capability)