SIP基础协议总结
SIP协议是一个用于建立，更改和终止多媒体会话的应用层控制协议，大量借鉴了成熟的HTTP协议（文本格式编码，Request消息中的method等），采用基于文本的UTF-8编码方式，可以承载与UDP或者TCP协议之上(首选UDP)。和Diameter协议类似，SIP也是有一个基础协议和很多扩展协议，基础协议在RFC3261中定义，本文主要概括SIP基础协议的要点。
1. 基本概念：
· Session：Session简单的说就是一次通话，从摘机拨号开始到最终的挂机之间所有的SIP消息都属于一个Session，它们具有相同的Call-Id。
· Dialog：基于Peer-to-Peer，描述了两端的User Agents在一段时间内的关联。Dialog用Dialog Id来表示，Dialog Id是由三部分组成的：Call-Id，from中的tag，to中的tag。只有对Invite消息响应的的2xx 和 101-199 消息才能建立一个Dialog。100 Trying相应无法建立Dialog，因为100 Trying中的To属性没有tag值。
· Transaction：一个Transction是有一个Request消息和一个或者多个临时或者最终应答消息构成的。如果对Invite的应答是200 OK，则接下来的ACK消息认为是另一个transaction。
2. SIP网络实体：
· UA(User Agent)：和用户直接交互的SIP设备，可以是硬件的SIP电话也可以是电脑上具有SIP电话功能的软件等；发送SIP Request消息的UA即UAC(User Agent Client), 接受SIP Request消息的UA即UAS(User Agent Server), 一个UA通常既是UAC又是UAS。
· Proxy Server：进行消息转发，负责把消息转发给最终用户或者另一个Proxy Server。
· Redirect Server：和Diameter的Redirect Server类似，不进行消息转发，而是给消息发送方回复一个或者多个地址，建议发送方把消息发往这些地址。Redirect Server返回的地址并不一定就是最终用户的地址，也有可能是另一个Proxy Server的地址。
· Registrars: 因为SIP需要支持用户的移动性，所以当用户改变位置后需要对新位置的终端进行注册，Registrars接受SIP用户注册，从而得知可以从何处找打当前用户。Registrars通常位于SIP Server(Proxy Server 或者Redirect Server)中。
· Location Server：不是SIP实体，之所以说它不是SIP实体是因为Location Server上面不必运行SIP协议栈，SIP Server和 Location Server之间的通信方式也不是用SIP(比如用LDAP)。Location Server的作用是保存SIP用户位置数据(IP 或者Hostname)，比如当一个SIP用户向SIP Server注册之后，SIP Server将该SIP用户位置信息上传到Location Server中，当SIP Server收到需要发送给该SIP用户的消息时，SIP Server再向Location Server询问该用户位置信息(IP 或者Hostname)。
3. SIP消息分类：
SIP消息分为如下两类:
· 请求消息：UAC发给UAS的消息，包括INVITE、ACK、BYE、CANCEL、OPTION和REGISTER消息。
· 响应消息：UAS回应给UAC的消息，包括1xx、2xx、3xx、4xx、5xx、6xx响应消息，每类消息的具体含义如下表：
| 1xx |
进展相应 |
临时相应 |
| 2xx |
成功 |
最终相应 |
| 3xx |
重定向错误 |
最终相应 |
| 4xx |
客户端错误 |
最终相应 |
| 5xx |
服务端错误 |
最终相应 |
| 6xx |
全局错误 |
最终相应 |
4. SIP消息格式：
SIP由于是采用文本格式编码，所以消息格式很简单，是由Message Header加可选的Message body构成，Message Header 从第二行开始每一行都由“Tag :Valued”格式组成，每一行描述一个属性。 头部的属性有很多，基本协议中定义了一部分，扩展协议也定义了相应的头部属性。如果消息中携带了Message body，则Message Header和Message body之间用一个空行分割开来；Message body通常有“Content-Type”和“Content-Length”属性来对Message body进行解释，例如：
Content-Type: application/sdp
Content-Length: 212
SIP消息也可以携带多个Message body，比如可以带上SDP信息和主叫方的照片，这样被叫就能看到主叫方的头像了。
SIP消息在经过Proxy的时候，Proxy只关心Message Header，而不会检查Message body，所以说Message body对Proxy是透明的。
5. SDP(Session Description Protocol)：
在SIP的Message body中最常见的就是SDP，这里概述一下SDP。Session Description Protocol (SDP) 在RFC 2327中被定义；SDP中携带了一些必要信息，以供用户可以加入一个多媒体会话，比如IP地址，端口号，会话的日期时间等；这有点儿类似电视台的节目单，有了节目单，我们就可以在指定的时间切换到指定的频道收看到预期的节目。SDP是单独定义的，和SIP没有必然的联系，SDP信息可以通过各种途径传输比如Email，Webpage等，SIP只是众多传输SDP方式中的一种而已。
1) SDP语法：
SDP也是用文本格式描述的，一个SDP Description可以包含很多行，每一行的格式如下：
Type = Value
Type只用一个字母来表示；一个SDP Description通常有一个Session-level和多个Media-level信息组成；Session-level信息用来描述整个Session，每个Media-level信息用来描述一个特定的媒体流。Session-level总以”v=0”开头，Media-level总已”m=<media type> <port number> <transport protocol> <media formats>”开头,。下面是一个SDP Description的例子，该例子中包含了三个Media-level信息：
v=0
o=Bob 2890844526 2890842807 IN IP4 131.160.1.112
s=SIP seminar
i=A Seminar on the Session Initiation Protocol
u=http://www.cs.columbia.edu/sip
[email protected]
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
该例中o描述该session的发起者是Bob以及他的IP地址；s描述该session的名字；i描述了该session的一般信息；u说明可以从这个URL中获取和该session相关的更多信息；e描述了该session联系人的email。C和t描述了什么时间从哪里可以接收到该Session的multicast。m描述了一个媒体流的端口号，传输协议，媒体格式等信息。a可以用来对SDP进行扩展，比如双方如果协商音频的音量，可以用下面的SDP描述：
m=audio 49170 RTP/AVP 0
a=volume:8
前提是双方都需要理解volume的含义，如果对方不理解volume，也不会出错，只是将其忽略。
2) SDP描述中常见属性：
| v |
Protocol version |
| b |
Bandwidth information |
| o |
Owner of the session and session identifier |
| z |
Time zone adjustments |
| s |
Name of the session |
| k |
Encryption key |
| i |
Information about the session |
| a |
Attribute lines |
| u |
URL containing a description of the session |
| t |
Time when the session is active |
| e |
E-mail address to obtain information about the session |
| r |
Times when the session will be repeated |
| p |
Phone number to obtain information about the session |
| m |
Media line |
| c |
Connection information |
| i |
Information about a media line |
6. SIP呼叫流程实例分析：
下图是一个完整的SIP呼叫消息流示意图，这里重点关注SIP消息流，下一篇文中将给出一个稍微复杂的例子，那个例子中将重点关注SIP消息的路由和SIP常见头部字段的含义。
Laura要与Bob通话，Laura拨打Bob的的Public URI：sip:[email protected]，给Bob一个Invite消息，在Invite消息中携带了SDP，表明Laura期望在UDP端口20002上收到包含PCM voice编码的RTP数据包。Proxy收到这个Invite消息后转发给Bob，同时给Laura回送一个100 Trying消息(Trying消息是Hop-to-Hop的，不会被转发)。Bob收到Invite消息后开始振铃，返回180 Ringing消息给Laura，Laura侧会听到回铃音。
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP workstation1000.university.com:5060
From: Laura Brown <sip:[email protected]>
To: Bob Johnson sip:[email protected]
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: Laura Brown <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 154
v=0
o=Laura 2891234526 2891234526 IN IP4 workstation1000.university.com
s=Let us talk for a while
c=IN IP4 138.85.27.10
t=0 0
m=audio 20002 RTP/AVP 0
当Bob摘机后，一个200 OK的最终应答消息会被返回给Laura，消息中携带了一个SDP，表明Bob可以在UDP端口41000上接受数据包。Laura收到200 OK后给Bob发送一个ACK消息，确认已经收到200 OK。此时双方进入通话。
SIP/2.0 200 OK
Via: SIP/2.0/UDP 131.160.1.110
Via: SIP/2.0/UDP workstation1000.university.com:5060
From: Laura Brown <sip:[email protected]>
To: Bob Johnson <sip:[email protected]>;tag=314159
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: Bob Johnson <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 154
v=0
o=Bob 2891234321 2891234321 IN IP4 131.160.1.112
s=Let us talk for a while
c=IN IP4 131.160.1.112
t=0 0
m=audio 41000 RTP/AVP 0
当通话结束时，Bob发送一个Bye消息给Laura，Laura随后回应200 OK给Bob，至此通话结束。
参考资料：
1. “RFC 3261”- Section 4，Section 12，Section 17，Section 24；
2. “SIP Demystified”- Chapter 4， Chapter 5；