SIP：基础知识及延伸 -

2007年3月9日
第5卷，第2期

SIP 基础知识及延伸

SIP 不仅仅是一个简单的电话应用协议，它还是一个用于开发通信系统的框架。

什么是 SIP？它有什么用途？

Robert Sparks，Estacado Systems

您很可能已经在使用 SIP（会话发起协议）。它是推动当前通信系统演进的关键创新之一。它的首要用途是在互联网电话中进行信令传输。大型运营商已经在其网络内部使用 SIP 多年，用于互连和长途干线传输。如果您拨打过长途电话，那么该通话的某些部分可能使用了 SIP。

最近，SIP 通过各种看起来和行为都很像电话（但只有以太网接口）的设备以及 Vonage 等服务提供商进入了最终用户的手中，这些服务提供商通过任何现有的互联网连接提供电话服务。下一代移动电话将使用 SIP 作为主要信令技术。SIP 的用途不仅限于电话：它已被用作即时消息 (IM) 和状态 (presence) 的基础技术。

SIP 带来的优势

在传统的电路交换系统中，电话基本上需要具有相同的功能集。连接到电话的机制是基于它们位于特定固定段铜线的末端。在新兴的基于互联网的系统中，用户可以在任何时间将电话连接到互联网上的任何位置，并立即可以被联系到。该电话可以具有广泛的功能，包括许多不同的编解码器（语音编码算法）、对双向视频、IM，甚至可能文件共享的支持。在这种环境中，人们希望进行实时交互式通信的选择要丰富得多。

SIP 解决了建立这些实时通信会话中的两个基本问题。首先，它帮助想要通信的双方在互联网上找到彼此（会合）。然后，它允许双方协商他们将如何通信（会话协商）。今天运行的系统中的大多数协商都产生语音会话，但没有什么可以阻止协商 IM 会话甚至在线游戏。

SIP 是由 IETF（互联网工程任务组）开发的开放标准。¹ 它拥有庞大而活跃的实现社区。在最近的 SIP 论坛 SIPit（SIP 互操作性测试）活动中，几乎每次都有 100 个独特的实现。这些活动不仅提高了各个实现的质量，而且还使我们能够改进规范并在问题场景影响实际部署之前发现它们。

SIP 为开发通信系统提供了一个框架。它不仅仅是一个简单的电话应用协议。它正被用于构建点对点系统、住宅电话服务、PBX 替代系统和大型运营商下一代网络，例如 3GPP（第三代合作伙伴计划）的 IMS（IP 多媒体子系统）（参见 http://www.3gpp.org/）。

SIP 的工作原理

SIP 是一种面向事务、基于文本的协议。它的消息在语法上与 HTTP 类似，但在协议行为方面几乎没有相似之处。SIP 端点，也称为 UA（用户代理），可以生成和应答请求。大多数 SIP 服务器（注册服务器、网关、语音邮件服务器）都是端点。唯一明确定义的非端点 SIP 元素是代理。一个元素可以同时扮演多个角色。通常，代理和注册服务器位于同一位置。代理/注册服务器在处理注册时是端点，在转发请求时是中介（代理/注册服务器通常被称为代理）。SIP 消息可以使用多种传输协议（例如 UDP 或 TCP）传输，并且给定消息在通过代理转发时可以在传输协议之间切换。SIP 本身定义了事务级状态机和定时器，这些状态机和定时器调用重传，以便在可能丢失数据包的 UDP 等传输协议上提供可靠性。

在最简单的情况下，两个端点可以直接交换 SIP 消息。然而，在当前部署的系统中，端点之间的大多数信令都涉及一个或多个 SIP 代理。图 1 显示了在基本架构中建立会话的开始阶段。请注意，SIP 信令和媒体独立地遍历网络。语音和视频媒体使用 RTP（实时传输协议）传输。²

会合是通过这些代理/注册服务器建立的，并且基于用户拥有众所周知的 AoR（记录地址）。SIP AoR 看起来很像电子邮件地址（例如，sip:[email protected]）。AoR 可以放在名片或网页上。在图 2 中，Robert 在 example.net 注册了 SIP 服务（使用 DNS 查找它们），建立了他的 AoR 与他的电话插入酒店网络时获得的临时 IP 地址之间的绑定。当 Phil 想要与 Robert 通话时，他只需要知道 Robert 的 AoR。Phil 的邀请到达负责该 AoR 的服务（再次使用 DNS），该服务重新定向并将请求转发到注册的联系人，使该电话铃响。

可以向一个 AoR 注册多个端点。当收到针对该 AoR 的请求时，可以将其转发到所有端点。为 AoR 提供服务的代理在确定使用每个绑定联系人的顺序方面具有很大的灵活性。在许多已部署的服务中，它会简单地将请求同时转发到每个联系人（并行分叉）。在其他服务中，它会一次尝试一个联系人，在前一个联系人超时后再尝试第二个联系人（串行分叉）。分叉是 SIP 会合功能的主要力量来源。它也是协议中最复杂性的来源。

在图 3 中，Robert 有四个联系人绑定到他的 AoR：两个是通过我们已经描述的注册过程，另外两个（一个 PSTN 网关和一个语音邮件服务）是通过配置。Phil 给 Robert 的呼叫同时使 Robert 的所有三部电话和他的语音邮件服务器（配置为等待几秒钟，然后发送将应答呼叫的响应）响铃。当 Robert 接听他的手机时，代理取消了对其他两部电话和语音邮件服务器的邀请，导致它们停止响铃。

一般来说，当代理分叉一个请求时，它负责收集来自每个分支的响应，并选择最佳响应返回给原始请求者。传达有助于请求者稍后成功的响应（例如凭据质询）比不传达的响应（例如“忙”）是更好的选择。成功响应始终是最佳选择。事实上，如果多个分支对会话邀请返回成功，则代理必须将所有这些响应返回给请求者。这种特殊情况是设计使然——目标是避免有人拿起电话却只听到无声，因为某些代理做出了任意选择。在这种情况下，端点必须同时处理多个呼叫。它可以选择其中一个响应来继续通话，并显式终止与另一个响应者的会话。或者，它可能会将所有响应者混合到一个临时的本地会议中。

一旦会合过程将请求发送到正确的位置，端点就会进入会话中将交换的媒体类型的协商。这是通过在 SIP 消息中携带一个单独的协议（称为 SDP（会话描述协议）³）并执行提供-应答交换来完成的。

提供指示提供者希望如何接收媒体。它描述了协议、媒体类型、编解码器、地址和端口。应答说明了应答者希望接收的媒体的类似信息，列出了其自身的地址和端口。应答者从提供中选择项目，接受一些媒体流，拒绝其他媒体流。第一个成功的提供-应答交换建立一个会话。额外的提供-应答交换可以修改该会话（更改编解码器或将流置于保持状态）。图 4 中的消息体包含一个简单的提供，用于在 pc33.atlanta.example.com 上的端口 49172 接收 G.711 编码的媒体。

SIP URI

图 2 中使用的 AoR 是 SIP URI 的一个示例：sip:[email protected]。用户名部分标识 @ 符号后出现的域中的资源。DNS 用于将域名转换为要使用的传输协议（例如 TCP）、端口和 IP 地址。RFC 3263 定义了协调所涉及的 DNS 查询。⁴ 简而言之，@ 符号后的名称与 NAPTR（命名权威指针）查询一起使用，以确定要使用的传输协议。然后，结果在 SRV（服务）查询中使用，以确定端口和要使用的特定服务器的名称。该名称在 A（或 IPv6 的 AAAA）查询中使用，以查找该服务器的 IP 地址。每个查询都可以返回多个结果，并且有指定的算法按顺序处理它们。特别是 SRV 结果将包含影响负载平衡和故障转移的参数。也可以将传输协议、端口和地址直接编码到 URI 中，并且当端点获得没有关联 DNS 资源记录的临时地址时，必须这样做。

SIP URI 出现在 SIP 消息的多个位置。请求第一行的 RURI（请求 URI）（见图 4）决定了请求将要发送到的位置。本质上，这是请求的目标对象。代理可以在转发请求时通过更改 RURI 来重定向请求。

To 和 From URI 是混淆的来源。如果 RURI 确定了请求的目标对象，那么 To 的含义是什么？最初，To 标头字段旨在携带请求最初的目标对象（以防某个代理在 RURI 到达最终目的地之前重新定向了它）。From 标头字段旨在标识谁发送了请求。然而，由于一系列决策，包括代理的指定行为方式，将原始含义归因于这些字段变得不安全。端点可以将他们想要的任何内容放在那里，中介可以欺骗并更改值。任何基于对这些字段中感知身份的处理都可能很容易被颠覆。在没有协议扩展的情况下，最好将它们视为不透明的位。有一些扩展，特别是 SIP 身份标头字段，⁵ 进行了加密断言，使这些字段，特别是 From 标头字段恢复了一些含义。

此消息中的 Contact URI 告诉接收者在此消息可能建立的对话中将来的请求的目标位置。一旦会合发生，代理可能会退出路径，端点可以直接交换其余的 SIP 信令。（有关这种情况如何发生的更多详细信息，请参见 RFC 3261 对 Route 和 Record-Route 的讨论。）

某些 URI 可能是 GRUU（全局可路由用户代理 URI）。⁶ 这些 URI 与 AoR 类似，因为它们是长期存在的——它们可以放在名片或电子邮件签名中。它们与 AoR 的不同之处在于，它们路由到完全一个端点。端点可以在注册期间获得 GRUU。GRUU 的一个重要动机是解决呼叫转移问题。图 5 显示了 Jean 正在将 Phil 转移给 Robert 的过程。之前，Phil 打电话给 Jean，她决定他需要与 Robert 通话。她让 Phil 保持通话状态，并致电 Robert，在他的家庭电话中联系到他。现在她需要告诉 Phil 的端点 (UA) 呼叫 Robert。如果她告诉 Phil 的 UA 使用 Robert 的 AoR，Phil 的呼叫将分叉到 Robert 的办公桌、家庭电话和语音邮件（Robert 的家庭电话可能会返回“忙”，因此 Phil 最终会进入语音邮件）。如果她告诉 Phil 的 UA 使用她和 Robert 正在共享的对话中的联系 URI，Phil 的邀请可能会路由失败（该 URI 可能指示 NAT（网络地址转换器）后面的地址，或者可能仅在 Jean 呼叫 Robert 建立的路由的上下文中有效）。Robert 家庭电话的 GRUU 是必需的。

图 6 显示了 Robert 的家庭 UA 获取 GRUU 并将其作为他们呼叫的一部分提供给 Jean。Jean 将 Phil 转介到该 GRUU。Phil 的呼叫准确地路由到 Robert 的家庭 UA，并带有足够的信息，让 UA 知道此呼叫正在替换它当前与 Jean 的呼叫。

SIP 如何改进实时通信

通过提供会合和协商任意实时会话的能力，SIP 实现了广泛的新通信应用。重现传统电话呼叫的概念是第一步，而不是最终目标。SIP 还提供了一种称为 SIP 事件的发布-订阅机制，使元素能够了解网络中其他位置的状态变化。例如，服务可以订阅 UA 的对话状态，以了解其何时可用，从而轻松构建驻留或回叫服务。然而，当前最强大的事件是状态 (presence)。⁷ 此事件由 IETF 的 SIMPLE 工作组（用于即时消息和状态利用扩展的 SIP）定义，传达有关最终用户的可用性和通信意愿的信息。此 RPID（丰富状态信息）的范围从用户所在的位置（地理位置）到他或她正在做的事情（例如，驾驶、开会或吃饭），甚至到他或她所处的环境类型（例如电影院）。想要通信的人可以使用此信息来选择最合适的时间和机制。

假设 Jean 想要让 Robert 知道会议日程的更改。她订阅了 Robert 的状态。Robert 的 SIP 状态服务器可以访问他的日历并报告 Robert 当前在飞机上。她决定打电话并留言，Robert 的 SIP 语音邮件服务器收集留言，将其转换为音频文件，并通过电子邮件发送给他。

稍后，Phil 需要让 Robert 和 Jean 都参与通话，以讨论会议议程。Phil 调用一项服务，该服务订阅他们三人的状态。当他们都在一个理智的时间都可用时，该服务会向他们每个人发送一条 SIP 即时消息，告知他们现在可以进行通话。如果他们都回复他们愿意，则该服务会呼叫他们每个人并将他们加入会议。Jean 使用她笔记本电脑上的 SIP 用户代理软件接听电话。在通话期间，她需要带领小组浏览幻灯片。Robert 和 Phil 让他们的工作站加入，并使用 SIP re-INVITE，Jean 向会议添加了 MSRP（消息会话中继协议⁸）媒体流。

一个青年足球队的家长并非都拥有 SIP 电话，他们可以使用相同的自动会议应用程序。教练需要召集所有家长讨论即将到来的异地比赛的旅行事宜。一些家长拥有 SIP 电话，范围从在他们的家用计算机上运行的软件到简单的模拟终端适配器，这些适配器随 ISP 服务一起提供，使他们能够将旧的 PSTN（公共交换电话网络）电话与 SIP 一起使用。一些家长只是订阅了 PSTN 网关服务，该服务允许 SIP 呼叫者通过他们的手机联系到他们。一些家长的 UA 直接发布状态，服务提供商根据各种启发式方法推断其他家长的可用性。当足够数量的家长显示可用时，自动会议系统将呼叫他们。

这些示例利用了几个重要的架构构造。首先，SIP 用户代理和服务器是功能齐全的互联网设备，可以轻松集成任何其他互联网技术或应用程序来完成工作。这允许利用较低级别的基础设施以及较高级别的应用程序，例如日历和电子邮件。例如，SIP 已经使用了 DNS 中的高级功能，这些功能有助于高可用性，允许端点自动连接到服务器集群中的不同元素。其他路由技术（例如任播）可以在 SIP 下方使用以提供冗余。

其次，SIP 是用于开发通信应用程序的框架。它允许将应用程序分发到任意元素，包括端点。一家企业可以集成来自一家供应商的状态服务器和来自另一家供应商的语音邮件服务器。他们甚至可以使用一家供应商的应用程序服务器和第二家供应商的媒体服务器构建自己的语音邮件服务。尽管早期的许多努力都集中在以服务提供商模型定义和部署 SIP 上，但该框架允许许多其他模型。IETF 内的一个社区正在定义以对等方式使用 SIP（这项工作被称为 P2PSIP，并且很可能在不久的将来成为一个工作组；有关更多信息，请参见 David Bryan 在第 34 页上的文章）。

最后，SIP 被设计为自愈的。正在运行的系统中的几乎所有状态更改都是“软”的——它们是在有限的、协商的生命周期内创建的，必须刷新，否则它们会自行消失。在刷新周期内，使用 SIP 的系统将适应意外的部分网络中断或计划的大规模管理更改的意外副作用。

当前问题

任何不断发展的协议都会有一些粗糙的边缘。SIP 正通过扩展和澄清不断改进。目前，围绕以下方面存在重要的活动：使实时通信通过 NAT 工作、保护信令和媒体通道、处理多个早期媒体流，以及确保正确的信息到位以提供紧急服务呼叫。

通过 NAT 进行通信。 SIP 在分散在消息中的几个字段中携带信令和媒体的路由信息。特别是对于媒体，这些字段经常携带显式的 IP 地址和端口。NAT 后面的 SIP 端点将发送带有其私有地址和未映射端口的消息，这些地址和端口对于不在同一 NAT 后面的其他端点来说都是无用的。此外，大多数 NAT（和防火墙）将阻止传入的 TCP 连接和 UDP 流量，这些流量与传出的 UDP 流量建立的临时针孔不一致。因此，仅实现基本协议的 SIP 端点在 NAT 后面工作时将需要外部帮助。

这种帮助可以以 NAT 内部的 ALG（应用层网关）的形式出现。SIP 感知的 ALG 可以深入到消息中，查找提到内部地址或端口的位置，并“修复”它们以匹配外部的内容。这可以（并且已经）在最简单的场景中工作，但 SIP 是一个框架协议，而不是单个应用程序。新的用途经常出现，如果 ALG 不知道新用途的细微差别，它通常会阻止成功的信令。

相同想法的更强大版本是在 NAT 或防火墙点上背靠背放置一对用户代理，终止和重新发起两侧的信令和媒体。这为中间元素（通常称为 B2BUA 或会话边界控制器）提供了在边界点移动 SIP 和媒体方面的灵活性。这些设备在最近的部署中很受欢迎，以解决策略控制和互操作性问题。然而，同样，B2BUA 必须在允许任何新的协议功能和行为通过之前学习它们。

使 NAT 遍历对于端点更轻松的扩展工作正在顺利进行中。STUN（NAT 下穿越的简单方式）协议⁹ 已经可用几年，并且被 SIP 端点广泛使用，以发现其 IP 地址和端口在 NAT 的另一侧看起来是什么样子（然后端点可以将其外部地址放在所有正确的位置，牺牲与同一 NAT 后面的其他端点通话的能力）。TURN 协议（最近称为 STUN 中继）¹⁰ 允许 SIP 端点与具有公共可路由地址的设备建立连接，请求该设备上的地址和端口，并将其所有流量中继到该绑定的公共地址和端口中。ICE（交互式连接建立）框架¹¹ 允许端点相互通告其所有可能的地址，并定义一种算法来查找有效的地址。

结合使用 STUN、TURN 和 ICE 的端点可以与同一 NAT 后面的其他端点、其他 NAT 后面的端点或开放互联网中的端点进行通信。TURN 和 ICE 分别处于 IETF 的 BEHAVE 和 MMUSIC 工作组的标准开发的最后阶段。

在最坏的情况下，端点可能会发现自己位于阻止所有传入流量的防火墙或 NAT 后面。只有属于端点打开的 TCP 流的数据包才能通过。SIP 出站扩展提供了一种机制，允许端点与该 NAT 或防火墙另一侧的第一跳代理建立一组长期连接，并指示所有发往该端点的 SIP 流量都必须通过这些连接进入。GRUU 扩展与 SIP 出站结合使用，通过在服务提供商处提供一个 URI，该 URI 充当 AoR，但仅路由到此端点（因此使用出站连接）。

使用 STUN 的 SIP 今天已广泛部署。支持 TURN 和 ICE（同时使用 TURN 和 STUN）的端点才刚刚出现。截至本文撰写之时，可用的 SIP 出站实现非常少，但预计在 2007 年春季的下一次 SIPit 活动中会有更多实现。

早期媒体。 SIP 的初始设计在会话邀请（INVITE 请求）中携带提供，并在接受该提供的消息（200 OK）中携带应答。在这些位置提供和应答的情况下，仅当会话被接受时才交换媒体。传统的 PSTN 允许在呼叫完成之前传输媒体。这用于向呼叫者播放振铃声，甚至用于与 IVR（交互式语音应答）和公告系统交互。

为了促进 SIP 和 PSTN 系统的集成，已向 SIP 添加了几个扩展，以支持早期媒体的概念。INVITE 事务允许在事务的最终响应之前存在任意数量的临时信息性响应，但如果基本协议跨越任何 UDP 跳跃，则不能确保它们的可靠传递。100rel 扩展使用一种新方法 PRACK 添加了这种可靠性，以确认收到临时响应。第二个扩展 UPDATE 允许请求者在 INVITE 等待最终响应时更改会话。

这些架构修改带来了力量，尽管它们可能使如何在 SIP 和传统 PSTN 之间构建网关变得更加明显，但它们为基本 SIP 端点引入了相当多的复杂性。一旦包含提供的 INVITE 分叉到多个位置，它们中的每一个都可能开始流式传输早期媒体。请求电话现在必须决定要向用户呈现哪个流（或找到某种明智的方式来呈现所有流）。这类似于如前所述的多个端点应答，但更具普遍性。

当转发对 INVITE 的 200 OK 最终响应时，代理将尝试取消任何其他振铃分支。拥有多个分支应答的唯一方法是失去竞争条件，即第二个电话在代理的取消到达之前应答。失去此竞争的可能性存在于以毫秒为单位的时间段内。然而，对于早期媒体，代理取消分支是没有意义的。如果请求分叉，则多个早期媒体流很可能成为常态。此外，很难分辨哪个早期媒体流属于哪个临时响应。保护媒体流的工作应该会改善这种情况。

最后，即使没有分叉，早期媒体也带来了特殊的考虑条件。一些大型机构已与电话运营商安排，在呼叫者与他们的语音菜单系统交互、收集帐号、选择部门或进行对该机构有意义的任何工作时，使呼叫保持振铃状态。只有当呼叫者开始与人交谈时，呼叫才会完成（在许多情况下，例如大型信用卡公司和航空公司，预计这种情况只会发生在很小一部分呼叫中）。SIP 网关、SIP 电话以及它们之间的代理必须预料到将呼叫（更具体地说是 INVITE 事务）长时间（以十分钟为单位）保持在这种振铃、未完成状态。在此期间，端点需要允许用户发送媒体，尤其是 DTMF 数字。

保护信令和媒体。 SIP 信令可以通过使用安全传输协议（例如 TLS（传输层安全性）或 DTLS（数据报 TLS））逐跳保护。这些传输协议确保第三方既不能读取也不能更改跨越该跳的消息。如果消息必须跨越多个跳，则可以单独保护每个跳。实际上，一个名为“sips”的配套 URI 方案旨在向请求路径上的每个代理发出信号，表明只能使用 TLS 跳。然而，与 https URI 方案不同，每个跳之间的代理可以完全访问并更改消息的内容。sips 的有效性在 IETF 内受到质疑。当前标准允许在某些条件下使用 TLS 以外的传输类型，并且没有办法验证节点是否作弊（或无意中以不安全的方式违反了协议）。

SIP 消息中对路由不重要的部分可以使用 S/MIME 进行端到端加密。例如，这将允许在端点之间交换提供和应答，而无需让代理看到会话协商的详细信息。不幸的是，很少有使用 S/MIME 的 SIP 实现可用。

保护信令还意味着保护其免受拒绝服务攻击。IETF 的 SIP 工作组正在完成对协议的修复，以消除在 SIPit 测试活动中发现的攻击，该攻击允许攻击者利用分叉来刺激大量流量——可能达到 270 条消息的量级——只需发送两个请求。¹²

许多努力都投入到保护媒体通道中，并且正在评估许多替代方案。最古老的是 SRTP（安全实时传输协议）。这是一个框架，允许使用各种密码系统来加密和完整性保护 RTP 数据包的有效载荷。这些系统依赖于密钥材料的安全交换。围绕保护媒体的许多讨论都集中在如何执行此密钥交换上。其他竞争者包括通过 DTLS 而不是 UDP 传输 RTP，以及一种完全使用媒体通道设置媒体安全的方法，该方法由 PGP 的 Phil Zimmerman 倡导。由于解决此问题的方法如此之多，因此随机选择的两个实现不太可能具有通用的媒体安全机制。

推动解决这些可部署性问题的一个重要因素是 IM 甚至 VoIP（有时称为 SPIM 和 SPIT）上的垃圾邮件类活动的迫在眉睫的威胁。到目前为止，针对这些不受欢迎的侵扰的最佳保护措施是基于以下几点：提供强大的发送者身份，例如 SIP 身份提供的身份；保护信令，使身份更难篡改；以及保护媒体，以便可以就向最终用户呈现哪些媒体流做出准确的决定。

紧急服务。 传统 PSTN 网络中的紧急服务提供商利用了多项功能和假设，但这些功能和假设并未延续到互联网电话中。最值得注意的是，他们利用了呼叫电话位于固定的、已配置的铜线末端的特性（后来演变为位于相对静态配置的 PBX 端口或特定无线蜂窝小区附近）。在互联网上，没有这种便利来识别呼叫位置。多年的工作已经投入到提供必要的扩展，以区分紧急服务呼叫与其他呼叫，以不会侵犯隐私的方式呈现呼叫者的位置，并构建过渡元素，以便可以继续使用当前的系统。

在 IETF 中，这项工作正在 ECRIT 和 GEOPRIV 工作组中进行。对于北美，国家紧急号码协会 (http://www.nena.org) 提供了当前在提供紧急服务方面所涉及问题的摘要，并推动了构建新系统的大部分工作。情况并不像一些大众媒体文章喜欢呈现的那样糟糕，但基于 SIP 的互联网电话系统的用户需要了解其当前系统的局限性。

摘要

SIP 已成为实时通信系统的基本构建块。它已被部署，用户基础正在迅速增长。简单的电话率先将其推入网络，但这只是基于 SIP 构建的应用冰山一角。 SIP 提供的灵活框架正在激发新的想法，并实现更好的通信体验，但与交换电话网络面临的问题相比，它带来了一组不同的问题需要解决。

SIP 是一项开放标准，围绕它形成的开发社区致力于高水平的互操作性。 IETF 和其他一些组织正在开放论坛中努力进一步增强功能并解决已知问题。如果本文引起了您的兴趣，请加入这些讨论。问

参考文献

Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., Schooler, E. 2002. SIP: 会话发起协议, RFC 3261.
Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V. 2003. RTP: 实时应用传输协议. STD 64, RFC 3550 (7 月).
Handley, M., Jacobson, V., Perkins, C. 2006. SDP: 会话描述协议, RFC 4566 (7 月).
Rosenberg, J., Schulzrinne, H. 2002. 会话发起协议 (SIP)：定位 SIP 服务器, RFC 3263 (6 月).
Peterson, J., Jennings, C. 2006. 会话发起协议 (SIP) 中经过身份验证的身份管理增强功能, RFC 4474 (8 月).
Rosenberg, J. 2006. 在会话发起协议 (SIP) 中获取和使用全局可路由用户代理 (UA) URI (GRUU), draft-ietf-sip-gruu-11 (正在进行的工作，10 月).
Rosenberg, J. 2004. 会话发起协议 (SIP) 的 presence 事件包, RFC 3856 (8 月).
Campbell, B. 2006. 消息会话中继协议, draft-ietf-simple-message-sessions-16 (正在进行的工作，10 月).
Rosenberg, J. 2006. 简单穿越网络地址转换器 (NAT) (STUN), draft-ietf-behave-rfc3489bis-05 (正在进行的工作，10 月).
Rosenberg, J. 2006. 从简单穿越 NAT (STUN) 获取中继地址, draft-ietf-behave-turn-02 (正在进行的工作，10 月).
Rosenberg, J. 2006. 交互式连接建立 (ICE)：用于提供/应答协议的网络地址转换器 (NAT) 穿越方法, draft-ietf-mmusic-ice-12 (正在进行的工作，10 月).
Sparks, R. 2006. 解决会话发起协议 (SIP) 分叉代理中的放大漏洞, draft-ietf-sip-fork-loop-fix-04 (正在进行的工作，10 月).

SIP 词汇表

SIP 通过扩展和澄清不断改进。

Robert Sparks，Estacado Systems

3GPP (第三代合作伙伴计划)：多个电话标准组织之间的合作，旨在制定 GSM 无线电话网络演进的标准。

AoR (记录地址)：用户的众所周知的地址，适合印在名片上。在 SIP 中，这是一个 URI（参见 SIP URI），例如 sip:[email protected]。

B2BUA (背靠背用户代理)：与 SIP 代理不同，它终止并重新发起 SIP 信令和媒体的中介。对于给定的呼叫，它的行为类似于内部耦合的两个端点。当这些端点跨越策略执行点（例如防火墙）时，B2BUA 通常被称为会话边界控制器 (SBC)。

Branch: SIP 消息在设备之间的“跳”，例如在代理之间或在代理和端点之间。当请求分叉时，离开代理的每个副本都会形成一个单独的分支。

Codec (媒体编码器/解码器)：编解码器是用于创建媒体传输流内部音频、视频或其他媒体表示形式的算法。

Dialog: 在 SIP 端点之间创建的关联，用于对与呼叫或订阅相关的 SIP 消息进行分组。

Dialog usage: 在对话中端点之间形成的关联，用于保留特定于特定应用程序的信息。目前，有两种对话使用类型：用于呼叫的会话使用和用于订阅的订阅使用。

DTMF (双音多频) 数字：按下 1 时得到的内容。 DTMF 是标准 16 键键盘按键（大多数电话仅公开 12 个键，省略 A、B、C 和 D）的编码，通过为每行和每列赋予唯一的频率来创建。如果编解码器可以重现这些频率，则 VoIP 系统可以在媒体中带内传输实际音调。或者，可以使用 RFC 2833 中定义的特殊 telephone-events 媒体类型来传输按下的数字，而无需使用音调。

Early media: 在呼叫完成之前交换的媒体。早期媒体的范围可以从铃声到与交互式语音应答系统的整个交互。

ECRIT (使用互联网技术的紧急上下文解析)：IETF 工作组，负责研究使用 SIP 等技术提供紧急服务电话呼叫所涉及的一些技术问题。

Endpoint: 终止 SIP 信令并且通常终止媒体的互联网设备。端点可能看起来像电话，或者可能是高密度语音邮件服务器。

Forking: 将 SIP 请求转发到多个目的地的过程。这可以按顺序完成（串行分叉）或同时完成（并行分叉）。分叉允许在呼叫给定用户时多个电话响铃。

Gateway: 将 SIP 转换为其他实时通信协议的设备。通常，这是用于将 SIP 网络连接到 PSTN 的 SIP 到 ISUP 网关。

GEOPRIV (地理位置/隐私)：IETF 工作组，负责开发一种表达地理位置和权限策略的方法，该方法允许用户声明其位置以及谁可以查看该位置。

IETF (互联网工程任务组)：负责开发和维护互联网协议的开放标准机构。

IMS (互联网协议多媒体子系统)：3GPP 架构的组件，用于提供下一代 GSM 无线电话服务。 IMS 将传统和新兴的互联网服务带入蜂窝世界。

Media: 实时通信的内容。这可以是语音、视频、即时消息或作为实时会话一部分交换的任何其他信息流。

Offer-answer: 关于如何通信的协商。 offer 携带使用 SDP 的会话描述。 answer 携带另一个会话描述，该描述选择除 offer 中通信方式之外的其他通信方式。在给定的对话中，任何时候都只能有一个 outstanding 的 offer。

Peer-to-peer SIP (P2PSIP)：几乎没有或没有“网络内”基础设施的 SIP 系统。汇集功能由端点通过分布式哈希表等技术提供，而不是使用集中式代理/注册器。 IETF 正在考虑成立一个工作组来标准化对等 SIP。

Provisional responses: 在最终接受或拒绝响应之前，对进入会话的邀请（INVITE 请求）的 SIP 响应。 Provisional responses 通常指示远程端正在“振铃”，但可用于设置早期媒体会话。

Proxy: 转发 SIP 请求的中介。通常，SIP 代理与注册器结合使用以提供汇集功能。

Registrar: 管理长期存在的众所周知的 AoR 与端点连接到网络时获得的临时联系地址之间绑定的 SIP 服务器。

Rendezvous: 两个端点找到彼此以建立实时通信的过程。

Retargeting: 在将 SIP 请求转发到代理时更改其目标（请求 URI）。通常，重新定位是作为汇集过程的一部分执行的。

RTP (实时传输协议)：用于在端点之间传输媒体的协议。 RTP 数据包包含时间戳、一些序列数据和一段编码媒体。 RTP 接收器使用这些信息来重建媒体流，准确地考虑数据包延迟、抖动和丢失。

SBC (会话边界控制器)：请参阅 B2BUA。

SDP (会话描述协议)：用于描述会话中要使用的媒体类型的格式，包括编解码器、编解码器参数以及媒体流的目标 IP 地址和端口。 SDP 用于建立或修改实时通信会话的 offer-answer 交换中。

SIGCOMP (信令压缩)：用于使用任意压缩算法压缩信令消息（例如 SIP）的框架。 SIGCOMP 在事件相对不频繁但对延迟敏感的环境（例如无线电话）中特别有用。

Signaling: 用于建立实时通信的控制通道。 SIP 是一种信令协议。信令建立单独的媒体通道。

SIMPLE (用于即时消息和 presence 扩展的 SIP)：IETF 工作组，创建 SIP 和配套协议的扩展，以促进构建即时消息和 presence 系统。 SIMPLE 定义了 SIP Events “presence”事件包、富 Presence 信息数据 (RPID) 格式、用于建立用户列表和权限的 XML 配置访问协议 (XCAP) 以及消息会话中继协议 (MSRP)。

SIP (会话发起协议)：IETF 协议，用于建立实时通信会话。允许希望通信的 SIP 端点相互查找（汇集）并协商他们希望如何交换媒体。

SIP URI: 方案为“sip:”的统一资源标识符。例如 sip:[email protected]。 SIP URI 标识域 (example.net) 中的特定资源 (RjS)。 SIP 系统使用域组件以及 DNS 来确定将 SIP 消息发送到哪里。

Target: SIP 请求的目的地。目标在请求 URI 中携带，请求 URI 是每个请求第一行中的 SIP URI。

Transaction: SIP 请求和关联响应的组合。 SIP INVITE 事务可以持续任意长时间。所有其他 SIP 事务都具有固定的和有限的生命周期，以秒为单位衡量。

Transport protocol: 用于传输 SIP 或 RTP 消息的底层互联网协议。为 SIP 定义的传输协议包括 UDP、TCP、TLS 和 SCTP。 RTP 通过 UDP 传输。正在进行工作以定义通过 DTLS 传输这两种协议。

UA (用户代理)：请参阅端点。

Usage: 请参阅对话使用。

ROBERT SPARKS 是 Estacado Systems 的研发副总裁，他在那里管理面向新市场的产品和组件的开发。他之前曾担任 Xten Networks 的 CTO，并在 Dynamicsoft、Lucent 和 MCI 担任管理和研究职位。在过去的七年中，他一直专注于设计和开发基于 SIP 的 IP 通信系统。他积极参与标准和行业发展，并担任 IETF SIMPLE 工作组主席。他是 RFC 3261（定义 SIP）的特约编辑。 Sparks 拥有德克萨斯 A&M 大学的数学硕士学位和计算机科学学士学位。

最初发表于 Queue vol. 5, no. 2—
在数字图书馆中评论本文

更多相关文章

- 从负债到优势：与 John Graham-Cumming 和 John Ousterhout 的对话
软件生产（软件开发的后端，包括构建、测试、打包和部署等任务）已成为许多开发组织中的瓶颈。在本次采访中，Electric Cloud 创始人 John Ousterhout 解释了如何将软件生产从负债转变为竞争优势。

- 为您的应用程序配备防弹部署：与 Tom Spalthoff 的对话
应用程序、更新和补丁的部署是任何 IT 部门最常见且风险最高的功能之一。部署任何未正确配置为分发的应用程序都可能中断或崩溃关键应用程序，并使公司在生产力损失和帮助台费用方面付出高昂的代价——而公司每天都在这样做。事实上，Gartner 报告称，即使经过 10 年的经验，大多数公司也无法以 90% 或更高的成功率自动部署软件。

Martin J. Steinmann - 使用 SIP 的统一通信
基于 SIP（会话发起协议）标准的通信系统在过去几年中取得了长足的进步。 SIP 现在已基本完成，甚至涵盖了高级电话和多媒体功能以及功能交互。不同供应商解决方案之间的互操作性在 SIP 论坛组织的 SIPit（互操作性测试）会议等活动中反复得到证明，并且多家制造商已经证明，标准的专有扩展不再由技术需求驱动，而是由商业考虑驱动。

Jason Fischl, Hannes Tschofenig - 让 SIP 产生效益
会话发起协议 (SIP) 用于在基于 IP 的网络中建立实时会话。这些会话可能是用于音频、视频或 IM 通信，或者它们可能用于中继 presence 信息。 SIP 服务提供商主要专注于提供一种服务，该服务复制 PSTN（公共交换电话网络）或 PLMN（公共陆地移动网络）向基于互联网的环境提供的服务。