目  录

第3章 SIP协议.................................................................................................................... 3-1

3.1 概述.......................................................................................................................... 3-1

3.1.1 基本概念.......................................................................................................... 3-1

3.1.2 相关术语.......................................................................................................... 3-2

3.1.3 协议栈结构....................................................................................................... 3-5

3.1.4 SIP协议的应用................................................................................................. 3-6

3.2 协议消息.................................................................................................................... 3-6

3.2.1 消息类型.......................................................................................................... 3-6

3.2.2 消息结构.......................................................................................................... 3-9

3.3 基本消息流程........................................................................................................... 3-23

3.3.1 SIP用户注册流程............................................................................................ 3-23

3.3.2 成功的SIP用户呼叫流程................................................................................. 3-26

3.3.3 成功的SIP中继呼叫流程................................................................................. 3-34

3.3.4 成功的SIP-T中继呼叫流程.............................................................................. 3-37

第3章  SIP协议

3.1  概述

3.1.1  基本概念

会话启动协议SIP（Session Initiation Protocol）是由IETF提出并主持研究的一个在IP网络上进行多媒体通信的应用层控制协议，它被用来创建、修改、和终结一个或多个参加者参加的会话进程。这些会话包括Internet多媒体会议、Internet电话、远程教育以及远程医疗等。即所有的因特网上交互式两方或多方多媒体通信活动，统称为多媒体会话。参加会话的成员可以通过组播方式、单播联网方式或者两者结合的方式进行通信。

SIP协议是一个正在发展和不断研究中的协议。一方面，它借鉴了其他Internet标准和协议的设计思想，在风格上遵循因特网一贯坚持的简练、开放、兼容和可扩展等原则，并充分注意到因特网开放而复杂的网络环境下的安全问题。另一方面，它也充分考虑了对传统公共电话网的各种业务，包括IN业务和ISDN业务的支持。

利用带有会话描述的SIP邀请消息来创建会话，以使参加者能够通过SIP交互进行媒体类型协商。它通过代理和重定向请求用户当前位置，以支持用户的移动性。用户也可以登记它们的当前位置。SIP协议独立于其他会议控制协议，它在设计上独立于下面的传输层协议，因此可以灵活方便地扩展其他附加功能。

SIP作为一个应用层的多媒体会话信令协议，可以被用来发起一个会话进程、在会话中邀请其他参加者加入会议，会话本身可以通过基于组播协议的会话通告协议（SAP）、电子邮件、网页通告、以及轻量级号薄访问协议（LDAP）等方式预先通告各个可能的参加者。SIP协议支持别名映射、重定向服务、ISDN和IN业务。它支持个人移动（personal mobility），即终端用户能够在任何地方、任何时间请求和获得已订购的任何电信业务。总的来说，会话启动协议能够支持下列五种多媒体通信的信令功能：

l   用户定位：确定参加通信的终端用户的位置；

l   用户通信能力协商：确定通信的媒体类型和参数；

l   用户意愿交互：确定被叫是否乐意参加某个通信；

l   建立呼叫：包括向被叫“振铃”，确定主叫和被叫的呼叫参数；

l   呼叫处理和控制：包括呼叫重定向、呼叫转移、终止呼叫等等。

SIP协议可以通过MCU（Multipoint Control Unit）、单播联网方式、或组播方式创建多方会话，支持PSTN和因特网电话之间的网关功能。

SIP协议可以与其他用于建立呼叫的信令系统或协议结合使用，它在设计上充分考虑了对其他协议的可扩展性。譬如，SIP协议支持的主叫可以识别出H.323协议支持的被叫，通过H.245网关利用H.225.0协议向被叫发起并建立呼叫；另外，一个SIP主叫可以识别出PSTN上的被叫及其电话号码，通过与PSTN相连的网关向被叫发起并建立呼叫。

SIP协议不提供发言控制（floor control）、投票等会议控制功能，也不规定如何管理一个会议。但是SIP协议可被用来引发这些会议控制协议。SIP协议本身不具备资源预留功能，但可以向被邀请者们传达这方面的信息。

3.1.2  相关术语

1. 呼叫

一个呼叫是由一个公共源端所邀请的在一个会议中的所有参加者组成，由一个全球唯一的Call-ID进行标识。

例如：由同一个源邀请的一个会议的所有参加者构成一个呼叫；点到点IP电话会话是一种最简单的会话，它映射为单一的SIP呼叫。

通常情况下，呼叫由主叫方创建，但是更一般说来，呼叫可由并不参与媒体通信的第三方创建，此时会话的主叫方和会话的邀请方并不相同。对于多播会议来说，一个用户可由不同的人邀请参加同一会议，则每一个邀请应视作不同的呼叫。对于基于MCU的会议，每个参与者使用一个呼叫邀请自己加入MCU。

2. 事务

SIP是一个客户/服务器协议。客户和服务器之间的操作从第1个请求至最终响应为止的所有消息构成一个SIP事务。

一个正常的呼叫一般包含三个事务。其中，呼叫启动包含两个操作请求：邀请（Invite）和证实（ACK），前者需要回送响应，后者只是证实已收到最终响应，不需要回送响应。呼叫终结包含一个操作请求：再见（Bye）。

3. SIP URL

为了能正确传送协议消息，SIP还需解决两个重要的问题。一是寻址，即采用什么样的地址形式标识终端用户；二是用户定位（下面介绍）。SIP沿用WWW技术解决这两个问题。

寻址采用SIP URL（Uniform Resource Locators），按照RFC2396规定的URI导则定义其语法，特别是用户名字段可以是电话号码，以支持IP电话网关寻址，实现IP电话和PSTN的互通。

SIP URL的一般结构为：

SIP：用户名：口令@主机：端口；传送参数；用户参数；方法参数；生存期参数；服务器地址参数？头部名＝头部值

“SIP”表示需采用SIP协议和所指示的端系统通信。

“用户名”可以由任意字符组成，一般可取类似与E-mail用户名形式，也可以是电话号码（SoftX3000目前用户名是电话号码）。

“主机”可为主机域名或IPv4地址。

“端口”指示请求消息送往的端口号，其缺省值为5060，即公开的SIP端口号。

“口令”可以置于SIP URL中，但一般不建议这样做，因为其安全性是有问题的。

“传送参数”指示采用TCP还是UDP传送，缺省值为UDP。

“用户参数”，SIP URL的一个特定功能是允许主机类型为IP电话网关，此时，用户名可以为一般的电话号码。由于BNF语法表示无法区分电话号码和一般的用户名，因此，在域名后增加了“用户参数”字段。该字段有两个可选值：IP和电话，当其设定为“电话”时，表示用户名为电话号码，对应的端系统为IP电话网关。

“方法参数”指示所用的方法（操作）。

“生存期参数”指示UDP多播数据包的寿命，仅当传送参数为UDP、服务器地址参数为多播地址时才能使用。

“服务器地址参数”指示和该用户通信的服务器的地址，它覆盖“主机”字段中的地址，通常为多播地址。

“传送参数”、“生存期参数”、“服务器地址参数”和“方法参数”均属于URL参数，只能在重定向地址，即后面所说的Contact字段中才能使用。

下面给出若干个SIP URL的示例：

Sip; 55500200@191.169.1.112;

55500200为用户名，191.169.1.112为IP电话网关的IP地址。

Sip; 55500200@127.0.0.1:5061; User=phone;

55500200为用户名，127.0.0.1为主机的IP地址，5061为主机端口号。用户参数为“电话”，表示用户名为电话号码。

Sip: alice@registrar.com; method=REGISTER;

Alice为用户名，registrar.com为主机域名。方法参数为“登记”。

4. 用户定位

用户定位基于登记。SIP用户终端上电后即向登记服务器（SoftX3000）登记，SIP专门为此定义了一个“登记”（REGISTER）请求消息，并规定了登记操作过程。

5. 定位服务（Location Service）

SIP重定位服务器或代理服务器用来获得被叫位置的一种服务，可由定位服务器提供，但SIP协议不规定SIP服务器如何请求定位服务。在华为U-SYS解决方案中，SoftX3000兼任定位服务器的角色。

6. 代理，代理服务器（Proxy、Proxy sever）

作为一个逻辑网络实体代表客户端转发请求或者响应，可以同时作为客户端和服务器端。代理服务器有三种形态：Stateless、Statefull和Call Stateful，其可以采用分支、循环等方式向多个地址尝试转发请求。

代理服务器的主要功能：路由、认证鉴权、计费监控、呼叫控制、业务提供等。在华为U-SYS解决方案中，SoftX3000兼任代理服务器的角色。

7. 重定向服务器（Redirect server）

重定向服务器将请求中的目的地址映射为零个或多个新的地址，然后返回给客户端，客户端直接再次向这些新的地址发起请求。重定向服务器并不接收或者拒绝呼叫，主要完成路由功能，与注册过程配合可以支持SIP终端的移动性。在华为U-SYS解决方案中，SoftX3000兼任重定向服务器的角色。

8. 注册员（Registrar）

注册员为接收注册请求的服务器，通常与Proxy或者Redirect Server共存。注册员需要将注册请求中的地址映射关系保存到数据库中，供后续的相关呼叫过程使用，同时可以提供定位服务。在华为U-SYS解决方案中，SoftX3000兼任注册员的角色。

9. 用户助理（User Agent）

用来发起或者接收请求的逻辑实体称为User Agent。

10. 用户助理客户（User Agent Client）

发起请求的一方称为UAC（User Agent Client），举例SIP Phone就是UAC的一种实际形态。

11. 用户助理服务器（User Agent Server)

接收请求的一方称为UAS（User Agent Server），举例SoftX3000就是UAS的一种实际形态。

注意：UAC和UAS的划分是针对一个事务而言的。

3.1.3  协议栈结构

SIP协议栈结构如图3-1所示。

图3-1 SIP协议栈

SIP协议是IETF多媒体数据和控制体系结构的一部分，与其它协议相互合作，例如：RSVP（Resource ReServation Protocol）用于预约网络资源，RTP（Real-time Transmit Protocol）用于传输实时数据并提供服务质量（QoS）反馈，RTSP（Real-Time Stream Protocol）用于控制实时媒体流的传输，SAP（Session Announcement Protocol）用于通过组播发布多媒体会话，SDP（Session Description Protocol）用于描述多媒体会话。但是SIP协议的功能和实施并不依赖这些协议。

传输层支持：SIP协议承载在IP网，网络层协议为IP，传输层协议可用TCP或UDP，推荐首选UDP。

3.1.4  SIP协议的应用

SoftX3000通过SIP/SIP-T与其它软交换系统互通，以及与其它SIP域设备（如SIP Phone，SIP Softphone等）互通，SIP协议在NGN中的典型应用如图3-2所示：

图3-2 SIP在NGN中的典型应用

3.2  协议消息

3.2.1  消息类型

SIP消息采用文本方式编码，分为两类：请求消息和响应消息。

1. 请求消息

用于客户端为了激活按特定操作而发给服务器的SIP消息，包括INVITE， ACK，OPTIONS，BYE，CANCEL和REGISTER消息等，各消息功能如表3-1所示。

表3-1 请求消息

2. 响应消息

用于对请求消息进行响应，指示呼叫的成功或失败状态。不同类的响应消息由状态码来区分。状态码包含三位整数，状态码的第一位用于定义响应类型，另外两位用于进一步对响应进行更加详细的说明。各响应消息分类和含义如表3-2所示。

表3-2 响应消息

请求消息和响应消息都包括SIP头字段和SIP消息字段。

在SIP消息中加入SDP消息正文部分。

3.2.2  消息结构

1. 请求消息

(1)      请求消息结构

如图3-3所示是SIP请求命令的格式，由起始行、消息头和消息体组成。通过换行符区分消息头中的每一条参数行。对于不同的请求消息，有些参数可选。

如图3-3所示是SIP请求命令的格式，由起始行、消息头和消息体组成。通过换行符区分消息头中的每一条参数行。对于不同的请求消息，有些参数可选。

图3-3 SIP请求消息结构

(2)      请求消息参数

下面仅对几个常用的参数字段进行说明。

l   Call-ID

该字段用以唯一标识一个特定的邀请或标识某一客户的所有登记。该字段用以唯一标识一个特定的邀请或标识某一客户的所有标记。该字段用以唯一标识一个特定的要求或标识某一客户的所有标记。

需要注意的是，一个多媒体会议可能会有多个呼叫，每个呼叫有其自己的Call-ID。例如，某用户可数次邀请某人参加同一历时很长的会议。用户也可能会收到数个参加同一会议或呼叫的邀请，其Call-ID各不相同。用户可以利用会话描述中的标识，例如SDP中的o（源）字段的会话标识和版本号判定这些邀请的重复性。

Call-ID的一般格式为：

Call-ID：本地标识@主机

其中，主机应为全局定义域名和全局可选路IP地址，此时，本地标识由在“主机”范围内唯一的URI字符组成。否则，本地标识必须是全局唯一的值，以保证Call-ID的全局唯一性。Call-ID字符需区分大小写。

Call-ID示例：

Call-Id: call-973636852-4@191.169.150.101

其中，191.169.150.101为主机的IP地址，call-973636852-4为全局唯一的本地标识。

l   From

所有请求和响应必须包含此字段，以指示请求的发起者。服务器将此字段从请求消息复制到响应消息。

该字段的一般格式为：

From:显示名<SIP-URL>;tag=xxxx

其中，显示名为用户界面上显示的字符，如果系统不予显示，应置显示名为“匿名(Anonymous)”。显示名为任选字段。tag称为标记，为16进制数字串，中间可带连字符“-”。当两个共享同一SIP地址的用户实例用相同的Call-ID发起呼叫邀请时，就需用此标记予以区分。标记值必须全局唯一。用户在整个呼叫期间应保持相同的Call-ID和标记值。

From字段的示例：

From: <sip:1000@191.169.200.61>;tag=1c17691

l   To

该字段指明请求的接收者，其格式和From相同，仅第一个关键词代之以To。所有请求和响应消息必须包含此字段。

字段中的标记参数可用于区分由同一SIP URL标识的不同的用户实例。由于代理服务器可以并行分发多个请求，同一请求可能到达用户的不同实例（如住宅电话等）。由于每个实例都可能响应，因此需用标记来区分来自不同实例的响应。需要注意的是，To字段中的标记是由每个实例至于响应消息中的。

To字段的示例：

To: <Sip:1000@191.169.200.61>

To: <sip:1001@191.169.200.61>;tag=62beb3ca

注意，在SIP中，Call-ID、From和To三个字段标识一个呼叫分支。在代理服务器并行分发请求时，一个呼叫可能会有多个呼叫分支。

l   Cseq

Cseq称之为命令序号。客户在每个请求中应加入此字段，它由命令名称和一个十进制序号组成，该序号由请求客户选定，在Call-ID范围内唯一确定。序号初值可为任意值，其后具有相同Call-ID值，但不同命令名称、消息体的请求，其Cseq序号应加1。重发请求的序号保持不变。服务器将请求中的Cseq值复制到响应消息中，用于将请求和其触发的响应相关联。

ACK和CANCEL请求的Cseq值（十进制序号）和对应的INVITE请求相同，BYE请求的Cseq序号应大于INVITE请求。服务器必须记忆相同Call-ID的INVITE请求的最高序号，收到序号低于此值的INVITE请求应在给出响应后予以丢弃。

由代理服务器并行分发的请求，其Cseq值相同。严格来说，Cseq对于任何可由BYE或CANCEL请求取消的请求以及客户可连续发送多个具有相同Call-ID请求的情况都是需要的，其作用是判定响应和请求的对应关系。

Cseq字段的示例：

Cseq: 1 INVITE

l   Via

Via字段用以指示请求历经的路径。它可以防止请求消息传送产生环路，并确保响应和请求消息选择同样的路径，以保证通过防火墙或满足其它特定的选路要求。

发起请求的客户必须将其自身的主机名或网络地址插入请求的Via字段，如果未采用缺省端口号，还需插入此端口号。在请求前传过程中，每个代理服务器必须将其自身地址作为一个新的Via字段加在已有的Via字段之前。如果代理服务器收到一个请求，发现其自身地址位于Via头部中，则必须回送响应“检测到环路”。

当请求消息通过网络地址翻译点（如防火墙）时，请求的源地址和端口号可能被改变，此时Via字段就不能成为响应消息选路的依据。为了防止这一点，代理服务器应校验顶端Via字段，如果发现其值和代理服务器检测到的前站地址不符，则应在该Via字段中加入“receive”参数，如此修改后的字段称为“接收方标记Via头部字段”。例如：

Via:SIP/2.0/UDP softx3000.bell-telephone.com:5060

Via:SIP/2.0/UDP 10.0.0.1:5060;received=191.169.12.30

由点10.0.0.1发出的请求消息路径外部地址为191.169.12.30的网络地址翻译点后，到达代理服务器softx3000.bell-telephone.com。后者注意到前站发送地址和Via字段地址不符，就把实际发送地址作为接收方标记加在顶端Via字段的末尾，然后再将代理自己的地址作为新加的Via字段置于最上面。

若代理服务器向多播地址发送请求，则必须在其Via头部字段中加入“多播地址(maddr)”参数，此参数指明该多播地址。

代理服务器或UAC收到Via头部字段时的处理规则是：

规则1：第1个Via头部字段应该指示本代理服务器或UAC。如果不是，丢弃该消息，否则，删除该Via字段。

规则2：如果没有第2个Via头部字段，则该响应已经到达目的地。否则，继续做如下处理。

规则3：如果第2个Via头部字段包含“maddr”参数，则按该参数指示的多播地址发送响应，端口号由“发送方”参数指明，如未指明，就使用端口号5060。响应的生存期应置为“生存期（ttl）”参数指定的值，如未指明，则置为1。

规则4：如果第2个Via字段不包含“maddr”参数，但有一个接收方标记字段，则应将该响应发往“received”参数指示的地址。

规则5：如果既无“maddr”参数又无标记，就按发送方参数指示的地址发送响应。

Via字段的一般格式为：

Via：发送协议 发送方；隐藏参数；生存期参数；多播地址参数；接收方标记，分支参数

其中，发送协议的格式为：协议名/协议版本/传送层，协议名和传送层的缺省值分别为SIP和UDP。发送方为通常的发送方主机和端口号。隐藏参数就是关键词hidden，如有此参数，表示该字段已由上游代理予以加密，以提供隐私服务。多播地址参数和接收方标记的意义如前所述。生存期参数与多播地址参数配用。分支参数用于代理服务器并行分发请求时标记各个分支，当响应到达时，代理可判定是哪一分支的响应。

Via字段的示例：

Via:SIP/2.0/UDP191.169.1.116:5061;ttl=16;maddr=191.169.10.20;branch=z9hG4bkbc427dad6

l   Contact

该字段用于INVITE、ACK和REGISTER请求以及成功响应、呼叫进展响应和重定向响应消息，其作用是给出其后和用户直接通信的地址。

INVITE和ACK请求中的Contact字段指示该请求发出的位置。它使被叫可以直接将请求（如BYE请求）发往该地址，而不必借助Via字段经由一系列代理服务器返回。

对INVITE请求的成功响应消息可包含Contact字段，它使其后SIP请求（如ACK请求）可直接发往该字段给定的地址。该地址一般是被叫主机的地址，如果该主机位于防火墙之后，则为代理服务器地址。

对应于INVITE请求的呼叫进展响应消息中包含的Contact字段的含义和成功响应消息相同。但是，CANCEL请求不能直接发往该地址，必须沿原请求发送的路径前传。

REGISTER请求中的Contact字段指明用户可达位置。该请求还定义了通配Contact字段“*”，它只能和值为0的“失效”字段配用，表示去除某用户的所有登记。Contact字段也可设定“失效”参数（任选），给定登记的失效时间。如果没有设定该参数，则用“失效”字段值作为其缺省值。如果两者均无，则认为SIP URI的失效时间为1小时。

REGISTER请求的成功响应消息中的Contact字段返回该用户当前可达的所有位置。

重定向响应消息，如用户临时迁移、永久迁移、地址模糊等消息中的Contact字段给出供重试的其它可选地址，可用于对BYE、INVITE和OPTIONS请求的响应消息。

Contact字段的一般格式为：

Contact：地址；q参数；动作参数；失效参数；扩展属性

其中，地址的表示形式和To，From字段相同。q参数，其取值范围为[0，1]，指示给定位置的相对优先级。数值越大，优先级越高。动作参数仅用于REGISTER请求。它表明希望服务器对其后至该客户的请求进行代理服务还是重定向服务。如果未含此参数，则执行动作取决于服务器的配置。失效参数指明URI的有效时间，可用秒表示，也可用SIP日期表示。扩展属性就是扩展名。

Contact字段的示例为：

Contact: <Sip:66500002@191.169.1.110:5061>;q=0.7;expires=3600

l   Max-Forwards

该字段用于定义一个请求到达其目的地址所允许经过的中转站的最大值。请求每经过一个中转站，该值减1。如果该值为0时该请求还没有到达其目的地址，服务器将回送“483”(Too Many Hops)响应并终止这个请求。

设置该字段的目的主要是为了出现环路时不会一直消耗代理服务器的资源。该字段的初始值为70。

Max-Forwards字段的一般格式为：

Max-Forwards:十进制整数

l   Allow

该字段给出代理服务器支持的所有请求消息类型列表。

Allow字段的示例：

Allow: INVITE, ACK, OPTIONS, CANCEL, BYE

l   Content-Length

该字段表示消息体的大小，为十进制值。应用程序使用该字段表示要发送的消息体的大小，而不考虑实体的媒体类型。如果使用基于流的协议（如TCP协议）作为传输协议，则必须使用此消息头字段。

消息体的长度不包括用于分离消息头部和消息体的空白行。 Content-Length值必须大于等于0。如果消息中没有消息体，则Content-Length头字段值必须设为0。

SDP用于构成请求消息和2xx响应消息的消息体。

Content-Length字段的一般格式为：

Content-Length：十进制值

Content-Length字段的示例：

Content-Length: 349

表示消息体的长度为349个字节。

l   Content-Type

Content-Type字段表示发送的消息体的媒体类型。如果消息体不为空，则必须存在Content-Type 头字段。如果消息体为空且Content-Type 头字段存在，则表示此类型的消息体长度为0 （如一个空的声音文件）。

Content-Type字段的示例：

Content-Type: application/sdp

l   Supported

SIP协议中定义的100类临时响应消息的传输是不可靠的，即UAS发送临时响应后并不能保证UAC端能够接受到该消息。

如果需要在该响应消息中携带媒体信息，那么就必须保证该消息能够可靠的传输到对端。100rel扩展为100类响应消息的可靠传输提供了相应的机制。100rel新增加对临时响应消息的确认请求方法：PRACK。

如果UAC支持该扩展，则在发送的消息中增加Supported:100rel头域和字段。如果UAS支持该扩展，则在发送100类响应时增加Require:100rel头域和字段。UAC收到该响应消息后需要向UAS发送PRACK请求通知UAS已收到该临时响应。UAS向UAC发送对PRACK的2XX响应消息结束对该临时响应的确认过程。

如果某一UA想要在发送的临时响应消息中携带SDP消息体，那么UAC和UAS都必须支持和使用100rel扩展以保证该消息的可靠传输。

举例：

Supported: 100rel

l   User-Agent

User-Agent头字段包含有发起请求的用户终端的信息。

显示用户代理的软件版本信息可能会令用户在使用有安全漏洞的软件易受到外界攻击，因此，应该使User-Agent头字段成为可选配置项。

举例：

User-Agent: Softphone Beta1.5

l   Expires

Expires头字段指定了消息（或消息内容）多长时间之后超时。

举例：

Expires: 5

l   Accept-Language

Accept-Language头字段用在请求消息中，表示原因短语、会话描述或应答消息中携带的状态应答内容的首选语言类型。如果消息中没有Accept-Language头字段，则服务器端认为客户端支持所有语言。

举例：

Accept-Language: en

l   Authorization

Authorization字段包含某个终端的鉴权证书。

首先介绍一下终端向服务器端请求认证的一般过程：

终端发起请求时如果服务器端需要对用户进行认证，那么会在本地产生本次认证的NONCE，并且通过认证请求头域将所有必要的参数返回给终端从而发起对用户认证过程。

终端收到认证请求消息后根据服务器端返回的信息和用户配置等信息采用特定的算法生成加密的RESPONSE，并且通过新的请求消息发送给服务器端。

服务器端在收到带有认证响应的新的请求消息后首先检查NONCE的正确性。如果NONCE不是本地产生，则直接返回失败。否则如果NONCE是本地产生，但是认证过程已经超时，则服务器端会重新产生NONCE并重新发起对用户的认证过程。其中老的NONCE会通过CNONCE参数返回。

NONCE验证通过后服务器端会根据NONCE、用户名、密码（服务器端可以根据本地用户信息获取用户的密码）、URI等采用和终端相同的算法生成RESPONSE，并且对此RESPONSE和请求消息中的RESPONSE进行比较，如果二者一致则用户认证成功，否则认证失败。

Authorization字段的一般格式为：

Authorization：认证方式  USERNAME，REALM，NONCE，RESPONSE，URI，CNONCE，ALGORITHM

认证方式：有DIGEST、BASIC、CHAP-PASSWORD、CARDDIGEST等认证方式。DIGEST为HTTP-DIGEST认证方式。目前SoftX3000只支持HTTP-DIGEST方式。以后为了实现Uniphone的卡号呼叫还会加入卡号认证的CARDDIGEST方式。

USERNAME：被认证的用户的用户名。

REALM：用于标识发起认证过程的域。

NONCE：由发起认证过程的实体产生的加密因子。

RESPONSE：终端在收到服务器的认证请求后根据服务器端产生的NONCE、用户名、密码、URI等信息经过一定的算法生成的一个字符串。该字符串中包含了经过加密后的用户密码。（在认证过程中处理用户密码之外其他信息都会通过SIP消息以明文的方式在终端和服务器端进行传递。）

URI：发起的呼叫请求消息的Request-URI。由于终端在收到认证请求后需要重新向服务器端发起请求（其中带有认证响应信息）。该请求消息在经过网络服务器时某些字段包括Request－URI都有可能被修改。认证头域的URI参数用于传递终端发起请求时原始消息的Request-URI用于对认证信息进行认证，这样才能保证认证过程的正确性。

CNONCE：如果在服务器端超时后终端才向服务器返回了带有认证响应的新的请求消息，则服务器端需要重新产生NONCE重新对用户进行认证。其中NONCE中带有新的NONCE，老的NONCE会通过CNONCE参数返回给终端。

ALGORITHM：用于传递生成RESPONSE的算法。

举例：

Authorization: DIGEST USERNAME="6540012", REALM="huawei.com", NONCE="200361722310491179922", RESPONSE="b7c848831dc489f8dc663112b21ad3b6", URI="sip:191.169.150.30"

(3)      请求消息示例

下面是SIP请求消息编码的示例：

INVITE sip:66500002@191.169.1.110 SIP/2.0

From: <sip:44510000@191.169.1.116>;tag=1ccb6df3

To: <sip:66500002@191.169.1.110>

CSeq: 1 INVITE

Call-ID: 20973e49f7c52937fc6be224f9e52543@sx3000

Via: SIP/2.0/UDP 191.169.1.116:5061;branch=z9hG4bkbc427dad6

Contact: <sip:44510000@191.169.1.116:5061>

Supported: 100rel,100rel

Max-Forwards:70

Allow:INVITE,ACK,CANCEL,OPTIONS,BYE,REGISTER,PRACK,INFO,UPDATE,SUBSCRIBE,NOTIFY,MESSAGE,REFER

Content-Length:230

Content-Type: application/sdp

v: 0

o: HuaweiSoftX3000 1073741831 1073741831 IN IP4 191.169.1.116

s: Sip Call

c: IN IP4 191.169.1.95

t: 0 0

m: audio 30000 RTP/AVP 8 0 4 18

a: rtpmap:8 PCMA/8000

a: rtpmap 0 PCMU/8000

a: rtpmap 4 G723/8000

a: rtpmap 18 G729/8000

第一行：请求起始行。INVITE请求消息。请求URI，即被邀用户的当前地址为“sip:66500002@191.169.1.110”。SIP版本号为2.0。

第二行：From字段。指明请求发起方的地址为“<sip:44510000@191.169.1.116>”。标记为“1ccb6df3”，用于共享同一SIP地址的不同用户用相同的Call-ID发起呼叫邀请时，对用户进行区分。

第三行：To字段。指明请求接收方的地址为“<sip:66500002@191.169.1.110>”。

从From和To字段，我们可以看出：

IP地址为191.169.1.116的MGC控制下的终端44510000拨打IP地址为191.169.1.110的MGC控制下的66500002终端。终端类型可以为SIP、H.323、IAD/AG下挂的ESL等。

第四行：Cseq字段。用于将INVITE请求和其触发的响应、对应的ACK、CANCEL请求相关联。

第五行：Call-ID字段。该字段唯一标识一个特定的邀请，全局唯一。Call-ID为“20973e49f7c52937fc6be224f9e52543@sx3000”，sx3000为发起呼叫的SoftX3000的域名，20973e49f7c52937fc6be224f9e52543为本地标识。

第六行：Via字段。该字段用于指示该请求历经的路径。“SIP/2.0/UDP”表示发送的协议，协议名为“SIP”，协议版本为2.0，传输层为UDP；“191.169.1.116:5061”表示发送方SoftX3000 IP地址为191.169.1.116，端口号为5061；“branch=z9hG4bkbc427dad6”为分支参数，SoftX3000并行分发请求时标记各个分支。

第七行：Contact字段。指示其后的请求（如BYE请求）可以直接发往<sip:44510000@191.169.1.116:5061>，而不必借助Via字段。

第八行：100rel扩展，该字段为100类响应消息的可靠传输提供了相应的机制。

第九行：Max-Forwards字段。表示该请求到达其目的地址所允许经过的中转站的最大值为70。

第十行：Allow字段。给出IP地址为191.169.1.116的SoftX3000支持的请求消息类型 列表。

第十一行：Content-Type字段，表示消息中携带的消息体是单消息体且为SDP。

第十二行：空行，表示下面为SDP会话描述。

第十三行：SDP协议版本号，目前为0版本。

第十四行：会话拥有者/创建者和会话标识，用于给出会话的发起者（其用户名和用户主机地址）以及会话标识和会话版本号。“HuaweiSoftX3000”为用户名，用户名是用户在发起主机上的登录名，如果主机不支持用户标识的概念，该字段标记为“-”。第一个“1073741831”为会话标识，会话标识为一数字串，使得多元组（用户名、会话标识、网络类型、地址类型、地址）构成会话的全球唯一的标识符。第二个“1073741831”为版本号，指该会话公告的版本。供代理服务器检测同一会话的若干个公告哪一个是最新的公告。其基本要求是会话数据修改后，其版本号应递增。“IN”指网络类型，为文本串形式，目前规定的“IN”为Inernet。“IP4”指地址类型，为文本串形式，目前已定义的有“IP4”和“IP6”两种。“191.169.1.116”为创建会话的主机的IP地址。对于IP4地址类型，可以是域名全称或点分十进制IP4地址表示形式。对于IP6地址类型，可以是域名全称或压缩文本IP6地址表示形式。

第十五行：会话名。每个会话描述必需有一个且只有一个会话名。

第十六行：连接数据。网络类型和地址类型目前的定义值仅限于IN和IP4。“191.169.1.95”为SoftX3000（IP地址：191.169.1.116）控制下的MG的IP地址（终端类型为IAD/AG下挂的ESL电话）或SIP、H.323终端的IP地址（终端类型为SIP、H.323电话）。

第十七行：时间描述，给出会话激活的时间区段，允许会话周期性发生。 “0”表示起始时间。该字段的格式为t：<起始时间><终止时间>。其中起始时间和终止时间值为NTP（Network Time Protocol）时间值的十进制表示，单位为秒。

第十八行：媒体级描述，该部分给出只适用于该媒体流的信息。“audio”表示媒体类型为音频。目前定义的媒体类型有5种：音频、视频、应用、数据和控制。“30000”指明媒体流发往的传送层端口，即MG的UDP端口号（终端类型为IAD/AG下挂的ESL电话）或SIP、H.323终端的UDP端口号（终端类型为SIP、H.323电话）。“RTP/AVP”为传送层协议，其值和“c”行中的地址类型有关，对于IP4来说，大多数媒体业务流都在RTP/UDP上传送，已定义如下两类协议：RTP/AVP，音频/视频应用文档，在UDP上传送；Udp，UDP协议。“8 0 4 18”对于音频和视频来说，就是RTP音频/视频应用文档中定义的媒体静荷类型。表示会话中所有这些格式都可能被用到，但第一个格式是会话的缺省格式。

该行总体表示，缺省A律PCM编码单信道音频信号，其在RTP音频/视频应用文档中的静态静荷类型号为8 ，该信号发往UDP端口30000。

第十九～二十二行：rtpmap属性行，指明从RTP静荷类型至编码的映射关系。该行的格式为：a: rtpmap:<静荷类型><编码名>/<时钟速率>[/<编码参数>]。其中，<编码参数>指的就是音频信道数，对于视频信号尚无编码参数。

2. 响应消息

(1)      响应消息结构

如图3-4所示是SIP响应消息的格式，由起始行、消息头和消息体组成。通过换行符区分消息头中的每一行参数。对于不同的响应消息，有些参数可选。

图3-4 SIP响应消息结构

(2)      响应消息参数

响应消息参数请参考“请求消息参数”一节。

(3)      响应消息示例

下面是SIP响应消息编码的示例：

SIP/2.0 180 Ringing

From: <sip:44510000@191.169.1.116>;tag=1ccb6df3

To: <sip:66500002@191.169.1.110>;tag=58877b85

Cseq:1 INVITE

Call-ID: 20973e49f7c52937fc6be224f9e52543@sx3000

Via: SIP/2.0/UDP 191.169.1.116:5061;branch=z9hG4bkbc427dad6

Require:100rel

RSeq:1

Contact:<sip:66500002@191.169.1.110:5061;transport=udp>

Content-Length:157

Content-Type:application/sdp

v=0

o=HuaweisoftX3000 1073741824 1073741824 IN IP4 191.169.1.110

s=Sip Call

c=IN IP4 191.169.1.135

t=0 0

m=audio 30016 RTP/AVP 8

a=rtpmap:8 PCMA/8000

第一行：SIP协议，版本号为2.0。状态码为180。“Ringing”为注释短语。表示向被叫送振铃。

第二行、第三行：请参考“请求消息示例”小节。

第四行：Cseq字段。用于将INVITE请求和其触发的响应、对应的ACK、CANCEL请求相关联。该响应消息和上文中的请求消息Cseq字段相同，均为“1 INVITE”，表明该响应消息由上文中的请求消息触发。

第五～第十一行：请参考“请求消息示例”小节。

第十二行：空行，表示下面为SDP会话描述。

第十三行：SDP协议版本号，目前为0版本。

第十四行：会话拥有者/创建者和会话标识，用于给出会话的发起者（其用户名和用户主机地址）以及会话标识和会话版本号。“HuaweiSoftX3000”为用户名，用户名是用户在发起主机上的登录名，如果主机不支持用户标识的概念，该字段标记为“-”。第一个“1073741824”为会话标识，会话标识为一数字串，使得多元组（用户名、会话标识、网络类型、地址类型、地址）构成会话的全球唯一的标识符。第二个“1073741824”为版本号，指该会话公告的版本。供代理服务器检测同一会话的若干个公告哪一个是最新的公告。其基本要求是会话数据修改后，其版本号应递增。“IN”指网络类型，为文本串形式，目前规定的“IN”为Inernet。“IP4”指地址类型，为文本串形式，目前已定义的有“IP4”和“IP6”两种。“191.169.1.110”为创建会话的主机的IP地址。

第十五行：会话名。每个会话描述必需有一个且只有一个会话名。

第十六行：连接数据。网络类型和地址类型目前的定义值仅限于IN和IP4。“191.169.1.135”为SoftX3000（IP地址：191.169.1.110）控制下的MG的IP地址（终端类型为IAD/AG下挂的ESL电话）或SIP、H.323终端的IP地址（终端类型为SIP、H.323电话）。

第十七行：时间描述，给出会话激活的时间区段，允许会话周期性发生。

第十八行：媒体级描述，该部分给出只适用于该媒体流的信息。“audio”表示媒体类型为音频。“30016”指明媒体流发往的传送层端口，即MG的UDP端口号（终端类型为IAD/AG下挂的ESL电话）或SIP、H.323终端的UDP端口号（终端为SIP、H.323电话）。“RTP/AVP”为传送层协议，其值和“c”行中的地址类型有关，对于IP4来说，大多数媒体业务流都在RTP/UDP上传送，已定义如下两类协议：RTP/AVP，音频/视频应用文档，在UDP上传送；Udp，UDP协议。“8”就是RTP音频/视频应用文档中定义的媒体静荷类型。

第十九行：rtpmap属性行，指明从RTP静荷类型至编码的映射关系。RTP静荷类型“8”对应的编码为PCMA。

3.3  基本消息流程

3.3.1  SIP用户注册流程

用户每次开机时都需要向服务器注册，当SIP Client的地址发生改变时也需要重新注册。注册信息必须定期刷新。下面以SIP Phone向SoftX3000注册的流程为例，说明SIP用户的注册流程。

在下面的实例中，我们基于以下约定：

l   SoftX3000的IP地址为191.169.150.30；

l   SIP Phone的IP地址为191.169.150.251；

l   SIP Phone向SoftX3000请求登记。

图3-5 SIP实体和SIP服务器之间的登记流程

(1)      事件1：SIP Phone向SoftX3000发起注册请求，汇报其已经开机或重启动，请求向MGC注册。下面是Register请求消息编码的示例。

REGISTER sip:191.169.150.30 SIP/2.0

From: sip:6540012@191.169.150.30;tag=16838c16838

To: sip:6540012@191.169.150.30;tag=946e6f96

Call-Id: 1-reg@191.169.150.251

Cseq: 2762 REGISTER

Contact: sip:6540012@191.169.150.251

Expires: 100

Content-Length: 0

Accept-Language: en

Supported: sip-cc, sip-cc-01, timer

User-Agent: Pingtel/1.2.7 (VxWorks)

Via: SIP/2.0/UDP 191.169.150.251

第一行：请求起始行。REGISTER请求消息。表示终端向IP地址为191.169.150.30的MGC发起登记。SIP版本号为2.0。

第二行：From字段。指明该REGISTER请求消息由MGC（IP地址：191.169.150.30）控制的SIP Phone发起的。

第三行：To字段。指明REGISTER请求接收方的地址。此时REGISTER请求的接收方为IP地址为191.169.150.30的MGC。

第四行：Call-ID字段。该字段唯一标识一个特定的邀请，全局唯一。Call-ID为“1-reg@191.169.150.251”，191.169.150.251为发起REGISTER请求的SIP Phone的IP地址，1-reg为本地标识。

第五行：Cseq字段。此时用于将REGISTER请求和其触发的响应相关联。

第六行：Contact字段。在REGISTER请求中的Contact字段指明用户可达位置。表示SIP Phone当前的IP地址为“191.169.150.251”，电话号码为“6540012”。

第七行：表示该登记生存期为100s。

第八行：表明此请求消息消息体的长度为空，即此消息不带会话描述。

第九行：表示原因短语、会话描述或应答消息中携带的状态应答内容的首选语言为英语。

第十行：表示发送该消息的UA实体支持sip-cc, sip-cc01以及timer扩展协议。timer表示终端支持session-timer扩展协议。

第十一行：发起请求的用户终端的信息。此时为SIP Phone的型号和版本。

第十二行：Via字段。该字段用于指示该请求历经的路径。“SIP/2.0/UDP”表示发送的协议，协议名为“SIP”，协议版本为2.0，传输层为UDP；“191.169.150.251”表示该请求消息发送方SIP终端IP地址为191.169.150.251。

(2)      事件2：SoftX3000返回401 Unauthorized（无权）响应，表明MGC端要求对用户进行认证，并且通过WWW-Authenticate字段携带MGC支持的认证方式Digest和MGC域名“huawei.com”，产生本次认证的nonce，并且通过该响应消息将这些参数返回给终端从而发起对用户的认证过程。

SIP/2.0 401 Unauthorized

From: <sip:6540012@191.169.150.30>;tag=16838c16838

To: <sip:6540012@191.169.150.30>;tag=946e6f96

CSeq: 2762 REGISTER

Call-ID: 1-reg@191.169.150.251

Via: SIP/2.0/UDP 191.169.150.251

WWW-Authenticate: Digest realm="huawei.com",nonce="200361722310491179922"

Content-Length: 0

(3)      事件3：SIP Phone重新向SoftX3000发起注册请求，携带 Authorization字段，包括认证方式DIGEST、SIP Phone的用户标识（此时为电话号码）、MGC的域名、NONCE、URI和RESPONSE（SIP Phone收到401 Unauthorized响应后根据服务器端返回的信息和用户配置等信息采用特定的算法生成加密的RESPONSE）字段。下面是Register请求消息编码的示例：

REGISTER sip:191.169.150.30 SIP/2.0

From: sip:6540012@191.169.150.30;tag=16838c16838

To: sip:6540012@191.169.150.30;tag=946e6f96

Call-Id: 1-reg@191.169.150.251

Cseq: 2763 REGISTER

Contact: sip:6540012@191.169.150.251

Expires: 100

Content-Length: 0

Accept-Language: en

Supported: sip-cc, sip-cc-01, timer

User-Agent: Pingtel/1.2.7 (VxWorks)

Authorization: DIGEST USERNAME="6540012", REALM="huawei.com", NONCE="200361722310491179922", RESPONSE="b7c848831dc489f8dc663112b21ad3b6", URI="sip:191.169.150.30"

Via: SIP/2.0/UDP 191.169.150.251

(4)      事件4：MGC收到SIP Phone的注册请求，首先检查NONCE的正确性，如果和在401 Unauthorized响应中产生的NONCE相同，则通过。否则，直接返回失败。然后，MGC会根据NONCE、用户名、密码（服务器端可以根据本地用户信息获取用户的密码）、URI等采用和终端相同的算法生成RESPONSE，并且对此RESPONSE和请求消息中的RESPONSE进行比较，如果二者一致则用户认证成功，否则认证失败。此时，MGC返回200 OK响应消息，表明终端认证成功。

SIP/2.0 200 OK

From: <sip:6540012@191.169.150.30>;tag=16838c16838

To: <sip:6540012@191.169.150.30>;tag=946e6f96

CSeq: 2763 REGISTER

Call-ID: 1-reg@191.169.150.251

Via: SIP/2.0/UDP 191.169.150.251

Contact: <sip:6540012@191.169.150.251>;expires=3600

Content-Length: 0

3.3.2  成功的SIP用户呼叫流程

在同一SoftX3000控制下的两个SIP用户之间的成功呼叫，呼叫流程应用实例如图3-6所示。

在下面的实例中，我们基于以下约定：

l   SoftX3000的IP地址为191.169.200.61；

l   SIP PhoneA的IP地址为191.169.150.101；

l   SIP PhoneB的IP地址为191.169.150.100；

l   SIP PhoneA为主叫，SIP PhoneB为被叫，主叫先挂机；

l   SIP PhoneA的电话号码为1000，SIP PhoneB的电话号码为1001。

图3-6 SIP实体之间的SIP呼叫流程

(1)      事件1：SIP PhoneA发INVITE请求到MGC，请求MGC邀请SIP PhoneB加入会话。SIP PhoneA还通过INVITE消息的会话描述，将自身的IP地址：191.169.150.101，端口号：8766，静荷类型，静荷类型对应的编码等信息传送给MGC。

INVITE sip:1001@191.169.200.61 SIP/2.0

From: sip:1000@191.169.200.61;tag=1c12674

To: sip:1001@191.169.200.61

Call-Id: call-973598097-16@191.169.150.101

Cseq: 1 INVITE

Contact: sip:1000@191.169.150.101

Content-Type: application/sdp

Content-Length: 203

Accept-Language: en

Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE

Supported: sip-cc, sip-cc-01, timer

User-Agent: Pingtel/1.2.7 (VxWorks)

Via: SIP/2.0/UDP 191.169.150.101

v=0

o=Pingtel 5 5 IN IP4 191.169.150.101

s=phone-call

c=IN IP4 191.169.150.101

t=0 0

m=audio 8766 RTP/AVP 0 96 8

a=rtpmap:0 pcmu/8000/1

a=rtpmap:96 telephone-event/8000/1

a=rtpmap:8 pcma/8000/1

每行的详细解释请参考3.2.2  1.请求消息一节中的“请求消息示例”。

(2)      事件2：MGC给SIP PhoneA回100 Trying表示已经接收到请求消息，正在对其进行处理。

SIP/2.0 100 Trying

From: <sip:1000@191.169.200.61>;tag=1c12674

To: <sip:1001@191.169.200.61>

CSeq: 1 INVITE

Call-ID: call-973598097-16@191.169.150.101

Via: SIP/2.0/UDP 191.169.150.101

Content-Length: 0

(3)      事件3：MGC给SIP PhoneA发407 Proxy Authentication Required响应，表明MGC端要求对用户进行认证，并且通过Proxy-Authenticate字段携带MGC支持的认证方式Digest和MGC域名“huawei.com”，产生本次认证的nonce，并且通过该响应消息将这些参数返回给终端从而发起对用户的认证过程。

SIP/2.0 407 Proxy Authentication Required

From: <sip:1000@191.169.200.61>;tag=1c12674

To: <sip:1001@191.169.200.61>;tag=de40692f

CSeq: 1 INVITE

Call-ID: call-973598097-16@191.169.150.101

Via: SIP/2.0/UDP 191.169.150.101

Proxy-Authenticate: Digest realm="huawei.com",nonce="1056131458"

Content-Length: 0

(4)      事件4：SIP PhoneA发ACK消息给MGC，证实已经收到MGC对于INVITE请求的最终响应。

ACK sip:1001@191.169.200.61 SIP/2.0

Contact: sip:1000@191.169.150.101

From: <sip:1000@191.169.200.61>;tag=1c12674

To: <sip:1001@191.169.200.61>;tag=de40692f

Call-Id: call-973598097-16@191.169.150.101

Cseq: 1 ACK

Accept-Language: en

User-Agent: Pingtel/1.2.7 (VxWorks)

Via: SIP/2.0/UDP 191.169.150.101

Content-Length: 0

(5)      事件5：SIP PhoneA重新发INVITE请求到SoftX3000。携带 Proxy-Authorization字段，包括认证方式DIGEST、SIP Phone的用户标识（此时为电话号码）、MGC的域名、NONCE、URI和RESPONSE（SIP PhoneA收到407响应后根据服务器端返回的信息和用户配置等信息采用特定的算法生成加密的RESPONSE）字段。

INVITE sip:1001@191.169.200.61 SIP/2.0

From: sip:1000@191.169.200.61;tag=1c12674

To: sip:1001@191.169.200.61

Call-Id: call-973598097-16@191.169.150.101

Cseq: 2 INVITE

Contact: sip:1000@191.169.150.101

Content-Type: application/sdp

Content-Length: 203

Accept-Language: en

Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE

Supported: sip-cc, sip-cc-01, timer

User-Agent: Pingtel/1.2.7 (VxWorks)

Proxy-Authorization: DIGEST USERNAME="1000", REALM="huawei.com", NONCE="1056131458", RESPONSE="1b5d3b2a5441cd13c1f2e4d6a7d5074d", URI="sip:1001@191.169.200.61"

Via: SIP/2.0/UDP 191.169.150.101

v=0

o=Pingtel 5 5 IN IP4 191.169.150.101

s=phone-call

c=IN IP4 191.169.150.101

t=0 0

m=audio 8766 RTP/AVP 0 96 8

a=rtpmap:0 pcmu/8000/1

a=rtpmap:96 telephone-event/8000/1

a=rtpmap:8 pcma/8000/1

(6)      事件6：MGC给SIP PhoneA回100 Trying表示已经接收到请求消息，正在对其进行处理。

SIP/2.0 100 Trying

From: <sip:1000@191.169.200.61>;tag=1c12674

To: <sip:1001@191.169.200.61>

CSeq: 2 INVITE

Call-ID: call-973598097-16@191.169.150.101

Via: SIP/2.0/UDP 191.169.150.101

Content-Length: 0

(7)      事件7：MGC向SIP PhoneB发INVITE消息，请求SIP PhoneB加入会话。并且通过该INVITE请求消息携带SIP PhoneA的会话描述给SIP PhoneB。

INVITE sip:1001@191.169.150.100 SIP/2.0

From: <sip:1000@191.169.200.61>;tag=1fd84419

To: <sip:1001@191.169.150.100>

CSeq: 1 INVITE

Call-ID: 1746ac508a14feaaccb35e4a35ea1768@sx3000

Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bK8fd4310b0

Contact: <sip:1000@191.169.200.61:5061>

Supported: 100rel,100rel

Max-Forwards: 70

Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REGISTER,PRACK,INFO,UPDATE,SUBSCRIBE,NOTIFY,MESSAGE,REFER

Content-Length: 183

Content-Type: application/sdp

v=0

o=HuaweiSoftX3000 1073741833 1073741833 IN IP4 191.169.200.61

s=Sip Call

c=IN IP4 191.169.150.101

t=0 0

m=audio 8766 RTP/AVP 0 8

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

(8)      事件8：SIP PhoneB给MGC回100 Trying表示已经接收到请求消息，正在对其进行处理。

SIP/2.0 100 Trying

From: <sip:1000@191.169.200.61>;tag=1fd84419

To: <sip:1001@191.169.150.100>;tag=4239

Call-Id: 1746ac508a14feaaccb35e4a35ea1768@sx3000

Cseq: 1 INVITE

Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bK8fd4310b0

Contact: sip:1001@191.169.150.100

User-Agent: Pingtel/1.0.0 (VxWorks)

CONTENT-LENGTH: 0

(9)      事件9：SIP PhoneB振铃，并回180 Ringing响应通知MGC。

SIP/2.0 180 Ringing

From: <sip:1000@191.169.200.61>;tag=1fd84419

To: <sip:1001@191.169.150.100>;tag=4239

Call-Id: 1746ac508a14feaaccb35e4a35ea1768@sx3000

Cseq: 1 INVITE

Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bK8fd4310b0

Contact: sip:1001@191.169.150.100

User-Agent: Pingtel/1.0.0 (VxWorks)

CONTENT-LENGTH: 0

(10)   事件10：MGC回180 Ringing响应给SIP PhoneA，SIP PhoneA听回铃音。

SIP/2.0 180 Ringing

From: <sip:1000@191.169.200.61>;tag=1c12674

To: <sip:1001@191.169.200.61>;tag=e110e016

CSeq: 2 INVITE

Call-ID: call-973598097-16@191.169.150.101

Via: SIP/2.0/UDP 191.169.150.101

Contact: <sip:1001@191.169.200.61:5061;transport=udp>

Content-Length: 0

(11)   事件11：SIP PhoneB给MGC回200 OK响应表示其发过来的INVITE请求已经被成功接受、处理。并且通过该消息将自身的IP地址：191.169.150.101，端口号：8766，静荷类型，静荷类型对应的编码等信息传送给MGC。

SIP/2.0 200 OK

From: <sip:1000@191.169.200.61>;tag=1fd84419

To: <sip:1001@191.169.150.100>;tag=4239

Call-Id: 1746ac508a14feaaccb35e4a35ea1768@sx3000

Cseq: 1 INVITE

Content-Type: application/sdp

Content-Length: 164

Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bK8fd4310b0

Session-Expires: 36000

Contact: sip:1001@191.169.150.100

Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY

User-Agent: Pingtel/1.0.0 (VxWorks)

v=0

o=Pingtel 5 5 IN IP4 191.169.150.100

s=phone-call

c=IN IP4 191.169.150.100

t=0 0

m=audio 8766 RTP/AVP 0 8

a=rtpmap:0 pcmu/8000/1

a=rtpmap:8 pcma/8000/1

(12)   事件12：MGC给SIP PhoneA回200 OK响应表示其发过来的INVITE请求已经被成功接受、处理，并且将SIP PhoneB的会话描述传送给SIP PhoneA。

SIP/2.0 200 OK

From: <sip:1000@191.169.200.61>;tag=1c12674

To: <sip:1001@191.169.200.61>;tag=e110e016

CSeq: 2 INVITE

Call-ID: call-973598097-16@191.169.150.101

Via: SIP/2.0/UDP 191.169.150.101

Contact: <sip:1001@191.169.200.61:5061;transport=udp>

Content-Length: 183

Content-Type: application/sdp

v=0

o=HuaweiSoftX3000 1073741834 1073741834 IN IP4 191.169.200.61

s=Sip Call

c=IN IP4 191.169.150.100

t=0 0

m=audio 8766 RTP/AVP 0 8

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

(13)   事件13：SIP PhoneA发ACK消息给MGC，证实已经收到MGC对于INVITE请求的最终响应。

ACK sip:1001@191.169.200.61:5061;transport=UDP SIP/2.0

Contact: sip:1000@191.169.150.101

From: <sip:1000@191.169.200.61>;tag=1c12674

To: <sip:1001@191.169.200.61>;tag=e110e016

Call-Id: call-973598097-16@191.169.150.101

Cseq: 2 ACK

Accept-Language: en

User-Agent: Pingtel/1.2.7 (VxWorks)

Via: SIP/2.0/UDP 191.169.150.101

Content-Length: 0

(14)   事件14：MGC发ACK消息给SIP PhoneB，证实已经收到SIP PhoneB对于INVITE请求的最终响应。

此时，主被叫双方都知道了对方的会话描述，启动通话。

ACK sip:1001@191.169.150.100 SIP/2.0

From: <sip:1000@191.169.200.61>;tag=1fd84419

To: <sip:1001@191.169.150.100>;tag=4239

CSeq: 1 ACK

Call-ID: 1746ac508a14feaaccb35e4a35ea1768@sx3000

Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bK44cfc1f25

Max-Forwards: 70

Content-Length: 0

(15)   事件15：SIP PhoneA挂机，发BYE消息给MGC，请求结束本次会话。

BYE sip:1001@191.169.200.61:5061;transport=UDP SIP/2.0

From: sip:1000@191.169.200.61;tag=1c12674

To: sip:1001@191.169.200.61;tag=e110e016

Call-Id: call-973598097-16@191.169.150.101

Cseq: 4 BYE

Accept-Language: en

Supported: sip-cc, sip-cc-01, timer

User-Agent: Pingtel/1.2.7 (VxWorks)

Via: SIP/2.0/UDP 191.169.150.101

Content-Length: 0

(16)   事件16：MGC给SIP PhoneA回487响应，表明请求终止。

SIP/2.0 487 Request Terminated

From: <sip:1000@191.169.200.61>;tag=1c12674

To: <sip:1001@191.169.200.61>;tag=e110e016

CSeq: 4 BYE

Call-ID: call-973598097-16@191.169.150.101

Via: SIP/2.0/UDP 191.169.150.101

Content-Length: 0

(17)   事件17：MGC收到SIP PhoneA发过来的BYE消息，知道A已挂机，给SIP PhoneB发BYE请求，请求结束本次会话。

BYE sip:1001@191.169.150.100 SIP/2.0

From: <sip:1000@191.169.200.61>;tag=1fd84419

To: <sip:1001@191.169.150.100>;tag=4239

CSeq: 2 BYE

Call-ID: 1746ac508a14feaaccb35e4a35ea1768@sx3000

Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bKf5dbf00dd

Max-Forwards: 70

Content-Length: 0

(18)   事件18：SIP PhoneB挂机，给MGC反馈200 OK响应，表明已经成功结束会话。

SIP/2.0 200 OK

From: <sip:1000@191.169.200.61>;tag=1fd84419

To: <sip:1001@191.169.150.100>;tag=4239

Call-Id: 1746ac508a14feaaccb35e4a35ea1768@sx3000

Cseq: 2 BYE

Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bKf5dbf00dd

Contact: sip:1001@191.169.150.100

Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY

User-Agent: Pingtel/1.0.0 (VxWorks)

CONTENT-LENGTH: 0

3.3.3  成功的SIP中继呼叫流程

不同SoftX3000之间采用SIP协议进行互通，SIP中继的成功呼叫流程应用实例如图3-7所示。

在下面的实例中，我们基于以下约定：

l   SoftX3000A的IP地址为191.169.1.112；

l   SoftX3000B的IP地址为191.169.1.110；

l   SoftX3000A控制的SIP PhoneA的电话号码为66600003；

l   SoftX3000B控制的SIP PhoneB的电话号码为5550045；

l   SIP PhoneA为主叫、SIP PhoneB为被叫，被叫先挂机。

图3-7 SIP中继呼叫流程示例

(1)      事件1：SoftX3000A控制的SIP PhoneA摘机，拨打 SoftX3000B控制的SIP PhoneB。SoftX3000A向SoftX3000B发INVITE消息，邀请SoftX3000B加入会话。SoftX3000A还通过INVITE消息的会话描述，将自身的IP地址：191.169.200.61，SIP PhoneA的IP地址：191.169.200.101、端口号：30014、支持的静荷类型、静荷类型对应的编码等信息传送给SoftX3000B。

INVITE sip:5550045@191.169.100.50 SIP/2.0

From: <sip:66600003@191.169.200.61>;tag=64e3f587

To: <sip:5550045@191.169.100.50>

CSeq: 1 INVITE

Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000

Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bKff661c627

Contact: <sip:008675566600003@191.169.200.61:5061>

Supported: 100rel,100rel

Max-Forwards: 70

Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REGISTER,PRACK,INFO,UPDATE,SUBSCRIBE,NOTIFY,MESSAGE,REFER

Content-Length: 184

Content-Type: application/sdp

v=0

o=HuaweiSoftX3000 1073741831 1073741831 IN IP4 191.169.200.61

s=Sip Call

c=IN IP4 191.169.200.101

t=0 0

m=audio 30014 RTP/AVP 8 0

a=rtpmap:8 PCMA/8000

a=rtpmap:0 PCMU/8000

(2)      事件2：SoftX3000B给SoftX3000A回100 Trying表示已经接收到请求消息，正在对其进行处理。

SIP/2.0 100 Trying

From: <sip:66600003@191.169.200.61>;tag=64e3f587

To: <sip:5550045@191.169.100.50>

CSeq: 1 INVITE

Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000

Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bKff661c627

Content-Length: 0

(3)      事件3：SoftX3000B给SoftX3000A回180 Ringing响应通知SoftX3000A SIP PhoneB已振铃。

SIP/2.0 180 Ringing

From: <sip:66600003@191.169.200.61>;tag=64e3f587

To: <sip:5550045@191.169.100.50>;tag=2dc18caf

CSeq: 1 INVITE

Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000

Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bKff661c627

Contact: <sip:5550045@191.169.100.50:5061;transport=udp>

Content-Length: 0

(4)      事件4：SoftX3000B给SoftX3000A回200 OK响应表示其发过来的INVITE请求已经被成功接受、处理。并且通过该消息将自身的IP地址：191.169.100.50，SIP PhoneB的IP地址：191.169.100.71、端口号：40000、支持的静荷类型、静荷类型对应的编码等信息传送给SoftX3000A。

SIP/2.0 200 OK

From: <sip:66600003@191.169.200.61>;tag=64e3f587

To: <sip:5550045@191.169.100.50>;tag=2dc18caf

CSeq: 1 INVITE

Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000

Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bKff661c627

Contact: <sip:5550045@191.169.100.50:5061;transport=udp>

Content-Length: 159

Content-Type: application/sdp

v=0

o=HuaweiSoftX3000 1073741826 1073741826 IN IP4 191.169.100.50

s=Sip Call

c=IN IP4 191.169.100.71

t=0 0

m=audio 40000 RTP/AVP 0

a=rtpmap:0 PCMU/8000

(5)      事件5：SoftX3000A发ACK消息给SoftX3000B，证实已经收到SoftX3000B对于INVITE请求的最终响应。

ACK sip:5550045@191.169.100.50:5061;transport=udp SIP/2.0

From: <sip:66600003@191.169.200.61>;tag=64e3f587

To: <sip:5550045@191.169.100.50>;tag=2dc18caf

CSeq: 1 ACK

Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000

Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bK7d4f55f15

Max-Forwards: 70

Content-Length: 0

(6)      事件6：SIP PhoneB挂机，SoftX3000B发BYE请求消息给SoftX3000A，请求结束本次会话。

BYE sip:66600003@191.169.200.61:5061 SIP/2.0

From: <sip:5550045@191.169.100.50>;tag=2dc18caf

To: <sip:66600003@191.169.200.61>;tag=64e3f587

CSeq: 1 BYE

Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000

Via: SIP/2.0/UDP 191.169.100.50:5061;branch=z9hG4bK2a292692a

Max-Forwards: 70

Content-Length: 0

(7)      事件7：SoftX3000A给SoftX3000B回487响应，表明请求终止。

SIP/2.0 487 Request Terminated

From: <sip:5550045@191.169.100.50>;tag=2dc18caf

To: <sip:008675566600003@191.169.200.61>;tag=64e3f587

CSeq: 1 BYE

Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000

Via: SIP/2.0/UDP 191.169.100.50:5061;branch=z9hG4bK2a292692a

Content-Length: 0

3.3.4  成功的SIP-T中继呼叫流程

SIP-T并不是一个新的协议，它在SIP的基础上增加了关于如何实现SIP网络与PSTN网络互通的扩展机制，包括三种应用模型：PSTN-IP、IP-PSTN、PSTN-IP-PSTN。

SIP-T协议的特点：

l   封装：在SIP消息体中携带ISUP消息；

l   映射：ISUP-SIP消息映射，ISUP参数与SIP头域映射。SIP消息与ISUP信令之间的映射关系可简单描述为：

IAM = INVITE

ACM = 180 RINGING

ANM = 200 OK

RLS       = BYE

RLC       = 200 OK

下面以PSTN-IP-PSTN模型为例，简单介绍PSTN消息通过SIP-T消息透传的呼叫流程，SIP-T中继的成功呼叫流程应用实例如图3-8所示。

图3-8 成功的SIP-T呼叫流程（PSTN端－IP端－PSTN端）

(1)      事件1：主叫PSTN用户摘机拨号，通过SoftX3000A控制的SGA向MGC发送IAM消息。

SoftX3000A收到SGA发过来的IAM消息，将其封装到INVITE消息的消息体（SDP）中发送给SoftX3000B，邀请SoftX3000B加入会话。SoftX3000A还通过INVITE消息的会话描述，将SGA的IP地址：191.169.200.188、端口号：30014、支持的静荷类型、静荷类型对应的编码等信息传送给SoftX3000B。

(2)      事件2：SoftX3000B给SoftX3000A回100 Trying表示已经接收到请求消息，正在对其进行处理。

(3)      事件3：被叫PSTN用户振铃，同时，SGB送ACM消息给SoftX3000B，SoftX3000B收到ACM消息，将其封装到180 Ringing响应消息中发送给SoftX3000A。SoftX3000B还通过180 Ringing消息的会话描述，将SGB的IP地址：191.169.150.1、端口号：13304、支持的静荷类型、静荷类型对应的编码等信息传送给SoftX3000A。

SoftX3000A收到180 Ringing消息后，将ACM消息从180 Ringing消息中解析出来转发给SGA。SGA收到ACM消息，同时，主叫PSTN用户听回铃音。

(4)      事件4：被叫PSTN用户摘机，SGB送ANM消息给SoftX3000B，SoftX3000B收到ANM消息，将其封装到200 OK响应消息的消息体（SDP）中发送给SoftX3000A。

SoftX3000A收到200 OK消息，将ANM消息从200 OK消息中解析出来转发给SGA。

(5)      事件5：SoftX3000A发ACK消息给SoftX3000B，证实已经收到SoftX3000B对于INVITE请求的最终响应。

此时，就建立了一个双向的信令通路，双发可以进行通话。

(6)      事件6：主叫PSTN用户挂机，SGA发REL消息给SoftX3000A。SoftX3000A收到REL消息，将其封装到BYE请求消息的消息体（SDP）中，发送给SoftX3000B。

SoftX3000B收到BYE消息，将REL消息从BYE消息中解析出来转发给SGB。

(7)      事件7：SGB收到REL消息，知道主叫PSTN用户已挂机，转发该REL消息给PSTN交换机，PSTN交换机收到该消息，同时，给被叫PSTN用户送忙音。被叫PSTN用户挂机，SGB送RLC消息给SoftX3000B，SoftX3000B收到RLC消息，将其封装到200 OK响应消息的消息体（SDP）中发送给SoftX3000A。

SoftX3000A收到200 OK响应，将RLC消息从中解析出来转发给SGA。