WebSphere Application Server V6.1 中的会话发起协议——第 1 部分:SIP 简介

核心提示： SIP 消息将传递给 ibm.com 的本地 SIP 代理，ibm.com 的 SIP 代理必须定位 example.com 服务器，WebSphere Application Server V6.1 中的会话发起协议——第 1 部分:SIP 简介(4)，以将请求转发到 example.com，

SIP 消息将传递给 ibm.com 的本地 SIP 代理。ibm.com 的 SIP 代理必须定位 example.com 服务器，以将请求转发到 example.com。进行此任务的首选方法请参见 RFC 3263 的“Locating SIP Servers”中的描述。在此标准中描述了使用 Domain Name System (DNS) Naming Authority Pointer (NAPTR) 记录来定位 SIP 服务器的一种方法，此方法与使用 SMTP 路由邮件的方法类似。ibm.com 服务器将查找 example.com 的 NAPTR 记录，并将 INVITE 消息转发给 example.com 服务器。

ibm.com 代理发送了 INVITE 后，代理将发送一个临时响应或信息响应。在此场景中，服务器可以发送响应代码为 100 的 Trying 响应。在这种特殊的情况下，Trying 响应向客户机指示 ibm.com 代理已接受连接，将尝试把请求发送到下一个位置。服务器使用这些 1xx 响应（称为临时响应）来指示 SIP 事务的进度。在 RFC 3262 中，开发了一项机制来确保可靠地发送消息，且仅为确认目的而发送，以便在使用 UDP 之类的传输协议时不会丢失呼叫状态。

example.com 代理接收到 INVITE 消息后，example.com 服务器通常会使用整个统一资源标识符 (URI) 来查找用户所在的位置，或查找提供用于发起连接的准确 IP 地址的注册中心。在此例中，user@example.com 定义了要邀请到此会话中的特定用户。当用户位于网络地址转换（Network Address Translation，NAT）防火墙后时，通常使用 Simple Traversal of UDP through NATs (STUN)、Traversal Using Relay NAT (TURN) 和 Interactive Connectivity Establishment (ICE) Firewall 遍历机制来创建从 example.com 服务器到客户机的连接。建立了到客户机的连接后，服务器将向客户机发送 INVITE 消息，并向发送该消息的客户机回发一个临时响应 (Trying)。