3.3.5.3.3 Processing MCS Connect Initial PDU with GCC Conference Create Request

The structure and fields of the MCS Connect Initial PDU with GCC Conference Create Request are specified in section 2.2.1.3. A basic high-level overview of the nested structure for the MCS Connect Initial PDU is illustrated in section 1.3.1.1, in the figure specifying MCS Connect Initial PDU.

If Enhanced RDP Security (section 5.4) is in effect, the External Security Protocol (section 5.4.5) MUST be used to decrypt and verify the integrity of the entire PDU prior to any processing taking place.

The embedded length fields within the tpktHeader field ([T123] section 8) MUST be examined for consistency with the received data. If there is any discrepancy, the connection SHOULD be dropped.

The MCS Connect Initial PDU (embedded within the mcsCi field) is specified in [T125] section 7, part 2. The server SHOULD ignore the calledDomainSelector, callingDomainSelector, and upwardFlag fields of this PDU.

The domain parameters (contained in the targetParameters, minimumParameters, and maximumParameters fields) received in the MCS Connect Initial PDU are examined and the resultant parameters determined. The following pseudo-code describes the process employed by the server to merge the domain parameters. If the server is unable to successfully merge the domain parameters, the connection SHOULD be dropped.

 //
 // Merges the fields contained in the targetParameters, minimumParameters, and
 // maximumParameters fields. Returns TRUE if the domain parameters were successfully 
 // merged, FALSE otherwise.
 //
 BOOL
 MergeDomainParameters(
     DomainParameters targetParameters,
     DomainParameters minimumParameters,
     DomainParameters maximumParameters,
     DomainParameters* pOutParameters
     )
 {
     //
     // maxChannelIds
     //
     if (targetParameters.maxChannelIds >= 4)
     {
         pOutParameters->maxChannelIds = targetParameters.maxChannelIds;
     }
     else if (maximumParameters.maxChannelIds >= 4)
     {
         pOutParameters->maxChannelIds = 4;
     }
     else
     {
         return FALSE;
     }
            
     //
     // maxUserIds
     //
     if (targetParameters.maxUserIds >= 3)
     {
         pOutParameters->maxUserIds = targetParameters.maxUserIds;
     }
     else if (maximumParameters.maxUserIds >= 3)
     {
         pOutParameters->maxUserIds = 3;
     }
     else
     {
         return FALSE;
     }
            
     //
     // maxTokenIds
     //
     pOutParameters->maxTokenIds = targetParameters.maxTokenIds;
            
     //
     // numPriorities
     //
     if (minimumParameters.numPriorities <= 1)
     {
         pOutParameters->numPriorities = 1;
     }
     else
     {
         return FALSE;
     }
     
            
     //
     // minThroughput
     //
     pOutParameters->minThroughput = targetParameters.minThroughput;
            
     //
     // maxHeight
     //
     if ((targetParameters.maxHeight == 1) || 
         (minimumParameters.maxHeight <= 1))
     {
         pOutParameters->maxHeight = 1;
     }
     else
     {
         return FALSE;
     }
            
     //
     // maxMCSPDUsize
     //
     if (targetParameters.maxMCSPDUsize >= 124) 
     {
         if (targetParameters.maxMCSPDUsize <= 65528) 
         {
             pOutParameters->maxMCSPDUsize = targetParameters.maxMCSPDUsize;
         }
         else if (minimumParameters.maxMCSPDUsize >= 124 &&
                  minimumParameters.maxMCSPDUsize <= 65528) 
         {
             pOutParameters->maxMCSPDUsize = 65528;
         }
         else 
         {
             return FALSE;
         }
     }
     else 
     {
         if (maximumParameters.maxMCSPDUsize >= 124) 
         {
             pOutParameters->maxMCSPDUsize = maximumParameters.maxMCSPDUsize;
         }
         else 
         {
             return FALSE;
         }
     }
            
     //
     // protocolVersion
     //
     if ((targetParameters.protocolVersion == 2) || 
         (minimumParameters.protocolVersion <= 2 && maximumParameters.protocolVersion >= 2))
     {
         pOutParameters->protocolVersion = 2;
     }
     else
     {
         return FALSE;
     }
            
     return TRUE;    
 }

The userData field of the MCS Connect Initial PDU contains the GCC Conference Create Request (embedded within the gccCCrq field). The GCC Conference Create Request is described in [T124] section 8.7 and appended as user data to the MCS Connect Initial PDU using the format specified in [T124] sections 9.5 and 9.6.

The server MUST ensure that the size of the GCC Conference Create Request data is within bounds. If Extended Client Data Blocks are not supported (section 2.2.1.2.1), then the maximum allowed size of the GCC Conference Create Request data is 1024 bytes. If Extended Client Data Blocks are supported, then the maximum allowed size is 4096 bytes. If the size of the GCC Conference Create Request data is invalid, the server MUST close the connection as specified in section 3.3.5.3.3.1.

If the size of the GCC Conference Create Request data is valid, processing MUST continue. The server MAY ignore all of the GCC Conference Create Request fields, except for the userData field. The userData field of the GCC Conference Create Request MUST contain basic client settings data blocks (sections 2.2.1.3.2 through 2.2.1.3.5). The server MUST check that the client-to-server H.221 nonstandard key embedded at the start of the userData field ([T124] section 8.7 for a description of the structure of user data) is the ANSI character string "Duca". If this is not the case, the server MUST close the connection as specified in section 3.3.5.3.3.1.

All of the encoded lengths within the MCS Connect Initial PDU and the GCC Conference Create Request MUST also be examined for consistency with the received data. If there is any discrepancy, the server MUST close the connection as specified in section 3.3.5.3.3.1.

Once the mcsCi and gccCCrq fields have been successfully parsed the server examines the basic client settings data blocks in the GCC Conference Create Request user data and stores this data in the Received Client Data store (section 3.3.1.1). However, before the data is stored, the basic client settings data blocks are checked for validity.

Select settings in the Client Core Data (section 2.2.1.3.2) are validated using the following rules.

Client core data field	Validation rule
desktopWidth	If this field contains a value greater than the maximum allowed width,<45> it is implicitly assumed to equal the maximum allowed width.
desktopHeight	If this field contains a value greater than the maximum allowed height,<46> it is implicitly assumed to equal the maximum allowed height.
colorDepth	If this field does not contain a valid color depth (valid values are specified in section 2.2.1.3.2) and the postBeta2ColorDepth field is not present, the server MUST close the connection as specified in section 3.3.5.3.3.1.
postBeta2ColorDepth	If this field does not contain a valid color depth (valid values are specified in section 2.2.1.3.2) and the highColorDepth field is not present, the server MUST close the connection as specified in section 3.3.5.3.3.1.
highColorDepth	If this field does not contain a valid color depth (valid values are specified in section 2.2.1.3.2), a value of 8 bits per pixel is assumed.
serverSelectedProtocol	If this field does not contain the same value that the server transmitted to the client in the RDP Negotiation Response (section 3.3.5.3.2), the server SHOULD drop the connection. In the event that this optional field is not present, the value PROTOCOL_RDP (0) MUST be assumed.

The encryptionMethods and extEncryptionMethods fields in the Client Security Data (section 2.2.1.3.3) are examined to ensure that they contain at least one valid flag. If no valid flags are present, the server MUST close the connection as specified in section 3.3.5.3.3.1.

If the Client Network Data (section 2.2.1.3.4) is included in the Settings Data, the server MUST check that the channelCount field is within bounds. Furthermore, the data supplied in the channelDefArray MUST be complete. If these two conditions are not met, the server MUST close the connection as specified in section 3.3.5.3.3.1.

Once the basic client settings data blocks have been processed successfully, the server MUST send the MCS Connect Response PDU with GCC Conference Create Response (section 2.2.1.4) to the client.