SIP协议与多媒体会议系统

1.1概述

SIP （Session Initiation Protocol，起始会话协议）是IETF 提出的在IP 网络上进行多媒体通信的应用层控制协议，SIP是一个客户/服务器协议，可用于建立，修改，终结多媒体会话和呼叫。SIP 协议采用基于文本格式的客户-服务器方式，以文本的形式表示消息的语法、语义和编码，客户机发起请求，服务器进行响应。可以承载IP地址、端口信息、媒体能力和编码方式等会话相关的信息。SIP独立于低层协议—TCP 或UDP ，而采用自己的应用层可靠性机制来保证消息的可靠传送。SIP 协议的详细内容可参见IETF RFC2543（1999）。

SIP的特点是简单、便于扩展和扩充，而且重要的是SIP概念与Internet的出发点一致，SIP借鉴了许多已有的Internet协议，因而是实现新的增值综合业务的理想手段。SIP协议可以很好地配合Web和Email工作，其原因是：1）SIP消息数据及格式与Web消息数据是同样类型的数据。2）SIP采用URL地址格式来进行消息路由和定位用户，URL可以嵌入Web网页，可以利用任何其它类型的URI，如Web等。3）采用DNS选路技术进行路由选择。

由于SIP协议具有上述特点，因此它能够很容易地开发与Web结合的综合应用，可以降低开发成本并缩短开发周期。

由于IP网络的发展，SIP将变得愈来愈重要，将来人们可以用SIP来构筑一个基本的框架，在这个框架上用简单且单一的 "INVITE-ACCEPT" 消息结构方式来为PC终端、移动终端和固定网终端用户提供语音、多媒体、电子商务的综合业务。

目前对SIP协议的更新是RFC2543bis，与原有版本兼容。同样，IETF SIP工作组也制定了一个文档，提出了一个方法可以将ISUP信令消息封装在SIP的消息体内，该方法参照了SIP for Telephony(SIP-T)草案。

目前已有众多的包括3COM、Lucent、Level(3) Communication、ERICSSON 在内的设备供应商和运营商宣布支持SIP。 Microsoft曾经发布过基于H.323的NetMeeting 客户机，而最近又宣布将在Windows XP 客户机和服务器平台上增加SIP功能，这将引起SIP客户机数量的迅速增加。

目前相关设备供应商和业务供应商联合成立了一个关于SIP的论坛：www.sipforum.org，为SIP的发展提供一个自由讨论、展现新思维的发展平台。

1.2 SIP消息总体描述

SIP 消息由一个起始行（start-line）、 一个或多个字段（field） 组成的消息头、一个标志消息头结束的空行（CRLF） 以及作为可选项的消息体（message body ）组成，其中描述消息体（message body），的头称为实体头entity header。

SIP定义的SIP消息的一般格式为：

SIP一般消息=起始行

                    *消息头部（一个或者多个头部）

                    CRLF（空行）

                    [消息体]

SIP的消息机制采用了Client/Server请求和响应的应答机制，消息有两种：客户机到服务器的请求（Request），服务器到客户机的响应（Response）。

在上述SIP一般消息的格式中，启始行分请求行（Request-Line）和状态行（Status-Line） 两种，其中请求行是请求消息的启始行，状态行是响应消息的启始行。在请求行中给出SIP版本、调用的请求操作（方法）、被邀用户的当前地址。在响应行中给出SIP版本、状态码和相关的文字说明。消息头部分为4类：通用头部（general-header）、请求头部（request-header）、 响应头部（response-header）和实体头部（entity-header ）四种。SIP2.0版本共定义了36种头部消字段。空行表示消息头部字段的结束。消息体主要是SDP会话描述，在响应消息中还可能是原因和进展指示文本。上面描述中的符号“*”表示该字段可有多个。

SIP消息的语法基本上和HTTP相同，头部字段也和HTTP基本相同。但是它可以在UDP上传送。包括头部字段在内的UDP数据包长度不应该超过路径的最大允许传输单元（MTU），如果MTU未知，则最大长度可取为1500字节（以太网MTU典型值）。

下面进一步说明SIP请求消息格式和响应消息格式。

1.3 SIP请求消息格式描述

请求消息的格式如下：

SIP请求消息=请求起始行

                    *（通用头部

                       | 请求头部

                       | 实体头部）

                    CRLF（空行）

                    [消息体]

请求起始行（Request-Line）以方法（method）标记开始，后面是Request-URI 和协议版本（SIP-Version），最后以回车键结束，各个元素间用空格键字符间隔。

Request-Line = Method SP Request-URI SP SIP-Version CRLF

其中SP符号代表空格。

方法就是请求执行的操作，SIP 用术语“method”来对方法部分作以描述，Method 标识是区分大小写的。SIP 定义了以下几种方法。邀请（INVITE）、证实(ACK)、选择（OPTIONS）、再见（BYE）、取消（CANCEL）、登记（REGISTER）、信息（INFO），所有方法必须大写。请求-URI（Request-URI）是被邀请用户的当前地址。SIP版本号现设定为SIP/2.0。

方法描述：

（1）INVITE

INVITE 方法用于邀请用户或服务参加一个会话。在INVITE 请求的消息体中可对被叫方被邀请参加的会话作以描述，如主叫方能接收的媒体类型、发出的媒体类型及其一些参数；对INVITE 请求的成功响应必须在响应的消息体中说明被叫方愿意接收哪种媒体，或者说明被叫方发出的媒体。

服务器可以自动地用200(OK)响应响应会议邀请。

（2）ACK

ACK 请求用于客户机向服务器证实它已经收到了对INVITE 请求的最终响应。ACK 只和INVITE 请求一起使用。对2xx 最终响应的证实由客户机用户代理发出，对其它最终响应的证实由收到响应的第一个代理或第一个客户机用户代理发出。ACK 请求的To、From、Call-ID，CSeq字段的值由对应的INVITE 请求的相应字段的值复制而来。

（3）OPTIONS

用于向服务器查询其能力。如果服务器认为它能与用户联系，则可用一个能力集响应OPTIONS 请求；对于代理和重定向服务器只要转发此请求，不用显示其能力。

OPTIONS 的From、To分别包含主被叫的地址信息，对OPTIONS 请求的响应中的From、To（可能加上tag 参数）、Call-ID字段的值由OPTIONS 请求中相应的字段值复制得到。

（4）BYE

用户代理客户机用BYE 请求向服务器表明它想释放呼叫。

BYE 请求可以象INVITE 请求那样被转发，可由主叫方发出也可由被叫方发出。呼叫的一方在释放（挂断）呼叫前必须发出BYE 请求，收到BYE 请求的这方必须停止发媒体流给发出BYE 请求的这方。

（5）CANCEL

CANCEL 请求用于取消一个Call-ID，TO，From 和Cseq（仅序列号）字段值相同的正在进行的请求，但取消不了已经完成的请求（如果服务器返回一个最终状态响应则认为请求已完成）。

CANCEL 请求中的Call-ID，To，Cseq 的数字部分及From 字段和原请求的对应字段值相同，从而使CANCEL请求与它要取消的请求匹配。

（6）REGISTER

REGISTER 方法用于客户机向SIP 服务器注册列在列在To 字段中的地址信息。

REGISTER 请求消息头中各个字段的含义定义如下：

To：含要创建或更新的注册的地址记录。

From：含提出注册的人的地址记录。

Request-URI：注册请求的目的地址，地址的域部分的值即为主管注册者所在的域，而主机部分必须为空。一般，Request-URI 中的地址的域部分的值和To 中的地址的域部分的值相同。

Call-ID：用于标识特定客户机的注册请求。来自同个客户机的注册请求至少在相同重启周期内Call-ID字段值应该相同；用户可用不同的Call-ID 值注册不同的地址，后面的注册请求将替换前面的所有请求。

Cseq：Call-ID 字段值相同的注册请求的CSeq 字段值必须是递增的，但次序无关系，服务器并不拒绝无序请求。

Contact：此字段是可选项；用于把以后发送到TO 字段中的URI 的非-注册请求转到Contact 字段给出的位置那里。如果请求中没有Contact 字段，那么注册保持不变。

Expires：表示注册的截止期。

（7）INFO

INFO方法是对SIP 协议的扩展，用于传递会话中产生的与会话相关的控制信息，如ISUP和ISDN信令消息，有关此方法的使用还有待标准化，详细内容参见IETF RFC 2976。

有关消息头和消息头各个字段的说明在下面章节将进一步描述。

1.4 SIP响应消息格式描述

响应消息的格式如下：

SIP响应消息=状态起始行

                    *（通用头部

                       | 响应头部

                       | 实体头部）

                    CRLF（空行）

                    [消息体]

状态行（Status-Line）以协议版本开始，接下来是用数字表示的状态码（Status-Code）及相关的文本说明，最后以回车键结束，各个元素间用空格字符（SP）间隔，除了在最后的CRLF 序列中，这一行别的地方不许使用回车或换行字符。

Status-Line = SIP-version SP Status-Code SP Reason-Phrase CRLF

其中SP符号代表空格。

SIP 协议中用三位整数的状态码（Status Code）和原因值（Reason Code）来表示对请求的作出的回答，状态码用于机器识别操作，原因短语（Reason-Phrase）是对状态码的简单文字描述用于人工识别操作，便于使用者理解。

在SIP/2.0 中状态码共分为6类，其中第一位数字指示响应类别，后两位数字表示该类中的具体响应。

Status-Code = 1xx (Informational)

                | 2xx (Success)

                | 3xx (Redirection)

                | 4xx (Client-Error)

                | 5xx (Server-Error)

                | 6xx (Global-Failure)

                | extension-code

（1）1xx：信息响应，即呼叫进展响应。表示请求已经收到，继续处理请求。

100：试呼中

180：振铃

181：呼叫正在前转

182：排队

（2）2xx：成功响应，表示行动已经成功地收到，理解和并接受。

200：OK

（3）3xx：重定向响应，表示为完成呼叫请求还须采取进一步的动作。

300：多重选择

301：永久迁移

302：临时迁移

303：见其他

305：使用代理

380：替换服务

（4）4xx：客户出错，表示请求有语法错误或不能被服务器执行。客户机需修改请求，然后再重发请求。

（5）5xx：服务器出错，表示服务器出错不能执行合法请求。

（6）6xx: 全局故障，表示任何服务器都不能执行请求。

其中1xx 响应为暂时响应，其它响应为最终响应。

SIP响应码是可扩展的。不要求SIP应用程序理解所有已经注册响应码的含义，但是它必须理解所有响应码的类别。不能识别的响应码则作为x00处理，此时，用户代理应向用户显示该响应的消息体，该消息体一般含有能解释该异常状态的可读信息。

上面我们介绍了SIP协议的消息头分为通用头部、请求头部、 响应头部和实体头部四种、下面我们介绍一下SIP协议的消息头。

1.5 SIP消息头格式描述

SIP 协议的消息头定义与HTTP 在语法规则和定义上很相似。每个头字段都遵循以下格式：首先是字段名（Field Name），字段名不分大小写，后面是冒号，然后是字段值，字段值与冒号间可有多个前导空格（LWS）。下面为SIP消息头格式：

message-header = field-name ":" [ field-value ] CRLF

field-name = token

field-value = *( field-content | LWS )

(1) 通用消息头General-header

通用头字段适用于请求消息和响应消息，包含的字段有：

general-header = Accept| Accept-Encoding| Accept-Language | Call-ID| Contact| CSeq| Date| Encryption| Expires| From| Organization| Record-Route| Timestamp| To| User-Agent| Via

其中，Accept，Accept-Encoding，Accept-Language字段用于客户机在请求消息中给出其可接受的响应的媒体类型，编码方式，以及描述语言；用于服务器在415 响应中表明其可理解的请求消息的媒体类型，编码方式，以及描述语言。

Call-ID：用于唯一标识特定邀请或某个客户机的注册请求，一个多媒体会议可产生多个Call-ID不同的呼叫。

Contact：给出一个URL，用户可以与此URL 建立进一步的通信。

Cseq：用于标识服务器发出的不同请求，若Call-ID 值相同，那么Cseq 值必须各不相同。

Date：反映首次发出请求或响应消息的时间，重发的消息与原先的消息有相同的Data 字段值。

Encryption：表明内容经过了加密处理，这种加密为端到端的加密。

Expire：给出消息内容截止的日期和时间。

From：此字段给出请求的发起者，所有消息中都必须有。

Organization：给出发出请求或响应消息的实体所属的组织的名称。

Record-Route：给出一个全局可到达的Request-URI，用于标识代理服务器。

Time-Stamp：给出客户机向服务器发出请求的时间。

To：此字段给出请求的目的收方，所有消息中都必须有。

User-Agent：含有与发起请求的用户代理客户机有关的信息。

Via：给出请求消息迄今为止经过的路径。

（2）实体消息头Entity-header

实体头字段用于定义与消息体相关的信息，包含的字段有：

entity-header = Content-Encoding| Content-Length| Content-Type

Content-Encoding：表明消息体上添加应用的内容编码方式。

Content-Length：表明消息体的大小。

Content-Type：表明消息体的媒体类型。

（3）请求消息头Request-header

请求头字段用于客户机上传附加信息到服务器，其中包括有关请求和客户机本身的信息。包含的字段有：

request-header = Authorization| Contact| Hide| Max-Forwards| Priority| Proxy-Authorization| Proxy-Require| Route| Require| Response-Key| Subject

Authorization：用于用户代理向服务器鉴定自身身份。

Hide：用于客户机表明其希望向后面的代理服务器或用户代理隐藏由Via 字段构成的路径。

Max-Forwards：表明请求消息允许被转发的次数。

Priority：用于客户机表明请求的紧急程度。

Priority-Authorization：用于客户机向要求身份认证的代理服务器表明自身身份。

Proxy-Require：用于标识出代理必须支持的代理敏感特征。

Route：决定请求消息的路由。

Require：用于客户机告诉代理服务器为了正确让服务器处理请求，客户机希望服务器支持的选项。

Response-Key：用于给出被叫方用户代理加密响应消息所采用的密钥需满足的要求。

Subject：提供对呼叫的概述或表明呼叫的性质，可用于呼叫过滤。

（4）响应消息头Response-header

响应头字段用于服务器向Request-URI 指定的地址传送有关响应的附加信息。包含的字段有：

response-header = Allow| Proxy-Authenticate| Retry-After| Server| Unsupported| Warning| WWW-Authenticate

Proxy-Authenticate：必须为407 响应的一部分，字段中的值给出适用于Request-URI 的代理的认证体制和参数。

Retry-After：可用于503 响应中，向发出请求的客户机表明服务预计多久以后可以启用，用于404，600，603响应中表明被叫方何时再有空。

Server：含用户代理服务器处理请求所使用的软件信息。

Unsupported：字段列出服务器不支持的特征。

Warning：用于传递与响应状态有关的附加信息。

WWW-Authenticate：含于401 响应中，指出适用于Request-URI 的认证体制和参数。

由于消息体的内容由SDP协议定义，我们在这里不作介绍。

1.6 SIP网络框架描述

SIP协议采用的是客户/服务器（C/S）控制方式，呼叫控制请求发出方称为客户，请求接收和处理方为服务器。SIP的网络框架为下图：

文件: SIP协议多媒体会议系统.rar 大小: 57KB 下载: 下载