/mcpthe endpoint MUST present the call security level dictated by the Unified CM in the Call-Info header), especially if the call security level specified by Unified CM is lower than the endpoint’s call leg security level. For instance, if the endpoint is using encrypted TLS signaling and SRTP media, the Unified CM may still signal a call security level of 'NotAuthenticated' or 'Authenticated' as Unified CM allows mixing of secure and non-secure call legs through external conference bridges. The endpoint must comply with the above statement if they advertise the X-cisco-sis-2.0.0 or greater release tag. If they do not advertise the tag, then the Unified CM restricts media negotiation to RTP for that endpoint. The one exception to this rule is the Third-Party AS-SIP Endpoint, which supports SRTP but does not support signaling of this tag. Since Unified CM is a B2BUA, we must look at call setup and mid call updates to determine when the Call-Info header will be sent (for example, which method or response). Call Setup: • Originating side (A side): When the phone originates an INVITE to Unified Communications Manager, assuming Unified CM extends the call forward, the security status will be known when the 200 OK is generated back to the phone. The 200 OK will contain the Call-Info header as indicated above. • Terminating side (B side): Unified Communications Manager does not evaluate the security status of the call until both endpoints are connected from a signaling perspective. For a call leg that terminates on a SIP device, the value is known when the ACK is sent to the device. However, 3261 precludes an ACK from containing a Call-Info header. Therefore, it will be sent in a subsequent re-INVITE or UPDATE. Mid call Updates: Feature invocations cause dialogs to be manipulated. The security status is impacted. For example, endpoints A and B are connected securely but A is transferred to C which is unsecure. For endpoints already involved in a call, a change in status will be sent through a re-INVITE or UPDATE. In the example given, endpoint A receives a re-INVITE or UPDATE containing the Call-Info header with a new security status. XSI Icon Display The Conference List (XSI-based) feature will now be able to include security icon information in the data sent to supporting endpoints for each participant in a conference call. This icon information will not display properly on phones which do not support the additional information. Unified Communications Manager must be aware of what the version of the phone’s XSI SDK is to include or exclude the new icon information in the Conference List display. For this reason, all phones which support the new XSI content must advertise X-cisco-xsi-6.0.1 or greater release in the Supported header tags that are sent during registration. Orientation Mid call feature invocations can cause the display orientation on the phone to change directions. For example, Alice calls Bob. Bob’s phone indicates that the call is 'From Alice' assuming Alice’s caller id is not restricted. While talking with Bob, Alice creates an ad hoc conference with Charlie. Bob’s phone should show 'To Conference'. The orientation has changed. It was 'From Alice' and now it is 'To Conference'. The caller id information sent in the Remote-Party-Id header only includes the name (for example, 'Alice' or 'Conference'). Note that from a SIP perspective, Alice had placed a call to Bob. Originally, Bob’s display had reflected 'From' which also happened to reflect the direction of the SIP dialog relative to Bob’s phone (that is, the dialog was from the Unified CM). When Bob’s call leg was redirected to the conference server, the orientation of the SIP dialog did not change. Media was redirected to an alternative destination. SIP Line Messaging Guide (Standard Edition) for Cisco Unified Communications Manager 53 SIP Standard Line Interface XSI Icon Display