McDewey

Multi-vendor documentation library · semantic search · MCP endpoint at /mcp

Page 11

↗ View in doc context
page
11
source
cucm/v15/recording-use-cases/cucm-15-recording-use-cases.md
chunk_id
cucm::v15::recording-use-cases::cucm-15-recording-use-cases::10

PartyB answers the call. 3. Because the agent line appearance is configured for automatic recording, the recording session for the media streams automatically gets triggered. Cisco Unified Communications Manager first makes a recording call to the built-in bridge (BIB) of the agent IP phone for the agent voice. 4. Cisco Unified Communications Manager makes the second recording call to the BIB of the agent IP phone for the customer voice. 5. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the agent voice through a SIP trunk. The agent IP phone starts to fork the agent voice stream to the recorder. 6. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the customer voice through a SIP trunk. The agent IP phone starts to fork the customer voice stream to the recorder. 7. PartyA (far-end party = customer in local cluster) places the call on hold. 8. Once the call is placed on hold, the existing recording is stopped. 9. PartyA (far-end party = customer in local cluster) resumes the held call from deviceA’ (a different device with same DN). Upon call resumption, partyB is now connected to the new far-end partyA’. The far-end call information has changed. 10. As the call has been resumed now, the recording is restarted. Note the following particularities of call processing that apply in this use case: • Insertion of MOH when the far-end party places the call on hold does not cause a change in the far-end party. • When another device that shares the line resumes the call, the recording is restarted. Note the header information of the INVITE message from step5. The SIP header enhancement feature adds the information in bold text to the message header. Step 5 INVITE Message Header Information From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB; x-farendrefci=ci1;x-farenddevice=deviceA;x-farendaddr=1000>;tag=fromtag1 Far-End Party Transfers Call to Another Far-End Party in Local Cluster In this use case for automatic call recording, the far-end party in the local cluster transfers the call to another far-end party in the same local cluster. The following figure illustrates this use case. Figure 12: Far-End Party in Local Cluster Transfers Call to Another Far-End Party in Local Cluster 11