RFC 3841 的位址比對方法

依RFC 3841 Caller Preferences for Session Initiation Protocol (SIP)上所 說明的位址比對方法，是為了讓發話者裝置能夠選擇適當的受話裝置，以 便傳送影像或聲音等功能，也就是希望受話者裝置與發話者有相同的能 力，因此在請求連線時，可以附加兩種header field：Reject-Contact header field及Accept-Contact header field，其中便會提到該發話端拒絕裝置有哪些 功能的位址或是同意裝置有哪些功能的位址，而比對方法是首先處理 Reject-Contact header field ，排除掉不想要的位址，餘下的位址便稱為target set ，接著處理 Accept-Contact header field，依其想要的功能將餘下的位址 做一排序。

在 target set 中，若無位址存在，代表所有受話者位址皆被排除在外，

為了避免 call miss 的問題，則連線順序會依各位址的 q 值為依據，若有位 址存在 target set，接者是要在這其中排出順序，順序的參照數值稱為 Qa 值，計算方式是依照 Accept-Contact，Qa 值是在當位址的 q 值相同時，才 拿來當作第二決定優先順序之值；另外有種情形是受話者某位址並不帶有 任何能力參數可供比對時，將會被暫時排除在 target set 之外，待計算 Qa 值時才加回在 target set 中，且其 Qa 值為 1。

每個位址的 Qa 值計算方式，是先依 accept-contact 的項目計算分數 (score)，然後視 accept-contact 有幾項，算出其平均值，即為 Qa 值，計算 方式如下所述，若該位址所具備的能力完全符合 accept-contact 中的所需要 項目，則拿到 1 分，若只符合二項中的一項則拿到¹

2分，也就是 0.5 分，

依此類推，接著再按其附加標籤調整分數，如圖 2.1，標籤的種類有 explicit 與 require，調整分數的方式為當分數為 1 分時，不作調整；小於 1 分時才 進入調整步驟程序，因為分數小於 1，代表該位址的受話裝置有部份功能 沒有完全符合該 accept-contact 的要求，因此，若沒有附加任何標籤，則分 數不作改變；若有 explicit 標籤，則分數調整為 0；若有 require 標籤，表 示這項功能是必須的，則將該位址排除在 target set 外，最後依有幾項

accept-contact，算出該位址分數的算術平均值，即為 Qa 值，誰獲得的 Qa 最高即是 target set 中的第一優先位址，排出順序後，再依 target set 中各位 址的 q 值大小，由大至小，若相同時再參照剛剛計算出的 Qa 值，決定受 話端的順序，依序發出連線請求，其步驟順序整理如下：

STEP 1.處理 Reject-Contact header field STEP 2.處理 Accept-Contact header field

STEP 3.計算 target set 中各位址的分數(score)，其平均值為 Qa STEP 4.先依 q-value，若有相同再依 Qa 值大小決定優先順序

圖 2.1 計算分數流程圖

2.3.1 位址比對範例

範例如RFC 3841 Caller Preferences for SIP[8]中所述，假設一位已註冊 的使用者其位址為sip:[email protected]，且他有五個連絡位址，分別是：

1. Contact:sip:[email protected];audio;video;methods="INVITE,BYE

";q=0.2

2. Contact:sip:[email protected];audio="FALSE";methods="INVITE"

;actor="msg-taker";q=0.2

3. Contact: sip:[email protected];audio;actor="msg-taker";

methods="INVITE";video;q=0.3

4. Contact:sip:[email protected];audio;methods="INVITE,OPTIONS"

;q=0.2

5. Contact: sip:[email protected];q=0.5

u1 到u5，位址後面接著的即是該裝置所具備的功能，如第一個連絡 位址u1，即是指位址為[email protected]的，其具備的能力有audio、

video，且可以使用SIP的methods為INVITE與BYE，及其q值為 0.2，當有一 發話者向sip:[email protected]發出INVITE時，且附帶的caller preferences header fields如下所示：

– Reject-Contact: *;actor="msg-taker";video – Accept-Contact: *;audio;require

– Accept-Contact: *;video;explicit

– Accept-Contact: *;methods="BYE";class="business";q=1.0 如表 2.2 所示，按照 2.3 節提到的位址比對方法步驟，一開始，首先移除 u5，因為他並不帶有任何能力可供比較，所以先排除在外，接著處理 Reject-Contact，u3 是唯一完全符合的項目，因此將 u3 排除，餘下的繼續

步驟程序，u1、u2、u4 成為 target set，按 accept-contact header field 開始計 算 分 數 ， u1 符 合 第 一 項 accept-contact ， 拿 到 1 分 ， 亦 符 合 第 二 項 accept-contact，對於第二項也拿到 1 分，在第三項 accept-contact，只符合 兩項要求中的一項，因此拿到 0.5 分，又該項並無附加任何標籤，所以分 數不作調整，而 u2，對於第一項 accept-contact 並不符合，又該項有附加 標籤 require，所以 u2 被排除，接著處理 u4，符合第一項 accept-contact，

拿到 1 分，對於第二項 accept-contact 的要求，不符合 video，得 0.0 分，

Reject-Contact Accept-Contact Accept-Contact Accept-Contact

Reject & Accept

methods="BYE";

class="business"; q=1.0

Qa

audio;

video;

methods="INVITE,BYE; u1

q=0.2

Get 1 point Get 1 point Get 0.5 point (1+1+0.5)/

3=0.83 audio="FALSE";

methods="INVITE";

在 RFC3841 Caller Preferences for SIP 的位址比對法中，可以發現是把 受話者的所有裝置位址一次處理完，決定出剩餘位址(target set)的順序後再 依其 q 值的大小決定真正的連線順序，其真正第一優先考量的參考值是各 位址的 q 值，是經過比對過程後，餘下受話者位址的 q 值，而非在處理過 程中依 Accept-Contact 計算分數而得的 Qa 值，Qa 值是在 q 值相同時，才 提供一個比較的依據，是連線請求的第二參考值。