信用建设网站动态信息报送制度最安全的域名注册商

信用建设网站动态信息报送制度,最安全的域名注册商,dw建设网站视频,义乌商城网站开发1. 引言 在会话初始化协议#xff08;SIP#xff09;RFC3261的定义里#xff0c;引用实体的基本单位是地址记录#xff08;AOR#xff09;。然而#xff0c;在一个SIP系统中#xff0c;单个用户可以拥有多个UA#xff08;手持设备、软电话、语音信箱账号#xff0c;等…1. 引言在会话初始化协议SIPRFC3261的定义里引用实体的基本单位是地址记录AOR。然而在一个SIP系统中单个用户可以拥有多个UA手持设备、软电话、语音信箱账号等等所有这些都通过同一个UA引用。在很多上下文中我们需要一个指向具体UA的标识符而不是指向一组UA的逻辑标识符AOR。举个例子考虑一个盲转请参考RFC5889 [19]的场景用户A正与用户B通话这时用户A希望把电话转给用户C。因此用户A向用户C发出一条REFER消息。下面是REFER消息的片段REFER sip:Cexample.com SIP/2.0 From: sip:Aexample.com;tag99asd To: sip:Cexample.com Refer-To: (URI that identifies Bs UA)在Refer-To报头里需要包含一个URI让用户C可以取代用户A与用户B通话。这时用户C所发起的通话需要路由给用户B正在使用的UA否则转移可能会失败。比如说如果A向C提供的是B的AOR这时B正用他的手持设备通话那么C发起的呼叫很可能被路由到语音信箱。为了方便通信用户B在SIP交换中向用户A提供了一个实例相关的URIContact 报头里的设备URI。这个URI指向了用户B当前所使用的UA它可以由用户C间接引用。用户B并不知道用户A会把电话转移给谁因此这个URI事实上是可以被任何人引用的。当前许多client端试图通过Contact报头所携带的IP地址来寻找它们所需要的实例关联的标识信息。但是由于NAT、防火墙的存在外部连接的clietn很可能是用不上这些信息的。使用hostname标识也会面临类似的问题。更何况许多SIP client自己没有获取hostname的能力。本规范描述了一种机制它提供了一种全局唯一的UA标识符可用于全局路由。我们把这种标识符称为全局可路由的UA URI(GRUU)。2. 术语本规范中关键字MUST必须, MUST NOT不许, REQUIRED要求, SHALL应当, SHALL NOT不当, SHOULD应该, SHOULD NOT不该, RECOMMENDED建议, MAY可能, 和OPTIONAL可选的定义遵循RFC2119。此外本规范定义了以下专用术语contact: 术语 contact全小写时指的是通过注册绑定到AORt和GRUU的URI。通常contact是一个SIP URI它通过REGISTER请求的Contact头域携带绑定到AOR和GRUU上。remote target: 术语 remote target 是一个URIUA用它标识自己用于接收dialog内和dialog外的请求。remote target 是在建立dialog的交互过程中建立的通常是在请求和应答消息里的Contact头域中携带它可以在后续的刷新请求和应答中更新。Contact 头域: 术语Contact头域指的是在REGISTER请求及应答消息、重定向消息或创建dialog的请求及应答中消息携带的消息报头。根据不同语义Contact头域有时承载的是contact有时承载的是remote target。3. 操作概述GRUU背后的基本思想很简单。GRUU由某个SIP域颁发通常可以路由到这个域内的一台proxy。反过来SIP域负责维护GRUU和特定UA实例之间的绑定。当发出SIP请求解除GRUU绑定时这个请求会被路由给这台proxy。它负责特定UA实例的contact和GRUU之间的映射因此把消息路由给它。3.1. GRUU的结构GRUU是一个SIP URI它拥有两个属性o 它路由到一个特定的UA实例。o 它可以由Internet上的任意UA解绑不局限于GRUU指向的UA实例所在的域。原则上只要满足上述两条就可以选择任意方式来构造GRUU。但是为了让GRUU的接收方可以知道这两个属性要求所有GRUU包含gr URI参数带不带值都可以。在实践中存在两种不同的GRUU1. 暴露潜在AOR的GRUU2. 隐藏潜在AOR的GRUU3.1.1. 暴露潜在AOR的GRUU在很多场景中构建GRUU时会显式映射AOR。比如说很多UA保留呼叫日志记录呼叫的尝试。如果UA呼叫一个GRUU也许是呼叫转移请求触发的结果那么呼叫日志中将会包含GRUU信息。因为日志最终是要呈现给用户的那么如果日志内容里用AOR描述将是会很有帮助的因为AOR对用户来说是有意义的标识符。这种GRUU称为公共的GRUU。构造时取AOR的值加上gr URI参数其值是由域内注册服务器生成的。gr URI参数的值 表示具体的UA实例。假设有这么一个AORsip:aliceexample.com那么对应的GRUU可能是sip:aliceexample.com;grkjh29x97us97d如果接收终端删除gr URI参数那么结果就是取AOR的值。很多系统会忽略它们不能处理的参数这时公共GRUU就等价于AOR。3.1.2. 隐藏潜在AOR的GRUU在其他一些场景中我们希望构造GRUU时隐藏AOR的信息不让接收方提取。这样的GRUU称为临时GRUU。最明显的用途是保护用户的隐私。这时只要GRUU满足3.1 和5.4要求就行它可以携带任何内容只要不让别人猜出AOR就行。这时GRUU携带的gr URI参数可以不带参数值。为了避免在注册服务器建立过多的状态通常通过算法构造“无状态的”GRUU具体请参考附录A。下面是一个无状态GRUU的具体实例sip:asd887f9dfkk76690example.com;gr3.2. 获取GRUUUA有多种获取GRUU的途径o 作为REGISTER 事务的组件o UA本地构造使用自己的IP地址或主机名作为URI的domain组件描述UA实例。这称为自制GRUU。只有在UA的IP或主机名是全局可见的前提下这个GRUU才是真正意义上的GRUU。o 通过一些指定的本地管理机制。如果UA希望通过REGISTER请求获取GRUU那么它要在Contact头域中携带一个sip.instance参数传递instance IDRFC5626比如Contact: sip:callee192.0.2.2;sip.instanceurn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6注册服务器发现这个参数在REGISTER 的应答消息中提供两个GRUU其中一个是临时GRUU一个是公共GRUU。消息中这两个GRUU分别用temp-gruu 和pub-gruu参数描述Contact 头域。比如allOneLine Contact: sip:callee192.0.2.2;pub-gruusip:calleeexample.com;grurn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;temp-gruusip:tgruu.7hsjd7vnzga5w7fajsc7-ajd6fabz0f8g5example.com;gr;sip.instanceurn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;expires3600 /allOneLine注意the allOneLine 这个tag的用法如附录[17]所述。UA刷新注册时注册服务器将返回同一个公共GRUU但会建立一个新的临时GRUU。尽管每次刷新都会创建一个新的临GRUU但是之前REGISTER应答中学习到的所有临时GRUU的contact在期生命周期中依然有效只要满足下列条件(1)这个instance ID指向的contact依然在注册(2)与之前的reg-id 附录14RFC5626实例比较UA没有变更REGISTER请求中的Call-ID。当实例的最后一个contact超时后无论是因为注销还是因为定时器触发所有临时GRUU都将失效。同样如果注册方刷新contact时或者使用RFC5626reg-id变更了Call-ID那么之前的所有临时GRUU都将失效。如果UA后来用同一实例ID发起注册那么得到的公共GRUU是同一个但临时GRUU会是全新的因为已经刷新过了此外直到下次刷新之前这个临时GRUU将是唯一的有效ID因为前面的ID因为实例ID变更已经抢失效了。因此临时GRUU在注册生命周期内是可以“积累的”。3.3. 使用GRUU一旦UA从注册服务器取得GRUU就拥有了多少使用它的方式。首先可以把它作为非REGISTER请求及应答比如INVITE消息和对应的200 OK的Contact头域的内容。根据RFC3261的定义Contact头域携带了可以直接路由到这个UA的URI。在本规范之前还没有真正满足这一需求的方式出现。UA可以在匿名呼叫中使用临时GRUU其他场景使用公共GRUU。此外UA可以在其他需要解析指向自己的地方使用GRUU比如WEB页面上。3.4. GRUU解析引用因为GRUU就是一个简单的URI所以引用的方式和其它URI没什么不同。但是当请求路由到对应的proxy时它的处理行为却稍微有点不同。proxy需要把GRUU映射为AOR并从注册实例中确实GRUU指向的具体实例。然后把消息路由给指定的实例。4. UA行为本章定义UA的行为规范。4.1. 生成REGISTER 请求当遵循本规范的UA生成REGISTER请求时它必须在请求中包含Supported头域。Supported头域中必须包含gruu选项标签。这告诉注册服务器UA支持GRUU机制。这类Contact头域字段不应SHOULD NOT包含pub-gruu或temp-gruu。此外如果UA希望获取GRUU那么它的每个contact必须携带一个sip.instance媒体特性标签参考RFC5626[14]作为UA特征参见[7]其值必须是标识当前注册的UA实例的ID。基于RFC 3261 [1]的等价规则比较contact URI不允许MUST NOT等价于To头域里的AOR。如果contact URI是一个GRUU那么它不允许MUST NOT为To头域里的AOR的GRUU。根据RFC 3261 [1]REGISTER刷新请求中的Call-ID应当SHOULD 完全等同于先前注册contact的Call-ID。带GRUU时有一个额外的考虑。如果在注册刷新时Call-ID有变化那么服务端将废弃之前所有与这个UA实例关联的临时GRUU唯一有效值将是REGISTER应答中新生成的那个。遵循RFC 5626时这一规则适用于reg-id如果特定reg-id注册刷新时变更了Call-ID那么服务端将废弃之前关联到这个UA实例的所有GRUU。因此如果UA希望让之前获取的GRUU保持效力那么它在刷新注册时必须MUST 用相同的Call-ID反之如果它想弃用之前的GRUU可以MAY改变Call-ID。请注意如果有dialog正在进行中并且它使用GRUU作为remote target恰好这时UA变更Call-ID进行刷新操作那么dialog所使用的GRUU可能会失效导致后续的消息处理失败。如果UA实例注册多个contact用于HA冗余备份那么它必须遵循RFC5626[14]的定义。使用GRUU的UA依然可以执行第三方注册可以携带省力sip.instance Contact头域字段的contact内容。如果UA期望在对方不支持本规范时中止注册那么它应当MAY在请求中携带Require头域并在头域值上添加gruu选项标签。这是Supported头域之外的消息内容。至于Proxy-Require头域的使用则是没必要的本规范也不建议。4.2. 从REGISTER 应答消息中学习GRUU如果REGISTER应答是2XX每条包含sip.instance 参数的Contact头域也可以包含pub-gruu 和temp-gruu参数。这两个参数分别承载UA实例的公共GRUU和临时GRUU信息。UA必须(MUST)支持以下场景的兼容只有 pub-gruu参数只有temp- gruu参数两者都有。临时GRUU的有效周期限定为注册的生命周期内公共GRUU则是跨注册的持续存在。UA每收到一个成功的REGISTER消息都会收到一个新的临时GRUU但公共GRUU保持不变。但是UA必须准备好处理公共GRUU变更因为持久性也有不确定性。如果UA在REGISTER刷新过程中针对同一contact或 reg-id变更了Call-ID那么它必须MUST丢弃之前学习到的临时GRUU。UA可以(MAY)保留零个、一个、部分或全部临时GRUU。如果UA存储了临时GRUU那么它必须保证GRUU不会因为UA与注册服务器之间的时钟偏差导致意外失效。因此UA必须刷新其注册以保证REGISTER的持续生效。对于默认的事务定时器假设注册周期大于64秒至少提前32秒刷新如果注册周期小于64秒UA应当SHOULD 折半提前刷新。请注意使用RFC5626 [14]并且UA注册多流实现冗余时只要有一个流还保持注册那么临时GRUU就有效。因此即使其中的一个流超时了之前学习的其它临时GRUU依然有效。在注册服务端强制缩短注册周期的场景下UA通过注册事件包还了解这些变化详见RFC3680[24]。同时实现RFC 3680和GRUU的UA必须实现RFC 3680 [24]的扩展以承载GRUU的信息如RFC5628[28]所定义因为这些是保持UA和注册服务端之间的临时GRUU集同步所需要的。更一般地说临时GRUU的效用取决于UA和注册服务器之间的有效的临时GRUU集合的同步。没有RFC3680[24]及它的GRUU扩展支持的话client端只有在注册周期超时之前刷新注册才能保持同步。除子强制注销之外 其他事件比如说网络中断连接失败短暂的刷新间隔可能导致GRUU集合的不一致。因此本规范建议实现临时GRUU的UA同时实现RFC 3680 [24] 和RFC 5628 [28]的扩展。REGISTER请求收到非2XX应答对之前提供给这个UA的GRUU没有影响。具体地说如果先前成功处理过REGISTER请求并向UA提供了一个GRUU那么后续的注册请求失败不会删除GRUU或令其失败。UA从REGISTER应答消息中学习到的GRUU的user和host部分必须不透明处理。也就是说不允许MUST NOTUA以任何形式修改。不允许UA修改或删除它不识别的URI参数。进一步说不允许UA添加、删除或修改proxy接收或处理请求相关的URI参数包括transport, lr, maddr, ttl, user, 和comp (RFC 3486 [25])。另一个在RFC3261 [1]里定义的URI参数method通常不会出现在GRUU里UA在向其它实体递交GRUU时可以MAY 加上method参数。类似的RFC 4240 [26]和RFC 4458 [27]定义的URI参数是供UA使用的。这些内容不应出现在注册服务器返回的GRUU里但是UA可以加上这些参数以表达UA期望得到参数所描述的相关服务。但是请注意如果另一个UA解除GRUU引用proxy在把Request-UR转换为注册的contact时这些参数会丢失除非提供了其它手段用于传递这些属性给UA。这类交付机制是目前标准化进程中的活跃主题详见Delivery of Request-URI Targets to User Agents [29]。4.3. 构建‘自制’GRUU许多UA比如说连接PSTN的网关、会议服务器、媒体服务器本身不执行注册因此不能通过注册机制获取GRUU。这类UA通常可以公开访问。这意味着该域的安全策略允许从公网上接入并递交给UA而无需域内的proxy干预。此外防火墙和NAT策略会允许这类请求进入网络。当UA确认满足这些条件时可以MAY 构建一个‘自制’GRUU。当然如果UA执行注册时满足这些条件也可以构建一个‘自制’GRUU。但是本规范推荐使用注册的机制来获取。‘自制’GRUU的域名部分等价于UA的IP地址或主机名。SIP URI的user部分则由UA任意选择。和其它GRUU一样URI必须包含gr参数以标识它是一个GRUU参数有没有值都可以。如果UA没有执行注册并且不能在公网上访问那么它需要通过其它方式获取GRUU。典型的方式是配置一个GRUU这个GRUU可以指向proxy并由proxy配置GRUU到IP或主机的映射关系。4.4. 使用自己的GRUUUA在dialog内处理请求和应答填充Contact头域时应当使用GRUU。换句话说遵循本规范的UA应当以自己的GRUU作为 remote target。包括o INVITE 请求o INVITE 的2xx 或 18x 应答带 To tag的o SUBSCRIBE 请求(参考[5])o SUBSCRIBE 的2xx 或 18x 应答带 To tag的o NOTIFY 请求o REFER 请求([6])o NOTIFY 的 2xx 应答o 请求o UPDATE 的 2xx 应答不使用GRUU的唯一原因是考虑隐私因素详见10.3一节。使用注册机制获取GRUU时UA必须先有一个活跃的注册进而必须通过这个注册学习GRUU。绝不允许使用已经失效的GRUU换句话说不能使用已超时的GRUU。UA既可以使用公共GRUU也可以选择一个临时GRUU。GRUU与Call-ID关联对于同一个UA的AOR或实例如果GRUU的Call-ID与最近REGISTER的Call-ID不同那么就不允许继续使用如果使用RFC 5626 [14]那么reg-id也是一样 。如果UA按RFC3323 [15]的描述构造匿名请求那么它应该SHOULD 选用临时GRUU。10.3一节提供了临时GRUU与隐私保护的更完整论述。如RFC3261 [1]所述UA应该在自己生成的请求或应答消息中携带Supported 头域标签gruu 以声明自己支持gruu扩展。4.4.1. 针对多个AOR实例的考虑在一些SIP网络里一个UA可以有多个AOR不论它是隶属一个域或多个域。这时需要考虑更全面一些。在UA发出请求消息时将会‘使用’其中的一条AOR。通常这个AOR会出现在请求的From头域中并且用这个AOR关联的唯一权证信息进行鉴权。植入Contact头域的GRUU应当是和这个AOR关联的。当UA使用tel URI(如 [11]所定义)作为From 的AOR时通常会有一个对应的SIP AOR作为tel URI的别名。那么可以把这个SIP URI所关联的GRUU作为Contact头域内容。在UA接收请求时2XX应答消息中Contact头域植入的GRUU应当是与请求目标最近的实体所关联的AOR或GRUU。有很多种方式可以决定使用AOR或GRUU来发请求。比如说UA为每个UA独立注册一个contactURI的user部分可以区分Request-URI携带contact内容里将指示具体的AOR。4.5. Dereferencing a GRUUGRUU的解除引用GRUU由URI参数gr标识这个参数有没有值都可以。UA希望把请求发给包含GRUU的URI时只需要知道它是要递交给指定UA实例的就行不需要采取其他更多的措施。有些UA实现了非标的URI处理机制来弥补很多URI不是全局可路由的不足。由于携带gr 参数的URI已经定义为全局可路由的了那么UA在处理这包含gr 参数的URI时就不应当再用这类前面所说的非标机制来处理。因为这个实例ID是一种被叫方能力参数那么UA可以尝试把请求发给用户的AOR同时包含一个Accept-Contact头域 ( 由[12]定义)由它标识路由给特定实例ID的偏好。尽管这看起来与向GRUU发送请求具有相同的效果但实际上并不是。 Accept-Contact头域描述的仅仅是主叫方的选项偏好。它们的有效性取决于UA如何构造Accept-Contact头域字段该字段与AOR的域处理逻辑交互从而导致请求路由到特定的实例。考虑到域内路由逻辑的可变性(例如基于时间路由给特定contact)这对许多域路由策略都不起作用。然而本规范并不禁止客户端尝试这样的请求因为在某些情况下所希望的操作确实是由偏好路由决定的。4.6. 在UI上呈现GRUU在UI上呈现GRUU时建议RECOMMENDED 删除gr参数。对于公共URI来说这能如你所愿生成AOR。对于临时GRUU看起来显示的URI是随机的。未来的工作可能会提供优化机制让我们识别匿名的URI和不适合呈现给用户的内容。5. 注册服务器行为5.1. 处理REGISTER 请求REGISTER 请求可能带有Require头域头域值包含 gruu选项标签这说明要求注册服务器必须理解本规范才能处理这个请求。但是它并不要求注册服务器必须建立GRUU。当注册服务器根据RFC3261的10.3一节所描述的第七步流程处理REGISTER请求中的contact时检查每个Contact头域是否包含sip.instance参数。如果注册周期不为0那么按本节的后续步骤继续处理contact。否则这个contact基于RFC3261的正常规则处理。注意对于Contact头域值为*并且注册周期为0的请求仍然按RFC 3261[1]中的定义处理——删除所有contact而不仅仅是具有特定实例ID的contact。如本规范5.4所述这将删除每个contact与AOR的绑定还有每个contact与GRUU的绑定。如果contact URI等价于AOR根据RFC 3261 定义的规则比较那么注册服务器必须MUST回403拒绝因为这会导致环回。如果 contact URI是 To头域的AOR的GRUU那么基于相同原因必须回403拒绝。如果 contact URI不是SIP URI那么注册服务器必须回403拒绝。接下来注册服务器检查是否有AOR对应的有效公共GRUU存在REGISTER 请求里的To头域内容和实例IDContact 头域的sip.instance参数。如果没有有效的公共GRUU这时应当SHOULD 根据5.4所述构建一个。这个公共GRUU必须带gr参数其值为AOR。如果contact包含pub-gruu Contact头域参数注册服务器必须忽略它。UA不能以任何方式向注册服务器提供或建议公共GRUU。接下来注册服务器检查现有的已注册contact是否有相同的AOR、实例ID还有REGISTER请求是否带有流[14]标识也就是reg-id。如果其中一条匹配那么查找最近的注册记录检查关联的Call-ID。如果Call-ID有变化那么注册服务器必须废弃之前为这个实例IDAOR所生成的所有临时GRUU。结果是从今往后所有发向这些GRUU的请求都将被拒绝状态码是404。接下来注册服务器应当SHOULD 为AOR实例ID创建一个新的临时GRUU。创建规则将在5.4一节中描述。临时GRUU的算法必须拥有以下两项属性1. 必须保证生成两个相同临时GRUU的可能性非常小。2. 给定一对GRUU必须保证很难算出它们是否为同一AOR所发出的。如果contact带有temp-gruu参数必须忽略它。UA不能以任何方式向注册服务器提供或建议临时GRUU。5.2. 生成REGISTER 应答对REGISTER请求生成200 (OK)应答时遵循RFC3261 10.3第8步所定义的流程。此外对应答消息中的每个Contact头域如果服务端存储了与contact相关联的实例ID那么这个实例ID以参数的形式返回。如果REGISTER请求中有携带gruu选项标签的Supported头域并且注册服务器上至少存在一个与AOR或实例ID关联的临时GRUU那么注册服务器必须增加一个temp-gruu Contactu头域参数。temp-gruu参数值是一个引号字符串其值是为这个实例ID最近生成的关联GRUU。此外如果注册服务器上有这个APR实例ID所关联的公共GRUU并且client端支持GRUU那么必须增加一个 pub-gruu Contact头域参数。pub-gruu Contact头域参数的值就是公共GRUU的值。在应答消息中不应在Require或Supported头域里携带gruu选项标签。5.3. 注册超时当已注册的contact超时时不论是因为定时器超时还是显式的注销它所绑定的AOR按正常删除。此外绑定的GRUU同时删除这是5.4所描述的关系的结果。如果由于contact过期某个特定的GRUU不再有任何已注册的contact绑定到它并且该GRUU是临时GRUU那么该GRUU必须失效。这意味着一旦给定实例ID的最后一个contact过期所有累积的临时gruu都会失效。但是如果GRUU是公共GRUU那么注册服务器应当把它视为有效的。因此后续指向这个GRUU的请求在向这个GRUU重新注册contact之前应当返回80 (Temporarily Unavailable)应答。此外由于GRUU仍然有效根据5.1的规则当带有这个实例IDAOR的contact继续注册时其值将继续使用。这些规则赋予公共GRUU永久的属性。其目的是只要AOR本身在域内是已知的注册服务器就会尽一切努力保持GRUU的有效性。这一条约的要求级别是应当SHOULD 而不是必须MUST 因为很难达到必须的级别。注册服务器的故障可能会导致有效GRUU丢失而本规范要求UA对这种场景保持健壮。也就是说可以构建一个公共 GRUU这样注册服务器就不需要为它保留任何额外的状态但 GRUU 仍然满足本规范的要求。5.4. 创建 GRUU本节定义注册服务器构建和维护GRUU的附加行为。这些规则不适用于自制GRUU和不通过注册机制获取GRUU的场景。一旦注册服务器创建一个GRUU就要求它维护与这个GRUU相关联的信息不论它是公共的还是临时的。每个GRUU都与一个独立的AOR及实例ID关联。当以GRUU的形式呈现时注册服务器必须拥有判定实例ID及AOR的能力。此外GRUU和AOR一样可以解析为零个或多个contact。AOR解析为已注册的所有contact但GRUU只解析为与GRUU关联的实例ID的contact。因此一个带有实例ID的contact通常同时绑定能GRUU和AOR上永远不会只绑定给AOR或者只绑定给GRUU。这个关系如图1所示。图中有三个contact注册到一个AOR。其中一个contact带有实例ID 1另外两个带有实例ID 2。在这个AOR有两个GRUU。其中一个关联实例ID 1另一个关联实例ID 2。第一个GRUU只能解析为带有实例ID 1的contact。第二个GRUU只能解析为带有实例ID 2的contact。如果UA崩溃、重启并以同一实例ID重新注册或者按RFC5626 的定义进行冗余注册那么对于同一实例ID就会出现多个contact。如果实例ID 1的contact超期那么AOR将会解析为两个contact但是关联实例ID 1的GRUU解析得到的就是零个contact。图 1同一个实例ID及AOR可以有多个GRUU。事实上本规范要求注册服务器维护多全GRUU其中公共GRUU只有一个临时GRUU可以有多个。然而如果两个GRUU关联到两个不同的AOR或实例ID上那么按照URI比较规则比较这两个GRUU它必须是不同的。按照URI比较规则域内的GRUU不允许与任何AOR等价除非它是这个AOR关联的GRUU。公共GRUU通常等价于AOR。根据RFC 3261 [1]的URI比较规则如果某个参数只在其中一个URI里出现那么比较时忽略这个参数。公共GRUU与AOR的区别仅在于有没有gr URI参数因此它们是等价的URI。一旦临时GRUU创建那么在按之前描述的规则判定失效之前注册服务器必须把它视为有效的。一旦公共GRUU创建那么在对应AOR有效的期间内它必须视为有效的。一旦AOR在域内判定为失效那么它所关联的所有GRUU必须同时视为失效。本规范没有强制指定生成GURR的机制。附录A给出了一个运行良好的算法可以用它生成GRUU。然而除了3.1所描述的属性之外注册服务器所构建的GRUU还必须拥有以下属性o URI的domain部分是公网的IP地址如果给的是主机名按RFC3263的解析流程处理可以得到对应的公网地址。o 如果请求是发给GRUU的把它路由给可以访问注册数据的代理。这样的代理称为权威代理其定义在RFC5626[14]。5.5. Registration 事件支持RFC 3680 [24]定义了一种event让client端可以了解注册服务器发生的事件。它还允许注册服务器强制修改注册内容比如说缩短周期强制刷新。如果注册服务器支持RFC3860 [24]和GRUU那么它必须同时支持RFC5628 [28]。6. Proxy 行为RFC3261 16章完整定义了代理的行为规范。GRUU的处理对它有两处影响请求权威代理定位目标和record-routing。6.1. 请求的目标代理收到请求时说明它是Request-URI所指定的域的属主并假定它可以访问定位服务器以确定请求的目标RFC3261 16.5一节的定义代理需要检查Request-URI。如果它包含gr参数那么按URI比较规则与现有域内有效GRUU进行比较如果找不到等价的记录它应当返回404 (Not Found)应答。这一行为与代理处理无效URI的定义是一致的。如果Request-URI包含gr参数按URI比较规则与现有域内有效GRUU进行比较找到匹配记录那么 处理流程和其它URI的定位服务一样基于RFC3261 16.5的定义不同之处是gr参数不像标准规范定义那样删除。对于dialog外请求和dialog内请求的处理是一样的dialog内请求可能带有Route头域携带代理record-routing填充的内容。注意保留gr参数的目的只是为了方便定位服务器查找GRUU。如果找到匹配Request-URI将用注册的contact重写替换GRUU及gr参数。gr参数不会被带入重写的 Request-URI中。如果没有注册的contact与GRUU绑定那么服务端必须返回480 (Temporarily Unavailable)应答。如果找到不止一个contact那么有两种场景1. Client端使用RFC5626[14]注册了多个contact冗余备份。这时这些contact包含reg-id Contact头域参数那么就按RFC5626 第7章定义的规则选择contact。2. Client端没有使用RFC5626[14]那么这时只有在client出现崩溃重启并以相同ID重新注册的场景下会出现一个实例ID对应多个contact。这种情况下这些contact没有reg-id特征参数。这时代理必须选择最近刷新的contact。与RFC5626定义一样如果请求指向这个目标因 408 (Request Timeout) 或430 (Flow Failed)处理失败代理应当SHOULD 继续尝试下一个contact按最近刷新时间排序。此外如果请求收到其它失败应答那么不允许代理重试这个实例的其它contact。请求中的任何主叫方首选项如RFC3841定义都应当紧着GRUU绑定的contact处理。从本质上讲选择已注册的contact时GRUU的处理和AOR一样差别是只选择AOR所绑定的contact的子集。需要特殊考虑注册中有Path 头域的处理RFC3327 [3]。如果接收到的请求有Route头域其值超出权威代理自身的范围这在dialog 请求可能会出现这时必须丢弃 Path URI。这是RFC3327 [3]允许的本地处理策略。GRUU的用法要求使用这类策略以避免出现螺旋呼叫导致失败。代理可以对请求执行其它处理比如执行被叫方业务就像它处理AOR的请求目标那样。对于dialog外请求建议采用筛选类型的功能包括自动比如黑白名名单和交互式比如通过IVR与用户协商是否接听电话。在很多场景中新的请求与现有dialog有关它们可能是要尝试加入使用RFC3911定义的Join 头域或者可能是要替代使用RFC3981定义的Replaces 头域。当新请求与现有dialog相关时UA通常会有自己的授权决定绕过权威代理上的筛选服务可能是有意义的。但是网络设计人员需要仔细斟酌因为这样的能力取决于筛选服务的特定类型。但是前转服务比如说呼叫前转对于发给GRUU的请求不应提供服务。GRUU的目的是把呼叫目标限定为指定的UA实例这与前转操作是不兼容的。如果请求是dialog内的。通常来说代理应当只处理对dialog内请求有意义的服务。这也就排除筛选服务和前转服务了。此外指向GRUU的请求不应被重定向。在很多实例中UA使用GRUU的目的是解决NAT和防火墙穿透但是重定向经常会阻止为类情况的工作。6.2. Record-Routing对于record-routing有两个截然不同的需求在源端域和宿端域的需求。这些需求避免了不必要的、可能有问题的、螺旋式的请求。如果:o 源端权威代理收到一个创建dialog的请求o 并且Contact 头域包含代理的域的GRUUo 并且这个GRUU是代理域内的有效GRUU,o 并且这个GRUU与请求AOR关联这个AOR已经通过身份认证假设已经执行完认证机制o 并且请求中带有 Record-Route头域,那么权威代理必须做record-route。如果所有条件都满足除了与 GRUU 关联的 AOR 与请求者的身份验证不匹配之外建议代理使用 403Forbidden响应拒绝请求。如果:o 宿端权威代理收到一个创建dialog的请求o 并且Request-URI包含定位服务器的资源记录可以是GRUU或AORo 并且选中的contact有一个实例ID绑定到GRUUo 并且注册时带有 Path URI,那么宿端权威代理必须做record-route。如果代理是在源端或宿端域内但不是权威代理那么这个代理可以选择record-route。如果宿端域内的代理基于某种原因防火墙穿透、计费要求dialog内请求经过它处理那么它必须做record-route此外绝对不允许假定UA会用到应答消息里的Contact头域的GRUU这将会导致dialog请求绕过没做record-routing的代理。实现者应当注意如果UA在它的contact里使用GRUU并且代理在注册时把自己放入Path头域里那么无论呼叫过程中有没有record-route这个代理都会收到dialog内请求。唯一区别是代理在dialog内请求中的topmost Route里看到的URI是什么。如果代理用record-route看到的就是它否则看到的是Path URI。7. 语法本规范定义了两个新的Contact 头域参数temp-gruu 和pub-gruu它扩展了RFC3261对contact-params的定义。此外还定义了一个新的SIP URI参数gr它扩展了RFC3261对uri-parameter的定义。具体ABNF定义如下contact-params / temp-gruu / pub-gruutemp-gruu temp-gruu EQUAL quoted-stringpub-gruu pub-gruu EQUAL quoted-stringuri-parameter / gr-paramgr-param gr [ pvalue] ; defined in RFC 3261描述temp-gruu 和pub-gruu的quoted-string必须是一个SIP URI。但它们的编码与所有其他带引号的字符串一样因此如果内容包含引号需要转义。8. 需求本规范的建立是为了满足以下需求的REQ 1: 当UA引用GRUU时必须把请求路由给GRUU关联的特定UA实例。REQ 2: 必须保证GRUU可以在Internet的任何地方上引用并且保证请求可以被正确地路由。也就是说不能限定GRUU的使用域。REQ 3: 必须保证不需要在网络中存储附加状态就能构建GRUU的可行性。REQ 4: 必须保证UA能获取UA实例上每条路由的多条GRUU。例如如果UA实例主持多个会议时每个会议都需要一个标识的URI这就需要多个GRUU。注意本规范并未满足这个需求它将在另一份规范中独立处理目前可以参考Delivery of Request-URI Targets to User Agents [29]。REQ 5: UA收到指向GRUU的请求时必须能够知道GRUU调用的资源是什么作为REQ 4的结果这个要求是必然的。注意本规范并未满足这个需求它将在另一份规范中独立处理目前可以参考Delivery of Request-URI Targets to User Agents [29]。REQ 6: 必须保证UA向GRUU增加不透明内容的可能性。这些内容不由网络中的其他实体解释或修改只由GRUU指向的UA实例使用。这提供了类似cookie的功能允许UA在GRUU里嵌入状态信息。注意本规范并未满足这个需求它将在另一份规范中独立处理目前可以参考Delivery of Request-URI Targets to User Agents [29]。REQ 7: 必须保证代理通过GRUU执行服务与特性的能力。比如说如果用户有呼叫阻止的功能那么无论是用AOR还是用GRUU代理都能正确地执行。REQ 8: 必须保证dialog内的UA有能力通知对端它的GRUU并且让对端知道这个URI表示的是一个GRUU。这对于会议和dialog复用的应用来说是必要的因为这类应用中会在dialog传输URI。REQ 9: 基于之前 REQ 8需求传送GRUU时必须保证接收方UA有能力识别完整性和真实性。REQ 10: 对于一个域来说具有权威性的服务器必须能够构造GRUU该GRUU可以路由到绑定到该域中AOR的UA实例。换句话说代理也可以构造GRUU。这是在线状态应用所需要的。9. 流程实例图2中所描绘的流程包含了基本的注册与呼叫建立的流程演示了GRUU的使用方法。还有一个订阅GRUU的过程。接着是一个被叫方失败和重注册。使用RFC4475的约定来描述长消息行。被叫方支持GRUU扩展因此它的注册消息REGISTER (1)是这样的REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.1;branchz9hG4bKnashds7 Max-Forwards: 70 From: Callee sip:calleeexample.com;taga73kszlfl Supported: gruu To: Callee sip:calleeexample.com Call-ID: 1j9FpLxk3uxtm8tn192.0.2.1 CSeq: 1 REGISTER Contact: sip:callee192.0.2.1;sip.instanceurn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 Content-Length: 0注册服务器分配一个临时的和一个公共的GRUUREGISTER的应答消息 (message 2)是这样的SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.2.1;branchz9hG4bKnashds7 From: Callee sip:calleeexample.com;taga73kszlfl To: Callee sip:calleeexample.com ;tagb88sn Call-ID: 1j9FpLxk3uxtm8tn192.0.2.1 CSeq: 1 REGISTER allOneLine Contact: sip:callee192.0.2.1;pub-gruusip:calleeexample.com;grurn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;temp-gruusip:tgruu.7hsjd7vnzga5w7fajsc7-ajd6fabz0f8g5example.com;gr;sip.instanceurn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;expires3600 /allOneLine Content-Length: 0REGISTER的应答消息的Contact头域里带有pub-gruu参数其值是公共GRUUip:calleeexample.com;grurn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6。还有一个 temp-gruu参数其值为临时GRUU sip:tgruu.7hsjd7vnzga5w7fajsc7-ajd6fabz0f8g5example.com;gr。这两个GRUU对AOR和实例ID都是有效的最终都解析为contact sip:callee192.0.2.1。主叫发出的INVITE消息(message 3)是一个正常的SIP INVITE。但是被叫生成的200 OK里携带了自己的GRUU作为 remote target。这时UA选择的是公共GRUU。SIP/2.0 200 OK Via: SIP/2.0/UDP proxy.example.com;branchz9hG4bKnaa8 Via: SIP/2.0/UDP host.example.com;branchz9hG4bK99a From: Caller sip:callerexample.com;tagn88ah To: Callee sip:calleeexample.com ;taga0z8 Call-ID: 1j9FpLxk3uxtma7host.example.com CSeq: 1 INVITE Supported: gruu Allow: INVITE, OPTIONS, CANCEL, BYE, ACK, SUBSCRIBE allOneLine Contact: sip:calleeexample.com;grurn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 /allOneLine Content-Length: -- Content-Type: application/sdp [SDP Not shown]过段时间主叫方决定订阅这个特定UA的 dialog事件(16]中定义)。因此它生成一条SUBSCRIBE 请求(message 9)指向之前记录下来的remote target即GRUU。allOneLine SUBSCRIBE sip:calleeexample.com;grurn:uuid:f8 1d4fae-7dec-11d0-a765-00a0c91e6bf6 SIP/2.0 /allOneLine Via: SIP/2.0/UDP host.example.com;branchz9hG4bK9zz8 From: Caller sip:callerexample.com;tagkkaz- allOneLine To: sip:calleeexample.com;grurn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 /allOneLine Call-ID: faif9ahost.example.com CSeq: 2 SUBSCRIBE Supported: gruu Event: dialog Allow: INVITE, OPTIONS, CANCEL, BYE, ACK, NOTIFY Contact: sip:callerexample.com;grhdg7777ad7aflzig8sf7 Content-Length: 0在本例中主叫自身支持GRUU因此它用自己的GRUU来填充remote target。订阅请求路由到代理它基于 Request-URI执行定位服务。最终转换为实例指向的contact并把消息转发出去。SUBSCRIBE sip:callee192.0.2.1 SIP/2.0 Via: SIP/2.0/UDP proxy.example.com;branchz9hG4bK9555 Via: SIP/2.0/UDP host.example.com;branchz9hG4bK9zz8 From: Caller sip:callerexample.com;tagkkaz- allOneLine To: sip:calleeexample.com;grurn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 /allOneLine Call-ID: faif9ahost.example.com CSeq: 2 SUBSCRIBE Supported: gruu Event: dialog Allow: INVITE, OPTIONS, CANCEL, BYE, ACK, NOTIFY Contact: sip:callerexample.com;grhdg7777ad7aflzig8sf7 Content-Length: 0SUBSCRIBE 请求生成一条200应答(message 11)其后跟着NOTIFY(message 13 and 14)和对应的应答(message 15和 16)。接收message 16一段时间之后被叫方的机器崩溃并重启了它获取到一个新的IP192.0.2.2。它不知道之前的注册所以重新注册(message 17 以后)。但是注册时保持之前的实例ID因为它有持久化处理。REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.2;branchz9hG4bKnasbba Max-Forwards: 70 From: Callee sip:calleeexample.com;tagha8d777f0 Supported: gruu To: Callee sip:calleeexample.com Call-ID: hf8asxzff8s7f192.0.2.2 CSeq: 1 REGISTER allOneLine Contact: sip:callee192.0.2.2;sip.instanceurn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 /allOneLine Content-Length: 0Both contacts are注册服务器注意到同一实例ID已经关联了另一个contactsip:callee192.0.2.1。它注册新的记录并在REGISTER应答中一同返回新老记录。两个记录的公共GRUU是一样的但重新生成临时GRUU。两条contact内容都在REGISTER应答中但是临时GRUU的值是一样的用最近生成的值填充。注册服务器最终发出的应答消息SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.2.2;branchz9hG4bKnasbba From: Callee sip:calleeexample.com;tagha8d777f0 To: Callee sip:calleeexample.com;tag99f8f7 Call-ID: hf8asxzff8s7f192.0.2.2 CSeq: 1 REGISTER allOneLine Contact: sip:callee192.0.2.2;pub-gruusip:calleeexample.com;grurn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 ;temp-gruusip:tgruu.7hatz6cn-098shfyq193 ajfux8fyg7ajqqe7example.com;gr;sip.instanceurn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;expires3600 /allOneLine allOneLine Contact: sip:callee192.0.2.1;pub-gruusip:calleeexample.com;grurn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;temp-gruusip:tgruu.7hatz6cn-98shfyq193ajfux8fyg7ajqqe7example.com;gr;sip.instanceurn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;expires400 /allOneLine Content-Length: 0UA不需要刻意去删除残余的contact。请求目标定位时按6.1一节的描述会自动递交给最近刷新的地址。10. 安全考虑SIP网络中使用GRUU时攻击可以分为外部第三方攻击系统和内部攻击者是内部的恶意元素。此外使用GRUU时还需要考虑隐私保护。10.1. 外部攻击对于 UA 来说确保 REGISTER 响应中给出的 GRUU 的完整性很重要。 如果 GRUU 被攻击者篡改结果可能导致对 UA 的拒绝服务 (DoS)攻击。 因此建议 UA 在注册时在 Request-URI 中使用 SIPS URI 方案。 代理和注册服务器必须支持 SIPS URI 并且必须支持 TLS。 这并没有变更RFC 3261 [1] 中的要求。。附录A.1所给的构建GRUU算法并没有尝试隐藏GRUU所关联的AOR和实例ID。通常AOR与GRUU明确关联是和个很好的属性因为它可以轻松跟踪特定的呼叫目标。了解实例ID对攻击者来说几乎没什么好处。注册攻击需要截获用户的鉴权凭据只知道实例ID是不够的。附录A.1所给的构建GRUU算法并没有尝试防止用户根据AOR和实例ID知识猜测GRUU。能够执行这个操作的用户同样能够在别的实例上直接发起新的请求。但是本规范建议对发给GRUU的请求要进行特别的处理比如说筛选。这种处理能确定GRUU不会为攻击者留下后门阻止外部攻击用户的试图。10.2. 内部攻击使用本规范的结果UA将从dialog的创建和刷新过程中开始使用GRUU。这些GRUU又会传递给其它UA称为通讯员然后其它UA会在请求中直接使用。如果某个恶意通信都删除 gr URI参数那么请求将会被路由给权威代理。如果是临时GRUU删除gr URI参数会导致GRUU不与任何AOR匹配请求被拒绝。如果是公共GRUU删除gr URI参数会被处理为AOR因此和直接呼叫AOR是一样的。由于协议允许从GRUU里提取AOR所以这不算攻击呼叫会被正常处理。系统中的恶意用户可能会尝试使用 GRUU 对另一个 SIP UA 发起 DoS 攻击。为此它将等待来自该 UA 的呼叫并从中观察他们的 GRUU。一旦获得 GRUUUA 将向实体例如在线服务器发起 SIP 请求该实体将生成许多返回给 UA 的请求。但是攻击者将在该 SUBSCRIBE 请求的 Contact 头域中使用攻击目标的 GRUU。这将导致流量被定向到目标。由于 GRUU 是全局可路由的与发送到其IP 地址的流量相比这类流量更有可能被发给攻击目标。本规范要求代理验证请求的Contact 中的 GRUU 与请求发送者的身份匹配来帮助减轻这种攻击。这类检查需要使用outbound proxy。 SIP 不强制使用outbound proxy这确实会留下潜在的漏洞。然而在实践中几乎所有 SIP 部署都使用outbound proxy因此这种漏洞不太可能成为问题。10.3. 隐私考虑RFC 3323 [15]定义了隐私机制。它区分了网络提供的隐私和用户提供的隐私。在前者中用户在请求中包含Privacy 头域以从网络请求隐私服务。在后者中UA遵循一套基本的准则来构造其请求因此提供了一定程度的隐私。RFC 3323[15]的4.1节中为用户提供的隐私请求定义了指导方针UA使用一个省略user 部分的URI构造其Contact头域并利用UA的IP地址或主机名。这样的建议与本规范中定义的规则相冲突本规范要求在Contact头域中使用GRUU。但是注册服务器提供的临时GRUU可以用来代替RFC 3323[15]中描述的Contact URI格式。UA从每个REGISTER响应中收集临时GRUU并缓存其中的一小部分。当它发出或接收一个呼叫时可以使用一个临时GRUU来填充Contact头域。UA可以选择在所有呼叫中使用同一个临时GRUU也可以选择每个通呼叫换一个临时GRUU。选择取决于隐私考虑的程度。o 如果UA在所有的呼叫中使用同一GRUU那么将允许通讯员基于Contact头域组织调查将来自同一UA的呼叫关联起来。RFC 3323[15]提供的的隐私过程也是如此因为Contact URI中的IP或主机名提供了一种类似的关联性。o UA.如果UA的每通电话使用不同的GRUU那么通讯员将不能基于Contact头域组织调查因为其内容不能提供关联性。o 在上述两种场景中如果没有提供网络级的隐私保护那么SDP协议里的IP地址和端口可以为通讯员提供呼叫来自同一UA的线索。o 在两种场景中如果用户发起呼叫通讯员都能够通过Contact 头域里的GRUU发起回呼。类似呼叫转移和通过网络应用服务收集数据RFC4730的特性实现是有可能的它们依赖于Contact里的GRUU。在注册失效之前这些入局请求都是可行的。UA如果希望限制之前生成的临时GRUU的可见性可以改变Call-ID刷新注册。UA不应用先注销再注册的方式来使之前的临时GRUU失效因为这会导致短时间内的完全不可达也会增加网络负载。用新的Call-ID刷新会更高效它是控制临时GRUU有效性的一种粗粒度的控制。UA不希望被特定的回呼打扰需要实现手动或自动的呼叫控制流程来拒绝它。本规范没有为UA提供让单个临时GRUU失效的能力。如果UA坚持不接收任何这类入局请求包括诸如数字收集服务生成的请求那么UA可以选择在Contact头域中使用非GRUU。但这是不推荐的。使用带有自动呼叫拒绝的GRUU会优越得多。o 只要使用临GRUU填充Contact头域通讯员将无法通过检查Contact头域确定AOR或UA实例ID的任何信息。但是在没有网络提供隐私服务的情况下可以通过SDP中的IP地址来确定UA的信息如其地理位置和ISP等。o 在所有场景中无论UA在Contact 中使用的是临时GRUU还是公共GRUU无论它使用GRUU与否无论它是否使用网络提供的隐私服务通讯员都能够确定UA的SIP服务商。11. IANA 考虑事项本规范定义了两个新的Contact头域参数和一个SIP URI参数还有一个SIP选项标签。11.1. 头域参数本规范根据RFC3968[8]的定义注册了两个新的头域参数。它们的需求信息描述如下参数可以出现的头域: Contact参数名: pub-gruu预定义值: 无参考RFC: RFC 5627参数可以出现的头域: Contact参数名: temp-gruu预定义值: 无参考RFC: RFC 562711.2. URI 参数本规范根据RFC 3969 [9]定义注册了一个新的SIP URI参数具体信息如下参数名: gr预定义值: 无参考RFC: RFC 562711.3. SIP 选项标签本规范根据RFC3261 27.1的准则定义注册了一个新的SIP选项标签其信息如下名称: gruu描述: 这个标签用于标识全局可路由的 UA URIGRUU扩展。当它出现在Supported头域中时说明UA理解本扩展。当它出现在REGISTER请求的Require头域中时要求注册服务器只有在理解本扩展的前提下才能处理注册请求。