# SIPREC call recording interface Canonical: https://warmtransfer.net/knowledge/siprec-recording Last verified: 2026-09-25 RFC 7866 (Session Recording Protocol) is a Standards Track RFC published in May 2016[^46]. RFC 7865 (SIP Recording Metadata) is a Standards Track RFC published in May 2016, and the SIPREC architecture in RFC 7245 defines the Session Recording Client (SRC) and Session Recording Server (SRS)[^32][^26][^24][^25]. ## SIPREC Architecture and Protocol Mechanics The SIPREC architecture defined in RFC 7245 establishes that the recording session is independent of the recorded communication session at both the SIP dialog level and the session level[^23]. RFC 7245, the SIPREC architecture, is an Informational RFC published in May 2014[^26]. An SRC is a SIP UA acting as the source of recorded media, which can be a SIP phone, a media gateway, an SBC, or a media server[^24]. A SIP proxy cannot act as an SRC because it lacks access to the media[^22]. The SRS is a SIP UA operating as a specialised media server or collector that acts as the sink of recorded media[^25]. RFC 6341, Use Cases and Requirements for SIP-Based Media Recording (SIPREC), is an Informational RFC from August 2011 that no later RFC updates or obsoletes[^21]. Under RFC 7866, the SRC initiates the recording session and must include the `+sip.src` feature tag in the Contact URI of the recording session[^44]. The SRC must also include the `siprec` option tag in the `Require` header so that any UA lacking Session Recording Protocol support rejects the INVITE with a 420 (Bad Extension) response[^41]. RFC 7866 permits persistent recording, where a recording session is established in the absence of any communication session[^38]. For media handling, the SRC typically marks each offered media stream with `a=sendonly`, and the SRS normally answers with `a=recvonly` because it typically only receives RTP[^43][^45]. Recording state and preferences can be expressed within SDP: - `a=record` uses values `on`, `off`, and `paused` to signal recording state to recording-aware participants[^39]. - `a=recordpref` uses values `on`, `off`, `pause`, and `nopreference` to communicate participant recording preferences[^40]. Security requirements in RFC 7866 dictate that both the SRC and SRS must support SIP over TLS version 1.2[^47]. Furthermore, the recording session must be at least as secure as the communication session being recorded, including at least the same cipher-suite strength[^42]. ## Metadata Format and Media Types When a SIPREC SIP message carries both an SDP offer and recording metadata, the body must use the `multipart/mixed` content type[^37]. The metadata body part carries the Content-Disposition type `recording-session`[^33]. The SRC can transmit metadata in an INVITE request, in an UPDATE request, or in a 200 response to an offerless INVITE[^36]. RFC 7866 specifies that the SRC SHOULD include a full metadata snapshot in the initial INVITE that establishes the recording session[^34]. The metadata model in RFC 7865 defines Recording Session, Communication Session Group, Communication Session, Participant, and Media Stream classes, as well as CS-RS, Participant-CS, and Participant-Stream association classes[^29]. The metadata XML namespace is `urn:ietf:params:xml:ns:recording:1`[^30]. Within the metadata: - The `` element shows that a participant contributes to a stream, and the `` element indicates that a participant receives it[^31]. - The `associate-time` and `disassociate-time` values are computed by the SRC from when it sees a participant join or leave a communication session[^27]. RFC 7865 names the recording metadata XML document type `application/rs-metadata+xml`[^28]. RFC 9806 (Proposed Standard, June 2025) updates RFC 7866 by replacing every instance of `application/rs-metadata` with `application/rs-metadata+xml`[^48]. RFC 7866 erratum 7987 regarding the missing `+xml` suffix holds the status Held for Document Update[^14]. IANA registers `application/rs-metadata+xml` referencing RFC 7865 and RFC 9806, noting that it replaces the `application/rs-metadata` label used in RFC 7866[^15]. ## Platform Implementations ### Cisco Unified Border Element (CUBE) CUBE acts as a SIPREC SRC under RFC 7245 section 3.1.1 (B2BUA as SRC), forking a copy of the media to the recording server[^11]. CUBE starts the recording session when the original call connects, and forks media after the recording server returns 200 OK[^13]. Operational constraints and behaviors for CUBE include: - Only SIP-to-SIP calls are supported for SIPREC recording[^10]. - SRTP passthrough, SDP pass-through, flow-around, and RTP loopback calls are not supported[^7]. - For SRTP-to-RTP interworked calls, CUBE forks media only from the RTP leg; forking from the SRTP leg is listed as a restriction[^12]. - IPv6-to-IPv6 calls cannot be recorded, nor can IPv6-to-IPv4 calls when the recording server is configured on the IPv6 leg[^4]. - The recorder call leg does not support mid-call renegotiation or supplementary services like hold and resume[^6]. - CUBE sends SIPREC metadata as XML that complies with draft-ietf-siprec-metadata-17, not with the final RFC 7865, and the metadata reflects session changes such as hold, transfer and escalation[^5]. - From IOS XE 17.18.2, if a recorder answers with an inactive SDP direction attribute, CUBE stops sending media packets to that recorder[^3]. - IOS XE 17.18.1a improved CUBE SIP-recording serviceability so that it shows consolidated information on forked and associated anchor call legs[^8]. - CUBE SIPREC sessions are verified with `show voip recmsp session` (including `detail call-id` and `detail forked call-id` variants), `show voip rtp forking`, and `show voip rtp connections`[^9]. ### Oracle Enterprise SBC The Oracle Enterprise SBC functions as the SIPREC Session Recording Client, initiating recording dialogs to SRSs and replicating media from communication sessions[^18]. It supports only selective recording (one recording session per communication session) and does not support persistent recording[^16]. SRSs can be grouped in a `session-recording-group` with hunt, round-robin, least-busy, or lowest-sustained-rate selection, and can send recording dialogs to several SRSs at once for redundancy[^19]. The Oracle Enterprise SBC supports SIPREC on any combination of SRTP and RTP on ingress, egress, and recording legs; its SDES profile must list both `AES_CM_128_HMAC_SHA1_80` and `AES_CM_128_HMAC_SHA1_32`[^20]. If ingress and egress sides point at the same SRS or session recording group, the Oracle Enterprise SBC records the media only once[^17]. ### AudioCodes Mediant SBC An AudioCodes Mediant SBC acts as the SIPREC SRC and sends recording sessions to a third-party SRS for RTP or SRTP calls that traverse it[^2]. On AudioCodes Mediant SBCs, SIPREC is available only with a License Key that sets the maximum number of recording sessions, and recording video in audio-video calls uses additional SBC media channel resources[^1]. ## Cloud Service Recording Architectures ### Webex Calling When a Webex Calling call is recorded, dual streams are sent to the call recording provider[^56]. Recording modes are On-Demand, Always, Always with Pause/Resume, and Never, with Never being the default[^58]. When an announcement plays at recording start, stop, pause, or resume, Webex Calling tells the call recording provider in a SIPREC metadata message[^59]. Webex Calling users and workspaces need a Professional licence to record with a third-party provider; Standard-licensed users can record only with Webex as the provider[^57]. ### Microsoft Teams Teams compliance recording is delivered by certified third-party partners whose recording bots use Microsoft Graph APIs, an application instance, and a compliance recording policy[^51]. Microsoft supports Teams compliance recording only with solutions from listed certified partners and may reject support cases that involve non-certified solutions[^55]. A Teams compliance recorder bot must run on a Windows virtual machine deployed in Azure[^49]. Teams compliance recording is not supported for E911 emergency calls, for users in Survivable Branch Appliance mode, or for PSTN calls of users in India[^53]. Microsoft's comparison table lists third-party compliance recording as not supporting audio-only recording and not supporting participant consent, although participant notification is enforced[^50]. Teams Compliance Recording for Call Queues records all agent-answered inbound call queue calls without per-agent policy, requires conference mode, and does not cover agents' outbound calls, which need a user compliance recording policy[^52]. ## See also - See also [CUBE troubleshooting commands](https://warmtransfer.net/knowledge/cube-troubleshooting-toolkit). - See also [SDP offer answer and codec negotiation](https://warmtransfer.net/knowledge/sdp-offer-answer). - See also [SRTP and media encryption negotiation](https://warmtransfer.net/knowledge/srtp-media-security). ## Applicability Applies to: IETF SIPREC, IANA SIPREC, Cisco CUBE, Oracle Enterprise Session Border Controller, AudioCodes Mediant SBC, Cisco Webex Calling, and Microsoft Teams. Deployments: on-premises, multi-tenant, and any. Sources checked 2026-09-25. Directional SDP attribute handling for SIPREC responses applies from Cisco IOS XE 17.18.2[^3]. Enhanced serviceability in SIP recording applies from Cisco IOS XE 17.18.1a[^8]. Teams compliance recording excludes E911 emergency calls, users in Survivable Branch Appliance mode, and PSTN calls of users in India[^53]. ## What remains uncertain SBC-side SIPREC recording of Teams Direct Routing calls (SBC as SRC on the DR trunk) is not covered by the sources below. Call recording consent law (one-party vs all-party) as it applies to SIPREC deployments is not covered by the sources below. CUCM built-in-bridge and network-based recording versus standards SIPREC from CUBE is not covered by the sources below. Recording options and SIPREC use in Webex Calling Dedicated Instance is not covered by the sources below. Webex Calling SIPREC interface specification for recording providers (metadata profile transport and security) is not covered by the sources below. Per-platform concurrent SIPREC session capacity for CUBE (ISR and Catalyst 8000 and CSR) is not covered by the sources below. Teams compliance recording for call queues setup steps and cmdlets is not covered by the sources below. AudioCodes SIPREC behaviour in User's Manual 7.6 (standards list and REST on-demand SIPREC and SRTP) is not covered by the sources below. ## Sources [^1]: On AudioCodes Mediant SBCs, SIPREC is available only with a License Key that sets the maximum number of recording sessions, and recording video in audio-video calls uses additional SBC media channel resources. Source: [SIPREC Overview (Mediant 500 SBC User's Manual, Version 7.4)](https://techdocs.audiocodes.com/session-border-controller-sbc/mediant-500-sbc/user-manual/version-740/Content/UM/siprec-overview.htm), SIPREC Overview, licensing note and video note. Checked 2026-09-25. [^2]: An AudioCodes Mediant SBC acts as the SIPREC SRC and sends recording sessions to a third-party SRS for RTP or SRTP calls that traverse it. Source: [SIPREC Overview (Mediant 500 SBC User's Manual, Version 7.4)](https://techdocs.audiocodes.com/session-border-controller-sbc/mediant-500-sbc/user-manual/version-740/Content/UM/siprec-overview.htm), SIPREC Overview, opening paragraphs. Checked 2026-09-25. [^3]: From IOS XE 17.18.2, if a recorder answers with an inactive SDP direction attribute, CUBE stops sending media packets to that recorder. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards: SIP Forking](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-sip-rec-recorder.html), SIP Forking > Feature Information: Directional attribute compliance for SIPREC responses. Checked 2026-09-25. [^4]: CUBE does not support SIPREC recording of IPv6-to-IPv6 calls, nor of IPv6-to-IPv4 calls when the recording server is configured on the IPv6 leg. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards: SIP Forking](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-sip-rec-recorder.html), SIP Forking > Restrictions for SIPREC. Checked 2026-09-25. [^5]: CUBE sends SIPREC metadata as XML that complies with draft-ietf-siprec-metadata-17, not with the final RFC 7865, and the metadata reflects session changes such as hold, transfer and escalation. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards: SIP Forking](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-sip-rec-recorder.html), SIP Forking > Metadata. Checked 2026-09-25. [^6]: Mid-call renegotiation and supplementary services such as hold and resume are not supported on the CUBE recorder call leg. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards: SIP Forking](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-sip-rec-recorder.html), SIP Forking > Restrictions for SIPREC. Checked 2026-09-25. [^7]: CUBE does not support SIPREC recording of SRTP passthrough calls, SDP pass-through calls, flow-around calls or RTP loopback calls. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards: SIP Forking](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-sip-rec-recorder.html), SIP Forking > Restrictions for SIPREC. Checked 2026-09-25. [^8]: IOS XE 17.18.1a improved CUBE SIP-recording serviceability so that it shows consolidated information on forked and associated anchor call legs. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards: SIP Forking](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-sip-rec-recorder.html), SIP Forking > Feature Information: Enhanced support for serviceability in SIP recording. Checked 2026-09-25. [^9]: CUBE SIPREC sessions are verified with show voip recmsp session (including detail call-id and detail forked call-id variants), show voip rtp forking and show voip rtp connections. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards: SIP Forking](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-sip-rec-recorder.html), SIP Forking > Verifying SIPREC. Checked 2026-09-25. [^10]: CUBE SIPREC recording is not supported for calls that do not use SIP; only SIP-to-SIP call flows are recorded. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards: SIP Forking](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-sip-rec-recorder.html), SIP Forking > Restrictions for SIPREC. Checked 2026-09-25. [^11]: CUBE acts as the SIPREC Session Recording Client, in line with RFC 7245 section 3.1.1 (B2BUA as SRC), and forks a copy of the media to the recording server. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards: SIP Forking](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-sip-rec-recorder.html), SIP Forking > Overview / Information About SIPREC. Checked 2026-09-25. [^12]: For SRTP-to-RTP interworked calls, CUBE supports forking only from the RTP leg; forking from the SRTP leg is listed as a restriction. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards: SIP Forking](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-sip-rec-recorder.html), SIP Forking > Restrictions for SIPREC. Checked 2026-09-25. [^13]: CUBE starts the recording session when the original call connects, and forks media after the recording server returns 200 OK. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards: SIP Forking](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-sip-rec-recorder.html), SIP Forking > Information About SIPREC / call flow. Checked 2026-09-25. [^14]: RFC 7866 erratum 7987, a Technical erratum on the missing +xml suffix of the metadata media type, has status Held for Document Update. Source: [RFC Errata for RFC 7866](https://www.rfc-editor.org/errata/rfc7866), Errata ID 7987. Checked 2026-09-25. [^15]: IANA registers application/rs-metadata+xml with references to RFC 7865 and RFC 9806, noting that it replaces the application/rs-metadata label used in RFC 7866. Source: [Media type registration: application/rs-metadata+xml](https://www.iana.org/assignments/media-types/application/rs-metadata+xml), Registration template: Published specification and Interoperability considerations fields. Checked 2026-09-25. [^16]: The Oracle Enterprise SBC supports only selective SIPREC recording (one recording session per communication session) and does not support persistent recording. Source: [Configuring SIPREC (Oracle Enterprise Session Border Controller Call Traffic Monitoring Guide, Release 8.3.0)](https://docs.oracle.com/en/industries/communications/enterprise-session-border-controller/8.3.0/monitoring/configuring-siprec.html), Configuring SIPREC > session-recording-server > mode. Checked 2026-09-25. [^17]: If the ingress and egress sides point at the same SRS or session recording group, the Oracle Enterprise SBC records the media only once. Source: [Configuring SIPREC (Oracle Enterprise Session Border Controller Call Traffic Monitoring Guide, Release 8.3.0)](https://docs.oracle.com/en/industries/communications/enterprise-session-border-controller/8.3.0/monitoring/configuring-siprec.html), Configuring SIPREC > ingress and egress recording. Checked 2026-09-25. [^18]: The Oracle Enterprise SBC acts as the SIPREC Session Recording Client, initiating recording dialogs to SRSs and replicating media from communication sessions. Source: [Configuring SIPREC (Oracle Enterprise Session Border Controller Call Traffic Monitoring Guide, Release 8.3.0)](https://docs.oracle.com/en/industries/communications/enterprise-session-border-controller/8.3.0/monitoring/configuring-siprec.html), Configuring SIPREC > overview. Checked 2026-09-25. [^19]: The Oracle Enterprise SBC can group SRSs in a session-recording-group with round-robin, hunt, least-busy or lowest-sustained-rate selection, and can send recording dialogs to several SRSs at once for redundancy. Source: [Configuring SIPREC (Oracle Enterprise Session Border Controller Call Traffic Monitoring Guide, Release 8.3.0)](https://docs.oracle.com/en/industries/communications/enterprise-session-border-controller/8.3.0/monitoring/configuring-siprec.html), Configuring SIPREC > session-recording-group. Checked 2026-09-25. [^20]: The Oracle Enterprise SBC supports SIPREC on any combination of SRTP and RTP on ingress, egress and recording legs; its SDES profile must list both AES_CM_128_HMAC_SHA1_80 and AES_CM_128_HMAC_SHA1_32. Source: [Configuring SIPREC (Oracle Enterprise Session Border Controller Call Traffic Monitoring Guide, Release 8.3.0)](https://docs.oracle.com/en/industries/communications/enterprise-session-border-controller/8.3.0/monitoring/configuring-siprec.html), Configuring SIPREC > SRTP support. Checked 2026-09-25. [^21]: RFC 6341, Use Cases and Requirements for SIP-Based Media Recording (SIPREC), is an Informational RFC from August 2011 that no later RFC updates or obsoletes. Source: [RFC 6341: Use Cases and Requirements for SIP-Based Media Recording (SIPREC)](https://www.rfc-editor.org/info/rfc6341), RFC Editor info page: Status, Date, Updated by and Obsoleted by fields. Checked 2026-09-25. [^22]: RFC 7245 treats a SIP proxy as unable to act as an SRC because it has no access to the media. Source: [RFC 7245: An Architecture for Media Recording Using the Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc7245.html), Section 3.1.3. Checked 2026-09-25. [^23]: In the SIPREC architecture the recording session is independent of the recorded communication session at both the SIP dialog level and the session level. Source: [RFC 7245: An Architecture for Media Recording Using the Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc7245.html), Section 3.2. Checked 2026-09-25. [^24]: RFC 7245 defines the Session Recording Client as a SIP UA that is the source of recorded media, and says it can be a SIP phone, a media gateway, an SBC or a media server. Source: [RFC 7245: An Architecture for Media Recording Using the Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc7245.html), Section 2 (Definitions), Session Recording Client. Checked 2026-09-25. [^25]: RFC 7245 defines the Session Recording Server as a SIP UA that is a specialised media server or collector acting as the sink of recorded media. Source: [RFC 7245: An Architecture for Media Recording Using the Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc7245.html), Section 2 (Definitions), Session Recording Server. Checked 2026-09-25. [^26]: RFC 7245, the SIPREC architecture, is an Informational RFC published in May 2014. Source: [RFC 7245: An Architecture for Media Recording Using the Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc7245.html), RFC 7245 header block. Checked 2026-09-25. [^27]: The participant associate-time and disassociate-time metadata values are computed by the SRC from when it sees a participant join or leave a communication session. Source: [RFC 7865: Session Initiation Protocol (SIP) Recording Metadata](https://www.rfc-editor.org/rfc/rfc7865.html), Section 6.6.1. Checked 2026-09-25. [^28]: RFC 7865 names the recording metadata XML document type application/rs-metadata+xml. Source: [RFC 7865: Session Initiation Protocol (SIP) Recording Metadata](https://www.rfc-editor.org/rfc/rfc7865.html), Section 5 (metadata format overview sentence naming the XML document type). Checked 2026-09-25. [^29]: The RFC 7865 metadata model consists of Recording Session, Communication Session Group, Communication Session, Participant and Media Stream classes, plus CS-RS, Participant-CS and Participant-Stream association classes. Source: [RFC 7865: Session Initiation Protocol (SIP) Recording Metadata](https://www.rfc-editor.org/rfc/rfc7865.html), Section 4 (metadata model). Checked 2026-09-25. [^30]: The SIPREC metadata XML namespace is urn:ietf:params:xml:ns:recording:1. Source: [RFC 7865: Session Initiation Protocol (SIP) Recording Metadata](https://www.rfc-editor.org/rfc/rfc7865.html), Section 5.1.1. Checked 2026-09-25. [^31]: In RFC 7865 metadata the send element indicates a participant contributes to a stream and the recv element indicates a participant receives it. Source: [RFC 7865: Session Initiation Protocol (SIP) Recording Metadata](https://www.rfc-editor.org/rfc/rfc7865.html), Section 6.8.1. Checked 2026-09-25. [^32]: RFC 7865 (SIP Recording Metadata) is a Standards Track RFC published in May 2016. Source: [RFC 7865: Session Initiation Protocol (SIP) Recording Metadata](https://www.rfc-editor.org/rfc/rfc7865.html), RFC 7865 header block. Checked 2026-09-25. [^33]: The SIPREC metadata body part carries Content-Disposition type recording-session. Source: [RFC 7866: Session Recording Protocol](https://www.rfc-editor.org/rfc/rfc7866.html), Section 9. Checked 2026-09-25. [^34]: RFC 7866 says the SRC SHOULD (not MUST) include a full metadata snapshot in the initial INVITE that establishes the recording session. Source: [RFC 7866: Session Recording Protocol](https://www.rfc-editor.org/rfc/rfc7866.html), Section 9.1. Checked 2026-09-25. [^35]: RFC 7866 as published names the SIPREC metadata content type application/rs-metadata, without the +xml suffix (disputed). Source: [RFC 7866: Session Recording Protocol](https://www.rfc-editor.org/rfc/rfc7866.html), Section 9. Checked 2026-09-25. [^36]: The SRC can send recording metadata in an INVITE request, in an UPDATE request, or in a 200 response to an offerless INVITE. Source: [RFC 7866: Session Recording Protocol](https://www.rfc-editor.org/rfc/rfc7866.html), Section 9.1. Checked 2026-09-25. [^37]: When a SIPREC SIP message carries both an SDP offer and recording metadata, the body must use content type multipart/mixed. Source: [RFC 7866: Session Recording Protocol](https://www.rfc-editor.org/rfc/rfc7866.html), Section 9.1. Checked 2026-09-25. [^38]: RFC 7866 permits persistent recording, in which a recording session is established in the absence of any communication session. Source: [RFC 7866: Session Recording Protocol](https://www.rfc-editor.org/rfc/rfc7866.html), Section 10. Checked 2026-09-25. [^39]: RFC 7866 defines the SDP attribute a=record with values on, off and paused to indicate recording state to recording-aware participants. Source: [RFC 7866: Session Recording Protocol](https://www.rfc-editor.org/rfc/rfc7866.html), Section 7.1.2. Checked 2026-09-25. [^40]: RFC 7866 defines the SDP attribute a=recordpref with values on, off, pause and nopreference, which a participant uses to express a recording preference. Source: [RFC 7866: Session Recording Protocol](https://www.rfc-editor.org/rfc/rfc7866.html), Section 7.3.2. Checked 2026-09-25. [^41]: An SRC must include the siprec option tag in the Require header when initiating a recording session so that a UA without Session Recording Protocol support rejects the INVITE with 420 (Bad Extension). Source: [RFC 7866: Session Recording Protocol](https://www.rfc-editor.org/rfc/rfc7866.html), Section 6.1.1. Checked 2026-09-25. [^42]: RFC 7866 requires the recording session to be at least as secure as the communication session being recorded, including at least the same cipher-suite strength. Source: [RFC 7866: Session Recording Protocol](https://www.rfc-editor.org/rfc/rfc7866.html), Section 12. Checked 2026-09-25. [^43]: In a recording session the SRC typically marks each offered media stream a=sendonly. Source: [RFC 7866: Session Recording Protocol](https://www.rfc-editor.org/rfc/rfc7866.html), Section 7.1.1. Checked 2026-09-25. [^44]: Under RFC 7866 the Session Recording Client must include the +sip.src feature tag in the Contact URI of the recording session. Source: [RFC 7866: Session Recording Protocol](https://www.rfc-editor.org/rfc/rfc7866.html), Section 6.1.1. Checked 2026-09-25. [^45]: The SRS normally answers each recording media stream with a=recvonly because it typically only receives RTP from the SRC. Source: [RFC 7866: Session Recording Protocol](https://www.rfc-editor.org/rfc/rfc7866.html), Section 7.1.1. Checked 2026-09-25. [^46]: RFC 7866 (Session Recording Protocol) is a Standards Track RFC published in May 2016. Source: [RFC 7866: Session Recording Protocol](https://www.rfc-editor.org/rfc/rfc7866.html), RFC 7866 header block (Category: Standards Track; May 2016). Checked 2026-09-25. [^47]: RFC 7866 requires both SRC and SRS to support SIP over TLS version 1.2. Source: [RFC 7866: Session Recording Protocol](https://www.rfc-editor.org/rfc/rfc7866.html), Section 12. Checked 2026-09-25. [^48]: RFC 9806 (Proposed Standard, June 2025) updates RFC 7866 by replacing every instance of application/rs-metadata with application/rs-metadata+xml. Source: [RFC 9806: Updates to SIP-Based Media Recording (SIPREC) to Correct Metadata Media Type](https://www.rfc-editor.org/rfc/rfc9806.html), Section 2; RFC Editor info page 'Updates: RFC 7866'. Checked 2026-09-25. [^49]: A Teams compliance recorder bot must run on a Windows virtual machine deployed in Azure. Source: [Microsoft Teams compliance recording (third-party)](https://learn.microsoft.com/en-us/microsoftteams/teams-recording-compliance), Recorder development, requirements list. Checked 2026-09-25. [^50]: Microsoft's comparison table lists third-party compliance recording as not supporting audio-only recording and not supporting participant consent, although participant notification is enforced. Source: [Introduction to recording Microsoft Teams calls, meetings, and events](https://learn.microsoft.com/en-us/microsoftteams/teams-recording-policy), Overview, convenience vs compliance comparison table (rows: Participant consent supported; Audio only supported; Participant notification enforced). Checked 2026-09-25. [^51]: Teams compliance recording is delivered by certified third-party partners whose recording bots use Microsoft Graph APIs, an application instance and a compliance recording policy. Source: [Microsoft Teams compliance recording (third-party)](https://learn.microsoft.com/en-us/microsoftteams/teams-recording-compliance), Recorder development. Checked 2026-09-25. [^52]: Teams Compliance Recording for Call Queues records all agent-answered inbound call queue calls without per-agent policy, requires conference mode, and does not cover agents' outbound calls, which need a user compliance recording policy. Source: [Microsoft Teams compliance recording (third-party)](https://learn.microsoft.com/en-us/microsoftteams/teams-recording-compliance), Considerations > Call queues (Compliance Recording for Call Queues). Checked 2026-09-25. [^53]: Teams compliance recording is not supported for E911 emergency calls, for users in Survivable Branch Appliance mode, or for PSTN calls of users in India. Source: [Microsoft Teams compliance recording (third-party)](https://learn.microsoft.com/en-us/microsoftteams/teams-recording-compliance), Supported compliance recording capabilities > Considerations. Checked 2026-09-25. [^54]: Microsoft's native Teams compliance recording interface is a Graph-based recorder bot rather than SIPREC; neither Microsoft recording overview page mentions SIPREC (inferred). Source: [Microsoft Teams compliance recording (third-party)](https://learn.microsoft.com/en-us/microsoftteams/teams-recording-compliance), Whole page (Recorder development section; no SIPREC mention); also ms-learn-teams-recording-policy whole page. Checked 2026-09-25. [^55]: Microsoft supports Teams compliance recording only with solutions from listed certified partners and may reject support cases that involve non-certified solutions. Source: [Microsoft Teams compliance recording (third-party)](https://learn.microsoft.com/en-us/microsoftteams/teams-recording-compliance), Support boundaries. Checked 2026-09-25. [^56]: When a Webex Calling call is recorded, dual streams are sent to the call recording provider. Source: [Manage call recording for Webex Calling](https://help.webex.com/en-us/article/ilga4/Manage-call-recording-for-Webex-Calling), Call recording behavior. Checked 2026-09-25. [^57]: Webex Calling users and workspaces need a Professional licence to record with a third-party provider; Standard-licensed users can record only with Webex as the provider. Source: [Manage call recording for Webex Calling](https://help.webex.com/en-us/article/ilga4/Manage-call-recording-for-Webex-Calling), Overview. Checked 2026-09-25. [^58]: Webex Calling recording modes are On-Demand, Always, Always with Pause/Resume and Never, and Never is the default. Source: [Manage call recording for Webex Calling](https://help.webex.com/en-us/article/ilga4/Manage-call-recording-for-Webex-Calling), Recording modes / Enable call recording for Webex Calling users and workspaces. Checked 2026-09-25. [^59]: When an announcement plays at recording start, stop, pause or resume, Webex Calling tells the call recording provider in a SIPREC metadata message. Source: [Manage call recording for Webex Calling](https://help.webex.com/en-us/article/ilga4/Manage-call-recording-for-Webex-Calling), Call recording behavior; also Enable call recording for Webex Calling users and workspaces. Checked 2026-09-25. [^60]: The two clouds expose different recording interfaces to partners: Webex Calling sends call media to recording providers over SIPREC, while Teams compliance recording has partners run Graph-based bots in Azure; so a SIPREC-only recorder can integrate natively with the first but not the second (inferred). Source: [Microsoft Teams compliance recording (third-party)](https://learn.microsoft.com/en-us/microsoftteams/teams-recording-compliance), Recorder development; compared with cisco-help-ilga4-webex-calling-recording Call recording behavior. Checked 2026-09-25.