sip会话流程以及sip介绍（2）

下面我们通过一个简单的场景例子来简单介绍一下 SIP 会话流程。

Tom 和 Jerry 是非常好的伙伴，Tom 在他的 PC 上使用一个 SIP 的应用程序呼叫 Internet 上另一个 SIP 电话用户 Jerry。

1. 注册过程 :

SIP 注册过程是建立用户当前 IP 地址与用户URI之间的对应关系。首先，Tom 和 Jerry 的 SIP 应用程序或者硬件设备，需要在网络中注册。之后终端需要知道代理呼叫会话控制功能（P-CSCF）的地址。P-CSCF 是终端向网络中发送所有 SIP 消息的惟一入口,用于 SIP 出站代理，注册完成后服务于所有其他 SIP 信令。该地址可以预先配置，在没有配置的情况下，终端可以在建立的通用或专用 PDP 信令上下文的过程中请求该地址。

Tom 的终端首先会生成一个 REGISTER 请求，该请求中的相关信息从 Tom 的用户标识模块 (USIM) 的 IP 多媒体服务标识模块（ISIM）中获取。请求经过 P-CSCF 和 I-CSCF（问询呼叫会话控制功能）为 Tom 指定一个 S-CSCF（服务呼叫会话控制功能）。S-CSCF 负责根据请求信息建立用户标识与终端 IP 地址的对应绑定关系。

清单 1. 构造的 REGISTER 消息

1 2 3 4 5 6 7 8 9 10 11 12 13 14

REGISTER sip: telcomx.tel.com SIP2.0 From:<sip: tom@telcomx.tel.com>;tag=pohjaxx To:<sip: tom@telcomx.com> Via:SIP/2.0/UDP[4444::2:3:4:5];branch=xo93sle Route: sip:[5555::a:f:f:e];lr Contact:<sip:[4444::2:3:4:5]>;expires=600000 Call-ID: apb304a94sslfeiasle93aj11 Authorization:Digest username="tom@telcomx.tel.com",              realm="telcomx.tel.com",              nonce="",              uri="sip:telcomx.tel.com",              response="" CSeq: 25 REGISTER Content-Length:0

该消息中 Route 标识请求路由的下一节点；Contact 中定义了 IP 地址与 SIP URI的绑定持续时间；Call-ID 和 CSeq 消息头惟一标识本次事务。注册消息经 P-CSCF 发送到 I-CSCF，I-CSCF 是 Tom 所在归属网的入口，接收 Tom 终端发起的每一次注册请求。I-CSCF 查询 HSS 服务器，根据请求中标识的需求能力，选择一个合适的 S-CSCF 为用户提供服务，并将请求发送到该 S-CSCF 节点上。

S-CSCF 返回 401（未授权）响应要求 Tom 进行认证，则 Tom 的终端将发送第二个 REGISTER 请求，第二个请求包含相同的有关注册信息，并经过的路由与第一个 REGISTER 的路由完全相同。但是第二个 REGISTER 产生一个新的 Call-ID、Cseq 号码、branch 参数以及一个新的 From 标签，并且该 REGISTER 请求会带入新的安全认证标签信息。

清单 2. 构造带有认证信息的 REGISTER 消息

1 2 3 4 5 6 7 8 9 10 11 12 13 14

REGISTER sip: telcomx.tel.com SIP2.0 From:<sip: tom@telcomx.com>;tag=6e87wa9 To:<sip: tom@telcomx.tel.com> Via:SIP/2.0/UDP[4444::2:3:4:5];branch=u2x9s7 Route: sip:[5555::a:f:f:e];lr Contact:<sip:[4444::2:3:4:5]>;expires=600000 Call-ID: apb304a94sslfaser2le93aj22 Authorization:Digest username="tom@telcomx.tel.com",              realm="telcomx.tel.com",              nonce="A34Cm+FVa73YTUGpGMBIs34P,algorithm=AKAv1-MD5",              uri="sip:telcomx.tel.com",              response="6629fac4969a87854152369874c43fd1" CSeq: 47 REGISTER Content-Length:0

注意，第二次注册请求会填写相应的认证密钥信息。认证过程成功，S-CSCF 将对 Tom 进行注册。即 S-CSCF 创建一个绑定关系，绑定 To 消息头中公共用户标识和 Contact 中的 IP 访问地址。随后 S-CSCF 向终端发送响应。

清单 3.REGISTER 消息的响应

1 2 3 4 5 6 7 8 9 10 11

SIP/2.0 200 OK Via:SIP/2.0/UDP icscf1.tel.com;branch=21ksi9 Via:SIP/2.0/UDP pcscf1.tel.com;branch=2x7as2 Via:SIP/2.0/UDP[4444::2:3:4:5];branch=u2x9s7 From:<sip: tom@telcomx.tel.com>;tag=6e87wa9 To:<sip: tom@telcomx.tel.com>;tag=kotimaex Contact:<sip:[4444::2:3:4:5]>;expires=600000 Service-Route:sip:telcomx@scscf1.tel.com;lr Call-ID: apb304a94sslfaser2le93aj22 CSeq: 47 REGISTER Content-Length:0

S-CSCF 将自己的访问地址通过 Service-Route 消息头返回给终端，该响应送回的路径是所有接收过 REGISTER 请求的 CSCF，因为各个 CSCF 在接收 REGISTER 时都把自己的地址放在了 Via 消息头的顶端。这时终端注册已经成功。

SIP 注册流程

2. 会话建立：

Tom 通过 Jerry 的 SIP 标识呼叫 Jerry，这个SIP URI 很像一个 E-mail 地址，典型的URI包括一个用户名和主机名。假设 Jerry 的URI为 sip: jerry@california.tel.com。主机名 california.tel.com 是 Jerry 的本地 SIP 服务供应商即 Jerry 的归属域。Tom 使用自己的URI发送请求。Tom 的统一资源标识符：sip: tom@telcomx.tel.com。其中 telcomx.tel.com 是 Tom 的 SIP 服务供应商。

建立会话的过程主要有以下几步：

(1)使用 Jerry 的URI创建 INVITE 请求；

(2)在 Contact 消息头中设置自己的访问 IP 地址与端口号，确保对端 Jerry 所有的响应都能直接发回到该终端；

(3)将注册过程中所存储的 S-CSCF 访问地址信息添加到消息的 Route 中，这样避免每次发送 SIP 请求需要通过 I-CSCF 查找 S-CSCF 的开销；

(4)将出站代理 P-CSCF 的访问地址也添加到 Route 消息头顶端生成消息路由；

(5)请求按照 Route 顶端地址发送到出站代理 P-CSCF 上，去除 Route 中标识自己的访问条目，在 Record-Route 和 Via 中添加 P-CSCF 访问条目，确保请求的响应路由能够返回到自身节点。转发 INVITE 请求到 Route 定义的下一个节点；

(6)请求发送到 S-CSCF 节点上，首先去除 Route 中标识自己的访问条目，将 S-CSCF 访问条目添加到 Record-Route 和 Via 中，查询 DNS 服务获得用户 Jerry 的 SIP URI 所归属的域，将请求转发到 Jerry 所归属域的 I-CSCF 节点上；

(7)在 Jerry 归属域的 I-CSCF 节点上，首先添加自己的访问条目并将该访问条目添加到 Via 消息头中，查询 SLF 获取 Jerry 的 HSS 服务器地址，并查询 HSS 获取与用户 Jerry 相绑定的 S-CSCF 节点访问地址，将 INVITE 请求转发到该 S-CSCF 节点上；

(8)请求到达 Jerry 归属域的 S-CSCF 节点上，首先从路由 Route 消息头中删除标识自己的访问条目，在 Record-Route 中添加该访问条目，将用户 Jerry 的统一资源标识符替换为注册的联系地址，转发请求到下一个节点；

(9)消息到达 Jerry 的 P-CSCF 代理节点上，其转发请到用户 Jerry 的 IP 地址上；

(109)这时 INVITE 请求已经到达用户 Jerry 的终端上，该终端设备保存 Tom 的 Contact 消息头，生成相应响应信息，并设置响应 Contact 消息头为 Jerry 终端的 IP 地址 / 端口，将 Record-Route 和 Via 消息头复制到响应中，并基于 Via 消息头发送响应；

(11)当响应到达用于 Tom 终端时，Tom 终端也会保存用户 Jerry 的 Contact 信息，这样双方都知道对方直接访问的 IP 地址和端口，之后可以直接发送请求到对方终端了。

SIP 会话建立路由过程

清单 4.INVITE 请求

1 2 3 4 5 6 7 8 9 10 11 12 13

INIVTE sip:jerry@california.tel.com  Via: SIP/2.0/UDP[4444::2:3:4:5];branch=8ulse1  Route:<sip:[5555::a:b:c:d];lr>  Route:<sip:telcomx@scscf1.tel.com;lr>  Contact:<sip:[4444::2:3:4:5]:1537>  From:<sip: tom@telcomx.tel.com>;tag=6e87wa9  To:<sip: jerry@california.tel.com>  Call-ID: apb03a0s09dkjdfoaidy49555  CSeq: 1 INVITE  Max-Forwards: 70  Content-Length:183 （必须的空行） （SDP 请求消息体）

清单 5. 183“会话进行中”响应

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

SIP/2.0 183 Session in Progress  Via: SIP/2.0/UDP scscf2.california.tel.com;branch=12fd3  Via: SIP/2.0/UDP icscf2.california.tel.com;branch=24re3  Via: SIP/2.0/UDP scscf1.tel.com;branch=64w32  Via: SIP/2.0/UDP pcscf1.tel.com;branch=412d2  Via: SIP/2.0/UDP[4444::2:3:4:5];branch=8ulse1  Route-Route:<sip pcscf2.california.tel.com;lr>  Route-Route:<sip scscf2.california.tel.com;lr>  Route-Route:<sip scscf1.tel.com;lr>  Route-Route:<sip pcscf1.tel.com;lr>  Route:<sip:telcomx@scscf1.tel.com;lr>  Contact:<sip:[4444:5:6:7:8]:1078>  From:<sip: jerry@california.tel.com>;tag=e42q14d  To:<sip: tom@telcomx.tel.com>;tag=6e87wa9  Call-ID: apb03a0s09dkjdfoaidy49555  CSeq: 2 183  Max-Forwards: 70  Content-Length:165 （必须的空行） （SDP 请求消息体）

Tom 发送 INVITE 请求后需要等待 Jerry 的响应，如果等待超时则需要重传一个 INVITE 请求，如果 128 秒后仍收不到响应，就宣告本次会话建立失败。例如本例中该呼叫漂洋过海，因此到达 Jerry 终端可能超过超时等待时间，为了避免 Tom 终端频繁地重发 INVITE 请求，P-CSCF 收到 INVITE 请求后，返回一个 100 Trying 临时响应。这表明现在开始 P-CSCF 负责 INVITE 的重传工作，以此类推。

SIP 会话信号流程图

3. 会话媒体参数协商：

Tom 终端在发送第一个 INVITE 请求中带有一个 SDP 的消息体，该消息体描述 Tom 希望在本次会话中使用的所有媒体参数信息，包括媒体类型、各类媒体支持的编码解码类型；在 Jerry 终端的第一个响应中会带入 INVITE 请求的 SDP 消息体应答，可能拒绝某些提议的媒体类型，缩减媒体编码解码类型，仅剩下双方都支持的编码解码。Tom 终端收到第一个应答后，其必须最终决定使用哪种编码解码类型，并给被叫方发送 PRACK 消息，将第二个 SDP 媒体协商参数消息发出，确定在本次会话中每种媒体类型采用的惟一编码解码类型。Jerry 终端接受第二次提议并返回一个确认应答。

会话协商信号流程图

通过会话媒体协商，双方商定最终使用的媒体参数建立媒体连接，实现通话。

4. 会话的释放：

Tom 和 Jerry 通话完毕，这是 Jerry 会按下终端设备的红色挂机按钮断掉呼叫。这使他的终端生成一个 BYE 请求，沿着与其他请求相同的路由发送给 Tom 的终端，同时还会释放本次会话建立的媒体 PDP 上下文。Tom 的终端收到该请求后也会立刻释放它的 PDP 上下文，同时向 Jerry 终端返回一个 200(OK) 的响应来应答 BYE 请求。注意路径的 CSCF 和所有的 AS 都会清除与本次会话有关的所有会话状态和信息。

清单 6. BYE 请求

1 2 3 4 5 6 7 8 9 10 11

BYE sip:[4444::2:3:4:5] SIP/2.0 Route:<sip:pcscf2.california.com;lr> Route:<sip:scscf2.california.com;lr> Route:<sip:scscf1.tel.com;lr> Route:<sip:pcscf1.tel.com;lr> To:<sip: tom@telcomx.tel.com>;tag=6e87wa9 From:<sip: jerry@california.tel.com> Call-ID: w273alskdjb732s07yad22 CSeq: 15 BYE Max-Forwards: 70 Content-Length:0

从上述报文可以看到 From 和 To 消息头的信息互换了，因为本次消息是从用户 Jerry 一方发出的。

SIP 会话释放流程图