Export (0) Print
Expand All

6 Appendix A: Product Behavior

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include released service packs:

  • Windows XP operating system

  • Windows Server 2003 operating system

  • Windows Vista operating system

  • Windows Server 2008 operating system

  • Windows 7 operating system

  • Windows Server 2008 R2 operating system

  • Windows 8 operating system

  • Windows Server 2012 operating system

  • Windows 8.1 operating system

  • Windows Server 2012 R2 operating system

Exceptions, if any, are noted below. If a service pack or Quick Fix Engineering (QFE) number appears with the product version, behavior changed in that service pack or QFE. The new behavior also applies to subsequent service packs of the product unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms SHOULD or SHOULD NOT implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term MAY implies that the product does not follow the prescription.

<1> Section 2.1: In Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2, the client MUST advertise the static virtual channel named "RDPDR", as defined in [MS-RDPEFS]. If that channel is not advertised, the server will not issue any communication on the "RDPSND" channel.

<2> Section 2.1: Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 always use unreliable UDP for dynamic virtual channel if the following three conditions are true. Otherwise, reliable transport is used.

  • An unreliable UDP transport is available.

  • The protocol version of both client and server is at least version 8.

  • The AAC codec is used to compress data.

<3> Section 2.2.2.1:

Client and server version

Meaning

0x02

Windows XP

0x05

Windows XP SP1, Windows XP SP2, and Windows XP SP3

0x05

Windows Server 2003

0x05

Windows Vista

0x05

Windows Server 2008

0x06

Windows 7

0x06

Windows Server 2008 R2

0x08

Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2

<4> Section 2.2.2.1.1: For more information about registering format information, see [RFC2361].

For more information about Pulse-Code Modulation (PCM), see [G711].

For more information about Global System for Mobile communications (GSM), see [ETSI-GSM].

The following tables show codecs and associated format tags that are supported by default on the different versions of Windows, which support audio redirection. Unless otherwise specified, information about these codecs may be found in [RFC2361].

The following codecs are supported by default on Windows XP:

Codec name

Format tag

DSP Group, Inc. TrueSpeech

WAVE_FORMAT_DSPGROUP_TRUESPEECH

0x0022

ISO/MPEG Layer 3 [ISO/IEC 11172-3]

WAVE_FORMAT_MPEGLAYER3

0x0055

Microsoft PCM

WAVE_FORMAT_PCM

0x0001

Microsoft Adaptive PCM

WAVE_FORMAT_ADPCM

0x0002

Microsoft ALAW

WAVE_FORMAT_ALAW

0x0006

Microsoft G.723 [G723.1]

WAVE_FORMAT_MSG723

0x0042

Microsoft GSM

WAVE_FORMAT_GSM610

0x0031

Microsoft MULAW

WAVE_FORMAT_MULAW

0x0007

Voxware, Inc. AC10

WAVE_FORMAT_VOXWARE_AC10

0x0071

Voxware, Inc. AC16

WAVE_FORMAT_VOXWARE_AC16

0x0072

Voxware, Inc. AC20

WAVE_FORMAT_VOXWARE_AC20

0x0073

Voxware, Inc. AC8

WAVE_FORMAT_VOXWARE_AC8

0x0070

The following codecs are supported by default on Windows Server 2003:

Codec name

Format tag

DSP Group, Inc. TrueSpeech

WAVE_FORMAT_DSPGROUP_TRUESPEECH

0x0022

ISO/MPEG Layer 3

WAVE_FORMAT_MPEGLAYER3

0x0055

Microsoft PCM

WAVE_FORMAT_PCM

0x0001

Microsoft Adaptive PCM

WAVE_FORMAT_ADPCM

0x0002

Microsoft ALAW

WAVE_FORMAT_ALAW

0x0006

Microsoft G.723

WAVE_FORMAT_MSG723

0x0042

Microsoft GSM

WAVE_FORMAT_GSM610

0x0031

Microsoft MULAW

WAVE_FORMAT_MULAW

0x0007

Voxware, Inc. AC20

WAVE_FORMAT_VOXWARE_AC20

0x0073

The following codecs are supported by default on Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2:

Codec name

Format tag

Microsoft PCM

WAVE_FORMAT_PCM

0x0001

Microsoft Adaptive PCM

WAVE_FORMAT_ADPCM

0x0002

Microsoft ALAW

WAVE_FORMAT_ALAW

0x0006

Microsoft G.723

WAVE_FORMAT_MSG723

0x0042

Microsoft GSM

WAVE_FORMAT_GSM610

0x0031

Microsoft MULAW

WAVE_FORMAT_MULAW

0x0007

The following codecs are supported by default on Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2:

Codec name

Format tag

Microsoft PCM

WAVE_FORMAT_PCM

0x0001

Microsoft Adaptive PCM

WAVE_FORMAT_ADPCM

0x0002

Microsoft ALAW

WAVE_FORMAT_ALAW

0x0006

Microsoft G.723

WAVE_FORMAT_MSG723

0x0042

Microsoft GSM

WAVE_FORMAT_GSM610

0x0031

Microsoft MULAW

WAVE_FORMAT_MULAW

0x0007

Microsoft AAC

WAVE_FORMAT_AAC

0xa106

Microsoft Implementations deviate from the GSM standard [ETSI-GSM] while bitpacking coefficients, as described by the following example:

ITU-T Standard Implementation of GSM 610
    if (((*c >> 4) & 0x0F) != GSM_MAGIC) return -1;
    LARc[1]  = (*c++ & 0xF) << 2;                  /* 1 */
    LARc[1] |= (*c >> 6) & 0x3;
    LARc[2]  = *c++ & 0x3F;
    LARc[3]  = (*c >> 3) & 0x1F;
    LARc[4]  = (*c++ & 0x7) << 2;
    LARc[4] |= (*c >> 6) & 0x3;
    LARc[5]  = (*c >> 2) & 0xF;
    LARc[6]  = (*c++ & 0x3) << 2;
    LARc[6] |= (*c >> 6) & 0x3;
    LARc[7]  = (*c >> 3) & 0x7;
    LARc[8]  = *c++ & 0x7;
 
Microsoft Implementaion of GSM 610
    LAR[1] =  (ab[0] & 0x3F);
    LAR[2] = ((ab[0] & 0xC0) >> 6) | ((ab[1] & 0x0F) << 2);
    LAR[3] = ((ab[1] & 0xF0) >> 4) | ((ab[2] & 0x01) << 4);
    LAR[4] = ((ab[2] & 0x3E) >> 1);
    LAR[5] = ((ab[2] & 0xC0) >> 6) | ((ab[3] & 0x03) << 2);
    LAR[6] = ((ab[3] & 0x3C) >> 2);
    LAR[7] = ((ab[3] & 0xC0) >> 6) | ((ab[4] & 0x01) << 2);
    LAR[8] = ((ab[4] & 0x0E) >> 1);

The ITU implementation is Most Significant Bit (MSB) to Least Significant Bit (LSB). The Microsoft Implementation is LSB to MSB. The following coefficients are represented as MSB to LSB. The first line is the bit position in the actual byte, the second line is the coefficient index, and the third line is the bit position of the coefficients.

ITU:
 
BYTE 0            BYTE 1            BYTE 2            BYTE 3
7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0
        1 1 1 1   1 1 2 2 2 2 2 2   3 3 3 3 3 4 4 4   4 4 ...
        5 4 3 2   1 0 5 4 3 2 1 0   4 3 2 1 0 4 3 2   1 0 ...
 
MS:
 
BYTE 3            BYTE 2            BYTE 1            BYTE 0
7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0
                  ... 4 4 4 4 4 3   3 3 3 3 2 2 2 2   2 2 1 1 1 1 1 1
                  ... 4 3 2 1 0 4   3 2 1 0 5 4 3 2   1 0 5 4 3 2 1 0

<5> Section 2.2.2.2:

Client and server version

Meaning

0x02

Windows XP

0x05

Windows XP SP1, Windows XP SP2, and Windows XP SP3

0x05

Windows Server 2003

0x05

Windows Vista

0x05

Windows Server 2008

0x06

Windows 7

0x06

Windows Server 2008 R2

0x08

Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2

<6> Section 2.2.2.3: If the server version is under 6, the Quality Mode PDU will not be handled on the server side. If the server version is at least 6, but the client version is under 6, the Quality Mode PDU will be ignored on the server side.

<7> Section 2.2.3.3: Windows sets this field to the number of milliseconds that have elapsed since the system was started.

<8> Section 2.2.3.5: Windows sets this field to the number of milliseconds that have elapsed since the system was started.

<9> Section 2.2.3.10: Windows sets this field to the number of milliseconds that have elapsed since the system was started.

<10> Section 3.1.3: Windows 8 and Windows Server 2012 will try to create a dynamic virtual channel first. If that fails, they will try to create a static virtual channel.

<11> Section 3.2.5.1.1.2: Windows XP and Windows Server 2003 clients try to negotiate UDP using the API function getsockname. If the function is successful, Windows clients advertise a UDP port. Otherwise, the clients use static virtual channels. For more information about the getsockname function, see [MSDN-getsockname].

Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2 always use static virtual channels, even if the client advertises a UDP port.

Windows 8 and Windows Server 2012 always use virtual channels, even if the client advertises a UDP port.

Windows XP and Windows XP SP1 servers use UDP.

Windows Server 2003, Windows XP SP2, and Windows XP SP3 use UDP if the client advertises a UDP port, with the following exception: if the client version is less than 5, and the data size is greater than the maximum datagram size for the UDP socket, these servers use static virtual channels.

<12> Section 3.2.5.1.1.4: In Windows XP and Windows Server 2003, if a client advertises a UDP port during version exchange, the Training PDUs are first sent over UDP. Static virtual channels are used only if the communication over UDP fails.

In Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2, the training PDU is always sent over static virtual channels even if the client has advertised a UDP port.

In Windows 8 and Windows Server 2012, the training PDU is always sent over virtual channels even if the client has advertised a UDP port.

<13> Section 3.3.2: A Windows server will wait 10 seconds after sending a Server Audio Formats and Version PDU. If a Client Audio Formats and Version PDU is not received within this time, the server terminates the protocol.

<14> Section 3.3.2: Windows XP and Windows Server 2003 servers will wait 1 second after sending a UDPTraining PDU for the Training Confirm PDU. If the Training Confirm PDUs are not received, the server will retry up to 10 times before falling back on static virtual channels.

<15> Section 3.3.2: Windows 7 and Windows Server 2008 R2 servers will wait 10 seconds after receiving a Client Audio Formats and Version PDU. If the Quality Mode PDU is not received, the server uses the DYNAMIC_QUALITY quality mode (section 2.2.2.3).

<16> Section 3.3.5.1.1.2: If a Windows server receives the client PDU before sending the server PDU to the client, the server processes the client PDU as if it were received in the normal sequence (after the server sends the server PDU). If the format list that is contained in the client PDU is not a subset of the format list that is contained in the server PDU, the server handles the format list as if it is a subset of the formats it sends out. The server picks a format from the list, and if the format is not supported by the server, the server will close the virtual channel. If the picked format is supported on the server side, the server will start sending data using that format. Note that even when the server starts sending data, it can change the format later and subsequently close the virtual channel if the changed format is not supported on server side.

<17> Section 3.3.5.1.1.2: Windows XP and Windows Server 2003 use UDP.

Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2 always use virtual channels.

Windows 8 and Windows Server 2012 always use virtual channels.

<18> Section 3.3.5.1.1.3: Windows 7 and Windows Server 2008 R2 servers will wait 10 seconds after receiving a Client Audio Formats and Version PDU. If the Quality Mode PDU is not received, the server uses the DYNAMIC_QUALITY quality mode (section 2.2.2.3).

<19> Section 3.3.5.1.1.4: Windows XP and Windows Server 2003 clients try to negotiate UDP by using the API function getsockname. If the function is successful, Windows clients advertise a UDP port. Otherwise, the clients use static virtual channels. For more information about the getsockname function, see [MSDN-getsockname].

Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2 always use static virtual channels, even if the client advertises a UDP port.

Windows 8 and Windows Server 2012 always use virtual channels, even if the client advertises a UDP port.

Windows Server 2003, Windows XP, Windows XP SP1, Windows XP SP2, and Windows XP SP3 servers use UDP, provided that the client advertises a UDP port.

<20> Section 3.3.5.1.1.5: Windows XP and Windows Server 2003 servers will wait 1 second after sending a UDPTraining PDU for the Training Confirm PDU. If theTraining Confirm PDUs are not received, the server will retry up to 10 times before falling back on static virtual channels.

<21> Section 3.3.5.1.1.6: Windows XP and Windows Server 2003 servers will not send a Crypt Key PDU if the Encryption Level in the RDP Listener settings is set to "Low".

<22> Section 3.3.5.2: Windows XP and Windows Server 2003 clients try to negotiate UDP by using the API function getsockname. If the function is successful, Windows clients advertise a UDP port. Otherwise, the clients use static virtual channels. For more information about the getsockname function, see [MSDN-getsockname].

Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2 always use static virtual channels, even if the client advertises a UDP port and the samples will be sent by using a WaveInfo PDU and a Wave PDU.

Windows 8 and Windows Server 2012 always use virtual channels, even if the client advertises a UDP port and the samples are sent by using a WaveInfo PDU and a Wave PDU, or a Wave2 PDU.

Windows XP and Windows XP SP1 servers use UDP and samples are sent using a Wave Encrypt PDU.

When the client version is less than 5, Windows Server 2003, Windows XP SP2, and Windows XP SP3 use UDP and samples are sent using a Wave Encrypt PDU. However, if the data size is greater than the maximum datagram size for the UDP socket, the samples are sent using a static virtual channel with a WaveInfo PDU and Wave PDU.

<23> Section 3.3.5.2: Windows XP and Windows Server 2003 clients try to negotiate UDP by using the API function getsockname. If the function is successful, Windows clients advertise a UDP port. Otherwise, the clients use static virtual channels. For more information about the getsockname function, see [MSDN-getsockname].

Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2 always use static virtual channels, even if the client advertises a UDP port and the samples will be sent by using a WaveInfo PDU and a Wave PDU.

Windows 8 and Windows Server 2012 always use virtual channels, even if the client advertises a UDP port and the samples are sent by using a WaveInfo PDU and a Wave PDU, or a Wave2 PDU.

Windows XP and Windows XP SP1 use UDP if the client advertises a UDP port and the samples will be sent by using a Wave Encrypt PDU.

If the client is less than 5 and the data size is greater than the maximum datagram size for the UDP socket, Windows Server 2003, Windows XP SP2, and Windows XP SP3 will use a static virtual channel, otherwise, the samples will be sent by using a Wave Encrypt PDU over UDP.

If the server is Windows Server 2003, Windows XP SP2, or Windows XP SP3, and the client is at least 5, the samples will be sent over UDP. If the data size is greater than the maximum datagram size for the UDP socket, samples will be sent by using UDP Wave PDUs and a UDP Wave Last PDU; otherwise, the samples will be sent by using a Wave Encrypt PDU.

The maximum datagram size for the UDP socket depends on system configuration parameters. Typically, the value is 1460 bytes.

<24> Section 3.3.5.2.1.3: Windows XP and Windows Server 2003 clients try to negotiate UDP by using the API function getsockname. If this function is successful, these clients advertise a UDP port. Otherwise, these clients use static virtual channels. For more information about the getsockname function, see [MSDN-getsockname].

 
Show:
© 2014 Microsoft