2.2.1.3 Client MCS Connect Initial PDU with GCC Conference Create Request

The MCS Connect Initial PDU is an RDP Connection Sequence PDU sent from client to server during the Basic Settings Exchange phase of the RDP Connection Sequence (see section 1.3.1.1 for an overview of the RDP Connection Sequence phases). It is sent after receiving the X.224 Connection Confirm PDU (section 2.2.1.2). The MCS Connect Initial PDU encapsulates a GCC Conference Create Request, which encapsulates concatenated blocks of settings data. A basic high-level overview of the nested structure for the Client MCS Connect Initial PDU is illustrated in section 1.3.1.1, in the figure specifying the MCS Connect Initial PDU. Note that the order of the settings data blocks is allowed to vary from that shown in the previously mentioned figure and the message syntax layout that follows. This is possible because each data block is identified by a User Data Header structure (section 2.2.1.3.1).

tpktHeader (4 bytes): A TPKT Header, as specified in [T123] section 8.

x224Data (3 bytes): An X.224 Class 0 Data TPDU, as specified in [X224] section 13.7.

mcsCi (variable): Variable-length Basic Encoding Rules encoded (BER-encoded) MCS Connect Initial structure (using definite-length encoding) as described in [T125] section 11.1 (the ASN.1 structure definition is detailed in [T125] section 7, part 2). The userData field of the MCS Connect Initial encapsulates the GCC Conference Create Request data (contained in the gccCCrq and subsequent fields). If the server did not advertise support for extended client data (section 2.2.1.2.1), then the maximum allowed size of the userData field is 1024 bytes, and the combined size of the gccCCrq and subsequent fields MUST be less than 1024 bytes. However, if the server did advertise support for extended client data, then the maximum allowed size of the userData field is 4096 bytes and the gccCCrq and subsequent fields MUST be less than 4096 bytes.

gccCCrq (variable): Variable-length Packed Encoding Rules encoded (PER-encoded) GCC Connect Data structure, which encapsulates a Connect GCC PDU that contains a GCC Conference Create Request structure as described in [T124] (the ASN.1 structure definitions are detailed in [T124] section 8.7) appended as user data to the MCS Connect Initial (using the format described in [T124] sections 9.5 and 9.6). The userData field of the GCC Conference Create Request contains one user data set consisting of concatenated Client Data Blocks.

clientCoreData (variable): Variable-length Client Core Data structure (section 2.2.1.3.2).

clientSecurityData (12 bytes): Client Security Data structure (section 2.2.1.3.3).

clientNetworkData (variable): Variable-length Client Network Data structure (section 2.2.1.3.4).

clientClusterData (12 bytes): Optional Client Cluster Data structure (section 2.2.1.3.5).

clientMonitorData (variable): Variable-length Client Monitor Data structure (section 2.2.1.3.6). This field MUST NOT be included if the server did not advertise support for Extended Client Data Blocks by using the EXTENDED_CLIENT_DATA_SUPPORTED flag (0x00000001) as described in section 2.2.1.2.1.

clientMessageChannelData (8 bytes): Optional Client Message Channel Data structure (section 2.2.1.3.7). This field MUST NOT be included if the server did not advertise support for Extended Client Data Blocks by using the EXTENDED_CLIENT_DATA_SUPPORTED flag (0x00000001) as described in section 2.2.1.2.1.

clientMultitransportChannelData (8 bytes): Optional Client Multitransport Channel Data structure (section 2.2.1.3.8). This field MUST NOT be included if the server did not advertise support for Extended Client Data Blocks by using the EXTENDED_CLIENT_DATA_SUPPORTED flag (0x00000001) as described in section 2.2.1.2.1.

clientMonitorExtendedData (variable): Variable-length Client Monitor Extended Data structure (section 2.2.1.3.10). This field MUST NOT be included if the server did not advertise support for Extended Client Data Blocks by using the EXTENDED_CLIENT_DATA_SUPPORTED flag (0x00000001) as described in 2.2.1.2.1.