目 录
第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-5 3.2 协议消息.. 3-6 3.2.1 消息类型.. 3-6 3.2.2 消息结构.. 3-9 3.3 基本消息流程.. 3-22 3.3.1 SIP用户注册流程.. 3-22
3.3.2 成功的SIP用户呼叫流程.. 3-25 3.3.3 成功的SIP中继呼叫流程.. 3-33 3.3.4 成功的SIP-T中继呼叫流程.. 3-36
第3章 SIP协议 3.1 概述
3.1.1 基本概念
会话启动协议SIP（Session InitiationProtocol）是由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（MultipointControl Unit）、单播联网方式、或组播方式创建多方会话，支持PSTN和因特网电话之间的网关功能。
SIP协议可以与其他用于建立呼叫的信令系统或协议结合使用，它在设计上充分考虑了对其他协议的可扩展性。譬如，SIP协议支持的主叫可以识别出H.323协议支持的被叫，通过H.245网关利用H.225.0协议向被叫发起并建立呼叫；另外，一个SIP主叫可以识别出PSTN上的被叫及其电话号码，通过与PSTN相连的网关向被叫发起并建立呼叫。 SIP协议不提供发言控制（floorcontrol）、投票等会议控制功能，也不规定如何管理一个会议。但是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 ResourceLocators），按照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、Stateful和CallStateful，其可以采用分支、循环等方式向多个地址尝试转发请求。
代理服务器的主要功能：路由、认证鉴权、计费监控、呼叫控制、业务提供等。在华为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（ResourceReServation Protocol）用于预约网络资源，RTP（Real-time TransmitProtocol）用于传输实时数据并提供服务质量（QoS）反馈，RTSP（Real-TimeStream Protocol）用于控制实时媒体流的传输，SAP（SessionAnnouncement Protocol）用于通过组播发布多媒体会话，SDP（Session DescriptionProtocol）用于描述多媒体会话。但是SIP协议的功能和实施并不依赖这些协议。
传输层支持：SIP协议承载在IP网，网络层协议为IP，传输层协议可用TCP或UDP，推荐首选UDP。
3.1.4 SIP协议的应用
SoftX3000通过SIP/SIP-T与其它软交换系统互通，以及与其它SIP域设备（如SIP Phone，SIPSoftphone等）互通，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 请求消息 请求消
消息含义
息
发起会话请求，邀请用户加入一个会话，会话描述含于消息体中。对于两方呼叫来说，主叫方在会话描述中指示其能够接受的媒体类型及其参数。被叫方必需在成功响应消息的消息体中指明其希望接受哪些
INVITE
媒体，还可以指示其行将发送的媒体。 如果收到的是关于参加会议的邀请，被叫方可以根据Call-ID或者会话描述中的标识确定用户已经加入该会议，并返回成功响应消息。 证实已收到对于INVITE请求的最终响应。该消息仅和INVITE消息配
ACK
套使用。
BYE 结束会话
取消尚未完成的请求，对于已完成的请求（即已收到最终响应的请求）
CANCEL
则没有影响
REGISTER 注册
OPTIONS 查询服务器的能力
2. 响应消息
用于对请求消息进行响应，指示呼叫的成功或失败状态。不同类的响应消息由状态码来区分。状态码包含三位整数，状态码的第一位用于定义响应类型，另外两位用于进一步对响应进行
更加详细的说明。各响应消息分类和含义如表3-2所示。 表3-2 响应消息 序
状态码 消息功能 号
信息响应（呼叫进展
响应） 1xx
100 180 181 182 2xx
成功响应 200 重定向响应 300 301 3xx 302
303 305 380
客户出错 400 401 402 403 404 405 406 407 408 410 4xx 413
414 415 416 420 421 423 480 481 482 483 484 485
表示已经接收到请求消息，正在对其进行处理
试呼叫 振铃 呼叫正在前转 排队 表示请求已经被成功接受、处理 OK 表示需要采取进一步动作，以完成该请求 多重选择 永久迁移 临时迁移 见其它 使用代理 代换服务
表示请求消息中包含语法错误或者SIP服务器不能完成对该请求消息的处理 错误请求 无权 要求付款 禁止 没有发现 不允许的方法 不接受 要求代理权 请求超时 消失
请求实体太大 请求URI太大
不支持的媒体类型 不支持的URI方案 分机无人接听 要求转机 间隔太短 暂时无人接听
呼叫腿/事务不存在 相环探测 跳频太高 地址不完整 不清楚
序
状态码 消息功能 号
486 线路忙 487 终止请求 488 此处不接受 491 代处理请求 493 难以辨认 服务器出错 表示SIP服务器故障不能完成对正确消息的处理 500 内部服务器错误 501 没实现的 502 无效网关 5xx
503 不提供此服务 504 服务器超时 505 SIP版本不支持 513 消息太长 全局故障 表示请求不能在任何SIP服务器上实现 600 全忙 6xx 603 拒绝
604 都不存在 606 不接受
请求消息和响应消息都包括SIP头字段和SIP消息字段。 在SIP消息中加入SDP消息正文部分。 3.2.2 消息结构 1. 请求消息
(1) 请求消息结构
如图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:显示名
其中，显示名为用户界面上显示的字符，如果系统不予显示，应置显示名为“匿名(Anonymous)”。显示名为任选字段。tag称为标记，为16进制数字串，中间可带连字符“-”。当两个共享同一SIP地址的用户实例用相同的Call-ID发起呼叫邀请时，就需用此标记予以区分。标记值必须全局唯一。用户在整个呼叫期间应保持相同的Call-ID和标记值。 From字段的示例：
From:
该字段指明请求的接收者，其格式和From相同，仅第一个关键词代之以To。所有请求和响应消息必须包含此字段。
字段中的标记参数可用于区分由同一SIP URL标识的不同的用户实例。由于代理服务器可以并行分发多个请求，同一请求可能到达用户的不同实例（如住宅电话等）。由于每个实例都可能响应，因此需用标记来区分来自不同实例的响应。需要注意的是，To字段中的标记是由每个实例至于响应消息中的。 To字段的示例：
To:
To:
注意，在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/UDPsoftx3000.bell-telephone.com:5060 Via:SIP/2.0/UDP10.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:
该字段用于定义一个请求到达其目的地址所允许经过的中转站的最大值。请求每经过一个中转站，该值减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=\REALM=\3112b21ad3b6\
(3) 请求消息示例
下面是SIP请求消息编码的示例：
INVITE sip:66500002@191.169.1.110SIP/2.0
From:
Call-ID:20973e49f7c52937fc6be224f9e52543@sx3000
Via: SIP/2.0/UDP191.169.1.116:5061;branch=z9hG4bkbc427dad6 Contact:
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 INIP4 191.169.1.116 s: SipCall
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字段。指明请求发起方的地址为“
第三行：To字段。指明请求接收方的地址为“
IP地址为191.169.1.116的SoftX3000控制下的终端44510000拨打IP地址为191.169.1.110的SoftX3000控制下的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”表示发送方SoftX3000IP地址为191.169.1.116，端口号为5061；“branch=z9hG4bkbc427dad6”为分支参数，SoftX3000并行分发请求时标记各个分支。
第七行：Contact字段。指示其后的请求（如BYE请求）可以直接发往
第八行：100rel扩展，该字段为100类响应消息的可靠传输提供了相应的机制。
第九行：Max-Forwards字段。表示该请求到达其目的地址所允许经过的中转站的最大值为70。
第十行：Allow字段。给出IP地址为191.169.1.116的SoftX3000支持的请求消息类型列表。 第十一～十二行：Content-Length字段，表示消息长度为230个字节。
第十三行：Content-Type字段，表示消息中携带的消息体是单消息体且为SDP。 第十四行：空行，表示下面为SDP会话描述。 第十五行：SDP协议版本号，目前为0版本。
第十六行：会话拥有者/创建者和会话标识，用于给出会话的发起者（其用户名和用户主机地址）以及会话标识和会话版本号。“HuaweiSoftX3000”为用户名，用户名是用户在发起主机上的登录名，如果主机不支持用户标识的概念，该字段标记为“-”。第一个“1073741831”为会话标识，会话标识为一数字串，使得多元组（用户名、会话标识、网络类型、地址类型、地址）构成会话的全球唯一的标识符。第二个“1073741831”为版本号，指该会话公告的版本。供代理服务器检测同一会话的若干个公告哪一个是最新的公告。其基本要求是会话数据修改后，其版本号应递增。“IN”指网络类型，为文本串形式，目前规定的“IN”为Internet。“IP4”指地址类型，为文本串形式，目前已定义的有“IP4”和“IP6”两种。“191.169.1.116”为创建会话的主机的IP地址。对于IP4地址类型，可以是域名全称或点分十进制IP4地址表示形式。对于IP6地址类型，可以是域名全称或压缩文本IP6地址表示形式。 第十七行：会话名。每个会话描述必需有一个且只有一个会话名。
第十八行：连接数据。网络类型和地址类型目前的定义值仅限于IN和IP4。“191.169.1.95”为SoftX3000（IP地址：191.169.1.116）控制下的终端的IP地址（终端类型为SIP、H.323电话或IAD/AG下挂的ESL电话）。 第十九行：时间描述，给出会话激活的时间区段，允许会话周期性发生。 “0”表示起始时间。该字段的格式为t：<起始时间><终止时间>。其中起始时间和终止时间值为NTP（Network TimeProtocol）时间值的十进制表示，单位为秒。
第二十行：媒体级描述，该部分给出只适用于该媒体流的信息。“audio”表示媒体类型为音频。目前定义的媒体类型有5种：音频、视频、应用、数据和控制。“30000”指明媒体流发往的传送层端口，即终端的UDP端口号（终端类型为SIP、H.323电话或IAD/AG下挂的ESL电话）。“RTP/AVP”为传送层协议，其值和“c”行中的地址类型有关，对于IP4来说，大多数媒体业务流都在RTP/UDP上传送，已定义如下两类协议：RTP/AVP，音频/视频应用文档，在UDP上传送；Udp，UDP协议。“80 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:
Call-ID:20973e49f7c52937fc6be224f9e52543@sx3000
Via: SIP/2.0/UDP191.169.1.116:5061;branch=z9hG4bkbc427dad6 Require:100rel RSeq:1
Contact:
Content-Type:application/sdp v=0
o=HuaweisoftX3000 1073741824 1073741824 INIP4 191.169.1.110 s=SipCall
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字段相同，均为“1INVITE”，表明该响应消息由上文中的请求消息触发。
第五～第十一行：请参考“请求消息示例”小节。 第十二行：空行，表示下面为SDP会话描述。 第十三行：SDP协议版本号，目前为0版本。
第十四行：会话拥有者/创建者和会话标识，用于给出会话的发起者（其用户名和用户主机地址）以及会话标识和会话版本号。“HuaweiSoftX3000”为用户名，用户名是用户在发起主机上的登录名，如果主机不支持用户标识的概念，该字段标记为“-”。第一个“1073741824”为会话标识，会话标识为一数字串，使得多元组（用户名、会话标识、网络类型、地址类型、地址）构成会话的全球唯一的标识符。第二个“1073741824”为版本号，指该会话公告的版本。供代理服务器检测同一会话的若干个公告哪一个是最新的公告。其基本要求是会话数据修改后，其版本号应递增。“IN”指网络类型，为文本串形式，目前规定的“IN”为Internet。“IP4”指地址类型，为文本串形式，目前已定义的有“IP4”和“IP6”两种。“191.169.1.110”为创建会话的主机的IP地址。
第十五行：会话名。每个会话描述必需有一个且只有一个会话名。
第十六行：连接数据。网络类型和地址类型目前的定义值仅限于IN和IP4。“191.169.1.135”为SoftX3000（IP地址：191.169.1.110）控制下的终端的IP地址（终端类型为SIP、H.323电话或IAD/AG下挂的ESL电话）。
第十七行：时间描述，给出会话激活的时间区段，允许会话周期性发生。
第十八行：媒体级描述，该部分给出只适用于该媒体流的信息。“audio”表示媒体类型为音频。“30016”指明媒体流发往的传送层端口，即终端的UDP端口号（终端类型为SIP、H.323电话或IAD/AG下挂的ESL电话）。“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发起注册请求，汇报其已经开机或重启动。下面是
Register请求消息编码的示例。 REGISTER sip:191.169.150.30SIP/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/UDP191.169.150.251
第一行：请求起始行。REGISTER请求消息。表示终端向IP地址为191.169.150.30的SoftX3000发起登记。SIP版本号为2.0。
第二行：From字段。指明该REGISTER请求消息由SoftX3000（IP地址：191.169.150.30）控制的SIP Phone发起的。
第三行：To字段。指明REGISTER请求接收方的地址。此时REGISTER请求的接收方为IP地址为191.169.150.30的SoftX3000。
第四行：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返回401Unauthorized（无权）响应，表明SoftX3000端要求对用户进行认证，并且通过WWW-Authenticate字段携带SoftX3000支持的认证方式Digest和SoftX3000域名“huawei.com”，产生本次认证的nonce，并且通过该响应消息将这些参数返回给终端从而发起对用户的认证过程。 SIP/2.0 401 Unauthorized
From:
Call-ID: 1-reg@191.169.150.251 Via: SIP/2.0/UDP191.169.150.251
WWW-Authenticate: Digest realm=\Content-Length: 0
(3) 事件3：SIP Phone重新向SoftX3000发起注册请求，携带Authorization字段，包括认证方式DIGEST、SIP Phone的用户标识（此时为电话号码）、SoftX3000的域名、NONCE、URI和RESPONSE（SIP Phone收到401Unauthorized响应后根据服务器端返回的信息和用户配置等信息采用特定的算法生成加密的RESPONSE）字段。下面是Register请求消息编码的示例： REGISTER sip:191.169.150.30SIP/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: DIGESTUSERNAME=\REALM=\3112b21ad3b6\Via: SIP/2.0/UDP191.169.150.251
(4) 事件4：SoftX3000收到SIP Phone的注册请求，首先检查NONCE的正确性，如果和在401Unauthorized响应中产生的NONCE相同，则通过。否则，直接返回失败。然后，SoftX3000会根据NONCE、用户名、密码（服务器端可以根据本地用户信息获取用户的密码）、URI等采用和终端相同的算法生成RESPONSE，并且对此RESPONSE和请求消息中的RESPONSE进行比较，如果二者一致则用户认证成功，否则认证失败。此时，SoftX3000返回200 OK响应消息，表明终端认证成功。 SIP/2.0 200 OK
From:
Call-ID: 1-reg@191.169.150.251 Via: SIP/2.0/UDP191.169.150.251
Contact:
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请求到SoftX3000，请求SoftX3000邀请SIP PhoneB加入会话。SIP PhoneA还通过INVITE消息的会话描述，将自身的IP地址：191.169.150.101，端口号：8766，静荷类型，静荷类型对应的编码等信息传送给SoftX3000。 INVITE sip:1001@191.169.200.61SIP/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/UDP191.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：SoftX3000给SIP PhoneA回100Trying表示已经接收到请求消息，正在对其进行处理。
SIP/2.0 100 Trying
From:
Call-ID: call-973598097-16@191.169.150.101 Via: SIP/2.0/UDP191.169.150.101 Content-Length: 0
(3) 事件3：SoftX3000给SIP PhoneA发407Proxy Authentication Required响应，表明SoftX3000端要求对用户进行认证，并且通过Proxy-Authenticate字段携带SoftX3000支持的认证方式Digest和SoftX3000域名“huawei.com”，产生本次认证的nonce，并且通过该响应消息将这些参数返回给终端从而发起对用户的认证过程。 SIP/2.0 407 Proxy Authentication Required
From:
CSeq: 1 INVITE
Call-ID: call-973598097-16@191.169.150.101 Via: SIP/2.0/UDP191.169.150.101
Proxy-Authenticate: Digestrealm=\Content-Length: 0
(4) 事件4：SIP PhoneA发ACK消息给SoftX3000，证实已经收到SoftX3000对于INVITE请求的最终响应。
ACK sip:1001@191.169.200.61SIP/2.0 Contact: sip:1000@191.169.150.101
From:
Accept-Language: en
User-Agent: Pingtel/1.2.7 (VxWorks) Via: SIP/2.0/UDP191.169.150.101 Content-Length: 0
(5) 事件5：SIP PhoneA重新发INVITE请求到SoftX3000。携带Proxy-Authorization字段，包括认证方式DIGEST、SIP Phone的用户标识（此时为电话号码）、SoftX3000的域名、NONCE、URI和RESPONSE（SIP PhoneA收到407响应后根据服务器端返回的信息和用户配置等信息采用特定的算法生成加密的RESPONSE）字段。 INVITE sip:1001@191.169.200.61SIP/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: DIGESTUSERNAME=\REALM=\d\Via: SIP/2.0/UDP191.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：SoftX3000给SIP PhoneA回100Trying表示已经接收到请求消息，正在对其进行处理。
SIP/2.0 100 Trying
From:
Call-ID: call-973598097-16@191.169.150.101 Via: SIP/2.0/UDP191.169.150.101 Content-Length: 0
(7) 事件7：SoftX3000向SIP PhoneB发INVITE消息，请求SIP PhoneB加入会话。并且通过该INVITE请求消息携带SIP PhoneA的会话描述给SIP PhoneB。 INVITE sip:1001@191.169.150.100SIP/2.0
From:
Call-ID:1746ac508a14feaaccb35e4a35ea1768@sx3000
Via: SIP/2.0/UDP191.169.200.61:5061;branch=z9hG4bK8fd4310b0 Contact:
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 INIP4 191.169.200.61 s=SipCall
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给SoftX3000回100Trying表示已经接收到请求消息，正在对其进行处理。
SIP/2.0 100 Trying
From:
Call-Id:1746ac508a14feaaccb35e4a35ea1768@sx3000 Cseq: 1 INVITE
Via: SIP/2.0/UDP191.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振铃，并回180Ringing响应通知SoftX3000。 SIP/2.0 180 Ringing
From:
Call-Id:1746ac508a14feaaccb35e4a35ea1768@sx3000 Cseq: 1 INVITE
Via: SIP/2.0/UDP191.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：SoftX3000回180Ringing响应给SIP PhoneA，SIP PhoneA听回铃音。 SIP/2.0 180 Ringing
From:
Call-ID: call-973598097-16@191.169.150.101 Via: SIP/2.0/UDP191.169.150.101
Contact:
(11) 事件11：SIP PhoneB给SoftX3000回200OK响应表示其发过来的INVITE请求已经被成功接受、处理。并且通过该消息将自身的IP地址：191.169.150.101，端口号：8766，静荷类型，静荷类型对应的编码等信息传送给SoftX3000。 SIP/2.0 200 OK
From:
Call-Id:1746ac508a14feaaccb35e4a35ea1768@sx3000 Cseq: 1 INVITE
Content-Type: application/sdp Content-Length: 164
Via: SIP/2.0/UDP191.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：SoftX3000给SIP PhoneA回200OK响应表示其发过来的INVITE请求已经被成功接受、处理，并且将SIP PhoneB的会话描述传送给SIP PhoneA。 SIP/2.0 200 OK
From:
Call-ID: call-973598097-16@191.169.150.101 Via: SIP/2.0/UDP191.169.150.101
Contact:
Content-Type: application/sdp v=0
o=HuaweiSoftX3000 1073741834 1073741834 INIP4 191.169.200.61 s=SipCall
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消息给SoftX3000，证实已经收到SoftX3000对于INVITE请求的最终响应。
ACK sip:1001@191.169.200.61:5061;transport=UDPSIP/2.0 Contact: sip:1000@191.169.150.101
From:
Accept-Language: en
User-Agent: Pingtel/1.2.7 (VxWorks) Via: SIP/2.0/UDP191.169.150.101 Content-Length: 0
(14) 事件14：SoftX3000发ACK消息给SIP PhoneB，证实已经收到SIP PhoneB对于INVITE请求的最终响应。
此时，主被叫双方都知道了对方的会话描述，启动通话。 ACK sip:1001@191.169.150.100SIP/2.0
From:
Call-ID:1746ac508a14feaaccb35e4a35ea1768@sx3000
Via: SIP/2.0/UDP191.169.200.61:5061;branch=z9hG4bK44cfc1f25 Max-Forwards: 70
Content-Length: 0
(15) 事件15：SIP PhoneA挂机，发BYE消息给SoftX3000，请求结束本次会话。 BYE sip:1001@191.169.200.61:5061;transport=UDPSIP/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/UDP191.169.150.101 Content-Length: 0
(16) 事件16：SoftX3000给SIP PhoneA回487响应，表明请求终止。 SIP/2.0 487 Request Terminated
From:
Call-ID: call-973598097-16@191.169.150.101 Via: SIP/2.0/UDP191.169.150.101 Content-Length: 0
(17) 事件17：SoftX3000收到SIP PhoneA发过来的BYE消息，知道A已挂机，给SIP PhoneB发BYE请求，请求结束本次会话。 BYE sip:1001@191.169.150.100SIP/2.0
From:
Call-ID:1746ac508a14feaaccb35e4a35ea1768@sx3000
Via: SIP/2.0/UDP191.169.200.61:5061;branch=z9hG4bKf5dbf00dd Max-Forwards: 70 Content-Length: 0
(18) 事件18：SIP PhoneB挂机，给SoftX3000反馈200OK响应，表明已经成功结束会话。 SIP/2.0 200 OK
From:
Call-Id:1746ac508a14feaaccb35e4a35ea1768@sx3000 Cseq: 2 BYE
Via: SIP/2.0/UDP191.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.50SIP/2.0
From:
Call-ID:9e62b921769c9ae546ed4329a3c04182@sx3000
Via: SIP/2.0/UDP191.169.200.61:5061;branch=z9hG4bKff661c627 Contact:
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 INIP4 191.169.200.61 s=SipCall
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回100Trying表示已经接收到请求消息，正在对其进行处理。
SIP/2.0 100 Trying
From:
Call-ID:9e62b921769c9ae546ed4329a3c04182@sx3000
Via: SIP/2.0/UDP191.169.200.61:5061;branch=z9hG4bKff661c627 Content-Length: 0
(3) 事件3：SoftX3000B给SoftX3000A回180Ringing响应通知SoftX3000A SIPPhoneB已振铃。
SIP/2.0 180 Ringing
From:
Call-ID:9e62b921769c9ae546ed4329a3c04182@sx3000
Via: SIP/2.0/UDP191.169.200.61:5061;branch=z9hG4bKff661c627 Contact:
(4) 事件4：SoftX3000B给SoftX3000A回200OK响应表示其发过来的INVITE请求已经被成功接受、处理。并且通过该消息将自身的IP地址：191.169.100.50，SIP PhoneB的IP地址：191.169.100.71、端口号：40000、支持的静荷类型、静荷类型对应的编码等信息传送给SoftX3000A。 SIP/2.0 200 OK
From:
Call-ID:9e62b921769c9ae546ed4329a3c04182@sx3000
Via: SIP/2.0/UDP191.169.200.61:5061;branch=z9hG4bKff661c627 Contact:
Content-Type: application/sdp v=0
o=HuaweiSoftX3000 1073741826 1073741826 INIP4 191.169.100.50 s=SipCall
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=udpSIP/2.0 From:
Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000
Via: SIP/2.0/UDP191.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:5061SIP/2.0 From:
Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000
Via: SIP/2.0/UDP191.169.100.50:5061;branch=z9hG4bK2a292692a Max-Forwards: 70 Content-Length: 0
(7) 事件7：SoftX3000A给SoftX3000B回487响应，表明请求终止。 SIP/2.0 487 Request Terminated
From:
To:
Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000
Via: SIP/2.0/UDP191.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向SoftX3000A发送IAM消息。
SoftX3000A收到SGA发过来的IAM消息，将其封装到INVITE消息的消息体（SDP）中发送给SoftX3000B，邀请SoftX3000B加入会话。SoftX3000A还通过INVITE消息的会话描述，将SGA的IP地址：191.169.200.188、端口号：30014、支持的静荷类型、静荷类型对应的编码等信息传送给SoftX3000B。
(2) 事件2：SoftX3000B给SoftX3000A回100Trying表示已经接收到请求消息，正在对其进行处理。
(3) 事件3：被叫PSTN用户振铃，同时，SGB送ACM消息给SoftX3000B，SoftX3000B收到ACM消息，将其封装到180Ringing响应消息中发送给SoftX3000A。SoftX3000B还通过180Ringing消息的会话描述，将SGB的IP地址：191.169.150.1、端口号：13304、支持的静荷类型、静荷类型对应的编码等信息传送给SoftX3000A。 SoftX3000A收到180Ringing消息后，将ACM消息从180 Ringing消息中解析出来转发给SGA。SGA收到ACM消息，同时，主叫PSTN用户听回铃音。
(4) 事件4：被叫PSTN用户摘机，SGB送ANM消息给SoftX3000B，SoftX3000B收到ANM消息，将其封装到200OK响应消息的消息体（SDP）中发送给SoftX3000A。
SoftX3000A收到200OK消息，将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消息，将其封装到200OK响应消息的消息体（SDP）中发送给SoftX3000A。
SoftX3000A收到200OK响应，将RLC消息从中解析出来转发给SGA。