1. TIP是什么？
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的基礎上擴展，能允許每條視頻流明確最大碼率等等。
2. TIP實現指導
CISCO為TIP開發者指出實現指導。CISCO建議按以下步驟進行。
1) 在IMTC官網取TIP協議文檔，學習評估。
2) 取TIP源碼看實現。
3) 學習CISCO的單屏網真和三屏網真的TIP實現文檔。（這步重要）
3. TIP的版權
CISCO將TIP協議開放並轉交給了IMTC國際多媒體通信聯盟(International Multimedia Telecommunications Consortium)。
IMTC給於TIP在世界范圍內免版稅許可證。允許永久的世界范圍的免費應用TIP協議。
4. 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
5. TIP和RFC
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
6. TIP功能摘要
本節TIP功能摘要，是對TIP協議標准文檔的內容抽取和摘要。
1) 媒體通道建立
TIP是假設媒體路徑基本建立好，TIP不負責NAT/防火牆穿越，TIP會有獨立的媒體協商，TIP能力檢測，加密通道。
TIP能力檢測和協商。TIP通過RTCP的應用擴展進行TIP能力檢測，如檢測到對端有TIP能力則進一步協商，如對端沒有TIP能力僅在媒體通道中發一路視頻或音頻。
TIP允許使用加密通道SRTP/SRTCP。 加密技術DTLS(Datagram Transport Layer Security) EKT（Encrypted Key Transport）。
2) TIP媒體復用
i. 位置信息
TIP的關鍵功能就是復用多個媒體流。被復用的媒體流需要是相同的媒體類型，它們通過相同的UDP通道傳遞並准遵UDP標准。為實現復用需要為每路數據打上標簦，這里我們稱之為“位置”。位置信息放在CSRC中。
TIP的RTP 包頭
MUX-CSRC如下圖
視頻位置信息的定義如下圖
音頻位置信息的定義如下圖
ii. TIP RTCP 應該擴展
iii. 復用控制
MUXCTRL是用於協商和建立TIP復用的參數。它需要在媒體通道建立好以后，媒體碼流真正傳輸前使用。有時也使用在呼叫更新后。
iv. 網絡線路測量
TIP通過RTCP的“ECHO”擴展能精確測量對端點的網絡線路。此方法的功能和ICMP ECHO類似，但相比ICMP ECHO有些明顯的優勢。如ICMP ECHO的數據包常會被防火牆等中繼設備過濾掉，但RTCP一般不會被過濾。
TIP設備用RTCP APP ECHO 包來檢測網絡時延，對端保活測試。
v. 媒體流控制
這里的媒體流控制是對媒體編解碼（信源）的控制應該而不是對RTP流（信道）的控制。
vi. 視頻刷新請求
當視頻源切換的時就需要視頻編碼器產生一個關鍵幀IDR。下面的RTCP APP就實現這個機制。這個機制不是用於丟包修復的機制。Subtype必須是8。
vii. 媒體選項
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加密。
viii. SPI MAP
ix. 請求對端發送
TIP支持在呼叫過程中動態增加或減少媒體源。當在一個通道中加入一個新的媒體源，TIP設備需要發送一個REQTOSEND消息到對端，對端可以接收或拒絕，只有對端接收后（回發ACK）才能發送新的媒體源。
x. 通知信息
TIP設備實時產生NOFIFY消息告知當前狀態的變化
xi. ACK回傳信息
xii. RTP 信息反饋
3) 呼叫建立例子
i. 基本TIP 建立
ii. DTLS加密TIP建立
iii. DTLS和EKT加密TIP建立
7. LIBTIP
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的命名空間。
8. 參考：
《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