P-Called-Party-ID头域

典型的proxy 服务器在路由 INVITE 请求到目标时插入 P-Called-Party-ID 头域.该头域用 porxy 收到请求的 Request-URI 填写。UAS 从几个已注册的 AORs 中标识出是会话邀请发送给哪个AOR。

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 请求。

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:user1-business@example.com

From: sip:user1-business@example.com;tag=456248

Call-ID: 843817637684230998sdasdh09

CSeq: 1826 REGISTER

Contact: sip:user1@192.0.2.4

用户注册其个人 URI 也到代理服务器 (P1)。

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:user1-personal@example.com

From: sip:user1-personal@example.com;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:other-user@othernetwork.com。 SIP 服务器 othernetwork.com 将会话前转到sip:user1- business @example.com。

场景 UA --- P1 --- P2

F3 Invite P2 -> P1

INVITE sip:user1-business@example.com SIP/2.0

Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1

To: sip:other-user@othernetwork.com

From: sip:another-user@anothernetwork.com;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:other-user@othernetwork.com

From: sip:another-user@anothernetwork.com;tag=938s0

Call-ID: 843817637684230998sdasdh09

CSeq: 101 INVITE

当 UAS 收到 INVITE, 它不确判断是业务 URI 还是个人 URI 上收到会话邀请。无论 UAS 还有代理服务器以及应用服务器都不可能对提供会话目标 AOR 作出判断。我们解决这个问题方案是：允许用户的归属域代理服务器(SIP 中定义)插入一个标识会话目标的 AOR 的 P-Called-Party-ID 头域。

如果使用了这项 SIP 扩展的话，被叫用户代理服务器将在获得消息 F5 后，用 F5 中的 Request-URI 填写到 F6 中 P-Called-Party-ID 去。

消息流 F5 和 F6 内容如下:

F5 Invite P2 -> P1

INVITE sip:user1-business@example.com SIP/2.0

Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1

To: sip:other-user@othernetwork.com

From: sip:another-user@anothernetwork.com;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:other-user@othernetwork.com

From: sip:another-user@anothernetwork.com;tag=938s0

Call-ID: 843817637684230998sdasdh09

P-Called-Party-ID: sip:user1-business@example.com

CSeq: 101 INVITE

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