会话初始协议ISP技术要求-中国通信行业标准(6)

时间:2008-10-19 来源: 作者: 点击:
使用S/MIME 机制,UA 可以发送一个加密的但是无同步码的请求,如果该请求在密钥环中含有一个目标记录地址的证书。但是,任何注册为某个目标地址的设备不能持有任何曾经被该设备的当前用户所使用的证书。因此它就不
  
使用S/MIME 机制,UA 可以发送一个加密的但是无同步码的请求,如果该请求在密钥环中含有一个目标记录地址的证书。但是,任何注册为某个目标地址的设备不能持有任何曾经被该设备的当前用户所使用的证书。因此它就不能正确的处理一个加密的请求, 这样就不可避免的产生错误的信令。当一个加密的请求被分叉代理的时候这种情况就最可能发生。
S/MIME 有关的密钥适合用于与一个特定的用户(记录地址)而不是一个设备(UA)相关联的时候。当用户在设备间移动时, 它也许很难在UA 间安全的传输私有密钥; 关于设备如何得到这种密钥不在本规范的范围之内。
S/MIME 中,很难解决的问题是它能产生很大的消息,特别是当使用SIP 隧道机制时。因此,本规范建议在使用S/MIME 隧道技术时,应当使用TCP 作为传输协议。
A.5.3 TLS
TLS 需要一个有连接的下层传输协议,本规范中即TCP 协议。TLS 不能用于UDP 之上。
本地出代理服务器和/或注册服务器也很难同时维持和很多的UA 的长时间的TLS 连接。尤其对于UA 单独负责建立连接并维护冗余的长时间生存的TLS 连接的时候。
TLS 只允许SIP 实体来鉴权其相邻的服务器;它提供严格的逐跳的安全。TLS 和本文所述的任何其他的机制都不可以允许客户授权它们无法建立直接的TCP 连接的代理服务器。
A.5.4 SIPS URIs
在请求路径的任何部分使用TLS 都必须使终结的UAS 在TLS 上是可达的(可以和SIPS URI 注册一个关联地址)。例如, 许多有效的网络结构使用TLS 来保证部分的请求路径的安全, 而用其他的一些机制保证到UAS 的最后一跳的安全。这样就不能保证TLS 是真正的端到端实现的。注意到由于许多UA 不接受引入的TLS 连接,甚至那些支持TLS 的UA 可能也被要求维持永久的TLS 连接,以便于UAS 能在TLS 上接收请求消息。
定位服务不要求为SIPS Request-URI 提供SIPS 绑定。虽然定位服务通常由用户注册服务器提供,参见本规范10.2.1 。其他的各种协议和接口也是可为AOR 提供可信的联系地址,并且这些工具也可自由地将 SIPS URI 映射成正确的SIP URI 。定位服务在询问绑定时返回它的联系地址而不管是否收到了一个带有SIPS Request-URI 的请求。如果重定向服务器访问位置服务,将由该实体处理重定向的Contact 头字段以决定该联系地址是否合适。
由目标域来确保TLS 可以被用于所有的请求部分的方法实现起来很麻烦。因此在转发路径上,以密码鉴权的不兼容的代理服务器可能不考虑与SIPS 有关的转发规则。总的转发规则参见本规范16.6 。例如,这些恶意的中介可能将一个请求从SIPS URI 重指向到一个SIP URI 来试图破坏安全。
另外,某中介可能正当的将请求由SIP 重指向到SIPS URI 。该请求的接收者的Request-URI 使用SIPS URI 方案, 这样就不能基于Request-URI 的来保证SIPS 被用于整个的请求路径上。
本规范建议,如果请求的Request-URI 包括一个SIP 或者SIPS URI ,请求接收者应检查To 头字段值是否包括SIPS URI ,如果该URI 有着相同方案但并不等于To 头字段中的URI 不会破坏其安全。虽然客户可以选择不同的方式组装请求的Request-URI 和To 头字段,但当使用SIPS 时,这种不同就被认为是一个可能的安全隐患,因而该请求就随即被接收者所拒绝。接收者也可以检查Via 头字段链而确信是否TLS 被用在直到本地管理域整个的请求路径上。S/MIME 也可以被用在发起UAC 上来帮助确保端到端的携带的To 头字段的最初的格式的安全。
如果UAS 相信Request-URI 的方案在传输中被不正当的修改了,UA 就应该通其用户潜在的安全破坏。
以后为了预防下降攻击,只接受SIPS 请求的实体也可以拒绝在不安全端口上的连接。
终端用户可以判断SIPS 和SIP URI 之间的区别,并且它们可以手动的编辑自己的响应。这对于安全即有利又有弊。例如, 如果攻击者破坏DNS 的缓存, 为了有效的去掉所有的服务器的SIPS 记录而插入假的记录集,然后任何穿过该服务器的SIPS 请求都会失败。然而, 当一个用户看到一个到SIPS AOR 的重复呼叫失败,他们就会在某些设备上手动的将SIPS 方案变成SIP 方案并重试。当然,也有些对此的防护措施(如果目标UA 很多疑, 他就会拒绝所有的非SIPS 的请求), 但是其局限性使之没有什么价值。好的一面是,用户也可以知道即便当它们只带有SIP URI 出现时,“SIPS ”也可以是有效的。
A.6 保密性
SIP 消息经常带有发送者的敏感信息,包括通话内容,通信的对方,通信时长,双方在会话中从何地加入。许多应用和他们的用户要求的个人信息对任何不需要知道的参与者都应该隐藏。
但是, 很少有直接的泄漏个人信息的方式。如果用户或服务选择在由姓名和组织从属关系( 描述大多数的记录地址)可推测出的地址上是可达的,传统的保密性措施(即有一个未列出的“电话号码”) 就被破坏了。用户定位服务可以由泄漏呼叫者详细位置来破坏会话邀请的接收方的保密性;具体实现时, 应该能够基于每个用户来限制何种位置和何种可用的信息是可被某类呼叫者所知的。在某些情况下,用户可能希望在传送标识的头字段中隐藏个人信息。这不仅可以用在代表请求发起方的From 及相关的头字段,还有To 头字段―― 发送给最终目的一个快速拨号的别名或者一个目标组的未展开的标识可能不太合适,它们在路由请求时都可能从Request-URI 中被去掉,但如果它们最初是相同的,那么在To 中就不会改变。因此,为了保密,需要创建一个与Request-URI 不同的To 头字段。
附录 B
(标准性附录)
IANA 考虑
在SIP应用中使用的所有方法名字、头字段头字段名字、状态编码和选项标记都通过RFC中IANA Considerations 事项章节中的指导向IANA注册。
规范指示IANA 去在http://www.iana.org/assignments/sip-parameters 下创建4个子注册项目:选项标记、告警编码(warn-codes) 、方法和响应编码, 这些被增加到头字段的子注册项中, 头字段已经在该注册项中存在了。
B.1 选项标记
本规范在http://www.iana.org/assignments/sip-parameters 下建立了选项标记子注册项。
为了支持SIP 的兼容性机制用于扩展,参见本规范19.2 节,选项标记用于头字段中,诸如Require 、Supported 、Proxy-Require 和Unsupported 。选项标记自身是一个与特定SIP 选项相关的字符串(即扩展)。它确定SIP终端点的可选项。
当选项标记在RFC 的标准中公布时,选项标记由IANA注册。RFC的IANA Considerations 章节必须包括下列信息,这些信息和出版的RFC号码一样在IANA 注册登记中出现。
o 选项标记的名字。名字可以是任意长度,但应该不超过20个字符长度。名字必须仅由字母和
数字(参见25节)组成。O 描述扩展内容的描述性文字。
B.2 告警编码
本规范在http://www.iana.org/assignments/sip-parameters 下建立了告警编码子注册项,并以
20.43节中列出的告警编码做为其初始的告警编码。另外的告警编码由RFC 出版物注册。告警编码表的描述性文字是:当会话描述协议(SDP),参见RFC 2327 问题导致了事务处理故障时, 告警编码为SIP 响应消息中的
状态编码提供了补充信息。
“warn-code ”由3个数字组成。第一个数字“3” 指出告警是针对SIP 的。在将来的规范描述告警编码的用法不是3XX 以前,可能仅有3XX的告警编码被注册。
300至329 的告警被预留用于与指示会话描述中关键字相关的问题,告警330 至339 是与会话描述中所请求的基本网络业务相关的告警,告警370 至379 是与会话描述中所请求的QOS 量化参数相关的告警,告警390至399是不属于上述告警类型的其他各种告警。
B.3 头字段名字
为了注册新的头字段名字,需要在RFC 的出版物中提供下列信息:
.o 报头被注册的RFC号码;
.o 所注册的头字段名字;
.o 该头字段的紧凑形式版本,如果定义了版本号字段;

头字段的某些普遍用法是指定了使用一个字母的紧凑形式,参见本规范7.3.3 节。紧凑形式仅仅在SIP工作组讨论后被指定,随后由RFC出版物出版。
B.4 方法和响应编码
本规范在http://www.iana.org/assignments/sip-parameters 下建立了方法和响应编码子注册项,将以下编码做为其初始的编码。初始的方法编码表是:
INVITE [RFC3261]
ACK [RFC3261]
BYE [RFC3261]
CANCEL [RFC3261]
REGISTER [RFC3261]
OPTIONS [RFC3261]
INFO [RFC2976]

响应编码表参见本规范21章,编码的类型部分标记为Informational 、Success 、Redirection 、Client-Error 、Server-Error 和Global-Failure 。编码采取下列格式: Type ( 例如,Informational) Number Default Reason Phrase [RFC3261] 为了注册一个新的响应编码或方法,需要在RFC 出版物中提供下列信息:
.o 方法或响应编码所注册的RFC号码;
.o 所注册的响应代码或方法名字;
.o 某个响应编码的缺省原因短语;

B.5 “message/sip”MIME 类型
为了允许SIP 消息通过SIP实体中的隧道,本文档注册了“message/sip”MIME 媒体类型,主要是用于端到端的安全目的。该媒体类型由下列信息定义:
Media type name: message Media subtype name: sip Required parameters: none Optional parameters: version Version: 所附加的消息的SIP版本号码(如“2.0”) 。如果该参数不存在, 则缺省值为“2.0”。Encoding scheme:SIP 消息由8比特组成,其后可选地跟随着一个二进制的MIME 数据对象。同样
地,SIP 消息必须按照二进制来对待。在正常情况下,SIP消息在支持二进制的传输媒体上传输, 不需要特殊的编码。Security considerations:做为与S/MIME 一致的安全机制,该用法的目的和例子参见本规范23.4 节。
B.6 新的Content-Disposition 参数注册
本规范注册了4个新的Content-Disposition 报头“disposition-types”:alert 、icon、session
和render 。这些值要求记录在IANA 注册项中以用于Content-Disposition 。对这些“disposition-types ”的描述,包括目的和例子,在20.11 节给出。与IANA注册内容相配的简短描述是:
alert 该实体是提醒用户的用户振铃音调
YD ××××—××××
icon 该实体做为一个图标向用户显示
render 该实体应该向用户显示
session 该实体描述了通信会话,例如,RFC 2327 SDP 实体

118
附录 C (标准性附录) 与RFC 2543 相比的改变
本RFC是对RFC 2543 的修订。本文档的大部分与RFC 2543 是相兼容的。这里所描述的改变修正了在RFC 2543 中发现的错误,并为RFC 2543 中未详细描述的事例提供了相关信息。在这里以更为清晰的分层化模型介绍SIP协议。
我们将这些差异划视为与RFC 2543 相比具有实质性变化的功能行为,这些差异在某些情况下对互操作性和正确操作具有一定影响,而且不同于RFC 2543 的功能行为并不是互操作性问题的潜在根源。同时也存在未在这里描述的无数需澄清的地方。
.C.1 主要的功能性变化
o 当UAC 希望在应答呼叫之前终止呼叫,它将发送CANCEL 。如果最初的INVITE 仍返回2xx ,则UAC发送BYE。BYE仅仅能在现存的对话上发送,然而在RFC 2543 中BYE可以在任意时候发送。
o SIP BNF 可以转换成与RFC 2234 相一致的范式。
.o SIP URL BNF 更为普通, 在用户部分允许更大的字符集。而且,对比规则被简化以对大小写不敏感,并且描述了在出现参数时对比的详细处理。最实质性的变化是带有缺省值参数的URI 并不匹配未带该参数的URI 。
.o 消除了Via 头字段隐藏。Via 头字段隐藏具有严重的信任问题,因为它是依靠下一跳来完成模糊方案。相反,在有状态的代理服务器中,Via 头字段隐藏可以做为本地实现方案来完成,
.o 在RFC 2543 中,CANCEL 和BYE事务处理是混和在一起的。本规范中,它们是分开处理的。当用户发送INVITE,然后发送CANCEL 时,INVITE 事务处理将正常地终止。UAS 需要以487 响应来应答最初的INVITE 请求。
.o 类似地,CANCEL 和BYE事务处理是混和在一起的;当接收到BYE 时,RFC 2543 中规定UAS不去向INVITE发送响应。在本规范中,规定最初的INVITE 需要一个响应回答。

o 在RFC 2543 中,UA仅需要支持UDP。在本规范中,UA需要同时支持UDP和TCP。
O 在RFC 2543 中, 在多个请求同时出现时,分叉的代理仅仅向上传递一个来自下游实体的请求。在本规范中,代理要收集所有的请求并将这些请求放置到转发响应中。
.o 在分类鉴权证书中,URI 需要用引号来引用;这在RFC 2617 和RFC 2069 中并不明确,而且这两者对此论述不一致。
.o SDP处理已经被分出来,作为单独的规范RFC 3264, 并且做为正式的offer/answer 交换程序进行了更加详尽的规定,该程序能够有效在SIP中建立隧道通信。在INVITE/200 或200/ACK 中允许使用SDP以有助于基本的SIP实现;RFC 2543 间接提及在INVITE/200 和单个事务处理的ACK 中使用SDP 程序的能力,但并未对此作明确规定。在扩展中则允许使用更复杂的SDP用法。
.o 在URI 和Via 头字段中增加了对IPv6的完全支持。在Via中支持IPv6 需要其头字段参数允许方括号和冒号字符出现。理论上, 这将引起于旧的实现机制的互操作性问题。绝大部分实现中接受在这些参数中的任何非控制性ASCII 字符。
.o DNS SRV 程序现在在单独的规范RFC 3263中描述。该程序使用SRV和NAPTR 资源记录并不再合并来自SRV记录的数据,参见RFC 2543 。
.o 环路检测已经做为可选, 而是用Max-Forwards 的强制使用所代替。在RFC 2543 中的环路检测程序具有严重的错误,该错误将报告“spirals” 做为一个错误情形,但该错误并未发生。本规范中,作为可选的环路检测程序更加完善。
.o本规范中, 标记的使用是强制的, 在RFC 2543 中则是任选的, 现在标记是对话标志的基本构建块。
.o 增加了Supported 头字段,客户可以指定,对服务器那些扩展是支持的,服务器可以在响应中应用那些扩展并在响应中用Require 指定其用法。
.o 对于某些头字段,扩展参数在BNF中并不存在,但现在已经被加上了。
.o Route 和Record-Route 构词法的处理在RFC 2543 中并未详细规定。在本文档中已经进行了充分的重新规定并变得简单。后向兼容性仍然被提供以用于处理该构词法, 这两个域并不使用“ 预先加载的路由”,初始请求具有一套Route 头字段值,这些值是通过Record-Route 之外的某些方式获得的。在那些情况中,新的机制并不具备互操作性。
.o 在RFC 2543 中, 在消息中的横线可以用CR、LF或CRLF 终止。本文档仅允许使用CRLF。
.o 本规范对CANCEL 和ACK中Route头字段使用给出了完善的定义如果一个请求具有Route 头字段,则对该请求的非2xx 响应CANCEL 或ACK 需要承载同样的Route 头字段值。用于2xx 响应的ACK使用的Route 值是从2xx响应的Record-Route 学到的。
.o RFC 2543 允许在单个UDP 分组中同时存在多个请求。这种用法已经被消除了。
.o Expires 头字段中和参数中的绝对时间的用法已经被取消。它会引起不能进行时间同步的单元的互操作性问题,本规范规定采用相对时间。
.o Via头字段值的branch 参数现在对所有的单元是强制使用的。该参数现在充当唯一事务标志符的作用。这避免了RFC 2543 中复杂的、充满错误的事务鉴别规则。在该参数中使用magic cookie 用于确定前一跳已经使该参数成为全局唯一的, 而且当该参数不出现时, 采用旧的规则进行对比。因此,互操作性得到了保证。
.o 在RFC 2543 中,TCP连接的关闭等同于CANCEL 。这对代理之间的TCP连接来说几乎是不可能实现的。这点已经在本文档中消除了,因此在TCP连接状态和SIP处理状态之间不存在耦合了。
.o UA将初始化对对等方的新事务而另一方也处于如此进行中,而在RFC 2543 中,另一方是寂静无所动作的。现在在此规定了做法。对non-INVITE 请求是允许的,但不接受INVITE 。
.o PGP被删除了。PGP并未进行充分规定,而且与更完善的PGP MIME并不兼容。PGP被S/MIME 说代替。
.o 增加“sips”URI方案用于端到端TLS 。该方案与RFC 2543 并不具备后向兼容性。接收到在Request-URI 中带有SIPS URI 方案的请求,现存的方案将很有可能拒绝该请求。这是一个事实上的特征; 一个对SIPS URI 的呼叫仅仅在路径上的所有跳都是安全可靠时被发送,这种情况是可以确保的。
.o TLS中增加了额外的安全特征,这些在更全面的和完整的安全考虑章节中进行描述。
.o 在RFC 2543 中, 代理并不需要向上游方向转发从101 到199的临时响应。现在已经变成了必须转发响应了。这点很重要,因为许多后续的消息特征依靠从101 到199 的所有临时响应的传送。
.o 关于RFC 2543中的503响应编码说得很少,以后发现该响应在指示代理中的故障或者过载情况时具有实质的用途。这需要稍微特殊一点的处理。特别地,接收到503 响应应触发尝试联系DNS SRV 查找表中的下一个单元。而且,在某种条件下503 响应由代理仅仅向上游转发。
.o RFC 2543 定义了, 但未充分规定用于服务器的UA鉴权机制。该机制已经被删除了。相反,RFC 2617 的相互鉴权程序是允许的。
.o UA不能对呼叫发送BYE, 直到它接收到初始INVITE 的ACK。这在RFC 2543是允许的,但导致了潜在的竞争环境产生。
.o UA或代理不能对事务发送CANCEL, 直到它获得该请求的临时响应。这在RFC 2543 中是允许的,但导致了潜在的竞争环境产生。
.o 在注册中的action 参数被反对使用。它对于任何有用的业务是不够的,当在代理中处理应用时, 该参数会引起冲突。
.o RFC 2543 有许多特殊的情况用于组播。例如,某些响应被抑止,定时器被调整等等。组播现在扮演一个更加受限制的角色, 与单播相反, 组播的使用并不影响协议的运作。由此导致的限制在文档中有所描述。
.o 基本鉴权已经被完全删除且其用法也被禁止。
.o 在接收到6xx响应后,代理并不立即就转发。相反,代理立即取消未决的分支响应。这避免了潜在的竞争条件产生,那将导致UAC 在得到2xx 响应后获得6xx 响应。在所有的情况中,除了这种竞争条件外,结果都是一样的――6xx 响应向上游转发。
.o RFC 2543 并未提出请求合并的问题。当请求去往分支的代理且以后又在某个单元重新聚会的时候就会发生这个问题。合并处理仅仅在UA上完成, 而且定义了拒绝所有请求但不拒绝第一个请求的程序。
.C.2 次要的功能改变
.o 对用户,为任选的content presentation 增加了Alert-Info 、Error-Info 和Call-Info 头字段。
.o 增加了Content-Language 、Content-Disposition 和MIME-Version 头字段。
.o 增加了“glare handling” 机制来处理双方同时相互发送re-INVITE 的情况, 使用新的错误代码:491(Request Pending )。
.o 为了支持以后的时间内接收到丢失的呼叫或消息,增加了In-Reply-To 和Reply-To 头字段。
.o 增加了TLS 和SCTP 做为有效的SIP 传输方式。
.o 描述了各种机制用于处理呼叫中任意时候发生的故障;这些机制现在一般的未统一,发送BYE用于终止呼叫。
.o RFC 2543 要求在TCP上重传INVITE 响应,但注意实质上仅对2xx 响应需要重传。那是由于协议层不够而人为地进行处理。在这里定义了更连贯的事务处理层,那种人为处理就不再需要了。对INVITE, 仅有2xx的响应在TCP 上重传。
.o 客户和服务器的处理机现在是基于超时设定驱动的,而不是基于重传计数的。这允许为TCP和UDP 适当地指定状态机。
.o 在REGISTER 响应中使用Date 头字段来为用户代理的自动配置提供简单的方法。
.o 允许注册机构拒绝超时的注册,该注册的生存期很短。定义了响应代码423和Min-Expires 即用于此目的。

下表总结了在本规范中所使用的各种定时器的含意和缺省值。
定时器 值 章节 含意
T1 500ms 17.1.1.1 RTT估计
T2 4s 17.1.2.2 用于non-INVITE 请求和INVITE 响应的最大重传间隔
T4 5s 17.1.1.2 在网络中保存的最大延迟时间
定时器A 最初T1 17.1.1.2 INVITE请求重传间隔,仅用于UDP
定时器B 64*T1 17.1.1.2 INVITE处理超时定时器
定时器C 大于3min 16.6 代理INVITE 处理超时
定时器D 对UDP,大于32s 对TCP/SCTP,0s 17.1.1.2 响应重传等待时间
定时器E 最初T1 17.1.2.2 非INVITE 请求重传时间,仅用于UDP
定时器F 64*T1 17.1.2.2 非INVITE 处理超时定时器
定时器G 最初T1 17.2.1 INVITE响应重传间隔
定时器H 64*T1 17.2.1 ACK接收等待时间
定时器I 对UDP,T4 对TCP/SCTP,0s 17.2.1 ACK重传等待时间
定时器J 对UDP,64*T1 对TCP/SCTP,0s 17.2.2 对非INVITE 请求重传的等待时间
定时器K 对UDP,T4 对TCP/SCTP,0s 17.1.2.2 响应重传的等待时间

附录 D
(标准性附录)
SIP 协议中临时响应的可靠性

D.1 简介
SIP 协议是一个请求响应协议,用于发起和管理会话。在SIP 中,响应分为两类,一类是临时响应,一类是最终响应。最终响应传递呼叫请求处理的结果,并且保证可靠传递; 临时响应提供呼叫请求处理过程中的信息,并且不保证可靠传递。
但在有些情况下,可靠地传递临时响应非常重要,其中包括和PSTN 互通这种情况,因此需要任选能力集来支持临时响应的可靠传递。
可以借鉴最终响应2xx 的可靠传递机制来实现临时响应的可靠传递。事务处理用户部分(TU)将周期性地发送最终响应2xx, 直到收到ACK 为止。2xx 沿着INVITE 消息的发送路径逐段回送,ACK 消息则端到端传递。为了可靠传递临时响应,需要采用相同的机制。事务处理用户部分TU 采用按照指数递增的定时器控制临时响应的重传,当收到PRACK消息是停止临时响应的重传。但是PRACK 和ACK 不同,PRACK 是一个常规的SIP 消息,和BYE 类似,PRACK 消息通过stateful 代理服务器逐跳传送,并且有对应的响应消息。
每个临时响应都有一个序列号, 包含在RSeq 头部字段中。PRACK 消息中应包含RAck 头部字段, 指示被证实的临时响应的序列号。为了防止拥塞,一次只应发送一个临时响应并且PRACK 消息不进行累积。
D.2 UAS 的行为
只要初始的INVITE 请求( 该请求的临时响应被可靠传递)中包含Supported 头部字段,且该头部字段中的任选标记为100rel,UAS 就可以可靠地传递任何non-100 临时响应。虽然本规范不允许对INVITE 之外的其他方法可靠地传递临时响应,但是在定义用于建立对话的新方法的扩展协议中,可以使用该机制。
如果初始请求中包含Require 头部字段, 且该头部字段中的任选标记为100rel,UAS 就必须可靠地传递任何non-100 临时响应。如果UAS 不能满足此要求,则UAS 必须用420 (不正确的扩展)的拒绝初始请求,并且在响应中包含Unsupported 头部字段,该头部字段中的任选标记为100rel 。
UAS 不应尝试可靠地传递100 (试呼中)响应,只有编号为101 到199 的临时响应可以可靠传递。如果请求方法中未包含指示该特性的Supported 头部字段或 Require 头部字段, 则UAS 就不用可靠地传递临时响应。
100( 试呼中) 响应只能逐跳传递,而本规范中描述的可靠机制要端到端进行传递。
能够充当代理的单元也可以可靠地传递临时响应, 此时该单元可以看作是UAS。但是,如果请求方法的To 字段中包含标记, 则该单元不应尝试可靠地传递临时响应,即代理不应对在对话上下文中发送的请求产生可靠地临时响应。和UAS 不同, 当代理单元接收到PRACK 方法, 该方法和任何未确认的可靠的临时响应都不匹配,那么将作为代理消息继续传递。
有几种原因可能导致UAS 发送可靠地临时响应。一种原因是INVITE 事务处理可能需要一段时间才能产生最终响应, 此时UAS 需要定期发送临时响应, 请求在代理上延长事务处理。要求代理能够每隔3 分钟收到一个临时响应,但是在传递的过程中可能有包丢失,所以UAS 应该以更短的周期发送临时响应(推荐1 分钟一次),更有效的方式是如果UAS 能够可靠地传递临时响应,可以每隔2.5 分钟发送一次。推荐扩展的事务处理中使用可靠的临时响应。
下面假定初始请求中包含Supported 或Require 头部字段且字段中包含标记100rel,此时需要可靠地传递临时响应。
需要可靠传递的临时响应由UAS 核心构建。临时响应中应包含Require 头部字段, 其中的任选标记为100rel ,并且应包含RSeq 头部字段。在事务处理中,第一个可靠的临时响应中的RSeq 头部字段的值应在1 和231–1 之间, 推荐在该范围内统一进行选择。RSeq 的编号空间仅在一个事务处理内有效,即不同请求的临时响应可以使用相同的RSeq 编号。
可靠的临时响应也可以包含消息体。
可靠的临时响应周期地传递到事务处理层,初始间隔为T1 秒,然后每次重传的间隔都扩大两倍。一旦向事务处理传递了可靠的临时响应,UAS 核心应将该响应增加到内部未被证实的可靠的临时响应列表中。事务处理层应前传UAS 核心重发的可靠的临时响应。
和可靠的临时响应的重发不同,2xx 响应的重发间隔为T2 秒,这是因为当收到2xx 响应时触发ACK 的重传,而PRACK 的重传和1xx 响应的接收相互独立。
当UA 核心收到匹配的PRACK, 将停止可靠的临时响应的重传。PRACK 类似于对话中的其他请求。匹配的含义是PRACK 和对应的响应属于同一个对话,并且RAck 头部字段中的方法、Cseq-num 和response-num 分别和可靠的临时响应中Cseq 字段的方法、Cseq 字段的序列号和RSeq 字段的序列号相同。
如果UA 核心收到的PRACK 请求和任何未被证实的可靠的临时响应都不匹配,UAS 应用481 来响应收到的PRACK 。如果PRACK 和某个未被证实的可靠的临时响应相匹配,则UAS 应响应2xx ,此时UAS 可以确定临时响应已经被按序接收,应该停止对该响应的重发,同时应从未被证实的临时响应列表中删除该响应。
如果以64*T1 秒的间隔重发可靠的临时响应,但当定时器超时时仍没有收到相应的PRACK,UAS 应拒绝初始的请求并发送5xx 响应。
如果PRACK 包含会话描述, 则按照本规范中描述的方式进行处理。如果PRACK 包含的是其他类型的消息体,那么该消息的处理方式和ACK 中消息体的处理方式相同。
第一个可靠的临时响应被证实之后,UAS 可以发送其他可靠的临时响应。在第一个可靠的临时响应被证实之前,UAS 不应发送第二个可靠的临时响应。第一个可靠的临时响应除外,建议在先前发送的可靠的临时响应被证实之前,UAS 不应发送其他可靠的临时响应。第一个可靠的临时响应需要特殊处理, 因为该响应传递初始序列号。如果在第一个可靠的临时响应被证实之前发送其他可靠的临时响应,UAS 将不能确定这些响应是否被按序接收。
对于同一个请求, 每个后续可靠的临时响应中RSeq 的值应大于1。RSeq 编号不应循环。RSeq 的值应小于等于231-1,所以每个请求可以有231 个可靠的临时响应,这足够使用。
对于所有未被证实的可靠的临时响应,在收到相应的PRACK 之前,UAS 可以对初始请求发送一个最终响应,除非最终响应是2xx 且未被证实的可靠的临时响应中某个响应包含会话描述,此时在所有临时响应被证实之前,UAS 不能发送最终响应。如果仍有可靠的临时响应未被证实时UAS 发送了最终响应, 那么UAS 不应继续重发未被证实的可靠的临时响应,但应该准备处理针对这些响应的PRACK 请求。对初始请求发送了最终响应之后,UAS 不应发送新的可靠的临时响应。
D.3 UAC 的行为
当UAC 创建新的请求时,可以要求该请求的临时响应必须可靠传递,为此UAC 可以在请求中插入任选标记为100rel 的Require 头部字段。包含任选标记100rel 的Require 头部字段不能在INVITE 之外的请求中出现。
表1 头部字段的总结
头部字段 位置 PRACK
Accept R o
Accept 2xx -
Accept 415 c
Accept-Encoding R o
Accept-Encoding 2xx -

Accept-Encoding 415 c
Accept-Language R o
Accept-Language 2xx -
Accept-Language 415 c
Alert-Info R -
Alert-Info 180 -
Allow R o
Allow 2xx o
Allow r o
Allow 405 m
Authentication-Info 2xx o
Authorization R o
Call-ID c m
Call-Info -
Contact R -
Contact 1xx -
Contact 2xx -
Contact 3xx o
Contact 485 o
Content-Disposition o
Content-Encoding o
Content-Language o
Content-Length T
Content-Type *
CSeq c m
Date o
Error-Info 300-699 o
Expires -
From c m
In-Reply-To R -
Max-Forwards R M
Min-Expires 423 -
MIME-Version o
Organization -

表1(续) 头部字段的总结

头部字段 位置 PRACK
Priority R -
Proxy-Authenticate 407 m
Proxy-Authenticate 401 o
Proxy-Authorization R o
Proxy-Require R o

Record-Route R o
Record-Route 2xx,18x o
Reply-To -
Require c
Retry-After 404,413,480,486 500,503 600,603 o
Route R c
Server R o
Subject R -
Supported R o
Supported 2xx o
Timestamp o
To C m
Unsupported 420 m
User-Agent o
Via C m
Warning r o
WWW-Authenticate 401 m

如果UAC 不要求可靠的临时响应, 但需要表明如果UAS 需要传递可靠的临时响应它能够支持,那么在请求中应包含Supported 头部字段,其中任选标记为100rel 。UAC 应在所有的INVITE 请求中包含该字段。
如果收到初始请求的临时响应, 并且该响应中包含Require 头部字段, 其中的任选标记为100rel, 那么应该可靠地传递该响应。如果该响应是100( 试呼中)(相对于101 到999), 必须忽略该任选标记, 并且不执行下面描述的程序。
如果还没有创建对话,那么收到临时响应时必须创建一个对话。
假设响应被可靠地传递,UAC 必须创建一个新的PRACK 请求, 该请求在和临时响应关联的对话中传递。PRACK 请求可以包含消息体,可以根据消息体的类型和处理方式进行解释。
PRACK 和对话中的其他非INVITE 请求类似。当收到重发的临时响应但该响应已经被证实过,此时UAC 不应重发PRACK 请求。
收到可靠的临时响应之后,应该舍弃重发的响应。当响应的对话ID、Cseq、RSeq 和曾经收到过的响应相关参数匹配时, 那么该响应就是一个重发响应。UAC 应对序列号进行维护, 序列号指示了近来依次收到的初始请求的可靠临时响应,应一直维护此序列号直到收到初始请求的最终响应。序列号的初始值等于初始请求的第一个可靠临时响应中RSeq 头部字段的值。
除了要保证可靠的临时响应的次序之外,按照如上所述的同样规则处理同一个初始请求后续可靠的临时响应。因此,如果UAC 收到了同一请求的另一个可靠的临时响应,但响应中RSeq 的值没有维护的序列号的值大,那么UAC 就不应用PRACK 证实该响应, 并且不应进一步进行处理。具体实现时可以丢弃该响应,或者如果期望收到丢失的响应则将该响应缓存。
UAC 可以对在最终响应之后收到的可靠的临时响应进行证实,也可以丢弃该响应。
D.4 Offer/Answer 模式和PRACK
RFC3261 对Offer 和Answer 出现的消息集进行了指导性的描述,基于这些描述,本扩展规范规定了需要Offer/Answer 的其他情况。
126
如果INVITE 中包含Offer 字段,那么UAS 可以在可靠的临时响应中产生Answer 字段(假定UAC 支持这些字段), 这将导致呼叫完成之前会话的建立。如果一个可靠的临时响应是传送回UAC 的第一个可靠的临时响应,并且在UAC 发送的INVITE 中没有包含Offer 字段, 那么在这个可靠的临时响应中应该包含该字段。
如果UAC 收到包含Offer 字段的可靠的临时响应(如果UAC 发送的INVITE 未包含Offer 字段,那么第一个可靠的临时响应将包含该字段),那么UAC 应在PRACK 中产生Answer 字段。如果UAC 收到包含Answer 字段的可靠的临时响应,那么UAC 可以在PRACK 中产生另外的Offer 字段。如果UAS 收到包含Offer 字段的PRACK, 那么它必须响应2xx。
一旦发送或收到Answer 字段,UA 就应基于Offer 和Answer 字段中的参数建立会话,即使还没有响应初始的INVITE 。
如果UAS 在某个可靠的临时响应中包含了会话描述,那么UAS 必须延迟发送2xx 直到该临时响应被证实。但是不能保证1xx 的可靠性,要保证可靠性需要正确地进行Offer/Answer 字段的交互。
所有支持本扩展规范的用户代理必须支持所有的Offer/Answer 交互。
D.5 PRACK 方法的定义
本规范定义了新的SIP 方法——PRACK,该方法的语义如上所述。表1 和2 是针对该方法对RFC3261 中表2 和3 的扩展。
D.6 头部字段的定义
本规范定义了两个新的头部字段,RAck 和RSeq 。表3 是针对这些头部字段对RFC3261 中表2 和3 的扩展。
D.6.1 RSeq
RSeq 头部字段用在临时响应中用来保证响应的可靠传送。该字段只包含一个数值从1 到231-1 。
例如:
RSeq: 988789
表3 RAck 和RSeq 头部字段

头部字段 位置 代理 ACK BYE CAN INV OPT REG PRA
RAck R - - - - - - m
RSeq 1xx - - - o - - -

D.6.2 RAck
RAck 头部字段用在PRAck 请求中用来保证临时响应的可靠性。该字段包含两个数值和一个方法标记。第一个数值等于要被证实的临时响应中RSeq 头部字段的值,第二个数值和方法从要被证实的响应中Cseq 字段复制得到。RAck 头部字段中方法名称区分大小写。
例如:
RAck: 776656 1 INVITE
D.7 安全考虑
攻击者可能插入PRACK 请求,强迫可靠的临时响应的重发停止。由于这些响应可能传递重要信息,所以PRAck 消息也应被鉴权。
D.8 BNF 集
本节定义RAck 和RSeq 头部字段以及PRACK 方法的BNF。
PRACKm = %x50.52.41.43.4B ; PRACK in caps
Method = INVITEm / ACKm / OPTIONSm / BYEm
/ CANCELm / REGISTERm / PRACKm
/ extension-method

RAck = "RAck" HCOLON response-num LWS CSeq-num LWS Method response-num = 1*DIGIT CSeq-num = 1*DIGIT
RSeq = "RSeq" HCOLON response-num
附录 E (标准性附录)
定位SIP 服务器
SIP 协议利用DNS 程序,允许客户端将SIP URI 解析成下一跳的IP 地址、端口号和传输协议。同时利用DNS 程序, 当主用客户端故障时允许服务器向备用的客户端发送响应。
E.1 简介
SIP 协议是一个客户服务器协议,用于发起和管理用户间的会话。SIP 端系统称为用户代理,中间单元称为代理服务器。典型的SIP 配置如图1 所示。在图1 中,域A 中的主叫用户(UA1) 想呼叫域B 中的用户Joe(joe@B)。首先UA1 需要和自己所属域(域A)中的代理服务器1 通信,代理服务器1 向被叫用户所属域( 域B) 内的代理服务器—— 代理服务器2 前传呼叫请求, 然后代理服务器2 向被叫用户——UA2 前传呼叫。
作为呼叫流程的一部分,代理服务器1 需要为域B 确定SIP 服务器。为此代理服务器1 使用DNS 程序,同时使用SRV 和NAPTR 记录。
E.2 DNS 需要解决的问题
需要利用DNS 系统协助解决简介中描述的整个呼叫流程中的两个问题。第一个问题是代理服务器1 如何找到域B 中的SIP 服务器,以便把呼叫前传给joe@B; 第二个问题是当代理服务器1 在前传呼叫请求之后发生故障时,代理服务器2 如何识别代理服务器1 的备份服务器。
对于第一个问题,代理服务器1 需要明确确定域B 中SIP 服务器的IP 地址、端口号和传输协议。传输协议的选择尤其要注意。和许多其他协议不同,SIP 协议可以承载在各种传输协议之上,包括TCP、UDP 和SCTP。因此客户端需要能够自动确定哪一种传输协议可用。发送请求的代理服务器有一个它所支持的特定的传输协议集,同时在这些传输协议中有一个优选协议。代理服务器2 有它自己支持的传输协议集,和相应的优选传输协议。所有的代理服务器必须同时支持UDP 和TCP, 因此总是存在能力集的交集。对于代理服务器1 需要某种类型的DNS 程序,以便找到域B 中SIP 业务可用的传输协议, 以及这些传输协议中优选的传输协议。代理服务器1 找到它所支持的传输协议列表和代理服务器2 所支持的传输协议列表的交集,从中的选出代理服务器2 优选的协议。

图1 SIP 协议的典型配置

在处理呼叫的过程中可以多次执行DNS 查询。通常,要发送请求的单元(称为客户端)可能需要执行DNS 程序以便确定下一跳单元(称为服务器,可以是代理服务器也可以是用户代理服务器)的IP 地址、端口号和传输协议。在两个单元之间的任何一跳上都可能执行DNS 查询程序。
既然SIP 协议用于建立交互式通信服务, 那么主被叫用户之间事务处理的完成时间就非常重要。通常从主叫用户发起呼叫到被叫用户被提醒之间的时间应不大于几秒。假定在呼叫过程中要经过多跳,并且假设除了潜在的近似实时的操作之外每一跳都要执行DNS 查询,那么对于每一跳DNS 查询的时间将受到限制。
可扩展性和高可用性在SIP 协议很重要。在实现SIP 业务的过程中可能使用多种技术。典型的, 图1 所示的网络在实际应用中,代理服务器2 可能是一组同样配置的代理服务器,此时需要DNS 提供为域B 配置一组服务器的能力,包括优先级和权重,以便为基于能力的负荷分担提供一个的粗略的等级。
SIP 利用上行单元检测故障的机制来确保高可用性。例如,假设代理服务器2 在实际网络中对应到两个代理服务器—— 代理服务器2.1 和代理服务器2.2。如果代理服务器1 向代理服务器2.1 发送了一个请求且请求失败, 那么代理服务器1 可以向代理服务器2.2 再次发送该请求。在许多情况下, 代理服务器1 不知道最终要和哪个域进行通信。当用户确实向其他域的用户发起呼叫时,才有可能知道其他域的信息。呼叫结束之后代理服务器1 可能再也不会和该域进行通信。在几分钟之内代理服务器1 可能和成千上万个不同的域进行通信,同时代理服务器2 也可能在几分钟之内从成千上万个不同的域收到请求消息。由于这种“多对多” 的关系, 且两个域之间的通信间隔可能很长, 所以一个单元一般不可能维护它要与之进行通信的代理服务器的动态可用状态。当代理服务器从某个特定的域收到第一个呼叫时,代理服务器应该依次尝试该域内的服务器,直到找到一个可用的服务器为止。理想情况下这个可用服务器的标识应该缓存一段时间,以便减少后续呼叫建立的时延。客户端不应连续地查询故障服务器来确定该服务器是否又重新可用。而且,最终要刷新可用性状态,以便向已经恢复的单元重新分配负荷。
单元在事务处理过程中可能发生故障。例如,代理服务器2 向UA 2 前传了请求之后,代理服务器1 故障,UA 2 向代理服务器2 发送响应,代理服务器2 试图向代理服务器1 前传,而此时代理服务器1 已经不再可用。此时, 就需要DNS 协助解决简介中描述的呼叫流程中的第二个问题, 代理服务器2 要标识代理服务器1 的备份服务器, 以便向备份的服务器发送该响应。这个问题在SIP 协议比较突出, 因为有些SIP 响应需要很长的时间才能产生, 主要是因为产生这些响应常常需要和人进行交互。因此, 在呼叫请求和呼叫应答之间常需要几十秒的时间。
E.3 客户端用法
在客户端和服务器端DNS 的用法不同。本节讨论客户端用法。首先假设客户端是stateful( 可以是用户代理客户端(UAC )也可以是stateful 代理服务器)。
当客户端需要向SIP URI 或SIPS URI 标识的资源发送请求时,将调用此处描述的程序。URI 可以标识请求要发往的资源(此时URI 在Request-URI 字段中), 或者标识到达目标资源要经过的中间某一跳(此时URI 在Route 字段中)。此处描述的程序不影响此URI( 即DNS 查询的结果不会改写此URI) ,只是产生请求可发往的IP 地址、端口号和传输协议。RFC3261 对确定哪个URI 需要在DNS 中解析进行了指导性描述,以便确定请求需发往的主机。RFC3261 也提出,在有些情况下,请求可以发送到不是用SIP URI 标识,而是用主机名或数字型IP 地址标识的特定的中间代理服务器。在这种情况下将使用一个临时URI 。该URI 的形式为sip:< 代理服务器>, 此处的代理服务器可以是下一跳代理服务器的FQDN 或数字型IP 地址。因此在所有的情况下,问题就局限在在DNS 中解析SIP URI 或SIPS URI ,以便确定请求要发往的主机的IP 地址、端口号和传输协议。
每个事务处理必须正确地执行一次此处描述的程序。也就是所,一旦和SIP 服务器成功建立了连接,所有重传的SIP 请求和ACK(此ACK 是为证实响应INVITE 消息而发送的non-2xx) 都必须发往同一个主机。而且,对于特定SIP 请求的CANCEL 消息必须发送到SIP 请求发送到的同一个SIP 服务器。
由于ACK 请求(此ACK 是为证实响应INVITE 消息而发送的non-2xx) 将创建不同的事务处理,所
以不要求该ACK 发送到收到初始请求的服务器( 实际上,如果服务器在non-2xx 中不包含record-route 字段,它也收不到该ACK)。如果在URI 中包含maddr 参数, 那么将目标作为该参数的值,否则将目标作为URI 中主机端口部分的主机值。目标标识了要建立连接的域。
E.3.1 选择传输协议
首先客户端要选择传输协议。如果URI 在transport 参数中指定了传输协议,则应使用该传输协议。否则,如果没有指定传输协议,但目标是一个数字型IP 地址,那么对于SIP URI 客户端应该使用
UDP,对于SIPS URI 客户端应该使用TCP。同样,如果没有指定传输协议,并且目标不是数字型的IP 地址,但是提供了具体的端口号,那么对于SIP URI 客户端应该使用UDP, 对于SIPS URI 客户端应该使用TCP。
否则,如果没有指定传输协议或端口号,并且目标不是数字型IP 地址,那么客户端应该对URI 中的域名执行NAPTR 查询。和传输协议选择相关的业务是包含NAPTR 业务字段且该字段的值为”SIP+D2X” 和”SIPS+D2X”的业务,字母X 对应该域所支持的传输协议。本规范为UDP 定义了D2U,为TCP 定义了D2T。在NAPTR 业务字段中NAPTR 记录提供域名到SRV 记录的映射,以便使用特定的传输协议和服务器建立连接。资源记录将包含一个空的规则表达式和一个替换值,该实体记录是针对特定传输协议的SRV 记录。如果服务器支持多个传输协议, 将有多个NAPTR 记录, 每个有不同的业务值。客户端丢弃业务字段不可用的记录。本规范中定义了几个规则。
首先,解析SIPS URI 的客户端应丢弃业务字段中协议不为SIPS 的所有业务,相反却不正确。解析SIP URI 的客户端应保留记录。其次,客户端应丢弃业务字段(标识解析的业务)的值不为”D2X”的所有业务,X 的值指示客户端所支持的传输协议。和SRV 记录相同, 针对服务器,处理NAPTR 能得出客户端所支持的、并且服务器最优选的是传输协议。
例如, 客户端要解析sip:user@example.com 。针对域名客户端执行NAPTR 查询, 将返回如下NAPTR 记录:
次序优先级标志 业务 规则表达式 替换值
IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.example.com.
IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.example.com
IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.com.

既然客户端支持TCP 和UDP,那么可以使用TCP 和通过SRV 查询”_sip._tcp.example.com”确定的主机建立联系。
优先级权重端口号目标
IN SRV 0 1 5060 server1.example.com
IN SRV 0 2 5060 server2.example.com
如果通过查询NAPTR 记录可以和SIP 代理服务器、重定向服务器或注册服务器建立连接,那么至少有三个记录—— 一个记录包含”SIP+D2T”业务字段,一个包含”SIP+D2U”业务字段,一个包含”SIPS+D2T”业务字段。业务字段中协议为SIPS 的记录应比业务字段中协议为SIP 的记录优先级高(即次序字段的值较小)。业务字段为”SIPS+D2U”的记录不应出现在DNS 中。
在NAPTR 替换值字段中域名的后缀没必要和初始请求中的域名( 即example.com )相匹配。然而,域必须为初始请求中的域名维护SRV 记录,即使NAPTR 记录在另一个域中。例如, 即使对TCP 已经有
SRV 记录” _sip._tcp.school.edu”,还必须有SRV 记录”_sip._tcp.example.com”。
如果服务器使用站点证明,那么基于TLS 交互中服务器提供的站点证明,对于包含SIPS 协议字段的NAPTR 记录, NAPTR 查询中的域名和NAPTR 记录中替换值字段中的域名必须有效。同样基于相同的站点证明,SRV 查询中的域名和SRV 记录中目标字段中的域名必须有效。另外, 攻击者可能修改DNS 记录使替换值为一个不同的域名,而客户端不能确认该操作是一个合理的行为还是攻击的结果。
如果没有返回NAPTR 记录, 客户端将对它所支持的传输协议创建SRV 查询, 并且执行每个查询。对SIP URI 使用业务标识”_sip”,对SIPS URI 使用业务标识”_sips”执行SRV 查询。如果查询成功,那么将支持特定的传输协议。客户端可以使用任何它想使用的并且服务器支持的传输协议。
如果没有返回SRV 记录,对于SIPS URI ,客户端应使用TCP ,对于SIP URI 应使用UDP 。然而,可以使用其他传输协议如TCP, 如果对于特定的请求SIP 要求使用这个传输协议。例如超过通路MTU 的请求就是这种情况。
E.3.2 确定端口号和IP 地址
确定了传输协议之后就要确定IP 地址和端口号。
如果目标字段是数字型IP 地址,客户端将使用该地址。如果URI 中包含端口号,客户端也将使用该端口号。如果没有指定端口号,将使用传输协议对应的默认端口号。
如果目标字段不是数字型IP 地址, 但是在URI 中包含端口号, 那么客户端将执行域名的记录查询。查询结果为一列IP 地址,每个IP 地址可以使用URI 中的端口号和之前确定的传输协议进行连接。客户端应尝试第一个记录。如果尝试失败,将尝试下一个记录,如果失败再尝试下一个。
如果目标不是数字型IP 地址,并且在URI 中未包含端口号,那么如果执行了NAPTR 处理,客户端将根据NAPTR 处理返回的记录执行SRV 查询。如果没有执行NAPTR 处理, 因为已经指定传输协议, 客户端可以针对该传输协议执行SRV 查询,并且对于SIPS URI 使用业务标识”_sips”,对于SIP URI 使用业务标识”_sip”。如果因为没有返回NAPTR 记录而未执行NAPTR 处理,但是针对所支持的传输协议SRV 查询成功,那么将选择返回的SRV 记录。不考虑如何确定SRV 记录,执行RFC2782 的”使用规则”一节中描述的程序,并且遵循下一节对该程序的扩充。
如果没有返回SRV 记录, 那么客户端将执行域名查询。查询结果将为一列IP 地址,每个地址可以使用之前确定的传输协议和所对应的默认端口号进行连接。一旦查询到记录,将对具体的端口号执行上述程序。
E.3.3 RFC 2782 处理细节
RFC 2782 描述了一组SRV 记录如何分类和如何尝试。然而,它仅仅说明了客户端应”尝试建立连接到(协议、地址、业务)”,而没有详细描述故障时发生的情况。此处将描述这些细节问题。
对于SIP 请求,如果事务处理层响应503 或是某一类的传输失败(通常是由于UDP 中重大的ICMP 错误或TCP 中连接故障), 那么此时故障发生。如果事务处理层定时器(即定时器B 或定时器F 超时) 超时时没有收到过任何响应,包括临时响应或最终响应,那么此时也发生了故障。如果故障发生, 客户端应该创建一个新的请求, 该请求和先前的请求相同, 除了Via 字段中的branch ID 和先前的请求具有不同的值(这样将创建新的SIP 事务处理)。该请求发往RFC 2782 指定列表中的下一个单元。
E.3.4 Stateless 代理服务器的考虑
前面章节中描述的处理程序都是针对stateful 代理服务器的。当一个服务器被成功连接,对于该事务处理所有重发请求、证实非最终响应2xx 的ACK 以及CANCEL 请求,都必须发送到相同的服务器。
事务处理状态中包含成功连接的服务器的标识。这对stateless 代理服务器来说是一个难题,stateless 代理服务器也需要在事务处理中将所有请求都发送到同一个服务器。
cookie 会话中的HTTP 事务处理基于DNS 随机选路到不同服务器, 采用那个服务器不是问题。通常工作的服务器共享保存会话数据的后台数据存储区。当工作的服务器收到HTTP 请求,且请求中包含会话标识,服务器将根据会话标识获取处理请求所需的状态。收到未包含会话标识的请求时将创建一个新的状态。然而和stateless 代理服务器相关的问题不同,和stateless 代理服务器相关的问题处在较低层,经过stateless 代理服务器传递的请求在事务处理中被看作重传的请求。既然这些重传的请求中都不含会话标识(即完整的对话标识), 那么应在每个服务器中创建一个完全相同的新的对话。这可能导致到同一个电话创建了多个呼叫。因此,关键在于如何在刚开始的时候就防止这种情况的发生。
如果尝试和服务器建立连接时没有发生故障,那么此时比较容易防止这种情况的发生。当stateless 代理服务器收到请求时, 它将执行上述DNS 查询。对于具有相同优先权的记录,Stateless 代理服务器必须使用配置的算法确定记录的次序。一种建议是将这些记录按照字母顺序排列,另一种更常用的方式是按照标准的ASCII 编码对记录进行排列。要使stateless 代理服务器的处理简单,建议域名管理者使具有相同优先级的SRV 记录具有不同的权重( 例如: 如果两个服务器的优先级相同,分配不同权重1000 和1001 比分配相同权重1000 好),对NAPTR 记录也类似处理。如果成功地和第一个服务器建立连接,代理服务器将仍作为stateless 服务器。但是如果没有成功地和第一个服务器建立连接,而是和后续的服务器建立了连接,那么对于该事务处理代理服务器不能继续作为stateless 服务器。如果服务器是stateless 服务器,那么如果在重传过程中故障的服务器恢复将很有可能使重传请求发送到不同的服务器。因此,当代理服务器不能和第一个服务器成功建立连接时,该服务器应作为stateful 代理服务器。
但是stateless 代理服务器仍然有可能向另外的服务器转发重传请求,即使该stateless 服务器遵循上述描述。在事务处理过程中如果DNS TTL 超时并且列项已经改变,将有可能出现这种情况。这种情况不可避免。网络设计者应该意识到这种限制,如果这种错误比较严重应不使用stateless 代理服务器接入DNS 。
E.4 服务器用法
通常,对于单播UDP 请求,响应应该回送到发送请求的源IP 地址,使用Via 头部中的端口号。对于可靠的传输协议,应在收到请求的连接上发送响应。但是当在发送请求和接收响应的过程中客户单元故障时,对故障克服机制的支持就非常重要。
对于可靠的传输协议, 服务器将在收到请求的连接上发送响应, 对于不可靠的传输协议, 响应将发送到请求中的源地址和Via 头部字段中的端口号。当服务器尝试向相应的地址发送响应但发生故障时调用此处描述的程序。“故障”指的是在发送响应之前,收到请求的传输连接关闭或者传输层指示通信中发生重大错误。
在这些情况下, 服务器检查最顶部Via 头部字段中Sent-by 参数的值。如果该值是数字型IP 地址,那么服务器尝试向该地址发送响应,并且使用Via 头部字段中的传输协议,如果Sent-by 参数中包含端口号则使用该端口号,否则使用该传输协议对应的缺省端口号。
如果Sent-by 参数字段包含域名和端口号,那么服务器将使用该域名查询记录。服务器尝试向查询结果IP 地址列表中的每个地址发送响应,使用Via 字段中的端口号和传输协议。和客户端的处理相同,如果失败则尝试列表中的下一个IP 地址。
如果sent-by 字段包含域名但不包含端口号,那么服务器将使用业务标识”_sip”查询该域名的SRV 记录。对结果列表按照RFC 3262 中的描述进行分类,并且将响应发送到位于新列表中最顶部的单元。如果失败,则尝试下一个列项。
E.5 构建SIP URI
在许多情况下,单元需要构建SIP URI ,以便包含在REGISTER 的Contact 头部字段中,或者包含在INVITE 的Record-Route 头部字段中。这些URI 必须解析成插入它们的单元。但是,如果这些URI 只用IP 地址构成,例如:
sip:1.2.3.4
那么如果单元故障,则没有办法将请求或者响应选路到备用单元。
SRV 提供了一种解决这个问题的办法。代替使用IP 地址,解析成SRV 记录的域名可以使用:
sip:server23.provider.com
对于特定的目标可以构建SRV 记录,使其中一个记录的优先级较小,并且该记录指向构建该URI 的特定单元。同时也应该有其他记录,这些记录的优先级较大,并且用来指向故障时的备用单元。
E.6 安全考虑
攻击者可以通过缓存来分流消息。经常和相同的域建立连接的客户端应缓存NAPTR 记录,无论该NAPTR 记录的业务字段是否包含SIPS 。如果出现这样的记录,而在以后的查询中不再出现,那么这是隐秘攻击的一种迹象。在这种情况下,客户端应产生提示或告警信息并且可以拒绝请求。
另外一种情况是处于系统端用户之间的代理服务器经常要发起NAPTR 查询,因此代理服务器有可能忽略业务字段为SIPS 的记录,即使有这些记录,这将降低安全性。很难采取措施来防止这样的攻击。客户端简单地依赖代理服务器完成呼叫,就必须相信代理服务器能够正确地实现提供一定安全性的协议。通过篡改业务(在缺少DNSSEC 的情况下)可以伪造DNS 记录, 妥协和强迫代理服务器请求中断,但是这种情况比降低安全性的威胁少。
E.7 传输协议确定应用
本节描述NAPTR 的用法,使用动态删除发现系统(DDDS )框架。DDDS 代表NAPTR 资源记录的演进。DDDS 定义应用,该应用针对特定的解析业务使用NAPTR 记录。该应用称为传输协议确定应用,目的是将输入的SIP URI 或SIPS URI 映射到一组SRV 记录,这些记录对应到处理该URI 的各种服务器。
下面是DDDS 请求应用提供的信息:
应用唯一字符串:应用唯一字符串(AUS)是解析业务的输入。此处是要解析的URI。
第一个众所周知的规则: 第一个众所周知的规则是从AUS 中提取的关键字。此处是SIP URI 或SIPS URI 的主机部分。
有效的数据库: 在单一的数据库中查寻从第一个众所周知的规则中等到的关键字。此处有效的数据库是DNS 。
期望的输出:应用的结果是对应要连接的服务器的SRV 记录。
附录 F (标准性附录)
SDP 的提供/应答模式
利用该机制两个实体可以使用SDP 对它们之间的多媒体会话达成一致。在该模式中, 一个参加者向另一个参加者提供它期望建立的会话的描述,另一个参加者应答它期望建立的对话。提供/应答模式在单播会话中最有用,此时需要两个参加者的信息来完成会话的协商。SIP 协议可以使用提供/应答模式。
F.1 简介
SDP 最早用作描述多媒体网络中的组播会话。SAP 被设计成一种组播机制来传送SDP 消息。虽然SDP 规范中允许用于单播操作,但是该规范不完善。组播会话需要所有参加者对所使用的对话进行整体协商,但是单播会话不同, 单播会话只包含两个参加者, 会话的协商仅需要两个参加者的信息, 且仅需要两个参加者对各种参数达成一致。
例如, 组播会话需要对于特定的媒体流通告一个组播地址, 但是对于单播会话, 需要两个地址—— 每个参加者一个。又例如, 组播会话要指出会话中使用的编解码,但是对于单播会话,需要确定一组两个参加者都支持的编解码。
因此, 虽然SDP 能够描述单播对话,但是它缺少具体的语义和操作描述。本文通过基于SDP 定义的简单提供/应答模式对此进行补充,。在该模式中会话的一个参加者产生SDP 消息,该SDP 消息构成提供——提供者希望使用的一组媒体流和编解码,以及提供者想用来接收媒体的IP 地址和端口号。提供传送给另一个接收者,称为应答者。应答者产生应答, 应答是SDP 消息用来响应提供者的提供。应答中包含与提供中相同的媒体流,指示该媒体流是否被接受,以及所使用的编解码和应答者希望用来接收媒体所使用的IP 地址和端口号。
组播会话也有可能象单播会话一样工作; 两个用户之间协商会话参数, 类似于单播会话, 但是和单播会话不同,两个用户都向同一个组播地址发送分组。本文也讨论了提供/应答模式对组播媒体流的应用。
同时本文也描述了在初始提供/应答交互之后如何使用提供/应答模式来更新会话。
本文不规定提供和应答传递的方式。这里定义的提供/应答模式是SIP 必须使用的基本机制。
F.2 定义
代理:代理是在提供/应答交互中涉及的协议实现,共涉及两种代理。
应答:应答者发送的SDP 消息,用来相应从提供者收到的提供。
应答者: 一个代理, 从其他代理接收描述期望进行的媒体通信的会话描述, 然后用自己的会话描述进行响应。
媒体流: 单个媒体实例,例如:音频流或视频流,也可以是单个白板或共享应用组。在SDP 中,媒体流用”m=”行和相关的属性描述。
提供:提供者发送的SDP 消息。
提供者:一个代理,产生会话描述用来创建或修改会话。
F.3 协议操作
提供/应答交互假设存在高层协议(例如SIP)为了会话建立该协议能够在代理之间交换SDP 信息。

当一个代理向另一个代理发送初始提供时协议操作开始。如果提供位于高层协议建立的所有上下文之外, 那么该提供即为初始提供。假设高程协议提供对某类上下文的维护, 该上下文允许同时进行各种相关SDP 消息的交互。
收到提供的代理可以产生应答,也可以拒绝该提供。拒绝提供的方式依赖于高层协议。提供/应答的交互是自动的;如果应答被拒绝,会话恢复到提供之前的状态(可能没有对话)。
任何时候, 任何代理都可以产生新的提供来更新对话。但是, 如果该代理已经收到一个提供但还没有进行应答或还没有拒绝,那么该代理就不能产生新的提供。另外如果它已经产生了一个提供但还没有收到应答或拒绝消息, 那么它也不能产生新的提供。如果代理在发送提供之后又收到一个提供, 但是对发送的提供还没有收到响应,这时将被认为发生了“同抢”。
同抢最初用在电路交换网中,用来描述两个交换机同时想占用同一条中继上的同一个空闲电路。这里,同抢指的是两个代理想同时发送更新的提供。
高层协议需要提供一种解决这种情况的方式。高层协议需要在每个方向上对消息进行排列。SIP 协议能够满足这种要求。
F.4 产生初始提供
提供和应答应是有效的SDP 消息,如RFC 2327 中的定义,但是有一个例外。RFC2327 要求在SDP 消息中必须同时包含e 和p 行。本规范放松了该限制;提供/应答应用描述的SDP 可以同时省略e 和p 行。
o 行中会话ID 的值和版本号的值应能够用64 比特符号整数表示。版本号的初始值应小于262-1 以避免环回。虽然SDP 规范允许将多个会话一起放入一个大的SDP 消息中,但是提供/应答模式中使用的SDP 消息应只包含一个会话描述。
SDP 中的”s=”行传送会话主题,主要用于组播而非单播。对于单播对话,建议该行采用一个空格(0x20)或破折号(-) 表示。
但是,SDP 不允许”s=”行为空。
SDP 的”t=”行传送会话时间。通常,单播会话的媒体流使用外部信令的方式建立和终止, 如SIP。此时,”t=”行应填充之"0 0" 。
提供将包含零个或多个媒体流(每个媒体流用"m="行和相关的属性描述)。零个媒体流隐含地指出提供者希望进行通信,但是会话的媒体流将在之后通过修改提供的方式增加。媒体流可以同时用于单播和多播;在用于多播的情况下,在相关的"c="行中指示多播地址。
每个提供的媒体流的创建依赖于该媒体流是单播还是组播。
F.4.1 单播媒体流
如果提供者希望在一个媒体流上仅向它的对等发送媒体,那么它应通过"a=sendonly" 属性来标记该流为只发。如果在媒体流属性或会话属性中有方向属性, 那么该流就被标记了一定的方向。如果提供者希望从它的对等只接收媒体, 它应标记该流为只收。如果提供者希望进行通信, 但是此时既不希望发送也不希望接收媒体, 那么它应用属性"a=inactive" 标记该流。此时该流未激活, 在RFC3108 中定义了未激活的方向属性。注意对于实时传输协议(RTP)对于只发、只收和未激活的流仍然要发送和接收RTCP 。
, 也就是说,媒体流的方向性不影响RTCP 的使用。如果提供者希望和它的对等之间同时进行媒体的接收和发送,那么它可以包含属性"a=sendrecv", 也可以省略该属性,因为收发是默认的。
对于只收和收发媒体流, 提供中的端口号和地址指示提供者希望从哪里接收媒体流。对于只发RTP 流,地址和端口号隐含地指示提供者希望从哪里接收RTCP 报告。除非明确指明, 否则RTCP 报告将发送到比指定值大一的端口号。提供中的IP 地址和端口号没有对提供者发送RTP 分组和RTCP 分组的源IP 地址和源端口号进行指定。提供中的端口号为0 指示提供媒体流但不能使用该媒体流。这在初始提供中没有太大意义,但是为了完成的原因, 应答可以包含0 端口号来指示拒绝媒体流。而且已经存在的媒体流可以通过将端口号设置为0 来终止。通常,0 端口号指示不期望该媒体流。
每个媒体流的媒体格式列表传达了两个信息,即提供者能够发送和/或接收(依赖于方向属性)媒体的格式集( 在使用RTP 的情况下, 主要是编解码以及和编解码相关参数), 以及在使用RTP 的情况下, 用于标识这些格式的RTP 载荷的类型值。如果列出了多个格式,那么意味着提供者能够在会话过程中使用其中的任何一个。也就是说,在会话过程中不用发送新的提供,应答可以使用列出的这些格式中的任何一个改变媒体格式。对于只发媒体流, 提供指示对于该媒体流提供者期望发送的媒体格式。对于只收媒体流, 提供指示对于该媒体流提供者期望接收的媒体格式。对于收发媒体流, 提供指示提供者期望发送和接收的媒体的编解码。
136
对于只收RTP 媒体流,载荷类型值指示对于该编解码提供者期望接收的RTP 分组中载荷类型字段的值。对于只发RTP 媒体流,载荷类型值指示对于该编解码提供者期望发送的RTP 分组中载荷类型字段的值。对于收发RTP 媒体流,载荷类型值指示提供者期望接收和发送的RTP 分组中载荷类型字段的值。但是,对于只发和收发媒体流, 对于相同的编解码,应答可能指示不同的载荷类型值, 在这种情况下,提供者必须使用应答中的载荷类型值发送RTP 分组。
为了和H.323 互通, 在每个方向上可能需要不同的载荷类型值。
可以包含fmtp 参数来提供媒体格式的其他参数。
在使用RTP 媒体流的情况下,所有的媒体描述应包含"a=rtpmap" 属性,指示从RTP 载荷类型到编码的映射。如果没有"a=rtpmap" ,将使用默认的载荷类型映射。
------分隔线----------------------------
顶一下
(2)
100%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容
  • VoIP的配置选择

    前面,我们已经围绕Vo I P 讨论了一些问题。现在,让我们讨论几种Vo I P 的配置和拓扑...

  • SIP协议介绍

    介绍 通信提供商及其合作伙伴和用户越来越渴求新一代基于 IP 的服务。现在有了 SIP协...

  • IP电话协议H.323协议 MGCP协议 SIP协议比较

    随着IP电话应用的普及,建立终端设备和网关的可扩展网络已成为业界面临的一大技术挑战...