应用程序共享(RTP Payload format for Application and Desktop Sharing)

RTP Payload format for Application and Desktop Sharing
draft-boyaci-avt-app-sharing-00

1. 定义

Application Host (AH): AH是运行共享应用程序的主机，分发屏幕更新给参与者，并重新生成从参与者接收到的人机界面事件。
Participant: 参与者是接收屏幕更新的主机，并发送人机界面事件给AH。参与者不需要存储和运行共享应用程序，多个参与者可以连接到一个AH。
Remoting Protocol: 远程协议让AH分发窗口信息和屏幕更新给参与者。
Human Interface Protocol (HIP): 人机界面接口协议让参与者发送人机接口设备事件给AH。HIDs生成鼠标和键盘事件。例如鼠标按下，鼠标释放，鼠标移动，鼠标点击等。

2．简介
应用程序和桌面共享允许与一个或多个参与者通过Internet共享任何软件应用程序。应用程序主机是运行共享应用程序的计算机。参与者从AH接收共享应用程序的screen-view，参与者不需要存储和运行共享应用程序，把它们的鼠标和键盘事件交给AH并在AH上重新生成。一个提供应用程序和桌面共享系统是一个client-server体系结构[图1]。

+-------------+
| |
| participant |
| |
+-------------+
^ |
| |
Screen updates | | HIP
| |
| |
| v
+-------------+ Screen updates +---------+
| |<-------------- | |
| participant | | AH |
| |--------------->| |
+-------------+ HIP +---------+

图1: 应用程序共享系统体系结构
应用程序和桌面共享能够通过Internet进行协同工作、软件教育、和e-learning。然而现在基于标准协议的二方或多方会议系统多是遵循aging T.120协议开发应用程序共享功能。在本文档中，我们为应用程序和桌面共享定义RTP负载格式。
应用程序共享不同于桌面共享。在桌面共享，一个计算机分发全部屏幕更新，而在应用程序共享，AH分发只属于共享应用程序窗口的范围内的屏幕更新。应用程序通常包括一套不断变化的关联窗口来完成同一个任务并通常关联在一个进程中。只考虑共享窗口的边界是不够的，其他非共享窗口可能覆盖了共享窗口，而且共享窗口经常会打开子窗口，比如在选择字体的时候。一个真正的应用程序共享系统必须屏蔽掉非共享窗口并且必须传输共享应用程序的所有子窗口。
我们注意到，远程访问一个应用程序（“remoting desktop”）和在一个合作环境下多用户共享一个应用程序（例如一个多媒体呼叫或多方会议）是很相似的。本文档定义的协议可以同时支持这二种情况。
应用程序共享可以使用SDP(RFC2327)会话描述协议和SIP协议整合到现有的IETF会话模型中。
。。。。。

我们区分了AH用户和参与者，AH用户使用正常的操作系统机制来实现与应用程序交互，而参与者是通过使用本文档定义的递送协议来实现与共享应用程序交互的。
应用程序共享问题可以被分成四个组成部分：
（1） 在AH上建立一个会话，
（2） 从参与者传输人机界面事件到AH
（3） 从AH传输屏幕输出到参与者
（4） 对访问共享人机界面设备(如键盘、鼠标、游戏杆)建模。
我们第二部分定义人机界面协议(HIP)；第三部分定义远程协议（remoting protocal）；远程用户的输入控制通过BFCP协议建模。
会话协商和描述可以由现有的会话建立协议，这超出了本文档的范围。

3. Requirements Notation

4．概述

4.1. 坐标系统

坐标系统的原点origin(0,0) 位于左上角，在协议规定的消息中所有坐标都是绝对坐标并且是以像素(pixel)为单位的。

0,0 x 轴

220,150

窗口A

窗口B

450,400

800,700

850,320

窗口C

1280,1024

图2: 一个AH共享三个窗口

0,0

窗口A

窗口B

窗口C

220,150

1280,1024

850,320

800,700

450,400

图3：参与者1将共享窗口显示在与AH原始坐标相同的坐标系中

窗口A

窗口B

窗口C

230,250

630,170

1280,1024

0,0

图4: 参与者2将共享窗口以偏移坐标显示

0.0

窗口A

窗口C

窗口B

60,180

640,480

图5: 参与者3用完全不同的坐标显示共享窗口

图2显示了一个共享窗口的场景，所有坐标都是绝对坐标，参与者可以用与AH相同的原始坐标来显示共享窗口，也可以用不同的坐标系统来显示共享窗口。图三中，参与者1采用了原始坐标显示共享窗口；图4中参与者2向左偏移了220个单位，向上偏移了150个单位；参与者2仍然保留了窗口之间的关系，然而图5中，参与者3却将共享窗口结合起来以适应屏幕的方式来显示。在这个场景中，所有参与者都保留了窗口的z序(z-order)。 AH将窗口的位置和尺寸，z序和分组信息通知给参与者，AH用一个分组标识符来确定窗口属于哪个进程。参与者可以参照分组信息来重新放置窗口并强制它们的z序，参与者可以改变共享窗口在本地的z序，但不能改变在AH上的z序。某些remoting/HIP消息携带了left, top, width和height域，采用像素作为单位。
AH要检查鼠标坐标是否在共享窗口以内，并只接受坐标在共享窗口以内的合法HIP事件。

4.2．操作

检测到共享应用的GUI变化，AH用一个RTP包容纳更新区域的编码图像。RTP允许参与者对包进行重新排序，识别已经丢失的包，并允许应用共享同步其他媒体类型的RTP包如音频、视频。屏幕更新可以采用PNG、JPEG、JPEG2000、Theora编码，也可以根据其特征采用其他媒体像H264来编码。PNG是一种采用无损压缩算法的开放图像格式，很适合计算机生成的图像。JPEG是有损压缩，但很适合照片图像。JPEG2000支持无损压缩和有损压缩，因而既适合计算机生成图像，也适合电影。Theora是与H264相当的开放源码的视频编解码，适合于电影编码。
尽管多个用户可以同时接收屏幕更新，但很明显，只有一个可以通过鼠标和键盘操作应用程序。二进制发言权控制协议-BFCP协议可以将对共享应用程序的控制限制在一个用户。BFCP从参与者接收发言权请求和发言权释放消息，然后将发言权授予给合适的参与者一段时间，而把其他参与者的请求保留在一个FIFO队列中。BFCP协议的详细细节参考RFC4582。
鼠标指针模式有2种，一种是将鼠标指针图像以RegionUpdate消息传输，一种是采用MousePointerInfo消息独立地传输。由AH决定采用哪种模式，参与者支持2种模式。
HIP支持UTF-8编码的unicode字符，已经其他在unicode中没有定义的键盘键，如一些功能键和控制键。对于键盘事件，使用公开有效的Java虚拟键盘编码(Keycodes)。
本文档定义的应用和桌面共享可以被整合到IETF会议模型。可以用SIP来初始化远程访问。这样可以利用SIP已有的安全、认证和授权、用户定位和会议功能。
此外，可以采用一些机制来增强应用和桌面共享。音频流可以被关联到桌面和应用共享；可以利用参与者侧的伸缩性来优化小屏幕参与者的数据转换；还有复制粘贴功能在AH和参与者之间也是经常使用的。本文档不定义这些或其他扩展机制。
AH可以支持多播和单播传输。2单播连接，可以使用UDP和TCP。AH可以将应用程序共享给TCP参与者和UDP参与者，以及同一个共享会话内的若干多播地址。

4.3．UDP参与者

由于UDP本身并不提供流和拥塞控制手段，所以需要AH控制UDP参与者的传输速率。AH上可以创建若干个不同传输速率的并发多播会话。
任何时候加入共享会话的参与者，在接收变化的区域更新之前，都需要共享窗口的信息和全部屏幕数据。因此，UDP参与者在加入会话之后，使用RTCP协议发送反馈包和图像损失指示（Picture Loss Indication (PLI) [RFC4585]）。AH在收到一个PLI消息后，准备并发送窗口状态信息和全部区域图像。

4.4．TCP参与者

TCP提供了可靠的通讯和流控制，很适合于单播会话。TCP参与者可以有不同的带宽，所以需要一个能够在不同速率的链接上发送更新数据的算法。
TCP和RTP都不声明RTP包的长度，采用RTP分帧(RFC4571)来区分TCP字节流中区分出RTP包。
一旦TCP连接建立后，AH就准备和传输窗口的状态信息和全部共享区域的图像给新的参与者。

4.5．协议概述

应用程序和桌面共享协议由2个协议组成，远程协议(remoting)和人机接口协议(HIP)。远程协议的消息从AH向参与者传输屏幕更新，而HIP消息从参与者传输鼠标和键盘事件到AH。
远程和HIP消息都是RTP消息，由RTP头、remoting/HIP公共头、message-type私有头和消息负载组成。HIP消息的负载类型与remoting消息是不同的。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. RTP header .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common remoting/HIP header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Message-type specific header .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. Message Specific Payload .
. +-+-+-+-+-+-+-+-+
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图6: 应用程序共享协议消息结构

4.5.1．Remoting 协议概述
Remoting协议由四个AH->参与者的消息和2个参与者->AH的控制消息组成。AH-to-
Participant消息包括：WindowStateInfo, RegionUpdate,MoveRectangle,和 MousePointerInfo. 从UDP参与者到AH的RTCP消息是"Picture loss indication (PLI)"和“NACK Request”。参与者必须实现本文档定义的所有消息。

WindowManagerInfo通知参与者共享窗口的WindowID、位置和尺寸，Z-order和分组。所有remoting消息都携带windowID来标识消息的目标。对应TCP参与者，AH在建立连接后立即发生WindowManagerInfo。UDP参与者加入会话不久发生PLI，收到PLI后，AH立即传输WindowStateInfo。对那些已经变化了的区域，AH传输RegionUpdate消息。不论什么时候，窗口的尺寸和位置发生了改变，AH都要发送一个WindowManagerInfo。类似，如果z-order改变了，AH也发送WindowManagerInfo消息。MoveRectangle指示参与者将窗口从一个地方移动到另一个地方，这对于像scroll一样的绘图操作时很高效的。MousePointerInfo消息传输鼠标的位置和图标。某些AH还可以通过RegionUpdate传送鼠标指针图像，这时就不需要MousePointerInfo。
"NACK request"是UDP参与者请求AH传输丢失的包。AH可以支持重传。TCP和UDP参与者都可以使用PLI来请求传输一个完整的屏幕刷新。PLI和NACK request采用RTCP封装。

4.5.2．人机接口协议概述

HIP有7个消息：namely, Mouse Pressed, Mouse Released,Mouse Moved, Mouse Wheel Moved, Key Pressed, Key Released and Key Typed. 都是从参与者到AH的，用RTP携带。HIP消息的负载类型与Remoting消息不同。

5．远程协议（Remoting Protocal）

5.1．负载格式

5.1.1．RTP Header 用法：

Marker bit：Marker bit 表示是RegionUpdate消息多个包的最后一个。该位让接收方不必等待新时间戳的下一个包，从而完成图像解码，除非有别的定义，否则其他类型的消息必须将该位置0。
Timestamp：remoting消息在AH上创建的时间。时间戳基于90-KHz的时钟，如果RegionUpdate消息需要几个包封装，这些包的时间戳应该相同。时间戳的初始值必须是随机的（不可预测），这使得known-plaintext攻击更困难.
RTP头域的使用参考RFC3550。

5.1.2．Remoting/HIP公共头

RTP头之后，紧跟着的是Remoting/HIP公共头，见下图：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg Type | Parameter | WindowID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图7: Common remoting/HIP header

Message Type和Parameter 域是占8位的标识符，而windowID是16-bit标识符，取值范围为0-65535。
下表定义消息类型的枚举值，参与者必须全部实现。第九节描述了可以注册到IANA的附加类型，参与者可以忽略这些附加类型。
+-------+-------------------+
| Value | Message Type |
+-------+-------------------+
| 1 | WindowManagerInfo |
| | |
| 2 | RegionUpdate |
| | |
| 3 | MoveRectangle |
| | |
| 4 | MousePointerInfo |
+-------+-------------------+
表1: Remoting protocol message types

5.2．AH-to-participant messages

5.2.1．WindowManagerInfo

WindowManagerInfo消息通知参与者窗口、窗口位置与尺寸、z-order已经分组信息。将全部窗口管理状态传输给参与者。共享窗口大小和位置的任何改变都触发一个WindowManagerInfo消息。Remoting/HIP公共头的Parameter和windowID域必须被忽略。该消息携带自己的特定负载，一个或多个窗口记录紧跟在Remoting/HIP公共头后面。

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WindowID | GroupID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Top |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Width |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Height |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图 8: 一个窗口记录
每个窗口记录占20个字节，z-order是隐含的，第一个窗口记录表示最底层的窗口，最后一个记录表示最顶层的窗口。每个窗口都赋给一个WindowID，参与者每发现一个新的WindowID就必须创建一个窗口。如果发现一个WindowID没有包含在WindowManagerInfo消息中，就必须关闭这个窗口。GroupID是窗口的分组标识符，AH将属于同一个进程的窗口赋予同一个GroupID。参与者可以使用GroupID来改变窗口的位置，或强制z-order。如果GroupID为0，表示每个给窗口分组，0是一个保留的值。

图9是图2中三个共享窗口的WindowManagerInfo消息示例。

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg Type = 1 | Parameter = 0 | WindowID = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WindowID = 1 | GroupID = 1 | Reserved = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Left = 220 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Top = 150 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Width = 350 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Height = 450 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WindowID = 2 | GroupID = 2 | Reserved = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Left = 850 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Top = 320 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Width = 160 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Height = 150 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WindowID = 3 | GroupID = 1 | Reserved = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Left = 450 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Top = 400 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Width = 350 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Height = 300 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图 9: WindowManagerInfo消息示例

5.2.2．RegionUpdate

RegionUpdate指示参与者用新的内容刷新一个窗口的指定区域。凡是有一个RTP负载规格的媒体类型都应该支持，所以，支持的媒体类型应该在会话建立期间协商。
公共头的Parameter域将携带FirstPacket位和实际的内容负载类型。7位的PT域携带实际负载类型，可以是PNG、JPEG、Theora、或者其他有RTP负载规格的媒体类型，AH和参与者都需要实现PNG图像。消息特定的私有头紧跟在Remoting/HIP头后面。消息私有头包含2个32位参数，left和top，指示RegionUpdate区域的左上角坐标，RegionUpdate的宽度和高度不显式地传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RegionUpdate |F| PT | WindowID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图 10: Common remoting/HIP header for RegionUpdate messages

如果更新数据用单个RTP装不下，可以使用若干RTP负载，所有包都携带32位remoting/HIP公共头，但left和top仅在第一个RTP负载携带就可以了。Marker和FirstPacket位告诉参与者分段信息。

+------------+-----------------+-----------------------+
| Marker bit | FirstPacket bit | Fragment Type |
+------------+-----------------+-----------------------+
| 1 | 1 | Not Fragmented |
| | | |
| 0 | 1 | Start Fragment |
| | | |
| 0 | 0 | Continuation Fragment |
| | | |
| 1 | 0 | End Fragment |
+------------+-----------------+-----------------------+
Table 2: Marker and FirstPacket bits carry fragmentation info

图11显示一个RegionUpdate消息的例子，RTP头在图11中省略了。RegionUpdate是一个不分段的消息，因而marker和firstpacket为都设置为1

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg Type = 2 |1| PT | WindowID = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Top |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. Payload .
. +-+-+-+-+-+-+-+-+
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: An example non fragmented RegionUpdate message

5.2.3．MoveRectangle

MoveRectangle消息指示参与者移动一个窗口区域到一个新的位置。AH通过source left、source top，width和height参数指定一个源矩形通知参与者，参与者从消息中得知destination left和destination top参数。源和目的矩形是可以重叠的。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Top |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Width |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Heigth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Top |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图 12: Message specific payload for move rectangle

5.2.4．MousePointerInfo

某些AH可以将鼠标指针图像嵌入RegionUpdate消息。但是AH可以选择显式地通知参与者鼠标的位置和图标。如果RegionUpdate消息包含了鼠标指针图标，那么就不需要MousePointerInfo消息了。收到图像时，参与者应该在指定的位置绘制鼠标指针图标。本消息携带私有负载数据，除了消息类型，其格式与RegionUpdate相同。
MousePointerInfo消息可以只有left和top坐标，这种情况下，参与者必须移动当前鼠标指针到指定的坐标位置。负载可以携带left和top和新的鼠标图像，参与者必须存储并使用整个图像，直到又由新的图像数据到来。如果AH使用MousePointerInfo，当有新的参与者加入会话时，必须通知他当前的鼠标位置和图像。

5.3．Participant-to-AH Messages

UDP参与者可以发送2个RTCP消息给AH。后来的加入者可以使用PLI向AH请求完整屏幕。对于丢失的包，UDP参与者可以发送NACK Request。

5.3.1．PLI
指示AH生成一个共享区域的完整屏幕更新。在完整更新之前，AH发送WindowManagerInfo通知新的参与者窗口信息。TCP和UDP参与者可以传输本消息，消息格式满足"Picture Loss Indication (PLI)" section 6.3.1 of [RFC4585]

5.3.2．NACK Request
“NACK Request”消息通知AH丢包信息，消息格式满足"Generic NACK" section 6.2.1 of[RFC4585]。多播参与者和AH可以采取必要的预防措施防止NACK风暴，比如在发送一个 "NACK Request"消息之前等待一个随机时间。

6．HIP

6.1. Payload Format

6.1.1. RTP头使用

Marker Bit：参与者必须将marker设置为0，AH必须忽略。
Timestamp：表示参与者侧发生鼠标和键盘事件的时间。HIP时间戳基于90-kHz时钟。初始值必须是一个随机数，可以使基于加密的known-plaintext攻击很困难。

6.1.2. Common remoting/HIP header

所有HIP消息都携带图7中展示的相同的公共头。WindowID参数表示键盘和鼠标发生的窗口，这个窗口有鼠标或键盘焦点。
下面列出定义的HIP消息类型
+-------+-----------------+
| Value | Message Type |
+-------+-----------------+
| 121 | MousePressed |
| | |
| 122 | MouseReleased |
| | |
| 123 | MouseMoved |
| | |
| 124 | MouseWheelMoved |
| | |
| 125 | KeyPressed |
| | |
| 126 | KeyReleased |
| | |
| 127 | KeyTyped |
+-------+-----------------+
Table 3: HIP Message Types

6.2 MousePressed

指示AH生成一个在给定屏幕坐标处按下鼠标的事件。本消息携带私有头。公共头的“Parameter”域携带鼠标按钮信息，值1,2,3分别表示为left，right和middle按钮。AH和参与者可以协商另外的值来表示其他按钮。AH可以忽略不认识的值。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Top |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Message specific payload for mouse pressed

6.3. MouseReleased

通知AH生成一个给定屏幕坐标的释放鼠标事件。本消息携带私有头，公共头的Parameter域携带鼠标按钮信息，值1,2,3分别表示为left，right和middle按钮。AH和参与者可以协商另外的值来表示其他按钮。AH可以忽略不认识的值。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Top |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Message specific payload for mouse released

6.4. MouseMoved

指示AH将鼠标指针移动到提供的新坐标。本消息携带私有头。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Top |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Message specific payload for mouse moved

6.5. MouseWheelMoved

指示AH在给定屏幕坐标上生成一个移动滚轮的鼠标事件。本消息携带私有头，“distance”域携带滚轮转动数量，方法是"120 * (number of notches)"。一个鼠标滚轮有discrete，evenly spaced notches（平均间隔刻度）。当用户旋转滚轮时，每遇到一个刻度变化，都会有一个滚轮事件发送到OS。“distance”域并不携带刻度数，目的是支持平滑地滚动滚轮，而是每个刻度当做120来传输。一些情况可以只发送120的倍数，而平滑滚动可以发送任何值。正值表示向前滚动，负值表示向后滚动。负数传输采用2的补数的方法。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Top |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Distance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Message specific payload for mouse wheel moved

6.6. KeyPressed

指示AH生成一个按住键的键盘事件。消息携带一个32位的KeyCode。使用java虚拟keycodes，在openJDK网站是公共有效的。实际的值是嵌入在KeyEvent.java文件中的。例如 F1键在KeyEvent.java文件被定义为"int VK_F1 = 0x70;"
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KeyCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Message specific payload for key pressed

6.7. KeyReleased

指示AH生成一个释放按键的键盘事件。同一个键，必须先有KeyPressed，KeyReleased事件才会被AH接受。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KeyCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Message specific payload for key released

6.8. KeyTyped

指示AH向OS输入队列注入一定数量的UTF-8编码的unicode字符。本消息携带特定消息的负载。UTF-8字符串没有padding。如果字符串不能装入一个RTP包，参与者必须发送多个KeyTyped消息。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. UTF-8 String .
. +-+-+-+-+-+-+-+-+
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: Message specific payload for key released

7. 实现提示

AH不应该盲目地将所观察到的屏幕更新发送给参与者，而应该监控TCP传输缓冲区的状态（通过Select（）），只在没有积压的时候才发送最近的屏幕数据。当一个观看者只需要看到最终的图像状态时，这将防止迅速改变图像导致的屏幕延迟。

8. 安全考虑

9. IANA Considerations

10. Mapping to the Session Description Protocol (SDP)
SDP描述

10.1. Mapping remoting Media Type Parameters into SDP

Remoting 协议
媒体类型application作为媒体名称，出现在SDP的m= 属性
媒体子类型remoting作为编码名称，出现在SDP的a=rtpmap属性
参数rate作为时钟速率出现在SDP的a=rtpmap属性
必选的参数retransmissions必须被包括在SDP的a=fmtp 属性。

10.2. Mapping hip Media Type Parameters into SDP

HIP协议
媒体类型application作为媒体名称，出现在SDP的m= 属性
媒体子类型hip作为编码名称，出现在SDP的a=rtpmap
参数rate作为时钟速率出现在SDP的a=rtpmap属性

10.3. SDP的例子

下面是一个AH到参与者的SDP例子，HIP流和BFCP会话通过label和m-stream关联（见RFC4583）。
AH通知参与者它支持TCP和UDP传输remoting协议。AH支持重传，所以参与者可以发生NACK请求。如果AH将同样的内容通过TCP和UDP传输，端口必须相同。本例子中，AH从6000端口传输remoting协议数据。如果AH有多个remoting会话，则每个会话必须采用不同的端口号。
m=application 50000 TCP/BFCP *
a=floorid:0 m-stream:10
m=application 6000 RTP/AVP 99
a=rtpmap:99 remoting/90000
a=fmtp: retransmissions=yes
m=application 6000 TCP/RTP/AVP 99
a=rtpmap:99 remoting/90000
m=application 6006 TCP/RTP/AVP 99
a=rtpmap:99 hip/90000
a=label:10

Appendix A. Using BFCP for Application and Desktop Sharing

使用BFCP

应用程序和桌面共享工具可以使用BFCP来管理AH的HID所有权。
BFCP定义了若干消息，但只有5个对于应用和桌面共享是必须的。分别是："Floor Request", "Floor Release", "Floor Granted", "Floor Released" and "Floor Request Queued"。
在应用程序和桌面共享环境，发言权floor就是AH的HIDs，AH可以不撤销发言权控制临时阻塞HID事件。例如，如果共享应用程序失去焦点或者被非共享应用程序覆盖，AH可以临时阻塞HID事件。AH通过Floor Granted的STATUS-INFO属性通知当前发言权的取得者HID的状态。参与者应用程序可以通知用户当前的HID Status. HID Status是16为无符号值，定义如下：
+-------+------------------------+
| Value | Status |
+-------+------------------------+
| 0 | STATE_NOT_ALLOWED |
| 1 | STATE_KEYBOARD_ALLOWED |
| 2 | STATE_MOUSE_ALLOWED |
| 3 | STATE_ALL_ALLOWED |
+-------+------------------------+
Figure 20: HID Status Values