McDewey

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

Page 33

↗ View in doc context
page
33
source
cucm/v12.0.1/sip-line-messaging/sip-line-messaging.md
chunk_id
cucm::v12.0.1::sip-line-messaging::sip-line-messaging::31

The transferor call flow, which uses a REFER with embedded replaces header, is based on the existing implementation of this feature on the SIP phones and gateways. The problem with this implementation in a peer-to-peer environment is the failure to support parallel forking to multiple targets. Version 04 of the replaces draft specifically precludes a UAS from accepting a replaces header that was not initiated by that UA. The receiving UAS must return a 481 message in that situation. Instead, the existing implementation honors the request and replaces the early dialog. That causes it to send a 487 message back to the transferor. Early attended transfer involves two somewhat independent dialogs at the transferor device up until the time that the device sends a REFER with embedded replaces header. When this message is received, Unified CM registers that the calls are associated. Because Unified CM is a B2BUA, a REFER with a replaces header does not trigger an INVITE with replaces from the transferee to the transfer target. The dialogs between Unified CM and each phone stay independent. Instead, Unified CM reINVITEs (and UPDATEs) the transferee and transfer target to connect them together. During this process, the transferor will receive sipfrag NOTIFY messages. After the connection is complete, both dialogs between Unified CM and transferor get BYE’d. The following more detailed view shows what happens when the REFER is received: 1. Split transferor and transferee call: • reINVITE to disconnect media. 2. Split transferor and transfer target call: • reINVITE sent to transferor to disconnect media. 3. Join transferee and transfer target call legs: a. reINVITE to connect media. b. UPDATE display name and number via the Remote-Party-ID header. c. Clear transferor dialogs. The transferee will not receive a ringback although the target is alerting. Blind Transfer With blind transfer, the transferor places the original call on hold and dials the target. The transferor then uses SIP REFER to redirect the transferee to the target. No call gets made to the target prior to transfer. The timing for when the transferor drops out of the call depends on the transferor implementation of the feature, but, most likely, the drop occurs when the transferor is notified that the redirect operation was accepted and has begun. The REFER does not contain an embedded replaces as it does for attended and early attended transfer. Three-Way Calling Many SIP phones support local mixing by the endpoint. For example, the existing SIP implementation on the Cisco Unified IP Phone 7960/40 supports it. It continues to work for Unified CM line-side SIP endpoints. To support local mixing on the phone, Unified CM must allow the endpoint to have multiple active calls. Unified CM allows this for SIP endpoints. From the Unified CM perspective, a locally mixed three-way call (or an n-way call) just looks like individual active calls. Unified CM does not perceive local mixing. Unified CM conference-related features like Conference List and Remove Last Party do not apply. SIP Line Messaging Guide (Standard Edition) for Cisco Unified Communications Manager 29 SIP Standard Line Interface Blind Transfer