IP标准（下）
三、会话初始化协议（SIP）
——会话初始化协议（SIP）是由IETF推出的一种基于文本的协议，采用SIP规则资源定位语言描述。它不像H.323那样提供所有的通信协议，而是提供和呼叫建立控制功能相关的协议。它应用于IP电话，与H.323建议相比，具有简单、灵活的特点。
——SIP借鉴了超文本传输协议（HTTP）的设计思想和体系结构（HTTP是万维网所使用的信息交换协议）。SIP是基于客户机／服务器的协议，客户机发出信息，被呼的服务器回答。SIP使用了许多HTTP的消息类型和报头域，用实体头（内容类型的描述）标识信息流的内容，并且考虑了认证授权，所使用的认证授权方法类似于Web中所使用的认证授权方法。
——SIP定义了IMITE和ACK消息，它们类似于H.225协议中定义的建立和连接消息。之所以类似，是因为H.225协议和SIP都定义了建立一条可传输呼叫控制信息的可靠信道。SIP和H.225协议不同的是，SIP定义的这条信道，并不依赖于TCP达到它的可靠性，而是通过处理自己的握手确认信号来取得可靠性。SIP的支持者认为，将可靠性集成到应用层，可以使定时值（用于重传和确认）与应用紧密相连，这将有利于VoIP业务的传输。使VoIP业务的传输不受制于TCP的“通用目的”。
——最后，SIP依赖于会话描述协议（SDP）。SDP是另一种IETF标准。它用于传输类似于H.245协议中容量交换机制的协商信息。例如在呼叫中，SDP可被用于传输交换过程中的编解码标识。SDP也被用来传输定义于SIP中的许多信息的通用格式，以及用于实时信令协议（RTSP）的消息。
——究竟是H.323协议／H.225协议，还是SIP更适合用于IP电话传输，目前在学术界还处于争论之中。事实上，两种方法各有利弊，就市场的占有额而言。H.323协议比较有利（因为H.323协议先于SIP发展）。而SIP则得益于IETF的势头，IETF是发展得最快的标准化组织。在研究VoIP问题的解决方案时，一种较好的方式是将H.323协议模型和SIP模型一起考虑。
1.编址与命名
——当然只有当呼叫者能准确地说明他（她）将要呼叫的另一方时，会话初始化或呼叫建立才能进行。在会话初始化或呼叫建立的过程中，被呼叫方的标识将被解析为有效的IP地址，通过IP地址主叫网关才能连通被叫网关。目前，VoIP系统极大程度上是手工配置点到点的地址。比如，某系统有十个网关，每个网关的IP地址手工配置成与区号相关连。网关收到一给定号码的VoIP呼叫后，它将要呼叫的区号与它自己保存的区号表进行对比，然后与相关网关建立连接。当然，此方案只适用于节点数较少的系统，它并不适用于分布式VoIP系统。
——另外，由于VoIP网络可依据各种不同的模型来构建，所以，不同的VoIP网络的编址及命名方式也不尽相同。例如，在一个能连通所有用户的全分布式IP网络中，一个IP地址就是一个用户，因此，仅仅通过VoIP终端的DNS域名就可标识用户。但是，全分布式模型不是目前VoIP应用的主流，很多能作为VoIP终端的工作站并不拥有DNS域名。而且通过PC到PC来传输VoIP分组，还必须借用专用的目录服务或提前共享它们需要通信的地址。通话双方必须让对方知道自己的位置，如同打电话的人预约下一次在何处见面一样。这种人工操作的寻址方式很难体现出VoIP的好处。最好的处理办法是让呼叫者无需知道被呼者的物理位置。
——在网关到网关的模型中，一个IP地址即可对应于多个用户，不同的用户对应于不同的电话号码。在此模型中，找出被叫所处的网关是首要问题。IETF的IP电话工作组已经提出网关定位协议（GLP）解决这一问题。尽管这一协议还不太完善，但有一点可以明确的是GLP是通过交换网关标识信息来工作的，如同一些路由协议通过定位服务器（LS）交换网络层可达性信息一样。
——由IETF的MGCP工作组发起的媒体网关控制协议（MGCP）定义了一种方式，通过这种方式，呼叫网关从呼叫PSTN节点收到E.164地址（PSTN电话号码）之后，向被叫所属的关守发送信令。另外，GLP和MGCP允许关守：（1）提供对主叫网关或终端的认证。（2）根据被叫号码查询所对应的网关。（3）为完成呼叫建立会话。MGCP和GLP的确切操作规程还在制定中，所有的提案除涉及网关定位和被叫号码信息外，还应涉及带宽限制信息和编解码协商信息等。
——在使用Internet作为骨干传输网的VoIP系统中，必须有一套与DNS兼容的命名方案，很有可能采用由SIP和H.323建议的类似于e-mail地址的命名方式，如user＠domain.com。这种使用已有地址格式的方式允许重用已经存在的数据库，同时也允许HTML网页中旬含诸如h.323：//domain.com，sip：//user＠domain.com之类的USL地址。这样，建立一个呼叫如同点击一超文本连接一样简单。
2.目录服务
——DNS这种名字服务是一种相对静态的服务，DNS系统不会根据IP地址与域名的变化而自动变化。因此，目前的DNS系统对查找与主机名相关的网关有用，但是对查找VoIP的用户终端却无能为力。因为终端的IP地址经常会发生变化，变化的原因为：（1）域名发生变化（比如旅行者离开公司的局域网在旅馆通过一不同的ISP接入Internet）。（2）使用动态地址分配方式，这种方式已应用于点到点协议（PPP）和动态主机配置协议（DHCP）。
——因此，在端点地址变化的地区建立IP电话系统，必须提供目录服务，而不是类似于DNS提供的名字服务。目录服务与名字服务的区别在于目录服务能以与关系数据库相同的检索方式来检索信息。（在关系数据库中，检索记录信息依赖于许多参数，且每个参数都是对实体某些属性的描述）。例如，目录服务的用户可以向目录服务系统询问：“请立即回答user＠domain.com的终端IP地址是多少？”目录服务系统将根据系统中的记录值进行回答，一般白天是一个地址，晚上是另一个地址（用户每更换一个地址需要在目录服务系统中进行登记）。同样用户也可以通过目录服务系统得知网关或特定用户的IP地址。目前，基于Internet的VoIP目录服务系统的有力竞争者是基于“简易目录接入协议”（LDAP）的一种服务，这种服务使用客户机／服务器方式，从X.500目录数据库中获得信息。
3.网络需求
——尽管H.323协议和SIP都提供了通用语言（目前还不兼容）。通过通用语言，VoIP的端节点可以互相发信号，对语音信号进行编解码，以及与关守进行通信。但是对于整个电话服务网络而言，这种通用语言的描述还不够明确。比如，H.323协议认为Novell的IPX协议和IP协议一样是一个网络层协议，甚至IETF也认为这是可行的。但是，一般而言，网络层协议应该可以运行于任何基于帧和信元的网络（比如以太网，令牌环网，ATM、FDDI等）之上。
——然而，由于网络本身（数据链路层和网络层）只能提供“尽力而为”的服务，所以负责发送和接收语音数据的应用程序至少应从网络服务那里收集一些信息。也就是说，应用程序应该跟踪网络的运行情况，以调节自己的操作，从而提供尽可能好的服务。为此，H.323协议和SIP都制定了实时传输协议（RTP）和实时控制协议（RTCP）。
4.RTP和RTCP
——利用RTP可提供大量的实时业务，特别是语声业务和视频业务。RTP主要应用于在Internet上传输对时延敏感的业务，使得这些业务的传输更具规律性和可预测性。
RTP可提供的功能包括：
——（1）打时戳。在诸如Internet的分组网中，从发送端到接收端不同的时延通常导致达到目的地的分组“成堆”，也就是说，大量的分组几乎一起到达，其间一会儿丢失分组，一会儿到达大量的分组，造成的结果就是时延抖动，从而达不到专用电路的传输质量。在专用电路中，数据以固定的时延到达。RTP通过一个32比特域来解决此问题：此域用于标识数据的时戳值，并用一随机标识符产生第一个分组的时戳值。对后续的分组，按照已过去的“时钟滴嗒”数以线性方式增加时戳值。
——尽管此法并不能保证数据按时到达，但是当此方案与接收端时延抖动缓冲区结合使用时，收到的数据至少能以发送端一样的相对分组时延馈入接收应用程序。接收端的时延缓冲区根据分组的时戳值（由RTP发）对来得太快的分组加上一些附加时延，从而平滑数据发送。
——（2）编序列号，大多数分组交换网允许同一数据流的分组在网中沿不同路径传输，这样很可能会出现到达接收端的分组顺序与发送时的分组顺序不一致。为解决此问题，RTP给第一个分组分配一个随机序号，后续分组的序号按序递增。这样就允许接收端：（1）对收到的分组排序。（2）检测丢失的分组。尽管RTP并没有为丢失的分组提供重传机制（事实上，实时或近实时的数据传送不免许重发），但是接收端至少知道语音流有间断期。
——（3）发送监控：RTP可通过与它关系密切的RTCP向语音流的发送端提供有用的反馈信息。RTCP定义了发送端记录（SR）和接收端记录（RR）分组，这些记录分组所记录的情况包括：到达时延间隔的抖动、丢失分组数、传输的分组和字节总数，以及其它对诊断、监控和纠正网络错误等有用的数据。比如，当端到端时延增加或抖动加剧，以至影响到声音的保真度时，自适应编码器可能产生更短更低质的分组。
——（4）负载标识：不仅对通过RTP传送的语音数据用正确的顺序接收是必须的，而且按编码方法对其进行解码也是必须的，因此，RTP给每一个分组指配负载类型标识符以标识该分组所负载的类型。RFC1890定义了语音和视频信息的负载类型（用于语音或视频的具体编解码方式），其它的负载类型可由IETF定义或动态地由软件定义。
——ITU-T的RTP实现方案是将RTP和它所支持的应用层高度集成，而不是将其作为单独的协议层。因此，RTP更像支持应用程序所要求的功能的“协议帧”。协议帧头不支持的功能可由开发商自行增加，但这将引起多个供应商的互操作牲问题。
——RTP和RTCP分组都不包括复用信息，因此设法区分不同的数据流，但接收端可能同时收到来自不同地方的多个语音数据分组，它必须要将其区别开，所以RTP分组被封装在UDP中，UDP本身封装
在IP中。UDP是不可靠传输层协议，它提供了端口号标识，但没有纠正错误的能力。
——H.323协议与SIP之间的竞争日趋激烈。H.323协议应用得较早，而SIP得到了许多强有力的IP团体的支持。然而限制VoIP发展的因素，既不是H.323协议，也不是SIP，而是VoIP的服务质量。
四、服务质量（QoS）
——在当前的IP网络中，QoS问题是通过服务类型（TOS）字节解决的。分组头的第二个字节被分成两部分：第一部（3比特）是优先级参数，标识路由器处理分组的优先级；第二部分（4比特）是服务参数，标识发送端的要求，比如时延，吞吐量，可靠性以及费用等。
——目前大多数路由器都可处理优先级域，但处理该域的应用程序则各不相同。另外，在Internet中，由于缺乏区别对待不同流量的选择，所似服务参数从未实现。要想直接实现低时延就需要预先在“正常”路径之外假设一条“低时延”路径。支持这种能力的路由协议已开发成功，比如IETF的开放式路径优先（OSPF）和Cisco系统的内部网关路由协议（IGRP）都支持基于链路和路径质量的网络路径差异。然而，两个协议在应用的过程中都未能充分利用这种能力。
——在Internet中，即使完全实现OSPF和IGRP，也会失去选择有效路径的能力，这是因为大型的ISP们组成了所谓自治系统。一旦某个分组离开单ISP控制路由协议的自治系统，服务参数将难以保证，除非相邻的自治系统以同样的方式实现路由。所以尽管在单个自治系统中区分不同的服务质量是可能的，但要跨自治系统保持这种能力就需要很好地协作，但在Internet中，这是很难实现的。主要原因是不同的ISP对优先级的支持不一致以及所使用的IP服务参数路由协议不一致。之所以这样很大程度是因为ISP对是否有必要提供这些服务的意见不统一。毕竟IP和它的TOS域是在广域网的速度为9.6Kb／s或更低的时候发展起来的，然而在今天的网络，1.5MB／s的DS-1线也
被认为很慢，随着光纤技术，波分复用等技术的投入使用，网络速度不断增加，以至于一些工程师认为区分不同类型的数据流给数据传输增加了不必要的复杂性，从而影响数据传输的速率。对他们来说，解决所有网络问题就是增加带宽，直至解决为止。
——认为IP网络需要支持QoS传输的人指出，未来5年中，Internet的规模将急剧增大，日增长率也在增加。如此的环境中，需求总会超过容量，因此，网络应该保持优先传送某些分组的能力。对IP网来说，有两种解决此问题的方案比较引入注目：集成服务模型和差异服务模型，它们的
缩写为intserv和diffserv。
1.Intserv和RSVP
——集成服务模型（Intserv）的目标是使得应用程序能在几种不同级别的“传输服务”中为其数据流传输选择合适的一种。Intserv包含两种基本元素：
——（1）可以识别不同服务级别的路由器和主机。这些设备必须能够决定如何处理具有一定特性的数据分组（如特殊的路由，高优先级队列等等）。这种功能有时也被称为Intserv的QoS控制功能。其例子包括控制流量加载和保证流量加载，它们分别在RFC2211和RFC2212中有所概述。
——控制流量加载服务使用接入控制功能来识别符合一定描述特征的数据分组，并确定它们的优先级，使得信息象在没有流量负载的网络中传输一样。但是，即使在控制流量加载服务下，网络在传输时延和可靠性方面，仍然只能采取“尽力而为”的机制，也就是说网络从本质上来讲仍然是不确定的。在有QoS保障的情况下，网络能力数据流提供数学预测时延服务。
——（2）可以使用户或应用程序将他们的要求告知传输节点的一种方法。这种方法一般被称为Intserv的初始化控制功能，在RFC 2205的资源预留协议（RSVP）中有所描述。
——Intserv的实现依赖于这两种基本元素的交互作用和他们在共性数据流上的应用。所谓共性数据流就是指在某些方面相关的一组数据分组，由于这些相关性它们可以被看做一个整体。例如，当Internet网上的一台主机与另一台主机间进行IP电话传输时，具有这种呼叫特性的所有数据分组都可被看作一个共性数据流。之所以能够这样划分，是因为这些数据分组具有共同的目标地址，源地址，共同的传输层端口，还可能有其它一些共同特性。但假若这两台主机间同时也在进行非实时的文件传输操作，那这些文件传输的数据分组就不属于上面的共性数据流，因为至少它们与上面的共性数据流具有不同的传输层端口。这样在网络节点处，就能分开文件传输业务与IP电话业务。
——一般而言，共性数据流对于RSVP和Interv的操作是必不可少的，因为Interv结构使用共性数据流描述，它将数据流的传输要求告之路由器（初始化控制功能），路由器再根据特定的QoS控制参数进行处理（QoS控制功能）。综上所述，Intserv过程包括以下基本步骤（如图6所示）。
——（1）发达应用程序将它所要发送信息所属的共性数据流的特征和需求告知RSVP。
——（2）包含着共性数据流的特征和需求信息的RSVP初始化信息分组在到达预定接收端的过程中，被传输路径上各节点的性能信息修正，形成路径描述表。例如，共性数据流的某个要求是传输节点必须具有1KB的最大可传输单位（MTU），那么沿途的每个路由器都要给出声明，表明它是否有1KB的MTU或是否愿为该共性数据流提供1KB的MTU。
——（3）初始化信息到达接收端后，RSVP就将路径描述表送给应用程序，应用程序可以根据要求来选择合理的路由。一旦接收端应用程序整理出它的需求，它就将其回送给RSVP。
——（4）RSVP将接收端的需求逆着所选路径传给发送端，并沿途取得路由器的属性信息。
——（5）发送端的RSVP进程接收到信息后，就通知发送程序已开通一条可用路由，并指明该路由的特性。
——（6）当发送端初始化信息中的信息流特征描述与接收端要求的属性相匹配时，路由器确认该路由可用并记录该路由属性。
——尽管Intserv的过程有些复杂，但毫无疑问，保存特定信息流的网络特征还是值得的——至少
从个人应用的角度讲应是如此。不难想象，通过Intserv过程，网络上的任何设备都可在任何时间，为它们所进行的任何操作向网络申请确定的服务级别，或者在只需要网络提供尽力而为的服务时不提出任何请求。
——然而Intserv也有其局限性。其一表现为它更多地位赖于Internet的发展规模。而非协议的设计。尽管服务器发送成百上千的RSVP请求并不困难，但由于它要处理同时连在其上的所有用户，因此，网络核心部分的路由器就要有能力保存所有同时经过的信息流的状态信息。这些状态信息就不仅关系到一台服务器和连在其上的用户，而且关系到许多服务器和这些服务器所带的所有用户。因此，位于信息交换密集处的路由器就要同时跟踪百万条交互信息，并为这些交互信息的传输分组分配路由。
——因此，RSVP也象其它全局性协议那样有这样的缺陷，即：即使通信流量并不大，它对节点却可能有较大影响，因为节点需要分配进程能源和存储单元来管理通信流量，记录状态信息。主干线上的路由器光是进行简单的分配路由和存储网络的可达性信息（运行选路协议）的工作就够大了，这还不包括对进程状态信息的管理，这种管理只会增加路由器间的时延。当Internet网络规模增大，速度提高时，需要管理的流量状态信息也相应增加。
——阻碍RSVP广泛应用的另一个原因是ISP间不易达成共识。ISP若允许RSVP信流注册和传送，就要支持同样的QoS控制功能，为给定信息流提供合适的服务等级和足够的存储容量。ISP可能不愿接受这些条件，而使合作失败。
——由于上述原因，许多人认为Intserv和RSVP仅在边缘路由有价值。例如，某个特定ISP所提供的个人VoIP呼叫业务或由单一ISP提供的IP电话业务和其它实时性业务（只要ISP是处于一种管理认证模式下）。显然，Intserv不适合支持大规模VoIP业务和其它Internet上的实时业务。
2.DiffServ和ToS字节
——由于Intserv和RSVP解决Internet的服务质量问题并不如意，人们开始重新关注原来很少用到的IP分组头中的第二字节，即服务类型（ToS）字节。1997年12月，IETF集成服务工作组中的一些人为了找到一种可升级的“服务鉴别”方法，形成了DiffServ（差异服务模型）工作组。DiffServ不象Intserv／RSVP解决方案那样需要复杂的识别和归类方式。它使用“无归属”的分组标识方式，允许路由器根据单一区域内的内容决定如何转发每一个分组。
——按最初规定，IP分组的ToS字节包含两个子区域：前面3个比特决定8种优先级别中的一种，后3个或4个比特用于申请特定的信道性能，如低时延，高吞吐量和高可靠性等，究竟3个还是4个比特取决于执行时间。DiffServ将该字节定为包含单一的6比特域，而剩余的2个比特未用。这6比特域用来选择“差异服务码点”（DSCP），指示路由器和其它节点采取何种方式去处理信息流。这样定义ToS字节向方法与在RFC791中的ToS字节“传统”定义方法完全不兼容（RFC791的ToS字节定义方式存在很多问题）。
——DiffServ的定义方式如图7所示。该模式定义了一个DS域，该域定义了一些支特相同的每一跳行为（PHB）定义的相互连接的路由器。Differs模式假设该域是单一网络服务提供商的网络或是处于同一管理模式下的网络（在这些网络上可以定义共同的PHB）。允许进出DS域的路由器称之为“DS边界节点”，它们根据网络管理者规定的模版来“划分”进入DS域的流量信息。符合特定模版的流量信息可能有其特定的“差异服务码点”，表明DS域中的路由器遵循某一PHB定义。这一码点对于特定DS域外的路由器而言，意义可能相同，也可能不同。
——例如，当为低时延支付了服务费的用户信息进入DS域时，接收边界节点将会为其划分为一个表示“低时延”的码点，这个码点对于该域中的所有路由器含义相同。边界节点为信息划分码点的依据是一些IP分组头属性，包括IP地址，协议类型，甚至还可包括主机初始化分组时设置的DS域参数或主机网络路由器所设置的DS域参数。这样，任何流量属性都可被压缩成一个码点来告知网络该如何处理该流量。
——差异服务的体系结构依赖于对PHB规则的共识，以及这些规则如何与网络期望的服务质量相联系。因此，DiffServ希望经过DS域界的消息服从于一定协议。如服务等级协议（SLA）或流量调节协议（TCA）。尽管出于一致性的考虑，Internet分配号码管理机构（IANA）规定了某些PHB标准，但网络服务提供商们仍有规定他们自己的码点和PHB的权力，来提供他们及其用户认同的服务等级。
3.IPv6的QoS
——Internet协议的下一版本，IPv6，既明确又合蓄地指出了QoS存在的问题。首先，IPv6分组头定义了一个4比特的优先级区域，可以指示16种优先级别。同前面所讲的IP ToS宁节类似。16种优先级别中的9种用于非实时传输业务（象“文件传输”或“无特征流量”），其余的8种用于实时传输业务（比如可用来区分同时传送的语音业务或视频业务）。但是协议中的应用指南并没有严格规定IPv6路由器应如何使用这一优先级区域。其次，这一优先级区域的使用与IPv4的ToS区域的使用非常相似，所以它是否能成功地做为网络优先级机制就要看路由器生产商和应用程序设计者是否愿意支持它。由于IPv4平台上的ToS域未能得到很好的应用。人们必会怀疑IPv6的优先级区域是否会有同样的命运。值得乐观的一点是，由于现在的数据通信业非常重视IP传输的QoS问题，所以必会加大力度推行优先级机制。
——在未来的IP网络中，优先级标签并不是IPv6指出分组的QoS的唯一方法。IPv6的分组头还包括1个24比特的信息流标签，这个标签可由初始化程序来设定，指出某组数据分组属于某种特定的IP信息流。这样，路由器不需要检查地址、程序端口或其它信息，就可将数据分组分类。在IP分组头中带有信息识别号可以使路由器的工作得到简化，因此也就减少了路由器确定数据分组的QoS的时间。但需要注意的是，信息标号并没有表明QoS的提供方式，所以仍需使用RSVP和其它预留协议。
——当然，只有在相当比例的网络服务提供商使用IPv6后，IPv6强大的新功能方会体现出来。但这一点，看起来似乎比较遥远。目前IPv4为提供下一代服务而做的一些修正方法，象流量信息标号、地址分配、定时，甚至地址区扩展等，将大大地延长IPv4的使用期。因此，Internet和其它网络最终完全由IPv4转化为IPv6，可能是先在一些骨干网络进行，然后再在外围网络缓慢进行，最后经过相当长的时间，公司网和个人网也转化到IPv6，从而完成网络由IPv4向IPv6的彻底转化。
——所有的这些标准，从H.323到SIP，到QoS体制（如diffserv）等，都与IP电话网关密切相关。在绝大多数情况下，IP电话网关位于IP网和PSTN网的交界之处。因此，了解IP电话网关设备的构成和功能很有必要。（《CTI世界》2000.04）