P-Called-Party-ID頭域
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:[email protected]
上面描寫敘述的方案假定 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 提供對應的服務.
P-Called-Party-ID頭域