3.1.5.5 Receive Security Handshake Message
When a Miracast Sink receives a Security Handshake message (section 2.2.3) and one of the following is true, it MUST proceed to complete the DTLS handshake procedure:
The Sink is in the Socket Connected state (section 3.1.1).
The Sink is in the Waiting for Security Handshake state (section 3.1.1).
The Sink is currently in the DTLS Handshake state (section 3.1.1) and this is an additional message.
In all other cases, the Sink MUST ignore the message and MUST tear down the connection on TCP port 7250.
The DTLS handshake procedure is performed by parsing the Security Token TLV (section 2.2.7.4) as a message in the DTLS exchange [RFC6347]. The sink should respond with a Security Handshake message containing the DTLS payload in the Security Token TLV as specified in [RFC6347]. Note that each message in the DTLS exchange requires zero or more responses. Upon sending a Security Handshake message which requires a response from the Source, the Sink MUST begin the Security Handshake Message Timer and reset the timer upon receipt of the next message.
Upon completion of the DTLS handshake, the DTLS Encryption Key is stored for the remainder of the session (section 3.1.1). If the Security Options have been set (section 3.1.1), indicating the Source sent a Session Request message (section 2.2.4), then the TLVArray of all further messages MUST be encrypted by the sender and decrypted by the receiver using the DTLS Encryption Key. If the Security Options have the SinkDisplaysPin bit set, then the sink goes to the Waiting for PIN state (section 3.1.1).