SIP（Session Initiation Protocol）是由IETF定义，基于IP的一个应用层控制协议。由于SIP是基于纯文本的信令协议，可以管理不同接入网络上的会晤等。会晤可以是终端设备之间任何类型的通信，如视频会晤、既时信息处理或协作会晤。该协议不会定义或限制可使用的业务，传输、服务质量、计费、安全性等问题都由基本核心网络和其它协议处理。SIP得到了微软、AOL、等厂商及IETF和3GPP等标准制定机构的大力支持。支持SIP的网络将提供一个网桥，以扩展向互联网和无线网络的各种设备提供融合业务能力。这将允许运营商为其移动用户提供大量的信息处理业务，通过SMS互通能力与固定用户和2G无线用户交互。SIP也是在UMTS3GPP R5/R6版本中使用的信令协议，因此可以保护运营商目前的投资而及具技术优势和商业价值。

SIP的技术优势

*独立于接入：SIP可用于建立与任何类型的接入网络的会晤，同时还使运营商能够使用其它协议。

*会晤和业务独立：SIP不限制或定义可以建立的会晤类型，使多种媒体类型的多个会晤可以在终端设备之间进行交换。

*协议融合：SIP可以在无线分组交换域中提供所有业务的融合协议。

SIP的商业价值

*收入商机：新的融合多媒体业务可以部署在GORS，UMTS，XDSL，WLAN等与接入独立的域中，因此运营商可以在3GPP R5推出之前就开始创收。

*经济高效：由于SIP是与接入独立的协议，无线运营商无需构建适用于多种接入网络的基础设施。
*********************************************************************************
 
 
 
TCP/IP协议 （传输控制协议/网间协议） 

  TCP/IP 协议集确立了 Internet 的技术基础。TCP/IP 的发展始于美国 DOD （国防部）方案。 IAB （Internet 架构委员会）的下属工作组 IETF （Internet 工程任务组）研发了其中多数协议。 IAB 最初由美国政府发起，如今转变为公开而自治的机构。IAB 协同研究和开发 TCP/IP 协议集的底层结构，并引导着 Internet 的发展。TCP/IP 协议集记录在请求注解（RFC）文件中，RFC 文件均由 IETF 委员会起草、讨论、传阅及核准。所有这些文件都是公开且免费的，且能在 IETF 网站上列出的参考文献中找到。 
  TCP/IP 协议覆盖了 OSI 网络结构七层模型中的六层，并支持从交换（第二层）诸如多协议标记交换，到应用程序诸如邮件服务方面的功能。TCP/IP 的核心功能是寻址和路由选择（网络层的 IP/IPV6 ）以及传输控制（传输层的 TCP、UDP）。 
 

 IP （网际协议） 

  在网络通信中，网络组件的寻址对信息的路由选择和传输来说是相当关键的。相同网络中的两台机器间的消息传输有各自的技术协定。LAN 是通过提供6字节的唯一标识符（“MAC”地址）在机器间发送消息的。SNA 网络中的每台机器都有一个逻辑单元及与其相应的网络地址。DECNET、AppleTalk 和 Novell IPX 均有一个用来分配编号到各个本地网和工作站的配置。

  除了本地或特定提供商的网络地址，IP 为世界范围内的各个网络设备都分配了一个唯一编号，即 IP 地址。IPV4 的 IP 地址为4字节，按照惯例，将每个字节转化成十进制（0-255）并以点分隔各字节。IPV6 的 IP 地址已经增加到16字节。关于 IP 和 IPV6 协议的详细说明，在相关文件中再另作介绍。 
 

 TCP （传输控制协议） 

  通过序列化应答和必要时重发数据包，TCP 为应用程序提供了可靠的传输流和虚拟连接服务。TCP 主要提供数据流转送，可靠传输，有效流控制，全双工操作和多路传输技术。可查阅 TCP 部分获取更多详细资料。

  在下面的 TCP/IP 协议表格中，我们根据协议功能和其在 OSI 七层网络通信参考模型的映射关系将其全部列出。然而，TCP/IP 并不完全遵循 OSI 模型，例如：大多数 TCP/IP 应用程序是直接在传输层协议 TCP 和 UDP 上运行，而不涉及其中的表示层和会话层。 
 

 主要协议表 

IP TCP UDP IPsec HTTP POP3 SNMP MPLS DNS SMTP 

应用层（Application Layer） 

--------------------------------------------------------------------------------
 
BOOTP：引导协议 （BOOTP：Bootstrap Protocol） 
DCAP：数据转接客户访问协议 （DCAP：Data Link Switching Client Access Protocol） 
DHCP：动态主机配置协议 （DHCP：Dynamic Host Configuration Protocol） 
DNS：域名系统（服务）系统 （DNS：Domain Name Systems） 
Finger：用户信息协议 （Finger：User Information Protocol） 
FTP：文件传输协议 （FTP：File Transfer Protocol） 
HTTP：超文本传输协议 （HTTP：Hypertext Transfer Protocol） 
S-HTTP：安全超文本传输协议 （S-HTTP：Secure Hypertext Transfer Protocol） 
IMAP & IMAP4：信息访问协议 & 信息访问协议第4版 （IMAP & IMAP4：Internet Message Access Protocol） 
IPDC：IP 设备控制 （IPDC：IP Device Control） 
IRCP/IRC：因特网在线聊天协议 （IRCP/IRC：Internet Relay Chat Protocol） 
LDAP：轻量级目录访问协议 （LDAP：Lightweighted Directory Access Protocol） 
MIME/S-MIME/Secure MIME：多用途网际邮件扩充协议 （MIME/S-MIME/Secure MIME：Multipurpose Internet Mail Extensions） 
NAT：网络地址转换 （NAT：Network Address Translation） 
NNTP：网络新闻传输协议 （NNTP：Network News Transfer Protocol） 
NTP：网络时间协议 （NTP：Network Time Protocol） 
POP&POP3：邮局协议 （POP & POP3：Post Office Protocol） 
RLOGIN：远程登录命令 （RLOGIN：Remote Login in Unix） 
RMON：远程监控 （RMON：Remote Monitoring MIBs in SNMP） 
RWhois：远程目录访问协议 （RWhois Protocol） 
SLP：服务定位协议 （SLP：Service Location Protocol） 
SMTP：简单邮件传输协议 （SMTP：Simple Mail Transfer Protocol） 
SNMP：简单网络管理协议 （SNMP：Simple Network Management Protocol） 
SNTP：简单网络时间协议 （SNTP：Simple Network Time Protocol） 
TELNET：TCP/IP 终端仿真协议 （TELNET：TCP/IP Terminal Emulation Protocol） 
TFTP：简单文件传输协议 （TFTP：Trivial File Transfer Protocol） 
URL：统一资源管理 （URL：Uniform Resource Locator） 
X-Window/X Protocol：X 视窗 或 X 协议（X-Window：X Window or X Protocol or X System） 
 

表示层（Presentation Layer） 

--------------------------------------------------------------------------------
 
LPP：轻量级表示协议 （LPP：Lightweight Presentation Protocol） 
 

会话层（Session Layer） 

--------------------------------------------------------------------------------
 
RPC：远程过程调用协议 （RPC：Remote Procedure Call protocol） 
 

传输层（Transport Layer） 

--------------------------------------------------------------------------------
 
ITOT：基于TCP/IP 的 ISO 传输协议 （ITOT：ISO Transport Over TCP/IP） 
RDP：可靠数据协议 （RDP：Reliable Data Protocol） 
RUDP：可靠用户数据报协议 （RUDP：Reliable UDP） 
TALI：传输适配层接口 （TALI：Transport Adapter Layer Interface） 
TCP：传输控制协议 （TCP：Transmission Control Protocol） 
UDP：用户数据报协议 （UDP：User Datagram Protocol） 
Van Jacobson：压缩 TCP 协议 （Van Jacobson：Compressed TCP） 
 

网络层（Network Layer） 

--------------------------------------------------------------------------------
 
  路由选择（Routing）  
BGP/BGP4：边界网关协议 （BGP/BGP4：Border Gateway Protocol） 
EGP：外部网关协议（EGP：Exterior Gateway Protocol） 
IP：网际协议 （IP：Internet Protocol） 
IPv6：网际协议第6版 （IPv6：Internet Protocol version 6） 
ICMP/ICMPv6：Internet 信息控制协议 （ICMP/ICMPv6：Internet Control Message Protocol） 
IRDP：ICMP 路由器发现协议 （IRDP：ICMP Router Discovery Protocol） 
Mobile IP： 移动 IP （Mobile IP：IP Mobility Support Protocol for IPv4 & IPv6） 
NARP：NBMA 地址解析协议 （NARP：NBMA Address Resolution Protocol） 
NHRP：下一跳解析协议 （NHRP：Next Hop Resolution Protocol） 
OSPF：开放最短路径优先 （OSPF：Open Shortest Path First） 
RIP/RIP2：路由选择信息协议 （RIP/RIP2：Routing Information Protocol） 
RIPng：路由选择信息协议下一代 （RIPng：RIP for IPv6） 
RSVP：资源预留协议 （RSVP：Resource ReSerVation Protocol） 
VRRP：虚拟路由器冗余协议 （VRRP：Virtual Router Redundancy Protocol） 
 
  组播（Multicast） 
BGMP：边界网关组播协议 （BGMP：Border Gateway Multicast Protocol） 
DVMRP：距离矢量组播路由协议 （DVMRP：Distance Vector Multicast Routing Protocol） 
IGMP：Internet 组管理协议 （IGMP：Internet Group Management Protocol） 
MARS：组播地址解析服务 （MARS：Multicast Address Resolution Server） 
MBGP：组播协议边界网关协议 （MBGP：Multiprotocol BGP） 
MOSPF：组播OSPF （MOSPF：Multicast OSPF） 
MSDP：组播源发现协议 （MSDP：Multicast Source Discovery Protocol） 
MZAP：组播区域范围公告协议 （MZAP：Multicast Scope Zone Announcement Protocol） 
PGM：实际通用组播协议 （PGM：Pragmatic General Multicast Protocol） 
PIM-DM：密集模式独立组播协议 （PIM-DM：Protocol Independent Multicast - Dense Mode） 
PIM-SM：稀疏模式独立组播协议 （PIM-SM：Protocol Independent Multicast - Sparse Mode） 
 
  MPLS 协议（MPLS Protocols） 
CR-LDP：基于路由受限标签分发协议 （CR-LDP: Constraint-Based Label Distribution Protocol） 
GMPLS：通用多协议标志交换协议 （GMPLS：Generalized Multiprotocol Label Switching） 
LDP：标签分发协议 （LDP：Label Distribution Protocol） 
MPLS：多协议标签交换 （MPLS：Multi-Protocol Label Switching） 
RSVP-TE：基于流量工程扩展的资源预留协议 （RSVP-TE：Resource ReSerVation Protocol-Traffic Engineering） 
 

数据链路层（Data Link Layer） 

--------------------------------------------------------------------------------
 
ARP and InARP：地址转换协议和逆向地址转换协议 （ARP and InARP：Address Resolution Protocol and Inverse ARP） 
IPCP and IPv6CP：IP控制协议和IPV6控制协议 （IPCP and IPv6CP：IP Control Protocol and IPv6 Control Protocol） 
RARP：反向地址转换协议 （RARP：Reverse Address Resolution Protocol） 
SLIP：串形线路 IP （SLIP：Serial Line IP） 
 
SIP
 介绍 

新一代的服务 

历史回顾 

SIP 的优点：类似 Web 的可扩展开放通信 

SIP 会话构成 

介绍 

通信提供商及其合作伙伴和用户越来越渴求新一代基于 IP 的服务。现在有了 SIP（会话启动协议），一解燃眉之急。SIP 是不到十年前在计算机科学实验室诞生的一个想法。它是第一个适合各种媒体内容而实现多用户会话的协议，现在已成了 Internet 工程任务组 (IETF) 的规范。 

今天，越来越多的运营商、CLEC（竞争本地运营商）和 ITSP（IP 电话服务商）都在提供基于 SIP 的服务，如市话和长途电话技术、在线信息和即时消息、IP Centrex/Hosted PBX、语音短信、push-to-talk（按键通话）、多媒体会议等等。独立软件供应商 (ISV) 正在开发新的开发工具，用来为运营商网络构建基于 SIP 的应用程序以及 SIP 软件。网络设备供应商 (NEV) 正在开发支持 SIP 信令和服务的硬件。现在，有众多 IP 电话、用户代理、网络代理服务器、VOIP 网关、媒体服务器和应用服务器都在使用 SIP。 

SIP 从类似的权威协议－－如 Web 超文本传输协议 (HTTP) 格式化协议以及简单邮件传输协议 (SMTP) 电子邮件协议－－演变而来并且发展成为一个功能强大的新标准。但是，尽管 SIP 使用自己独特的用户代理和服务器，它并非自成一体地封闭工作。SIP 支持提供融合的多媒体服务，与众多负责身份验证、位置信息、语音质量等的现有协议协同工作。 

本白皮书对 SIP 及其作用进行了概括性的介绍。它还介绍了 SIP 从实验室开发到面向市场的过程。本白皮书说明 SIP 提供哪些服务以及正在实施哪些促进发展的方案。它还详细介绍了 SIP 与各种协议不同的重要特点并说明如何建立 SIP 会话。 

返回页首 

新一代的服务 

SIP 较为灵活，可扩展，而且是开放的。它激发了 Internet 以及固定和移动 IP 网络推出新一代服务的威力。SIP 能够在多台 PC 和电话上完成网络消息，模拟 Internet 建立会话。 

与存在已久的国际电信联盟 (ITU) SS7 标准（用于呼叫建立）和 ITU H.323 视频协议组合标准不同，SIP 独立工作于底层网络传输协议和媒体。它规定一个或多个参与方的终端设备如何能够建立、修改和中断连接，而不论是语音、视频、数据或基于 Web 的内容。 

SIP 大大优于现有的一些协议，如将 PSTN 音频信号转换为 IP 数据包的媒体网关控制协议 (MGCP)。因为 MGCP 是封闭的纯语音标准，所以通过信令功能对其进行增强比较复杂，有时会导致消息被破坏或丢弃，从而妨碍提供商增加新的服务。而使用 SIP，编程人员可以在不影响连接的情况下在消息中增加少量新信息。 

例如，SIP 服务提供商可以建立包含语音、视频和聊天内容的全新媒体。如果使用 MGCP、H.323 或 SS7 标准，则提供商必须等待可以支持这种新媒体的协议新版本。而如果使用 SIP，尽管网关和设备可能无法识别该媒体，但在两个大陆上设有分支机构的公司可以实现媒体传输。 

而且，因为 SIP 的消息构建方式类似于 HTTP，开发人员能够更加方便便捷地使用通用的编程语言（如 Java）来创建应用程序。对于等待了数年希望使用 SS7 和高级智能网络 (AIN) 部署呼叫等待、主叫号码识别以及其他服务的运营商，现在如果使用 SIP，只需数月时间即可实现高级通信服务的部署。 

这种可扩展性已经在越来越多基于 SIP 的服务中取得重大成功。Vonage 是针对用户和小企业用户的服务提供商。它使用 SIP 向用户提供 20,000 多条数字市话、长话及语音邮件线路。Deltathree 为服务提供商提供 Internet 电话技术产品、服务和基础设施。它提供了基于 SIP 的 PC 至电话解决方案，使 PC 用户能够呼叫全球任何一部电话。Denwa Communications 在全球范围内批发语音服务。它使用 SIP 提供 PC 至 PC 及电话至 PC 的主叫号码识别、语音邮件，以及电话会议、统一通信、客户管理、自配置和基于 Web 的个性化服务。 

某些权威人士预计，SIP 与 IP 的关系将发展成为类似 SMTP 和 HTTP 与 Internet 的关系，但也有人说它可能标志着 AIN 的终结。迄今为止，3G 界已经选择 SIP 作为下一代移动网络的会话控制机制。Microsoft 已经选择 SIP 作为其实时通信策略并在 Microsoft XP、Pocket PC 和 MSN Messenger 中进行了部署。Microsoft 同时宣布 CE.net 的下一个版本将使用基于 SIP 的 VoIP 应用接口层，并承诺向用户 PC 提供基于 SIP 的语音和视频呼叫。 

另外，MCI 正在使用 SIP 向 IP 通信用户部署高级电话技术服务。用户将能够通知主叫方自己是否有空以及首选的通信方式，如电子邮件、电话或即时消息。利用在线信息，用户还能够即时建立聊天会话和召开音频会议。使用 SIP 将不断地实现各种功能。 

返回页首

历史回顾 

SIP 出现于二十世纪九十年代中期，源于哥伦比亚大学计算机系副教授 Henning Schulzrinne 及其研究小组的研究。Schulzrinne 教授除与人共同提出通过 Internet 传输实时数据的实时传输协议 (RTP) 外，还与人合作编写了实时流传输协议 (RTSP) 标准提案，用于控制音频视频内容在 Web 上的流传输。 

Schulzrinne 本来打算编写多方多媒体会话控制 (MMUSIC) 标准。1996 年，他向 IETF 提交了一个草案，其中包含了 SIP 的重要内容。1999 年，Shulzrinne 在提交的新标准中删除了有关媒体内容方面的无关内容。随后，IETF 发布了第一个 SIP 规范，即 RFC 2543。虽然一些供应商表示了担忧，认为 H.323 和 MGCP 协议可能会大大危及他们在 SIP 服务方面的投资，IETF 继续进行这项工作，于 2001 年发布了 SIP 规范 RFC 3261。 

RFC 3261 的发布标志着 SIP 的基础已经确立。从那时起，已发布了几个 RFC 增补版本，充实了安全性和身份验证等领域的内容。例如，RFC 3262 对临时响应的可靠性作了规定。RFC 3263 确立了 SIP 代理服务器的定位规则。RFC 3264 提供了提议/应答模型，RFC 3265 确定了具体的事件通知。 

早在 2001 年，供应商就已开始推出基于 SIP 的服务。今天，人们对该协议的热情不断高涨。Sun Microsystems 的 Java Community Process 等组织正在使用通用的 Java 编程语言定义应用编程接口 (API)，以便开发商能够为服务提供商和企业构建 SIP 组件和应用程序。最重要的是，越来越多的竞争者正在借助前途光明的新服务进入 SIP 市场。SIP 正在成为自 HTTP 和 SMTP 以来最为重要的协议之一。 

返回页首

SIP 的优点：类似 Web 的可扩展开放通信 

使用 SIP，服务提供商可以随意选择标准组件，快速驾驭新技术。不论媒体内容和参与方数量，用户都可以查找和联系对方。SIP 对会话进行协商，以便所有参与方都能够就会话功能达成一致以及进行修改。它甚至可以添加、删除或转移用户。 

不过，SIP

不是万能的。它既不是会话描述协议，也不提供会议控制功能。为了描述消息内容的负载情况和特点，SIP 使用 Internet 的会话描述协议 (SDP) 来描述终端设备的特点。SIP 自身也不提供服务质量 (QoS)，它与负责语音质量的资源保留设置协议 (RSVP) 互操作。它还与若干个其他协议进行协作，包括负责定位的轻型目录访问协议 (LDAP)、负责身份验证的远程身份验证拨入用户服务 (RADIUS) 以及负责实时传输的 RTP 等多个协议。 

SIP 规定了以下基本的通信要求： 

1. 用户定位服务

2. 会话建立

3. 会话参与方管理

4. 特点的有限确定

SIP 的一个重要特点是它不定义要建立的会话的类型，而只定义应该如何管理会话。有了这种灵活性，也就意味着 SIP 可以用于众多应用和服务中，包括交互式游戏、音乐和视频点播以及语音、视频和 Web 会议。 

下面是 SIP 在新的信令协议中出类拔萃的一些其他特点 

SIP 消息是基于文本的，因而易于读取和调试。新服务的编程更加简单，对于设计人员而言更加直观。 

SIP 如同电子邮件客户机一样重用 MIME 类型描述，因此与会话相关的应用程序可以自动启动。 

SIP 重用几个现有的比较成熟的 Internet 服务和协议，如 DNS、RTP、RSVP 等。不必再引入新服务对 SIP 基础设施提供支持，因为该基础设施很多部分已经到位或现成可用。 

对 SIP 的扩充易于定义，可由服务提供商在新的应用中添加，不会损坏网络。网络中基于 SIP 的旧设备不会妨碍基于 SIP 的新服务。例如，如果旧 SIP 实施不支持新的 SIP 应用所用的方法/标头，则会将其忽略。 

SIP 独立于传输层。因此，底层传输可以是采用 ATM 的 IP。SIP 使用用户数据报协议 (UDP) 以及传输控制协议 (TCP)，将独立于底层基础设施的用户灵活地连接起来。 

SIP 支持多设备功能调整和协商。如果服务或会话启动了视频和语音，则仍然可以将语音传输到不支持视频的设备，也可以使用其他设备功能，如单向视频流传输功能。  

返回页首

SIP 会话构成 

SIP 会话使用多达四个主要组件：SIP 用户代理、SIP 注册服务器、SIP 代理服务器和 SIP 重定向服务器。这些系统通过传输包括了 SDP 协议（用于定义消息的内容和特点）的消息来完成 SIP 会话。下面概括性地介绍各个 SIP 组件及其在此过程中的作用。 

SIP 用户代理 (UA) 是终端用户设备，如用于创建和管理 SIP 会话的移动电话、多媒体手持设备、PC、PDA 等。用户代理客户机发出消息。用户代理服务器对消息进行响应。 

SIP 注册服务器是包含域中所有用户代理的位置的数据库。在 SIP 通信中，这些服务器会检索参与方的 IP 地址和其他相关信息，并将其发送到 SIP 代理服务器。 

SIP 代理服务器接受 SIP UA 的会话请求并查询 SIP 注册服务器，获取收件方 UA 的地址信息。然后，它将会话邀请信息直接转发给收件方 UA（如果它位于同一域中）或代理服务器（如果 UA 位于另一域中）。 

SIP 重定向服务器允许 SIP 代理服务器将 SIP 会话邀请信息定向到外部域。SIP 重定向服务器可以与 SIP 注册服务器和 SIP 代理服务器同在一个硬件上。 

以下几个情景说明 SIP 组件之间如何进行协调以在同一域和不同域中的 UA 之间建立 SIP 会话： 

在同一域中建立 SIP 会话 

下图说明了在预订同一个 ISP 从而使用同一域的两个用户之间建立 SIP 会话的过程。用户 A 使用 SIP 电话。用户 B 有一台 PC，运行支持语音和视频的软客户程序。加电后，两个用户都在 ISP 网络中的 SIP 代理服务器上注册了他们的空闲情况和 IP 地址。用户 A 发起此呼叫，告诉 SIP 代理服务器要联系用户 B。然后，SIP 代理服务器向 SIP 注册服务器发出请求，要求提供用户 B 的 IP 地址，并收到用户 B 的 IP 地址。SIP 代理服务器转发用户 A 与用户 B 进行通信的邀请信息（使用 SDP），包括用户 A 要使用的媒体。用户 B 通知 SIP 代理服务器可以接受用户 A 的邀请，且已做好接收消息的准备。SIP 代理服务器将此消息传达给用户 A，从而建立 SIP 会话。然后，用户创建一个点到点 RTP 连接，实现用户间的交互通信。 

1.呼叫用户 B

2.查询捻没?B 在哪里？?br> 3.响应捻没?B 的 SIP 地址?br> 4.挚顶呼叫

5. 响应

6. 响应

7. 多媒体通道已建立

返回页首

在不同的域中建立 SIP 会话 

本情景与第一种情景的不同之处如下。用户 A 邀请正在使用多媒体手持设备的用户 B 进行 SIP 会话时，域 A 中的 SIP 代理服务器辨别出用户 B 不在同一域中。然后，SIP 代理服务器在 SIP 重定向服务器上查询用户 B 的 IP 地址。SIP 重定向服务器既可在域 A 中，也可在域 B 中，也可既在域 A 中又在域 B 中。SIP 重定向服务器将用户 B 的联系信息反馈给 SIP 代理服务器，该服务器再将 SIP 会话邀请信息转发给域 B 中的 SIP 代理服务器。域 B 中的 SIP 代理服务器将用户 A 的邀请信息发送给用户 B。用户 B 再沿邀请信息经由的同一路径转发接受邀请的信息。 

1. 呼叫用户 B 2. 询问撑胰绾谓油ㄓ?B 中的用户 B？? 3. 响应挚砜刂破鞯挠虻刂窋 4. 挚顶呼叫域 B 的 SIP 代理 5. 查询捻没?B 在哪里？? 6. 用户 B 的地址 7. 代理呼叫 8. 响应 9. 响应 10.响应 11.多媒体通道已建立 

无缝、灵活、可扩展：展望 SIP 未来 

SIP 能够连接使用任何 IP 网络（有线 LAN 和 WAN、公共 Internet 骨干网、移动 2.5G、3G 和 Wi-Fi）和任何 IP 设备（电话、PC、PDA、移动手持设备）的用户，从而出现了众多利润丰厚的新商机，改进了企业和用户的通信方式。基于 SIP 的应用（如 VOIP、多媒体会议、push-to-talk（按键通话）、定位服务、在线信息和 IM）即使单独使用，也会为服务提供商、ISV、网络设备供应商和开发商提供许多新的商机。不过，SIP 的根本价值在于它能够将这些功能组合起来，形成各种更大规模的无缝通信服务。 

使用 SIP，服务提供商及其合作伙伴可以定制和提供基于 SIP 的组合服务，使用户可以在单个通信会话中使用会议、Web 控制、在线信息、IM 等服务。实际上，服务提供商可以创建一个满足多个最终用户需求的灵活应用程序组合，而不是安装和支持依赖于终端设备有限特定功能或类型的单一分散的应用程序。 

通过在单一、开放的标准 SIP 应用架构下合并基于 IP 的通信服务，服务提供商可以大大降低为用户设计和部署基于 IP 的新的创新性托管服务的成本。它是 SIP 可扩展性促进本行业和市场发展的强大动力，是我们所有人的希望所在。
 
 
 

1.SIP这玩意是怎么走来和如何构建的？
 
    通俗的说，SIP就是一个轻量级信令协议，它可以作为音频、视频、及时信息的信令。
 
    说到SIP是怎么出来的就要提H.323，而提到这个标准由不得不提到ITU-T，我们就先说说指定SIP的IETF（Internet Engineering Task Force）和制定H.323的ITU-T（International Telecommunications Union–Telecommunications Standard Sector）之间一些小趣事吧。ITU-T和IETF想事儿总是不一样的，它们俩往往从两个不同的角度来进行。ITU-T作为一个隶属于美国的国际标准 化组织，传承了美国政策的一致性和试图完成维护世界和平的角色，所以它制定出来的标准一定是经过无数轮的反复和草案，花了N年制定出一个最终的，广为接受 的结果。而恰恰相反，IETF则更趋近于实用主义，信奉“rough consensus and running code”，也就是说能用进行，边用边补充呗。因此在大多数时候，IETF标准制定的周期要比ITU-T短一些，这可能也归因于IETF每年举办三次开放 性论坛。这些春季、夏季、秋季会议会安排在世界各地，并且向各个对此感性趣的组织开放（去瞅一瞅吧：http://www.ietf.org/meetings/meetings.html ）多个IETF工作组在这些会议上相聚，针对他们现在的系统开发敲定一些技术细节，对于要是到了会议结束时还是没有解决的问题那就几个月后的下次开会继续研究呗。简而言之，IETF以一种实际实用的角度去完善体系架构和协议设计。
 
    说了这么多可能你还没有意识到我在扯这些是为了什么，但是请记住这些正是SIP（Session Initiation Protocol）架构所体现的核心思想——先用着，再扩展。SIP的结构是建立于两个常用协议之上的：在RFC 2821中的SMTP 协议(Simple Mail Transfer Protocol )——它定义了电子邮件的消息格式，以及定义在RFC 2616的HTTP协议 (Hypertext Transfer Protocol )——它定义了基于Web的多媒体通信消息。另外，SIP又使用了定义在RFC 3550中的RTP/RTCP协议(Real Time Transport Protocol/Real Time Control Protocol )——它定义了在IP网上的多媒体包格式，还使用了定义在RFC 2327的SDP协议(Session Description Protocol )——它定义了一个多媒体会话的参数和特征。因此，SIP是建立在其他IETF提出的协议之上的，这有点像H.323建立在诸如H.225.0和 H.245等ITU-T制定的协议之上，它的两个比较基础的RFC分别是版本1.0 RFC2543和版本2.0 RFC3261。当然，SIP还运行于其他IETF定义的传输协议之上，比如TCP(Transport Control Protocol ), UDP(User Datagram Protocol ) 和IP (Internet Protocol )等。这样，这么多著名的，并且被广泛应用的协议为SIP提供了超于H.323的简单明了的特性。
 
    在网上看到了这样三个MindMap，觉得很能表达SIP的基本核心思想：
 
         
 
      
 
   
 
    关于SIP的架构，我们一定要知道这玩意不是什么新鲜玩意，你看看它基于什么就知道了，这么个拼出来的东东架构能崭新到什么地步呢？我的粗浅理解是SIP 的主要架构其实就是一个典型的C-S架构：一个Client客户端在RFC3261中定义为一个发送SIP请求并接收SIP回应的网络元素，这个 Client可能与也可能不与人进行交互。对应的，一个Server服务器是接受SIP请求并且给予其回应的网络元素。比如最典型的是一个SIP请求 INVITE，邀请一个用户或者服务器参与会话，若得到的是肯定的响应的话，那么则会返回响应SUCCESS。要是再深入一点，我们可以将这样一个简单的 分类进行细分：
 
     Client分为两类：
 
 
 
用户代理客户端User Agent Client ：它是一个逻辑功能，它创建请求、并且使用这个功能实体的一些具体功能发送出请求。
 
 
代理Proxy ：中文翻译过来还是代理，但是这个与上边的Agent不一样，它是一个中间设备，既作为Client，也作为Server  ， 可以解释、翻译、改写一个请求，并将请求转发给其他的服务器，完成路由功能。有时候有状态和无状态Proxy，所谓有状态就是Proxy根据不同的情形作 出不同的处理，这些处理具有前后的相关性，比如三个人传数字，A要通过B给C传一个数字，一种情况是不管A说什么，B都说同一数字给C，这叫做无状态 Proxy；另一种状态是A说1的话，B就传给C数字2，要是A说2的话，B就传给C数字3，这样就是一个有状态的Proxy。有些资料上有所为 B2BUA，实质与Proxy很相似，只不过更加灵活。
 
 
    Server分类三类：
 
 
 
用户代理服务器User Agent Server: 它是一个逻辑功能，它对一个请求产生应答。
 
 
重定向服务器Redirect Server: 一个将客户端的请求重定向去联系另一个服务器以完成请求的服务器。
 
 
注册服务器Registrar ：一个接受REGISTER 注册请求，并将信息放置于位置服务器的服务器。
 
 
注意：我们在书上常常看到的UA是一个概括的说法，之所以区分UAS和UAC只是从逻辑上区分，实质上不一定是独立物理实体。
 
2.SIP该在哪，能干啥？
 
我们学习SIP就要知道它的地位，有个宏观的了解才能知道N多协议之间的关系：
 
  
 
既然根据RFC 3261，SIP是基于STMP和HTTP的，并且底层使用了IP、UDP和TCP，那么它就是一个应用层协议，也就是说，它能为End User提供服务，你能看得见摸得着。描述SIP应用服务的单位是会话，也就是英文中Session一词，意为在两个或多个参与者之间有顺序的交换信息， 更深入一点，SIP必须先去扮演建立会话的角色，然后再在通信中管理会话。大家更关注的有三点：
 
 
 
a.多于两个的参与者就意味着呼叫可能是多点的，而不仅仅是点对点的那样子。
 
 
b.End User可能总不是从相同的地点发起呼叫的，我们需要添加追踪这些End User的功能。
 
 
c.End User可能会使用文字、音频、视频等的混合媒体类型，这些在网路中对网络的带宽、最大传输延时等都有不同的要求和限制。SIP还需要对此进行有效处理。
 
 
针对以上的Concerns，RFC 3261主要定义了五个方面的SIP多媒体会话管理能力：
 
用户位置管理：决定哪一个端系统用于这次通信。 
用户可用性：决定被叫端是不是愿意参与这次通信。 
用户容量：决定用于这次通信的媒体以及其参数。 
会话建立：在被叫和主叫两端建立会话参数。 
会话管理: 包含转接和终止会话、修改会话参数、调用会话业务。 
 
3. SIP依靠怎么运作？
 
既然SIP是建立在SMTP和HTTP上的，那么其消息格式也有巨大的相似度，但是注意到一个SIP会话的资源是通信资源，而不是页面或者网页资 源，这是与HTTP不同的地方。一个身份或者叫做一个寻址体制必须在请求/响应集有效建立之前建立。身份标识就是所谓的SIP URI（SIP Uniform Resource Indicator），其中包含了充足的信息来初始化一个会话。使用这个标识的资源的例子（RFC 3261中提供的）有：有在线业务的用户、在一个消息系统中的一个邮箱，在一个组织中的一组逻辑用户（例如销售部门），一个PSTN电话号码等等。SIP URI与电子邮件地址类似，这也是借用了SMTP协议中的规定：典型的包含两部分，第一部分为用户名，第二部分为主机名，sip:huangpc@bupt.cn， 这是RFC 2543所介绍的最通常的格式。 当然SIP URI还有其他的一些格式，比如在RFC 3261中引入的安全SIP URI：sips:huangpc@bupt.cn， 这个是在TCP上的TLS作为安全传输层的一种方式。
 
定义了用户标识后，我们就可以定义请求的标识了——SIP中称为方法（Method）。其他的扩展方法在后续的RFC中都有定义。 
 
REGISTER: 用于与SIP服务器进行注册。 
INVITE: 用于表明用户或者服务器被邀请参与这个会话。这个消息体中将包含一个对被叫端的会话描述。 
ACK: 仅用了INVITE请求，表明收到请求。 
CANCEL: 用于取消一个pending 的请求。 
BYE: User Agent Client用户代理客户端发送，来告诉服务器它希望结束通话。 
OPTIONS: 向服务器查询它的能力。 
 
定义完请求，很自然我们需要回应的语言规范：包含状态码和描述性短语。分为六类：
 
1xx: 暂时性回应，表明已经接收到，正在处理之中。 
2xx: 成功回应，表明动作已经被接收，理解并且接受了。 
3xx: 重定向回应，需要进一步的动作来处理处理这个请求。 
4xx: 客户端错误回应，请求中语法不对，不能被服务器接受。 
5xx: 服务器错误回应，服务器不能处理这个有效的请求。 
6xx: 全局错误回应，这个请求不能被任何服务器接受。 
 
你现在可能比较纳闷，这都是些关于SIP会话建立和拆除的部分，但关于这个会话中要传的文字、音视频等的格式等双方是怎么知道的呢？在INVITE 中，就带有了这些信息，这个信息的格式则又引出了另一个RFC，RFC 2327，会话描述协议（Session Description Protocol (SDP)）。
 
SIP和其他协议一样都有这样的一个要求：在会话开头时两端要有充分的信息交流。使用的两个协议就是定义在RFC 2974中的SAP(Session Announcement Protocol )和定义在RFC 2327的SDP (Session Description Protocol)。简单来说，SAP提供了一种定期宣传多媒体会话，向有意参与会话者传递相关会话信息的机制。使用它来支持 Mbone（Internet Multicast Backbone），因此关兴趣的各方都会清楚的指导目前正在进行的一些会话。而SDP则定义了描述一个通信会话的格式，同样的，它也可以用于不同的传输 协议，比如SAP、SIP、HTTP或其他等传输协议。学习时要注意SDP的载体是SIP。RFC 2327专门注明了一些SDP能提供的比较关键的信息：
 
 
 
会话名和目的。
 
 
会话激活的时间。
 
 
构成会话的媒体。
 
 
怎么样接收这些媒体（地址、端口号、格式等）
 
 
而另一些信息则是可选附带的，例如会议使用的带宽，负责这个会话的那个人的联系方式等等。
 
说到这些你可能觉得很抽象，我们赶紧那个例子RFC 2327中的例子来看看：
 
     v=0 
      o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 
      s=SDP Seminar 
      i=A Seminar on the session description protocol 
      u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps 
      e=mjh@isi.edu (Mark Handley) 
      c=IN IP4 224.2.17.12/127 
      t=2873397496 2873404696 
      a=recvonly 
      m=audio 49170 RTP/AVP 0 
      m=video 51372 RTP/AVP 31 
      m=application 32416 udp wb 
      a=orient:portrait
 
我们看到SDP格式包含多行文本，都是以 = 的格式书写的，RFC中的星号*指的是选择项。我们主要有三类的会话描述：会话描述、时间描述、媒体描述，具体你可以参看RFC 2327。注意这个例子中，两个m开头的行，定义了音视频的概要，这些概要是在RFC 3550 Real Time Protocol (RTP)中的第13节和RFC 3551 RTP Profile for Audio and Video Conferences with Minimal Control 中的第6节，在编码最后的那个0和31，这是在后续RTP帧中要使用的负载类型值，用来确定媒体和编码类型。49170和51372都是接收者的端口，发送者端口分别加1，也就是说在这个例子中49171和51373是发送者的端口。
 
4.SIP到底怎么运作？
 
一个最简单的例子是在SIP呼叫建立两个直接相连的端对端的通话过程。发起者会发起一个INVITE消息给对端来发起会话，接着会收到 Ringing和OK消息。被叫端返回ACK表明连接完成，可以进行信息交流了。当不需要这个连接时，任何一端发送BYE消息给对端，对端返回OK来终止 呼叫。
 
注意，SIP消息和具体的媒体流并不是在一个层面运作的。例如，一个VoIP电话是先通过SIP信令完成交互后再开始具体媒体流的传输的，如下图，SIP的根本作用的完成点对点（或多点）的媒体流传输的前序工作。 
 
 
 
在RFC 3261中描述了一个比较复杂的例子：使用了代理服务器作为通信通路。SIP代理服务器代表其他的Client发起请求，并且在许多时候作为路由模式，将 SIP请求转发给另一个距离最终目的地（也就是被叫端）较近的设备。因此，SIP代理服务器扮演着两个角色——在接收请求时是server角色，在发送请 求时是client角色。注意，代理服务器必须可以解释一个SIP消息，并且需要的时候转发这条消息前对其进行重写，大的网络中可能有多个代理服务器。在 RFC3261中的第四节中有个比较有趣的例子，描述了两个SIP终端通过两个代理服务器建立呼叫的过程。在这个例子中，两个终端位于两个不同的城 市：Atlanta and Biloxi，因此是在两个相互隔离的网络中。每个网络有它自己的代理服务器，分别称为atlanta.com 和 biloxi.com。 若在Atlanta的Alice想呼叫在Biloxi的Bob，那么Alice的电话就会发送以下的INVITE消息给它的代理服务器atlanta.com： 
 
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds 
 Max-Forwards: 70 
 To: Bob 
 From: Alice ;tag=1928301774 
 Call-ID: a84b4c76e66710@pc33.atlanta.com 
 CSeq: 314159 INVITE 
 Contact: 
 Content-Type: application/sdp 
 Content-Length: 142
 
当这个消息通过网络转到Bob后Bob要是愿意接受这个呼叫那么它就会返回一个OK，这个消息会先到biloxi.com 代理：
 
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 ;tag=a6c85cf 
 From: Alice ;tag=1928301774 
 Call-ID: a84b4c76e66710@pc33.atlanta.com 
 CSeq: 314159 INVITE 
 Contact: 
 Content-Type: application/sdp 
 Content-Length: 131 
 
我们注意到有相同的Call-ID来保证这个会话的单一性。更多的细节参看RFC 3261里的这个例子的具体解释。
 
5.SIP中的信令和媒体之间的关系：
 
SIP等于为媒体的建立进行实现的沟通，打个比喻，只有你知道你要说话的那个人在那，并且两个人都要找到彼此畅通的语言，这样才能更有效的沟通。
 
而真正开始两人滔滔不绝的倾心交谈了，就与前边这些对话前的相互了解和基本沟通没有关系了。
 
  
 
6.几个重要的概念：
 
呼叫（call）： 呼叫是一个非正式的术语，用来表示一个多媒体会话，用Call-ID来标识；不论两方通话还是在多方通话中，在每个UA中是使用同一个Call-ID；
 

  
 
事务(transaction)： 请求（UAC）+最终响应（相邻的UAS），SIP基于事务。所谓相邻就是说transaction存在于相邻的SIP实体，而不是存在于两个UA之间。 CSeq标识。一个事务中包含一个请求消息、0个或多个临时响应消息、1个或多个最终响应消息（2xx~6xx）。SIP是事务性的协议。事务的区分通过 Via字段栈顶的Branch的值来确定，这是由于对于请求消息每经过一个有事务状态的Proxy的时候，该Proxy需要为这个事务创建一个服务器端事 务和一个客户端事务，并且将自己的URI添加到Via的栈顶，并生成一个Global ID做为Branch的值，以此值来表示一个与之相对应的事务。SIP在事务层面定义了状态机和定时器来实现重传。
 
下图是一个回复200 OK的成功的INVITE事务：是不是INVITE事务区别在于 UAC需要为每个INVITE最终请求（2xx～6xx）生成ACK响应，而其他的请求消息（INFO,OPTION,etc）则不必如此。因为 INVITE的地位比较重要， 所以需要这样一个三次握手的机制来保证会话的双方都能够确保事务的完整性，这一点和TCP连接建立的三次握手比较像。 
 
 
 
注意在上图这两个UA中，每一个代理服务器都将自己的地址加入返回的ACK的Via头域中，而非成功的transaction则不会加入，见RFC 3261 (p.24)。CSeq头域的值必须与INVITE相同，并且CSeq的方法必须是ACK。中间响应消息 1xx 的使用则是为了节省网络开销设计的，一旦 UC 收到任何一个中间响应消息，则 UC 必须停止消息重发定时器，不再从发这个请求消息，反之则直到收到最终响应消息或重发定时器超时。一旦客户端UAC的事务在Calling状态收到任何中间 响应消息1xx，事务则自动切换到Processing状态，停止请求消息的重发。并且需要将中间响应消息传送给TU事务用户。在呼叫业务中，TU以及上 层应用可以根据中间响应消息在用户界面上提示用户。一旦事务切换到Processing状态，任何其他中间响应消息也都要传送给TU。
 
而非INVITE事务则如下： 
 
 
 
当UAC发出非INVITE请求时，它就会在事务管理子层上开启定时器F（TCP）或者是E（UDP），确保超时的时候进行重传。这适用于除了 ACK请求外的其他非INVITE请求。每次超时重传时E的时间都被翻倍，直到最大的4秒。而F超时时，UAC就会认为是Timeout，这个事务将被删 除。
 
对话(dialog/leg）： 代表着两个SIP UA之间持续一段时间的端到端的联系（如：一段通话）。也就说仅仅存在于端到端的信令关系。当一个UAS发出对于INVITE（或者REFER）的非失败 最终响应<=>200OK（BYE），则Dialog建立，同时这也是session的开始。UA和SIP代理服务器之间不会有对话。在 SIP中呼叫中包含一个或多个Dialog（这仅仅存在于多方通话中）。Dialog终结于任意一端发出 BYE。Early Dialog可以通过UAC发出的CANCEL进行终结，更确切的说，所有早期对话在接收到非2XX最终响应时就被终结了。 Call-ID-value、To、From进行标识。Forking时体现明显。
 
 
 
在这个Forking的例子中，这个用户注册了三个设备，在用户被呼叫时，INVITE的Contact头域就被转换为三个INVITE发往三个设 备。后边的q指的是优先级，q越小，优先级越高。其中的SIP注册服务器相当于一个Forking代理，尽管这个实体接收到两个ACK，但是除了这些 ACK外，它与主叫方的信令交互都是属于一个transaction的，而与被叫方则分别建立了Transaction。另外，被叫方收到的两个ACK由 分别建立了Transaction。注意Device3返回了488这样的非成功响应，SIP注册服务器（Forking代理服务器）没有将该响应发回主 叫方，这是SIP代理一个重要的特征，SIP代理还能自行发出Request:CANCEL消息。
 
UAS对话层接收到一个新的对话请求INVITE消息后，在建立会话的响应消息2xx中，将请求消息里面的所有Route-Record字段拷贝到 2xx消息中，并且UAS的对话层必须添加一个Contact字段使得对话中后续的响应（INVITE在2xx响应的情况下也包括ACK消息）、请求消息 可以直接和本UA联系。当UAC收到UAS的INVITE的2xx响应消息后，如果2xx中不包含任何Route-Record字段的，则UAC可以选择 直接发送ACK到Contact中地址&端口。
 

  
 
会话(session)： 多方用户的媒体关系，在对话的控制下建立。
 
下图是Early dialog、Session、Dialog、Transaction等的在一个UA-UA的呼叫中的体现：
 
 
 
在这个例子中，通过INVITE事务而成功建立起来的dialog必须有一个ACK进行回应，这是第二个transaction的开始，尽管ACK 并没有回复，但是由于新的 branch-value被填入，所以这个ACK代表了一个新的Transaction的开始。注意，此时 transaction number (CSeq) 并没有根据INVITE而增加--也就是说若收到的最终响应不是2XX（是3XX--6XX），则该transaction中包含ACK，若最终响应是 2XX，则ACK属于一个新的transaction。早期对话是UAS以一个1XX响应作为回应时建立的。这样做的好处是在UAC可能在早期对话中发出 诸如UPDATE这样的SIP请求。
 
7.在线状态（Presence）   
 
有人译为“呈现”，个人觉得译为在线状态比较贴切，这 是一种激动人心的SIP应用，它使您能够确定用户位置，并判断是否能够通过电话、电子邮件/文本或视频与其进行通信。人员和应用都可以利用状态信息，从而 使企业有机会将通信整合到业务流程之中。IETF指定了许许多多的SIP扩展来支持在线状态这个功能，我们列举如下：  
 
RFC 2778: A Model for Presence and Instant Messaging   
RFC 2779: Instant Messaging/Presence Protocol Requirements 
   
RFC 3261 SIP: Session Initiation Protocol 
   
RFC 3856: A Presence Event Package for the Session Initiation Protocol 
   
RFC 3859: Common Profile for Presence 
   
 
主要的组成有：
 
Presence Agent（PA）：PA为SIP使用者的代理人，能够接收和处理Presence的消息。它也能够回应和重新整理其它的消息（如公开的消息或SIP以外 的任何消息）。当一个用户改变其状态时，它还能给订阅者发送通知。其可以与 SIP proxy server放在一起实现，也可以作为一个独立实体存在。
 
Presence User Agent (PUA) ：查询更新PA。
 
  
 
8.全网看SIP 
 
在非IMS网络中，拓扑结构如下:
 
 
 
在这个结构中，有三个主要的部分：
 
公网与业务定制者节点：这是PSTN网络以及在用户层面的设备。
 
DMZ区域：对接外网的一些网络元素，用于安全方面。
 
核心网：网络消息处理的核心区域。
 
  
 
需要的注意是：
 
1.在核心网部分的媒体服务器有时候也可以扮演UA的角色，比如你定制语音留言这个业务，那么这个媒体服务器就负责播放提示音和录音。网关在某个层面上也是扮演了UA的角色。
 
2.IP PBX是一种B2BUA，另外，SBC也是一种B2BUA，负责隐藏内网拓扑结构。应用服务器也是一种B2BUA，供修改业务参数等操作使用。
 
9.NAT问题 
 
下图所示SIP可能会出现的NAT问题：
 
 
 
目前商用的方法是使用Session Border Controller (SBC)，也就是说在应用层提供NAT服务，SBC监听SIP请求，当得到一个请求时，它不仅检查IP头以便路由这个包，它也查看SIP消息内部的 contract地址，并且在将其路由到下一跳之前将该地址改为一个可路由的地址，这个可路由的地址不一定是公网地址，只要下一个节点可以路由即可，如下 图所示：
 
 
 
 
 
来源：http://blog.csdn.net/gnuhpc/archive/2009/11/29/4901908.aspx