Configuring SIPREC
This section defines the information required to configure SIPREC on the Oracle Communications Session Border Controller. It also provides a sample procedure for configuring SIPREC using the Acme Packet Command Line Interface (ACLI).
Session Recording Server (SRS)
The Oracle Communications Interactive Session Recorder’s RSS acts as the SRS in the network. A session-recording-server attribute under the session-router object in the Oracle Communications Session Border Controller ACLI allows you to enable/disable the SRS. This object is the session recording server that receives replicated media and records signaling. Additional parameters for SRS are configured under the session-agent, realm-config, and sip-interface objects. The rules of precedence for which the Oracle Communications Session Border Controller uses these parameters are: session-agent takes precedence over the realm-config, and realm-config takes precedence over sip-interface.
Each SRS is associated with a realm-config. The realm specifies the source interface from which replicated traffic originates. The destination is an IP Port parameter (IP address or hostname with an optional port) that defines the SIP address (request URI) of the actual SRS.
For an additional level of security, Oracle recommends the SRS be configured in its own realm so as to apply a set of access control lists (ACLs) and security for the replicated communication.
Although the Oracle Communications Session Border Controller supports large UDP packets, Oracle recommends the sip-interface associated with the SRS realm, be provisioned with a TCP port.
Enforcing Parity Check on Media Port Numbers with the SRS
You can configure the SBC to enforce media port number parity on flows between the SBC and the SRS, as discussed in RFC 4566. By default, the SBC does not consider port number parity when assigning or recognizing RTP and RTCP flows in SDP session descriptions. This can result in signaling issues, including one-way audio recording, when the recording server and the SBC establish flows that have a port number conflict.
By default, the SBC does not enforce port number parity for RTP and RTCP flows to the SRS, acting as the UAS callee on the east side interface. This parity defines the use of an even port for RTP and the subsequent odd port for RTCP. The force-parity parameter causes the SBC to behave as follows when receiving port number is the SDP m-line from the SRS:
- Disabled - The SBC accepts both odd and even ports on the m-line. The SBC sends both rtp and rtcp to this same port.
- Enabled - The SBC rejects odd ports on the m-line, and accepts even ports. Upon receiving an even port, the SBC sends rtp to the even port and rtcp to (rtp+1), which is an odd numbered port.
You enable the force-parity parameter on the applicable session-recording-server.
ACMEPACKET(session-recording-server)# force-parity enabledSession Recording Group
The Oracle Communications Session Border Controller uses the session-recording-group attribute under the session-router object in the ACLI to set high availability (HA) for 3rd party call recorders. Using this object, you can define a collection of one or more SRSs. The Oracle Communications Session Border Controller utilizes SIP’s transport mechanism and keeps track of statistics on each SRS to manage the distribution of traffic and load balancing. (For more information on Oracle Communications Session Border Controller load balancing in session recording groups, see Load Balancing). When multiple SRSs are in a session recording group, the Oracle Communications Session Border Controller uses heuristics to intelligently route the recording dialog to one or more SRSs utilizing the selection strategy.
The simultaneous-recording-servers configuration attribute controls the number of simultaneous SIP dialogs that the Oracle Communications Session Border Controller establishes to the SRSs in the session recording group per communication session. For instance, if a session recording group contains 3 SRSs, and simultaneous-recording-servers is set to 2, the recording agent initiates a SIP INVITE to the next two SRSs based on the session recording group strategy. In this way, duplicative recording sessions are instantiated, allowing for recording redundancy in multiple SRSs or within a session recording group.
Note:
The Oracle Communications Session Border Controller streams media to all SRSs. Each SRS chooses whether or not to ignore the media by returning a recvonly(receive only) media line. This permits an SRS to select specific media to record in the recording session, as well as determine whether or not to record the media.The number of simultaneous recording servers does not dictate the number of recording devices required to be active for a communication session. If two SRSs exist in a session recording group and simultaneous-recording-servers is set to 2, if at least one recording device to any of the servers completes, the recording server is treated as being established.
Load Balancing
The Oracle Communications Session Border Controller supports recording server load balancing across members of a session recording group using the following strategies:
Note:
SRS groups support “round-robin” and “hunt” strategies only.[Round-robin]: The Oracle Communications Session Border Controller remembers the last SRS that was used. Each new recording session selects the next SRS in the session recording group. When simultaneous-recording-servers is greater than 1, the next n recording servers are selected from the session recording group.
[hunt]: The Oracle Communications Session Border Controller successively attempts to contact SRSs in the session recording group until a successful recording dialog is established with the SRS, starting from the first SRS in the session recording group. The Oracle Communications Session Border Controller attempts to contact each SRS in the session reporting group once. When contact is exhausted, the recording device is considered failed. A SIP failure (response greater than 399, timeout or TCP setup failure) causes the Oracle Communications Session Border Controller to attempt the next possible SRS. When simultaneous-recording-servers is greater than 1, the Oracle Communications Session Border Controller attempts to establish n recording devices in a hunting fashion.
Session Recording Group within Logical Remote Entities
Each logical remote entity (session-agent, realm-config and sip-interface) has a session-recording-server attribute.This attribute is a reference to a specific SRS configuration and can be used to specify a session recording group instead. If a session recording group is specified instead of an SRS, the session recording group name must be prefixed with "SRG:" followed by the session recording group name. This distinguishes between an SRS being referenced and a session recording group being referenced.
With SIPREC, if an SRS or session recording group is configured on both the ingress and egress logical remote entities, both the ingress and egress SRS/session recording groups are used. This means that the Oracle Communications Session Border Controller records the media between participants twice (or more) - once for the ingress recorders and once for the egress recorders.
If both the ingress and egress SRS/session recording group are the same, the Oracle Communications Session Border Controller makes an optimization and only records the media once. Even if the ingress session recording group is the same exact set of SRSs as the egress session recording group (but with a different name), the Oracle Communications Session Border Controller replicates media to both destinations. However, if the same set of SRSs has the exact same identifier, the Oracle Communications Session Border Controller sends media to one and not both SRSs.
Selective Recording
SIPREC defines a number of use cases for which the Oracle Communications Session Border Controller can record communication sessions. These use cases include the use of selective based recording. A selective recording is one in which a unique recording server is created per communication session.
Note:
The Oracle Communications Session Border Controller does not support persistent recording.For SRSs using selective recording, recording servers are unique per session recording group. For each selective SRS in a session recording group, during the setup of a new communication session, the recording metadata is the same for each recording device. The SRC initiates a new SIP INVITE to the SRS carrying the metadata for that new recording server. The recording agent terminates the SIP dialog at the time that the recording session ends.
The lifetime of a recording session extends beyond the lifetime of the recorded communication. The SRC (Oracle Communications Session Border Controller) re-uses the recording session ID in the metadata instead of creating a new ID for each recording.
SIPREC Support for SRTP
With the exception noted in the following table, the SBC supports SIPREC on all media flows with any combination of SRTP-RTP call legs on ingress and egress for all Acme Packet platforms. The SBC also supports SRTP on the interface between the SBC and the SIPREC server.
| Caller A | Caller B | SRS | Supported or Not Supported |
|---|---|---|---|
| RTP | RTP | RTP | Supported |
| RTP | SRTP | RTP | Supported |
| SRTP | RTP | RTP | Supported |
| SRTP | SRTP | RTP | Supported |
| RTP | RTP | SRTP | Supported |
| RTP | SRTP | SRTP | Supported |
| SRTP | RTP | SRTP | Supported |
| SRTP | SRTP | SRTP | Supported |
- The supported combinations apply to transcoded and non-transcoded calls.
- The supported combinations apply to recording and requires either the disabled mode or the enabled mode.
- The SDES profile that you use for in the media-security-policy configuration must include both the AES_CM_128_HMAC_SHA1_80 and AES_CM_128_HMAC_SHA1_32 ciphers in the crypto-list. Apply this media security policy to each realm where you want SRTP traffic.
High Availability (HA) Support
An Oracle Communications Session Border Controller using SIPREC supports HA in the network. The Oracle Communications Session Border Controller replicates all metadata states between the active and standby Oracle Communications Session Border Controllers. Any recording dialogs in progress do not survive the failover, but all calls in progress are preserved. Additionally, the recording dialogs are replicated as well to the failed over Oracle Communications Session Border Controller so that in-dialog SIP requests continue to function.
Each recorded communication session replicated to a single SRS counts as two calls instead of one. The Oracle Communications Session Border Controller creates two flows between the two participants and two additional flows to the SRS for each of the parent flows.
SIPREC Configuration Procedure
The following configuration example assumes the Oracle Communications Session Border Controller has the session recording license enabled on the Oracle Communications Session Border Controller. Changes to the call session recording configuration for SIPREC are dynamic. Active calls in progress remain unaffected by the configuration changes. New calls, however, utilize the changes after a Save and Activate of the configuration.
The following attributes must be configured:
- session-recording-server
- session-recording-group (for RSS or 3rd party SRS high availability (HA) only) and at least one of the following attributes:
- realm-config
- session-agent
- sip-interface
Session-recording-group Attribute (for HA only)
For environments that required high availability (HA) requirements, configure the session-recording-group attribute.
To configure the session-recording-group attribute and enable HA:
P-Asserted Identity and Diversion Headers in SIPREC Metadata
The Oracle Communications Session Border Controller supports some call transfer scenarios in which the contents of the P-Asserted-Identity, Diversion and History-info headers must be included in the SIPREC metadata for in-dialog requests (re-INVITE and UPDATE) as well as initial requests.
During a Communication Session (CS) between user-agents, Oracle Communications Session Border Controllerupdates the SRS, for in-dialog requests like Re-INVITE and UPDATE, in the Recording Session (RS). In call transfer scenarios, the participant information available in the headers is updated in the extension data under SIPREC Metadata. When the option disable-re-invite-on-update is configured in the session-agent, sip-interface, or real-config configuration elements, the SBC restricts the Re-INVITE to RS for the in-dialog UPDATE in CS.
You will have to configure the system with the SipHeaderExtensionMetadata.spl (SBC Processing Language) plugin for the disable-re-invite-on-update option to work. For more information, see Inserting SIP headers into SIPREC Metadata.
Consider a call transfer scenario between User Agent A (UA-A) and User Agent C (UA-C). The session will be recorded by Oracle Communications Session Border Controlleracting as an SRC and an SRS. The SRS does not record the session with User Agent B. In order to record the session between UA-A and UA-C it is vital to correctly identify the User Agents in the session. The system uses the headers in the metadata to reflect the identities of the participating agents.
The header information such as P-Asserted Identity, Diversion and History-info for INVITE/Re-INVITE and UPDATE cases will be updated in the extension data of participant xml element.
You can configure the option disable-re-invite-on-update to stop the Re-INVITE requests towards the Recording Session (RS) for any in-dialog UPDATE in Communication Session (CS). This option can be configured under a specified sip-interface , realm-config , or a session-agent .
ORACLE#(session-agent) options +disable-re-invite-on-updateSession-agent takes precedence over realm-config, and realm-config takes precedence over sip-interface.
Metadata Contents
The recording metadata contains a set of related elements which define the recording session. A recording session may contain zero or more communication sessions and/or communication session groups. A communication session represents a call instance; a communication session group represents a related group of communication sessions. A recording session is composed of a sequence of complex element types. Not all element types are required to describe a recording session initiated from the Oracle Communications Session Border Controller. The recording session XML schema defines the following element types:
- dataMode - partial or complete metadata description (required)
- group - a collection of related communication sessions
- session - a single communication session of two or more participants (required)
- participant - a SIP endpoint representation (required)
- stream - a media stream
- extensiondata - application specific data outside of the SIPREC scope.
The recording agent generates dataMode, session, participant, and stream elements. Extension data is attached to other elements within the metadata through the use of the parent attribute. The recording metadata is defined as a sequence of element types; therefore all associations between elements are represented as references to element identifiers.
The state of the metadata within a recording session reflects the state of the communication session(s) which is being recorded. SIPREC implements stop-times and reason codes when communication sessions end within a recording session. Once a communication session, participant, or media stream has been marked as 'stopped' and accepted by the SRS, the metadata item is removed from the current metadata state. In addition, media lines within the SDP or the recording session may be re-used/re-labeled for reuse if new communication sessions and media streams are created within the recording session.
The XML schema for the recording metadata is defined in the IETF draft RFC draft-ram-siprec-metadata-format-02 [7].
The ACLI command to show recorded metadata is show rec. For more information on this command see the section, Show rec.
Show Commands for Recording Sessions
The Oracle Communications Session Border Controller allows you to utilize the following show commands via the ACLI to display statistical information about recording sessions:
- show rec
- show rec redundancy
Show rec
The show rec command displays the count of all metadata objects in sessions managed by the recording agent. These statistics include metadata monitored over an active period of time and over a lifetime period (where lifetime totals reflect from the last reboot of the Oracle Communications Session Border Controller to the present time). The following example shows the use of this command.
Show rec redundancy
The show rec redundancy command displays information for session recording server statistics when the Oracle Communications Session Border Controller is configured for HA. These statistics include metadata monitored over an active period of time and over a lifetime period (where lifetime totals reflect from the last reboot of the Oracle Communications Session Border Controller to the present time) on both the primary and redundant Oracle Communications Session Border Controller. The following example shows the use of this command.
Inserting SIP Headers into SIPREC Metadata
The SIPREC Extension Data Enhancements SPL provides additional header information in the originating SIP messages metadata sent to the Interactive Session Recorder. With this SPL, you can introduce more options for recording policy decisions when using the SIPREC feature of the Oracle Communications Session Border Controller (SBC). The enhanced metadata also allows for the realm-id to be used as an indicator of the recording account. The SPL also provides configurable values that collect additional header information to store in the metadata.
When the SPL is configured, the SIPREC Extension Data Enhancements SPL is only triggered upon INVITE/UPDATE requests, and stores the additional header information in the metadata that is sent to the Interactive Session Recorder (ISR). Metadata is a XML MIME attachment that describes recording details to the ISR.
By default, the Extension-Headers SPL option collects only the Request-URI in a received INVITE. You can store additional header information by configuring the SPL with additional attributes in the spl-options under the global spl-config. The values must be in a comma separated list enclosed in double quotation marks. For example:
Extension-Headers="P-Asserted-Identity,Diversion"This configuration of the Extension-Headers option adds the originating Request-URI along with all P-Asserted-Identity and Diversion-Headers into the participant section of the metadata.
You can configure the LRE-Identifier SPL option to add an identifier of the logical remote entity (LRE) that triggered the recording to the <apkt:realm> element of the extension metadata. When configured with a value added, the value appears in place of the identifier. When configured without a value, the identifier of the logical remote entity is used. For example, session-agent will be the hostname, realm-config will be the realm, and sip-interface will be the realm name.
Note:
Both options are required for the SPL to function properly.Sample Metadata
The sample below shows metadata with new extension data added by the SIPREC Extension Data Enhancements SPL:
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns="urn:ietf:params:xml:ns:recording">
<datamode>complete</datamode>
<session id="BYiC7uSZQGN3VQdzWI1HWw==">
<associate-time>2012-06-26T13:44:13</associate-time>
</session>
<participant id="hq18GJs3TtJdhjPsfPNV8A==" session="BYiC7uSZQGN3VQdzWI1HWw==">
<nameID aor="sip:sipp@192.168.10.1">
<name>sipp</name>
</nameID>
<send>aD50KX+LTvxNzASg+/GQTg==</send>
<associate-time>2012-06-26T13:44:13</associate-time>
<extensiondata xmlns:apkt="http://acmepacket.com/siprec/extensiondata">
<apkt:callingParty>true</apkt:callingParty>
<apkt:request-uri>sip:service@192.168.101.13:5060 </apkt:request-uri>
<apkt:in-realm>net192</apkt:in-realm>
<apkt:header label="P-Asserted-Identity">
<value>sip:mike@example.com</value>
<value>sip:bob@example.org</value>
</apkt:header>
<apkt:header label="Diversion">
<value><sip:jojo@example1.com>;happy=days;green=envy</value>
<value><sip:bebe@example2.net>;green=monster;go=carts</value>
<value><tel:+8675309;night=mare>;gear=head;green=monitor</value>
</apkt:header>
</extensiondata>
</participant>
<participant id="Ki6WEUi4TPRUPLtEaEhA7Q==" session="BYiC7uSZQGN3VQdzWI1HWw==">
<nameID aor="sip:service@192.168.101.13">
<name>sut</name>
</nameID>
<send>f9NDVhyMTul+ePlM2SceQA==</send>
<associate-time>2012-06-26T13:44:13</associate-time>
<extensiondata xmlns:apkt="http://acmepacket.com/siprec/extensiondata">
<apkt:callingParty>false</apkt:callingParty>
</extensiondata>
</participant>
<stream id="aD50KX+LTvxNzASg+/GQTg==" session="BYiC7uSZQGN3VQdzWI1HWw==">
<label>65804</label>
<mode>separate</mode>
<associate-time>2012-06-26T13:44:13</associate-time>
</stream>
<stream id="f9NDVhyMTul+ePlM2SceQA==" session="BYiC7uSZQGN3VQdzWI1HWw==">
<label>65805</label>
<mode>separate</mode>
<associate-time>2012-06-26T13:44:13</associate-time>
</stream>
</recording>Configure SIP Headers for SIPREC Metadata
To get more detailed information about a recorded session, you can add more SIP headers within the SIPREC metadata by way of the Extension-Headers option. The default behavior stores only the Request-URI and realm-id.
You must configure the Extension-Headers option at the global level under spl-config because the session-agent, realm-config, and sip-interface configurations do not recognize the option. The first time you configure one or more extension headers, you need only to save and activate the configuration for the system to recognize the extension headers. When you modify the existing SPL extension header list you need to save and activate the configuration, and reboot the system for the changes to take effect. Real Time Configuration (RTC) does not apply to extension header options.