P-Called-Party-ID头域

典型的proxy server在路由 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. 会话在到达为用户服务的代理server之前被前面的 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) 注冊到代理server (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 也到代理server (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) 从另外一个代理server(P2)收到一个目标为该用户业务 SIP AOR 的 INVITE 请求。我们假定该 SIP INVITE 之前经历了一系列的前转。因此它的 To 头域字段值填写并非用户的 AOR。在这样的情况下我们假定会话最初是发给sip:other-user@othernetwork.com。 SIP server 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



代理server 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 还有代理server以及应用server都不可能对提供会话目标 AOR 作出推断。我们解决问题方案是：同意用户的归属域代理server(SIP 中定义)插入一个标识会话目标的 AOR 的 P-Called-Party-ID 头域。

假设使用了这项 SIP 扩展的话。被叫用户代理server将在获得消息 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 提供对应的服务.