类型: Image

4.记录和保留

G.S.§132通过内容而不是媒体或格式来定义公共记录。当员工用于开展公共业务时，个人和工作场所发布的设备将导致构成公共记录的通信符合G.S.§132的要求，并得到北卡罗来纳州自然和文化资源部的指导。

员工有责任了解并遵守所有适用的保留时间表，这些保留时间表规定了记录应保留多长时间以及是否应永久保留，销毁或转移到国家档案馆保管。如上所述，记录由内容而不是给定通信的格式定义，因此员工必须适当地识别记录的类型。

尽管代理商记录保留时间表可能没有明确提及文本或即时消息，但仍然涵盖了通过这些媒体进行的通信。记录保留和处置计划包括适用于文本或即时消息的各种项目。

通常可以同时保留对话，以便从头到尾显示交换。许多移动设备和即时消息服务和程序允许保存和转发整个会话。来自不同平台的操作软件可能具有保留消息的工具，或者可能存在执行此操作的第三方应用程序。员工有责任确保保留消息，以便在响应记录请求或诉讼时生成消息。

注意：代理商和员工不应依赖服务提供商提供由文本/ IM创建的记录。服务提供商可以保留自己的文本和即时消息记录，但他们不会自动承担向政府实体提供这些记录的副本。使用个人设备的员工负责管理这些记录并确保按照要求保留这些记录。记录保留和处置计划。为不同平台开发的应用程序和工具可以帮助员工解决这个问题。

向员工提供工作发布设备的代理商应注意这些问题，并寻求在与服务提供商签订的合同和服务水平协议中解决这些问题，以确保他们能够获取其公共记录的副本。

以下是代理机构和地方政府的模型合同语言，用于从雇主发行的移动设备上获取服务提供商的公共记录副本：

“服务提供商同意允许代理机构从其电子邮件系统收集所有短信。服务提供商同意代理商有权访问所有数据，无论是谁创建了内容以及出于何种目的。服务提供商将根据以下时间表[特定程序]提供短信：[时间表]。机构内的以下职位有权向[服务提供者内部]提出此类请求。

3.使用消息技术的指导原则

• 3.1在公共事业中使用消息技术的考虑因素

在实施政策或允许使用文本和即时消息工具时，代理商应计划使用工具进行公共业务。每个机构的官员和管理人员都应该了解这些服务的广泛使用，并应通知员工适当使用文本/ IM。机构负责人还应考虑文本/即时消息对员工的好处，并努力保留这些好处或寻找替代方案，同时遵守记录保留和处置责任。

要考虑的问题：

如何在办公室中使用短信/即时消息？多常？

您的办公室是否有任何特定于文本消息/ IM有助于解决的需求 - 管理目的或与其他部门/第三方的沟通？

员工或官员是否使用工作场所发布的设备进行此类通信？个人设备？什么平台？

员工如何根据公共记录法和其他记录管理职责了解有关管理电子通信的信息？您的办公室当前如何存储和保留短信和即时消息？

是否存在转录或存储短信/ IM的现有方法？如果没有，现有的做法如何适应？或者需要一种新方法？

办公室政策如何解决电子发现对使用短信/即时消息的法律影响？

机构负责人可以使用此信息来帮助确定其代理机构是否以及如何使用这些通信平台进行公共业务。关于所有格式的政府业务的沟通导致创建公共记录，如N.C. G.S.§132所定义。

• 3.2适当使用

与所有记录一样，必须根据州法律的要求保留和管理与公共业务相关的文本/ IM日志。 N.C.G.S. §132将公共记录定义为“文件，文件，信件......无论其形成或收到的物理形式或特征如何...与公共业务的交易有关... “。

• 3.2.1个人使用

DNCR强烈鼓励各机构制定关于使用雇主发行的设备和个人使用工作场所发布的设备的政策。员工不得使用工作场所发行的移动电话为政治目的发送短信，进行私人商业交易或从事私人商业活动。

• 3.2.2专业用途

员工的沟通应该是专业的。虽然文本/ IM允许更快的响应和快速交换想法，但员工应该：

将个人和工作相关的信息分开，
确保他们的信息清晰简洁，
对这些交易所应用与工作相关的相同专业标准电子邮件（电子邮件）或信件，
请注意，根据NC公共记录法，可以披露与公共业务相关的信息。

如果员工选择使用文本或即时消息技术，他们必须密切关注他们维护公共记录的责任。

1.目的

移动设备和即时消息服务为员工提供了一种与工作场所和工作日进行通信的方法。几乎可以随时随地进行直接通信，从短消息到长期交换，可以提高员工的工作效率。根据北卡罗来纳州法规和自然和文化资源部的现有指南，员工有责任管理与公共业务相关的记录。这包括即时消息和文本消息应用程序启用的通信。员工还必须记住，这些形式的通信（如电子邮件或社交媒体通信）可能会导致记录由第三方服务提供商或转发服务托管。无论员工是使用个人或工作场所发布的设备，这些与工作相关的通信都遵守与其他公共记录相同的规则和规定。

本文档旨在解决即时消息（IM）和文本消息是什么以及如何在工作场所使用它们。它还根据一般法规和记录保留和处置时间表处理员工责任。

2.什么是文字消息？什么是即时消息？

• 2.1文本消息

短信，有时称为“短信”，通常是指使用“短消息服务”（SMS）将屏幕上的消息发送到接收者的电话。短信限制为160个字符。字符定义为需要一个字节的存储的任何符号，包括数字，字母，符号，空格和标点符号。其他形式的文本消息传递包括允许用户发送图片，视频和其他非文本媒体的多媒体消息服务（MMS），以及可以包括格式化文本的增强消息服务（EMS）。

通过“捎带”在电话和运营商基础设施之间经常发生的小型信息传输上交换文本消息。消息不是直接从电话发送到电话，而是通过电话网络使用标准通信协议进行存储和转发。如果电话关闭或没有信号，短信“等待”接收者接收信号。

每条短信还包含有关邮件的数据，包括邮件的发件人和收件人的电话号码，时间戳，目的地电话号码和格式。这些描述其他数据的上下文和内容的重要信息称为元数据。电子邮件软件和在线服务也可以向移动设备发送文本消息。短信也可以从一个来源发送到许多不同的收件人，允许办公室快速联系其许多员工或客户，例如在紧急情况下。

• 2.2即时消息

即时消息（IM）是一种在线服务，其中用户使用电话，个人计算机（PC）或其他设备上的客户端软件与使用兼容软件的人通信（例如，Apple®的iMessageTM服务，Microsoft的Skype for Business，或者GchatTM服务链接到Google的Gmail®客户端。诸如Facebook©之类的社交媒体网站也能够允许两个注册用户之间的即时消息传递。

即使是能够发送和接收数据的基本移动电话通常还具有预先安装的即时消息软件，允许用户通过移动设备与这些服务的其他用户进行通信。

当用户登录时，服务器加载可用收件人列表（“朋友列表”）。在连接用户之后，该服务允许每个用户的软件直接在另一端与软件“对话”，而无需进一步使用服务器。这是传统即时消息传递模型，但较新的服务有时会在“云中”保存消息30天。美国国家标准与技术研究院（NIST）将云计算定义为“用于实现对可配置计算资源共享池（例如，网络，服务器，存储，应用程序和服务）的无处不在，方便，按需网络访问的模型”可以通过最少的管理工作或服务提供商交互来快速配置和发布。在前面提到的示例中，云指的是由提供商提供的服务器，以便进行业务交易。

IM用户必须记住，他们发送的消息可以临时存储在服务器上，该服务器直到最近才通过即时消息应用于用户到用户的通信。

员工必须牢记使用文本/ IM以及在构成G.S.§132定义的公共记录时管理消息的准则。

• 2.3对话

即使是涉及公共业务的单个文本消息和即时消息也是公共记录，但是对较新的消息传递服务的通信通常会导致对话。这些是个人之间交换的消息的记录，按时间顺序保存，就像电子邮件交换一样。某些设备会自动以对话形式显示消息。其他包括它作为可选设置。但是，针对多个主题的对话可能会在同一对话中产生多个保留期；因此，保留会话将默认为最长保留期。

现下的经济环境是数字经济的时代，是信息化技术高速发展的时代，许多的先进技术被广泛运用比如：大数据、云计算、人工智能、物联网等等。个人、经济实体及整个数字经济环境中的生产资源都实现了广泛、即时的联接与沟通。随着信息化技术的不断发展、人们在日常生活及工作中对信息化系统的运用及依赖程度不断提高，即时沟通对于个人及企业来说从未如此重要。

劳格 SparkleComm统一通信平台是新一代的通讯平台，融合语音、视频、即时消息、文本、图片等移动互联网的数据融合通信平台，在当今经济环境下能优化你的及企业的工作及生活方式，使得沟通更加的便捷与高效，也让企业能够有效的整合现有的数据 业务流程，同时对信息的安全性能也是可圈可点，不用担心信息遗漏、延迟和误发是可以为客户提供一个即需即用、灵活高效的可以信赖的即时通信平台。

劳格 SparkleComm统一通信平台旗下的每一个功能性模块都可以独立使用以解决你具有针对性的需求，而整合后能为您提供全方位的通信需求，企业或组织机构可以从一个统一的软件界面(iOS／Android／Windows／Mac OS X)，采用熟悉简单的模式进行操作

劳格 SparkleComm统一通信平台包括有：

软件电话（softphone）--SparklePhone 全面集成语音、视频、电话、即时消息和邮件功能，可安装于智能手机、电脑(PC／Mac)的软件客户端。 支持操作系统：Android 4.4+；iOS 8.01+；Windows 7+；Linux(部分)；macOS 10.0+。 其特征：1.支持多种语音编码；2.支持与主流的IPPBX对接；3.支持IMS（有与中兴通讯及华为IMS成功对接案例）；4.支持呼叫转移、偏转、会议、三方等功能；5.支持模拟对讲机接入；6.支持状态呈现（Presense）。

视频通话--SparkleVideo 视频通话功能用于手机对手机、手机对PC以及视频会议。 特征：1.支持多种清晰度并可以根据网络带宽智能切换；2.语音通话动态结合，支持通话中途启动和关闭视频；3.支持视频设备选择如外接摄像头；4.支持与视频监控摄像头接入。

即时消息--SparkleIM 即时消息功能用于用户与用户间的多媒体及文本消息沟通，劳格即时消息包含即时消息客户端及服务端，支持群聊、离线消息推送。 特征：1.传送格式包括：图片、文件、表情、音频片段、视频片段等，实现桌面共享功能；2.支持SIP Message；3.同时支持手机客户端(Android／iOS／WM)以及PC客户端(Windows／macOS／Linux)，并与软件电话集成。

通讯录--SparklePhoneBook 网络电话解决方案整合通讯录功能，包括企业通讯录、云端通讯录、手机通讯录同步、好友管理等通讯录功能。 特征：1.支持读取本地通讯录(iOS／Android／macOS)；2.支持私有云端通讯录；3.企业通讯录具备后台web管理功能；4.支持多级组织架构；5.支持分级权限控制。 保密通话--SparkleSecPhone 劳格科技特有的保密通话技术，支持客户端(app2app)端到端动态加密，使得通话内容无法被窃听。 特征：支持实时加密，端到端加密，支持通话启动和关闭加密。

音视频会议--SparkleMCU SparkleMCU 为软件及硬件的视频和音频会议MCU，会议由SparkleComm核心管理和控制。 特征：开放会议控制OpenAPI，用户可以自行定义会议控制的软件。或者使用内嵌的基于Web的会议控制功能，控制功能包括：主动呼出／呼入设置、静音、私语、踢出、实时录音控制等，会议音频支持G.711，G.729等常用音频编码，视频支持H.264。客户端采用SparkleComm的SoftPhone，以及普通电话(需要另配网关)。 SparkleMCU包括软件独立版本，支持Linux操作系统。也包括硬件版本，硬件版本最低16路会议并发到200路会议。

呼叫中心--SparkleCC 劳格科技呼叫中心SparkleCC采用SparkleComm的ACD引擎，实现呼叫中心的功能，包含ACD，IVR，CTI。 采用开放接口，并提供坐席系统以及CTI API。坐席电话可使用SparkleComm的PC版本(支持Windows／macOS／Linux)，实现灵活的控制功能。同时可以使用普通的传统PSTN的耳麦(需配置IAD)。 呼叫中心SparkleCC配置可以包括软件独立版本，支持Linux操作系统。也包括硬件版本，硬件版本最低16坐席并发到100坐席。

手机对讲--SparklePTT SparklePTT手机对讲为集群通信中最广泛使用的一种通信调度工具，一般需要通过专门规划的无线通讯频率和专用的对讲承载工具、在一定的覆盖范围内实现 ，具有专用性、地域性的特点。 根据使用场景的不同，系统提供支持传统模拟对讲系统的接入支持，也就是说在网络结构中加入对讲模拟信号转换为IP信号的模拟对讲转换网关，即可实现SparkleComm与模拟对讲终端的互联互通，从而避免了通讯孤岛的出现。同时给用户在利用设备及发挥模拟数字对讲的各自长处方面增加可选的解决方案。

六、方法的实施

6.1 GCSVA系统的体系结构

        所提出方法的实现需要每个参与者主机的管理组件以及对其交互的协议支持。 图3显示了参与者主机上Gcsva的架构。 由于视频和音频流需要的服务与发送组通信数据所需的服务非常不同，因此我们将架构分为两部分：数据处理部分和信令部分。 它们由两种不同的协议支持：用于传输音频和视频流的MCM-TP（多播连续媒体传输协议），以及用于群组通信的GCP（组通信协议）。 两种协议都直接通过ATM适配层5（AALS）运行。 成的。 视频管理器还包含输出过滤器，用于根据系统配置QoS *调整输出视频流。通过MCM-TP执行从一个发送者到另一个参与者的音频和视频数据的传输。它提供连接定向的不可靠多播服务。 MCM-TP层包含输入滤波器，它可以将发声器的输入流从FRs *缩小到F R s /，并且分别从FRL *到FR L /缩小听众的输入流。

        信令部分负责组和QoS管理。它由QoS Manager，Monitor和Group Management Module组成。 QoS管理器计算系统配置QoS *的QoS参数，以及如上所述的本地过滤参数FRs /和FRL /。监视器支持QoS管理器的工作。监视器观察当前的CPU负载。它定期将此信息发送到QoS管理器以计算过滤器参数。当参与者改变或参与者加入或离开会议时，组管理模块会触发重新计算QoS参数。 ATM级的QoS管理组织如下。在连接建立期间确定ATM连接的QoS参数。之后不能改变它们。在所有参与者之间以最佳质量传输流的网络资源的预留将浪费网络资源并导致更高的成本。由于在Gcsva中，所有参与者并不总是以尽可能高的质量发送，因此在ATM级别的连接建立期间仅需要QoS参数的平均质量。

        集团管理模块监督集团的状态。 他们交换关于组的组成（参与者的加入和离开）的消息以及用于控制组的消息（进入说话者队列，从说话者队列中移除，交换QoS要求）。 组管理模块应该使用户免于任何QoS管理，因为用户通常不具备对QoS参数及其之间关系的深入了解。

        对于组管理模块之间的通信，设计了组播协议GCP。 它确保了参与者站点的QoS参数和组管理信息的一致性。 GCP是我们分散的集团管理的基础。

6.2集团通信协议（GCP）

        GCP协议是在仔细分析并部分调整现有多播协议和组通信方法的想法之后设计的。 为了确保组管理模块中组管理数据的一致性，支持协议必须满足以下要求：

        可靠性

        与视频数据的传输相反，其中一些帧可能丢失，失真或丢弃，因此必须能够交换控制数据。 消息可能不会失真，丢失或无序。

        原子性

        消息必须传递给所有参与者或者不传递给所有参与者。

        订购交货

        如果订单影响结果，则不同发件人的消息必须以相同的顺序传递给不同的接收者。 根据应用的不同，可能需要不同级别的订购。

        动态加入和离开

        应允许参与者随时加入并离开会议。

        GCP满足这个要求。它提供可靠的、原子的、有序的交付服务。

        为了提供有序的传递，GCP应用类似于基于令牌的机制。 所有参与者形成令牌旋转的逻辑环。 只允许令牌持有者发送。 所有参与者都必须承认这些PDU的接收。 超时后最多三次重传未确认的PDU。 收到所有确认后转发令牌。 必须同时接收令牌的接收。 如果没有要发送的消息，则会立即转发令牌。

        如果在一段时间后有任何未完成的确认，则会触发所谓的强制休假机制。 它从组中删除这些参与者（即他们必须离开会议）。 因此可以保证原子性的实现，因为剩下的参与者被重新感知到PDU。令牌丢失和重复的处理方式类似。

        由于在发送方和接收方之间仅发生一次消息交换（数据PDU传送和相关的知识），因此两个令牌移动之间的消息的交叉和超越是不可能的。 所有参与者都以相同的顺序接收所有消息。 这确保了完全有序的交付。

        旋转令牌机制进一步保证了所有参与者之间的公平性。 即使不必传输数据，令牌的移位也支持早期检测参与者的失败。

五、QOS管理

        此节将描述如何计算QoS参数以支持上面介绍的缩放方案。 为了使决策过程尽可能简单，仅考虑QoS参数帧速率和像素分辨率。 以下决定适用于说话者和听众之间的关系。 记录扬声器的视频流并以更高的帧速率和更高的像素分辨率发送。 其他参与者以较低的帧速率和像素分辨率发送，因此当前认为这些参数对于所有听众来说是相等的。

5.1系统参数的计算

        Gcsva的会议相继成立，即新的参与者一个接一个地加入会议。 随着每个新加入，包括新的参与者在内的所有参与者通过QoS请求分组交换其QoS参数（帧速率和像素分辨率）。 QoS参数由监视器提供，监视器观察CPU负载并获得QoS值。 假设主机上没有运行其他应用程序，即参与者仅将计算机用于视频会议。

        每个参与者指示其可以接收扬声器的视频流和其他听众的视频流的质量。 QoS管理已知参与者的数量。 每个参与者的QoS-Request-包包含以下值：

        其中FR和FS表示所需的帧速率和扬声器视频流的帧大小（像素分辨率，像素x像素）。 FRL是听众视频流的所需帧速率，FSL是相关像素分辨率。

        在交换QoS-Request-packets之后，计算整个系统的QoS参数。 如第4节所述，它们与最强大的参与者有关。由于帧速率和帧大小可能不同，因此必须找到一种措施来比较参与者的QoS要求。

        在视频会议期间，通常仅传送谈话者的头肩透视图像。 例如，与电影不同，连续帧中只有少数变化。 因此，在下面的讨论中可以忽略帧间编码对传输速率的影响。 因此，视频流的传输速率由帧速率和像素分辨率决定。 依赖关系是线性的（参见图2）。

        为了表达说话者拥有最高优先级，我们引入了权重。 与听众相比，扬声器被赋予双倍值。 所有听众都拥有相同的体重。 所有参与者的权重之和为1.然后，n为参与者数量，Wx为参与者x的权重

        WS是说话者和WL听众的权重。

        在下文中，我们确定值C，其被用作比较参与者的QoS要求的度量。 参与者i的QoS要求是

        如果未输出本地视频流，则必须引入（n-2）而不是（n-1）。

        与发送相关的系统QoS配置QoS *由参与者k的QoS要求Ck确定，其中计算所有Ci的最大Cmax：

         如果新参与者加入会议或参与者离开会议，则必须重新计算QoS *。

        在更换扬声器之后，新扬声器必须使用新的QoS参数QoS *发送包括前一个扬声器在内的所有其他参与者的听众参数QOSL *。 所有参与者都必须接受这一点在接收视频流时更改帐户。

5.2 计算局部QoS参数

        收到有效的系统参数QoS * =（QoSS *，QOSL *）（（FRs *，FSs *），（FRL *，FSL *））用于发送视频流，每个参与者必须自己确定它是如何的 必须过滤传入的视频流。 到达（已记录的）视频流的帧大小只能通过部分解压缩来改变。 这需要额外的计算工作，这应该在接收器站点避免。 因此，我们决定所有参与者分别接收和处理系统帧大小为FSs *和FSL *的输入视频流。 因此缩放减少了调整输入滤波器中的帧速率。 设FR，即参与者i可以接受的扬声器的视频流的帧速率然后通过以下公式基于帧速率和帧大小之间的线性相关性（参见图1）来计算减少：

        过滤器必须缩小传入扬声器流的帧速率，从FRs *到FRs /。 相同的缩放原理应用于收听者FRL /的视频流的帧速率。

        必须分别针对组或扬声器的组成的每次更改重新计算这些参数。

四、视频流的动态可扩展性

        在视频会议系统中，每个参与者接收来自所有其他参与者的视频流。它必须在这些流被释放出来之前先对它们进行减压。多个视频流同时解压会使终端系统过载。缩放视频流可以减少解压开销。这可以在不同的点上完成，通过这些点可以应用不同的方法:分层的、受发送者限制的和受接收者限制的。根据路径末端接收者的要求，在网络节点上进行分层计算。由于我们的系统是直接运行在ATM上的，这种方法是不可行的。

        在发送者限制方法中，发送者调整视频流的方式使所有参与者包括较弱的参与者都能接收视频流。该方法适用于群组信道的概念。组通道为整个组定义了一个QoS级别，将会议的总带宽限制为组中最慢工作站的性能。当参与者的性能几乎相同时，该方法很有效，但是当会议中包含了非常不同的性能参数时，它会极大地限制强大机器上的传输质量。

        受接收者限制的方法假设网络带宽不是瓶颈。 主机可以以尽可能高的性能发送。 接收器根据输入流的数量及其当前负载来缩小它们。 然而，该方法取决于所应用的压缩方法。 缩放也可能使功能较弱的主机过载。

        在我们的方法中，我们应用了一个组合方案。会议的总带宽与容量最大的参与者有关。 如上所述，在所有参与者之间划分带宽，使得当前的发言者具有更大的份额。 参与者的视频流根据其在总带宽上的配额发送。如有需要，视频流由输出滤波器调整。接收器必须根据性能参数对流进行过滤。扬声器流以尽可能高的服务质量播出，即更高的帧速率和更高的像素分辨率。它比听众的视频流过滤更少。在过载的情况下，仅可以显示听众的静止图像。

        由于参与者的动态加入和离开，要解压缩的视频流的数量可能会在会议期间发生变化。 因此，系统必须动态地调整过滤方案。 当参与者加入或离开会议时，在参与者之间重新协商总带宽及其分裂。

        图1给出了特定缩放情况的示例。 我们假设参与者c具有最高容量。 它能够处理每秒60帧（F / s）。 这是总带宽。 发言者（参与者b）获得20 Fls的配额，其他参与者（包括参与者c）可以10 F / s发送。 参与者a必须从60 Fls过滤到40 F / s。 这取决于参与者如何在单个视频流之间共享这40个Fls。 例如，扬声器可以用20 Fls播放，其他3个参与者获得6 F / s。 参与者d仅显示发言者。 对于其他参与者，它会显示静止图像。

        应用的缩放方法取决于缩放目的和应用的压缩技术。 存在不同的可能性，诸如时间缩放，空间缩放，频率缩放，振幅缩放和颜色空间缩放。 我们的缩放方法的目标是减少解压缩工作，从而减少视频流的接收器站点处的计算开销。 因此，需要大量计算的缩放方法是不合适的。 我们在输出滤波器中使用时间和空间缩放（参见图3），用于发送端站点的缩放，而在接收端站点的输入滤波器中只使用时间缩放。 对于时间缩放，采用帧丢弃滤波器。 使用的压缩方法是CellB。 我们首先为MPEGI流实现了过滤器，但是实现的性能太差了。

三、地面控制

        在会议中，通常只有一位发言者在特定的时间段内发言。其他参与者听它的演讲。Gcsva的QoS管理就是基于这一原则。它假设存在一个特定的扬声器，其视频和音频流处理特别小心。这避免了对扬声器进行大规模识别的方法，因为当前的扬声器是已知的。发言权的分配是通过一个联合发言者队列来完成的。队伍的头部是发言者。其他参与者可以在短时间内打断发言者的提问或发言。他们的音频流与扬声器的音频流合并。但是，这不会改变扬声器和任何QoS参数。中断选项可以关闭。还有其他方法可以尽可能自然地模仿会议中的社交行为。在Gcsva发展的当前状态下，我们不考虑任何精细的发言权控制机制，因为我们主要关注分布式组和QoS管理方法的细化。这计划用于后期的开发阶段。

        扬声器队列显示在每个参与者的屏幕上。 队列可以由参与者操纵。 例如，当讨论使其注释不必要时，它可以随时将自己从队列中删除。 每个参与者屏幕上的队列一致性由分布式组管理确保。

        由于发言者在这个会议场景中扮演着重要的角色，因此当前发言者的视频流传输的服务质量要高于其他参与者(听众)。它的视频流比听者的视频流有更大的带宽配额。在接收端，只有当所有侦听器的流都缩小了时，才会对其进行过滤。此外，扬声器的窗口大小大于侦听器的窗口大小(使用相同的窗口大小)。在尽力而为的基础上以较低的QoS处理侦听器的视频流。这些视频流首先在接收端缩小，如果需要，直到静止图像。由于带宽要求低，所有参与者的音频流都以保证的QoS传输。

（二）多方会议系统的QOS管理要求

        大多数现有的会议系统几乎不支持为不同的视频流和音频流灵活地分配QoS参数以控制带宽分配。如果参与者的表现非常不同，这一点尤其重要。应该实现具有不同性能参数的endsystems能够以可接受的服务质量处理多媒体流。它们必须防止过载。同时，避免了网络资源的浪费。因此，视频会议系统应该提供根据参与者的主机和网络的性能可能性动态缩小多媒体流的手段。

        在此提出，源提供具有3种不同质量的多媒体流用于参数帧速率，颜色空间和像素分辨率。 接收器可以根据他们的期望和性能参数选择适当的质量。这种方法对于按需服务或远程教学是有用的，其中通常一个源发送给几个接收器。 在会议系统中，每个发送者必须接受并实时发送几个不同质量的流，这会使网络和参与者过载。

        一种可能的方法是在中描述的接收器驱动的分层多播。 每个源发送包含不同QoS级别的流。 接收者选择他们想要接受的频道，从而确定接收流的质量。 此外，接收器可以为发送者分配权重。 这些权重（优先级）定期公布。 因此，更重要的来源（从接收者的角度来看）可以区别于不太重要的来源。 根据它们的权重，源可以在不同的网络信道上发送其视频流（信号层）的不同级别。 但是，对于这种方法，应用了特定的视频压缩方法。

        一种可能的方法是接收驱动的分层组播。每个源发送一个包含不同QoS级别的流。接收者选择他们想要接受的频道，从而决定接收的流的质量。此外，接收者可以为发送者分配一个权重。这些权重(优先级)定期公布。因此，更重要的消息源(从接收者的角度来看)可以从不那么重要的消息源中分离出来。根据其权重，源可以通过不同的网络通道传输不同级别的视频流(信号层)。对于这种方法，应用了一种特定的视频压缩方法。

        在纯视频会议系统中，使用所谓的组信道概念。 组通道为每个参与者分配带宽配额，从而为发言者和听众定义不同的配额。 要以最低性能主机未过载的方式选择要传输的所有视频流的总带宽。 因此，保护接收器免受过载并节省网络资源。 这种方法的不足之处在于，在参与者的性能参数变化很大的情况下，服务质量由最弱的主机确定。 对于能够处理高质量视频的强大工作站，这是不能令人满意的。 这里需要更灵活的可扩展性方法。

        另一个重要的设计决策涉及为会议系统选择的管理方案。大多数现有的视频会议系统使用集中式服务器进行组和QoS管理，就像系统中的系统一样。服务器控制整个会议。通常，发起会议的参与者将接管服务器角色。当它离开会议时，会议大多结束。集中式解决方案易于实施，因为所有管理功能都集中在一个系统中。如果应用复杂的控制算法，例如将传输的视频流适应于接收端系统的当前性能情况(负载)，尤其如此。集中式方法的主要缺点是服务器可能出现故障，从而立即终止会议。此外，当许多客户端同时处理服务器时，服务器可能会成为性能瓶颈。另一个问题是当持有该功能的参与者离开会议时，服务器功能的转移，但不希望终止会议。为了避免这些问题，分布式管理方法似乎更适合我们。当在广域网上建立视频会议服务作为互联网时，分布式方法是不可避免的。在分布式组中，还应用了管理方法，但它不包括扩展机制。

（一）概述及动机

        分布式交互式多媒体应用的QoS管理目前主要基于集中式方法，其中单个组服务器管理所有参与者的QoS要求。组服务器处理起来比较简单，但由于服务器故障或性能瓶颈，它们可能成为系统的弱点。为了避免这些问题并更好地支持终端系统中的应用程序，应用程序级别的分布式QoS管理似乎更合适。于是提出了这种分布式QoS管理。它是为多方视频会议系统GcsvA设计和实现的。我们的方法的基本思想包括分散计算和分配扬声器和听众的带宽配额，从而将最强大的参与者的接收能力作为衡量标准。功能较弱的接收器通过根据其性能参数进行过滤来缩小传入视频流的数据速率。通过专用的组通信协议确保终端系统中QoS数据的一致性，该协议提供可靠的，原子的和有序的递送服务。

        越来越多地使用分布式交互式多媒体应用作为CSCW应用（计算机支持的协同工作）的联合编辑或视频会议，需要适当的机制来管理和监督服务质量（QoS）要求。 大多数现有的视频会议系统不为QoS和带宽管理提供广泛的系统支持。 特别是，它们不支持与会议参与者的数量和所使用的终端系统的性能相关的视频流的缩放。用户常常被迫通过“试错”来确定最佳工作提供的可接受的服务质量。

        在多方会议系统中，多媒体流不仅从一个或几个选定的源流向不同的接收者，而且从每个协商参与者流向所有其他参与者，即每个参与者必须同时处理几个到达的流。与通常在硬件中执行的视频流压缩相反，解压缩在软件中实现，这对CPU造成了相当大的负担。几个视频流的同时解压缩可能导致终端系统的性能过载。因此，QoS管理必须考虑到终端系统的性能能力。在所有通信伙伴和不同流的网络之间协商传统意义上的QoS参数变得过于复杂。在一般情况下，当改变协商或网络参数的组成时，它必须被重复。为了达到这个目的，它似乎更有用，而不是应用通用的QoS框架来设计专用应用程序的专用解决方案，而这些应用程序恰好满足它们的需求。

        在此篇中，提出了一种用于多方多媒体会议系统的分布式QoS管理的方法。 该方法已经为视频会议系统Gcsva（ATM上的视频会议中的组通信和可扩展性）设计和实施。 Gcsva专为支持CSCW应用和远程教学而设计，尤其适用于远程研讨会。 它针对的是小型封闭式讨论组。 Gcsva的特点是分布式组织原则。 它直接在ATM上运行。