典型的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:[email protected]

From: sip:[email protected];tag=456248

Call-ID: 843817637684230998sdasdh09

CSeq: 1826 REGISTER

Contact: sip:[email protected]



用户注冊其个人 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:[email protected]

From: sip:[email protected];tag=346249

Call-ID: 2Q3817637684230998sdasdh10

CSeq: 1827 REGISTER

Contact: sip:[email protected]



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



场景 UA --- P1 --- P2

F3 Invite P2 -> P1

INVITE sip:[email protected] SIP/2.0

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

To: sip:[email protected]

From: sip:[email protected];tag=938s0

Call-ID: 843817637684230998sdasdh09

CSeq: 101 INVITE



代理server P1 定位目标用户并用其注冊时的 Contact 字段值替换 Request-URI。

F4 Invite P1 -> UA

INVITE sip:[email protected] 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:[email protected]

From: sip:[email protected];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:[email protected] SIP/2.0

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

To: sip:[email protected]

From: sip:[email protected];tag=938s0

Call-ID: 843817637684230998sdasdh09

CSeq: 101 INVITE



F6 Invite P1 -> UA

INVITE sip:[email protected] 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:[email protected]

From: sip:[email protected];tag=938s0

Call-ID: 843817637684230998sdasdh09

P-Called-Party-ID: sip:[email protected]

CSeq: 101 INVITE



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

05-12 10:23