SIP: PRACK Interworking

SIP PRACK Interworking

When you configure your Oracle Communications Session Border Controller with PRACK interworking for SIP, you enable it to interwork between endpoints that support RFC 3262, Reliability of Provisional Responses in the Session Initiation Protocol, and those that do not.

As its title indicates, RFC 3262 defines a reliable provisional response extension for SIP INVITEs, which is the 100rel extension tag. While some endpoints do not support the RFC, other SIP implementations require compliance with it. A session setup between two such endpoints fails. However, you can configure your Oracle Communications Session Border Controller to supply the provisional response on behalf of endpoints that do not support it—and thereby enable sessions between those endpoints and the ones requiring RFC 3262 compliance.

You need to configure PRACK interworking for a SIP interface associated with the endpoints that need RFC 3262 support. To enabled the feature, you set the 100rel-interworking option. The Oracle Communications Session Border Controller applies PRACK interworking for either the UAC or the UAS. TheOracle Communications Session Border Controller checks to see whether or not it needs to apply PRACK interworking when an INVITE arrives at the ingress or egress SIP interface with the option enabled. First, it checks the Require header for the 100rel tag; if not found there, it checks the Supported header.

Since there is a slight difference in the application of this feature between the UAC and UAS, this section explains both.

Note:

If SDP is included in a PRACK request sent to a SIP interface where PRACK interworking is enabled, it will not be responded to, nor will any SDP be included in the locally-generated 200 OK to that PRACK.

UAC-Side PRACK Interworking

The Oracle Communications Session Border Controller applies PRACK interworking on the UAC side when:

An incoming SIP INVITE contains the 100rel tag in a Require header
The ingress SIP interface is enabled with the 100rel-interworking option
The UAS fails to send reliable provisional responses

When it is to forward a non-reliable response to a UAC that requires RFC 3262 support, the Oracle Communications Session Border Controller converts the non-reliable response to a reliable one by adding the 100rel tag to the Require header and adding an Rseq header to the response. Further, the Oracle Communications Session Border Controller adds a Require header (complete with the100rel tag) if there is not one already in the response, and then also adds Rseq header.

Note that the Oracle Communications Session Border Controller sets the value of the Rseq header as 1 for the first provisional response, and then increments it by 1 for each subsequent provisional response. It also adds the PRACK method to the Allow header when that header appears.

The Oracle Communications Session Border Controller retransmits the converted reliable provisional response in accordance with RFC 3262, until it receives a PRACK request. For the initial timeout for retransmission, the Oracle Communications Session Border Controller uses the value you set in the init-timer parameter in the global SIP configuration. It stops retransmitting when either it receives a transmission, or when the ingress SIP interface’s trans-expire timer elapses.

If it never receives a PRACK, the Oracle Communications Session Border Controller does not generate an error response to the INVITE, relying instead on the downstream UAS to produce a final response.

The call flow for this application looks like this:

Call flow depicting UAC side PRACK interworking.

UAS-Side PRACK Interworking

The Oracle Communications Session Border Controller applies PRACK interworking on the UAS side when:

An incoming SIP INVITE does not contain the 100rel tag in a Require or Supported header
The egress SIP interface is enabled with the 100rel-interworking option
The UAS does send reliable provisional responses

When the UAC does not support RFC 3262, the Oracle Communications Session Border Controller generates a PRACK request to acknowledge the response. It also converts the response to non-reliable by removing the 100 rel tag from the Require header and removing the RSeq header from the response.

In the case of the UAS, the Oracle Communications Session Border Controller matches the PRACK to a converted reliable provisional response using the PRACK’s RAck header. If it finds a matching response, the Oracle Communications Session Border Controller generates a 200 OK to the PRACK. And if it finds no match, then it generates a 481 Call Leg/Transaction Does Not Exist response. The Oracle Communications Session Border Controller generates a 400 Bad Request response if either the RAck is not in the PRACK request or it is not formatted properly.

The call flow for this application looks like this:

Call flow depicting UAS side PRACK interworking.

PRACK Interworking Configuration

You enable PRACK interworking for ingress and egress SIP interfaces. Be sure you know on what side, ingress or egress, you need this feature applied.

To configure PRACK interworking for a SIP interface:

In Superuser mode, type configure terminal and press Enter.
```
ORACLE# configure terminal
ORACLE(configure)#
```

Type session-router and press Enter.

ORACLE(configure)# session-router
ORACLE(session-router)#

Type sip-interface and press Enter. If you are editing an existing configuration, select the one on which you want to enable this feature.
```
ORACLE(session-router)# sip-interface
ORACLE(sip-interface)#
```
options—Set the options parameter by typing options, a Space, the option name 100rel-interworking with a plus sign in front of it, and then press Enter.
```
ORACLE(sip-interface)# options +100rel-interworking
```
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 this configuration’s options list, you must prepend the new option with a plus sign as shown in the previous example.
Save and activate your configuration.

After Dialog Establishment (INVITE transaction terminated)

Inside a dialog that has already been established, we should offer a way to convert UPDATE methods (with or without SDP) to INVITE methods. During the duration of this UPDATE based transaction, the method has to be modified from UPDATE to INVITE in all the appropriate places.

OCSBC supporting PRACK IWF after dialog establishment.

In the case that the original UPDATE does not contain SDP, the INVITE will include the last SDP sent to Peer B.

During dialog establishment (INVITE transaction not yet terminated)

There are six different use cases here depending on the following factors:

Caller/called requirements of reliable responses
Delayed/early offer
SDP insertion in delayed offer or not

Use Case	100rel Required by	Delayed offer	SDP injection
Use Case 1	Callee	No	N/A
Use Case 2	Callee	Yes	Yes
Use Case 3	Callee	Yes	No
Use Case 4	Caller	No	N/A
Use Case 5	Caller	Yes	Yes
Use Case 6	Caller	Yes	No

PRACK IWF on ingress side:

When the 100rel-interworking (or equivalent CLI) option is activated on the ingress realm, if an INVITE comes with a 100rel tag in a Require header, the INVITE will be forwarded with the tag only in the Supported header.
If the response is that the UAS do not support 100rel, the function will be triggered. If the response comes with a supported 100rel, the function will not be triggered.

PRACK IWF on egress side:

When the 100rel-interworking option is activated on the egress realm:

If an INVITE comes with a 100rel tag in a Require header, the function will not be triggered.
If an INVITE comes with no 100rel tag, it will be included in the Supported header.
- If the response includes 100rel requirements, the function will be triggered

Use Case 1

In this use case the caller leg does not support reliable responses and the called leg requires them. The initial INVITE comes with an SDP offer.

Actions:

Upon reception of a response with SDP (it can only happen once)
- Forward it to A side
- Send PRACK and wait for 200OK
- Keep the SDP of the first provisional response (SDP1’).
  NOTE: The SDP answer must come in a reliable response. The 200OK of a PRACK is not reliable
Upon reception of a response with no SDP
- Forward it to A side
- Send PRACK and wait for 200OK
Upon reception of an UPDATE with SDP from B after the SDP answer,
- Answer locally the UPDATE in the called side. The SDP of the 200OK will contain:
  - The first codec of the codec list present in the new offer that complies with the configured codec-policies.
  - The tel-events and image codecs from the new offer.
Upon reception of an UPDATE with SDP from B before the SDP answer, reject it with 488 (INVITE is still ongoing)
Upon reception of any additional response with no SDP
- Forward it to A side
- Send PRACK and wait for 200OK
200OK for INVITE should come with no SDP. We’ll include the same SDP as in the previous message in this side (SDP1’).
Depending of the codecs offered and answered in both sides transcoding may be triggered.

Use Case 2 (Not applicable to SR)

In this use case the caller leg does not support reliable responses and the called leg requires them.

The initial INVITE comes without SDP offer, and the SBC is adding SDP in the outbound INVITE

This use case is not applicable in a SR installation since we don’t have a way to indicate the proper IP address in the generated SDP.

The Use Case 2 call flow is described below.

Actions:

Upon reception of offer-less INVITE, and add-SDP is used:
- Add SDP in the egress INVITE (as today).
Upon reception of a response with no SDP
- Forward it to A side
- Send PRACK and wait for 200OK
Upon reception of a response with SDP (it can only happen once)
- Remove SDP and forward it to A side
- Send PRACK and wait for 200OK
- Keep the SDP.
  NOTE: The SDP answer must come in a reliable response. The 200OK of a PRACK is not reliable.
Upon reception of an UPDATE with SDP from B after the SDP answer,
- Keep the SDP (don’t need the previous kept SDP)
- Answer locally the UPDATE in the called side. The SDP of the 200OK will contain:
  - The first codec of the codec list present in the new offer that complies with the configured codec-policies.
  - The tel-events and image codecs from the new offer.
Upon reception of an UPDATE with SDP from B before the SDP answer, reject it with 488 (INVITE is still ongoing)
Upon reception of any additional response with no SDP
- Forward it to A side
- Send PRACK and wait for 200OK
200OK for INVITE should come with no SDP. We’ll include the last SDP received from the B side..
The ACK from the calling side will come with SDP. Remove it before relaying the ACK to the other side.
Depending of the codecs offered and answered in both sides transcoding may be triggered.

Use Case 3 (Not applicable to SR)

In this use case the caller leg does not support reliable responses and the called leg requires them. The initial INVITE comes without SDP offer, and the SBC is not adding SDP in the outbound INVITE

This use case is not applicable in a SR installation since we don’t have a way to indicate the proper IP address in the generated SDP.

The Use Case 3 call flow is described below.

Actions:

Upon reception of a response with no SDP (Illegal, but should we care?)
- Forward it to A side
- Send PRACK and wait for 200OK
Upon reception of a response with SDP (it can only happen once)
- Keep the SDP.
- Remove SDP and forward it to A side
- Send PRACK with SDP. Include a SDP answer to the PRACK that acknowledges the provisional response with SDP offer. This SDP will contain:
  - The first codec of the codec list present in the new offer that complies with the configured codec-policies.
  - The tel-events and image codecs from the new offer.
- Wait for 200OK for PRACK
Upon reception of an UPDATE with SDP from B after the SDP answer,
- Keep the SDP (don’t need the previous kept SDP)
- Answer locally the UPDATE in the called side. The SDP of the 200OK will contain:
  - The first codec of the codec list present in the new offer that complies with the configured codec-policies.
  - The tel-events and image codecs from the new offer.
Upon reception of an UPDATE with SDP from B before the SDP answer, reject it with 488 (INVITE is still ongoing). This is completely illegal, remove it if required.
Upon reception of any additional response with no SDP:
- Forward it to A side
- Send PRACK and wait for 200OK
200OK for INVITE should come with no SDP. We’ll include the last SDP received from the B side.
The ACK from the calling side will come with SDP. Remove it before relaying the ACK to the other side.
Depending of the codecs offered and answered in both sides transcoding may be triggered

Use Case 4

In this use case the caller leg does require reliable responses and the called side does not support them. The initial INVITE comes with SDP offer.

Actions:

Upon reception of a response with no SDP:
- Forward it to A side
- Answer locally the PRACK with 200OK
Upon reception of a response with SDP (it can only happen once):
- Keep the SDP of the first provisional response (SDP1’).
- Forward it to A side
- Wait for PRACK.
If PRACK comes with SDP, handle it as an UPDATE (see below)
If PRACK comes with no SDP, just answer it as today.
Upon reception of a new response with SDP (new response with SDP again):
- Remove the SDP
- Forward it to A side
- Wait for PRACK.
  - If PRACK comes with SDP, handle it as an UPDATE (see below)
  - If PRACK comes with no SDP, just answer it as today.
Upon reception of an UPDATE with SDP from A after the SDP answer:
- Answer locally the UPDATE. The SDP of the 200OK will contain:
  - The first codec of the codec list present in the new offer that complies with the configured codec-policies.
  - The tel-events and image codecs from the new offer.
Upon reception of an UPDATE with SDP from A before the SDP answer, reject it with 488 (INVITE is still ongoing)
Upon reception of any additional response with no SDP:
- Forward it to A side
- Answer locally the PRACK with 200OK
200OK for INVITE should come with SDP:
- Remove SDP
- Forward 200OK to A side
Depending of the codecs offered and answered in both sides transcoding may be triggered.

Use Case 5 (Not applicable to SR)

In this use case the caller leg does require reliable responses and the called leg does not support them. The initial INVITE comes without SDP offer, and we have the SBC configured to add the SDP to the initial INVITE.

Also, the first provisional response comes with no SDP, so the SBC will add SDP to the first response.

This use case is not applicable in a SR installation since we don’t have a way to indicate the proper IP address in the generated SDP.

The Use Case 5 call flow is described below.

Actions:

Add SDP in the egress INVITE.
The first provisional response comes without SDP, so the SBC will add a predefined (media-profile) to the SDP to the response.
- Forward it to A side
- Wait for PRACK.
  - Will come with SDP1’’
  - And answer it
Upon reception of a new response with SDP:
- Remove the SDP
- Forward it to A side
- Wait for PRACK.
  - If PRACK comes with SDP, handle it as an UPDATE (see below)
  - If PRACK comes with no SDP, just answer it as today.
Upon reception of an UPDATE with SDP from A after the SDP answer:
- Answer locally the UPDATE. The SDP of the 200OK will contain:
  - The first codec of the codec list present in the new offer that complies with the configured codec-policies.
  - The tel-events and image codecs from the new offer.
Upon reception of an UPDATE with SDP from A before the SDP answer, reject it with 488 (INVITE is still ongoing)
Upon reception of any additional response with no SDP:
- Forward it to A side
- Wait for PRACK:
  - If PRACK comes with SDP, handle it as an UPDATE (see previous step)
  - If PRACK comes with no SDP, just answer it as today.
200OK for INVITE should come with SDP:
- Remove SDP
- Forward 200OK to A side
Depending of the codecs offered and answered in both sides transcoding may be triggered

As an alternative to use-case 5 we have the case where the first provisional response already comes with SDP:

The slternative to Use Case 5 call flow is described below.

Actions:

Add SDP in the egress INVITE.
The first provisional response comes with SDP:
- Forward it to A side
- Wait for PRACK.
  - Will come with SDP1’’
  - And answer it
Upon reception of a new response with SDP (new response with SDP again):
- Remove the SDP
- Forward it to A side
- Wait for PRACK.
  - If PRACK comes with SDP, handle it as an UPDATE (see below)
  - If PRACK comes with no SDP, just answer it as today.
Upon reception of an UPDATE with SDP from A after the SDP answer:
- Answer locally the UPDATE. The SDP of the 200OK will contain:
  - The first codec of the codec list present in the new offer that complies with the configured codec-policies.
  - The tel-events and image codecs from the new offer.
Upon reception of an UPDATE with SDP from A before the SDP answer, reject it with 488 (INVITE is still ongoing)
Upon reception of any additional response with no SDP:
- Forward it to A side
- Wait for PRACK.
  - If PRACK comes with SDP, handle it as an UPDATE (see previous step)
  - If PRACK comes with no SDP, just answer it as today.
200OK for INVITE should come with SDP:
- Remove SDP
- Forward 200OK to A side
Depending of the codecs offered and answered in both sides transcoding may be triggered.

Use Case 6 (not applicable to SR)

In this use case the caller leg does require reliable responses and the called leg does not support them. The initial INVITE comes without SDP offer, and the SBC is not configured to add the SDP to the initial INVITE.

This use case is not applicable in a SR installation since we don’t have a way to indicate the proper IP address in the generated SDP.

From the IETF point of view, the first SDP offer should come in the first reliable response from the UAS, in this case the 200OK. Any other case would be illegal. However, in order to protect for possible use cases, and leveraging the previous use case, we’ll offer also this one:

** LRBT is currently planned for a later release of SBC and so any interactions with LRBT will not be implemented as part of this PRACK IWF feature in 7.3 M2

The Use Case 6 call flow is described below.

Actions:

The first provisional response comes without SDP:
- o Add a predefined (media-profile) to the SDP in the response.
- o Forward it to A side
- o Wait for PRACK.
  - Will come with SDP1’’
  - And answer it
Upon reception of a new response with SDP:
- Remove the SDP
- Forward it to A side
- Wait for PRACK.
  - If PRACK comes with SDP, handle it as an UPDATE (see below)
  - If PRACK comes with no SDP, just answer it as today.
Upon reception of an UPDATE with SDP from A after the SDP answer:
- Answer locally the UPDATE. The SDP of the 200OK will contain:
  - The first codec of the codec list present in the new offer that complies with the configured codec-policies.
  - The tel-events and image codecs from the new offer.
Upon reception of an UPDATE with SDP from A before the SDP answer, reject it with 488 (INVITE is still ongoing)
Upon reception of any additional response with no SDP:
- Forward it to A side
- Wait for PRACK.
  - If PRACK comes with SDP, handle it as an UPDATE (see previous step)
  - If PRACK comes with no SDP, just answer it as today.
200OK for INVITE should come with SDP:
- Remove SDP
- Forward 200OK to A side
In the ACK insert SDP. The SDP will contain:
- The first codec of the codec list present in the new offer (SDP1’) that complies with the configured codec-policies.
- The tel-events and image codecs from the new offer (SDP1’).
Depending of the codecs offered and answered in both sides transcoding may be triggered.

Alternative case where the first reliable response comes with SDP:

Actions:

The first provisional response comes with SDP:
- Forward it to A side
- Wait for PRACK.
  - Will come with SDP1’’
  - And answer it
Upon reception of a new response with SDP (new response with SDP again):
- Remove the SDP
- Forward it to A side
- Wait for PRACK.
  - If PRACK comes with SDP, handle it as an UPDATE (see below)
  - If PRACK comes with no SDP, just answer it as today.
Upon reception of an UPDATE with SDP from A after the SDP answer:
- Answer locally the UPDATE. The SDP of the 200OK will contain:
  - The first codec of the codec list present in the new offer that complies with the configured codec-policies.
  - The tel-events and image codecs from the new offer.
Upon reception of an UPDATE with SDP from A before the SDP answer, reject it with 488 (INVITE is still ongoing)
Upon reception of any additional response with no SDP:
- Forward it to A side
- Wait for PRACK.
  - If PRACK comes with SDP, handle it as an UPDATE (see previous step)
  - If PRACK comes with no SDP, just answer it as today.
200OK for INVITE should come with SDP:
- Remove SDP
- Forward 200OK to A side
In the ACK insert SDP. The SDP will contain:
- The first codec of the codec list present in the new offer (SDP1’) that complies with the configured codec-policies.
- The tel-events and image codecs from the new offer (SDP1’).
Depending of the codecs offered and answered in both sides transcoding may be triggered.