# Setting up SIPREC forking on CUBE for call recording Systems: Cisco Unified Border Element For Voice engineers who run CUBE between a SIP carrier and Unified CM and need to give a recording server a copy of call audio. Canonical: https://warmtransfer.net/guides/cube-siprec-setup Last verified: 2026-10-01 Cisco describes CUBE SIPREC (SIP Forking) as media recording of RTP streams in compliance with section 3.1.1 of RFC 7245, with CUBE acting as the Session Recording Client[^47]. Unified CM documents 2 further recording methods: in network-based recording the media can be sourced from the phone or from a gateway connected over a SIP trunk, and in IP phone based recording the phone forks 2 media streams to the recording server[^56][^52]. ## Before you start - Cisco lists reachability of the recorders from CUBE as a prerequisite for SIPREC recording[^36]. - CUBE SIPREC recording requires a SIP-to-SIP call flow, and non-SIP calls are not supported[^46]. - For network-based recording, the gateway must connect to Unified CM over a SIP trunk[^68]. - When a gateway is used for recording, Unified Communications Gateway Services must be enabled by configuring Cisco IOS services on the device, then the XMF provider, then verifying[^69]. - To check whether a phone supports recording, run the Cisco Unified Reporting Unified CM Phone Feature List report with Record selected as the feature[^70]. - Each recording session adds 2 calls to the busy hour call completion (BHCC) rate[^71]. - Have the recorder's address, port and transport ready, because Cisco's recorder dial-peer carries a session target with the recorder address or DNS name and a session transport[^32]. - Have the list of CUBE dial-peers that recorded calls match, because Cisco lists an incorrect inbound dial-peer match, where the selected inbound dial-peer has no media-class, as a common SIPREC failure in new deployments[^12]. See also [SIPREC call recording interface](https://warmtransfer.net/knowledge/siprec-recording). See also [Unified CM network-based and built-in bridge recording](https://warmtransfer.net/knowledge/cucm-built-in-bridge-recording). See also [Setting up TLS and SRTP on CUBE](https://warmtransfer.net/knowledge/cube-tls-srtp-setup). See also [Troubleshooting SIPREC recording failures](https://warmtransfer.net/knowledge/siprec-recording-failures). ## What changes by situation - Which device sends the recording media, and who controls it? CUBE sends SIPREC sessions to a third-party recording server; Unified CM network-based recording with CUBE as the gateway source; Phone built-in bridge recording with no forking on CUBE. - If you use CUBE SIPREC, which side of CUBE carries the media class? The carrier-facing dial-peers; The internal dial-peers facing Unified CM. - How is media protected on each leg of CUBE? RTP on both legs; SRTP toward Unified CM and RTP toward the carrier; SRTP on both legs or SRTP passed through CUBE. ## Step 1: Inventory the call path and check SIPREC eligibility ### Do We infer that a call is forked only if a dial-peer it actually matches on the chosen side has the media class, so for each call type you must record, list the CUBE dial-peers it matches, inbound and outbound, on both the carrier and internal sides, and note the items below[^2]. - Whether the call is SIP-to-SIP, because CUBE SIPREC recording requires a SIP-to-SIP call flow[^46]. - Whether it is a flow-around, SDP pass-through, RTP loopback or high-density transcoder call, none of which CUBE SIPREC supports[^10]. - Whether CUBE runs a TCL IVR application other than survivability.tcl, because CUBE SIPREC recording is not supported while one runs[^51]. - Whether each leg and the recorder use IPv6, because CUBE SIPREC does not support IPv6-to-IPv6 call recording, nor IPv6-to-IPv4 recording when the recording server is on the IPv6 leg[^13]. - Whether each leg is RTP or SRTP, because CUBE SIPREC is not supported for SRTP pass-through calls and forks only the RTP leg of an SRTP-to-RTP interworked call[^49][^50]. - Whether video calls carry several video m-lines, because CUBE SIPREC then forks only the first video stream and does not fork application media streams[^62]. - For Unified CM gateway recording, whether a SIP proxy sits between Unified CM and CUBE, because Unified CM does not allow SIP proxy servers there when the gateway is the recording source[^57]. ### Verify Suggested check: confirm that every call type you must record passed each item in the list, and mark any that did not. Calls that are not SIP-to-SIP, that are flow-around or SDP pass-through calls, or that place the recorder on the IPv6 leg of an IPv6-to-IPv4 call cannot be SIPREC-recorded on CUBE[^46][^10][^13]. ## Step 2: Check that your media security allows the method you picked **RTP on both legs** ### Do - We infer that either the carrier-facing or the internal dial-peer can be the SIPREC anchor, because Cisco shows the media class on an inbound Unified CM-facing dial-peer in one example and on an outgoing dial-peer in another, and states no requirement[^6]. - Unified CM selects the gateway as recording source only when Gateway Preferred is set, the media is unsecure RTP and a gateway is in the call path[^60]. - With Gateway Preferred and RTP media, Unified CM falls back to the phone when no gateway is in the call path[^72]. ### Verify Suggested check: confirm from your step 1 inventory that both legs of every call type you must record carry RTP. **SRTP toward Unified CM and RTP toward the carrier** ### Do - On an SRTP-to-RTP interworked call, CUBE SIPREC does not support forking on the SRTP leg, and forking is supported on the RTP leg[^50]. - We infer that where the Unified CM leg is SRTP and the carrier leg is RTP, the SIPREC media class has to go on the carrier-facing dial-peer, so a CUBE SIPREC design here uses fork_leg=carrier[^48]. - For Unified CM gateway recording, Unified CM selects the phone, not the gateway, as recording source when the media is secure SRTP[^60]. ### Verify Suggested check: re-read your fork_leg answer and confirm that, if you use SIPREC, it names the carrier side. **SRTP on both legs or SRTP passed through CUBE** ### Do - CUBE SIPREC recording is not supported for SRTP pass-through calls[^49]. - Unified CM selects the phone as recording source when the media is secure SRTP[^60]. - For secure forking through CUBE Media Proxy, the outbound dial-peers toward the recorders must be configured for TLS or SRTP[^19]. - CUBE Media Proxy was introduced in IOS XE 16.10.1a, gained SIPREC support in 17.3.1a and gained secure forking of non-secure calls in 17.5.1a[^18]. - CUBE Media Proxy does not fork video sessions and does not support SRTP fallback[^17]. - The phone-based alternative sources media from the phone, which forks 2 media streams to the recording server[^52]. ### Verify Suggested check: write down whether you are moving to a proxy-based secure forking design or to phone-sourced recording before you configure anything. ## Step 3: Confirm the recording server is compatible **CUBE sends SIPREC sessions to a third-party recording server** ### Do - Cisco states recorders must support SIP Recording Metadata format version 17 at a minimum[^23]. - Cisco states CUBE should comply with draft-ietf-siprec-protocol-16 and supports only the siprec option tag and the src feature tag among its extensions[^30]. - SIP recording metadata was published as RFC 7865, a Proposed Standard, in May 2016[^37]. - We infer that, because Cisco states CUBE compliance against draft-ietf-siprec-metadata-17 and draft-ietf-siprec-protocol-16 rather than RFC 7865 and RFC 7866, a recorder's SIPREC conformance claim alone does not prove CUBE interoperability, so ask the recorder vendor for its tested CUBE integration[^5]. - Ask the vendor for the address and port its recorder listens on for TCP, because Cisco's recorder dial-peer uses session transport tcp[^32]. - MiaRec's guide, for example, shows a session target on TCP port 5080[^24]. ### Verify Suggested check: get written confirmation from the recorder supplier of its metadata version support and of the listening address, port and transport. Cisco lists reachability of the recorders from CUBE as a prerequisite, so confirm the recorder is reachable from CUBE[^36]. Under RFC 7866 an SRS normally only receives media, so its SDP answer sets each recorded stream to a=recvonly[^40]. **Unified CM network-based recording with CUBE as the gateway source** ### Do - Confirm the recorder can be the target of a Unified CM recording profile, whose Recording Destination Address is the recorder's directory number or URL[^59]. - Confirm your CUBE platform is listed, because Unified CM 15's recording chapter lists Cisco 4000 Series ISRs, ASR 1000 routers and CSR 1000V as gateways for gateway-sourced recording[^54]. - Cisco lists CUBE network-based (XMF) recording as not supporting video, high availability, VRF, TDM-leg forking, media mixing on forked streams, or record-tone insertion on SRTP calls[^65]. ### Verify Suggested check: confirm the recorder supplier documents support for network-based recording sourced from a gateway. **Phone built-in bridge recording with no forking on CUBE** ### Do - Confirm the recorder accepts the 2 media streams the phone forks to it[^73]. - Unified CM sends the recorder a separate SIP INVITE for each forked stream, one for the near-end voice and one for the far-end voice, so a basic call produces 2 recording sessions[^74]. - Run the Cisco Unified Reporting Unified CM Phone Feature List report with Record selected to check which phones support recording[^70]. - Field reports suggest that older Cisco models such as the 7940, 7960 and 7912 do not support built-in bridge recording while 7800 and 8800 models do, according to a third-party recorder vendor's list[^75]. ### Verify Suggested check: confirm every agent phone you must record appears in the phone feature report for recording, and that the recorder supplier documents phone-sourced recording support. ## Step 4: Build the CUBE side of the recording path **CUBE sends SIPREC sessions to a third-party recording server** ### Do - Create a recorder dial-peer with a destination-pattern, session protocol sipv2, session target ipv4 with the recorder address or DNS name, and session transport tcp[^32]. - Use a simple number as the destination-pattern, because Cisco lists a regular-expression destination-pattern on the recording dial-peer as a common cause of SIPREC failure in new deployments[^35]. - MiaRec's guide treats the recorder dial-peer destination-pattern as a dummy value[^24]. - Do not configure a server group on this dial-peer, because server groups on outbound dial-peers toward SIPREC recorders are not supported[^42]. - Build one recorder dial-peer per recorder, up to 5, because the media-recording command in step 5 accepts a maximum of 5 recorder dial-peer tags[^14]. ### Verify Cisco lists a wrong recording server IP address, or a recorder hostname that does not resolve, as a common SIPREC failure in new deployments[^33]. Suggested check: confirm the session target resolves to the address the recorder supplier gave you. Cisco lists reachability of the recorders from CUBE as a prerequisite for SIPREC recording[^36]. ### Rollback Suggested rollback: remove the recorder dial-peer you created. **Unified CM network-based recording with CUBE as the gateway source** ### Do - Configure CUBE as Cisco's network-based recording configuration does: enable ip http server, configure uc wsapi with a source-address and probing settings, and under provider xmf set no shutdown and a remote-url pointing to Unified CM on port 8090[^64]. - For gateway-based recording, Unified CM sends media-forking requests to CUBE over HTTP to the Unified Communications Services API through the XMF provider[^76]. - CUBE's XMF provider lets applications monitor calls and trigger media forking and can serve up to 32 applications[^63]. ### Verify Network-based recording on CUBE is verified with `show wsapi registration all` for registered XMF applications[^67]. Suggested check: repeat the registration check after the call-control side is configured in step 5, because nothing may register before then. ### Rollback Suggested rollback: shut down the forking provider and remove the web services configuration you added. **Phone built-in bridge recording with no forking on CUBE** ### Do In IP phone based recording the media is sourced from the phone, which forks 2 media streams to the recording server[^52]. ### Verify Suggested check: confirm that no recording configuration was added to the border device for this path. ## Step 5: Define the recording policy **CUBE sends SIPREC sessions to a third-party recording server** ### Do - Create `media profile recorder ` and list the recorder dial-peers in it with `media-recording`[^29]. - List no more than 5 recorder dial-peer tags, the maximum media-recording accepts[^14]. - Optionally add `media-type audio`, which makes CUBE record only the audio of a call that has both audio and video; without it both are recorded[^20]. - Create `media class ` and bind the profile with `recorder profile siprec`[^29]. Cisco documents a second method without a media profile recorder, in which the media class itself carries recorder parameter with siprec, optional media-type audio and the media-recording dial-peer tags[^28]. Keep the siprec keyword in whichever form you use, because if SIPREC is not configured in the recorder definition, CUBE falls back to its existing Network-Based Recording implementation rather than sending SIPREC sessions[^9]. ### Verify Suggested check: read back the running configuration and confirm the media class references the recorder profile with the siprec keyword. A recorder definition without SIPREC makes CUBE fall back to Network-Based Recording instead of sending SIPREC sessions[^9]. ### Rollback Suggested rollback: remove the media class and the media profile you created. **Unified CM network-based recording with CUBE as the gateway source** ### Do - In Unified CM, create a recording profile whose Recording Calling Search Space reaches the recorder's route pattern and whose Recording Destination Address is the recorder's directory number or URL[^59]. - On the SIP trunk to CUBE, set Recording Information to 'This trunk connects to a recording-enabled gateway'[^61]. - Optionally, in a SIP profile for recording, enable Deliver Conference Bridge Identifier to send the conference bridge identifier to the recorder[^77]. ### Verify On CUBE, `show wsapi registration all` lists registered XMF applications[^67]. Suggested check: confirm the trunk page shows the recording-enabled gateway option. ### Rollback Set Recording Information on the trunk back to None[^61]. **Phone built-in bridge recording with no forking on CUBE** ### Do - Create a recording profile whose Recording Calling Search Space reaches the recorder's route pattern and whose Recording Destination Address is the recorder's directory number or URL[^59]. - Set Built in Bridge to On for the agent phones, because phone-sourced recording in Unified CM needs it[^53]. - The per-phone Built In Bridge setting is On, Off or Default, where Default uses the cluster service parameter and On or Off overrides it for that phone[^78]. - The Builtin Bridge Enable service parameter of the Cisco CallManager service sets the cluster-wide default to On or Off[^79]. - Clear Media Termination Point Required on those phones, because recording can fail when Built-in Bridge is On and Media Termination Point Required is checked[^80]. ### Verify Suggested check: open each agent phone's configuration and confirm the built-in bridge is on and the media termination point requirement is cleared. ### Rollback Suggested rollback: restore each phone's previous built-in bridge setting and delete the recording profile you created. ## Step 6: Attach the SIPREC media class to the anchor dial-peers **The carrier-facing dial-peers + CUBE sends SIPREC sessions to a third-party recording server** ### Do - Add `media-class ` to the carrier-facing dial-peers, because media-class on a SIP dial-peer enables forking for calls on that dial-peer[^29]. - We infer that a call is forked only if a dial-peer it actually matches on the chosen side has the media class, so every inbound and outbound carrier-facing dial-peer that recorded calls can match needs it[^2]. - In CUBE SIPREC output the anchor leg is the call leg of the dial-peer where forking is enabled, which here is the carrier-facing leg[^1]. - We infer that this side is required where the Unified CM leg is SRTP and the carrier leg is RTP, because only the RTP leg can be forked[^48]. - WarmTransfer's reading of the sources is that applying the media class to both the carrier-facing and the internal dial-peer of the same call risks 2 recording sessions for one call, so leave the internal dial-peers without it[^45]. - Do not also configure dial-peer based recording for these calls, because forking a single call on CUBE with both dial-peer based recording and SIPREC is not supported[^27]. ### Verify Cisco lists an incorrect inbound dial-peer match, where the selected inbound dial-peer has no media-class, as a common SIPREC failure in new deployments[^12]. Suggested check: place a test call and confirm it matches one of the carrier-facing dial-peers that carry the media class, not a default or other dial-peer. ### Rollback Suggested rollback: remove the media class from each carrier-facing dial-peer you changed. **The internal dial-peers facing Unified CM + CUBE sends SIPREC sessions to a third-party recording server** ### Do - Add `media-class ` to the internal dial-peers, because media-class on a SIP dial-peer enables forking for calls on that dial-peer[^29]. - We infer that a call is forked only if a dial-peer it actually matches on the chosen side has the media class, so every inbound and outbound internal dial-peer that recorded calls can match needs it[^2]. - Cisco's SIPREC configuration example applies the media class to the Unified CM-facing dial-peer (dial-peer 11) and routes recordings through recorder dial-peer 777[^7]. - Cisco's SIPREC troubleshooting walkthrough shows a working call with the media-class configured on the outgoing dial-peer[^8]. - MiaRec's CUBE SIPREC integration guide recommends assigning the recorder to the incoming dial-peer rather than the outgoing one[^25]. - Do not use this side when the internal leg is SRTP and the carrier leg is RTP, because CUBE SIPREC does not support forking on the SRTP leg of an SRTP-to-RTP interworked call[^50]. - WarmTransfer's reading of the sources is that applying the media class to both the carrier-facing and the internal dial-peer of the same call risks 2 recording sessions for one call, so leave the carrier-facing dial-peers without it[^45]. - Do not also configure dial-peer based recording for these calls, because forking a single call on CUBE with both dial-peer based recording and SIPREC is not supported[^27]. ### Verify Cisco lists an incorrect inbound dial-peer match, where the selected inbound dial-peer has no media-class, as a common SIPREC failure in new deployments[^12]. Suggested check: place a test call and confirm it matches one of the internal dial-peers that carry the media class, not a default or other dial-peer. ### Rollback Suggested rollback: remove the media class from each internal dial-peer you changed. **Unified CM network-based recording with CUBE as the gateway source** ### Do In this path Unified CM sends media-forking requests to CUBE through the XMF provider rather than relying on a SIPREC media class[^76]. ### Verify Suggested check: confirm that no SIPREC media class was added to any dial-peer for this path. **Phone built-in bridge recording with no forking on CUBE** ### Do In this path the recording media is sourced from the phone[^52]. ### Verify Suggested check: confirm that no SIPREC media class was added to any dial-peer for this path. ## Step 7: Enable recording on agent lines in Unified CM **CUBE sends SIPREC sessions to a third-party recording server** ### Do CUBE SIPREC forking is enabled by `media-class ` on a SIP dial-peer, which step 6 has already done[^29]. ### Verify Suggested check: note which agent lines, if any, already have a recording option set, so that you know every recording path in use for the same calls. **Unified CM network-based recording with CUBE as the gateway source** ### Do - On each agent line, set Recording Option to Automatic Call Recording Enabled or Selective Call Recording Enabled, select the Recording Profile from step 5, and set Recording Media Source to gateway preferred[^55]. - Automatic silent recording records all calls on the configured line appearance and gives no indication on the phone[^81]. - Optionally, configure the recording notification tone, which Unified CM can play periodically to the agent, the caller or both[^58]. ### Verify Unified CM selects the gateway as recording source only when Gateway Preferred is set, the media is unsecure RTP and a gateway is in the call path; with secure SRTP media, or with Phone Preferred, it selects the phone[^60]. Suggested check: open each agent line and confirm the recording option, profile and media source you set. ### Rollback Set Recording Option back to Call Recording Disabled, one of its 3 values[^82]. **Phone built-in bridge recording with no forking on CUBE** ### Do - On each agent line, set Recording Option to Automatic Call Recording Enabled or Selective Call Recording Enabled and select the Recording Profile[^55]. - Set Recording Media Source to Phone Preferred, because with Phone Preferred Unified CM selects the phone as recording source[^60]. - Optionally, configure the recording notification tone, which Unified CM can play periodically to the agent, the caller or both[^58]. ### Verify Suggested check: open each agent line and confirm the recording option, profile and media source you set. ### Rollback Set Recording Option back to Call Recording Disabled, one of its 3 values[^82]. ## Step 8: Place test calls and confirm forking **CUBE sends SIPREC sessions to a third-party recording server** ### Do We infer that a call is forked only if a dial-peer it actually matches carries the media class, so place an inbound and an outbound test call that match the anchored dial-peers[^2]. ### Verify - `show voip recmsp session` lists active recording sessions with the MSP call-ID, anchor-leg call-ID and forked-leg call-ID, and its detail form shows stream types, packet counts and stream status ACTIVE or HOLD[^43]. - On IOS XE 17.18.1a and later, `show voip recmsp session detail forked call-id` displays consolidated information on forked and associated anchor call legs[^4]. - `show voip rtp forking` lists each fork's stream type, recorder IP and port, codec and packets sent[^44]. - CUBE sends SIPREC metadata as application/rs-metadata+xml in a multipart body describing the session, participants, streams and their associations, so confirm on the recorder that it arrived[^22]. ### Rollback Suggested rollback: if recording must stop, remove the media class from the anchor dial-peers as in step 6. **Unified CM network-based recording with CUBE as the gateway source** ### Do Place an RTP call from the carrier to a recording-enabled agent line, because Unified CM selects the gateway as source only for unsecure RTP media with a gateway in the call path[^60]. ### Verify - `show call media-forking` on CUBE shows active forked streams[^67]. - Unified CM sends the recorder a separate SIP INVITE for each forked stream, so a basic call produces 2 recording sessions[^74]. - The From header of recording INVITEs carries x-nearend or x-farend, x-refci, x-nearenddevice, x-farendrefci, x-farenddevice and x-farendaddr to identify the stream, the call leg and the parties[^83]. Suggested check: confirm the recorder stored the test call. ### Rollback Suggested rollback: if recording must stop, disable recording on the agent lines as in step 7. **Phone built-in bridge recording with no forking on CUBE** ### Do Place a call to a recording-enabled agent line, whose phone then forks 2 media streams to the recording server[^73]. ### Verify Unified CM sends the recorder a separate SIP INVITE for each forked stream, so a basic call produces 2 recording sessions[^74]. Suggested check: confirm the recorder received both streams for the test call and stored it. ### Rollback Suggested rollback: if recording must stop, disable recording on the agent lines as in step 7. ## Step 9: Test mid-call events on the recording **CUBE sends SIPREC sessions to a third-party recording server** ### Do On a recorded call, exercise hold, transfer and, if you record video, audio-video escalation and de-escalation, then hang up, because Cisco's metadata examples show CUBE updating recording metadata on those events and sending end-time metadata with the BYE at disconnect[^21]. ### Verify - Cisco's metadata examples show updated metadata on hold, escalation, de-escalation, transfer and caller-ID UPDATE, and end-time metadata with the BYE[^21]. - When the main call has several video m-lines, CUBE SIPREC forks only the first video stream[^62]. - CUBE does not support media parameter changes by Re-INVITE or UPDATE from the recording server, nor mid-call renegotiation or hold/resume on the recorder call leg[^34]. - From IOS XE 17.18.2, when a recorder answers with an inactive SDP attribute, CUBE stops sending media packets to that recorder[^11]. Suggested check: confirm the recorder's stored record shows each event you exercised. **Unified CM network-based recording with CUBE as the gateway source** ### Do - Put a recorded call on hold and resume it: recording sessions are torn down when the agent puts the call on hold and are re-established when the agent resumes[^84]. - Transfer the call from the agent: the existing recording sessions end with BYE and new sessions start, including for the consultation call[^85]. - Have the far-end party transfer a call: Unified CM sends the recorder UPDATE messages carrying the new x-farendaddr[^86]. ### Verify Suggested check: confirm the recorder shows a separate recording segment before and after each hold and agent transfer, and the new far-end address after a far-end transfer. **Phone built-in bridge recording with no forking on CUBE** ### Do - Put a recorded call on hold and resume it: recording sessions are torn down when the agent puts the call on hold and are re-established when the agent resumes[^84]. - Transfer the call from the agent: the existing recording sessions end with BYE and new sessions start, including for the consultation call[^85]. - Have the far-end party transfer a call: Unified CM sends the recorder UPDATE messages carrying the new x-farendaddr[^86]. ### Verify Suggested check: confirm the recorder shows a separate recording segment before and after each hold and agent transfer, and the new far-end address after a far-end transfer. ## Step 10: Troubleshoot a call that is not recorded **CUBE sends SIPREC sessions to a third-party recording server** ### Do - Check whether the call matched an inbound dial-peer without the media class, which Cisco lists as a common SIPREC failure in new deployments[^12]. - Check whether the recorder dial-peer uses a regular-expression destination-pattern, which Cisco lists as a common cause of SIPREC failure[^35]. - Check whether the recorder IP address is wrong or its hostname does not resolve, which Cisco lists as a common SIPREC failure[^33]. - Check whether the recorder answers the recording INVITE with 503 Service Unavailable or 500 Server Internal Error, which Cisco names as the main post-production SIPREC failure[^31]. - Collect debug voip ccapi inout, debug ccsip message, events, error and info, and debug voip recmsp event, error and inout, as Cisco's SIPREC troubleshooting does[^3]. ### Verify After the fix, `show voip recmsp session` lists the call with its MSP, anchor-leg and forked-leg call-IDs[^43]. ### Rollback Suggested rollback: turn off all debugging once you have collected the output. **Unified CM network-based recording with CUBE as the gateway source** ### Do - Check that no SIP proxy sits between Unified CM and CUBE, because Unified CM does not allow one when the gateway is the recording source[^57]. - Check that the call used RTP and that Gateway Preferred is set, because otherwise Unified CM selects the phone[^60]. - Check `show wsapi registration all` for the registered XMF application and `show call media-forking` for active forked streams[^67]. ### Verify Suggested check: place another test call and confirm the recorder stores it. **Phone built-in bridge recording with no forking on CUBE** ### Do - Check that Media Termination Point Required is not checked on the phone, because recording can fail when it is checked with Built-in Bridge On[^80]. - Check the phone in the Unified CM Phone Feature List report with Record selected[^70]. - Check that the line's Recording Media Source is Phone Preferred, because Unified CM then selects the phone[^60]. ### Verify Suggested check: place another test call and confirm the recorder stores both streams. ## Applicability Applies to: Cisco Unified Border Element, MiaRec, Cisco Unified Communications Manager, Cisco CUBE, and Cisco IP phones. Deployments: on-premises and any. Sources checked 2026-10-01. IOS XE 17.18.1a introduced `show voip recmsp session detail forked call-id`[^4], and the inactive-answer behaviour applies from IOS XE 17.18.2[^11]. CUBE Media Proxy was introduced in IOS XE 16.10.1a, gained SIPREC support in 17.3.1a and secure forking of non-secure calls in 17.5.1a[^18]. The gateway platform list is from Unified CM 15's recording chapter[^54]. The Unified CM 12.5(1) Recording chapter already documents the media source selection table, the Builtin Bridge Enable parameter, the 2 notification tone parameters and the rule that recording does not survive agent hold[^87]. RFC 7865 was published as a Proposed Standard in May 2016[^37]. ## What remains uncertain - Whether CUBE SIPREC can fork a call on which CUBE terminates SRTP on both legs rather than passing it through, and whether the stream to the recorder would then be SRTP, is not covered by the sources below. - Whether CUBE SIPREC works over TLS or UDP toward the recorder is not covered by the sources below. - Licensing, session capacity, CPU impact and box-to-box high availability for CUBE SIPREC are not covered by the sources below. - What happens to the main call when the recording server is unavailable is not covered by the sources below. - Whether a recording notification tone meets a given jurisdiction's consent or notification obligations is not covered by the sources below. - See also [Call recording consent laws](https://warmtransfer.net/knowledge/call-recording-consent-laws). - The exact command nesting of the recorder parameter form and the full URL path of the XMF remote-url are not covered by the sources below. ## Sources [^1]: In CUBE SIPREC output the anchor leg is the call leg of the dial-peer where forking is enabled, that is, the dial-peer carrying the media class. 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), Validate SIPREC Functionality, show voip recmsp session field table, Anchor Leg Call-id. Checked 2026-10-01. [^2]: Because recording follows the matched dial-peer that carries the media class, a call is forked only if a dial-peer it actually matches on the chosen side has the media class, so every inbound and outbound dial-peer on that side that recorded calls can match needs it (inferred). 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), Troubleshoot, common issues, first bullet; show voip recmsp session field table. Checked 2026-10-01. [^3]: Cisco's SIPREC troubleshooting uses debug voip ccapi inout, debug ccsip message, events, error and info, and debug voip recmsp event, error and inout. 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), Troubleshoot. Checked 2026-10-01. [^4]: IOS XE 17.18.1a introduced 'show voip recmsp session detail forked call-id' to display 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), Feature Information, Enhanced support for serviceability in SIP recording row. Checked 2026-10-01. [^5]: Because Cisco states CUBE compliance against draft-ietf-siprec-metadata-17 and draft-ietf-siprec-protocol-16 rather than RFC 7865 and RFC 7866, a recorder's SIPREC conformance claim alone does not prove CUBE interoperability; confirm the recorder vendor's tested CUBE integration (inferred). 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), Prerequisites for SIPREC Recording, third and fourth bullets. Checked 2026-10-01. [^6]: Because Cisco shows the media class on an inbound Unified CM-facing dial-peer in one example and on an outgoing dial-peer in another, and states no requirement, either the carrier-facing or the internal dial-peer can be the SIPREC anchor (inferred). 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), Configuration Examples for SIPREC-based Recording; Troubleshoot, working scenario. Checked 2026-10-01. [^7]: Cisco's SIPREC configuration example applies the media class to the Unified CM-facing dial-peer (dial-peer 11) and routes recordings through recorder dial-peer 777. 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), Configuration Examples for SIPREC-based Recording. Checked 2026-10-01. [^8]: Cisco's SIPREC troubleshooting walkthrough shows a working call with the media-class configured on the outgoing dial-peer. 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), Troubleshoot, working scenario. Checked 2026-10-01. [^9]: If SIPREC is not configured in the recorder definition, CUBE falls back to its existing Network-Based Recording implementation rather than sending SIPREC sessions. 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), Prerequisites for SIPREC Recording, second bullet. Checked 2026-10-01. [^10]: CUBE SIPREC recording is not supported for flow-around calls, SDP pass-through calls, RTP loopback calls or high-density transcoder 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), Restrictions for SIPREC Recording. Checked 2026-10-01. [^11]: From IOS XE 17.18.2, when a recorder answers with an inactive SDP 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), Feature Information, Directional attribute compliance for SIPREC responses row. Checked 2026-10-01. [^12]: Cisco lists an incorrect inbound dial-peer match, where the selected inbound dial-peer has no media-class, as a common SIPREC failure in new deployments. 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), Troubleshoot, common issues, first bullet. Checked 2026-10-01. [^13]: CUBE SIPREC does not support IPv6-to-IPv6 call recording, nor IPv6-to-IPv4 recording when the recording server is 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), Restrictions for SIPREC Recording. Checked 2026-10-01. [^14]: The media-recording command accepts a maximum of five recorder dial-peer tags. 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), Configure SIPREC-Based Recording (with Media Profile Recorder), media-recording step. Checked 2026-10-01. [^15]: CUBE Media Proxy uses 'media-recording proxy' and 'media-recording proxy secure' under a media profile recorder, with an optional 'proxy policy mandatory' recorder, and is verified with 'show media-proxy sessions'. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Media Proxy and Recording](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_recording_proxy.html), Configure CUBE Media Proxy; Verify. Checked 2026-10-01. [^16]: CUBE Media Proxy forks a call to at most five recorder destinations, the first configured being primary. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Media Proxy and Recording](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_recording_proxy.html), Restrictions; Configure media-recording proxy. Checked 2026-10-01. [^17]: CUBE Media Proxy does not fork video sessions and does not support SRTP fallback. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Media Proxy and Recording](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_recording_proxy.html), Restrictions. Checked 2026-10-01. [^18]: CUBE Media Proxy, a multiple-forking function built on CUBE, was introduced in IOS XE 16.10.1a, gained SIPREC support in 17.3.1a and secure forking of non-secure calls in 17.5.1a. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Media Proxy and Recording](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_recording_proxy.html), Feature Information. Checked 2026-10-01. [^19]: For secure forking through CUBE Media Proxy, the outbound dial-peers toward the recorders must be configured for TLS or SRTP. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Media Proxy and Recording](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_recording_proxy.html), Secure forking / Configure secure media forking. Checked 2026-10-01. [^20]: The optional 'media-type audio' setting makes CUBE record only the audio of a call that has both audio and video; without it both 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), Configure SIPREC-Based Recording (with Media Profile Recorder), media-type step. Checked 2026-10-01. [^21]: Cisco's metadata examples show CUBE updating recording metadata on hold, audio-video escalation and de-escalation, transfer and caller-ID UPDATE, and sending end-time metadata with the BYE at disconnect. 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), Configuration Example for Metadata Variations sections (Hold, Escalation, De-escalation, Transfer, Caller-ID UPDATE, Disconnect). Checked 2026-10-01. [^22]: CUBE sends SIPREC metadata as application/rs-metadata+xml in a multipart body, describing the session, participants, streams and participant-session and participant-stream associations. 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), Example: Complete SIP Recording Metadata Information Sent in INVITE or Re-INVITE. Checked 2026-10-01. [^23]: CUBE supports the SIP Recording Metadata format of draft-ietf-siprec-metadata-17, and Cisco states recorders must support metadata format version 17 at a minimum. 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), Prerequisites for SIPREC Recording, third bullet. Checked 2026-10-01. [^24]: MiaRec's guide treats the recorder dial-peer destination-pattern as a dummy value and shows a session target on TCP port 5080 as its example. Source: [Cisco CUBE SIPREC configuration](https://docs.miarec.com/cisco-siprec-integration-guide/cisco-cube-siprec-configuration/), Recorder dial-peer section. Checked 2026-10-01. [^25]: MiaRec's CUBE SIPREC integration guide recommends assigning the recorder to the incoming dial-peer rather than the outgoing one. Source: [Cisco CUBE SIPREC configuration](https://docs.miarec.com/cisco-siprec-integration-guide/cisco-cube-siprec-configuration/), Dial-peer configuration section. Checked 2026-10-01. [^26]: Cisco's Unified CM recording use-case document includes network-based recording scenarios for external calls to mobile Jabber clients, remote destination profiles and Extend and Connect CTI remote devices. Source: [Recording Use Cases for Cisco Unified Communications Manager](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/configExamples/cucm_b_recording-use-cases.html), Use case section titles. Checked 2026-10-01. [^27]: Forking a single call on CUBE with both dial-peer based recording and SIPREC is not supported. 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), Restrictions for SIPREC Recording, last general bullet. Checked 2026-10-01. [^28]: Cisco documents a second SIPREC method without a media profile recorder, in which the media class itself carries 'recorder parameter' with siprec, optional media-type audio and the media-recording dial-peer tags. 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), Configure SIPREC-Based Recording (without Media Profile Recorder); Feature Information row naming recorder parameter and recorder profile. Checked 2026-10-01. [^29]: With the media profile method, 'media profile recorder ' lists recorder dial-peers with 'media-recording', 'media class ' binds it with 'recorder profile siprec', and 'media-class ' on a SIP dial-peer enables forking for calls on that dial-peer. 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), Configure SIPREC-Based Recording (with Media Profile Recorder). Checked 2026-10-01. [^30]: Cisco states CUBE should comply with the session recording protocol of draft-ietf-siprec-protocol-16 and supports only the siprec option tag and the src feature tag among its extensions. 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), Prerequisites for SIPREC Recording, fourth bullet. Checked 2026-10-01. [^31]: Cisco attributes post-production SIPREC failures mainly to an unavailable recording server, seen as 503 Service Unavailable or 500 Server Internal Error responses to CUBE's recording INVITE. 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), Troubleshoot, post-production failures. Checked 2026-10-01. [^32]: Cisco's recorder dial-peer carries a destination-pattern, session protocol sipv2, session target ipv4 with the recorder address or DNS name, and session transport tcp. 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), Configure SIPREC-Based Recording, recorder dial-peer steps. Checked 2026-10-01. [^33]: Cisco lists a wrong recording server IP address, or a recorder hostname that does not resolve, as a common SIPREC failure in new deployments. 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), Troubleshoot, common issues, third bullet. Checked 2026-10-01. [^34]: CUBE does not support media parameter changes by Re-INVITE or UPDATE from the recording server, nor mid-call renegotiation or supplementary services such as hold/resume on the 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), Restrictions for SIPREC Recording, first and twelfth bullets. Checked 2026-10-01. [^35]: Cisco lists a regular-expression destination-pattern on the recording dial-peer, instead of a simple directory number, as a common cause of SIPREC failure in new deployments. 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), Troubleshoot, common issues, second bullet. Checked 2026-10-01. [^36]: Cisco lists reachability of the recorders from CUBE as a prerequisite for SIPREC recording. 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), Prerequisites for SIPREC Recording, first bullet. Checked 2026-10-01. [^37]: SIP recording metadata was published as RFC 7865, a Proposed Standard, in May 2016. Source: [RFC 7865 Session Initiation Protocol (SIP) Recording Metadata](https://www.rfc-editor.org/info/rfc7865), Info page, status and date fields. Checked 2026-10-01. [^38]: RFC 7866 requires an SRC to include the siprec option tag in the Require header of a recording session INVITE, so user agents without recording support reject it with 420 Bad Extension. Source: [RFC 7866: Session Recording Protocol](https://www.rfc-editor.org/rfc/rfc7866.html), Section 6.1.1 (SRC initiating a recording session). Checked 2026-10-01. [^39]: RFC 7866 requires the SRC to include the +sip.src feature tag in the Contact URI for all recording sessions. Source: [RFC 7866: Session Recording Protocol](https://www.rfc-editor.org/rfc/rfc7866.html), Section 6.1.1. Checked 2026-10-01. [^40]: Under RFC 7866 an SRS normally only receives media, so its SDP answer sets each recorded stream to a=recvonly. Source: [RFC 7866: Session Recording Protocol](https://www.rfc-editor.org/rfc/rfc7866.html), Section 7 (SDP handling). Checked 2026-10-01. [^41]: RFC 7866 requires both SRC and SRS to support SIP over TLS 1.2, and addresses SRTP media protection in its security considerations. Source: [RFC 7866: Session Recording Protocol](https://www.rfc-editor.org/rfc/rfc7866.html), Section 12 (Security Considerations). Checked 2026-10-01. [^42]: Server groups on outbound dial-peers toward SIPREC recorders are not supported. 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), Restrictions for SIPREC Recording, video recording list. Checked 2026-10-01. [^43]: 'show voip recmsp session' lists active recording sessions with the MSP call-ID, anchor-leg call-ID and forked-leg call-ID, and its detail form shows stream types, packet counts and stream status ACTIVE or HOLD. 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), Validate SIPREC Functionality, show voip recmsp session and field table. Checked 2026-10-01. [^44]: Cisco uses 'show voip rtp connections' and 'show voip rtp forking' to validate SIPREC, the latter listing each fork's stream type, recorder IP and port, codec and packets sent. 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), Validate SIPREC Functionality. Checked 2026-10-01. [^45]: Applying the media class to both the carrier-facing and the internal dial-peer of the same call risks two recording sessions for one call, so the media class should sit on one side only (inferred). Source: [Cisco CUBE SIPREC configuration](https://docs.miarec.com/cisco-siprec-integration-guide/cisco-cube-siprec-configuration/), dial-peer assignment recommendation. Checked 2026-10-01. [^46]: CUBE SIPREC recording requires a SIP-to-SIP call flow; non-SIP calls are not supported. 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), Restrictions for SIPREC Recording. Checked 2026-10-01. [^47]: Cisco describes CUBE SIPREC (SIP Forking) as media recording of RTP streams in compliance with section 3.1.1 of RFC 7245, with CUBE acting as the Session Recording Client. 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), Overview, first paragraph. Checked 2026-10-01. [^48]: Where the Unified CM leg is SRTP and the carrier leg is RTP, the SIPREC media class has to go on the carrier-facing dial-peer, because only the RTP leg can be forked (inferred). 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), Restrictions for SIPREC Recording; show voip recmsp session field table. Checked 2026-10-01. [^49]: CUBE SIPREC recording is not supported for SRTP pass-through 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), Restrictions for SIPREC Recording. Checked 2026-10-01. [^50]: On an SRTP-to-RTP interworked call, CUBE SIPREC does not support forking on the SRTP leg; forking is supported on the RTP 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), Restrictions for SIPREC Recording. Checked 2026-10-01. [^51]: CUBE SIPREC recording is not supported while CUBE runs a TCL IVR application, except survivability.tcl. 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), Restrictions for SIPREC Recording. Checked 2026-10-01. [^52]: In Unified CM IP phone based recording the media is sourced from the phone, which forks two media streams to the recording server. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Recording](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_mp_r53f7ff4_00_recording-12-0.html), Recording Overview, IP phone based recording. Checked 2026-10-01. [^53]: Phone-sourced recording in Unified CM needs the phone's Built in Bridge set On, and recording can fail if Built-in-Bridge is On while Media Termination Point Required is checked. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Recording](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_mp_r53f7ff4_00_recording-12-0.html), Phone recording task flow; restrictions. Checked 2026-10-01. [^54]: Unified CM 15's recording chapter lists Cisco 4000 Series ISRs, ASR 1000 routers and CSR 1000V as gateways for gateway-sourced recording. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Recording](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_mp_r53f7ff4_00_recording-12-0.html), Gateway recording prerequisites. Checked 2026-10-01. [^55]: On the agent line, Unified CM's Recording Option is Call Recording Disabled, Automatic Call Recording Enabled or Selective Call Recording Enabled, alongside a Recording Profile and a Recording Media Source of gateway or phone preferred. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Recording](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_mp_r53f7ff4_00_recording-12-0.html), Configure Agent Phone Line. Checked 2026-10-01. [^56]: In Unified CM network-based recording the recording media can be sourced from the phone or the gateway, and the gateway must connect to Unified CM over a SIP trunk. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Recording](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_mp_r53f7ff4_00_recording-12-0.html), Recording Overview, Network-Based Recording. Checked 2026-10-01. [^57]: When the gateway is the recording source, Unified CM does not allow SIP proxy servers between Unified CM and the gateway. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Recording](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_mp_r53f7ff4_00_recording-12-0.html), Network-based recording prerequisites / restrictions. Checked 2026-10-01. [^58]: Unified CM can play a periodic recording notification tone to the agent, the caller or both to indicate a recording is in progress. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Recording](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_mp_r53f7ff4_00_recording-12-0.html), Recording Overview, recording notification tone. Checked 2026-10-01. [^59]: A Unified CM recording profile sets a Recording Calling Search Space that reaches the recorder's route pattern and a Recording Destination Address that is the recorder's directory number or URL or the URL of a CUBE Media Proxy. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Recording](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_mp_r53f7ff4_00_recording-12-0.html), Create a Recording Profile. Checked 2026-10-01. [^60]: Unified CM selects the gateway as recording source only when Gateway Preferred is set, the media is unsecure RTP and a gateway is in the call path; with secure SRTP media, or with Phone Preferred, it selects the phone. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Recording](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_mp_r53f7ff4_00_recording-12-0.html), Recording Media Source Selection table. Checked 2026-10-01. [^61]: The Unified CM SIP trunk Recording Information setting offers None, 'This trunk connects to a recording-enabled gateway' and 'This trunk connects to other clusters with recording-enabled gateways'. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Recording](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_mp_r53f7ff4_00_recording-12-0.html), Gateway recording task flow, Configure SIP trunk for gateway recording. Checked 2026-10-01. [^62]: When the main call has several video m-lines, CUBE SIPREC forks only the first video stream, and application media streams are not forked. 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), Restrictions for SIPREC Recording, video recording list. Checked 2026-10-01. [^63]: CUBE's Extended Media Forking (XMF) provider lets applications monitor calls and trigger media forking and can serve up to 32 applications. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Network based Recording](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-uc-gateway-services.html), Overview / XMF provider. Checked 2026-10-01. [^64]: Cisco's network-based recording configuration enables 'ip http server', configures 'uc wsapi' with a source-address and probing settings, and under 'provider xmf' sets 'no shutdown' and a remote-url pointing to Unified CM on port 8090. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Network based Recording](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-uc-gateway-services.html), Configure network-based recording (HTTP, uc wsapi, provider xmf). Checked 2026-10-01. [^65]: Cisco lists CUBE network-based (XMF) recording as not supporting video, high availability, VRF, TDM-leg forking, media mixing on forked streams, or record-tone insertion on SRTP calls. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Network based Recording](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-uc-gateway-services.html), Restrictions. Checked 2026-10-01. [^66]: For SRTP calls, CUBE's XMF notification can carry an optional Crypto tag, present only with FORK_STARTED status, for the AES_CM_128_HMAC_SHA1_32 and AES_CM_128_HMAC_SHA1_80 suites. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Network based Recording](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-uc-gateway-services.html), SRTP / Crypto tag in notification messages. Checked 2026-10-01. [^67]: Network-based recording on CUBE is verified with 'show wsapi registration all' for registered XMF applications and 'show call media-forking' for active forked streams. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Network based Recording](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-uc-gateway-services.html), Verification. Checked 2026-10-01. [^68]: For network-based recording, the gateway must connect to Unified CM over a SIP trunk. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Recording](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_mp_r53f7ff4_00_recording-12-0.html), Recording Overview. Checked 2026-09-25. [^69]: When a gateway is used for recording, Unified Communications Gateway Services must be enabled: configure Cisco IOS services on the device, then the XMF provider, then verify. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Recording](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_mp_r53f7ff4_00_recording-12-0.html), Recording Configuration Task Flow > Enable Unified Communications Gateway Services. Checked 2026-09-25. [^70]: To check whether a phone supports recording, run the Cisco Unified Reporting Unified CM Phone Feature List report with Record selected as the feature. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Recording](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_mp_r53f7ff4_00_recording-12-0.html), Recording Prerequisites. Checked 2026-09-25. [^71]: Each recording session adds two calls to the busy hour call completion (BHCC) rate. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Recording](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_mp_r53f7ff4_00_recording-12-0.html), Recording Interactions and Restrictions > Busy Hour Call Completion. Checked 2026-09-25. [^72]: With gateway preferred and unsecure (RTP) media, Unified CM selects the gateway when one is in the call path and falls back to the phone when none is. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Recording](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_mp_r53f7ff4_00_recording-12-0.html), Recording Overview > Recording Media Source Selection, Table 1. Checked 2026-09-25. [^73]: In IP phone-based (built-in bridge) recording, the phone forks two media streams to the recording server. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Recording](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_mp_r53f7ff4_00_recording-12-0.html), Recording Overview. Checked 2026-09-25. [^74]: Unified CM sends the recorder a separate SIP INVITE for each forked stream, one for the near-end voice and one for the far-end voice, so a basic call produces two recording sessions. Source: [Recording Use Cases for Cisco Unified Communications Manager](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/configExamples/cucm_b_recording-use-cases.html), SIP Header Enhancement for Recording Sessions. Checked 2026-09-25. [^75]: A third-party recorder vendor's list marks older Cisco models such as the 7940, 7960 and 7912 as not supporting built-in bridge recording, and 7800 and 8800 models as supporting it (field report). Source: [Cisco Phones Supporting Built-in-Bridge Feature](https://docs.miarec.com/cisco-ucm-integration-guide/cisco-phones-supporting-built-in-bridge-feature/), Supported phones table. Checked 2026-09-25. [^76]: For gateway-based recording, Unified CM sends media-forking requests to CUBE over HTTP to the Unified Communications Services API through the Extended Media Forking (XMF) provider. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Network based Recording](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-uc-gateway-services.html), Network based Recording > overview. Checked 2026-09-25. [^77]: In the optional SIP profile for recording, the Deliver Conference Bridge Identifier setting sends the conference bridge identifier to the recorder. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Recording](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_mp_r53f7ff4_00_recording-12-0.html), Recording Configuration Task Flow > Configure SIP Profile for Recording. Checked 2026-09-25. [^78]: The per-phone Built In Bridge setting is On, Off or Default. Default uses the cluster service parameter; On or Off overrides it for that phone. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Recording](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_mp_r53f7ff4_00_recording-12-0.html), Recording Configuration Task Flow > Enable Built in Bridge for a Phone. Checked 2026-09-25. [^79]: The Builtin Bridge Enable service parameter (Cisco CallManager service) sets the cluster-wide built-in bridge default to On or Off. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Recording](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_mp_r53f7ff4_00_recording-12-0.html), Recording Configuration Task Flow > Enable Built in Bridge for Cluster. Checked 2026-09-25. [^80]: Recording can fail when Built-in Bridge is On and Media Termination Point Required is checked for the device. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Recording](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_mp_r53f7ff4_00_recording-12-0.html), Recording Configuration Task Flow > Enable Built in Bridge for a Phone, note. Checked 2026-09-25. [^81]: Automatic silent recording records all calls on the configured line appearance and gives no indication on the phone. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Recording](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_mp_r53f7ff4_00_recording-12-0.html), Recording Overview > recording modes. Checked 2026-09-25. [^82]: The agent line's Recording Option field has three values: Call Recording Disabled, Automatic Call Recording Enabled and Selective Call Recording Enabled. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Recording](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_mp_r53f7ff4_00_recording-12-0.html), Recording Configuration Task Flow > Configure Agent Phone Line. Checked 2026-09-25. [^83]: The From header of recording INVITEs carries parameters x-nearend or x-farend, x-refci, x-nearenddevice, x-farendrefci, x-farenddevice and x-farendaddr to identify the stream, the call leg and the parties. Source: [Recording Use Cases for Cisco Unified Communications Manager](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/configExamples/cucm_b_recording-use-cases.html), SIP Header Enhancement for Recording Sessions, From header example. Checked 2026-09-25. [^84]: Recording sessions are torn down when the agent puts the call on hold and are re-established when the agent resumes the call. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Recording](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_mp_r53f7ff4_00_recording-12-0.html), Recording Interactions and Restrictions > Recording Calls Do Not Survive Agent Hold. Checked 2026-09-25. [^85]: When the agent (near end) transfers a call, the existing recording sessions end with BYE and new sessions start, including for the consultation call. Source: [Recording Use Cases for Cisco Unified Communications Manager](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/configExamples/cucm_b_recording-use-cases.html), Transfer and Conference Handling > Near-End Party (Agent) Transfers. Checked 2026-09-25. [^86]: When the far-end party transfers the call, Unified CM sends the recorder UPDATE messages carrying the new x-farendaddr. Source: [Recording Use Cases for Cisco Unified Communications Manager](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/configExamples/cucm_b_recording-use-cases.html), Transfer and Conference Handling > Far-End Party Transfers. Checked 2026-09-25. [^87]: The Unified CM 12.5(1) Recording chapter already documents Multi-Fork Recording, the media source selection table, the Builtin Bridge Enable parameter, the two notification tone parameters and the rule that recording does not survive agent hold. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 12.5(1) - Recording](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/12_5_1/featureConfig/cucm_b_feature-configuration-guide-1251/cucm_b_feature-configuration-guide-1251_chapter_01010.html), Recording chapter: Multi-Fork Recording; Recording Media Source Selection; Enable Built in Bridge for Cluster; Configure Recording Notification Tones; Recording Calls Do Not Survive Agent Hold. Checked 2026-09-25.