rfc3455.txt

RFC3455中文版

           Contact: <sip:user1@192.0.2.4>
           P-Visited-Network-ID: "Visited network number 1"

   最后, 在流程F3中, proxy P2 是否插入它自己的标识符取决于它的域名.

      F3 Register P2 -> REGISTRAR
           REGISTER sip:example.com SIP/2.0
           Via: SIP/2.0/UDP p2.other.net;branch=z9hG4bK2bndnvk
           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
           Contact: <sip:user1@192.0.2.4>
           P-Visited-Network-ID: other.net, "Visited network number 1"

4.4 P-Access-Network-Info 头

   本节描述 P-Access-Network-Info 头. 该头在基于SIP的网络通过不同的接入技术
   与层2/层3互通时有用. SIP UA可以使用该头向提供服务的代理服务器传递有关接入技术的信息. 
   服务proxy 可以使用这些信息为UA优化服务. 例如, 一个 3GPP UA可以使用该头传递
   关于接入网的信息(如无线接入技术和无线小区标识等)给他的归属服务供应商.

   为了达到扩展的目的,我们将提供层2/层3 IP 连通性使得用户可以访问SIP功能
   以及提供的服务的网络定义为接入网络.
   
   在有些情况下, 给用户提供服务的SIP 服务器可能希望知道UA当前所使用的接入网类型信息.
   一些服务合适与否取决于接入类型, 





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


   如果为用户提供服务的SIP proxy知道接入网络的细节.一些服务将会对用户更有价值.

   在另外一些情况下, 向用户提供服务的SIP服务器为了向用户提供特定的服务
   可能只是简单地想知道用户的实际位置信息.  例如, 现在无线网络的许多有用的
   位置服务需要归属网知道用户正在使用的小区标识.

   一些规定的需求强制要求蜂窝无线系统在建立紧急呼叫时向紧急处理中心
   提供有效的小区标识.

   为用户提供服务的SIP服务器可能期望了解接入网. 这可以通过定义
   新的私有SIP 扩展头, P-Access-Network-Info.  该头在UAC及他的归属网
   服务proxy间携带关于接入网的信息.

4.4.1 P-Access-Network-Info 头的适用声明 

   该机制适合SIP 服务依赖 SIP 网元知道UA连接到SIP网络的IP及底层技术细节的环境.
   更具体地说, 该扩展需要UA知道自己使用的接入技术, 并且proxy需要通过该信息以
   提供服务. 通常SIP 是建立在 "Everything over IP and IP over everything" 基础之上,
   接入技术与SIP操作无关. 因为 SIP 系统通常不应该关注或者甚至是知道接入技术, 
   所以该 SIP扩展不作为SIP的一般用法.

   P-Access-Network-Info 头暴露的信息有可能很敏感.  
   这此信息的正确保护依赖于在观察含该头的SIP消息的代理服务器之间
   存在特定的业务和安全关系.它还依赖于UA明确地知道存在这样的关系. 
   因此,该机制只适合存在适当合理的关系且UA明确知道这一点的环境.








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


4.4.2 P-Access-Network-Info 头的用法

   当UA产生一个将被安全发送到给它的提供服务SIP proxy SIP请求或响应时, 
   UA 插入一个 P-Access-Network-Info 头到SIP消息中. 
   该头包含UA用以获得IP 连通性的接入网的信息.  
   该头典型地被UA及提供服务的SIP proxy之间的中间代理服务器忽略.
   提供服务的proxy 可以检查该头并且根据该头提供适当的服务. 
   在前转请求消息前, proxy 从消息中删除该头.

4.4.2.1 UA 行为

   支持该扩展并且期望暴露相关参数的UA可以在任何SIP请求或响应中插入
    P-Access-Network-Info头.

   插入该信息的UA 必须确信为它提供服务的proxy为了保护它的隐私,
   在将消息前转出proxy所在区域删除该头. 该proxy典型地位于归属网.

   为了执行删除头的动作, 必须同样信任UA及提供服务的SIP proxy之间的中间代理服务器.  
   该信任建立在归属网与接入网之间的业务协议之上 , 并且一般使用标准安全机制, 如.,
   IPsec, AKA, 和 TLS.

4.4.2.2 Proxy 行为

   proxy不能插入或修改P-Access-Network-Info 头的值.

   如果出现P-Access-Network-Info 头, 为UA提供服务的proxy的可以根据头上的信息,
   针对UA 访问服务器所使用的网络或位置提供不同的服务.  例如, 对于蜂窝无线接入网,
   位于归属网的SIP proxy 可以使用小区标识提供基本定位服务.

   为用户提供服务的proxy一般位于归属网同时也是可信的,
   当SIP信令前转至位于非信任网络管理区域的一个SIP server时必须删除该头.



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


  为UA提供服务的服务器使用接入网信息并且不关心位于其他不同的
  管理区域代理服务器.

4.5 P-Charging-Function-Addresses 头

   3GPP 定义了分布式架构导致多个网络实体被涉及提供接入和服务.
   这里就需要通知事务涉及到的每个相关公共计费功能实体的SIP proxy
   去接收产生的计费记录或计费事件.

   3GPP提供的方案定义了两类计费功能实体:计费采集(CCF)以及事件计费功能(ECF).
   CCF 用于离线计费(如后付费账务计费). ECF 用于在线计费(如预付费账务计费).
   为了实现冗余, 在网络上可能存在不止一个 CCF 和 ECF. 在存在多个CCF或ECF地址实例
   的情况下, 实现应该尝试向P-Charging-Function-Addresses 中地址序列的
   第一个ECF 或 CCF地址发送计费数据. CCF 和 ECF的地址可以在对话建立或单独事务中被传递.
   关于计费的更多信息参见 3GPP TS 32.200 [16] and 3GPP TS 32.225 [17].

   我们定义了 SIP 私有头 P-Charging-Function-Addresses. 如果没有出现该头的话
   proxy不论是在初始对话请求或响应, 还是在对话外单独事务的请求和应答都可以包含该头.
   在特定的请求或响应中只能出现一个头.

   SIP proxy 收集值并填写P-Charging-Function-Addresses 头的机制不在本文描述.
   然而, 作为一个例子, 一个SIP proxy 可以预先配好这些地址, 或者也可以从订阅数据库中获取.

4.5.1 P-Charging-Function-Addresses 头的适用声明

   P-Charging-Function-Addresses 头 适用于需要协作计费的单个私有管理区域,
    例如, 参照 3GPP TS 32.200 [16] 描述的架构.



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


   P-Charging-Function-Addresses 头不能包含在发送到外部管理区域SIP消息里.
   该头不适用于没有提供计费功能的管理区域.

   P-Charging-Function-Addresses 头的适用条件如下:

   1. UA 发送 REGISTER 或对话发起请求(如, INVITE)
      或一个单独的对话外事务请求到位于私有网络管理区域的proxy.

   2. 位于私有网络管理区域的一个registrar, proxy 或 UA 将产生计费记录.

   3. 位于私有网络一个registrar, proxy 或 UA在网络中有访问计费功能实体地址的权限.

   4. 位于私有网络相同的管理区域的其他代理服务器会产生计费记录或计费事件. 
   代理服务器想从SIP之外而不是第一个SIP proxy发送计费信息到相同的计费采集实体.

4.5.2 P-Charging-Function-Addresses 头的用法

   SIP proxy 在收到一个SIP请求,如果该头没有出现在请求之中则可以
   在将消息前转之前插入一个P-Charging-Function-Addresses 头.
   该头的值包含一个或多个参数, 其中包含了期望收到计费信息节点的主机名称或
   IP地址.

   收到含P-Charging-Function-Addresses头SIP请求的SIP proxy
   可以使用其中主机名称或IP地址作为计费信息或计费事件的目标.  
   发送计费信息或计费事件的方法不在本文中描述, 不过一般不使用SIP.

4.5.2.1 UA 的处理流程

   本文没有指明任何关于UA针对P-Charging-Function-Addresses 头的处理流程,
   UA不需要理解该头.





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


   然而, 这情况是可能的: UA 位于一个私有网络的管理区域(如, 一个 PSTN 网关, 或
   conference mixer), 并且它有权使用计费实体.在这种情形下, 
   当消息的下一跳是位于相同管理区域的proxy时, UA可以将
   P-Charging-Function-Addresses 头插入到一个SIP请求或响应中去.
 
4.5.2.2 Proxy 的处理流程

   支持这项扩展的SIP proxy在收到一个没有填写P-Charging-Function-Addresses的请求或
   响应时可以在前转消息之前插入一个P-Charging-Function-Addresses 头.
   该头填写为proxy应该发送计费相关信息的一个或多个计费实体地址列表.

   如果支持这项扩展的SIP proxy在收到带有P-Charging-Function-Addresses的请求或响应时,
   它可从头字段获取信息以应用相关逻辑, 如计费. 如果消息的下一跳与proxy处在
   同一管理区域, proxy应该在出口消息中包含P-Charging-Function-Addresses 头.
   然而, 如果下一跳与proxy不属同一管理区域, proxy必须删除 P-Charging-Function-Addresses 头.

4.5.2.3 用法示例

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

      场景                   UA1 --- P1 --- P2 --- UA2

   在这个场景中我们假定P1 和 P2 属于相同的管理区域.

   下面的例子列出由UA1发起最终到达UA2的INVITE事务的消息序列.
   P1 是UA1的出口proxy.  在这种情形下 P1 也插入计费
   信息.  然后P1 通过P2将呼叫路由至UA2.

  使用P-Charging-Function-Addresses头INVITE的消息序列:








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


      F1 Invite UA1 -> P1
         INVITE sip:[e-mail] 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: 18 INVITE
         Contact: sip:ua1@192.0.2.4

      F2 Invite P1 -> P2
         INVITE sip:[e-mail] SIP/2.0
         Via: SIP/2.0/UDP p1.home1.net:5060;branch=z9hG4bK34ghi7ab04
         Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
         To: sip:[e-mail]
         From: sip:ua1home1.net;tag=456248
         Call-ID: 843817637684230998sdasdh09
         CSeq: 18 INVITE
         Contact: sip:ua1@192.0.2.4
         P-Charging-Function-Addresses: ccf=192.1.1.1; ccf=192.1.1.2;
                                         ecf=192.1.1.3; ecf=192.1.1.4

   现在P1和P2都知道采集计费记录或计费事件的实体的IP地址.
   两个代理服务器都能向相同的实体发送计费信息.

4.6 P-Charging-Vector 头

      3GPP 定义了分布式架构导致多个网络实体被涉及提供接入和服务.
   运营商需要他们认为合理的能力和伸缩性去为接入和服务计费.
   该需求协调不同网络实体(如SIP代理服务器)在相同会话产生的计费记录
   相互关联.

   关联信息包括, 但并只限于, 一个让账单结果变得简单的全局唯一计费标识符.

   一个计费向量定义为一次计费信息的采集.
   计费向量在对话建立过程中或单独的对话外事务中填写. 
   计费向量中的信息可以被多个网络实体 (包括 SIP代理服务器)填写和获取.
   有三类关联信息需要被传送: IMS计费标识值 (ICID), 创建ICID值的SIP proxy 的地址,
   以及 Inter Operator标识符s (IOI).



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


   ICID 的值是对话及对话外事务的计费标识符. 
   它用来关联计费记录.  ICID必须是全局唯一的值.  生成唯一ICID值的一种方法是使用两
   个部份: 一个本地唯一值和SIP proxy的主机名或IP地址去生成唯一值.

   IOI 标识一个SIP对话或对话外事务涉及到的发起或终止网络.
   
   对话的每一端都可以产生 IOI 以标识本端的网络.

   由网络指明的接入层标识符的接入网计费信息也是希望得到的.
   (如, UMTS 无线接入网 或 IEEE 802.11b). 
   每种类型网络信息的细节不在本文中描述.

  我们定义了 SIP 私有头 P-Charging-Vector.  如果没有出现该头的话,
  不论是对话发起请求或响应还是对话外单独的事务的请求和响应, proxy 都可以
  包含该头. 该头在请求或响应中只能出现一次.

  SIP proxy 收集值并填写-Charging-Vector头的机制不在本文描述.

4.6.1 P-Charging-Vector 头的适用声明 

   P-Charging-Vector 头适用于单个私有管理区域或存在信任关系的不同管理区域.

   P-Charging-Vector 头不能包含在SIP消息中发送到其他不存在信任关系的网络.
   该头不适用于不需要在多个网络实体(如SIP代理服务器)关联计录的管理区域管理计费.