往回通道连接-kubernetes与微服务架构的端到端流水线驱动devops落地

时间:2024-06-30 18:26:09
【文件属性】:

文件名称:往回通道连接-kubernetes与微服务架构的端到端流水线驱动devops落地

文件大小:4.4MB

文件格式:PDF

更新时间:2024-06-30 18:26:09

onvif spec 文档 中文版

12.3 往回通道连接 本节介绍如何在客户端和服务器之间建立一个双向的连接。使用 RTSP 协议[ RFC 2326] 对反向通道连接进行处理。这里将存在一种机制用于表明客户端想建立一个往回通道连接。 RTSP 提供了功能标签来处理这样的附加的功能。 支持双向连接的设备(如音频或元数据连接)应该支持已经介绍 RTSP 扩展。 12.3.1 RTSP协议请求的标签 [ RFC 2326]的 RTSP 标准,可以用附加对象头进行扩展。为了这个目的,将引进一个请 求的标签来处理专门的附加功能(见 RFC2326] ,1.5 扩展 RTSP 和 12.32 需求) 请求标签是用来判断是否支持此功能。这头应包含任何请求并且要求服务器理解这些特性并 能够正确对这些请求进行应答。 支持反向通道的一种装置,应当理解的反向通道的标签: www.onvif.org/ver20/backchannel 希望建立具有数据反向通道的 RTSP 连接的客户应该在请求信息中包括请求的 Require 头 12.3.2双向连接的连接设置 客户端应当在它的描述请求中包括特性标签,用以表明应该建立双向数据连接。 理解这一要求标签的服务器应在 SDP 协议中包含一个正如在媒体类别的配置一样的额外流 媒体。 根据的 RTSP 标准,一个不理解的反向通道的特性标签或不支持双向数据连接 RTSP 服务 器会响应错误代码 551 Option not supported。然后,客户端可以尝试建立一个没有反向通道 RTSP 连接。 一个 SDP 的文件被用来描述会话。服务器应在每一个媒体选项中包括一个 a= sendonly 或 b= recvonly 属性来表明将要发送数据的方向。 服务器应该列举出所有支持的解码规则作为自己媒介选项以及客户应该选择哪一种。


网友评论