3.5.5 Message Processing Events and Sequencing Rules
This section describes the sequence of the control packets that the expert receives, as well as the control message packets with which the expert responds.

Figure 5: Remote Assistance session initialization sequence diagram for version 2
After the novice initiates Remote Assistance, the expert can obtain the Remote Assistance Connection String in any of the following methods:
Obtains the Remote Assistance Connection String 1 using the IPCHService ([MS-RAI] section 3.2).
Obtains the Remote Assistance Connection String 2 using IRASrv ([MS-RAI] section 3.4).
Obtains the Remote Assistance Connection String 1 using the RCTICKET attribute of the Remote Assistance Invitation File of first type ([MS-RAI] section 6).
Obtains the Remote Assistance Connection String 2 using the LHTICKET attribute of the Remote Assistance Invitation File of second type ([MS-RAI] section 6).
If the expert obtains the Remote Assistance Connection String 2, it MUST use the version 2 protocol. Otherwise, version 1 MUST be used (as specified in section 3.3).
If the expert obtains the Remote Assistance Connection String 2 during the connection sequence, and encryption is selected for the RDP session; that is. a nonzero encryptionMethod in TS_UD_SC_SEC1 (see [MS-RDPBCGR] section 2.2.1.4.3), the client validates the public key of the server certificate contained in the Server Security Data (TS_UD_SC_SEC1).
On receiving the TS_UD_SC_SEC1 from the server, the client calculates the hash of the public key, and compares its base64-encoded string against the value of the key hash parameter of the Auth String Node <A>. The hashing algorithm is determined by the key hash parameter in the Auth String Node <A> as specified in [MS-RAI] section 2.2.2. The validation is successful if they are an exact match. Otherwise, if the validation fails, the server certificate is considered invalid and the client disconnects the session.
As soon as the basic Remote Assistance Connection is established, the expert receives the REMOTEDESKTOP_CTL_SERVER_ANNOUNCE (section 2.2.1.7) and REMOTEDESKTOP_CTL_VERSIONINFO (section 2.2.1.8) packets. The expert drops the REMOTEDESKTOP_CTL_VERSIONINFO packet and announces to the novice to use the version 2 protocol by sending the REMOTEDESKTOP_EXPERT_ON_VISTA (section 2.2.1.12) packet. The expert also responds to the REMOTEDESKTOP_CTL_SERVER_ANNOUNCE (section 2.2.1.7) packet by sending the REMOTEDESKTOP_CTL_VERIFY_PASSWORD (section 2.2.1.11) packet.
The novice MUST respond to the REMOTEDESKTOP_CTL_VERIFY_PASSWORD (section 2.2.1.11) packet by verifying the Remote Assistance Connection String, as specified in [MS-RAI] Appendix A, and return SAFERROR_NOERROR to the expert indicating that the Remote Assistance Connection String is valid. If the Remote Assistance Connection String is not valid, the novice MUST return PASSWORDS_DONT_MATCH.
The REMOTEDESKTOP_CTL_RESULT (section 2.2.1.10) packet can be received with the following error codes.
|
Value |
Meaning |
|---|---|
|
SAFERROR_NOERROR |
No error occurred. |
|
SAFERROR_HELPEESAIDNO |
Sent from the novice to the expert when the novice rejects the Remote Assistance Connection. This error is returned when the novice rejects Remote Assistance by clicking "No" in the Remote Assistance Acceptance UI dialog box; otherwise, when the novice clicks "Yes" in this UI dialog box, the novice desktop shadowing completes, and the expert can view the novice screen. |
|
PASSWORDS_DONT_MATCH |
MUST be returned by the novice when the password used produces an invalid Remote Assistance Connection String.
|
After the novice receives a REMOTEDESKTOP_CTL_RESULT (section 2.2.1.10) packet with SAFERROR_NOERROR, the novice starts desktop shadowing. The expert and novice MAY exchange REMOTEDESKTOP_CTL_RANOVICE_NAME (section 2.2.1.13) and REMOTEDESKTOP_CTL_RAEXPERT_NAME (section 2.2.1.14) packets with each other to update their respective user interfaces.