标准规范下载简介：
内容预览由机器从pdf转换为word，准确率92%以上，供参考
YD／T 3245.2-2018 远程呈现视频会议系统协议技术要求 第2部分：信令流程.pdf5.4远程呈现受控媒体和CLUE分组语法
远程呈现受控媒体待发送的内容通过CLUE协议，在远程呈现数据信道上协商。在SDP中，远程 呈现受控媒体仍然是m行定义的媒体流，若要被CLUE控制，它的mid值应包含在CLUE分组中。 不受CLUE控制的m行遵循一般的SDP媒体流协商规则，如IETFRFC3264。
5.5远程呈现受控媒体的SDP语法
JB/T 3299-2012 手动插腿式液压叉车5.5.1CLUE编码
YD/T3245.1一2017《远程呈现视频会议系统协议技术要求第1部分：媒体参数》中定义了“编码 的概念，即发送端的编码能力。媒体提供者希望发送的每个编码，都通过恰当媒体类型的m行发送，并且 应通过“过送sendonly”属性标记为仅发送，或通过属性标记为仅发送，或通过属性标记为非活动。 活动编码（属性为“性为sendonly”）的编码限制可以用现有的SDP语法表示。 因为编码也是CLUE受控的，所以也应包含上文定义的CLUE分组中的。 除IETFRFC3264中规定的一般限制之外，在媒体提供方收到有效的CLUE配置消息之前，媒体 流的m行方向属性应被视为“须被inactive”。这意味着媒体包应在配置完成后才能发送，而非媒体包 （例如STUN和DTLS）若协商则应按常规发送。 每个代表一个CLUE编码的m行应包含一个IETFRFC4574规定的457属性。发送端在CLUE宣 告消息中，接收端在CLUE配置消息中，使用这个标记来识别某个编码。每个标记应与SDP消息中同 CLUE分组中的所有其他m行的标记不同
5.5.1.2在CLUE协议中引用编码
虽然是在SDP中定义，但CLUE编码能从CLUE协议消息中引用一 挪些编码属于一个（宣告消息中的）编码组，以及使用哪种编码方法来对（配置消息中的）特定捕获进 行编码。远程呈现受控m行的标记就是CLUE协议中使用的参考。 CLUE宣告消息中的每个
YD/T 3245.22018
配置消息发送端发送的最新SDP中的远 并且其标记的值与
5.5.1.3m行方向性
本部分中规定的CLUE受控m行应是单向的。这是因为将m行设置为“a=sendonly”可以表达发 送端的编码能力，而在其他情况下，编码属性表达的是媒体行的接收能力。CLUE的高度非对称性意味 着，初始请求的接受者需要在自已的请求消息中添加m行的几率比其他SIP呼叫场景（双方可发送的 音视频流数量相当）高得多。
5.5.2CLUE编码接收协商
m行。这个m行同样是CLUE受控，因此也应携带CLUE分组中对应编码的“mid”
5.6SDP请求/应答步骤
5.6.2.1协商使用CLUE和远程呈现数据信道
如果接收端是远程呈现可用设备，且初始请求中既有数据信道的m行文有包含这个m行的“mid” 的CLUE分组，那么收发端应协商支持数据信道的m行，并将这个m行的“mid”加到对应的CLUE 分组中。 若远程呈现可用接收端接收到有数据信道的m行，但没有包含这个m行的“mid”的CLUE分组， 那么在没有其他能在信道上传输的非CLUE协议的情况下，它不应协商这个数据信道，
2协商CLUE受控媒体
YD/T3245.2—2018 中携带这些媒体行。
5.6.2.3协商非CLUE受控媒体
远程呈现受控设备为尽快响应，可能希望为用户染最初的单流音视频，待CLUE协商完成后再 转移到CLUE受控媒体。当然，它也可能只希望在CLUE受控媒体协商结束之后，再提供这些媒体流。 如果最初请求的接收端，在SDP应答中使远程呈现赋能，那么它可以通过接受或者拒绝非CLUE 受控m行来明确表达它的意愿：拒绝所有的m行将保证在CLUE受控媒体协商前非CLUE受控媒体无 法传输；而接受一个或多个非CLUE受控媒体m行将使这些媒体流能够传输。 如果应答者选择在远程呈现赋能呼叫中发送初始非CLUE受控媒体，后续章节将说明，在CLUE 受控媒体完成协商后，非CLUE受控媒体将会失能。
5.6.3初始请求/应答协商
在请求者和应答者都携带数据信道m行， 包含在对应的CLUE分组中的情况下， 功完成协商，呼叫即为CLUE赋能。在其他情况下 呼叫都不是CLUE赋能的。
5.6.3.2CLUE协商成功
在CLUE赋能呼叫成功建立的情况下，收发设备应开始协商CLUE信道，具体协商方法见CLUE 协议。如果协商成功，那么就可以开始发送CLUE协议消息。 在CLUE受控媒体行协商阶段，远程呈现可用设备可选择在非CLUE受控信道上不发送媒体。但 是，它应仍然准备好接收成功协商的非CLUE受控媒体行的媒体。 如果任意一端希望添加CLUE受控m行，可以发送一个SIP请求携带新的SDP请求。注意，如果 成功协商了绑定并且需要产生BAS，接收请求的设备在收到BAS请求之前不应产生新的SDP请求。
5.6.3.3CLUE协商失购
在初始请求/应答中，CLUE协商失败，呼叫不是CLUE赋能的，那么CLUE不能用在呼叫中。 程呈现可用设备应回复到非CLUE状态，或者终止呼叫
5.6.1.1增加或删除CLUE受控媒体
后续请求/应答交换可添加CLUE受控媒体的m行，在大多数情况下，至少需要一次额外的交换过 程才能让双方添加所有的编码、协商好能力以接收它们想要的编码。远程呈现可用设备可在CLUE协 议协商完成后再添加“a=recvonly”的CLUE受控m行。 后续请求/应答交换可冻结CLUE受控媒体的m行。一CLUE媒体协商成功，远程呈现赋能设备 应保证非CLUE受控媒体被冻结，以免其影响到CLUE受控媒体。冻结过程可能需要额外的SDP交换： 也可以合并到CLUE协商过程中。
5.6.4.2中途CLUE呼叫
YD/T 3245.22018
远程呈现可用设备从非CLUE设备收到初始SDP请求后，应在接下来的请求中加入新的数据信道 m行和相关的CLUE分组，来表明它是CLUE可用的。 如果在非CLUE呼叫途中，呼叫中一方或双方在SDP中加入CLUE数据通道m行、为其对应的 CLUE分组中设置“mid”，那么这个呼叫就有可能升级为CLUE呼叫：在数据通道协商成功后，CLUE 协议消息交换，呼叫就升级为CLUE赋能
5.6.4.3中途失能CLUE呼叫
在CLUE赋能呼叫中，如果CLUE数据信道协商失败，或者一端未将数据信道包含在相应的CLUE 分组中，那么这个信道的CLUE呼叫被失能。在这种情况下，CLUE不再赋能，因此相应CLUE分组 相关的所有CLUE受控媒体都必须停止发送。 注意，这种情况与CLUE数据信道失效或者CLUE协议发生错误不同，详细内容请参见CLUE协 议。
5.7CLUE协议与SDP协商的相互作用
本节定义CLUE协议与SDP协商之间如何相互作用，为处理中间状态的非原子操作提供参考建议， 并规定何时能发送CLUE配置媒体， CLUE中媒体流的信息包含在两类消息中： a）SDP，定义媒体地址和限制； b）CLUE消息，定义可用捕获设备的属性、场景信息和其他限制。 因此，某些操作（如宣告新的捕获等）由于需要同时改变SDP和CLUE消息，所以并非原子操作
5.7.2SDP与CLUE协商的独立性
为避免处理联锁状态机中潜在的错误状态，SDP和CLUE的状态机应独立地运行。CLUE的状态 不会约束设备何时发送新的SDP请求或应答，同样地，最近的SDP协商结果或状态不会约束设备何时 发送新的CLUE宣告或配置（除非SDP协商移除了CLUE信道）。 这意味着，设备在SDP中收到的CLUE编码可能并没有对应的捕获信息，或者设备在收到的CLUE 配置消息中对应的捕获编码尚未在SDP中协商。 CLUE消息中的
详细的CLUE状态机描述。类似地，设备可以基于CLUE状态机选择延迟发起新的SDP交换。
5.7.3媒体发送限制
虽然SDP和CLUE消息之间的状态彼此没有限制， 但它们都对媒体发送有限制：不充许发送CLUI 受控媒体，除非它在SDP和CLUE中都协商完成。即只有在最近的SDP交换中包含活动媒体通道并且 对端通过CLUE配置消息为编码指定有效捕获之后，设备才能发送特定CLUE捕获编码。
不论SDP和CLUE消息的接收顺序如何，远程呈现可用设备应能够处理CLUE消息引用到与最近 SDP不匹配的编码ID的状态，即使这种不匹配是短暂现象。接下来为消息顺序提供操作建议。 在相关状态机和其他限制运行的情况下，远程呈现可用设备应通过更新SDP或CLUE消息来保证 SDP和CLUE信令间的不一致是短暂的。 通常，当收到的消息中的信息不完整时，设备应等待相关的消息到来。例如，当设备在一个新的 SDP请求中收到三个新“a=sendonly”的m行，但没有收到为这些m行提供捕获信息的对应CLUE宣 告消息时，它不应该在应答消息中包含对应的“a=recvonly”m行，而应该在收到相关宣告消息后再发 送新的SDP请求。 通常，新的SDP协商比CLUE消息交换会消耗更多的资源，再加上请求/应答机制本身的限制，本 标准推荐优先考患更新CLUE消息。这样，接收端会在SDP应答前获得完整的信息，从而减少新的SDF 请求的数量，降低系统的开销。
5.8CLUE协议和RTP/RTCP捕获ID的相互作用
YD/T3245.1一2017《远程呈现视频会议系统协议技术要求第1部分：媒体参数》中对多内容捕 获MCC进行了定义：包含多个媒体源的捕获，可由多画面合成，或根据某些策略切换生成。 合成MCC的捕获可以在宣告消息中定义，也可以不在。如果定义了，并且MCC使用切换策略， 那么接收方可能希望确定当前有效的捕获源自哪里，以便基于捕获的几何位置使用几何校正，或者根据 源捕获的信息执行其他操作。 为了达成这个目的，YD/T3245.3一2018《远程呈现视频会议系统协议技术要求第3部分：媒体 传输》规定了在RTP或RTCP中携带源捕获的捕获ID。媒体提供者在发送切换媒体的同时，应在RTP 和RTCP中同时发送捕获ID
5.8.2MCC重定义时接收捕获ID
因为RTP/RTCP的捕获ID不是在定义MCC内容的CLUE协议消息的信道中传输，所以当MCC 的内容在重定义时固然会存在竞态条件。 当媒体提供者重新定义MCC时，接收端接收到的相关捕获ID相对于新的宣告消息存在超前或者 带后的可能。因此，无论接收到的CLUE受控媒体流是静态还是MCC（因为静态捕获可能在后续宣告 中重定义为MCC)，媒体接收端应能处理下列异常情况： a）RTP或RTCP中包含的捕获ID对应的捕获，未出现在最近处理的宣告消息中：
YD/T 3245.22018
b）RTP或RTCP中未包含的捕获ID对应的捕获，出现在最近处理的宣告消息中； RTP或RTCP中包含的捕获ID对应的捕获，与最近处理的宣告消息中的内容匹配，但宣告消 息中的MCC并没有包含这个捕获 d）RTP或RTCP中包含的捕获ID对应的捕获，尚未在最近处理的宣告消息中定义。
5.9使用BUNDLE复用CLUE受控媒体
在一个CLUE呼叫中，大量的媒体流可以同时发送和/或接收。一般来说，媒体流在单独的端口上 发送和接收。然而，这样的端口有时候开销太大，例如在防火墙和NAT下打开端口，或者收集ICE候 选时，等等。 BUNDLE扩展可用于协商将多个媒体行复用到一个五元组来收发媒体，这样支持BUNDLE的设备 之间就能减少上述开销。 CLUE可用设备可以通过支持BUNDLE扩展来减少端口开销，但并不强制约束必须支持BUNDLE。
5.9.2同时使用BUNDLE和CLUE
当同时使用BUNDLE和CLUE时，并不需要增加额外的需求或限制。本标准并不限制将CLI 媒体行与非CLUE受控媒体行合并到同一个或多个BUNDLE分组中。但通过下述步骤，可以 LUE和BUNDLE同时使用时的SDP请求/应答交换次数。
5.9.2.2初始请求
BUNDLE规定初始SDP请求应为每个m行分配一个单独的非零端口。因为在通常情况下，CLUE 可用设备不会在没有数据信道的时候加入CLUE受控媒体行，所以如果BUNDLE协商成功的话，CLUE 可用设备之间就可以在不用开启大量端口的同时支持大量的媒体流了。
当使用BUNDLE时，请求者应发送BAS请求。如果请求者按照建议未在初始请求消息中包含CLUE 受限媒体行，则会在后续请求中包含。在这种情况下，BUNDLE建议请求者不要“修改可能导致应答 者拒绝BAS请求的SDP参数”。在使用现有媒体行的编码及其他属性来增加新的CLUE受控媒体行的 同时，不应该增加应答者拒绝BAS请求的风险；在增加新编码及其他SDP属性到CLUE受控媒体行之 前，应该谨慎考虑是否可行。
5.9.2.4数据信道和RTP媒体复用
支持BUNDLE的CLUE可用设备，可以将数据信道与RTP媒体包含到同一个BUNDLE分组中。 在这种情况下，CLUE可用设备应能够将这些不同类型的传输解复用（具体可参考CLUE协议）。如果 BUNDLE分组除了包含CLUE数据信道之外，还包含其他通过DTLS传输的协议，CLUE可用设备还 不能够区分这些不同的协议。
YD/T 3245.22018
YD/T 3245.22018
6.2.2阶段 B初始通信和能力交换
YD/T3245.22018
在知道对端支持CLUE信令的情况下，终端发送包含它所支持的配置的TerminalCapabilitySet消息。 另外，为了将特定配置与特定CLUE捕获编码绑定，在每个配置中都加入了包含编码ID的CLUE编码 关联参数。 在不知道对端是否支持CLUE信令的情况下，终端应包含至少一个未标记有编码ID的配置。 然后，终端使用CLUE消息来执行CLUE信令流程。交换的第一部分是CLUE协议版本和扩展的 协商。第二部分是使用CLUE数据的终端能力的宣告。CLUE宣告消息中的编码ID与H.245能力中的 相同编码ID形成绑定。 TerminalCapabilitySet配置需要与CLUE数据中的同时传输集保持一致。 在收到CLUE宣告消息之后，对端将根据宣告消息和TerminalCapabilitySet消息中的信息，选择其 所需的捕获和编码。然后，对端发送CLUE配置消息，以指示其选择接收的捕获和编码。 对端还回复TerminalCapabilitySetAck消息，指示其收到了TerminalCapabilitySet配置。
6.2.3阶段C音视频通信建立
当收到含未标记编码ID的H.245配置项的TerminalCapabilitySetAck消息后，终端可发起H.245开 启逻辑信道流程，开启相应的媒体流。 对于标记了编码ID的配置项，终端仅为在CLUE配置消息中收到了编码ID的配置项开启媒体流。 H.245开启逻辑信道消息包含具有编码ID的CLUE关联能力，与媒体流的捕获编码对应。这使得接收 终端能够辨认媒体流与哪娜个捕获描述对应。在收到媒体流后，接收终端可以根据CLUE捕获描迷述对媒 体流进行处理。 在会话中，终端可能会更新CLUE宣告或配置消息，它们包含更新的CLUE数据。这同样可能会 要求更新TerminalCapabilitySet消息。最终会导致开启逻辑信道程序增加、重配置或释放逻辑信道。
想要改变带宽的终端应考虑其信令对CLUE数据的影响。如果带宽请求需要相较于已宣告的与特 定编码ID绑定的额外带宽，那么CLUE消息和TerminalCapabilitySet消息可能需要更新。 CLUE控制能力可用于多点会议的场景中。例如，多点控制器从多个终端接收CLUE消息和 TerminalCapabilitySet消息，使用收到的信息创造自已的CLUE数据，并将其发送到各个端点。
5.2.5阶段 E呼叫经
在普通的呼叫终止流程之外，终端可以指示捕获编码不再可用，或指示其不再希望接收特定捕获编 码。这可以通过使用CLUE消息和可用的TerminalCapabilitySet消息来体现。其结果是关闭一个或多个 逻辑信道的同时，不必终止呼叫。
YD/T3245.2—2018
6.3.2CLUE消息传输
6.3.2.1CLUE能力协商
6.3.2.1.1概述
本节描述在H.323系统中协商使用CLUE的方法。 远程呈现可用设备可从TerminalCapabilitySet消息中包含的能力决定如何支持CLUE。如果在 DataApplicationCapability中存在应用dataChannel，且DataChannelProfile的protocol为CLUE，那么则 是在SCTP连接上使用CLUE；否则，远程呈现可用设备将使用H.245一般消息来传输CLUE消息。
6.3.2.1.2H.225中的CLUE控制能力
表1CLUE控制能力
6.3.2.2CLUE消息
6.3.2.2.1SCTP传输
在能力交换阶段，远程呈现可用设备从远端接收TerminalCapabilitySet消息，获得其对SCTP的使 用方式，包括直接使用SCTP、SCTP/DTLS或DTLS/SCTP，并结合自已的SCTP使用方式，确定双方 共同支持的SCTP使用方式。 如CLUE协议所所述，CLUE消息通过DTLS/SCTP连接传输。通过这个连接来建立CLUE数据信 道。 在能力交换后，远程呈现可用设备使用包含上述使用方式的OpenLogicalChannel消息，与远端建 立WebRTC数据信道（即DTLS/SCTP连接）。首先，建立DTLS连接；当DTLS握手结束后，远程呈 现可用设备与远端建立SCTP连接；然后，可以使用CLUE数据信道中的方法发起双向的CLUE信道， 在建立CLUE信道之后，双方就可以在协商好的SCTP连接上传输CLUE消息了。
6.3.2.2.2H.245一般消息传输
YD/T 3245.22018
bMessageldentifier的耳
messageContent中用到的GenericParameters
其中，CLUERequest包含XML编码的CLUE请求消息（宣告、配置、支持、必备），如CLUE切 议所属；CLUEResponse包含XMIL编码的CLUE响应消息（确认、否认、错误），亦如CLUE协议所 述。 远程呈现可用设备使用合适的H.245一般消息来传输CLUE请求和响应，具体呼叫/会话过程见下 文。
6.3.2.3媒体关联
6.3.2.3.1概述
为了提供CLUE捕获和编码与最终媒体流之间的联系，需要关联ID将其绑定。因此在CLUE消息 中，使用编码ID属性，与特定的捕获关联。 为了将其与逻辑信道中的媒体绑定，编码ID也加入到TerminalCapabilitySet中。
6.3.2.3.2CLUE关联能力
CLUE关联能力见表4。
表4CLUE关联能力
表4CLUE关联能力（续）
CJ/T 447-2014 管道燃气自闭阀缩码 ID参数见表 5.
表 5 编码ID 参数
CLUE关联能力（包含编码ID参数） 用来为CLUE编码关联TerminalCapabilitySet消息。它同时 用来将特定H.245逻辑信道与通过编码IL 来的特定捕获/编码ID关联
网守应了解网关和终端对CLUE的支持能力。当呼叫过程中需要网关且呼叫中的终端支持CLUE 的时候，网守要选择支持CLUE的网关。 本节描述的场景为：一个终端在RAS过程中，使用GEF与网守协商CLUE控制能力特征，表示其 对CLUE信令的支持。协商过程使用注册消息（RRQ/RCF/RRJ）消息组以图示说明。 由于GEF是一个可选功能，为表示支持CLUE，终端和网守应支持GEF及其携带的CLUE控制能 力特征。 GEF包含必选（needed）特征、优选（desired）特征和支持（supported）特征。终端可在任意消息 中包含CLUE控制能力。然而，如果这个能力包含在必选特征中，注册可能会失败。 CLUE终端和网守之间的注册信令过程的典型场景如下。
GB/T 9746-2013 航空轮胎系列6.4.2注册信令过程典型场景
6.4.2.1成功场景