SIP背景原則

本章并不提供完整的会话初始化协议(SIP)规范，而是旨在指出sip在应用于IP多媒体子系统(IMS)中时需重点关注的方面。例如，本章并不讨论SIP实体在URI(统一资源标识符）中应如何使用maddr参数，也不解释SIP实体在某个错误发生时所采取的动作。SIP的完整规范请参见［RFC3261］。

12.1背景

sip是一种在ip网络中建立、修改和终止多媒体会话的应用层协议，它是因分特网工程任务组(IETF）在不断进行标准化的多媒体协议体系的一部分。其应用协包括但不限于语音、视频、游戏、消息、呼叫控制和在线状态(presence)等。

IP上的会话信令协议思想可以追溯到组播会议概念刚出现的1992年。SIP本议身起源于1996年后期，当时是作为lETFMbone(组播骨干网)的一个组成部分，该网络是架设于公众因特网之上的一个组播实验网。其中SIP被IETF用来发布多媒体内容，包括IETF会议，专题讨论会和大型会议等。由于其简单性和可扩展性，SIP后来被采纳为IP电话(V6IP)的信令协议，并于1999年最终成为IETF标准［RFC2543］。之后SIP在互操作性、设计的优化和新特性等方面得到了进一步增强。为清晰起见，原文档进行了重写，由此形成的新协议基本上与［RFC2543］保持后向兼容。新文档于2002年取代了［RFC2543］,成为新标准［RFC3261］。

12.2设计原则

作为IETF工作进程中的一部分，SIP基于超文本传输协议(HTTP)和简单邮件传送协议(SMTP)。图12-1给出了SIP在协议栈中的位置。

SIP的设计旨在实现以下目标：

•独立于传输协议——可以在可靠(TCP、SCTP）和不可靠(UDP）的协议上运行。

•请求的路由——直接路由(为了性能）或代理路由(为了控制）。

•信令和媒体描述相分离——以便可以增加新的应用或媒体。

•可扩展性。

•个人的移动性。

图12-1 协议栈

12.3 SIP体系结构

SIP中的组成元素可分为用户代理(UA)和中间服务器。在理想情况下，两个端点(或UA)间的通信并不需要中间服务器的参与即可完成。但现实并非总是如此，因为网络管理者和业务提供者可能希望对其网络内的业务流有所了解。

图12-2描述了一种典型的网络结构，称为“SIP梯形(trapezoid）”。

SIPUA或终端构成对话的端点：它发送或接收SIP请求和响应，是多媒体流的终点。此外它通常是用户设备(UE),即终端上的一个应用或一个专用的硬件设备。UA由以下两部分组成：

• 用户代理客户端(UAC)——发起请求的主叫方应用。

• 用户代理服务器(UAS)——接受、重定向或拒绝请求，并代表用户给到来的请求发送响应。

图12-2  sip梯形

网关是UA的特例

SIP中间服务器是SIP消息在到达其最终目的地前所经过的逻辑实体，这些中间服务器用于对请求进行路由和重定向。这些服务器包括：

• 代理服务器(ProxyServer)接收和转发SIP请求。可解释或重写SIP消息的某些部分，包括消息正文。这些重写不会打乱端点处的请求或对话的状态。代理服务器也可同时向多处发送请求。这样的实体被标识为“分叉代理”。分叉可以是并行的或是串行的。一共有三种代理服务器类型：

■对话状态感知代理(Dialog-statefiill proxy)如果一个代理从起始请求(INVITE request)到终止请求(BYE request)期间保持各个对话的状态，则为对话状态感知代理。

■事务状态感知代理(Transaction-statefUll proxy)在处理请求的

过程中对客户端和服务器的事务状态机进行维护的代理。

■无状态代理(Stateless proxy)将收到的每个请求向下游转发和将收到的每个响应向上游转发的代理。

• 重定向服务器(RedirectServer)将请求地址映射为新地址。它对请求进行重定向，但并不参与事务的处理。

• 位置服务器(LocationServer)--跟踪用户的位置。

• 登记员服务器(RegistrarServer)--接受REGISTER请求的服务器。

这类服务器用于存储用户登记的地址(SIP地址)与用户当前所在的或用户希望用于接收请求的主机地址之间的明确绑定关系。

此外还有两个给SIP用户提供服务的元素:

• 应用服务器(ApplicationServer)—AS是在网络中为终端用户提供服务的实体，典型例子如在线状态(presence)和会议服务器。

• 背靠背用户代理(back-to-back-user-agent)正如其名字所述，一个B2BUA中的UAS和UAC粘合在一起。UAS和正常的UAS一样终止请求；而UAC发起一个新请求，该请求与UAS端收到的请求具有一定的相关性，但不是任何协议指定的链路。该实体基本上类似于一个代理(Proxy),但打破了代理(Proxy)修改请求时所遵守的所有准则。

12.4 消息格式

如图12-3所示，SIP消息由三部分组成，即：开始行(startline),消息头(header)和正文(body)。

开始行的内容根据SIP消息是请求还是响应而有所不同。若是请求，贝U称为“请求行”；若是响应，则称为“状态行”。

图12-3  SIP消息格式

SIP请求的例子如下所示：

INVITE sip:bob.smith@nokia.comSIP/2.0

Via:SIP/2.0/UDPcscfl.example.com:5060;branch=z9hG4bK8542.1

Via:SIP/2.0/UDP[5555::1:2:3:4]:5060;branch=z9hG4bK45a35h76

Max-Forwards:69

From:Alice<sip:alice@nokia.com>;tag=312345

To:Bob Smith<sip:bob.smith@nokia.com>

Call-ID:105637921

CSeq:1 INVITE Contact:sip:alice@[5555::1:2:3:4]

Content-Type:application/sdp

Content-Length:159

[body]

12.4.1请求

通过开始行可以识别一个SIP消息是请求还是响应。如前所述，请求中的开始行通常被称为请求行，由三个部分组成：方法名、请求URI和协议版本。它们以上述顺序出现并由单个空格符分开。请求行本身以一对回车换行符(CRLF）结束。

• 方法——方法表示请求的类型。在基本SIP协议［RFC3261］中定义了六个方法：INVITE请求、CANCEL请求、ACK请求和BYE请求用于会话的创建、修改和终止；REGISTER请求用于对用户的联系信息进行注册；OPTIONS请求用于对服务器及其能力进行查询。其他方法都是作为对［RFC3261］的扩展。

• 请求URI——请求URI用来标识所请求的资源的SIP或SIP SURI。

• 协议版本——目前的SIP版本为2.0o所有符合［RFC3261］的请求都必需包含这个版本信息，形式为“SIP/2.0”。

12.4.2 响应

SIP响应可以通过查询开始行来与SIP请求区分。如前所述，响应中的开始行4经常被称为状态行，由三个部分组成：协议版本、状态码和原因短语。它们以该顺序出现并由单个空格符分开。状态行本身以一对CRLF符号结束。

•版本——与请求行中的协议版本相同。

•状态码——状态码是由三个阿拉伯数字组成的码，用来标识响应种类，指示请求的结果。

•原因短语——这是一个自由的文本域，给状态码提供简短的描述，主要以针对个人用户。

状态码可以分为六类(从2xx到6xx类是最终响应）：

•Ixx——临时的/信息性响应。表明请求已收到，接收方正在继续处理该请求。

•2xx成功响应。请求已成功收到、理解并被接受。

•3xx重定向响应。请求方需要采取进一步动作以完成请求。

•4xx—客户端错误响应。该请求包含语法错误，也可指示服务器不能实现请求所提的要求。

•5xx一服务器错误响应。服务器在对有效请求进行处理时失败，是服务器的错误。

•6xx——全局失败响应。请求不能在任何一个服务器上得到满足，产生该响应的服务器需要知道有关用户的确切信息。

“xx"是表明响应确切种类的两位数字。例如，一个“180”的临时响应表明对端的振铃，而一个“181”临时响应则表明呼叫正在被中转。

12.4.3消息头字段

消息头字段包含与请求有关的信息，例如请求的发起者、请求的接收者和呼叫标识。消息头字段也可指示消息正文的特征。

每个消息头字段以一对CRLF结束。一个SIP消息的整个消息头部分也以CRLF结束。

消息头字段的格式如下：

Header-name:header-value

有些消息头是每个SIP请求和响应都必须具有的，这些消息头及其格式列举如下：

 •To  消息头                          To:SIP-URI(:参数）

 • From  消息头                     From:SIP-URI(；参数）

 • Call-ID消息头                    Call-ID:惟一的id

 • CSeq消息头                       CSeq:数字方法

 • Via消息头                          Via:SIP/2.0/［传输协议］发送者地址(；参数）

 • Max-Forwards消息头        Max-Forwards:数字

 • Contact  消息头                 Contact:SIP-URI(；参数）

Contact头对于创建对话的请求来说是必须的，Max-Forwards头的典型值为70o注意，参数两侧的括号表示参数是可选的，括号不是消息头语法的一部分。凡是(；参数）出现时即表明消息头里可以出现多个参数，参数之间用分号隔开。Via头的传输协议可以是用户数据报协议(UDP)、传输控制协议(TCP)或传输层安全(TLS)协议。

12.4.4消息正文

消息正文(有效负荷）可携带任何基于文本的信息，而请求的方法和响应的状态码决定了消息正文该如何解释。

当描述一个会话时，典型的SIP消息正文是一个会话描述协议(SDP）消息。

12.5  SIP  URI

sip uri遵从与电子邮件地址相同的格式，即"用户名@域名"。有如下两种URI模式：

• sip:bob.smith@nokia.com是一个SIP URI,这是最通用的格式，在［RFC2543］中有介绍。

• sips:bob.smith@nokia.com是一个SIPS URI,这种新模式在［RFC3261］中有介绍，要求使用TCP上的TLS来进行安全的传输。

存在两种SIP和SIPSURI：

• 记录地址（AOR）——这个SIP地址用于标识一个用户。该地址几乎可以同电话号码一样的方式发布给公众，例如sip:bob.smith@nokia.com（需要DNS SRV记录来定位nokia.com域的SIP服务器）。

• 主机的全合格域名（FQDN）或IP地址（标识一个设备）——例如：sip:bob.smith@127.233.4.12或sip:bob.smith@pc2.nmp.nokia.com（不需要路由解析）。

SIP URI的格式为:"sip:用户信息@主机端口［参数］［消息头］”，SIPSURI遵从与SIPURI完全相同的语法。

• 用户信息——用户名或电话号码。

• 主机端口——域名或数字形式的网络地址和端口。

• 参数——定义具体的URI参数，例如传输（transport）协议、生存时间等。

• 消息头——一个很少用到的格式，用来传递额外信息。

下面是一些SIPURI的例子。

• sip:bob.smith@nokia.com

• sip:bob@nokia.com;transport=tcp

• sip:+1-212-555-1234@gw.com;user=phone

• sip:root@136.16.20.100:8001

• sip:bob.smith@registrar.com;method=REGISTER