第4讲 基于SIP的IP电话系统
赵志峰1, 2, 3 杨永康2 仇佩亮1
（1. 浙江大学博士后科研流动站 杭州310027）
（2. 东方通信博士后科研工作站 杭州310053）
（3. 解放军理工大学通信工程学院 南京210007）
摘要 文章首先对基于SIP的IP电话系统进行了概括性的介绍，给出了其网络结构和协议栈的结构，并进行简要的分析和解释。在对SIP协议的分层结构、用户标识和消息结构等基本内容进行介绍后，分析了SIP IP电话系统的基本工作过程，对注册/注销过程、呼叫过程、重定向过程和能力查询过程进行了全面的描述。
关键词 SIP IP电话系统 网络结构 协议栈结构 SIP协议 工作过程
1 引言
会话启动协议SIP（Session Initiation Protocol）[1]是由IETF制定的用于对基于IP的多媒体通信系统进行控制的协议。SIP定义了对多媒体会话进行控制的信令过程，包括会话的建立、拆除和修改等，可以用来构建IP电话系统。目前已成为IP多媒体通信系统最有发展潜力的会话控制协议。3GPP已决定使用SIP来作为第三代移动通信系统多媒体域的控制协议。微软也在其新版本的MSN中集成了对SIP协议的支持，逐渐抛弃了使用H.323协议[2]的Netmeeting系统。
SIP协议最初是由IETF的MMUSIC工作组制定的，其第一版本RFC 2543[3]于1999年3月推出，可以支持IP网上的多媒体通信。与H.323协议相比，SIP具有简单、开放、扩展性好等特点，一出现就得到了业界的普遍关注和支持。为此，IETF专门成立了SIP工作组，对SIP协议进行研究和改进，并于2002年推出了SIP的第二版RFC 3261[1]。目前，SIP工作组在对SIP协议进行进一步的改进和完善，并对其应用进行研究。
2 系统的结构
2.1 网络结构
可以看出，系统采用了因特网的客户机/服务器结构，由用户代理和服务器两大部分组成。其中用户代理又分为用户代理客户（UAC: User Agent Client）和用户代理服务器（UAS:User Agent Server）两种。服务器分为代理服务器（Proxy Server）、重定向服务器（Redirected Server）和注册服务器（Registrar）。图中的定位服务器为SIP系统提供位置服务，不属于SIP协议的范畴。
在SIP中，终端用户被称为用户代理，主叫方称用户代理客户UAC，被叫方称用户代理服务器UAS。UAC负责发起SIP呼叫请求，UAS接收UAC的请求并负责对其做出响应（接受、拒绝或重定向）。终端用户应同时具备UAC和UAS的功能。
代理服务器是SIP IP电话系统中最重要的网络功能实体，主要提供路由功能。它负责将用户的SIP请求和响应转发到下一跳，最终到达目的地。
注册服务器是完成用户代理注册/注销功能的逻辑实体。它接收其管辖范围内的用户代理的注册请求，将用户代理的地址信息添加到定位服务器中。
重定向服务器是实现呼叫重定向功能的逻辑实体。它接收用户代理客户UAC的呼叫请求，通过服务器中配置的策略和对定位服务器的查询指示UAC将呼叫重定向到其它的目的地，以实现对呼叫的灵活控制。
定位服务器是SIP协议范畴之外的功能实体。它保存着用户的逻辑地址与当前联系地址间的绑定信息，支持对地址绑定信息的查询、添加、修改和删除，为注册服务器、代理服务器和重定向服务器提供服务。
当UAC要发起呼叫时，它一般将呼叫请求消息发送给本域的出向代理服务器。媒体描述信息以SDP（Session Description Protocol）[4]的形式在SIP消息中传送。代理服务器检查被叫地址，将请求转发（可能经过多个中间代理服务器的转发），直至到达被叫域的代理服务器。被叫域的代理服务器通过查询定位服务器确定被叫的确切位置，然后将请求转发给UAS。UAS收到请求后，生成响应消息。响应将按照请求消息经过的路径，原路返回到UAC。UAC根据响应消息的内容选择是建立呼叫、重新发起呼叫或取消该呼叫。
2.2 协议栈结构
SIP协议本身只定义了对多媒体呼叫进行控制的信令过程，它充分利用了因特网已有的协议来构建基于IP的多媒体通信系统。
在SIP多媒体通信系统中，音视频媒体信息可以使用现有的G.7xx和H.26x系列标准来进行压缩。媒体信息使用RTP/RTCP通过UDP来进行传送。呼叫的媒体类型和格式信息通过SDP协议来描述。SDP信息放在SIP消息的请求和响应消息体中传送。最终通信时使用的媒体类型和格式由双方协商决定。RTSP（Real Time Streaming Protocol）[5]协议用于控制对存储在库中的多媒体信息的实时操作，包括播放、暂停、快进、快退、停止等。比如IP电话系统中对语音信箱的控制。
3 SIP协议基础
3.1 协议的分层结构
为了方便协议的描述和理解，SIP将其协议定义自下而上划分为如图3所示的四层：语法和编码层（Syntax and Encoding）、传输层（Transport Layer）、事务层（Transaction Layer）和事务用户层（Transaction User）。
语法和编码层定义了SIP协议使用的各种参数、消息的结构、语法和格式。编码采用扩充的巴柯斯范式（BNF：Backus Normal Form）来描述。
传输层定义了客户端如何发送请求和接收响应，也定义了服务器端如何接收请求和发送响应。传输层负责对端到端的连接进行管理。所有的SIP功能单元都必须包含传输层，必须支持TCP和UDP作为传输协议，可选性地支持SCTP和TLS+TCP/SCTP作为传输协议。
事务层负责保存事务的状态，处理应用层的重传和超时，以实现消息的可靠传输。事务层还要负责匹配一个请求消息的所有响应消息。无状态的代理服务器不含该层。而用户代理、有状态的代理服务器和注册服务器都包含有事务层。在图3中，无状态的代理服务器直接使用传输层提供的服务进行消息转发。
最上层是事务用户层，除无状态的代理服务器外的所有实体都是事务用户。这些事务用户利用事务层提供的服务来实现各自的功能。比如当事务用户想要发送一个请求消息时，它创建一个客户事务，然后把请求消息、目的IP地址、端口号交给该事务，该客户事务负责把消息可靠地发送到目的地。
3.2 用户标识
在SIP IP电话系统中，使用SIP URI（Uniform Resource Identifier）地址来标识用户。SIP URI的一般结构为：
sip: user: password@host: port; uri-parameters ? headers
User：用户名，指在本主机或本域中的特定用户或其它通信资源。
Password：口令，指在本主机或本域中该用户名对应的口令。
Host：指本URI的主机名或域名。
Port：主机发送消息使用的TCP/UDP端口号。
uri-parameters：该URI的参数，格式是“参数名=参数值”，多个参数之间用分号分割。URI参数包括用于指明传输机制（TCP、UDP等）的“transport”；还有指明联系地址的“maddr”；区分用户名和电话号码的“user”；表示请求方法的“method”；指明路由方式的“lr”等。
headers：指使用该URI构建请求消息时应带有的头部字段。
下面是SIP URI的示例：
SIP: John @ eastcom.com
SIP: John:abced @ companu.com;transport=tcp ? subject=project
SIP: +86-571-86698522@gateway.com;
user=phone
SIP: alice @ 10.0.18.3; lr
SIP: aice @ registrar.com; method=REGISTER
3.3 消息结构
SIP消息是基于纯文本方式的。消息包含四部分：起始行、消息头、空行和消息体。其中起始行分为请求行和状态行，分别对应于SIP的请求消息和响应消息。消息头由多个头部参数构成，每个头部参数一行。消息后的空行（CRLF）表示消息头的结束，其后面是包含真正消息内容的消息体（message body）。
SIP的请求消息以请求行开始。请求行包括请求方法（method）、请求地址（Request-URI）和SIP版本号。图中的SP表示空格，而CRLF表示回车换行。目前SIP定义的请求方法有六种：REGISTER、INVITE、ACK、CANCEL、BYE和OPTION。其中REGISTER用于注册和注销地址绑定信息；INVITE用于发起呼叫；ACK用于确认建立呼叫；CANCEL用于取消呼叫；BYE用于终止对话；OPTIONS用于能力查询。请求地址是一个SIP URI（也可能是其它URI，比如tel），标识了请求的目标地址。在RFC 3261中，要求SIP的版本号必须设置为“SIP/2.0”。
SIP的响应消息以状态行开始。状态行包括SIP版本（SIP Version）、状态码（Status-Code）、原因描述（Reason-Phrase）组成。SIP版本与请求消息中的相同。原因描述指对响应状态的文字描述，以方便人们阅读。状态码由三位数字组成，表示响应的结果。目前，RFC 3261中定义的状态码从1xx ~ 6xx，1xx是临时响应（又叫中间响应），而其它的是最终响应。
· 1xx指请求已经收到正在处理中；
· 2xx是成功响应，指请求已被成功处理；
· 3xx是重定向响应，指示呼叫重新向指定的实体发起；
· 4xx是客户出错响应，指请求消息语法有误或此服务器无法处理；
· 5xx是服务器出错响应，指服务器无法处理一个合法的请求消息；
· 6xx是全局出错响应，指请求无法被任何服务器处理。
上述的临时响应指当接收方已经收到请求，但要花一段时间处理，为了防止请求方定时器超时，就用此消息通知请求方。对请求的处理结果仍以最终响应的方式返回给请求方。
SIP的头部域在语法和语义上都与HTTP的头部非常相似，其格式如下：
header =“header-name” ：header-value *（，header-value）
SIP的头部域由头部名字和头部值组成，两者以冒号“：”分割。允许一个头部有多个头部值，多个值之间以逗号“，”分割。SIP在RFC 3261中共定义了44种消息头部。比较重要的头部域有：呼叫标识域Call_ID，联系地址域Contact，请求者域From，接收者域To，路由头部域Route，路由记录头部域Record-Route，经过实体记录域Via，消息体类型域Content-Type，消息体长度域Content-Length等。
下面给出了一个请求消息和一个响应消息的示例。两个消息表示的是alice@atlanta.com向bob@biloxi.com发送的INVITE请求消息，和对方返回的成功响应。从两个消息可以看出To和From头部存放的是用户的逻辑地址，而Contact头部存放的是用户的联系地址。
4 基本工作过程
SIP IP电话系统定义了注册/注销、呼叫、重定向、能力查询四种工作过程。
4.1 注册/注销过程
SIP为用户定义了注册和注销过程，其目的是可以动态建立用户的逻辑地址和其当前联系地址之间的对应关系，以方实现呼叫路由和对用户移动性的支持。逻辑地址和联系地址的分离也方便了用户，它不论在何处、使用何种设备，都可以通过唯一的逻辑地址进行通信。
注册/注销过程是通过REGISTER消息和200成功响应来实现的。在注册/注销时，用户将其逻辑地址和当前联系地址通过REGISTER消息发送给其注册服务器，注册服务器对该请求消息进行处理，并以200成功响应消息通知用户注册/注销成功。
4.2 呼叫过程
SIP IP电话系统中的呼叫是通过INVITE邀请请求、成功响应和ACK确认请求的三次握手来实现的。即当主叫用户代理要发起呼叫时，它构造一个INVITE消息，并发送给被叫。被叫收到邀请后决定接受该呼叫，就回送一个成功响应（状态码为200）。主叫方收到成功响应后，向对方发送ACK请求。被叫收到ACK请求后，呼叫成功建立。
呼叫的终止通过BYE请求消息来实现。当参与呼叫的任一方要终止呼叫时，它就构造一个BYE请求消息，并发送给对方。对方收到BYE请求后，释放与此呼叫相关的资源，回送一个成功响应，表示呼叫已经终止。
当主被叫双方已建立呼叫，如果任一方想要修改当前的通信参数（通信类型、编码等），可以通过发送一个对话内的INVITE请求消息（称为re-INVITE）来实现。
4.3 重定向过程
当重定向服务器（其功能可包含在代理服务器和用户终端中）收到主叫用户代理的INVITE邀请消息，它通过查找定位服务器发现该呼叫应该被重新定向（重定向的原因有多种，如用户位置改变、实现负荷分担等等），就构造一个重定向响应消息（状态码为3xx），将新的目标地址回送给主叫用户代理。主叫用户代理收到重定向响应消息后，将逐一向新的目标地址发送INVITE邀请，直至收到成功响应并建立呼叫。如果尝试了所有的新目标而无法建立呼叫，则本次呼叫失败。
4.4 能力查询过程
SIP IP电话系统还提供了一种让用户在不打扰对方用户的情况下查询对方通信能力的手段。可查询的内容包括：对方支持的请求方法（methods）、支持的内容类型、支持的扩展项、支持的编码等等。
能力查询通过OPTION请求消息来实现。当用户代理想要查询对方的能力时，它构造一个OPTION请求消息，发送给对方。对方收到该请求消息后，将自己支持的能力通过响应消息回送给查询者。如果此时自己可以接收呼叫，就发送成功响应（状态码为200），如果此时自己忙，就发送自身忙响应（状态码为486）。因此，能力查询过程也可以用于查询对方的忙闲状态，看是否能够接受呼叫。
5 结束语
SIP协议是由IETF的SIP工作组制定的IP多媒体通信系统控制协议，它具有简单、开放、扩展性好等特点，可以被用于构建IP电话系统。SIP IP电话系统充分利用了因特网的已有协议，使用RTP/RTCP来传输媒体信息，使用DNS来进行地址翻译，使用SDP来对会话进行描述。在这些协议的支持下，SIP IP电话系统可以完成注册、注销、呼叫、重定向和能力查询等工作过程。以实现对基本呼叫路由和用户移动性的支持。
参 考 文 献
[1] IETF. RFC 3261: Session Initiation Protocol. June 2002
[2] ITU-T Recommendation H.323 (Version 4), Packet-Based Multimedia Communications Systems, November, 2000
[3] IETF. RFC 2543: Session Initiation Protocol. March 1999
[4] IETF RFC 2327: Session Description Protocol, April 1998
[5] IETF RFC 2326: Real Time Streaming Protocol, April 1998
[6] IETF RFC 2960: Stream Control Transmission Protocol, October 2000
[7] IETF RFC 2246: Transport Layer Security, January 1999.
----《中国数据通信》
|
