SIP結(jié)果/安全

12.6 tel URI

电话URI（tel URI）用于标识占用了某个电话号码的资源。SIP允许将请求送往telURI,这就意味着SIP请求的请求URI可以包含一个tel URI。

tel URI可包含—全球号码或一个本地号码。全球号码遵从E.164号码的规则，以“+”开始；而本地号码遵从本地私有编号计划。本地号码需要有电话上下文（phone-context）参数，用于标识本地号码的上下文（拥有者），也就是号码范围。这就使得该号码是全球惟一的。上下文可以用一个全球号码或域名来表示：前者必须包含一个有效的、被本地号码发行者所拥有的全球号码；后者必须包含一个有效的、已授权给本地号码发行者的域名。下面是一些tel URI的举例：

• 全球号码——tel:+358-9-123-45678。

• 具有域名上下文的本地号码一tel:45678;phone-context=example.com。

• 具有全球号码上下文的本地号码一tel:45678;phone-context=+358-9-123。

注意，telURI允许在号码中含有如连字号之类的视觉分隔符，以提高可读性。telURI的参数之间用分号“；"分隔。［RFC3966］中可以找到所有telURI的语法。

12.7SIP结构

SIP是一个分层协议，其中不同模块功能相对独立，各层间仅保持松散耦合。图12-4清楚地展示了所采用的分层方法。

图12-4  SIP协议层次

12.7.1 语法和编码层

协议的第一层（最底层）是语法和编码层。编码采用增强的巴柯斯范式（BNF）语法，[RFC3261]给出了其完整描述。

12.7.2 传输层

第二层是传输层。正如其名称所示，该层起到告知客户端如何发送请求和接收响应以及服务器如何接收请求和发送响应的作用。传输层与SIP实体的套接字(socket)层密切相关。

12.7.3事务层

第三层是事务层。在SIP术语中，一次事务是指客户端发送到服务器的一条请求，以及从服务器送回客户端的所有对该请求的响应。事务层处理响应与请求之间的匹配。应用层的重传和应用层的事务超时也都在该层处理，并依赖于所使用的传输协议。客户端事务发送请求并接收响应，而服务器事务则接收请求和发送响应。事务层利用传输层来发送和接收请求及响应。

事务层有四个事务状态机，每个事务状态机有其自身的定时器、重传规则和终止规则。

• INVITE客户端事务。

• 非INVITE客户端事务。

• INVITE服务器事务。

• 非INVITE服务器事务。

12.7.4事务用户层

第四层是事务用户（TU）层，该层创建客户端和服务器事务。当TU希望发送SIP请求时，它创建一个客户端事务实例（instance）,并把目的IP地址、端口号和所使用的传输协议等放在请求中一起发送。TU被定义为UAC核和UAS核，或简称为UAC和UASoUAC使用事务层创建和发送请求并接收响应，而UAS使用事务层接收请求并创建和发送响应。

有两个因素可以影响TU行为：一个是SIP消息中的方法名，另一个是请求的对话状态（对话将在12.9节中讨论）。

除了这两个因素外，TU以标准方式工作。相关内容在以下各部分进行介绍。

12.7.4.1UAC行为

对于在对话以外到达的请求，UAC需要采取的步骤包括填写请求URI、To消息头、From消息头、Call-ID消息头、CSeq消息头和Via消息头。其他消息头，例如Require头（用于指示UAC要求的SIP扩展）和Supported头（用于指示UAC支持的SIP扩展），也可以填入其中。如果该请求要创建一个对话或要进行注册绑定，则必须加入Contact消息头。任何其他的内容也可在这一阶段填加，包括消息正文。当SIP请求中出现消息正文时，Content-type和Content-length消息头也必须填加。

• To消息头填写为目标AOR（AOR类似于名片地址）。

• From消息头填写为发送者AOR,此外还填加一个标签（tag）参数。标签是用于标识对话的一种手段。

• Call-ID消息头填写为一个惟一的标识符。

• CSeq消息头用来标识事务的先后顺序。对于对话以外的请求，CSeq号码是任意数值。包含两部分，一个CSeq数值和一个方法名，二者由空格分开。方法部分填写为请求行中的方法。

• Max-Forwards消息头用来限制请求所经过的跳数，以避免回环，其典型值为70（表示跳数）-每经过一跳该值递减1。

• Via消息头包含两块关键的信息：传输协议和响应消息应该发往的地址。协议名称和版本号总是设为SIP和2.0oVia消息头包含一个标识事务的分支（branch）参数，用于将请求与响应相匹配。该参数必须是惟一的。符合本规范的分支参数值总是以字符串“z9hG4bK”开头。

• Contact消息头一般填写为发起该请求的主机地址的URIo

• 请求URI通常与To消息头中的数值相同。REGISTER请求是一个特例,其中的请求URI填写为登记员地址。

UAC可以有一个预置的路由集，即UAC希望请求在到达目的地之前途经的中间节点集合，包括出站代理(outbound-proxy)。该路由集放在请求消息的Route头中。在这种情况下，请求URI的值可能会根据Route头的最顶端是否包含“宽松路由(loose-route)”参数而有所区别。12.12.2节会解释宽松路由的概念以及当下一跳是宽松路由器时应该如何设置远端目的地。把请求URI设置为远端目的地时遵循12.12.2节中的过程。

UAC必须依照12.12节中定义的规则对请求进行路由。

UAC还对它所发出的请求的响应进行处理。这些响应可以是超时错误响应或SIP成功或失败响应，包括重定向响应(3xx)。

12.7.4.2UAS行为

对于在对话以外到达的请求，UAS检查请求中的方法以进行识别，并检查请求URI和To信息头以确定自己是否为该请求的目的地。如果两个检查中的任意一个失败，则返回一个错误响应。

然后UAS判断是否有扩展的要求，如果它不能满足扩展要求则返回一个错误。如果能够满足，则UAS继续处理该请求，检查和处理请求的内容(消息正文)。

如果以上步骤均成功，UAS就能采用UAC支持的所有扩展(如Supported消息头所指示)。随后的请求处理就取决于具体的方法了：对REGISTER请求的处理参见12.8节，对INVITE请求的处理参见12.10节。

一旦UAS处理完请求后，它就产生一个响应，该响应可以是临时的或是最终的。针对一个请求可以发送多个临时响应，但最终响应只会发送一个。一般来说,只有在对INVITE请求进行响应时才发送临时响应。

当产生一个响应时，响应中的From消息头、Call-ID消息头、CSeq消息头、Via消息头和To消息头等都是从请求消息中复制过来的。请求中Via消息头的顺序必须保持不变。

如果请求中包含有To消息头的标签参数，则不允许再产生新标签。然而，如果请求中的To消息头不含有标签，则UAS必须在响应中给To消息头添加一个标签。对于“100”临时响应来说，To消息头标签并不是必需的。该标签作为标识一个对话的多个组件之一，它还被分叉代理用来标识UAS。

12.8 注册

SIP支持用户移动性(usermobility)和发现(discovery)的概念。用户可以通过将自己的AOR与某个主机地址进行明确绑定，使自己可以被联络到。这就使用户移动性成为可能，因为用户可以通过支持SIP的任何设备进行注册，包括个人计算机、无线设备和蜂窝电话。

为一个SIP请求发现其希望到达的接收者，是典型的SIP中间服务器的功能。例如，用户创建一个与登记员之间的绑定，该登记员作为去往存储所有绑定记录的位置服务器的前置单元，当一个代理服务器收到的请求是发往其负责区域内的节点时，它就与这个位置服务器联系，以获取接收者的确切位置。

用户通过在To消息头中放置其AOR和在Contact消息头中放置主机地址来形成一个绑定。

用户通过从每个设备发送一个REGISTER请求，就可以实现同时从多个设备进行注册。同样，用户可以从同一个设备创建多个绑定，这可以通过发送一个与AOR有多个绑定的REGISTER请求来实现。要做到这一点，用户会在REGISTER请求中加入多个Contact消息头。

用户可以通过一个称为“注册领取”的过程来发现当前其AOR的所有绑定，这是通过发送一个没有Contact消息头的REGISTER请求来实现。登记员在对REGISTER请求的响应中返回当前所有绑定。在响应中，每个绑定都有一个它自己的Contact消息头。

SIP注册从本质上讲是软状态，这意味着注册的绑定必须周期性刷新。一个绑定的过期时间通过注册实体在Contact消息头里使用的过期参数来指示。如果该参数没有出现，则登记员会认为过期时间为Ih。若UA没有刷新或明确清除该绑定,则当绑定过期时，登记员将直接将其删除。UA可以通过发送一个REGISTER请求来明确地清除一个绑定，该请求中对要清除的绑定添加一个Contact消息头，该Contact消息头包含的过期参数值为O。

可使用第24章中的各个过程来进行有关登记员的讨论。

12.9对话

对话是通信双方之间的一种sip关系，它提供了在通信双方之间进行路由和消息排序时所依据的必要的状态信息。

对话使用对话ID来标识，UA用它来跟踪属于同一个对话的消息。对话ID由呼叫ID、本地标签和远端标签组成。对于UAC来说，本地标签就是在创建对话的初始请求的From消息头中的标签，远端标签就是创建对话的响应的To消息头中的标签。对于UAS来说，本地标签就是在创建对话的响应的To消息头中的标签，远端标签是创建对话的初始请求的From消息头中的标签。对于任意一端发出的该对话中的后续请求，本地标签放在From消息头中，而远端标签放在To消息头中。

请注意UAS也要接收From消息头中没有任何标签的请求，这时认为标签中包含了一个空值。

在一个对话中创建、发送、接收和处理消息时需要用到对话的状态。该状态由对话ID、本地序列号、远端序列号、本地URI、远端URI、远端目的地、一个称为“安全"标记的布尔标记以及一个路由集组成。

当某个对话处于“早期”状态时，它就称为“早期对话”。这在对初始请求的临时响应到达UAC时发生，这时一个对话就创建起来。当“2xx”成功响应到达时，对话就进入“确定"状态。若“2xx”类响应以外的其他最终响应到达，或根本没有响应到达时，早期对话便终止。

当UAS用表示成功的最终响应对一个请求进行应答时，它必须将出现在请求中的所有Record-Route消息头复制到响应中，并维持它们的顺序不变。然后UAS将Record-Route消息头中的那些URI存储为路由集，并维持其顺序不变。如果没有出现Record-Route消息头，则路由集置为空。该路由集合即使是空的，仍将在对话的后续部分中保持不变。这就意味着本对话中各请求消息的其他Record-Route消息头不会覆盖现有的路由集。

如果消息途径的中间服务器希望对话期间内所有从UAC发往UAS或者从UAS发往UAC的后续请求的信令仍然经过自己，它就在请求消息中添加一个Record-Route消息头。

UAS还必须在响应消息中添加一个Contact消息头，以指示对话内后续请求的目的地址。

UAS处的对话状态构成如下：

•  如果到来的请求是通过TLS传输的，且请求URI包含一个SIPSURL则"安全”标记设为真；否则设为假。

•  远端目的地设置为请求消息中Contact消息头内的URI。

•  远端序列号设置为请求消息中CSeq头内的序列号。

•  本地序列号在此阶段保持为空，当远端发送一个属于本对话内的请求时再填写。

•  远端URI设置为From消息头中的URI。

•  本地URI设置为To消息头中的URI。

•  对话ID如上所示来创建。

•  路由集如上所示来设置。

UAC必须在创建对话的初始请求中提供一个Contact消息头。当UAC收到一个创建对话的响应时，它根据如下步骤来创建自身的对话状态：

• 如果请求基于TLS发送并且请求URI包含一个SIPSURI，则“安全”标志设为真；否则设为假。

• 远端目的地设置为响应消息中Contact消息头的URIo

• 远端序列号在此阶段设置为空，当远端在对话期间发送一个请求时再填

写。

• 本地序列号设置为请求消息中Cseq头的序列号值。

• 本地URI设置为From消息头中的URI。

• 远端URI设置为To消息头中的URI。

• Dialog-ID如上所示来创建。

• 路由集用Record-Route头中的URI来设置，但其顺序进行了翻转。如果没有Record-Route头出现，则路由集设置为空。该路由集即使为空，仍将保留用于对话的余下部分。这就意味着出现在对话请求中的其他Record-Route消息头不会覆盖现有的路由集。如果路由集是由一个临时响应中的Record-Route头来生成的,则确认对话的2xx最终响应会使用其Record-Route头中的URI来重置路由集，但这次顺序又是翻转的。

对话内的请求填写要用到对话状态。每当对话中产生一个新请求时，本地Cseq消息头的值就加1。如果对话内的请求是目的地刷新请求，则可能更新远端目的地。目的地刷新请求的例子如INVITE请求和UPDTAE请求。

当返回一个非2xx的最终响应时，早期对话便会终止。已确认的对话根据所采用的方法不同，其终止方式也不同。

12.10会话

多媒体会话由一组多媒体发送者和接收者及其彼此之间的数据流组成，会话采用sip对话并在对话期间发送请求时遵循sip规则。

SIP在建立多媒体对话中扮演的角色以其在消息正文中携带SDP媒体描述的能力为核心。SDP用来描述会话，并采用提供/应答模型［RFC3264］。SDP和提供/应答模型在第14章讲述。12.10.1节描述了SIP对该模型的限制。

会话由INVITE方法、请求行和消息头发起，这些都由UAC来填写（见12.7.4.1节）。消息体中填入SDP提供。SDP应答可能在临时响应或2xx响应中到达。

INVITE请求遵循三次握手模型，即UAC在收到对INVITE请求的最终响应后，必须发送一个ACK请求。该ACK请求并不要求响应。实际上，对ACK请求发送响应也是不允许的。

在发送INVITE请求后，如果UAC想取消这次会话邀请，它可以发送一个CANCEL请求。CANCEL请求使用类似方法构造，其请求URI、To消息头、From消息头、Call-ID消息头以及CSeq消息头的数字部分都是从INVITE请求中复制过来的。CSeq消息头的方法部分的内容为“CANCEL”。收到CANCEL的UAS用200响应对其应答，紧接着对INVITE请求发出一个“487请求终止”响应。需要注意的是所有事务都必须彼此独立地完成，因此UAS不仅需要对CANCEL进行响应，还必须对INVITE请求进行响应。

如果UAC对2xx响应中的SDP应答不满意，就发送一个ACK请求后面跟着一个BYE请求来终止会话。如果UAS对SDP提供不满意，它就用488响应来拒绝该请求。

INVITE请求也可在对话期间发送，以对会话描述进行重新协商。

一个会话通过BYE请求来终止。BYE请求的发送和对话中其他请求的发送方式一样。

SIP中的SDP提供/应答模型

在基本的SIP中，提供和应答只能出现在INVITE请求中以及对INVITE请求和ACK请求的可靠响应中。然而，12.13.4节和12.13.5节则描述了SIP扩展中进行提供/应答交换的更多机会。

如果一个INVITE请求创建多个对话，则每个对话都有自己单独的提供/应答交换。

提供/应答交换的一个通用原则就是，如果前面发出(收到)了一个提供，那第么只有该提供已经收到(或发出)了应答，才可以发送下一个提供。该原则将基4本SIP限制在以下两种提供/应答交换的可能情形中：

• 如果提供存在INVITE请求中，则回答必须出现在对INVITE的2xx响应分中。

• 如果INVITE请求没有包含一个提供，则2xx响应包含提供，ACK包含应答。

议

12.11安全

12.11.1威胁模型

SIP可能会遭到以下威胁和攻击：

• 拒绝服务(Denialofservice)DOS攻击的结果就是遭受攻击的实体变成不可用。这包括如下情况：针对某个UA或代理发送大量请求。组播请求就是另一""例子。

• 窃听(Eavesdropping)——如果消息以明文发送，任何恶意用户都可以窃听并获取会话信息，从而轻而易举地发动各种拦截类的攻击。

• 拆除会话(tearingdownsessions)——攻击者可插入类似于CANCEL请求之类的消息来阻止呼叫方与他人的通信，也可通过发送BYE请求来终止会话。

• 注册拦截(registrationhijacking)——攻击者伪装成某用户进行注册，从而将所有去往该用户的流量引导到攻击者自己的机器。

• 会话拦截(sessionhijacking)攻击者可在对话中发送INVTIE请求，来请求对发送途中的请求进行修改，通过修改会话描述把媒体流引导到其他地方。会话拦截者也可用3xx-类型的响应来对呼叫者进行应答，从而将会话建立请求重定向到攻击者自己的机器。

• 冒充服务器(impersonatingaserver)——装自己是服务器并伪造一个响应，这样原来的消息就可能被错误地路由。

• 中间人(maninthemiddle)——这种攻击中，攻击者篡改发往接收者过程中的消息。

12.11.2安全框架

SIP安全框架包含六个方面：

• 认证(Authentication)——识别某实体或用户并确保该用户确实是其自称的用户的方法，典型方法包括用户ID,口令或使用密钥散列进行数字签名。

• 授权(Authorization)——旦用户通过认证后，就必须对其授权。授权包括决定是否允许已确认身份的用户访问他所要求的服务，通常使用访问控制列表(ACLs)来实现。

• 机密性(Confidentiality)这用于消息必须保持机密并且只允许特定接收者看到消息内容的场合，通常通过加密的方法来实现。

• 完整性(Integrity)——用户需要确保消息在途中不被篡改。消息完整性检查是确保完整性的方法之一。

• 隐私性(Pricacy)——用户的匿名是一个关键因素。用户不想其他人知道他是谁，他的通信内容以及他在与谁通信。

• 不可否认(Non-repudiation)提供反向保护。

12.11.3机制和协议

12.11.3.1逐跳机制

逐跳认证给用户提供了完整的机密性。它包括一个复杂的安全体系，该体系要求每个代理对消息进行解密，因此该体系依赖于各跳之间的信任关系。SIP现在使用两种安全协议，IP安全(IPsec,第22章)和传输层安全协议(或称TLS,第18章)。.

1.SIP、TLS和SIPSURI.

TLS可以实现认证、完整性和机密性。正如前面所提到的，SIP消息中若使用TLS要求，则所有SIP实体都要使用SIPSURIo即如果UAC希望进行安全通信,就在To消息头中放置一个SIPSURIo如果下一跳URI或SIP请求的请求URI包含SIPSURI,则UAC必须在Contact消息头里放置一个SIPSURI。如果请求URI包含一个SIPSURI,则请求的任何备选目的地也必须用TLS来联系。

用TLS来保证安全的请求必须使用可靠的传输层协议，如TCP或流控制传输协议（SCTP）o发送TLS安全请求和发送TLS安全响应的默认端口都是5061。

当注册一个绑定时，UAC必须在Contact消息头里创建一个SIPSURI,除非它能保证Contact消息头里的主机有其他的安全措施。

当UAS用能创建对话的响应（非失败响应）对能创建对话的请求进行响应时，如果请求URI、Record-route消息头顶端（如果有该消息头）或Contact消息头（如果没有Record-Route消息头）中含有SIPSURI,则UAS要在该响应的Contact消息头里放入一个SIPSURIo如果收到的请求是基于TLS（Via消息头显示传输协议为TLS）的，则UAS必须用TLS来发送响应。

当在对话期间发送请求时，UAC和UAS检查对话状态中的“安全”标志。该标志为真时，则要求UAC和UAS在Contact消息头里放入一个SIPS URI。

对于插入Record-Route消息头的代理而言，如果请求URI或Route消息头顶端（在对请求进行处理后）有SIPSURI,则他们必须在消息头里插入一个SIPS URI。

如果下一跳URI是SIPSURI,所有SIP实体都必须使用TLS。如果初始请求中的请求URI包含SIPS URI,并且收到了对该请求的3xx响应，那么实体在按照3xx响应里的Contact消息头来发送新请求时，不应给其中的非SIPSURI发送新分请求。SIP实体在进行下一跳发现过程时（12.12节），不论使用哪种URI作为过协程的输入，只要请求-URI中列出了一个SIPS资源，SIP实体就必须遵循与输入URI是SIPSURI时相同的过程。

代理对响应进行处理时，如果要将来自非TLS连接的请求转发到TLS连接上时，则它会把放在Record-Route消息头里的URI由SIPS URI改为SIPURI。同样，当代理处理响应时收到从TLS连接来的请求并把它转发到非-TLS连接上，则将它放在Record-Route消息头里的URI由SIP URI改为SIPS URI。

SIPS URI的格式与SIPURI的格式惟一的不同点在于模式（scheme）不同：SIPSURI以“sips”开头，而SIPURI以“sip”开头。因此SIPURI和SIPSURI是不能等同的。

2.IPsec

IPsec通过在IP层对SIP消息提供安全来实现认证、完整性和机密性，它同时支持TCP和UDP（详细内容见第22章）。

12.11.3.2用户到用户和代理到用户机制

用户到用户（或端到端）和代理到用户的安全可以被认为是一种更安全的机制，因为只有两个实体可被攻击。SIP中使用两种协议来实现这种机制，即SIP摘要和安全多用途因特网邮件扩展或称S/MIME[RFC2633]。另外，在第三代伙伴计划（3GPP）的IMS中，采用了一种对摘要框架的扩展（即摘要AKA）。

1.摘要认证

SIP摘要认证大部分采用了HTTP摘要［RFC2617］认证机制，只有少量的改动。虽然摘要提供的完整性保护是有限的，但确实能提供客户端认证和阻止重放攻击（replay）。它还能提供一种互相认证的能力，使得客户端能认证服务器。

摘要认证要求共享密钥，这就意味着所有用户间以及用户和代理间都需要有一种先前存在的关系。在公共服务中，这个要求很成问题。

2.摘要AKA认证

如3.20.2节所述，IMS的认证采用了UMTS的认证和密钥协商（AKA）协议。该协议需要在SIP信令内传输，这就是摘要AKA的基本思想：将AKA协议和摘要认证框架集成起来。

现实中，这就意味着AKA认证请求被封装在401“未授权”响应的WWW-Authenticate消息头中或407"要求代理认证”响应的Proxy-Authenticate头里。同样，客户端认证响应被封装在请求消息的Authorization消息头或Proxy-Authorization消息头中。

AKA参数（即随机挑战（或RAND）和网络认证标志（AUTN））是串在一起的，并添加在服务器的当前参数之后。响应（RES）可以从响应摘要中计算出来，方法是简单地将RES参数视为摘要密码。使用摘要AKA的正常认证流程如图12-5所示。

图12-5正常的摘要AKA消息流程

（［］表示该元素可选，且消息语法仅仅是描述性的）

不能完全遵循摘要框架的惟一例外发生在AKA同步失败时。这时，同步失败参数AUTS被包含在扩展的摘要参数中，采用Base64编码：这样做的原因仅仅是没有其他更合适的协议元素来携带该参数（见图12-6）。

图12-6同步失败时的摘要AKA消息流程

(口表示该元素可选，且消息语法仅仅是描述性的)

3.S/MIME

安全的多目的互联网邮件扩展(S/MIME)通过加密和/或签名的S/MIMESIP消息正文来保护SIP消息头，从而提供消息的完整性、机密性和认证，该方法不需要共享密钥。