Uniphore Customer Portal

To provide a secure SIP interface, TLS and DTLS are supported as SIP transports. See SIP RAM Configuration for more information on how to set the enabled SIP transports. The following protocol versions are supported. Previous insecure protocol versions are not supported.

SIPS URIs are supported, but not required with either TLS or DTLS transports.

The cipher suites (listed below) are supported in order of preference. On first start with either TLS or DTLS transports enabled, the Diffie-Hellman (DH) parameters are automatically generated. This only happens once on first start but takes several minutes to complete. The OpenSSL command line window must not be closed during this operation.

Secure RTP operates in three modes:

The following cipher suites are supported in order of preference.

SRTP data is stored in its encrypted form. This is for performance reasons as cryptographic operations i.e. decryption, are slow. The SRTP keys are stored alongside the SRTP data.

Session Parameters

The following SDES session parameters from RFC 4568 are supported. The far end may use them to override the session defaults. These overrides will be honoured by the Collector.

Secure RTCP

If SRTP is in use, you can select whether to expect RTCP to be secure (SRTCP) as well (see [SRTCP]UseSRTCPWhenSRTP in RTP Collector Configuration). Receiver Reports transmitted will be secured using SRTCP and the negotiated keys.

This integration uses the SIP RAM’s SIPREC interpreter to ensure that the SIPREC metadata and call audio is correctly captured by the Collector. In order to use the interpreter, the SIP INVITE message sent from the SIP UAC (SIP User Agent Client) must meet the following criteria (as per RFC 7866 section 6.1.1) to establish a SIPREC recording session:

If this criteria is not met, the SIP INVITE message will be processed as though it is a basic SIP session.

For SIPREC sessions, call recordings are not started based on the receipt of a SIP INVITE message. This is achieved using the recording metadata, see Recording Metadata below.

Recording metadata must conform to the schema defined in RFC 7865. The SRS accepts capturing metadata bodies with either of the following content types contained in the SIP INVITE (multipart), UPDATE, and BYE messages:

Capturing metadata bodies may be either complete or partial updates. Provided the initial metadata body is complete, subsequent metadata bodies may be partial. Complete metadata bodies will replace the copy of the metadata held by the SRS. Partial metadata bodies will update the copy of the metadata held by the SRS.

To be viable to record, the metadata must contain at least one participant. Each participant must have at least one participant-session association i.e a person entering a call.

Receipt of a SIP BYE message implies that all call recordings started through recording metadata should be ended.

The following is an example of a complete recording metadata body.

<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
  <datamode>complete</datamode>
  <group group_id="7+OTCyoxTmqmqyA/1weDAg==">
    <associate-time>2010-12-16T23:41:07Z</associate-time>
  </group>
  <session session_id="hVpd7YQgRW2nD22h7q60JQ==">
    <group-ref>7+OTCyoxTmqmqyA/1weDAg==</group-ref>
  </session>
  <participant participant_id="srfBElmCRp2QB23b7Mpk0w==">
    <nameID aor="sip:bob@biloxi.com">
      <name xml:lang="en">Bob</name>
    </nameID>
  </participant>
  <participant participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
    <nameID aor="sip:Paul@biloxi.com">
      <name xml:lang="en">Paul</name>
    </nameID>
  </participant>
  <stream
      stream_id="UAAMm5GRQKSCMVvLyl4rFw=="
      session_id="hVpd7YQgRW2nD22h7q60JQ==">
    <label>1</label>
  </stream>
  <stream
      stream_id="i1Pz3to5hGk8fuXl+PbwCw=="
      session_id="hVpd7YQgRW2nD22h7q60JQ==">
    <label>2</label>
  </stream>
  <sessionrecordingassoc session_id="hVpd7YQgRW2nD22h7q60JQ==">
  <associate-time>2010-12-16T23:41:07Z</associate-time>
  </sessionrecordingassoc>
  <participantsessionassoc
      participant_id="srfBElmCRp2QB23b7Mpk0w=="
      session_id="hVpd7YQgRW2nD22h7q60JQ==">
    <associate-time>2010-12-16T23:41:07Z</associate-time>
  </participantsessionassoc>
  <participantsessionassoc
      participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
      session_id="hVpd7YQgRW2nD22h7q60JQ==">
    <associate-time>2010-12-16T23:41:07Z</associate-time>
  </participantsessionassoc>
  <participantstreamassoc participant_id="srfBElmCRp2QB23b7Mpk0w==">
    <send>i1Pz3to5hGk8fuXl+PbwCw==</send>
    <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
  </participantstreamassoc>
  <participantstreamassoc participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
    <send>UAAMm5GRQKSCMVvLyl4rFw==</send>
    <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
  </participantstreamassoc>
</recording>

The following is an example of a partial recording metadata body.

<?xml version="1.0" encoding="UTF-8"?>
  <recording xmlns='urn:ietf:params:xml:ns:recording:1'>
    <datamode>partial</datamode>
    <participant participant_id="srfBElmCRp2QB23b7Mpk0w==">
      <nameID aor="sip:bob@biloxi.com">
        <name xml:lang="en">Bob</name>
      </nameID>
    </participant>
    <participantsessionassoc
      participant_id="srfBElmCRp2QB23b7Mpk0w=="
      session_id="hVpd7YQgRW2nD22h7q60JQ==">
    <disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
  </participantsessionassoc>
</recording>

A call recording will begin when a participant-session association (<participantsessionassoc>) for a recorded participant does not contain a disassociate time (see Ending a Call Recording) and there is not already a call recording in progress for that participant-session association.

A call recording will end when a participant-session association contains a disassociate time – this is specified in <disassociate-time>, and there is a call recording in progress for that participant-session association.