Resiprocate介绍
1.前言
本文主要内容来自互联网，特此感谢Steven的辛苦撰写和resiprocate开源组织的
无私奉献以及sip协议的创造者Schulzrinne教授和Rosenberg大师的辛勤工作。
2．从SIP谈起 说明:
不期待一次就把RFC3261或者其他的协议文档内容及其细节全部记住或者完全理解;把原理性的东西及其脉络厘清也许更重要;在调试程序和看协议栈源码的过程中我的做法是一直把RFC3261(经常的是那份中文文档?的文档打开;遇到忘记或者不是太明白的概念和内容就在文档中再搜索相关主题及内容来看看;经常会碰到这样的问题,我发个内容给SIP Proxy或者SIP Server,可是并没得到我希望的回复或者与期待的回复内容有出入,这时,我的经常做法是再去研读协议的相关定义,看看是不是我哪个细节并没理解深入或者引起注意,导致我发出去的内容与协议标准有出入或者我的流程与协议定义不吻合。
接下来的内容是前人的文档整理,只是个大概,如果没兴趣,完全可以跳过不看;协议栈部分基本上是分成DUM与Stack两部份可以先后看，也可以先看Stack部分。
补充说明：文档中的大部分图片都来自网上公开的资料，只有少数几幅是自绘，因此出现内容不清和误导，概不负责? 特此感谢借鉴资料和图片的原创者们，虽然他们并不知道又误导了一个菜鸟。
2.1 SIP (Session Initiation Protocol) 简介
最先由美国哥伦比亚大学的Henning Schulzrinne 教授在1998 年初开始发起，1999 年3 月由IETF 的MMUSIC(Multipart MultimediaSession Control)工作小组制定正式标准成为RFC 2543， 1999 年9月IETF 成立新的工作小组 ,负责SIP新版本2.0 的制定 , 并于2000年7 月释出初版RFC 2543bis，于2001 年发布了RFC 3261 。RFC 3261 的发布，标示着SIP 的基础已经确立，随后又发布了几个RFC 增定版本，充实了安全性及身份认证等几个领域的内容，例如RFC 3262对临时响应做了可靠性的规范。RFC 3263确立了SIP proxy的定位规则。RFC 3264提供了Offer/Answer Model，RFC3265则是确立了具体的事件通知。如同Internet 一样，SIP 易于理解、扩充、及实做，作为IETF 的规范，SIP 将Internet 开放标准的精神延伸至通讯领域，实现了不同计算机、电话、及软件的通讯。SIP 的讯息类似于HTTP (RFC 2068)，其寻址方式，则是重用了SMTP 的寻址方式，SIP address (如： sip:inaba@ssl.es.ncku.edu.tw)与E-mail address 的结构相同，SIP 甚至利用Web 的体系结构，如DNS，而使得SIP 的使用者之间的通讯，
1
有更高的扩充性。 ? ? ?
SIP有下列几点特性
利用文字(Text-based)的方式来编码，类似HTTP/1.1 Client-Server的架构 ? ? ?
Clients 端初始一个呼叫(caller) Servers 端响应呼叫 (callee)
Signal与media独立，SIP负责signal部分，media传送部分可以使用RTP等，可与其它IETF 所制订的协议配合，例如：RFC2327(SDP), RFC2616(HTTP/1.1) ,RFC2396(URL)?
2.2 SIP命名方式
SIP 的地址称做SIP URLs，其格式为 user@host:port ，使用者利用REGISTER的SIP request来结合自己的SIP URLs user 代表使用者名称或是电话号码 host 代表 domain name 或是数字型态的IP address举例来说 sip:inaba@pku.edu.cn 或是sip:25643588@140.92.61.55
2.3 SIP 组件介绍
在SIP 是一个Client and Server的架构，在此环境当中，有三个主要的组件分别为: User Agents, Servers 还有Location Servers。
? User Agents
在SIP 环境中是终端设备，主要负责产生SIP requests，用来建立多媒体会议(media session)，并且传送及接收多媒体资料。UserAgents 又分成了User Agent Client (UAC) 及 User Agent Server 两种模式。UAC 负责产生一个Request 及处理一个Response，UAS 怎是接受一个Request 并且产生response。在Session建立过程中，UA通常需要接替着扮演这两个角色。这点并不像其它Client and Server 架构，例如HTTP，PC 一直扮演着HTTP client 的角色，而Web Server也一直扮演着HTTP Server 的角色。
? Servers
根据RFC 3261 中定义，Server主要分成了Proxy, Redirect, 以及Registrar server。
? SIP proxy：负责接受UA 或其它proxy 所发送的 SIPRequest，并且转
2
送Request 到其它地方。
? Redirect Server：负责接受UA或其它proxy所发送的 SIPRequest，并且传
回redirection response (3xx)，指出这个Request应该送往何方。 ? Registrar Server：负责接受SIP registration requests，并且更新SIP UA
在Location Server 或其它数据库当中的信息。
SIP proxy, Redirect 还有Registrar servers 只有做单纯的signal转送，
他们没有传送media及产生SIP Request 的能力。
Proxy, Redirect,以及Registrar server只是逻辑概念定义的不同而物理实
现上完全可以在同一物理位置实现。
? Location Servers：在RFC 3261 中，通常当作一个数据库来使用。数据库当
中可以存放使用者的信息，例如URLs, IP address, 或是其它资料等等。SIPUA 不能直接来存取Location server，而是透过proxy, redirect,或是registrar server。
2.4 SIP message
SIP message 的语意及表头与HTTP/1.1(RFC 2616)相同。可以分成两类，一类是Request ，另外一类是Response。在RFC 3261 当中，定义了六个基本的SIP request 种类，如表2.1所示。
方法 INVITE ACK BYE CANCEL REGISTER OPTIONS 说明 建立会话Session 对INVITE 做最后的确认 结束一个已经存在的会话 取消尚未建立联机的会话 注册使用者的URL 查询Server 及其功能 表2.1、SIP methods
Response 用status-codes 来表示响应的内容，符合且扩展了HTTP/1.1 response code。分成Provisional(暂时)及Final(最终)两类，Provisional 为1xx系列，Final 则包括了2xx，3xx，4xx，5xx，6xx等系列，表2.2 表示各个不同类别的Response。
方法 1xx 2xx 说明 Informational Successful 3
3xx 4xx 5xx 6xx Redirection Client-Error Server-Error Global-Failure 表2.2、SIP Response
1xx Informational responses 指的是server 或是proxy正在执行一些未来的动作，并还没有一个定义好的response。2xx代表这个request是成功的，并且必须结束一个搜寻的动作。3xx Redirection 会回复欲通讯的使用者目前的位置信息。4xx response 是Server 对于UAC 所提出的request 回复一个失败的response。5xx response 是代表Server本身发生了错误。Global Failures 6xx指的是server 有一个关于特定的使用者最终的信息，不仅仅是这个特定的Request-URI，所有未来的对这个使用者的搜寻都应该被终止。表2.3 为几个常用的Response code 范例
Response code 100 200 302 403 503 600 表2.3、SIP Response code
Reason Phrase Trying OK Moved temporarily Forbidden Service Unavailable Busy 2.5 SDP
SIP message body当中，可以携带任何的资料，但通常是给通讯双方用来协商session 相关的信息。SIP 本身并没有提供多媒体协商的能力，多媒体协商必须仰赖 Session Description Protocol (SDP)，SDP 本身并不是一个通讯协议，它的描述语言是基于文字的。SIP 利用answer/offer 的模式来使用SDP。呼叫者送出一个INVITE 讯息并携带着SDP，其中SDP 包含了呼叫者想使用的多媒体的格式、地址、Port，被呼叫方在响应的时候，便可以针对呼叫者所提出的SDP，做出接受或拒绝的响应，这种双方协商的结果，就可以得知多媒体资料格式及通讯的地址为何。SDP 定义在RFC 2327当中，后来经过修订及汇集draft 之后，发表了RFC 3264 “An Offer/Answer Model with SDP”，RFC 3264 明确的描述应该如何将SIP 与SDP 一起使用。SDP 简单地提供一个描述session 信息的格式。基本而言，一个session 是由数个media stream所组成，因此，要描述一个session必须要有数个相关的参数。SDP 当中有session-level与media-level 的参数， ?
session-level的参数包含了
4
? session的名称、 ? session的发起者、 ? session的期限等等。 ?
Media-level 的信息包含了
? media 的种类， ? port number、
? 传输协议以及media 的格式。
图2.1 为SDP 的结构。
Session Description Session Level Protocol Version Originator and Session ID Session Name Session Time Media Name and Transport Connection Information Media Description
图 2.1 SDP session Description Structure
5
