流媒体相关交互协议和开源服务介绍

SIP协议

SIP是Session Initialization Protocol （会话初始协议）的缩写，用来建立、更改和终止一个或者多个参与者的会话。这些会话包括多媒体会议、网络呼叫等。
 

SDP协议

SDP是Session Description Protocol（会话描述协议）的缩写，主要是用于在会话建立过程中对流媒体相关信息进行描述的协议。SIP协议建立到结束会话的过程中一般需要携带SDP数据。
 

Jingle协议

Jingle协议的目的是在XMPP实体间建立一对一、点对点的媒体会话，使其在进行媒体数据协商和交互时使用XMPP的信令交互。虽然Jingle协议提供了一个通用的会话管理框架，但是其设计的原始目的仅仅只是为了音视频通讯，强调的是“简单”。Jingle协议的目的不是为了建立一个完整的电话应用程序，包括呼叫等待、呼叫转发、呼叫转移、IVR系统、定位、视频会议等等。这些功能是对jingle感兴趣的用户群体将其添加到了jingle的核心层，专门为了设计简单而广义的会话协议。
此外，Jingle不是为了代替或是取代现有的已经存在了很久的SIP协议，因为双栈式的XMPP+SIP客户端很难创建。Jingle是作为一个纯粹的XMPP信令协议而被设计的。但是，Jingle同时被设计时也能够互通SIP协议使数以百万计的XMPP客户端能够被添加到VoIP网络，而不是限制XMPP用户使其成一个单独的网络。
 

LibJingle协议

一对libjingle 的对等连接实际上是由两个通道组成：
会话协商通道（也称为信令信道）是用于协商数据连接的通信链路。此通道用于请求连接，交换人选，并协商会话的详细信息（如套接字地址，需要编解码器，以交换文件，连接变更请求，并终止请求）。这是计算机之间进行的第一次连接，并且仅在由该连接可以将数据信道来建立。对libjingle 采用先导，以jingle 指定要建立数据连接所需的节和响应（见jingle 和对libjingle），该通道通过中介XMPP 服务器发送节;示例代码中使用了谷歌Talk
服务器作为中介。
数据通道是在点对点会话之间交换实际数据（音频、视频、文件等）。数据通道的数据依赖于传输协商，被捆绑在TCP 或UDP 包中。并且不经过XMPP 服务器。
 

WebRTC系统

Web 开发者开发的程序，Web 开发者可以基于集成WebRTC 的浏览器提供的web API 开发基于视频、音频的实时通信应用。其中的媒体描述是用SDP描述的，通信协议和方式可以自定义。
WebRTC服务器，是一个开源的媒体服务器，包括媒体编解码和信令协商，其中LibJingle是WebRTC的重要组成部分，该LibJingle编程的库可以供其他平台使用与WebRTC服务器进行对接。


 
 

WebRTC2SIP系统

WebRTC2SIP是RTCWeb到SIP网络的网关。浏览器通过WebSocket和该网关进行SIP通信，网关将这些数据通过UDP或TCP转给SIP终端，从而实现SIP终端和浏览器的多媒体通信。
 


 

SIPML5系统

SIPML5是用JAVASCRIPT实现的SIP协议栈，通过这套JS可以很方便的和WebRTC2SIP网关进行SIP通信，数据传输通道使用WebSocket。
 

STUN协议

STUN（Session Traversal Utilities for NAT，NAT 会话传输应用程序）是一种网络协议，它允许位于NAT（或多重NAT）后的客户端找出自己的公网地址，查出自己位于哪种类型的NAT 之后以及NAT为某一个本地端口所绑定的Internet 端端口。这些信息被用来在两个同时处于NAT 路由器之后的主机之间建立UDP 通信。
STUN 的探测过程需要有一个公网IP 的STUN server，在NAT 后面的UAC 必须和此server 配合，互相之间发送若干个UDP 数据包。UDP 包中包含有UAC 需要了解的信息，比如NAT 外网IP，PORT 等等。UAC 通过是否得到这个UDP 包和包中的数据判断自己的NAT 类型。
stun.l.google.com:19302

stun1.l.google.com:19302

stun2.l.google.com:19302

stun3.l.google.com:19302

stun4.l.google.com:19302

stun01.sipphone.com

stun.ekiga.net

stun.fwdnet.net

stun.ideasip.com

stun.iptel.org

stun.rixtelecom.se

stun.schlund.de

stunserver.org

stun.softjoys.com

stun.voiparound.com

stun.voipbuster.com

stun.voipstunt.com

stun.voxgratia.org

Stun.xten.com
 

TURN协议

TURN（全名Traversal Using Relay NAT），是一种资料传输协议（data-transfer protocol）。允许在TCP或UDP 的连线上跨越NAT 或防火墙。
TURN 是一个client-server 协议。TURN 的NAT 穿透方法与STUN 类似，都是通过取得应用层中的公有地址达到NAT 穿透。但实现TURN client 的终端必须在通讯开始前与TURN server 进行交互，并要求TURN server 产生"relay port", 也就是relayed-transport-address。这时TURN server 会建立peer, 即远端端点（remote endpoints）, 开始进行中继（relay）的动作，TURN
client 利用relay port 将资料传送至peer, 再由peer 转传到另一方的TURN client。
 

ICE协议

交互式连接建立（Interactive Connectivity Establishment），一种综合性的NAT 穿越的技术。
交互式连接建立是由IETF 的MMUSIC 工作组开发出来的一种framework，可整合各种NAT 穿透技术，如STUN、TURN（Traversal Using Relay NAT，中继NAT 实现的穿透）、RSIP（Realm Specific IP，特定域IP）等。该framework 可以让SIP 的客户端利用各种NAT 穿透方式打穿远程的防火墙。
基于信令协议的多媒体传输是一个两段式传输。首先，通过信令协议（如SIP）建立一个会话连接，通过该连接，会话双方（Agent）通过SIP 交互所承载的SDP 消息彼此学习传输媒体时所必须的信息，针对媒体传输机制达成共识。然后，通常采用RTP 协议进行媒体传输。
基于传输效率的考虑，通常在完成第一阶段的交互之后，通信双方另外建立一条直接的连接传输媒体。这样就会减少传输时延、降低丢包率并减少开销。这样，用于SIP 传输的链路就不再用于传输媒体。现在，问题出现了，由于不采用原来的链路，当传输双方中任一方位于NAT 之后，新的传输链接必须考虑NAT 穿越问题。