rfc3455.txt

RFC3455中文版

Network Working Group                                   M. Garcia-Martin
Request for Comments: 3455                                      Ericsson
Category: Informational                                     E. Henrikson
                                                                  Lucent
                                                                D. Mills
                                                                Vodafone
                                                            January 2003


     3GPP 对 SIP 的私有头(P-Header)扩展 

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This document describes a set of private Session Initiation Protocol
   (SIP) headers (P-headers) used by the 3rd-Generation Partnership
   Project (3GPP), along with their applicability, which is limited to
   particular environments.  The P-headers are for a variety of purposes
   within the networks that the partners use, including charging and
   information about the networks a call traverses.

目录

   1. 应用范围   . . . . . . . . . . . . . .. . . . . . . . . . . .  3
   2. 约定    . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3. 概述     . . . .  . . . . . . . . . . . . . . . . . . . . . .  3
   4. SIP 私有头 . . . . . . . . . . .  . . . . . . . . . . . . . .  3
     4.1 P-Associated-URI 头. . . . . . . . . . . . . . . . . . . .  3
         4.1.1 P-Associated-URI 头的适用声明. . . . . . . . . . . .  4
         4.1.2 P-Associated-URI 头的用法 . . . . . . . . . . .  . .  4
     4.2 P-Called-Party-ID 头  . . . . . . . . . . . . . . .  . . .  6
         4.2.1 P-Called-Party-ID 头的适用声明 . . . . . . . . . . .  9
         4.2.2 P-Called-Party-ID 头的用法. . . . . . . . . .  . . . 10
     4.3 P-Visited-Network-ID 头. . . . . . . . . . . . . . . . . . 11
         4.3.1 P-Visited-Network-ID 头的适用声明. . . . . . . . . . 11



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


         4.3.2 P-Visited-Network-ID 头的用法 . . . . . . . . . .. . 12
     4.4 P-Access-Network-Info 头 . . . . . . . . . . . . . . . . . 15
         4.4.1 P-Access-Network-Info  头的适用声明. . . . . . . . . 16
         4.4.2 P-Access-Network-Info 头的用法 . . . . .  .  . . . . 17
     4.5 P-Charging-Function-Addresses 头 . . . . . . . . . . . . . 18
         4.5.1 P-Charging-Function-Addresses 头的适用声明 . . . . . 18
         4.5.2 P-Charging-Function-Addresses 头的用法 . . . . . . . 19
     4.6 P-Charging-Vector 头 . . . . . . . . . . . . . . . . . . . 21
         4.6.1 P-Charging-Vector 头的适用声明 . . . . . . . . . . . 22
         4.6.2 P-Charging-Vector 头的用法.  . . . . . . . . . . . . 23
   5. 形式语法. . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     5.1 P-Associated-URI 头的语法. . . . . . . . . . . . . . . . . 25
     5.2 P-Called-Party-ID 头的语法 . . . . . . . . . . . . .. . .  25
     5.3 P-Visited-Network-ID 头的语法. . . . . . . . . . . . . . . 25
     5.4 P-Access-Network-Info 头的语法 . . . . . . . . . . . . . . 25
     5.5 P-Charging-Function-Addresses 头的语法 . . . . . . . . . . 26
     5.6 P-Charging-Vector 头的语法 . . . . . . . . . . . . . . . . 26
     5.7 新头列表 . . . . . . . . . . . . . . . . . . . . . . . . . 27
   6. 安全考虑. . . . . . . . . . . . . . . . . . . . . . . . . . . 28
     6.1 P-Associated-URI . . . . . . . . . . . . . . . . . . . . . 28
     6.2 P-Called-Party-ID. . . . . . . . . . . . . . . . . . . . . 28
     6.3 P-Visited-Network-ID . . . . . . . . . . . . . . . . . . . 28
     6.4 P-Access-Network-Info. . . . . . . . . . . . . . . . . . . 29
     6.5 P-Charging-Function-Addresses. . . . . . . . . . . . . . . 30
     6.6 P-Charging-Vector. . . . . . . . . . . . . . . . . . . . . 30
   7.  IANA 考虑. . . . . . . . . . . . . . . . . . . . . . . . . . 30
   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
   9.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 32
   10. Normative References . . . . . . . . . . . . . . . . . . . . 32
   11. Informative References . . . . . . . . . . . . . . . . . . . 32
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 34















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


1. 应用范围

   文中描述的SIP扩展对网络拓朴,SIP与底层的连接,以及信任的有效性作出了一定的假定.
   这些假定在Internet环境下一般不会全部适用. 这里所描述的机制是为了满足3GPP R5对SIP
   的需求而设计的, 它因为没有足够的运营经验或是不够成熟而没有考虑通用解决方案.
   参考每一项扩展的适用性可以了解更多关于扩展假定的描述
   

2. 约定

   文中关键字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 和 "OPTIONAL" 的描述
   参见 BCP 14, RFC 2119 [2].

3. 概述

   3GPP 已经选择SIP作为其在IMS环境中建立和解除会话的协议.  (关于IMS 的更多
   描述可参见 3GPP TS 23.228 [14] 和 3GPP TS 24.229 [15]).  3GPP 告知 IETF SIP
   和 SIPPING 工作组除了一些额外的功能外现有的SIP协议几乎提供了IMS所需要的全部功能.  
   这些需求[4]被制定为互联网草案提交给SIPPING Working 工作组. 其中的一些需求已通过
   协议扩展被满足,另外一些则因为不够通用而未被SIP工作组采纳.本文档描述了针对这些
   需求的私有扩展. 每一项扩展,以及与之相关的扩展在其相关章节进行描述.

4. SIP 私有头

4.1 P-Associated-URI 头

   这项扩展充许一次注册返回一组与已注册的AOR相关联的URI. 我们定义
   P-Associated-URI头字段并在REGISTER请求的200 OK 响应中使用该字段.
   P-Associated-URI关字段传送了一组与已注册的AOR相关联的URIs.



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


   服务供应商已经分配给一个用户专用的URI称为已关联的URI. registrar允许包含
   一个AOR关联0个或更多的URI的相关信息. 通常, 所有的这些URIs (AOR URI
   和 关联URIS) 已为特定用户指定好用途. 这项针对SIP的扩展允许UAC在一次
   成功的授权注册后知道还有哪些服务供应商提供的URIs关联至AOR上.

   请注意, 一般来说, registrar不会为用户注册关联URIs. 只有出现在REGISTER方法
   中的To头段的AOR才能被注册和绑定到联系地址(contact address). 这里传达的唯一信息
   是registrar知道其他的URIs将被同一用户使用.

   一个应用服务器(甚至是registrar自身)有可能通过第三方注册为用户注册了
   一个关联URIs. 本文不讨论第三方注册. 一个UAC不能假定关联URIs已经注册.
   
   如果一个UAC想检测某个关联URIs是否被注册, 它可以通过文档外描述的一种机制进行,
   例如, UA可以发送一个REGISTER请求并在To字段中填写期望的关联URI并不带Contact字段.
   200 OK 响应将包含一个带有已注册的联系地址列表的Contact头. 如果关联URI没
   有注册, UA可以在使用之前注册.

4.1.1 P-Associated-URI 头的适用声明

   P-Associated-URI 头适用于SIP供应商为用户提供一组在其UA产生请求可声明的
   标识符(在From头字段中)的SIP网络中. 更进一步, 它假定供应商知道用户可以
   合理声明整个标识集以及用户期望限制某些标识. 相对于这一点, 正常的SIP用法
   中From字段只是最终用户标明的字段.

4.1.2 P-Associated-URI 头的用法

   registrar将P-Associated-URI头字段插入至REGISTER请求的200 OK 响应中.
   头字段的值用0个或更多的与AOR关联的URIs组成的列表填写.




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


   如果registrar支持P-Associated-URI头扩展, registrar必须总是将P-Associated-URI 插入到
   REGISTER请求的200 OK的响应中去,而不管REGESTER是初始注册,重注册,或是注销以及
   是否有0个或是更多的URIs.

4.1.2.1 UA 的处理流程

   一个UAC可能在REGISTER的200 OK响应中收到P-Associated-URI 头字段. 该字段
   的出现意味着registrar支持该项扩展.

   头字段的值包含AOR的0个或多个关联URIs. UAC可以接下来的请求中可以使用任意
   一个来填写From头字段或为标识calling party提供信息的其他SIP头字段.
   
   UAC 可检测关联URIs是否注册. 示例如下, 将该URI填写到REGISTER消息中的To字段
   但不附加Contact字段. 200 OK响应中的Contact字段将包含已注册的联系地址列表.
   如同SIP[1]中描述的, 200 OK 响应中的Contact头字段可以包含0或多个值(0 意味着
   当前AOR未注册).
   
4.1.2.2 registrar 的处理流程

   一个接受并认证REGISTER请求的registrar 可以将AOR与0个或多个URI关联.

   支持该项扩展的registrar必须在REGISTER请求的200 OK 响应中包含P-Associated-URI
   头字段.  并且必须填写与当前注册AOR相关联的SIP 或 SIPS URIs的逗号分隔列表.
   
   如果当前注册的AOR没有相关联的SIP 或 SIPS URIs, registrar 必须包含一个空的
    P-Associated-URI 字段值.

4.1.2.3 proxy 的处理流程

   备忘录里没有定义关于 proxy 的处理流程.





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


4.2 P-Called-Party-ID 头

   proxy 服务器典型地在路由INVITE请求到它的目标时插入P-Called-Party-ID 头.
   该头用porxy收到请求的Request-URI 填写. UAS 从几个已注册的AORs中
   标识出是会话邀请是发送给哪个AOR.(例如, 用户可以同时使用个人
   或业务SIP URI来接受会话邀请).  UAS可以使用该信息根据接受会话的URI
   应用不同的有个性的音频提示音.
   
   3GPP IMS 的用户可以获得一个或多个标识用户的SIP URIs(AOR).  例如,
   一个用户可以获得一个业务SIP URI和一个个人SIP URI.  一个应用的案例是,
   用户可以让业务SIP URI只对工作伙伴有效而个人SIP URI只对家庭成员有效.

   在某一特定的时间点上, 业务SIP URI和个人SIP URI 都已注册到SIP registrar, 
   因此两个URI都能接受新的会话邀请.  当该用户收到一个加入会话的邀请, 
   他/她应该知道会话是发给已注册的几个SIP URI中的哪一个.

   这项需求在 3GPP R5 中关于 SIP[4]的需求中提及.

   当为UA服务的SIP proxy 获得INVITE, 然后对请求Request-URI字段进行目标重定位, 
   并且替换为用户在注册时REGISTER请求中Contact 头字段的所公布的SIP URI时, 
   这个问题就会在会话建立中的会话终结端产生.  
   当UAS 收到SIP INVITE, 它不能判断请求发给哪个AOR.

   某些人可能觉得To头字段指明了语义上被叫用户,所以无需对SIP进行该扩展.
   虽然SIP的To头字段在大多数情况下意味着called party ID, 但在以下两个
   特殊情况下并不正确:

   1. 会话在到达为用户服务的代理服务器之前被前面的SIP代理前转(forwarded), 
   重定向(redirected), 等.

   2. UAC 构造了一个 To 头字段与Request-URI不相同INVITE 请求.



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


   To头字段的使用问题是它只能被UAC填写而不能路径上的代理修改.
   如果因为某种原因UAC没有用目标用户的AOR填写To头字段, 目标用户将不能区分
   会话期望的AOR.

   这个问题另一个可能的解决方案建立在注册时不同的AOR使用不用的Contact头字段值.
   UA能够能过分配不同的Contact头字段值来区分不同的AOR. 例如, 当UA注册AOR sip:id1,
   Contact头字段可以为sip:id1@ua; 而sip:id2 的注册可以绑定到Contact字段sip:id2@ua.

   上面描述的方案假定UA显式注册它的每一个AOR, 因此必须完全控制分配给每次注册的联系地址.
   然而, 在UA不能完全控制它注册的AOR的情况下, 比如第三方注册, 这个方案
   就行不通. 3GPP 可能这样一种注册情形: UA可以在SIP之外预先指示网络当UA注册特定的AOR时,
    一些其他的AOR URIs 可以被自动注册.  该需求被 3GPP R5 需求SIP [4]涵盖.

   在下一段我们给出关于这个问题的一个例子, 它的情况是会话中已经存在有序的呼叫前转,
   因而UAC并不清楚当前INVITE的真实目标URI.

   我们假定用户代理 (UA) 注册到代理服务器 (P1).

         场景                      UA --- P1

      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>

   用户也注册其个人 URI 到 他/她的registrar.





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