3.17.5 Message Processing Events and Sequencing Rules
The first category of messages deals with the quality of the voice transmission or the capability of the remote computer that has the hardware configured to make and receive audio signals. Real-time communications (RTC) allows for the bandwidth usage to be of a set sampling rate by calling the method put_MaxBitRate on the IRTCClient interface. RTC also has a method that can be called to check if the local computer has the capability to do VoIP communications, InvokeTuningWizard also on the IRTCClient interface.
The Remote Assistance Protocol allows for an application to signal a request to lower or raise the bandwidth used with the messages BANDWTOLOW and BANDWTOHIGH, respectively. When the message is received, the implementing application MUST set the MaxBitRate to 6,400 (when BANDWTOLOW is received) and MUST set the MaxBitRate to 64,000 (when BANDWTOHIGH is received). These messages can be sent if a lower or higher bandwidth usage is needed.
The Remote Assistance Protocol allows for an application to signal that the RTC wizard failed or succeeded when it checked for the hardware and drivers needed to do VoIP communications on the local computer. If the WIZARDBAD message is received, the receiving side SHOULD NOT attempt to initiate VoIP communication with the remote computer. If the WIZARDGOOD message is received, the receiver MAY attempt to initiate VoIP communications.
The second category of messages deals with the initialization of VoIP using real-time communications (RTC) (for more information, see [MSDN-RTC]). The novice MUST act as the RTC server. The messages exchanged validate that the request for voice communication is wanted by the other user, can be utilized by the remote system, and can provide the encryption key and IP address of the RTC server to the client. This message exchange is detailed in the diagrams shown in section 3.17.
The first message sent (if the expert initiated the request for VoIP) or received (if the novice initiated the request) is the PRESTART message. This message signals the expectation for voice communications. If VoIP is not wanted, the response to this message is VOIPQNO, and the exchange is considered complete. If VoIP is wanted by the receiver, the message PRESTARTYES is sent.
After receiving the PRESTARTYES message, the initiator of the VoIP request signals the capability and readiness to start VoIP communications by sending the VOIPPREGO message. If sent by the expert, it signals that the application is ready to use RTC to start VoIP communications. The expert SHOULD have access to the IRTCClient interface and have checked if the hardware has been tuned for VoIP use with a call to the IsTuned method on the IRTCClient interface before sending this message. If sent by the novice, it is a query to determine if the expert can use RTC for VoIP. If the expert receives the message VOIPPREGO, it SHOULD obtain a pointer to the IRTCClient interface and determine if the hardware has been tuned for VoIP use with a call to the IsTuned method. If the expert fails to do these things, the expert MUST send the message VOIPGONO to the novice. If the expert succeeds, it MUST send the message VOIPPREGO2.
At this stage, the expert is waiting for the creation of the RTC server on the novice side and is waiting for a message from the novice. If the expert receives VOIPGONO, it signals that the creation of the RTC server failed. If the expert receives VOIPGO, it signals that the RTC server has been successfully created, and the expert can now connect. The VOIPGO message has two attributes that are used to make the connection, the key used to encrypt the data being sent between the two computers, and the IP list that the novice is listening on (see the VOIPGOKEY and VOIPIPLIST attributes in section 2.2.2). Using the PC-to-PC call model provided by RTC, the expert connects to the novice through RTC and can now send and receive audio data.
When either side wants to end the VoIP communications, the message PRESTART MUST be sent. When this message is received, and VoIP is already established, the receiver SHOULD clean up the RTC objects it has referenced and SHOULD send the PRESTARTYES message when finished.
The following diagram show the messages exchanged while setting up and cleaning up after a VoIP session.

Figure 20: Remote Assistance VoIP session message exchange