McDewey

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

Page 12

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

In this use case, the following entities participate: • The customer call originates from DN1000 deviceA in the local cluster. • The agent receives the call at DN2000 deviceB. • The customer transfers the call to DN1100 deviceC in the same local cluster. During an automatic call recording session that involves a customer (far-end party) in the local cluster that places the call to the agent and then later transfers the call to another far-end party in the local cluster, the following steps take place: 1. PartyA (far-end party = customer in local cluster) calls partyB (near-end party = agent). 2. 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. Party A (far-end party = customer in local cluster) initiates a consultation transfer of the call to another party, party C at DN1100, in the local cluster. 8. Once the consultation transfer is initiated, the recording is stopped. 9. Party C answers the transferred call. 10. Party A completes the transfer. 11. After the transfer is completed, Party B and Party C get connected. 12. As Party B has automatic recording enabled, the recording is restarted for the connection between party B and party C. Note the following particularities of call processing that apply in this use case: • After first press of the Transfer key, because no change in the far-end party information occurs, Cisco Unified Communications Manager does not update the recorder. • After the second press of the Transfer key, Cisco Unified Communications Manager restarts the recording. Note the following particularities of call processing that apply in this use case: 1. Insertion of MOH when the far-end party places the call on hold does not cause a change in the far-end party. 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 12