rfc3455.txt

RFC3455中文版

      F2 Register UA -> P1
           REGISTER sip:example.com SIP/2.0
           Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashdt8
           To: sip:[e-mail]
           From: sip:[e-mail];tag=346249
           Call-ID: 2Q3817637684230998sdasdh10
           CSeq: 1827 REGISTER
           Contact: <sip:user1@192.0.2.4>

   然后, 代理/registrar (P1) 从另外一个代理服务器(P2)收到一个目标为
   该用户业务SIP AOR的INVITE请求.  我们假定该SIP INVITE之前经历了一系列的前转,
   因此它的To字段值填写并不是用户的AOR. 在这种情况下我们假定会话最初是发给
   sip:[e-mail]的.  SIP 服务器othernetwork.com 将会话前转到
   sip:user1-业务@example.com

         场景                      UA --- P1 --- P2

      F3 Invite P2 -> P1
           INVITE sip:[e-mail] SIP/2.0
           Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
           To: sip:[e-mail]
           From: sip:[e-mail];tag=938s0
           Call-ID: 843817637684230998sdasdh09
           CSeq: 101 INVITE

   代理服务器 P1 定位目标用户并用其注册时的Contact字段值替换 Request-URI.

      F4 Invite P1 -> UA
           INVITE sip:user1@192.0.2.4 SIP/2.0
           Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bKg48sh128
           Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
           To: sip:[e-mail]
           From: sip:[e-mail];tag=938s0
           Call-ID: 843817637684230998sdasdh09
           CSeq: 101 INVITE

   当UAS收到 INVITE, 它不确判断是从业务URI还是从个人URI上收到会话邀请.
   无论UAS还有代理服务器以及应用服务器都不可能对提供会话目标AOR作出判断.





Garcia-Martin, et. al.       Informational                      [页 8]

RFC 3455              3GPP SIP P-Header 扩展          January 2003


   我们解决这个问题方案是: 允许用户的归属域代理服务器(SIP中定义)插入一个
   标识会话目标的AOR的P-Called-Party-ID头.
   
   如果使用了这项SIP扩展的话, 被叫用户代理服务器将在获得消息F5后将用F5中
   的Request-URI填写到F6中P-Called-Party-ID去.
   消息流F5和F6内容如下:

      F5 Invite P2 -> P1
           INVITE sip:[e-mail] SIP/2.0
           Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
           To: sip:[e-mail]
           From: sip:[e-mail];tag=938s0
           Call-ID: 843817637684230998sdasdh09
           CSeq: 101 INVITE

      F6 Invite P1 -> UA
           INVITE sip:user1@192.0.2.4 SIP/2.0
           Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bKg48sh128
           Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
           To: sip:[e-mail]
           From: sip:[e-mail];tag=938s0
           Call-ID: 843817637684230998sdasdh09
           P-Called-Party-ID: sip:[e-mail]
           CSeq: 101 INVITE

   当UA收到INVITE请求F6时,它能判断会话的目的AOR, 并能根据此AOR提供相应的服务.

4.2.1 P-Called-Party-ID 头的适用声明

   P-Called-Party-ID 适用于UAS需要知道在代理将目标改写为Contact地址之前
   请求中Request-URI的目的AOR的情况. UAS 可针对请求目标按兴趣设定不同的语音提醒
   或使用其他过滤服务. 当UAS注册了几个AOR,并且,除非使用这项扩展,否则UAS并不清楚
   他的代理服务器/registrar给出的INVITE请求的AOR. 此时,扩展将显得更有价值.

   更通用的解决方案需求已在[12]中被提交但未被SIP采纳, 方案也尚未开发.




Garcia-Martin, et. al.       Informational                      [页 9]

RFC 3455              3GPP SIP P-Header 扩展          January 2003


4.2.2 P-Called-Party-ID 头的用法

   P-Called-Party-ID 头字段将proxy目标重定位之前请求中Request-URI的AOR
   提供给代理服务器和UAS. 这些信息可以被到达UAS所经路径上的后续代理服务器使用.

   典型地, 一个SIP代理在目标重定位Request-URI 之前插入P-Called-Party-ID头.
   在Request-URI改写为Contact地址之前, 用Request-URI填写该字段.
   

4.2.2.1 UA 的处理流程

   UAC 不能在任何SIP请求或响应消息中插入P-Called-Party-ID 头字段.

   UAS 可能收到包含P-Called-Party-ID头字段的SIP 请求. 该头填写的是在被前
   转到UAS之前代理服务器收到请求消息的Request-URI.

   UAS可以使用P-Called-Party-ID根据called party URI提供服务, 例如,
   按日期和时间过滤呼叫, 定制展现服务, 定制提示音, 等等.

4.2.2.2 代理服务器的处理流程

   需要访问用户Contact信息的代理服务器可以
   向表1中列出的请求(Section 5.7)插入一个 P-Called-Party-ID 头字段. 代理服务器
   必须用其接收到的SIP请求消息中的Request-URI 填写该字段.

   为了防止called party ID的错误发送, 插入P-Called-Party-ID的代理服务器
   拥有用户信息显得很重要.例如,这些信息可通过注册过程得到.
 
   代理服务器或应用服务器接收到包含P-Called-Party-ID头的请求后可以使用并
   根据其内容提供服务.
   
   SIP proxy 不能在注册请求中插入 P-Called-Party-ID 头.





Garcia-Martin, et. al.       Informational                     [页 10]

RFC 3455              3GPP SIP P-Header 扩展          January 2003


4.3 P-Visited-Network-ID 头

   3GPP 网络由归属网, 拜访网 和 subscribers的集合组成.
   一个特定的归属网会和一个或多个拜访网存在漫游协议. 当移动终端漫游时
   这些将会起作用, 它可以使终端透明地使用拜访网提供的资源.

   归属网能够接受漫游至特定的拜访网UA的注册的前提之一就是归属网和拜访网
   存在漫游协议. 在这里归属网需要知道是哪个拜访网正在为漫游的UA提供服务. 

   3GPP UA总是注册到归属网络. REGISTER 请求被拜访网中的一个或多个代理服务器转
   发至归属网. 最简单的考虑,在拜访网包含一个归属网可以识别的标识符应该是比较明智的.
   这个标识符应该全局唯一, 格式采用引号括起的字符串或令牌. 归属网可以用该标识符
   检验拜访网的漫游协议是否存在, 并且通过拜访网授权注册.

4.3.1 P-Visited-Network-ID 头的适用声明

   P-Visited-Network-ID 在以下情形下适用:

   1. 通过归属网与拜访网已建立的关系UA与归属网之间的中间服务器必须互相信任,
   并且通常支持标准安全机制如,IPsec, AKA, 或 TLS 的使用.

   2. 终端使用一个或多个拜访网(用户与该网络没有直接的业务关系)提供的资源.

   3. 位于拜访网中的一个代理服务器希望在用户的归属网中能够标识出自己.

   4. 不是每个拜访网都需要在归属网标识出自已. 希望标识的可以按本文描述
   使用扩展, 不需要标识的则什么都不用做.




Garcia-Martin, et. al.       Informational                     [页 11]

RFC 3455              3GPP SIP P-Header 扩展          January 2003


   5. 归属网与拜访网协商一致的文本串或令牌标识符.

   6. UAC 向拜访网中的代理服务器发送一个REGISTER 或对话发起请求 (如,
      INVITE) 或者一个单独的对话外请求 (如 OPTIONS).

   7. 请求在到达目标的途中, 第一个代理服务器在拜访网, 第二个代理服务器在
   归属网或者他的目标是归属网中的registrar.

   8. registrar或归属代理服务器校验并授权在拜访网中资源的使用(如, 代理服务器)
   
4.3.2 P-Visited-Network-ID 头的用法

   P-Visited-Network-ID 用来向registrar或归属代理服务器传达拜访网标识符.
   该标识符是一个归属网的registrar或归属代理服务器以及拜访网中的代理服务器
   都能识别的文本字符串或令牌.

   典型地, 归属网授权UA漫游特定的拜访网. 该操作需要归属网与拜访网存在漫游协议.

   虽然归属网能够通过检查Via头字段中域名标识拜访网, 但该方法过分信赖DNS. 
   例如代理服务器在via头字段中可选填写IP地址, 在缺少返向DNS入口的情况下, 
   IP地址将不能转换出期望的信息.

   任何一个收到表 1(Section 5.7)任何一个请求的SIP代理服务器当它前传请求时
   可以插入一个P-Visited-Network-ID 头. 在REGISTER 或其他请求
   穿过不同的管理区域 (如 不同的漫游网)的情况下, 如果请求中未包含
   P-Visited-Network-ID 头值自身标识符,(如,请求穿过不同的管理区域)
   则SIP proxy 可以插入一个新的 P-Visited-Network-ID 头.

   还要注意的是, 代理服务器没有必要解读该字段.  因此, 第一个proxy可以插入
   一个只有registrar能够解密的加密头. 如果请求穿过位于与第一个proxy相同管理区域的
   第二个proxy, 第二个proxy将不能解读



Garcia-Martin, et. al.       Informational                     [页 12]

RFC 3455              3GPP SIP P-Header 扩展          January 2003


  P-Visited-Network-ID 头的内容.  在这种情况下, 
  第二个proxy 将认为它的拜访网络标识符并没有已经出现头的值中, 因此, 它将
  插入一个新的P-Visited-Network-ID 头字段值(虽然也许没有加密的话, 
  插入了与第一个proxy相同的标识符). 当请求到达归属网的registrar 或 proxy 时,
  因为两个代理服务器属于相同的管理区域所以解密后的值是相同的, 
  它将注意到头字段值重复了(第一个和第二个proxy都插入了).
  虽然不期望这种情况发生, 但它也没有对归属网的registrar 或 proxy 造成破坏.
   P-Visited-Network-ID 正常情况下在注册时使用. 然而本扩展没有排除其他的用法.
  例如, 位于拜访网中的一个没有保存注册状态的proxy
  可以插入一个 P-Visited-Network-ID 头到任何一个单独的
  对话外请求或对话创建请求.  在撰写本文时, 创建对话的唯一需求是INVITE [1], 
  SUBSCRIBE [6] 和 REFER [11].

   为了避免标识符冲突, 特别是当网络间的漫游协议增加时,
   选择 P-Visited-Network-ID 值时必须小心. 该标识符应该全局唯一以避免出现重复.
   虽然存在很多创建跨网络全局唯一标识符机制, 有一种机制已经在运作, 这就是 DNS.
   P-Visited-Network-ID 与DNS之间没有任何连接, 但是头字段的值可以从自身DNS条目中选取
   用以代表网络域名.这将确保该值的唯一性.

4.3.2.1 UA 的处理流程

   UAC 不应该向SIP消息中插入 P-Visited-Network-ID 头.

4.3.2.2 registrar 和 proxy 的处理流程

   位于拜访网中 SIP proxy 可以向表 1 (Section 5.7)列出的任何请求插入一个
   P-Visited-Network-ID 头字段.  该头必须用填写为一个在用户归属网中标识
   该proxy网络管理区域的文本字符串或令牌.





Garcia-Martin, et. al.       Informational                     [页 13]

RFC 3455              3GPP SIP P-Header 扩展          January 2003


   位于归属网的SIP proxy 或 registrar 可以使用
   P-Visited-Network-ID 的内容作为请求穿越的一个或多个拜访网的标识符.  
   归属网的proxy 或 registrar 能否按本地策略进行动作取决于
   归属网与拜访网之间是否存在漫游协议. 这意味着, 例如, 
   请求的授权取决于P-Visited-Network-ID 头的内容.

   为了保护用户隐私, 位于归属网的proxy在将消息前转到归属网以外的
   管理区域时必须该头删去.

   当归属代理服务器已经使用了头的内容或是
   请求已按基于called party路由, 即使请求并没有前转出归属网管理区域.
   位于归属网SIP proxy也应该删除该头. 

4.3.2.3 用法示例

  我们示例的场景环境如下面的网络图:

            场景            UA --- P1 --- P2 --- REGISTRAR

   这个例子列出一个从UA1发起最后到达REGISTRAR的REGISTER 事务的消息序列.
   P1 是UA1的出口proxy.  在这个情况下 P1 同时插入了 P-Visited-Network-ID 头.
   P1 然后通过P2将REGISTER请求路由至Registrar.

  使用了 P-Visited-Network-ID 头的REGISTER消息序列:

      F1 Register UA -> P1
           REGISTER sip:example.com SIP/2.0
           Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
           To: sip:[e-mail]
           From: sip:[e-mail];tag=456248
           Call-ID: 843817637684230998sdasdh09
           CSeq: 1826 REGISTER
           Contact: <sip:user1@192.0.2.4>

   在流程F2中, proxy P1 (???)将它自己的标识符加入到P-Visited-Network-ID 头.







Garcia-Martin, et. al.       Informational                     [页 14]

RFC 3455              3GPP SIP P-Header 扩展          January 2003


      F2 Register P1 -> P2
           REGISTER sip:example.com SIP/2.0
           Via: SIP/2.0/UDP p1.visited.net;branch=z9hG4bK203igld
           Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashdt8
           To: sip:[e-mail]
           From: sip:[e-mail];tag=346249
           Call-ID: 2Q3817637684230998sdasdh10
           CSeq: 1826 REGISTER