SIPREC Recording Session Refresh

The Oracle Communications Session Border Controller provides for periodic in-dialog OPTIONS request/response exchanges to test the availability of the recording session dialog.

As shown below, and previously explained, establishment of a SIPREC session involves the creation of three distinct dialogs: a recording session dialog between the SIPREC client and SIPREC server, a SIP dialog between the calling party (A) and the SBC (acting as a B2BUA), and another SIP dialog between the SBC (acting as a B2BUA) and the called party (B). The two SIP dialogs are viewed conceptually as a single communications session dialog.

Both the call recording and the communication session dialogs are triggered by an INVITE at the SIPREC client. Upon reception, the recording client (the SBC) buffers the original INVITE, and sends a copy if it, along with call-related meta-data to the recording server. A 200 OK response from the server establishes the recording session dialog that will carry replicated call content; signalling information is conveyed by the metadata in the recording dialog. After establishing the recording session, the client transmits the buffered INVITE to the called party to begin establishing the communications session dialog.

In the absence of a 200 OK response, the recording client is required to reject the offered INVITE with a 503 (Service Unavailable) SIP error code and an accompanying Reason header indicating that the recording session could not be established.

After establishing the recording session dialog, the client does not monitor its connection state. Its only opportunity to verify the state occurs after the termination of the communications session dialog, which triggers a client-originated BYE to the recording server. Reception of a 200 OK/ACK confirms the persistence of the recording session, while the lack of acknowledgement indicates the failure of the recording session at some unspecified point in time.

This failure to identify a prematurely terminated recording session has caused service providers and some regulatory agencies to require timely recognition of a failed call recording dialog.

Release S-CZ7.2.0, and later releases, address this requirement by providing for the exchange of periodic in-dialog OPTIONS request/response exchanges to test the availability of the recording session dialog.

Timer_B

Section 17.1.1.2 of RFC 3261, SIP: Session Initiation Protocol describes a TIMER_B, the SIP INVITE transaction timer, which specifies the maximum interval between an INVITE request and response. The RFC suggests a default value of 32 seconds. Depending on the installed release version, two ACLI commands, trans-expire and initial-inv-trans-expire, provide user control over the TIMER_B value at both the SIP global level and the SIP interface level. Use these commands to adjust TIMER_B values if required.

OPTIONS Request/Response

Availability of the recording session is tested by an in-dialog SIP OPTIONS request/response exchange initiated by the call recording client and completed by the call recording server. If the OPTIONS exchange is enabled, two timers are set when the recording session dialog is established: a refresh-timer that specifies the interval between OPTIONS requests sent by the call recording client, and a response-timer that specifies the maximum interval between the OPTIONS request and the OPTIONS response. The response-timer is set to the smaller of the configured TIMER_B or refresh-timer values.

Expiration of the refresh-timer results in the transmission of an OPTIONS request to the call recording server. The server, in turn, must reply with a 200 OK OPTIONS response prior to the expiration of the response-timer. In the event of a positive response, the call recording client restarts the refresh-timer, and re-issues the OPTIONS request when the timer next expires.

In the event that the call recording server response is non-positive, that is either

not received prior to the expiration of the response timer, or
a non-2xx OPTIONS response

the SBC terminates the session recording dialog and records the termination in the event log.

Typically, a SIPREC environment contains multiple recorders configured to record a communications session dialog, consequently the communications session should be terminated only when all recording dialogs in the call recording server have terminated. At that point the communications session dialog is torn down with a 503 (Service Unavailable) error report.

Recording Session Refresh Configuration

Use the following procedure to enable a SIP OPTIONS request/response mechanism used to detect a prematurely terminated call recording session dialog.

Access the session-recording-server configuration element.

ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# session-recording-server
ORACLE(session-recording-server)#

Type select to choose and configure an existing object

ORACLE(session-recording-server)# select
<recordingServerName>:1: name=SRS02 desc=SRS Atlanta
2: name=name desc="SRS First Server:
3: name=srs01 desc=Miami

selection: 2

session-recording-required—ensure that this parameter is enabled.
This is a prerequisite for the provision of recording session refresh services.
refresh-interval—use this parameter to both enable the SIP OPTIONS request/response mechanism, and to assign a value to the refresh-timer, which measures the maximum allowed interval (in seconds) between the OPTIONS request sent by the call-recording client and the OPTIONS response returned by the call-recording server.
By default, refresh-interval is set to 0, which disables detection of a failed recording session dialog.

Assignment of any non-zero value enables detection and sets the allowable interval between OPTIONS requests and responses.

Consult local policy and regulatory requirements when specifying the refresh-interval value.
```
ACMEPACKET(session-router)# refresh-interval 12
ACMEPACKET(session-recording-server)#
```
Type done to save your configuration.