Security State Notification Sample Clauses
Security State Notification. Secure TIP devices MAY transmit a TIP NOTIFY message following the establishment of a secure TIP session to indicate that despite the use of SRTP, the TIP session MUST be considered as non- secure by the remote peer. Secure TIP devices MAY transmit a TIP NOTIFY message to revert an SRTP TIP session security state from non-secure and back to secure. Secure TIP devices MUST NOT transmit a TIP NOTIFY message over a non-secure TIP session. Secure TIP devices MUST be prepared to receive a TIP NOTIFY message and MUST inform the user of the security state indicated by the NOTIFY message. TIP devices receiving a TIP NOTIFY message over a non-secure TIP session MUST ignore those.
Security State Notification. Secure TIP devices MAY transmit a TIP NOTIFY message following the establishment of a secure TIP session to indicate that despite the use of SRTP, the TIP session MUST be considered as non- secure by the remote peer. Secure TIP devices MAY transmit a TIP NOTIFY message to revert an SRTP TIP session security state from non-secure and back to secure. Secure TIP devices MUST NOT transmit a TIP NOTIFY message over a non-secure TIP session. Secure TIP devices MUST be prepared to receive a TIP NOTIFY message and MUST inform the user of the security state indicated by the NOTIFY message. TIP devices receiving a TIP NOTIFY message over a non-secure TIP session MUST ignore those. Figure 7 shows a call setup between two secure TIP endpoints. The first INVITE transaction negotiates a single audio and video media line with H264 and AAC. The negotiated media line might have an AVP or an SAVP RTP profile. Once the initial call setup completes, each secure TIP device starts two DTLS-SRTP sessions for each media line irrespective of whether the AVP or the SAVP profile was negotiated for the media line.
1. The DTLS-SRTP session for which the TIP device acts as a client will be used by the device to generate its SRTP and SRTCP master keys used for encryption. The crypto algorithm negotiated in the session will also be used for transmitted packet authentication and encryption
2. The DTLS-SRTP session for which the TIP device acts as a server will be used by the device to generate the SRTP and SRTCP master keys used for decryption. The crypto algorithm negotiated in the session will also be used for received packets authentication and decryption Once both DTLS-SRTP sessions have completed successfully for a specific (S)RTP session, the TIP device starts its secure TIP negotiation. From now on the call flow should follow the same pattern as described in 4.1 except that SRTP and SRTCP packets are transmitted and received rather than RTP and RTCP packets.