AudioCodes Mediant 3000 User Manual page 212

Gateway & enterprise sbc, family of media gateways & session border controllers
Hide thumbs Also See for Mediant 3000:
Table of Contents

Advertisement

The device can record calls between two IP Groups, or between an IP Group and a Trunk
Group (for Gateway calls). 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. 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/SRTP 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 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-Agent: Mediant /v.6.80A.014
User's Manual
212
Mediant 3000
Document #: LTRT-89738

Advertisement

Table of Contents
loading

Table of Contents