1.3 Overview

The following figure illustrates a baseline for terminology related to clients and servers.

TS and protocol client-server definition

Figure 1: TS and protocol client-server definition

Remote Desktop Protocol (RDP) Device Redirection enables client devices (for example, printers, smart card readers, drives, audio, serial ports, and parallel ports) to be available to server-side applications, within the context of a single RDP session. This protocol is specified in [MS-RDPEFS].

Smart Card Redirection is an asynchronous client/server protocol, an extension (specified in [MS-RDPEFS]) that is designed to remotely execute requests on a client's Smart Cards for Windows. These requests would have otherwise been executed on the server. Each request is composed of two packets: a call packet and return packet. The protocol client (Microsoft Terminal Services (TS) server) sends a call packet after an initial announcement by the protocol server (TS client), and will receive a return packet after the request has been completed or an error has occurred. Remote Desktop Protocol (RDP) Device Redirection uses a static virtual channel as its transport.

Smart Card Redirection redirects the TS client–side Smart Cards for Windows. When Smart Card Redirection is in effect, TS server application smart card subsystem calls (for example, EstablishContext) are automatically remapped to the TS client–side Smart Cards for Windows, which will then receive the corresponding request. Smart Card Redirection devices are only required to understand one type of device I/O request.

The following figure shows a high-level sequence diagram of the protocol for redirected calls. Device Announce and Device Disconnect are handled via the lower-layer protocols.

High-level protocol sequence

Figure 2: High-level protocol sequence

The following figure specifies how the messages are encoded and routed from a TS client to a TS server. The following numbered list details corresponding actions related to the pictured protocol flow.

Protocol flow

Figure 3: Protocol flow

The input for this protocol (call packet) is a combination of an I/O control (IOCTL) and the corresponding structure as specified in section 3.2.5.

  1. The call packet structure is encoded as specified in [MS-RPCE] section 2.2.6.

  2. The packet, as specified in [MS-RPCE], is returned as a response to 1.

  3. The encoded value from 2 is combined with the IOCTL and transported over RDP Device Redirection, as specified in [MS-RDPEFS] section 2.

  4. On the TS client, Remote Desktop Protocol: File System Virtual Channel Extension will route the packet from 3 to protocol server for the Smart Card Redirection, as specified in [MS-RDPEFS] section 2.

  5. After Smart Card Redirection receives the message, the encoded structure is decoded, as specified in [MS-RPCE] section 2.2.6.

  6. The packet, decoded as specified in [MS-RPCE], is a response to 5.

  7. Based on the IOCTL, the structure members are used as input parameters to the Smart Cards for Windows, as specified in [PCSC5] section 3.

  8. The output parameters including the return code are packaged into the return packet structure for this IOCTL.

  9. The return packet structure is encoded as specified in [MS-RPCE] section 2.2.6.

  10. Return data, encoded as specified in [MS-RPCE], is a response to 9.

  11. The encoded value from 10 is sent to RDP Device Redirection (as specified in [MS-RDPEFS]) as a reply to the call packet from 4.

  12. RDP Device Redirection (as specified in [MS-RDPEFS]) routes the reply back to the protocol client.

  13. On receipt of packet from 12, the encoded structure is decoded as specified by to [MS-RPCE] section 2.2.6.

  14. In response to 13, return data is decoded as specified by [MS-RPCE].

The output from the Smart Card Redirection is the return packet. This data will then be processed by higher layers.