SIP擴(kuò)展

12.12.1 服务器发现(discovery)

本节中所介绍的过程是最小化的，仅展示最基本情形下所需要的步骤(完整过程请参考［RFC3263］)。

12.12.1.1发送请求

TU层通过使用它选择的URI作为下一跳URI来进行下一跳发现(见12.12.5节)。基本步骤如下：

• 如果URI包含transport参数，则使用该传输协议。

• 如果URI包含数字IP地址而不包含transport参数，那么就使用该IP地址和所给出的端口(如果没有指定端口，则使用默认端口)来发送请求。SIPURI使用的传输层协议为UDP,而SIPSURI使用的传输层协议为TCP。

• 如果sent-by字段包含一个域名和一个端口号，则进行A（IPv4）或AAAA（IPv6）查询，所得到的IP地址和可用端口被用来发送响应。SIP URI使用的传输层协议为UDP,而SIPSURI使用的传输层协议为TCP。

• 对于没有数字IP地址或端口的URI,可通过查询域名系统（DNS）服务器来获取URI中域名的名称权威指针（NAPTR）记录，然后再对其进行检查。

• 如果有多个不同的传输协议可用，则TU根据外部因素（如配置）选择一个传输协议。

• TU根据所选的传输层协议和NAPTR记录来查询DNS服务器以获取服务（SRV）记录，服务器可能返回一条或多条SRV记录。

• 接着通过对每个记录进行A或AAAADNS查询，来对这些记录顺序地进行测试，从而可以找到该请求需要发往的IP地址和端口。请注意，对SRV记录进行A或AAAA查询可能会导致多个IP地址返回，应该依次试用其中的每一个地址，并且只有在所有试用都失败后才能对下一个SRV记录进行下一次A或AAAA查询。

12.12.1.2发送响应

当UAS使用"sent-by"字段中的源IP地址和端口发送请求遭遇失败时，执行以下过程：

• 如果sent-by字段包含一个数字IP地址，则使用其给出的端口来发送响应（或者如果没有指定端口，则采用默认端口）。

• 如果sent-by字段包含域名和端口，则进行A或AAAA查询，所得到的IP地址和可用端口被用来转发响应。

• 如果sent-by字段包含域名但不包含端口，则对域名进行SRV记录查询。接着通过对每个记录进行A或AAAA DNS查询，来对这些记录顺序地进行测试，从而可以找到该响应需要发往的IP地址和端口。注意，对SRV记录进行A或AAAA查询可能会导致多个IP地址返回，应该依次试用其中的每一个地址，并且只有在所有试用都失败后才能对下一个SRV记录进行下一次A或AAAA查询。

12.12.2宽松路由的概念

宽松路由在［RFC3261］中有所介绍，它为消息的多跳转发提供了一种更可靠的方式，并且提供了一种方法使得请求URI在请求消息到达负责为它服务的代理（即对请求URI中的域负责的代理）的整个途中都能保持不变。

携带有宽松路由参数的SIPURI表明该SIPURI的所有者（一般是中间服务器）遵循［RFC3261］并支持宽松路由。这样的URI的一个例子如sip:proxy.example.com;lr,其中lr参数该实体为宽松路由器。若没有该参数，则表明下一跳为严格路由器。

12.12.3代理行为

对于所有新请求，包括那些带有未知方法的请求，状态感知代理将进行以下操作：

• 对请求进行验证。

• 预处理路由信息。

• 确定请求的目的地。

• 转发该请求到每个目的地。

• 处理所有响应。

[RFC3261]详细描述了每一个步骤。为了完成路由分析，代理所采取的路由请求步骤如下：

• 如果请求URI中包含了本代理以前曾放入到该请求Record-Route消息头中的一个URI,则代理用填入最后一个Route头的URI来替换它,然 后将这个Route头删除。

• 如果第一个Route头包含本代理的URL则代理将这个Route头删除。

• 如果请求URI的域名指示的是不应由本代理负责的域，则仅仅将该请求URI放置在为该请求执行代理功能的目的地的地址集合中，之后就转发该请求。

• 如果请求URI的域名指示的是由本代理负责的域，则代理使用为它配置的各种机制来确定目的地集合。代理提取集合中的第一个目的地，将它放置在请求URI里。如果该代理希望这个对话的后续请求仍经过自己，则在Record-Route消息头最顶部再添加一个Record-Route消息头。这个Record-Route消息头里的URI必须包含lr参数，并且必须是SIP或SIPS URI。

• 如果代理服务器希望SIP请求在到达最终目的地之前经过一些实体，则要把那些实体的地址作为Route头插入在全部其他Route头之上（如果有的话）。代理需要确保这些实体是宽松路由器。

• 如果请求包含Route头,则代理检查最顶部的Route头。如果最顶部Route头不包含lr参数，则代理将请求URI放入一个Route头里作为最后一个Route头。然后，把最顶部Route头里的URI放入请求URL并去掉该Route头。接着，代理使用12.12.5节中的步骤来发送请求，并将计算得到的目的地集合中的第一个目的地设为路由集合中的条目。

代理服务器可能顺序地或并行地试用目标集里的每个地址，此概念称为“分叉（fbrking）”。

12.12.4填写请求UR1

UAC根据远端目的地和路由集合来形成请求-URL具体如下:

• 如果路由集合为空，则将远端目的地放置在请求URI内。

• 如果路由集合不为空，且最顶端URI为宽松路由器，则将远端目的地放置在请求URI内。Route头用路由集合来创建。

• 如果路由集合不为空，且最顶端URI为严格路由器，则将最顶端URI放置在请求URI内。Route头用路由集合来组建，但不包含该路由集合中的最顶端URIo然后，将远端目的地作为最后一^Route头。

12.12.5 发送请求和接收响应

12.12.1.1节中列出的过程被TU层用来发送请求，具体如下：

• 如果路由集合里的最顶端URI指示下一跳为严格路由器，因而按照12.12.4节中相应条目所述生成了请求，则12.12.1.1的这些过程被应用于请求URI。

• 如果路由集合里的最顶端URI指示下一跳为宽松路由器，则这些过程被用于路由集合中的最顶端URI。-

• 如果没有路由集合，则这些过程被用于请求URI。

然后，TU创建一个事务实例并将请求、IP地址和端口传给它，并指明所用的传输层协议。事务层将该信息传递给传输层，传输层按照下述进行请求发送：

• 在到达目的地的途中，如果请求的字节在最大传输单元（MTU）200B以内，则必须用带有拥塞控制的协议（TCP或SCTP）来发送请求。

• 如果MTU不可知，并且请求的长度大于1300B,则必须用带有拥塞控制的协议（TCP或SCTP）来发送请求。

• 如果Via消息头中指定的传输协议在以上步骤后需要更改，就将它更改。Via消息头的sent-by字段填写为一个IP地址和一个端口号（或者更可取的是用FQDN）。

接收到的响应用Via消息头里的分支（branch）参数来与请求匹配。

12.12.6 接收请求和发送响应

如果请求是从与其Via消息头sent-by字段所指示的地址不同的另一个IP地址发来的，则事务层会在Via消息头里添加一个“received”参数，并将它的值赋为发来该请求的IP地址。接着，该请求与一个服务器事务相匹配或（如果没找到匹配）传给TU,TU会选择创建一个新的服务器事务实例。

一旦TU完成请求处理并产生了响应，它就把响应传递给发送了该请求的事务实例，事务层将这个响应转交给传输层。传输层进行以下处理：

• 如果请求在面向连接的协议上收到，那么响应在相同连接上发送。

• 如果连接不再是打开状态，则使用sent-by字段中的参数和端口（没有定义端口的话，则为默认端口）打开一个新的连接并发送请求。

• 如果没有参数，则遵循12.12.1.2节中的过程。

12.13  SIP扩展

12.13.1事件通知框架

为了实现事件通知，对SIP进行了扩展。一个用户或资源订阅向其他资源发起订阅，由于后者有前者感兴趣的事件，之后前者会接收有关该事件的状态和任何变化的通知。

SIP的SUBSCRIBE方法用于订阅，而NOTIFY方法用于传递一个事件的任何变化的通知。

[RFC3265]是有关该扩展的IETF资料，它以通用的方式描述了订阅和通知的框架，并给出了创建SUBSCRIBE请求和NOTIFY请求的规则。它还描述了订阅方在发送和接收订阅请求时的行为，以及通知方在接收订阅请求和发送通知时的第行为。

事件通知框架在引入了SUBSCRIBE和NOTITY方法的同时，还引入了新的SIP消息头和响应代码。

• 事件（Event）消息头——这个消息头标识订阅方订阅的通知所针对的事协件。

• 允许事件（Allow-Events）消息头——向接收者指示本消息头的发送者理解事件通知框架，该消息头中的标志指示它支持哪些事件包。

• 订阅状态（Subscription-State）头——指示一个订阅的状态。“激活"、“等待”和“终止”是规范定义的三种订阅状态。该消息头还携带导致进入当前订阅状态的原因：“去激活”、“检验”、“拒绝”、“超时”、“放弃”和“无资源”等。对于订阅状态和原因值还可以进行扩展。

•“202接受（Accepted）”响应一一指示订阅请求已被初步接受，但还需等待最终决策，最终决策将在NOTIFY请求中给出。

•“489无效事件（BadEvent响应当通知方不能理解Event头里描述的事件时，就返回该响应。

SUBSCRIBE请求是触发建立对话的请求。当SUBSCRIBE请求的2xx响应或NOTIFY请求到达时，就创建一个对话。后续SUBSCRIBE和NOTIFY请求在创建的对话内发送。

首个SUBSCRIBE请求中的请求URJ用于说明订阅方希望接收的状态信息源。Event消息头标识与这次订阅有关的事件。

和注册类似，订阅采用软状态因而需要刷新。订阅的持续时长由Expire消息头来指示。如果该消息头没在SUBSCRIBE请求中出现，则缺省值为lh。如果持续时间内没有刷新，订阅将被终止，也可在对话期间通过发送一个SUBSCIRBE请求并将其Expire头的值设定为0来明确地终止一个订阅。

事件通知框架还引入了事件包的概念作为对框架的一种扩展，所产生的每个事件包都为事件通知框架引入一个新的用例。

NOTIFY请求的净荷（正文部分）用来携带状态信息，每个事件包都为携带的这些信息定义自己的MIME类型。

事件模板包是一种特殊的事件包，这类事件包与其他事件包相关联，包括它自己。模板包定义了能应用到其他事件包中的状态。对模板包的订阅是通过在Event消息头中在事件包后面追加一个句号来实现的，句号后面紧跟模板包的名称，Event:presence.winfo.

12.13.2状态的发布（PUBLISH方法）

事件通知框架定义了如何订阅事件的状态以及如何获取事件状态的变更通知，它没有定义如何进行状态发布。然而，SIP扩展中的状态发布规范［RFC3903］允许客户端向状态代理发布它的事件状态，状态代理充当这些状态的汇聚者并产生通知。这是通过使用PUBLISH方法来实现的。

PUBLISH请求采用软状态因而需要刷新。发布者用［RFC3265］中（以及12.13.1节中）定义的Event消息头来指示正在发布哪个事件的状态，而请求URI被用于指示正在发布的那个资源的状态。客户端使用一个实体标签（entitytag）,并且服务器也支持，以使得客户端可以使用PUBLISH方法来实现状态的更新。资源的状态由PUBLISH请求的正文内容来携带。

12.13.3 即时消息的SIP扩展

要获知即时消息（instantmessage）更详细的叙述，请参考第5章。

SIP通过引入［RFC3428］中定义的MESSAGE方法来扩展，以支持即时消息。

即时消息有两种交换模式，即页面模式和会话模式。MASSAGE方法用于页面模式。页面模式是一种单次的即时消息，即后续的即时消息与之前的即时消息在协议层无关。页面模式用于当对话或事务并非不可预见时。

MESSAGE请求中的请求URI指明请求所要发往的资源。MESSAGE请求正文部分携带着即时消息的实际内容，该内容也是某种MIME类型的。MIME正文普遍使用"text/plain”MIME类型。为了以IETF标准方式与非SIP即时消息客户实现互操作，需使用［RFC3862］“通用在线状态与即时消息：消息格式”中定义的MIME类型"message/cpim"。

基于会话的即时消息使用SIP作为信令，并在会话建立后使用消息会话中继协议（MSRP）来携带数据（即时消息）（有关如果使用SIP和SDP来建立即时消息以及MSRP如何工作的细节，见5.4节）。

12.13.4临时响应的可靠性

在基本SIP中，临时响应的传输是不可靠的，这与INVITE请求的2xx响应不同。后来人们发现临时响应的可靠性在有些情形下很重要而且很有用，因此定义了［RFC3262］。在3GPP中，可靠临时响应及其确认被用来交换附加的SDP提供/应答消息。

关于临时响应可靠性的SIP扩展仅应用于INVITE请求。

当一个UAC产生INVITE响应时，通过在INVITE请求中包含一个Supported消息头以及选项标签“l00rel”，来表明他支持可靠临时响应扩展。UAC通过在INVITE请求的Require消息头中放入选项标签“l00rel”来表明它要求UAS也支持可靠临时响应扩展。

如果UAS接收到一个Require头携带着可选参数“l00rel”的INVITE请求，但UAS并不支持这种扩展，则用出错响应“420无效扩展”来应答。如果选项标签出现在Support头中，则UAS可以将其忽略。

如果“l00rel”选项标签出现在Require消息头中，支持该扩展的UAS必须对临时响应进行可靠传输；如果选项标签出现在Support头中，支持该扩展的UAS可以选择对其进行可靠传输。

当UAS发送一个可靠的临时响应时，它将扩展消息头RSeq放置在临时响应中并把选项标签"lOOrel"放置在Require头中来指示这一情况。RSeq中的内容是一个1〜（231-1）之间的整数。

可以对同一个INVITE请求发送多个可靠的临时响应。任何后续的可靠临时响应的RSeq值都必须比相同事务空间内（相同INVITE事务内）的前一个响应的RSeq值大1。

收到可靠临时响应的UAC用一个临时响应确认（PRACK）请求来应答。PRACK请求携带有一个RACK头,该头依次包含RSeq头的值以及CSeq头中的值。

正如其他请求一样，PRACK必须得到响应。UAS推迟对INVITE请求发送2xx,直至它发出的所有可靠临时响应都收到PRACK请求为止。例子如下：

• Require:l00rel

• RSeq:12345

• RACK:12345 1 INVITE

“100尝试中”响应不是可靠发送的。

使用PRACK请求的SDP提供/应答模型

12.10节描述了使用基本SIP时提供/应答遇到的限制，本节为提供/应答的交换提供了额外的机会。

•如果INVITE包含一个提供，则在可靠临时响应中可能出现一个应答。

•如果INVITE不包含一个提供，则这个提供必须在第一个可靠临时响应中出现。

•如果可靠临时响应携带着第一个提供，则应答必须出现在PRACK中。

•如果可靠临时响应携带着一个应答，则PRACK可能携带另一个提供。

•如果PRACK携带着一个提供，则PRACK的2xx必须携带一个应答。

12.13.5 UPDATE方法

UPDATE方法是SIP的一个扩展，它使UA可以在不影响对话的情况下更新会话描述。UPDATE方法可在对话的早期阶段和确定阶段发送，但禁止在对话创建之前发送(例如在创建对话的临时响应发送/接收之前)。它的创建方式与对话中的其他请求一样。

UPDATE请求可以由主叫方(INVITEUAC)或被话方(INVITEUAS)发送，仅可以用于会话。这意味着UPDATE请求仅用于由INVITE请求产生的对话。

UAC通过在INVITE请求中包含一个Allow头并将UPDATE列为一种方法,来表明它希望支持对UPDATE方法的扩展。UAS则通过包含一个Allow头并用黑UPDATE方法来传递临时响应，来表明它希望支持UPDATE方法。

UPDATE请求是一个目的地刷新请求，即它可以更新一个对话的远端目的地。

  使用UPDATE请求的SDP提供/应答模型

UPDATE请求总是携带着提供，而2xx响应则携带着应答。

如果双方的所有提供都已得到了应答，则在对话的早期或确定阶段发送的UPDATE请求只可以携带一个提供。当然，如果还没有发生过提供/应答交换，则不能发送带有提供的UPDATE。

12.13.6 资源管理与SIP的结合：“前提”的概念

不能为会话预留网络资源是会话建立的严重缺陷。为了使会话启动后失败的可能性最小，有必要在被叫方得到通知之前(即振铃之前)进行资源预留。

为了进行资源预留，网络需要知道被叫方的IP地址、端口及会话参数。为实现这一点，没有提供/应答的交换是不行的。问题是，会话是在提供/应答交换之后建立的，而且一般来说，用户只有在会话建立发生以后才会被振铃。为了解决这个问题，引入了前提(precondition)的概念。在此概念中,主叫方通过一个SDP提供来指明对本次会话的一系列约束，应答者用一个SDP应答对其进行响应。然而，这一步既不建立会话，也不通知用户。只有当主叫方和被叫方得知前提已经被本地事件满足、主叫方发送一个新的提供对此进行确认并且被叫方也发送一个应答进行确认之后，会话才建立起来。在IMS中，这种新的提供/应答交换使用UPDATE请求和响应进行携带。

这种SDP扩展在［RFC3312］中定义，其中也定义了服务质量（QoS）前提。以下介绍三种新的SDP属性：

• 当前状态（currentstatus）——指示特定媒体流在网络中的当前资源预留状态。

• 希望的状态（desiredstatus）——指示网络中的资源预留前提，以进行会话建立。

• 确认状态（confirmationstatus）——确认状态属性指示媒体流的门限条件，它用于一个端点指示另一个端点在对端前提条件已得到满足时发回一个确认。

这三个属性均有以下四个字段，出现顺序也相同（当前状态属性是个例外，，因为它不含有强度标签）：

• 前提的类型——目前只定义了QoS一种前提类型（可以扩展）。

• 强度标签一指示前提的强度，定义的值有："必须（mandatory）”、“可选（optional）”、"无（none）”、"失败（failure）”和"未知（unknown）"。

• 状态的类型——端到端（或“e2e"）状态类型指示端到端的资源预留状态，“本地（local）”和“远端（remote）”状态类型分别表示本地和远端网络需要了解前提的状态。这些状态在双方本地进行其资源预留时会用到。

•方向标签——指示资源预留的当前方向：希望的还是确定的。

这里有一些a-行属性的例子：

a=curr:qose2e send

a=des:qos optional e2e send

a=conf:qos e2e recv

为了对前提进行处理，引入了一个新的SIP扩展选项标签“precondition”。如果在提供中出现一个值为"mandatory”的强度标签，则"precondition"标签就出现在Require头中。如果所有强度标签都是“opitional”或“none”，则该选项标签可以出现在Supported头中。这里有一个如何使用选项标签的例子：

Require:l00rel,precondition

12.13.7 SIP REFER方法

REFER 方法在［RFC3515］中进行了标准化。

REFER 请求的发送者指引其接收者去访问REFER请求中所标识的资源。

REFER 请求还隐性地创建一个订阅（隐性订阅的意思是创建一个如12.13.1所述的订阅状态，但不明确地发送SUBSCRIBE请求），使得REFER请求的接收者可以接收这次引荐的结果的通知（有关事件通知的细节，见12.13.1节）。因此,REFER请求是一个创建对话的请求。

REFER方法的一个应用就是呼叫转移。例如，秘书接到一个合伙人打给经理的电话，于是秘书通过发送一个含有经理联系信息的REFER请求给合伙人，从而将呼叫转移给经理，然后合伙人的UA通过发送INVITE来呼叫经理。

REFER标准还引入了SIP扩展头，即Refer-To头，它提供一个URL其语法与Contact消息头相同（惟一差别在于星号“*”不能出现在Refer-To头中）。Refer-To头只能出现在REFER请求中，但只能出现一次。

REFER请求的构建与对话以外的任何其他请求的构建一样（在12.7.4.1节中定义）。

REFER请求的接收者一般用“202接受”来对它进行响应。其接收者还创建一个订阅并发送结果通知，根据事件通知框架，在接收到REFER请求后，立即产生和发送NOTIFY请求。NOTIFY请求的构建与对话期间任何其他请求的构建一样，每个NOTIFY请求均包含带有标签"refbr”的Event消息头。

与SUBSCRIBE请求不同，REFER请求中不带有过期时间。隐性订阅的时长由被指引方决定，并在第一个NOTIFY请求里使用Subscription-State头告知指引方。指引方通过在对话期间发送一个SUBSCIRBE请求来延长对该事件的订阅时长。

NOTIFY请求还包含一个MIME类型"message/sipfiag”的正文（在12.13.8中介绍），最小的正文包含一个SIP响应状态行。

12.13.8message/sipfragwMIME类型

"message/sipfi"ag"MIME类型使得SIP消息可以分段表示。如果要表示SIP消息的开始行或正文，则根据这种表示的BNF范式，该表示必须是完备的。如果表示SIP消息正文，则分段也必须携带描述正文的适当的SIP消息头。

12.13.9用于注册非相邻联系的SIP扩展头（Path消息头）

中间服务器，如SIP代理服务器，可在网络拓扑中处于UA和登记员之间。由于这种情形，SIP扩展引入Path消息头，用来记录REGISTER请求从UA到登记员所经过的路径（穿过的代理）。该Path消息头和用于对话创建请求的Record-Route头类似，但仅被用户的归属网络用来向用户发送请求。

Path消息头的语法与Record-Route头的语法类似。UA在发送的REGISTER请求中包含一个Supported消息头并带有“path”选项标签。REGISTER请求的2xx响应中返回的Path消息头的值可以被UA忽略。

如果中间代理希望发往UA的任何后续请求仍经过自己，只要REGISTER请求中含有Supported头及选项标签“path”，它就可以在REGISTER请求中插入一个Path消息头并赋值为它自身的URIo该Path消息头的值或新的Path头必须出现在最顶端。如果代理要求登记员支持Path扩展，它就要插入一个带有选项标签“path”的Require头。

如果代理对网络拓扑有所了解，它可以将插入的Path消息头的值指向其他代理的URI。

如果UA没有指示它支持Path扩展，而Path消息头出现在REGISTER请求中，建议的操作是登记员用“420无效扩展”响应来拒绝注册请求的。

如果登记员接受了请求，则按照原顺序将Path消息头存储起来，并将他们与AOR和Contact头关联。然后，它将Path消息头的值复制到2xx响应中。

一般来说，会有一个归属地代理与用户的登记员相关联。如果归属地代理接收到一条去往AOR已注册用户的请求，它就要确定该用户的注册信息中是否有Path消息头。如果有，归属地代理就将该Path消息头作为Route头插入到请求中。Path扩展在［RFC3327］中定义。

12.13.10用于可信网络中判定身份的SIP私有扩展

［RFC3325］给SIP提供了私有（private）扩展，以让可信任的SIP服务器网络来判定终端用户或终端系统的身份。它还提供了一种机制，使终端用户可以指示其对隐私的要求。当要求隐私时，实体就有责任在信任域以外对判定的身份信息保密。

如果代理服务器收到了一个来自不可信任的实体发来的SIP请求，需要对用户进行认证，它就在将其转发到可信任的下一跳前，在请求中插入P-Asserted-Identity扩展头。当来自不可信任实体的请求中已经包含P-Asserted-Identity头时，则代理要将其去掉或替换。如果代理接收到来自可信任实体的请求，它可以安全地信赖其中已有的P-Asserted-Identity头中的身份信息。

当有多个公共用户身份时，用户可以让代理了解哪个公共身份在插入请求中时是优先选择的。这是通过使用P-Preferred-Identity扩展头来实现的。收到来自不可信任实体的请求的代理对用户进行认证后，使用该消息头作为插入P-Asserted-Identity头的内容。如果指示的身份不存在，则代理可以拒绝该请求或者插入一个P-Asserted-Identity消息头并忽略P-Preferred-Identity头。

如果终端用户已请求隐私保护，则将请求转发给不可信任的下一跳时，代理要去掉所有的P-Asserted-Identity头。希望请求隐私保护的用户将隐私标志"id"插入Privacy头（在3.6节中定义）。

P-Asserted-Identity头与P-Prefferred-Identity头的语法和From头的语法类似。

12.13.11SIP的安全机制协定

12.13.11.1介绍

SIP安全协定(Sip-Sec-Agree)[RFC3329]是SIP的一个扩展，它允许UA与其第一跳服务器之间就它们在后续的通信中所使用的安全机制进行协商并达成一致。Sip-Sec-Agree最重要的方面在于该协商本身是安全的。这个协议存在一种适当的机制，使得攻击者不能企图通过对UA和它的第一跳服务器强加一种不牢固的安全机制来削弱所交换的安全机制。这就使系统具有未来安全性：可以加入新的更强的安全机制，而较弱的机制将在以后被删除。

12.13.11.2操作

Sip-Sec-Agree握手包含以下几个阶段(见图12-7)。

图12-7  安全协定握手消息流程

• 当收到来自UA的请求时，第一跳SIP服务器通过挑战UA来发起安全协定。该挑战包括服务器所支持的一系列安全机制。注意，客户端可能抢先在其请求中包含它所支持的安全机制。然而，服务器在进行挑战时总是采用它自己支持的安全机制的完整列表，而不管客户端列表中的内容

• UA检查服务器的安全机制列表，该列表是一个按照优先级排序的列表。UA选择其中具有最高优先级的（即最普遍支持的）安全机制，接着就进入所选择的安全机制（即和服务器建立相互加密的IPsecSA或开始和服务器的TLS握手）。然后UA重新递交其原先的请求，这时请求已经由所使用的安全机制来保护。它还返回服务器支持的安全机制列表。

• 服务器收到一个安全机制列表，该列表被认为是它原先在Sip-Sec-Agree挑战中列表的镜像。服务器要验证镜像列表事实上是否与它之前发出的列表完全相同。如果不同，则意味着存在攻击这时服务器会立即放弃并拒绝该请求；如果一切检查正常，则该请求将被转发到下一跳。

12.13.12 用于媒体授权的SIP私有扩展

SIP扩展将承载网络中媒体的QoS与会话的信令关联起来,这有助于防止DOS攻击。该扩展只在存在信任关系的各管理域之间可行。SIP中间服务器（一般是代理服务器）对QoS进行授权，由策略控制功能——或策略决策功能（PDF）——来提供QoS。这种机制不允许对描述媒体会话的消息正文进行任何端到端加密，它必须仅用于像3GPPIMS这样的特定SIP网络中。

该扩展假设希望获得会话QoS的UA已经与具有QoS能力的代理和策略实施点（PEP）相连。具有QoS能力的代理是指与PDF有连接的代理。

该解决方案使用了一种称为令牌（token）的东西（一串十六进制的数字）。

UA从具有QoS能力的代理服务器处获取媒体授权令牌，代理服务器则去PDF获取媒体授权令牌然后传给UAo代理服务器通过一个SIP扩展头将该令牌传递给UA,然后UA将该令牌呈交给PEP以获得具有指定QoS的承载。

该扩展头称为P-Media-Authorization,它可以携带多个媒体授权令牌，之间用逗号分开。P-Media-Authorization头本身仅可以由携带SDP提供或应答的请求或响应来携带。如前所述，媒体授权令牌是一串十六进制的数字。

当SIPUA向具有QoS能力的代理服务器（一般称为“发起方代理服务器"）发送INVITE请求后，代理会在所有不可靠的临时响应（除了100）、第一个可靠的Ixx或2xx响应以及该可靠响应的所有重传中包含一个或多个媒体授权令牌。

©该行为的原因仅在于客户端列表没有任何的安全保护，因此不能被信任。它仅仅是一个将某些参数或观点传递到服务器的工具。

©Sip-Sec-Agree的这一点要求任何用Sip-Sec-Agree协商的机制都必须至少提供数据完整性保护。

作为INVITE请求的结果，代理服务器对创建的每个对话都如此处理。当UA向承载网络请求QoS时，它在资源预留请求中包含媒体授权令牌。

当SIPUA从具有QoS能力的代理(一般称为“目标方代理服务器”)接收到INVITE请求时，它对该请求进行检查，看代理在其中包含了哪些媒体授权令牌。当UA从承载网络请求QoS时，它就在资源预留请求中包含媒体授权令牌。

媒体授权扩展在［RFC3313］中定义。

12.13.13注册过程中用于服务路由发现的SIP消息头扩展

UA可以在初始请求中自由包含一系列Route头——预装载路由——来迫使请求访问一个或多个代理，并因而有可能接受它们的服务。通过这种方式，UA可以向某些特定的代理服务器请求服务，这些服务器通常都在用户的归属网络内。

［RFC3608］定义了一种称作aService-Route"的消息头，UA使用它来学习服务的路由(或预装载路由)。希望将服务路由集合通知给UA的登记员在对REGISTER请求的2xx响应中使用该Service-Route消息头。如果UA采用了这个服务路由集合，将可以从与该登记员相关联的一个或多个代理处获得服务。

若UA选择使用登记员所提供的服务路由集合，则将Service-Route消息头中的内容放入Route消息头，并维持原序。

［RFC3608］没有描述登记员用于构建消息头的机制，该机制是登记员的本地策略。

12.13.14用于3GPP的SIP私有消息头扩展

［RFC3455］定义了如下专用于3GPPIMS的SIP头：

• P-Charging-Vector——在IMS网络实体间传送IMS计费ID(ICID)和相关的接入网(如GPRS)计费信息。

• P-Charging-Function-Address在用户归属网络的IMS网络实体间传送计费功能的地址。

• P-Visited-Network-ID——在注册期间将拜访网络的标识字符串传送到用户归属网络，从而允许归属网络找到两个网络间漫游协定的细节。

• P-Access-Network-Info从拜访网络向归属网络传送关于接入网技术和用户位置(GPRSCell-ID)的信息。

• P-Called-Party-ID~由被叫用户的登记员包含在初始请求中，登记员用被叫用户的注册联系地址重写请求URK这样，请求URI中原来的URI将丢失。因此，请求URI中原来的URI存储到P-Called-Party-ID头中，并随请求一起发送。

• P-Associated-URI含在对REGISTER请求的200(OK)响应中，它包含与用户相关联的其他URI。登记员可以隐性地注册这些URI中的一部分。

12.13.15 SIP压缩

［RFC3486］提供了一种SIP机制，来指示是否支持信令压缩，其中定义了两个参数来让SIP实体指示它对信令压缩的支持。另外当出现这些参数时，还表明该实体愿意接收压缩消息。

第一个参数是一个SIPURI参数，命名为“comp”。目前只为该参数定义了一个值，即“SigComp”。当发送请求时，SIP实体（UA或中间服务器）检查下一跳URIo如果URI携带有参数“comp=SigComp”，则UAC根据［RFC3320］中的信令压缩规范来发送压缩形式的请求。

第二个参数为Via消息头参数。它与URI参数完全相同，但被转发SIP响应的实体用来了解上游实体的能力和接收压缩响应的意愿。因此，如果该参数在请求消息的Via消息头里出现，则响应消息经压缩后发送。

一般，发送压缩请求的UA在Via头里插入“comp=SigComp”参数。如果有Contact头出现，则还将该参数加入到Contact头的URI中。转发压缩请求的代理服务器也在它的Via头里插入该参数。如果代理记录路由，则它在插入的Record-Route头的URI里添加该参数。