国产一级a片免费看高清,亚洲熟女中文字幕在线视频,黄三级高清在线播放,免费黄色视频在线看

　　計費對于任何服務(wù)提供商而言都是必不可少的功能，電信運營商也不例外。因此，任何網(wǎng)絡(luò)都需要包含一組節(jié)點來專門實現(xiàn)這一任務(wù)。計費可以通過預(yù)付費（Prepaid）和后付費（Postpaid）這兩種方式實現(xiàn)。雖然預(yù)付費解決方案正在日趨盛行，不過后付費的解決方案仍然具有廣泛的普及程度。因此，任何面向商業(yè)應(yīng)用的電信網(wǎng)絡(luò)都必須同時實現(xiàn)這兩種方案。此外，隨著以IT為基礎(chǔ)的服務(wù)領(lǐng)域突飛猛進(jìn)，電話通信之外的服務(wù)也如雨后春筍般涌出并不斷發(fā)展演進(jìn)。視頻電話、無線接入和隨需應(yīng)變視頻都是典型的例子。

　　所有這些服務(wù)都需要找到一種計費方式。本文將探討如何使用各種IMS架構(gòu)來實現(xiàn)計費功能。文章還將描述如何使用BEA WebLogic SIP Server和Diameter協(xié)議實現(xiàn)這些架構(gòu)。

IMS計費架構(gòu)

　　IP多媒體子系統(tǒng)（IP Multimedia Subsystem，IMS）網(wǎng)絡(luò)使用的是3GPP所定義的架構(gòu)。圖1顯示了這一架構(gòu)中的計費功能。

　　1. IMS計費架構(gòu)（單擊圖片查看大圖）

　　圖1中的元素可以實現(xiàn)預(yù)付費和后付費這兩種計費功能。這兩種看上去類似的模式實際上從網(wǎng)絡(luò)視角來說是不同的。其中最大的差異是：當(dāng)用戶想要使用預(yù)付費服務(wù)時，網(wǎng)絡(luò)會根據(jù)用戶的當(dāng)前賬戶余額確定是否應(yīng)該允許該操作。預(yù)付費系統(tǒng)具有以下幾個要點：

• 在使用各服務(wù)之前，必須獲得計費系統(tǒng)的許可（我們稱之為交易準(zhǔn)許[credit authorization]）。
• 要決定是否應(yīng)該許可該服務(wù)，計費系統(tǒng)必須能夠?qū)崟r獲取用戶賬戶余額的信息。在后付費系統(tǒng)中，通常通過收集服務(wù)使用情況的數(shù)據(jù)并于月底處理（成批處理）這些數(shù)據(jù)來實現(xiàn)這一目的。不過在預(yù)付費系統(tǒng)中卻不能采用這種方法。在預(yù)付費系統(tǒng)中，使用任何服務(wù)都必須立即扣除賬戶的交易金額。
• 計費系統(tǒng)未在適當(dāng)?shù)臅r間內(nèi)響應(yīng)時，必須使用一種高效的方式來處理這種情況；不能讓用戶無限制地等待。
• 用戶必須能夠查詢賬戶的余額。

　　由于預(yù)付費系統(tǒng)要求能夠?qū)崟r更新賬號的信息，因此這種方式也被稱作在線計費。后付費的方式則被稱作離線計費。

離線計費

　　離線計費的框架如圖2所示。

　　圖2. 離線計費架構(gòu)（單擊圖片查看大圖）

　　該架構(gòu)由以下這些節(jié)點組成：

• 計費觸發(fā)函數(shù)（Charging Trigger Function，CTF）——服務(wù)元素（Service Element）的組成部分，負(fù)責(zé)監(jiān)控服務(wù)使用并以此為依據(jù)生成計費事件。
• 計費數(shù)據(jù)函數(shù)（Charging Data Function，CDF）——根據(jù)從CTF接收到的事件生成計費數(shù)據(jù)記錄（Charging Data Record，CDR），并將它們傳遞給CGF。
• 計費網(wǎng)關(guān)函數(shù)（Charging Gateway Function，CGF）——負(fù)責(zé)將CDR持久存儲到數(shù)據(jù)庫以及一些預(yù)處理和錯誤檢查；它還負(fù)責(zé)從許多CDF收集CDR并將其發(fā)送給賬單系統(tǒng)。
• 賬單系統(tǒng)（Billing System）——處理CDR并創(chuàng)建一些最終輸出信息，比如可使用這些信息為用戶開發(fā)票。

　　在這個架構(gòu)中，BEA WebLogic SIP Server連同CFT的角色是服務(wù)元素。

在線計費

　　圖3顯示了在線計費架構(gòu)中所使用的節(jié)點。

　　圖3.在線計費架構(gòu)（單擊圖片查看大圖）

　　以下是這些節(jié)點的描述：

• 計費觸發(fā)函數(shù)（Charging Trigger Function，CTF）——與離線計費架構(gòu)中所使用的CTF類似，不過此處的CTF需要在用戶賬戶余額不足時中斷服務(wù)。
• 在線計費系統(tǒng)（Online Charging System，OCS）——實現(xiàn)在線計費函數(shù)（Online Charging Function，OCF），它需要依賴以下這些函數(shù)：

• 賬戶余額管理函數(shù)（Account Balance Management Function，ABMF）——存儲和更新用戶賬戶的存款信息。
• 估價函數(shù)（Rating Function，RF）——根據(jù)網(wǎng)絡(luò)運營商所定義的價目表確定使用服務(wù)的費用。

　　在這個架構(gòu)中，BEA WebLogic SIP Server連同CTF的角色是服務(wù)元素（Service Element）。

IMS計費信息關(guān)聯(lián)

　　如今出現(xiàn)了許多不同的架構(gòu)和網(wǎng)絡(luò)；為各個網(wǎng)絡(luò)實體（如 SIP Proxy）提供正確的計費元素地址是一種明確的需求。3GPP定義了兩種類型的計費元素，即CDF和OCS。因此，擁有這些元素的多個實例是可行的。識別這些元素的方法是在SIP消息中添加一個頭部用于傳遞地址。

　　SIP信令中傳送的離線和在線函數(shù)地址被編碼到P-Charging-Function-Addresses中。P-Charging-Function-Addresses頭部含有CCF和ECF參數(shù)。此處是頭部的一個示例：

　　P-Charging-Function-Addresses：ccf=192.168.100.1；ecf=192.168.100.2

　　識別和關(guān)聯(lián)計費信息也是有必要的。IMS計費標(biāo)識符（IMS Charging Identifier，ICID）可以解決這個問題。ICID在同一會話或事務(wù)的IMS元素之間共享。ICID參數(shù)存儲在SIP消息的P-Charging-Vector頭部中，以在網(wǎng)絡(luò)上傳輸。這個頭部是由P-CSCF插入的，并且包含以下參數(shù)（按規(guī)格描述）：

• IMS計費標(biāo)識符（IMS Charging Identifier，ICID）——必需。
• 訪問網(wǎng)絡(luò)計費標(biāo)識符——用于使用IBM計費數(shù)據(jù)關(guān)聯(lián)訪問網(wǎng)絡(luò)計費數(shù)據(jù)。
• Inter Operator Identifier (IOI)——識別會話或事務(wù)中的發(fā)信（orig-ioi）網(wǎng)絡(luò)和收信網(wǎng)絡(luò)（term-ioi）。該參數(shù)由S-CSCF插入，當(dāng)請求離開網(wǎng)絡(luò)時會被P-CSCF移除。

　　此處是P-Charging-Vector頭部的一個示例：

　　P-Charging-Vector: icid-value="655Ayet773+7389088787e"; orig-ioi=bea.net

參考模型

　　離線和在線計費程序都可以分為兩種截然不同的類型：即基于事件的計費（Event-based Charging）和基于會話的計費（Session-based Charging）。

• 基于會話的計費——需要在整個服務(wù)中維持會話的情況下使用這種方式。通常，賬單系統(tǒng)中至少有兩個請求：
• 發(fā)起請求（Initial Request）——用于發(fā)起計費活動。該請求包含與用戶使用的會話相關(guān)的數(shù)據(jù)。
• 中間請求（Intermediary Request）——用于更新當(dāng)前會話（比如說，在某個語音呼叫中添加一個視頻）。當(dāng)然，這個請求是可選的。
• 最終請求（Final Request）——用于關(guān)閉一個會話。
• 基于事件的計費——用于在某個特定的事件（比如，充當(dāng)Redirect Server的SIP AS事件）之后發(fā)起一次性賬單活動。

　　在離線計費的例子中，請求是通過Rf協(xié)議傳輸?shù)?。而在線計費系統(tǒng)使用的是Ro協(xié)議。這兩種協(xié)議都基于Diameter。這兩者之間存在一些差異，其中之一是對與計費會話相關(guān)的會話狀態(tài)的維護(hù)。在事件模型中，由于只需處理單個應(yīng)用程序的事件，因此沒有必要維護(hù)會話。RFC3588中對會話的定義是“一系列致力于某個特定活動的相關(guān)事件”。

離線計費：Rf接口

　　CTF和CDF之間的事件和會話的離線計費的執(zhí)行使用了3GPPTS 32.240中所定義的Rf引用點。Rf接口用于非實時的操作，在這些操作中用戶所使用的單元不會計入賬戶。WebLogic SIP Server負(fù)責(zé)從CTF向CDF發(fā)送Diameter請求來實現(xiàn)這點。

　　這些消息用于向CCF報告賬戶信息，跟隨在DIAMETER方法后面（一個請求，一個應(yīng)答）：

• 計費請求（Accounting Request，ACR）
• 計費應(yīng)答（Accounting Answer，ACA）

　　根據(jù)之前公開的一個模型，基于會話的計費中的Accounting-Record-Type AVP可以含有以下這些值：

• START_RECORD，用于啟動計費會話，通常當(dāng)應(yīng)用程序接收到確認(rèn)初始SIP INVITE的SIP 200 OK消息時。
• INTERIM_RECORD，用于更新會話，比如，當(dāng)前SIP對話中的SIP RE-INVITE和/或UPDATE的例子。
• STOP_RECORD，用于停止賬號計費會話，比如，當(dāng)應(yīng)用程序接收到一個SIP BYE消息時。

　　在基于會話的計費系統(tǒng)中，WebLogic SIP Server會自動將Diameter Session鏈接到當(dāng)前活動的呼叫狀態(tài)。這表示Call-id編碼在Diameter Session Id中。

　　圖4.離線計費：基于會話的模型（單擊圖片查看大圖）

　　對于一次性計費事件，Event-Type的值為EVENT_RECORD。

　　圖5.離線計費：基于事件的模型（單擊圖片查看大圖）

在線計費：Ro接口

　　在線計費的目的是將計費信息提供給OCS，從而能夠在許可使用網(wǎng)絡(luò)資源之前執(zhí)行存款控制。為此，預(yù)付費的訂閱者必須存在于OCS中，資源使用要根據(jù)這情況記入賬單。因此，所有的活動（包括訪問被請求的資源使用、確定貨幣數(shù)額或其他單位的數(shù)額，以及將這些數(shù)額從訂閱者的賬戶中扣除）必須發(fā)生在使用資源之前，或至少是在使用資源的過程——即使用資源時必須處于在線狀態(tài)。根據(jù)情況的不同，資源使用結(jié)束時必須執(zhí)行最終評估。因此：必須區(qū)分以下兩種情況：

• 直接付款（Direct Debiting）——在這種情況下，交易單位會在單個事務(wù)中直接從用戶賬戶中扣除。
• 單位保留（Unit Reservation）——在這種情況下，OCS會將交易單位保留在用戶賬戶中，這主要是因為OCS不知道所提供的服務(wù)需要多少單位。服務(wù)終止之后，已用存款金額會從用戶賬戶中扣除，并用最后任何保留和未使用的單位會釋放并添加到用戶賬戶中去。

　　根據(jù)以上分類，OCS會識別以下三種場景：

• 即時事件計費（Immediate Event Charging，IEC）（基于事件的計費）
• 具有單位保留的事件計費（Event Charging with Unit Reservation，ECUR）（基于事件的計費）
• 具有單位保留的會話計費（Session Charging with Unit Reservation，SCUR）（基于會話的計費）

　　基于事件的計費的發(fā)生可以保留或不保留訂閱者的賬戶，并且可以將其識別為具有單位保留的事件計費（ECUR）或即時事件計費（IEC）。CC-Request-Type將具有一個EVENT REQUEST值。圖6顯示了相關(guān)的IEC呼叫流。

　　圖6.在線計費：事件模型（IEC）（單擊圖片查看大圖）

　　圖7顯示了與ECUR相關(guān)的呼叫流。

　　圖7.事件計費模型（ECUR）（單擊圖片查看大圖）

　　對于具有單位保留的會話計費（SCRU），需要大量的詢問，而且直接付款（Direct Debiting）情況下的WebLogic SIP Server（或者SIP-AS之類的普通網(wǎng)絡(luò)元素）的行為如下所示：提供服務(wù)之前，必須向OCS發(fā)送一個請求。接收到準(zhǔn)許的肯定應(yīng)答之后，WebLogic SIP Server能夠最后支持這個服務(wù)。作為任何其他的Diameter請求，存款控制請求被Command-Code字段識別；在本例中，代碼設(shè)置為272。CC-Request-Type AVP用于識別請求的類型，并且必須出現(xiàn)在所有的CCR消息中。根據(jù)RFC4006，CC-Request-Type具有以下這些值：

• INITIAL_REQUEST——用于啟動一個會話，觸發(fā)SIP方法有INVITE (SCUR)、NOTIFY (ECUR)、MESSAGE (ECUR)、REGISTER (ECUR)、SUBSCRIBE (ECUR)、REFER (ECUR)和PUBLISH (ECUR)。
• UPDATE REQUEST——用于為已有會話更新信息。通常，當(dāng)SIP 200 OK消息對SIP INVITE、RE-INVITE或UPDATE確認(rèn)時，或者當(dāng)保留配額到期時，有效時間觸發(fā)或其他事件觸發(fā)時使用。
• TERMINATION REQUEST——用于終止一個會話，當(dāng)我們接收到SIP最終應(yīng)答（4xx，5xx，6xx），異常中止SIP會話和SIP BYE時使用。
• EVENT REQUEST——無需維護(hù)會話時使用。

　　如圖8所示。

　　圖8.基于會話的模型（SCUR）（單擊圖片查看大圖）

示例IMS場景

　　圖9和圖10所顯示的IMS網(wǎng)絡(luò)就是一個在線計費場景的示例。當(dāng)用戶A發(fā)起呼叫時，用戶的電話會向P-CSCF發(fā)送一個SIP INVITE請求。P-CSCF是運營商網(wǎng)絡(luò)的入口點。它將INVITE消息轉(zhuǎn)發(fā)到分配給用戶的S-CSCF。網(wǎng)絡(luò)假定P-CSCF知道S-CSCF的地址，因為該信息在用戶注冊（圖中未顯示出來）時就從HSS中檢索出來了。然后，S-CSCF檢測到這個呼叫要求在線計費并將INVITE轉(zhuǎn)發(fā)給IMS-GWF（IMS網(wǎng)關(guān)函數(shù)）。

　　圖9. IMS示例場景：呼叫設(shè)置（單擊圖片查看大圖）

　　可以將IMS-GWF看作一種特殊的SIP應(yīng)用服務(wù)器，其作用是提供與OCS的通信。接收到INVITE消息后，IMS-GWF會向OCS發(fā)送一個類型INITIAL的CCR，從而為呼叫保留一些存款。OCS使用CCA作為應(yīng)答，其中含有結(jié)果代碼DIAMETER_SUCCESS，指示呼叫是允許的。CCA還含有關(guān)于準(zhǔn)許“服務(wù)單位”數(shù)量的信息。比如，這些單位可以是呼叫持續(xù)時間的秒數(shù)。

　　接收到CCA后，IMS-GWF將之前接收到的INVITE消息轉(zhuǎn)發(fā)回給CSCF，然后CSCF再將其傳遞給網(wǎng)絡(luò)的被叫方（I-CSCF，S-CSCF，P-CSCF，用戶B的電話）。IMS-GWF還通過設(shè)置計時器來監(jiān)控準(zhǔn)許單位的使用情況。

　　然后，用戶B的電話開始響鈴并使用180 Ringing消息應(yīng)答INVITE?？紤]到簡單性，這個圖中并未包含這個應(yīng)答，以及任何100 Trying應(yīng)答消息。當(dāng)被叫方應(yīng)答電話時，將會發(fā)送200 OK消息。這個OK消息通過各種不同的網(wǎng)絡(luò)元素到達(dá)用戶A的電話，如下圖所示。然后，A話機(jī)將ACK轉(zhuǎn)發(fā)到B端。這樣一個呼叫就建立起來了。

　　圖10. IMS示例場景：呼叫終止（單擊圖片查看大圖）

　　當(dāng)所有準(zhǔn)許單位都被使用后（也就是IMS-GWF中的計時器到期），將發(fā)送一個CCR保留這些單位的另一部分。這次的請求類型是UPDATE。OCS發(fā)送含有結(jié)果代碼DIAMETER_SUCCESS的CCA，以許可呼叫繼續(xù)。如果準(zhǔn)許單位是用戶賬戶上最后可用的存款，則OCS應(yīng)答會含有Final-Unit-Indication AVP。這表示使用完當(dāng)前準(zhǔn)許的單位之后，呼叫會斷開連接（或者采用另一種特殊的動作）。但是，在本例中沒有出現(xiàn)這個AVP。

　　在這之后，用戶A決定關(guān)閉呼叫并發(fā)送BYE。BYE將通過P-和S-CSCF轉(zhuǎn)發(fā)給網(wǎng)絡(luò)的呼叫方和IMS-GWF，IMS-GWF會發(fā)送類型TERMINATION的CCR給計費系統(tǒng)。這個CCR中包含與使用過的“服務(wù)單位”有關(guān)的信息（在本例中為呼叫持續(xù)時間）。OCS使用CCA作為應(yīng)答并釋放與該會話相關(guān)的內(nèi)部資源（比如說內(nèi)存、計時器）。用戶B的電話使用200 OK消息應(yīng)答B(yǎng)YE，該消息將傳回呼叫方。最后呼叫關(guān)閉。

如何在WebLogic SIP Server中實現(xiàn)這些功能

　　BEA WebLogic SIP Server含有一個簡單的支持Diameter協(xié)議的API，包括Diameter Base Accounting和Diameter Credit-Control應(yīng)用程序。本節(jié)介紹如何配置和使用Diameter功能。

配置

　　要使用Diameter功能，需要對WebLogic域進(jìn)行適當(dāng)?shù)呐渲?。配置過程由以下幾個步驟組成：

• 啟用Diameter自定義資源。
• 為Diameter創(chuàng)建一個網(wǎng)絡(luò)通道。
• 配置Diameter節(jié)點和應(yīng)用程序。

　　BEA文檔頁面的 參考資料 部分詳述了這些步驟。

初始化

　　部署好的應(yīng)用程序使用Diameter Rf或Ro功能之前，需要分別獲取RfApplication或RoApplication對象。這可以通過以下代碼實現(xiàn)，假定使用的是SIP或HTTP servlet類：

ServletContext sc = getServletConfig().getServletContext();
Node node = (Node)sc.getAttribute("com.bea.wcp.diameter.Node");
if(node == null) {
throw new  ServletException("Can't get Node. Check diameter.xml");
}
RfApplication rfApp = (RfApplication)
node.getApplication(Charging.RF_APPLICATION_ID);
if(rfApp == null) {
throw new  ServletException("Can't get RfApplication. Check diameter.xml");
}
RoApplication roApp = (RoApplication)
node.getApplication(Charging.RO_APPLICATION_ID);
if(roApp == null) {
throw new  ServletException("Can't get RoApplication. Check diameter.xml");
}

會話處理

　　Diameter有一個會話的概念。RFC3588中對會話的正式定義是“一系列致力于某個特定活動的相關(guān)事件”。實際上，會話使用ACR（START）或CCR（INITIAL）表示開始，并以ACA（STOP）或CCA（TERMINATION）表示結(jié)束。在一次性事件的例子中，會話只包含請求和應(yīng)答。所有消息都屬于一個與Session-Id AVP公共值相關(guān)的會話。

　　在WebLogic SIP Server API中，Diameter會話是與com.bea.wcp.diameter.Session對象映射在一起的。Session類處理Session-Id AVP。Rf和Ro接口有兩個特殊的子類，即RfSession和RoSession。這兩個類只處理特定于Diameter計費的請求和應(yīng)答。可以使用Rf/RoApplication創(chuàng)建會話對象：

　　RfApplication rfApp = ...

　　RfSession rfSes = rfApp.createSession();

　　RoApplication roApp = ...

　　RoSession roSes = roApp.createSession();

　　此外，DIAMETER會話是可序列化的，您可以將其作為屬性存儲于SipApplicationSession中，反之亦然。WebLogic Sip Server會自動將會話鏈接到活動的呼叫狀態(tài)。接收到消息之后，容器將自動檢索呼叫狀態(tài)，并找出Diameter會話。

創(chuàng)建Rf請求

　　創(chuàng)建Rf請求相當(dāng)簡單。讓我們從一個基于會話的請求入手。如前所述，獲得RfApplication和RfSession之后，我們使用RfSession對象創(chuàng)建一個新Accounting-Request。由于這是第一個請求，requestType將以值的形式出現(xiàn)：

　　ACR acr = session.createACR(RecordType.START);

　　創(chuàng)建Event請求的代碼為：

　　ACR acr = session.createACR(RecordType.INTERIM);

　　創(chuàng)建一個新Accounting-Request時，將會自動填充以下AVP：

　　可以通過調(diào)用addAvp方法添加其他AVP：

　　Acr.addAvp(Attribute.EVENT_TIMESTAMP, new Integer(timestamp));

創(chuàng)建Ro請求

　　對Ro接口的請求（比如說Credit-Control-Requests）的創(chuàng)建方式非常類似于創(chuàng)建Accounting-Requests的方式。以下這個示例可以說明一切：

　　CCR ccr = roSes.createCCR(RequestType.INITIAL);

　　注意，Credit Control的請求類型與賬戶的記錄類型有所不同——比如，START和INITIAL。事件請求可直接通過RoApplication創(chuàng)建，而不需要明確地創(chuàng)建一個會話：

　　CCR eventCcr = roApp.createEventCCR();

　　在兩種情況下，WebLogic SIP Server都會自動設(shè)置以下表格中的AVP。

　　可以使用與前面相同的方法添加其他AVP。

　　Diameter Base屬性是Attribute類中的靜態(tài)字段。此外，與計費相關(guān)的屬性可以在Charging類和CreditControl類中找到。WebLogic SIP Server并未限制用戶使用這些預(yù)先定義的屬性?？梢允褂肁ttribute.define()方法之一來創(chuàng)建新屬性。Attribute類包含為所有基本屬性預(yù)先定義的常量。以下示例展示了如何添加一個AVP：

　　public static final Attribute SUBSCRIPTION_ID_TYPE = Attribute.define(666, "Subscription-Id-Type", Type.INTEGER);

　　添加一個已經(jīng)由用戶或容器定義過的AVP時，WebLogic Sip Server會拋出一個異常。添加完所有必要的AVP后，我們最后還要發(fā)送CCR?？梢允褂靡韵聝煞N方法完成這一操作：

　　ccr.send();

　　// - or -

　　CCA answer = (CCA)ccr.sendAndWait();

　　第二種方法會發(fā)送CCR并阻塞執(zhí)行，直到接收到應(yīng)答或發(fā)生超時。

接收應(yīng)答

　　WebLogic SIP Server Diameter API中有兩種接收應(yīng)答的方法。第一種是異步方式，以Request.sendAndWait()方法為基礎(chǔ)。這個方法會發(fā)送請求并阻塞呼叫線程直到接收到應(yīng)答或請求超時。它會返回接收到的應(yīng)答。發(fā)送請求的異步方式適用于阻塞線程不會造成問題的應(yīng)用程序。

　　第二種方法是異步分離發(fā)送動作和接收動作。請求是通過調(diào)用Request.send()發(fā)送的。這個方法會立刻返回。接收到應(yīng)答時，該方法會調(diào)用其rcvMessage()方法通知監(jiān)聽程序。這個監(jiān)聽程序必須要實現(xiàn)SessionListener接口，而且必須要在接收到應(yīng)答之前建立在會話中。以下示例演示了這種方法：

//This is a listener class
class MyListener implements SessionListener {

public void rcvMessage(Message  message) {
System.out.println("Received a message: " + message);
       if(message.getCommand().equals(CreditControl.CCA)) {
System.out.println("The message is a Credit-Control-Answer");
}
}
}
//This code is inside some other (or the same) class, in a method
//responsible for sending the request
   //Create session and listener
RoSession roSes =  roApp.createSession();
MyListener myListener = new  MyListener();

//Set the listener on the session
roSes.setListener(myListener);
   //Now create and send a request
CCR ccr =  roSes.createCCR(RequestType.INITIAL);
ccr.addAvp(...);
ccr.send();
   //send() returns immediately.  Answer will be received in
//myListener.rcvMessage()

　　帶有監(jiān)聽程序的實現(xiàn)還可以允許我們接收當(dāng)前會話內(nèi)的服務(wù)器所發(fā)送的請求（比如說，當(dāng)服務(wù)器決定馬上關(guān)閉會話時所發(fā)送的Abort-Session-Request）。請求和應(yīng)答都以同樣的方式傳遞給監(jiān)聽程序的rcvMessage()方法。由應(yīng)用程序負(fù)責(zé)為請求和應(yīng)答提供不同的行為。

錯誤和超時處理

　　在設(shè)定時間內(nèi)未收到請求的應(yīng)答時，WebLogic SIP Server會自動檢測超時條件。diameter.xml中配置了超時的默認(rèn)值。還可以使用帶參數(shù)的send(...)或sendAndWait(...)為各個請求分別指定超時的時間。

　　WebLogic SIP Server通過創(chuàng)建一個帶有結(jié)果代碼DIAMETER_UNABLE_TO_DELIVER的響應(yīng)來處理超時。實際上，并不會在網(wǎng)絡(luò)上發(fā)送響應(yīng)，但是會將其傳遞給發(fā)送請求的應(yīng)用程序。這種處理超時的方法類似于SIP中所使用的方法。

　　同樣，WebLogic SIP Server可拋出以下兩種異常：

• 協(xié)議錯誤時會拋出MessageException異常，比如說無效的消息格式
• AVP無效和/或丟失時會拋出AvpException異常

調(diào)試應(yīng)用程序

　　WebLogic SIP Server中的日志記錄工具可用于跟蹤傳入和傳出消息。您可以使用控制臺配置消息調(diào)試。此外，也可以通過在腳本文件（類Unix的機(jī)器中為sh文件，Windows平臺中則為cmd）中的-Ddiameter.Debug=true選項來設(shè)置消息調(diào)試。調(diào)試消息將直接發(fā)送給控制臺。

　　除了在WLSS中設(shè)置調(diào)試之外，使用網(wǎng)絡(luò)嗅探程序也是大有幫助。這種類型的程序可以顯示在網(wǎng)絡(luò)中傳輸?shù)膱笪摹ireshark（原來稱作Ethereal）可能是最受歡迎的嗅探程序，它是一款免費軟件。

示例應(yīng)用程序

　　Ro和Rf接口的示例應(yīng)用程序可以從 此處 下載。這個應(yīng)用程序為一個SIP會話提供了Diameter Ro/Rf計費功能。接收到一個INVITE時請求，應(yīng)用程序會通過發(fā)送一個類型INITIAL的CCR來啟動會話。然后，用完所有準(zhǔn)許的存款后，應(yīng)用程序會通過發(fā)送UPDATE CCR來請求新的存款。接收到BYE消息時，應(yīng)用程序會通過發(fā)送TERMINATION CCR來關(guān)閉計費會話。

　　在存款用完的情況下，應(yīng)用程序也會關(guān)閉會話。如果CCA中接收到一個Final-Unit-Indication AVP，并且所有準(zhǔn)許額度都已用完，則應(yīng)用程序會通過發(fā)送BYE消息來斷開SIP會話。應(yīng)用程序還會發(fā)送一個TERMINATION CCR來關(guān)閉Diameter會話。

BEA模擬程序和Rf接口

　　BEA WebLogic Sip Server提供了一種簡單的測試方法，可以使用一個Rf接口的獨立的模擬程序測試自己的應(yīng)用程序。模擬程序可以作為獨立的應(yīng)用程序運行，模擬程序的離線計費接口為com.bea.wcp.diameter.charging.RfSimulator。

　　此外，BEA還提供了一個HSS模擬程序用于存儲與服務(wù)相關(guān)的數(shù)據(jù)，可以使用相同的方式運行該模擬程序。注意，這個模擬程序是用于測試目的的，并且只支持RepositoryData和PSI。HSS模擬程序為com.bea.wcp.diameter.sh.HSSSimulator。

　　這兩種模擬的命令行選項如下所示：

• -r, -real 節(jié)點實際名稱
• -h, -host 主機(jī)身份
• -a, -address 節(jié)點監(jiān)聽地址
• -p, -port 節(jié)點監(jiān)聽端口
• -d, -debug 啟用調(diào)試
• -m, -mdebug 啟用消息調(diào)試

　　以下示例演示了如何運行一個獨立的BEA Rf模擬程序：

　　java com.bea.wcp.diameter.util.Launcher -apps com.bea.wcp.diameter.charging.RfSimulator -r bea.com -h simulator -p 3900 -d -m

　　我們也可以運行多個模擬程序，比如使用以下腳本運行HSS模擬程序：

　　java com.bea.wcp.diameter.util.Launcher -apps com.bea.wcp.diameter.charging.RfSimulator,com.bea.wcp.diameter.sh.HssSimulator -h simulator -r bea.com -p 3900 -d -m

　　記住要先運行\(zhòng)sipserver30\server\bin\ directory目錄下的setWLSEnv腳本。

業(yè)已證實的互操作性

　　Ericpol Telecom已成功將其運行于BEA WLSS 3.0之上的IMS預(yù)付費解決方案（IMS Prepaid Solution）與Amdocs IMS計費解決方案（Amdocs IMS Charging Solution）集成在一起。IMS預(yù)付費解決方案通過其各組件的集成和相互協(xié)作提供了一種具有豐富特性的、兼容IMS的、可互操作的、電信級的解決方案。在這種集成場景中，IMS預(yù)付費解決方案通過Rf和Ro接口與Amdocs IMS計費解決方案相互通信。其網(wǎng)絡(luò)結(jié)構(gòu)如下所示：

　　圖11. BEA-Ericpol-Amdocs IOT的網(wǎng)絡(luò)架構(gòu)（單擊圖片查看大圖）

　　BEA-Ericpol IMS Prepaid和Amdocs Charging之間的互操作性測試（interoperability testing，IOT）包含以下兩個階段：離線和在線計費。各個場景的消息流包含在本文結(jié)尾的附加文件中。

　　IOT已經(jīng)證實WebLogic SIP Server中的Diameter實現(xiàn)符合協(xié)議規(guī)范。它還顯示對Java API的完全編程控制使得Diameter實現(xiàn)極具靈活性。在PoC過程中需要進(jìn)行幾次小更改。這些更改的實現(xiàn)快速而簡單。

　　IOT中所使用的Amdocs IMS計費解決方案基于Amdocs在線計費（Amdocs Online Charging）系統(tǒng)。與3GPP標(biāo)準(zhǔn)一致，這種在線計費功能通過Diameter接口與核心IMS網(wǎng)絡(luò)進(jìn)行交互（在線計費系統(tǒng)接口的Diameter引用點）。此外，Amdocs IMS計費解決方案中的兩種關(guān)鍵組件是Amdocs Rating和Amdocs Balance Manager。要與IMS呼叫會話控制函數(shù)進(jìn)行交互（以實現(xiàn)離線計費），針對IMS的3GPP標(biāo)準(zhǔn)定義了以下兩個組件：計費數(shù)據(jù)函數(shù)（charging data function，CDF）和計費網(wǎng)關(guān)函數(shù)（charging gateway function，CGF）。這些函數(shù)可以構(gòu)造、關(guān)聯(lián)和格式化與計費事件相關(guān)的信息，并將這些信息傳遞給賬單系統(tǒng)。Amdocs Service Mediation Manager是Amdocs IMS計費解決方案的一部分，它經(jīng)過改進(jìn)后符合3GPP標(biāo)準(zhǔn)并且其本身可以提供CDF和CGF功能。

　　如今，服務(wù)提供商開始爭先實現(xiàn)IMS架構(gòu)并提供越來越多的復(fù)雜服務(wù)，與此同時，他們也不得不開始面對各種問題：如收益率、定價、資本回報率和服務(wù)質(zhì)量等等。Amdocs使用了一套橫向的、統(tǒng)一的、模塊化的IMS就緒計費產(chǎn)品，實現(xiàn)了一種完善的IMS計費方式，并且很好地解決了上述問題。如Ericpol和BEA的IOT測試所示，Amdocs計費解決方案具有以下優(yōu)點：

• 正確地將任何業(yè)務(wù)線實時地聚合在一起
• 復(fù)雜IMS服務(wù)和產(chǎn)品快速投放市場
• 靈活地提供創(chuàng)新和多合一的服務(wù)
• 聚合調(diào)解（Converged mediation）
• 嚴(yán)格遵從IMS標(biāo)準(zhǔn)

　　下載

• 下載 Chargi計費示例——使用Ro和Rf接口構(gòu)建示例計費應(yīng)用程序的源代碼演示。
• Ericpol和Amdocs之間的用例——IOT中使用的示例用例。

結(jié)束語

　　已經(jīng)證實，Diameter成功克服了RADIUS的局限。它如今已成為IMS標(biāo)準(zhǔn)的一部分?；贗P和電話技術(shù)的新服務(wù)的開發(fā)現(xiàn)正在迅速發(fā)展，每一項服務(wù)都需要計費功能。因此，基于Diameter計費的普及指日可待。

　　通過閱讀本文，您應(yīng)該了解了Ro和Rf接口的基本概念，并知道如何使用BEA WebLogic SIP Server處理它們?，F(xiàn)在，您已經(jīng)可以借助所學(xué)的知識著手開發(fā)自己的應(yīng)用程序

致謝

　　作者感謝 Rafi Kretchmer，Amdocs的Revenue Management Product & Solutions Marketing部門的產(chǎn)品營銷總監(jiān)。Rafi負(fù)責(zé)為Amdocs的產(chǎn)品收益管理制訂IMS業(yè)務(wù)戰(zhàn)略，包括行業(yè)領(lǐng)先的Amdocs Billing產(chǎn)品組合。

參考資料

• WLSS 3.0 Doc——官方WebLogic Sip Server 3.0文檔
• WLSS 3.0 Doc——Diameter配置
• WLSS 3.0 Doc——配置和使用Rf應(yīng)用程序
• WLSS 3.0 Doc——配置和使用Ro應(yīng)用程序
• WLSS 3.0 Doc——群集環(huán)境中的Diameter處理
• 3GPP TS 32.240——計費架構(gòu)和基本原理
• 3GPP TS 32.260——IMS計費
• RFC 3588——Diameter基本協(xié)議
• RFC 4006——Diameter Credit-Control應(yīng)用程序
• Wireshark——開源的網(wǎng)絡(luò)協(xié)議分析程序
• WLSS 3.0 Doc——Dev2Dev網(wǎng)站上的WebLogic Communications Platform開發(fā)人員中心

術(shù)語表

3GPP - 3rd Generation Partnership Project
AAA - Authentication, Authorization, and Accounting
ABMF - Account Balance Management Function
ACA - Accounting Answer
ACR - Accounting Request
API - Application Programming Interface
AS - Application Server
AVP - Attribute-Value Pair
BGCF - Breakout Gateway Control Function
CCA - Credit-Control Answer
CCR - Credit-Control Request
CDF - Charging Data Function
CDR - Charging Data Record
CGF - Charging Gateway Function
CSCF - Call Session Control Function
CTF - Charging Trigger Function
DCC - Diameter Credit-Control application
GGSN - Gateway GPRS Support Node
GPRS - General Packet Radio Service
HSS - Home Subscriber Server
HTTP - HyperText Transfer Protocol
ICID - IMS Charging Identifier
I-CSCF - Interrogating-CSCF
IMS - IP Multimedia Subsystem
IMS-GWF - IMS Gateway Function
MGCF - Media Gateway Control Function
MRFC - Media Resource Function Controller
OCF - Online Charging Function
OCS - Online Charging System
P-CSCF - Proxy-CSCF
RF - Rating Function
RFC - Request For Comments
S-CSCF - Serving-CSCF
SGSN - Serving GPRS Support Node
SIP - Session Initiation Protocol
WLSS - BEA WebLogic SIP Server

原文出處：http://dev2dev.bea.com/pub/a/2007/07/IMC-charging-architecture.html

作者簡介
Stefano Gioia	Stefano Gioia 是EMEA的BEA WebLogic Sip Server 技術(shù)專家。他把主要精力都放在讓IMS及其工作人員和合作伙伴能夠跨越歐洲、中東和非洲的努力上。
	Tomasz Radziszewski是Ericpol Telecom的軟件研發(fā)工作師。