用于實現通信禁止服務的方法和裝置的制造方法
【技術領域】
[0001]本發明涉及實現IP多媒體子系統情境中的通信禁止服務的方法和裝置。
【背景技術】
[0002]IP多媒體子系統aMS)是由第三代合作伙伴關系項目(3GPP)定義的技術，以在移動通信網絡上提供IP多媒體服務。3GPP規范TS 23.002中一般性地描述了 MS的構架和一般特征，TS 23.228中更具體地進行了描述。通過服務集成和交互，IMS提供重要特征以豐富終端用戶的人與人之間的通信體驗。IMS實現了基于IP的網絡上全新和豐富的人與人(客戶端到客戶端)以及人與內容(客戶端到服務器)通信。IMS利用會話發起協議(SIP)建立和控制用戶終端(或者用戶終端和應用服務器)之間的呼叫或會話。由SIP信令承載的會話描述協議(SDP)被用于描述和協商會話的媒體組件。當SIP被作為用戶到用戶協議創建時，IMS允許運營商和服務提供商控制用戶接入服務以及相應地向用戶收費。其他協議如實時傳輸協議和實時傳輸控制協議(RTP/RTCP)被用于媒體傳輸和控制。
[0003]頂S邏輯上被部署進所謂的“核心網絡”層和所謂的“服務層”中。核心網絡層是由功能性實體(下文簡要描述)實現的。服務層主要包括“應用服務器”，其被布置用于向用戶終端(下文稱為用戶設備(UE))提供服務。這些應用服務器經由MS被連接，以及/或被布置為通過執行特定的基于服務的邏輯在服務提供中進行中介，例如在某些情況下轉移呼入多媒體會話。
[0004]當前的ms標準提供用于通信禁止(CB)的服務，以使得網絡能夠控制訂戶接入服務。3GPP TS 24.611中描述了頂S中3GPP標準化的CB服務的當前狀態。這個標準遵從并擴展了用于TS24.088中考慮的電路交換(CS)和分組交換(PS)網絡中呼叫限制補充服務的基本原則。
[0005]TS 24.611特別描述了在會話初始請求滿足CB服務訂戶的簡檔中規定的CB服務需求的事件中，頂S AS對該請求執行CB服務的動作。根據條件和動作的規則，定義了這些服務需求，由同一規范還進一步參考RFC 4745定義了這些規則。尤其是，TS 24.611定義了呼入通信禁止(ICB)服務以及呼出通信禁止(0CB)，該ICB服務是代表終止用戶拒絕滿足某些規定的或配置的條件的呼入通信的服務，該0CB代表始發用戶拒絕滿足某些規定的或配置的條件的呼出通信的服務。圖1圖示了該功能構架，假設在兩個訂戶UE-A和UE-B之間建立會話，UE-A為始發方，UE-B為終止方。
[0006]現有規范除了會話發起不包括任何(與ICB或0CB相關的)對用戶場景的規定。當前的方法可能為訂戶在某些情況下規避CB服務創造了機會。
【發明內容】
[0007]本發明的一個目的是克服或者至少減輕上面討論的CB相關問題。這一目的和其他目的的實現是通過引起MS AS解析與進行中的頂S會話或早期會話階段中的頂S會話有關的SIP消息，以標識和控制針對該會話的媒體變化和添加。
[0008]根據本發明的第一方面，提供一種在IP多媒體子系統IMS網絡內針對進行中的IMS會話或早期會話階段中的ms會話實現通信禁止CB服務的方法。該方法包括，在ms網絡內的應用服務器AS處，解析與會話相關的SIP消息，以檢測用以向會話添加一個或多個媒體流的嘗試。CB服務規則被應用以確定媒體流被添加的允許性。如果不允許媒體流被添加，則采取動作以阻止媒體流的添加，否則允許媒體流添加進行。
[0009]本發明的實施例可被用于針對欺詐和不恰當的收費，保護訂戶和/或網絡運營商。
[0010]在媒體流不被允許的事件中可采取的動作可以包括在AS處拒絕請求。
[0011]在所述消息是與早期會話階段的頂S會話相關的SIP PRACK請求的情況下，該動作可包括在上游方向從SIP PRACK請求中移除未被允許的媒體提議(offer)，轉發該請求到其目的用戶代理，以及在下游方向在響應中拒絕該媒體流。
[0012]SIP消息可以是可靠的SIP響應，所述動作可包括在轉發前在SIP響應中禁止個體的未被允許的媒體流。
[0013]CB服務規則可被應用于包含會話描述協議SDP提議的SIP消息。
[0014]CB服務規則可以是在會話發起期間所應用的相同的規則。
[0015]該方法可包括僅應用至少包含一個媒體條件的那些CB服務規則。
[0016]該方法可包括存儲來自發起進行中的IMS會話的請求和任何相關響應的會話參數，以及隨后在應用CB服務規則以確定媒體流被添加的允許性時，使用這些會話參數。
[0017]根據本發明的第二個方面，提供一種用于在IP多媒體子系統IMS網絡內針對進行中的MS會話或早期會話階段中的ms會話實現通信禁止CB服務的應用服務器AS。該裝置包括SIP消息解析器，用于解析與會話相關的SIP消息，以檢測用以向該會話添加一個或多個媒體流的嘗試；以及策略單元，用于應用CB服務規則以確定媒體流被添加的允許性。該裝置進一步包括策略實施單元，被配置為如果不允許媒體流被添加，則采取動作以阻止媒體流的添加，否則允許媒體流添加進行。
[0018]策略單元可被配置為僅應用至少包含一個媒體條件的那些CB服務規則。
[0019]策略實施單元可被配置為采取以下動作中的一個:
[0020]-拒絕包含未被允許請求的SIP消息；
[0021]-禁用未被允許的媒體流，該未被允許的媒體流在可靠響應中所接收的媒體提議中被添加或修改；
[0022]-完全移除在SIPPRACK中包含未被允許的媒體流的媒體提議。
[0023]所述應用服務器可進一步包括數據記錄器，用于存儲來自發起進行中的ms會話的請求和任何相關響應的會話參數；所述策略單元被配置為在應用CB服務規則以確定媒體流被添加的允許性時，使用這些會話參數。
【附圖說明】
[0024]圖1示出了在頂S內實現的始發和終止通信禁止服務的示意圖；
[0025]圖2示出了在早期會話階段或已建立的會話階段與通信會話更新相關的信令，使用 SIP UPDATE ；
[0026]圖3示出了在早期會話階段或已建立的會話階段與通信會話更新相關的信令，使用 SIP PRACK ；
[0027]圖4示出了在早期會話階段或已建立的會話階段與通信會話更新相關的信令，其中用戶代理中的一個在會話內“可靠的響應”中包括媒體描述，這個描述構成媒體提議；
[0028]圖5是示出了在早期會話階段或已建立的會話階段中針對通信會話更新的CB服務的實現的流程圖；以及
[0029]圖6示出了與圖5相一致的被配置為實現CB服務的MS應用服務器的示意圖。
【具體實施方式】
[0030]如上面已經考慮的，在IP多媒體子系統情境中，3GPP TS 24.611和TS24.088描述了通信禁止(CB)服務，其包括呼出CB(OCB)和呼入CB (ICB)。然而，現有技術關注的唯一的用戶場景是會話發起，即在IMS會話的發起期間CB服務的實現。認識到的是，通過發生在會話過程中(以及在早期會話階段中)以及來自始發或終止用戶代理(UA)始發的會話更新，繞過來自CB服務的呼叫限制是可能的。這尤其與操縱會話中所使用的媒體的會話更新相關。其結果，除了別的以外，包括向訂戶提議的高級服務的威脅，例如，用戶可能建立語音電話并為語音電話付費，隨后在呼叫中添加“免費的”視頻，而可能的是用戶為無法使用CB進行阻止的服務受到過多收費。進一步考慮后一種問題，當例如公司負責支付電話賬單，不允許其員工撥打視頻電話(因為其導致額外收費或由于安全原因)時，這可能是有問題的。同樣還可能產生問題的是，當私人訂戶在漫游時，由于額外收費，希望阻止撥打/接收視頻電話或被升級為視頻電話(在某些國家接收電話也會被收費)，或者當他或她希望避免在高峰時間使用某些服務時。
[0031]通過兩個主要操作，通信會話更新可以發生在早期會話階段或已建立的會話階段。首先，為了更新會話或改變會話參數，參與的用戶代理(UA)中的一個能夠在會話內生成SIP請求。這可以例如通過如圖2中所示的SIP INVITE (或使用SIP UPDATE代替INVITE)或使用如圖3中的SIP PRACK完成。在圖中，多媒體電話應用服務器(MTAS)被配置為代表UE-A實CB服務。MTAS是MMTel AS的具體實現。第二種方式涉及用戶代理之一在會話內的“可靠響應”中包括媒體描述，該媒體描述構成媒體提議。在圖4中示出了這種情況。
[0032]提出解決這個問題的方案是利用現有CB服務的擴展而非為此目的專門開發新服務。這提供了兩個優點，即:
[0033](1)將新功能包含進現有具有CB的解決方案(例如MMTel模擬服務)相對直接明了 ；
[0034](2)擴展的服務能夠重復利用已有的(標準化的)用于禁止會話起始的通信規則，盡管有一些適應性的修改。歸因于如下原因，這尤其有吸引力，該原因是可望實現的是適用于會話發起的規則應該在整個會話存在期被實施，即不太可能要求在會話發起期間有第一組規則并且針對會話存在期的其他時間有不同的第二組規則。
[0035]為了確定具有受限媒體實施(RME)的CB服務是否應該禁止會話更新，用于命令會話更新的消息必須在相關AS處例如MTAS處被調查。重要的是，RME必須僅在由媒體提議添加或修改的媒體流上被激活。如