SIPREC interface

The SIPREC interface is not described by the companion OpenAPI specification — it is a media-plane contract established during onboarding. This page is its reference.

Once an Experience Connection is ACTIVE and an Assignment is in place, Alianza initiates SIPREC recording sessions to your Session Recording Server (SRS) for calls involving provisioned users in the assigned account. All SIPREC sessions conform to RFC 7866 and are initiated outbound from Alianza to your SRS endpoint.

Properties

Single origin. Your SRS only needs to accept SIPREC traffic from Alianza's outbound IP addresses, provided during onboarding.
Dual-channel audio. Each recording session carries two separate SRTP streams — one per call participant in a standard two-way call.
Per-user enablement. SIPREC is initiated only for calls involving users provisioned for your Experience.
Best-effort recording. If your SRS is unreachable, the underlying call is not affected.

Network and transport

Item	Detail
Signaling transport	TLS. Alianza outbound IP addresses are provided during onboarding for firewall/allowlist configuration.
Media transport	SRTP.
DNS resolution	Alianza resolves your SRS DNS name per RFC 3263 (NAPTR → SRV → A/AAAA).
Port	Configurable. Default `5061` for TLS.
Authentication	IP allowlisting + TLS. SIP Digest authentication is also supported and recommended.
Failover	On timeout or `503`, Alianza tries up to seven additional resolved targets. The underlying call is not affected by SIPREC failures.

Allowlisting: Alianza will provide its outbound source IPs during onboarding. Allowlist these on your SRS firewall or load balancer.

Digest auth: IP allowlisting plus TLS is the minimum. Digest auth is recommended in addition, especially if your SRS is behind a shared edge.

Failover behaviour: Resolution per RFC 3263 typically yields multiple candidate targets via SRV records. Alianza walks the list on timeout or 503 until a target accepts the INVITE or the list is exhausted. Recording failure does not impact the in-progress call.

INVITE format

Each recording session begins with a SIP INVITE per RFC 7866. The INVITE body is multipart/mixed containing two parts: the SDP offer and the RFC 7866 recording metadata XML (Content-Type: application/rs-metadata+xml).

Example INVITE headers

INVITE sip:recorder@srs.example.com:5061 SIP/2.0
Via: SIP/2.0/TLS 10.191.12.11:5061;branch=z9hG4bK-example
From: <sip:+15551234567@orch.alianza.com>;tag=abc123
To: <sip:recorder@srs.example.com>
Call-ID: SIPREC-session-001@orch.alianza.com
CSeq: 1 INVITE
Contact: <sip:10.191.12.11:5061;transport=tls>
Max-Forwards: 70
Require: SIPREC
X-Alianza-Recording-Session-Id: 550e8400-e29b-41d4-a716-446655440000
Content-Type: multipart/mixed;boundary=SIPREC-boundary

Header	Meaning
`Require: SIPREC`	Identifies this as a SIPREC recording session per RFC 7866.
`X-Alianza-Recording-Session-Id`	A stable UUID that persists across SIPREC session segments caused by call transfer. Use this to group related recording segments into a single logical call record. See Call transfer and segments.

Example SDP offer

v=0
o=orch 1 1 IN IP4 10.191.12.11
s=-
c=IN IP4 10.191.12.11
t=0 0
m=audio 34318 RTP/SAVP 8 101
a=rtpmap:8 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=ptime:20
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:<key>
a=label:1
a=sendonly
m=audio 34320 RTP/SAVP 8 101
a=rtpmap:8 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=ptime:20
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:<key>
a=label:2
a=sendonly

Two m=audio lines — dual-channel, one stream per participant. The recording metadata XML maps stream labels to participants via <participantstreamassoc>. Do not assume a fixed label-to-role mapping; always use the XML to determine which stream belongs to which participant.
SRTP with AES_CM_128_HMAC_SHA1_80.
Codec: PCMU (G.711 μ-law) plus telephone-event (DTMF).
sendonly — Alianza sends media to your SRS; no media is expected back.

Sub-pages

Recording metadata — RFC 7866 XML body and Alianza extensions.
Call transfer and segments — what happens when calls transfer.