Bob 的 SIP 电话接收到 INVITE,提醒 Bob 有来自 Alice 的电话,从而让 Bob 作出是否回
话的决定,即 Bob 的电话响铃。Bob 的 SIP 电话在 180(Ringing)响应中表明这一点,该
180(Ringing)响应是通过两个代理在不同的方向路由返回。每个代理使用 Via 头字段决定
向哪里发送响应,并从顶端移除其地址。尽管为了路由初始的 INVITE 需要查询 DNS 和位置
服务,但在向呼叫者返回 180(Ringing)响应时既不需要查询,也不需要在代理中保存状
态。这里也有期望的特性,即每个能看到 INVITE 的代理服务器也能看到该 INVITE 的所有响
应。
当 Alice 的软电话接收到 180(Ringing)响应,软电话通过回铃音或在 Alice 屏幕上
显示消息的方式将信息传递给 Alice。
本例中,Bob 决定回话。当 Bob 拿起手持设备时,他的 SIP 电话发送一个 200(OK)响
应,表明电话已接。200(OK)包含一个 Bob 愿意与 Alice 建立的会话类型的 SDP 媒体描述
的消息体。因此,这里有两个阶段的 SDP 消息交换:Alice 向 Bob 发送一个消息,Bob 向 Alice
返回一个消息。这两个阶段的交换提供了基本的协商能力,它是基于 SDP 交换的简单呼叫/
应答模型。如果 Bob 不愿回话,或者正忙于另一个呼叫,那么发送的将不是 200(OK)而是
一个错误响应,也就不会建立媒体会话。第 21 章描述了 SIP 响应代码的完整列表。200(OK)
的形式如图 1 消息 F9:
SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.com
;branch=z9hG4bKnashds8;received=192.0.2.3
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com
;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com
;branch=z9hG4bK776asdhds ;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
(Bob’s SDP not shown)
响应的第一行包含响应代码(200)和原因分析(OK)。剩余行包含头字段。Via、To、
From、Call-ID 和 Cseq 头字段都是从 INVITE 请求中拷贝的。(这里有三个 Via 头字段值—
—一个是 Alice 的 SIP 电话增加的,一个是代理服务器增加的,一个是 biloxi.com 代理增
加的。)Bob 的 SIP 电话向 To 头字段中增加了一个标签参数。对话的两个终端都会包含该标
签,并且在本呼叫的后续请求和响应中也会包含该标签。Contact 头字段中包含 Bob 的 SIP
电话可直接到达的 URI。Content-Type 和 Content-Length 是指包含 Bob SDP 媒体信息的消
息体。
除本例中 DNS 和位置服务查询外,代理服务器也可作出灵活的“路由选择决定”,决定
向哪里发送请求。例如,如果 Bob 的 SIP 电话返回一个 486(Busy here)响应,biloxi.com