标签：
CISCO给TIP的定义如下：
The TIP protocol specifications describe how to multiplex multiple screens, multiple audio streams, as well as an auxiliary-data screen into a single Real-Time Transport Protocol (RTP) flows, one each for video and audio. It enables point to point and multipoint sessions as well as a mix of multi-screen and single-screen endpoints.
The TIP protocol specification also defines how RTP Control Protocol (RTCP) - APP extensions are used to indicate profile capabilities and per media flow options as a session is established. It also defines how devices can provide feedback and trigger resiliency mechanisms during the life of the streams.
TIP（Telepresence Interoperability Protocol）思科网真交互协议。Telepresence--思科网真
TIP协议规范描述如何实现实时的复用多路视频，多路音频及辅助视频到一路RTP流。支持单屏和多屏的点对点及多点会议。TIP协议还规范定义了如何利用RTCP应用扩展来协商媒体能力集和媒体通道的建立。TIP协议还为设备提供在媒体通道建立后的反馈和触发机制。
从RTP和RTCP两方面。
1） 利用现有RTP的扩展实现多路音视频线路复用。
2） 利用RTCP的扩展实现一套能力协商和设备间的信息交互机制。
总的来说, TIP系统是高端的高清视频会议设备，能处理多个音频和视频流。TIP设备通过TIP的消息交换来协商媒体流数量，但这些表现为传统语音IP(VoIP)设备与音频和视频功能。
TIP的终端, 包括可以参于实时点对点和多点视频会议的单屏和三屏设备。在多点会议中, 终端将通过TIP消息与MCU沟通。TIP中MCU可以是终端也可以不是终端。可以用来解码转码媒体流，也可以仅仅提供多点服务。
TIP协议提供了多种方式来定义终端和MCU，并且严格定义了终端和MCU之间的协商语法和机制。TIP协议提供一套文档来说明定义协议中的细节。这套文档还在进化过程中，TIP使用者可以及时更新。
TIP的当前版本是V8，这是TIP发布后的第三个版本。V8在V7的基础上扩展，能允许每条视频流明确最大码率等等。
CISCO为TIP开发者指出实现指导。CISCO建议按以下步骤进行。
1) 在IMTC官网取TIP协议文档，学习评估。
2) 取TIP源码看实现。
3) 学习CISCO的单屏网真和三屏网真的TIP实现文档。（这步重要）
CISCO将TIP协议开放并转交给了IMTC国际多媒体通信联盟(International Multimedia Telecommunications Consortium)。
IMTC给于TIP在世界范围内免版税许可证。允许永久的世界范围的免费应用TIP协议。
CISCO官网 http://www.cisco.com/web/about/doing_business/tip/index.html
IMTC官网 http://www.imtc.org/tip-for-developers/
TIP源码 http://tiprotocol.sourceforge.net
TIP V8中相关的RFC标准和RFC草案如下：
1) IETF RFC 3261 “SIP: Session Initiation Protocol”
2) IETF RFC 3264 “An Offer/Answer Model with the Session Description Protocol (SDP)”
3) IETF RFC 2327 “SDP: Session Description Protocol”
4) IETF RFC 3550 “RTP: A Transport Protocol for Real-Time Applications”
5) IETF RFC 3551 “RTP Profile for Audio and Video Conferences with Minimal Control”
6) IETF RFC 4961 “Symmetric RTP/RTP Control Protocol (RTCP)”
7) IETF RFC 3984 “RTP Payload Format for H.264 Video”
8) IETF RFC 4585 “Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)”
9) IETF RFC 5761 “Multiplexing RTP Data and Control Packets on a Single Port”
10) IETF RFC 3711 “Secure Real-time Transport Protocol (SRTP)”, includes SAVP
11) IETF RFC 4347 “Datagram Transport Layer Security”
12) IETF RFC 5764 “Datagram Transport Layer Security (DTLS) Extension to Establish Keys
13) IETF Internet-Draft “Revision of the Binary Floor Control Protocol (BFCP)”
2014年5月 cisco(思科) polycom（宝利通） Huawei(华为)三家向IETF 提交 RFC7205 “Use Cases for Telepresence Multistreams” 作为网真多流的使用案例。
注意：RFC7205 的Status是 INFORMATIONAL 而非 STANDARD。
RFC7205目录如下
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of Telepresence Scenarios . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Point-to-Point Meeting: Symmetric . . . . . . . . . . . . 7
3.2. Point-to-Point Meeting: Asymmetric . . . . . . . . . . . 7
3.3. Multipoint Meeting . . . . . . . . . . . . . . . . . . . 9
3.4. Presentation . . . . . . . . . . . . . . . . . . . . . . 10
3.5. Heterogeneous Systems . . . . . . . . . . . . . . . . . . 11
3.6. Multipoint Education Usage . . . . . . . . . . . . . . . 12
3.7. Multipoint Multiview (Virtual Space) . . . . . . . . . . 14
3.8. Multiple Presentation Streams - Telemedicine . . . . . . 15
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. Informative References . . . . . . . . . . . . . . . . . . . 16
可以看到提出的网真的应用场景有远程呈现，多点多视，多点教育，远程医疗等等。
2014年7月 （就在本月） cisco(思科) polycom（宝利通） Huawei(华为)三家又向IETF 提交 RFC7262"Requirements for Telepresence Multistreams" 网真多流的需求。
注意：RFC7262的Status是 INFORMATIONAL 而非 STANDARD。
RFC 7262目录如下：
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Informative References . . . . . . . . . . . . . . . . . . . 11
在RFC 7262中介绍了网真多流的需求和相关背景。
TIP协议是围绕着IETF(Internet Engineering Task Force)标准为VOIP和视频会议设计的，TIP并不是IETF的标准。一个TIP设备可以使用标准SIP,RTP.RTCP进行媒体传输。
TIP设备在呼叫阶段能提供音视频流，在呼叫建立阶段不会表达有多个流的能力。
IETF RTP媒体载荷如下：
Audio AAC-LD
Bitrate: 64 kbps/channel
RTP Payload: IETF RFC 3640, AAC-hbr mode
Default Dynamic Payload Number: 96
G.711 (u-law)
RTP Payload: IETF RFC 3351
Static Payload Number: 0
G.722
RTP Payload: IETF RFC 3351
Static Payload Number: 9
DTMF
RTP Payload: IETF RFC 2833
Default Dynamic Payload Number: 101
Video H.264 Baseline Profile
Image sizes: 1080p, 720p, 1024x768, 352x288
Bitrates: 4 Mbps to 300 kbps
RTP Payload: IETF RFC 3984, packetization mode 1 and mode 0
Default Dynamic Payload Number: 112
本节TIP功能摘要，是对TIP协议标准文档的内容抽取和摘要。
TIP是假设媒体路径基本建立好，TIP不负责NAT/防火墙穿越，TIP会有独立的媒体协商，TIP能力检测，加密通道。
TIP能力检测和协商。TIP通过RTCP的应用扩展进行TIP能力检测，如检测到对端有TIP能力则进一步协商，如对端没有TIP能力仅在媒体通道中发一路视频或音频。
TIP允许使用加密通道SRTP/SRTCP。 加密技术DTLS(Datagram Transport Layer Security) EKT（Encrypted Key Transport）。
TIP的关键功能就是复用多个媒体流。被复用的媒体流需要是相同的媒体类型，它们通过相同的UDP通道传递并准遵UDP标准。为实现复用需要为每路数据打上标簦，这里我们称之为“位置”。位置信息放在CSRC中。
TIP的RTP 包头
MUX-CSRC如下图
视频位置信息的定义如下图
音频位置信息的定义如下图
MUXCTRL是用于协商和建立TIP复用的参数。它需要在媒体通道建立好以后，媒体码流真正传输前使用。有时也使用在呼叫更新后。
TIP通过RTCP的“ECHO”扩展能精确测量对端点的网络线路。此方法的功能和ICMP ECHO类似，但相比ICMP ECHO有些明显的优势。如ICMP ECHO的数据包常会被防火墙等中继设备过滤掉，但RTCP一般不会被过滤。
TIP设备用RTCP APP ECHO 包来检测网络时延，对端保活测试。
这里的媒体流控制是对媒体编解码（信源）的控制应该而不是对RTP流（信道）的控制。
当视频源切换的时就需要视频编码器产生一个关键帧IDR。下面的RTCP APP就实现这个机制。这个机制不是用于丢包修复的机制。Subtype必须是8。
RTCP APP MEDIAOPTS。这节定义非常多。包含
1) 音频动态输出通道。
2) 音频矩阵，实时语音检测矩阵。
3) G722音频。
4) 视频刷新类型。
5) 视频图像参数。
6) 视频编码类型CAVLC/CABAC。
7) 视频长参考帧。LTRP
8) 辅视频帧率。
9) 渐进的解码器刷新。
10) 视频High Profile。
11) 限制的媒体。
12) 非限制的媒体。
13) 辅视频控制BFCP。
14) EKT加密。
TIP支持在呼叫过程中动态增加或减少媒体源。当在一个通道中加入一个新的媒体源，TIP设备需要发送一个REQTOSEND消息到对端，对端可以接收或拒绝，只有对端接收后（回发ACK）才能发送新的媒体源。
TIP设备实时产生NOFIFY消息告知当前状态的变化
http://tiprotocol.sourceforge.net
TIP库是用C++实现的TIP协议库，提供了一套简单的API接口来实现TIP功能。目前版本支持TIP V6和V7。
TIP库提供了三类API接口
1) 系统接口 System Api
系统接口提供了TIP系统级的交互接口。两个主要的系统接口是TIP协商和呈现协商。
2) 媒体接口 Media Api
媒体接口提供方法初始化和响应媒体事件。媒体接口也分为两类，媒体消费（Sinks）和媒体产生（sources）。
3) 转发接口 Relay Api
转发接口使用户能分别接收系统接口和媒体接口并将它们转发到时新的句柄。这个新句柄可以是另一个线程或进程甚至是另一个系统。
如上图，一个典型的TIP系统由呼叫控制，复用/解复用和媒体子系统组成。
l 呼叫控制系统：呼叫控制由基本呼叫系统（如SIP或H.323，注意：TIP不仅可用SIP也可以和H.323相结合）和TIP协议协商组成。
l 复用/解复用系统：用中继接口对RCP/RTCP包转发到正确目标。
l 媒体系统：使用媒体接口来接收和处理媒体信息。
IIBTIP是一套C++实现的库，可以用于跨平台的环境。这套库使用了标准的C++函数和模板库如STL。它不创建线程或进程，用户需要自己周期性的调用TIP库中的API函数和驱动TIP库的动作。这套库也不会创建或管理任何sockets或其IPC(inter-procss communication)。所有网络包的收发处理都需要用户自己用代码实现。同样这套库不会锁线程或其它的动作来保证线程安全，然而库的高级API接口对象是自独立的（无全局量），这样在不同线程中使用对象也是安全的。TIP事件的处理通过注册回调函数来调用。用户使用LIBTIP库的模型如下：
用户代码驱动调用TIP API，TIP 回调驱动用户代码，在这个过程中用户要注意不要死锁和死循环。
User code à TIP API à TIP Callback à User code
所有 TIP 库的类，函数和定义都在LIBTIP的命名空间。
《Telepresence Interoperability Protocol (TIP) Version 8.0》
《Telepresence Interoperability Protocol (TIP)Library API Guide》
http://www.imtc.org/tip-for-developers/
http://www.cisco.com/web/about/doing_business/tip/index.html
标签：
原文地址：http://www.cnblogs.com/huxiaopeng/p/5653361.html
