AudioCodes Mediant 500 E-SBC User Manual page 192

The device can record calls between two IP Groups. The type of calls to record can be
specified by source and/or destination prefix number or SIP Request-URI, as well as by call
initiator. The side ("leg") on which the recording is done must be specified. This recording
leg must be one that is interfacing with one of the IP Groups. Specifying the leg is
important as it determines the various call media attributes of the recorded RTP (or SRTP)
such as coder type.
The device can also record SRTP calls and send it to the SRS in SRTP. This applies to
Gateway and SBC calls. In such scenarios, the SRTP is used on the IP leg for Gateway
calls, or on one of the IP legs for SBC calls. For an SBC RTP-SRTP session, the recorded
IP Group in the SIP Recording Routing table must be set to the RTP leg if recording is
required to be RTP, or set to the SRTP leg if recording is required to be SRTP.
For SBC calls, the device can also be located between an SRS and an SRC and act as an
RTP-SRTP translator. In such a setup, the device receives SIP recording sessions (as a
server) from the SRC and translates SRTP media to RTP, or vice versa, and then forwards
the recording to the SRS in the translated media format.
The device initiates a recording session by sending an INVITE message to the SRS when
the recorded call is connected. The SIP From header contains the identity of the SRC and
the To header contains the identity of the SRS. The SDP in the INVITE contains:

Two 'm=' lines that represent the two RTP/SRTP streams (Rx and Tx).

Two 'a=label:' lines that identify the streams.

XML body (also referred to as metadata) that provides information on the participants
of the call session:
•
<group id>: Logging Session ID (displayed as [SID:nnnnn] in Syslog), converted
from decimal to hex. This number remains the same even if the call is forwarded
or transferred. This is important for recorded calls.
•
<session id>: Originally recorded Call-ID, converted from decimal to hex.
•
<group-ref>: same as <group id>.
•
<participant id>: SIP From / To user.
•
<nameID aor>: From/To user@host.
•
<send> and <recv>: ID's for the RTP/SRTP streams in hex - bits 0-31 are the
same as group, bits 32-47 are the RTP port.
•
<stream id>: Same as <send> for each participant.
•
<label>: 1 and 2 (same as in the SDP's 'a=label:' line).
The SRS can respond with 'a=recvonly' for immediate recording or 'a=inactive' if recording
is not yet needed, and send re-INVITE at any later time with the desired RTP/SRTP mode
change. If a re-INVITE is received in the original call (e.g. when a call is on hold), the
device sends another re-INVITE with two 'm=' lines (but without metadata) to the SRS with
the updated RTP/SRTP data. If the recorded leg uses SRTP, the device can send the
media streams to the SRS as SRTP; otherwise, the media streams are sent as RTP to the
SRS.
Below is an example of an INVITE sent by the device to an SRS:
INVITE sip:VSRP@1.9.64.253 SIP/2.0
Via: SIP/2.0/UDP 192.168.241.44:5060;branch=z9hG4bKac505782914
Max-Forwards: 10
From: <sip:192.168.241.44>;tag=1c505764207
To: <sip:VSRP@1.9.64.253>
Call-ID: 505763097241201011157@192.168.241.44
CSeq: 1 INVITE
Contact: <sip:192.168.241.44:5060>;src
Supported: replaces,resource-priority
Allow:
REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUB
SCRIBE,UPDATE
Require: siprec
User's Manual 192
Mediant 500 E-SBC
Document #: LTRT-10427