專利名稱:一種ims即時消息群發(fā)的方法及設備的制作方法
技術領域:
本發(fā)明屬于通信領域,特別涉及一種IMS即時消息群發(fā)的方法及設備。
背景技術:
IMS (IP Multimedia Subsystem: IP多々某體子系統(tǒng))是3GPP ( 3rd Generation Partnership Project,第三代移動通信標準化伙伴項目)標準定義的一個IP多J 某 體子系統(tǒng),是3G (3rd Generation)移動網實現(xiàn)分組話音和分組數據,提供統(tǒng) 一的多i某體業(yè)務和應用的目標網絡。
IMS采用IP分組域作為其控制信令和媒體傳輸的承載通道,采用SIP (Session Initiation Protocol:會話發(fā)起協(xié)議)協(xié)議作為呼叫控制信令,實現(xiàn)了 業(yè)務管理、會話控制及承載接入的三者分離。
目前,其它的國際標準組織如ITU-T( International Telecommunication Union -Telecommunication Standardization Sector,國際電信聯(lián)盟-電信標準部)、ETSI (European Telecommunications Standards Institute,區(qū)欠洲電4言才示〉隹十辦會)等也采 用IMS作為其定義的下一代網絡的核心網絡。
IMS即時消息業(yè)務是允許一個網絡實體向另一個網絡實體發(fā)送消息。IMS 即時消息的發(fā)送內容可以是文本、多媒體消息及其他MIME ( Multipurpose Internet Mail Extensions:多用途互聯(lián)網郵件擴展)類型的多種格式的內容,包 括了終端到終端、終端到增值應用、增值應用到終端之間的即時消息通信。
IP多播(也稱多址廣播或組播,下面簡稱多播)技術實現(xiàn)了一臺或多臺主 機(多播源)發(fā)送單一數據包到多臺主機。多播作為一點對多點的通信,是節(jié) 省網絡帶寬的有效方法之一。在網絡音頻/視頻廣播的應用中,當需要將一個節(jié)點的信號傳送到多個節(jié)點時,無論是采用重復點對點通信方式,還是采用廣播 方式,都會嚴重浪費網絡帶寬,采用多播才是較好的選擇。多播能使一個或多 個多播源只把數據包發(fā)送給特定的多播組,而只有加入該多播組的主機才能接 收到數據包。
發(fā)明人在實施現(xiàn)有技術的過程中發(fā)現(xiàn)現(xiàn)有IMS即時消息業(yè)務中,實現(xiàn)多 人相互發(fā)送消息主要是通過會議群發(fā)的方式,即只有會議的參與者才能發(fā)送和 接收消息,且參與會議的人數越多,會議服務器性能需求就越高,占用的資源 越多,成本增加。
發(fā)明內容
本發(fā)明實施例提供了 一種IMS即時消息群發(fā)的方法及設備,可以用于解決 現(xiàn)有技術中消息群發(fā)導致的占用資源過高、浪費網絡帶寬的問題。
本發(fā)明實施例提供了 一種IMS即時消息群發(fā)的方法,包括
多播組消息群發(fā)實體接收消息發(fā)送實體發(fā)送的IMS即時消息;所述多播組 消息群發(fā)實體與所述消息發(fā)送實體屬于同 一多播組;
所述多播組消息群發(fā)實體將所述IMS即時消息發(fā)送給所述多播組內的所 有消息接收實體。
本發(fā)明實施例還4是供一種多播組消息群發(fā)實體,包括
消息服務單元,所述消息服務單元用于接收消息發(fā)送實體發(fā)送的IMS即時 消息;所述多播組消息群發(fā)實體與所述消息發(fā)送實體位于同 一多播組內;
多播d泉體傳輸單元,所述多播媒體傳輸單元用于將所述IMS即時消息發(fā)送 給所述多播組內的所有消息接收實體。
本發(fā)明實施例利用多播實現(xiàn)群發(fā)消息,可以不關心多播組內有哪些用戶, 每個用戶的身份標識是什么,需要接收消息的用戶只要加入多播組即可,就可 以接收到此組內的所有數據。多播組內的所有用戶共享數據流,可以減輕服務 器的負載。
圖1為本發(fā)明才是供的第一實施例的系統(tǒng)結構示意圖; 圖2為本發(fā)明4是供的第二實施例的方法流程示意圖; 圖3為本發(fā)明提供的第三實施例的方法流程示意圖; 圖4為本發(fā)明提供的第四實施例的方法流程示意圖; 圖5為本發(fā)明才是供的第五實施例的方法流程示意圖; 圖6為本發(fā)明4是供的第六實施例的方法流程示意圖; 圖7為本發(fā)明提供的多播組消息群發(fā)實體結構示意圖。
具體實施例方式
在現(xiàn)有技術中,實現(xiàn)IMS即時消息業(yè)務時,用戶在發(fā)送消息時需要知道消 息接收方的身份標識或者會議標識(通過會議服務器轉發(fā)給會議參與者,而會 議服務器需要知道每個會議參與者的身份標識)?,F(xiàn)有技術通過會議群發(fā)的方 式實現(xiàn)多人相互發(fā)送消息即只有會議的參與者才能發(fā)送和接收消息,且參與 會議的人數越多,會議服務器性能需求就越高,占用的資源越多,成本增加。
本發(fā)明實施例利用多播實現(xiàn)群發(fā)消息,可以不關心多播組內有哪些用戶, 每個用戶的身份標識是什么,需要接收消息的用戶只要加入多播組即可,就可 以接收到此組內的所有數據。多播組內的所有用戶共享數據流,可以減輕服務 器的負載。本發(fā)明實施例利用多播群發(fā)消息的方可以在如下場景中應用用戶 加入一個多播節(jié)目,希望能夠對當前節(jié)目發(fā)表一些評論消息,并希望自己的評 論內容能夠被正在看當前節(jié)目的所有用戶接收到,而不需要知道每個用戶的身 份標識,也不需要關心有多少用戶要接收評論消息;用戶希望能夠加入一場直 播球賽的聊天室,與聊天室內的所有用戶聊天;
如圖1所示為本發(fā)明第一實施例^是供的系統(tǒng)示意圖。該圖中,各個網絡實體的功能描述如下
多播組消息群發(fā)實體101,用于接收消息發(fā)送實體102發(fā)送的IMS即時消 息,并通過多播方式群發(fā)給消息接收實體103;
多播組消息群發(fā)實體101與消息發(fā)送實體102之間的El接口協(xié)議可以采 用SIP、 HTTP、 RTP、 MSRP、其他標準或私有協(xié)議;
多播組消息群發(fā)實體101與消息接收實體103之間的E2接口協(xié)議可以有 采用RTP、 IGMP、 MSRP、其他標準或私有協(xié)議;
消息發(fā)送實體102,用于將用戶輸入的或來自網絡的IMS即時消息發(fā)送給 多播組消息群發(fā)實體101;消息發(fā)送實體102可以設置在用戶終端(如IPTV 終端、IMS終端等)或網絡實體(如IPTV業(yè)務服務器)上。
消息接收實體103,用于從多播組消息群發(fā)實體101接收IMS即時消息。 消息接收實體103可以設置在用戶終端(如IPTV終端、IMS終端等)上。
如圖2所示,為本發(fā)明第二實施例提供的利用多播實現(xiàn)消息群發(fā)的方法流
程示意圖。本實施例的方法可以包括
步驟201:消息發(fā)送實體發(fā)送IMS即時消息給多播組消息群發(fā)實體; 在步驟201中,消息發(fā)送實體首先獲取多播組消息群發(fā)實體的地址;具體
的,消息發(fā)送實體可以采用如下方式之一發(fā)送消息給多播組消息發(fā)送實體.-方式1:通過信令面將消息發(fā)送至多播組消息群發(fā)實體; 采用該方式,消息發(fā)送實體可以通過在SIPMESSAGE、 HTTP POST中攜
帶消息內容發(fā)送給多播組消息群發(fā)實體。使用該方式,在消息發(fā)送實體發(fā)送的
消息量較少時,該方式占用資源少,實現(xiàn)簡單。
方式2:通過i某體通道將消息發(fā)送至多播組消息群發(fā)實體;
采用該方式實現(xiàn)過程可以是消息發(fā)送實體獲取多播組消息群發(fā)實體地
址;消息發(fā)送實體根據多播組消息群發(fā)實體地址發(fā)起到多播組消息群發(fā)實體的
會話建立過程,并通過會話建立完成MSRP (Message Session Relay Protocol:
7消息會話中繼協(xié)議)媒體通道的協(xié)商,消息發(fā)送實體通過MSRP媒體通道將消 息發(fā)送至多播組消息群發(fā)實體。當消息發(fā)送實體要連續(xù)發(fā)送多條消息時,采用 該方式可以避免大量信令消息在網絡中傳遞可能引起網絡擁塞的問題。
步驟202:多播組消息群發(fā)實體群發(fā)消息給附著在多播組內的消息接收實 體,可以采用如下方式之一實現(xiàn)
方式1:通過多播傳輸通道將IMS即時消息轉發(fā)給多播組內的消息接收實
體;
采用該方式,多播組消息群發(fā)實體接收消息發(fā)送實體發(fā)送的IMS即時消 息,可以選擇將接收到的IMS即時消息封裝在多播媒體流中,與多播媒體流一 起通過多播方式轉發(fā)IMS即時消息給加入多播組的所有消息接收實體;當然也 可以不對接收到的IMS即時消息進行封裝,直接通過多播方式轉發(fā)IMS即時 消息給加入多播組的所有消息接收實體,即不與媒體流一起發(fā)送,而是獨立傳 輸。使用這種方式可以利用現(xiàn)有多播資源通道,無需重新分配資源。
方式2:利用已經建立的MSRP媒體通道轉發(fā)消息給多播組內的消息接收 實體;
采用該方式,消息接收實體在加入多播組時,利用多播會話協(xié)商建立了與 多播組消息群發(fā)實體之間的MSRP媒體通道,多播組消息群發(fā)實體通過已經建 立的MSRP通道發(fā)送消息給多播組內的所有消息接收實體。
比如在IPTV直播業(yè)務中,消息接收實體在發(fā)起直播會話建立過程時,發(fā) 送SIP INVITE邀請消息,INVITE請求被路由到多播組消息群發(fā)實體,多播組 消息群發(fā)實體獲取直播節(jié)目所關聯(lián)的消息業(yè)務信息,發(fā)起到多播媒體傳輸單元 的會話請求SIP INVITE,通過會話協(xié)商建立消息接收實體與多播組消息群發(fā)實 體之間的MSRP媒體通道。需要說明的是,上述消息接收實體發(fā)送的請求消息 還可以是SIP re-INVITE,比如消息接收實體是利用原有會話控制直接加入多 播組,則消息接收實體在加入多播組后發(fā)送的就是SIP re-INVITE會話修改請 求,觸發(fā)消息接收實體發(fā)起會話修改的條件可以是加入多播組后根據從媒體流中獲取的消息業(yè)務信息立即觸發(fā),還可以是在用戶啟動消息輸入人機交互界面 時觸發(fā)。該方式可以減少網絡間的控制信令傳遞。
如圖3所示,為本發(fā)明第三實施例提供的IMS即時消息群發(fā)流程示意圖。 本實施例中,IPTV用戶加入直播節(jié)目1, IPTV用戶通過IPTV終端上的鏈接 或按鍵啟動參與評論的人機交互界面,輸入相應評論內容參與評論,IPTV終 端從直播節(jié)目々某體流中獲取評論內容,并以滾動條方式顯示評論內容在直播節(jié) 目下方。該實施例中,多播邊緣節(jié)點ECF/EFF ( Elementary Control Functions/Elementary Forwarding Functions )、 多4番內容源BC-MF ( Broad Cast-Media Function )作為多播組消息群發(fā)實體,IPTV終端B為消息發(fā)送實體,IPTV 終端A為消息接收實體。本實施例方法包括
步驟301: IPTV終端B加入直播節(jié)目多播組,從多播邊緣節(jié)點ECF/EFF 接收直播節(jié)目媒體流;
步驟302: IPTV終端A加入直播節(jié)目多播組,從多播邊緣節(jié)點ECF/EFF 接收直播節(jié)目媒體流;
步驟303: IPTV終端A和IPTV終端B從J 某體流中獲取直播節(jié)目關聯(lián)的 評論業(yè)務描述信息,獲取評論信息接收地址BC-MF的地址,保存評論業(yè)務描 述信息在終端,可以鏈接形式顯示評論業(yè)務信息;
步驟304: IPTV終端B通過鏈接或某個按4定啟動評論信息輸入界面,輸 入評論內容;
步驟305: IPTV終端B發(fā)送攜帶評論內容的SIP MESSAGE消息給評論信 息接收地址BC-MF;
步驟306: BC-MF接收評論消息,可以選擇將評論消息封裝在直播節(jié)目媒 體流中,也可以選擇不對評論消息進行封裝;
步驟307: BC-MF發(fā)送評論消息到多播邊緣節(jié)點ECF/EFF,評論消息可以 是隨直播節(jié)目媒體流一起傳輸到多播邊緣節(jié)點,還可以是單獨傳輸到多播邊緣節(jié)點;
步驟308 ~ 309:所有加入多播組的IPTV終端(本實施例中包括IPTV終 端A和IPTV終端B )通過已經建立的多播媒體通道從多播邊緣節(jié)點接收評論 消息和直播節(jié)目媒體流。
如圖4所示,為本發(fā)明第四實施例提供的IMS即時消息群發(fā)流程示意圖。 本實施例中,IPTV用戶加入一個提供聊天室業(yè)務的直"f番節(jié)目2的頻道,通過 IPTV終端上的聊天室鏈接選擇一個聊天室加入該頻道,建立與聊天室之間的 會話,發(fā)送聊天內容給聊天室內所有用戶。本實施例中,BC-MF作為多播組 消息群發(fā)實體,IPTV終端B為消息發(fā)送實體,消息服務器作為即時消息轉發(fā) 實體,IPTV終端A為消息接收實體。本實施例方法包括
步驟401: IPTV終端B加入直播節(jié)目2的頻道的多播組,從多播邊緣節(jié) 點ECF/EFF接收直播節(jié)目媒體流;
步驟402: IPTV終端A加入直播節(jié)目2的頻道的多播組,從多播邊緣節(jié) 點ECF/EFF接收直播節(jié)目媒體流;
步驟403:所有加入直播節(jié)目2的頻道多播組的IPTV終端(本實施例包 括IPTV終端A和IPTV終端B )從媒體流中獲取直播節(jié)目關聯(lián)的聊天室信息, 獲取消息月良務器i也i止,比^口 chatroom@example.com;
步驟404: IPTV終端B選4奪加入聊天室,啟動聊天室界面,輸入聊天內
容;
步驟405: IPTV終端B發(fā)送聊天消息給消息服務器,其Request-URI就是 消息服務器地址;
步驟406:消息服務器將接收到的聊天信息發(fā)送到BC-MF;
步驟407: BC-MF接收聊天消息并封裝在直播球賽媒體流中;
步驟408: BC-MF復制包含聊天消息的媒體流給多播組ECF/EFF;
步驟409 -410:所有加入多播組的IPTV終端(本實施例包括IPTV終端A和IPTV終端B )通過已經建立的多播媒體通道接收包含聊天消息的直播節(jié) 目i某體流;
步驟411: IPTV終端B識別直播節(jié)目媒體流中的聊天信息,接收屬于自 己的聊天信息;
步驟412: IPTV終端A識別直播節(jié)目媒體流中的聊天消息,由于IPTV終 端A沒有加入聊天室,因此丟棄不屬于自己的聊天信息。
如圖5所示,為本發(fā)明第五實施例提供的IMS即時消息群發(fā)流程示意圖。 本實施例中,IPTV用戶加入直播節(jié)目3,通過終端上的鏈接或按4建啟動參與評 論的人機交互界面,輸入相應評論內容參與評論,評論信息以滾動條方式顯示 在直播節(jié)目下方。所用方法是所有加入直播節(jié)目的IPTV終端,利用直播會話 協(xié)商建立與直播媒體功能BC-MF之間的MSRP々某體通道,并通過已經建立的 MSRP通道接收評論信息。本實施例中,消息服務器作為即時消息轉發(fā)實體, BC-MF作為多播組消息群發(fā)實體;IPTV終端B為消息發(fā)送實體,同時也代表 所有加入直播節(jié)目的IPTV終端,IPTV終端A代表消息接收實體。本實施例 方法包括
步驟501: IPTV終端B選擇直播節(jié)目3;
步驟502: IPTV終端B發(fā)送直播節(jié)目請求到Core IMS (即IMS核心網), 該直播節(jié)目請求可以是SIP INVITE邀請消息;
步驟503:直播節(jié)目請求被Core IMS路由到直播業(yè)務控制功能BC-SCF;
步驟504: BC-SCF根據直播節(jié)目請求中攜帶的直播節(jié)目標識,獲取直播 節(jié)目所關聯(lián)的評論業(yè)務信息,并選擇BC-MF;
步驟505 ~ 506: BC-SCF發(fā)送SIP INVITE請求到BC-MF;
步驟507 ~ 510: BC-MF返回直播節(jié)目請求響應200 OK給IPTV終端B;
步驟511:建立IPTV終端B與BC-MF之間的MSRP媒體通道;
需要說明的是,上述步驟501~511實現(xiàn)了每個加入直播節(jié)目的IPTV終端都通過直播會話協(xié)商建立了 MSRP媒體通道。
步驟512 513: IPTV終端接收直播節(jié)目媒體流,從々某體流中獲取直播節(jié)目 所關聯(lián)的消息服務器地址;
步驟514: IPTV終端B啟動評論業(yè)務消息輸入界面,輸入評論內容;
步驟515: IPTV終端B發(fā)送評論消息給消息服務器;
步驟516:消息服務器將接收到的消息轉發(fā)給BC-MF;
步驟517 ~ 519: BC-MF通過已經建立的MSRP通道群發(fā)消息給多播組內 的所有IPTV終端,IPTV終端接收消息并顯示消息內容。
需要說明的是,IPTV終端在加入直播節(jié)目時,可以不需要重新進行會話 建立,直接加入直播節(jié)目多播組。此時IPTV終端根據從媒體流或EPG中獲取 的關聯(lián)消息業(yè)務描述信息,可以發(fā)起SIP re-INVITE會話修改過程,通過會話 修改協(xié)商建立MSRP纟某體通道。
如圖6所示,為本發(fā)明第六實施例提供的IMS即時消息群發(fā)流程示意圖。 本實施例中,IPTV用戶加入直播節(jié)目,通過終端上的鏈接或按一睫啟動參與評 論的人機交互界面,輸入相應評論內容參與評論,評論信息以滾動條方式顯示 在直播節(jié)目下方。本實施例中,所有加入直播節(jié)目的IPTV終端利用直播會話 協(xié)商建立與直插d泉體功能BC-MF之間的MSRP々某體通道,并通過已經建立的 MSRP通道發(fā)送和接收評論信息;本實施例中,BC-MF作為多播組消息群發(fā)實 體,IPTV終端B為消息發(fā)送實體,并同時代表所有加入直播節(jié)目的IPTV終 端;IPTV終端A為消息接收實體。
步驟601: IPTV終端B選擇直播節(jié)目;
步驟602: IPTV終端B發(fā)送直播節(jié)目請求到Core IMS,該直播節(jié)目請求 可以是SIP INVITE邀請消息;
步驟603: INVITE請求被Core IMS路由到直播業(yè)務控制功能BC-SCF; 步驟604: BC-SCF根據直播節(jié)目請求的直播節(jié)目標識,獲取直播節(jié)目所關聯(lián)的評論業(yè)務信息,并選擇BC-MF;
步驟605 ~ 606: BC-SCF發(fā)送SIP INVITE請求到BC-MF;
步驟607 ~ 610: BC-MF返回直播節(jié)目請求響應200 OK給IPTV終端B;
步驟611:建立IPTV終端B與BC-MF之間的MSRP i某體通道;
需要說明的是,上述步驟601-611實現(xiàn)了每個加入直播節(jié)目的IPTV終端 都通過直播會話協(xié)商建立了 MSRP媒體通道。
步驟612: IPTV終端B接收直播節(jié)目媒體流;
步驟613: IPTV終端B啟動評論業(yè)務消息輸入界面,輸入評論內容;
步驟614: IPTV終端B通過已經建立的MSRP通道發(fā)送攜帶評論內容的 MSRP SEND消息給BC-MF;
步驟615 ~ 617: BC-MF將評論消息再通過所有已經建立的MSRP通道群 發(fā)消息給多播組內的所有IPTV終端,IPTV終端接收消息并顯示消息內容。
需要說明的是,IPTV終端在加入直播節(jié)目時,可以不需要重新進行會話 建立,直接加入直播節(jié)目多播組。此時IPTV終端根據從媒體流或EPG中獲取 的關聯(lián)消息業(yè)務描述信息,可以發(fā)起SIPre-INVITE會話修改過程,通過會話 修改協(xié)商建立MSRP媒體通道。
本發(fā)明第七實施例提供的多播組消息群發(fā)實體,其結構如圖7所示,包括 消息服務單元,用于接收消息發(fā)送實體發(fā)送的IMS即時消息;該多播組消 息群發(fā)實體與所述消息發(fā)送實體位于同一多播組內;多播J 某體傳輸單元,用于
將接收到的IMS即時消息發(fā)送給所述多播組內的所有消息接收實體。
具體的,多播媒體傳輸單元發(fā)送IMS即時消息給多播組內所有消息接收實
體的方式可以采用如下之一
方式1:通過多播傳輸通道將IMS即時消息轉發(fā)給多播組內的消息接收實
體;
采用該方式,多播組消息群發(fā)實體接收消息發(fā)送實體發(fā)送的IMS即時消息,可以選擇將接收到的IMS即時消息封裝在多播媒體流中,與多播媒體流一
起通過多播方式轉發(fā)IMS即時消息給加入多播組的所有消息接收實體;當然也 可以不對接收到的IMS即時消息進行封裝,直接通過多播方式轉發(fā)IMS即時 消息給加入多播組的所有消息接收實體,即不與媒體流一起發(fā)送,而是獨立傳 輸。使用這種方式可以利用現(xiàn)有多播資源通道,無需重新分配資源。
在具體的實現(xiàn)過程中,多播媒體傳輸單元通過多播傳輸通道將IMS即時消 息發(fā)送給多播組內的所有消息接收實體可以通過多播路由器和多播邊緣節(jié)點 ECF/EFF配合實現(xiàn)。具體的實現(xiàn)方法和應用可以參見具體實施例三、具體實施 例四、圖3和圖4。
方式2:利用多播會話建立的MSRP媒體通道發(fā)送頂S即時消息給多播組內的 消息接收實體;
采用該方式,多播組消息群發(fā)實體還可以進一步包括MSRP媒體通道建立 單元。MSRP媒體通道建立單元用于在消息接收實體加入多播組過程中通過多 播會話協(xié)商建立與消息接收實體之間的MSRP媒體通道。多播媒體傳輸單元通 過該MSRP媒體通道將IMS即時消息發(fā)送給多播組內的所有消息接收實體。 具體的,如在IPTV直播業(yè)務中,消息接收實體在發(fā)起直播會話建立過程時, 發(fā)送SIP INVITE邀請消息,INVITE請求被路由到多播業(yè)務控制單元,多播業(yè) 務控制單元獲取直播節(jié)目所關聯(lián)的消息業(yè)務信息,發(fā)起到多播媒體傳輸單元的 會話請求SIP INVITE,通過會話協(xié)商建立消息接收實體與多播J 某體傳輸單元之 間的MSRP媒體通道。具體的實現(xiàn)方法和應用可以參見具體實施例五、具體實 施例六、圖5和圖6。
本發(fā)明實施例中,多播組消息群發(fā)實體可以接收多播組內任意實體發(fā)送的 IMS即時消息,并發(fā)送給加入多播組的所有實體;在TISPAN的基于IMS的IPTV 架構中,其可以為多播內容源BC-MF。
本領域普通技術人員可以理解實現(xiàn)上述實施例方法中的全部或部分步驟是可以通過程序來指令相關的硬件完成,所述的程序可以存儲于一種計算機可 讀存儲介質中。上述提到的存儲介質可以是只讀存儲器,磁盤或光盤等。
顯然,本領域的技術人員可以對本發(fā)明進行各種改動和變型而不脫離本發(fā) 明的精神和范圍。這樣,倘若本發(fā)明的這些修改和變型屬于本發(fā)明權利要求及 其等同技術的范圍之內,則本發(fā)明也意圖包含這些改動和變型在內。
權利要求
1、一種IMS即時消息群發(fā)的方法,其特征在于,所述方法包括多播組消息群發(fā)實體接收消息發(fā)送實體發(fā)送的IMS即時消息;所述多播組消息群發(fā)實體與所述消息發(fā)送實體屬于同一多播組;所述多播組消息群發(fā)實體將所述IMS即時消息發(fā)送給所述多播組內的所有消息接收實體。
2、 如權利要求1所述的方法,其特征在于,所述多播組消息群發(fā)實體接 收消息發(fā)送實體發(fā)送的IMS即時消息之前包括所述消息發(fā)送實體獲取所述多播組消息群發(fā)實體的地址; 所述消息發(fā)送實體#4居所述地址將所述IMS即時消息攜帶在信令面消息 中發(fā)送至所述多播組消息群發(fā)實體。
3、 如權利要求1所述的方法,其特征在于,所述多播組消息群發(fā)實體接 收消息發(fā)送實體發(fā)送的IMS即時消息之前包括所述消息發(fā)送實體獲取所述多播組消息群發(fā)實體的地址; 所述消息發(fā)送實體根據所述地址與所述多播組消息群發(fā)實體協(xié)商建立 MSRP媒體通道;所述消息發(fā)送實體通過所述MSRP通道將所述IMS即時消息發(fā)送至所述 多播組消息群發(fā)實體。
4、 如權利要求1至3任一項所述的方法,其特征在于,所述多播組消息 群發(fā)實體將所述IMS即時消息發(fā)送給所述多播組內的所有消息接收實體具體 包括所述多播組消息群發(fā)實體通過多播傳輸通道將所述IMS即時消息發(fā)送給 所述多播組內的所有消息接收實體。
5、 如權利要求1至3任一項所述的方法,其特征在于,所述多播組消息 群發(fā)實體將所述IMS即時消息發(fā)送給所述多播組內的所有消息接收實體具體 包括在消息接收實體加入多播組過程中,所述多播組消息群發(fā)實體通過多播會話協(xié)商建立與所述消息接收實體之間的MSRP媒體通道;所述多播組消息群發(fā)實體通過所述MSRP媒體通道將所述IMS即時消息 發(fā)送給所述多播組內的所有消息接收實體。
6、 一種多播組消息群發(fā)實體,其特征在于,所述多播組消息群發(fā)實體包括消息服務單元,所述消息服務單元用于接收消息發(fā)送實體發(fā)送的IMS即時 消息;所述多播組消息群發(fā)實體與所述消息發(fā)送實體位于同一多播組內;多插4某體傳輸單元,所述多播媒體傳輸單元用于將所述IMS即時消息發(fā)送 給所述多播組內的所有消息接收實體。
7、 如權利要求6所述的實體,其特征在于,所述多播媒體傳輸單元通過多播傳輸通道將所述IMS即時消息發(fā)送給所 述多播組內的所有消息接收實體。
8、 如權利要求6所述的實體,其特征在于,所述多播組消息群發(fā)實體還 包括MSRP媒體通道建立單元所述MSRP媒體通道建立單元,用于在消息接收實體加入多播組過程中通 過多播會話協(xié)商建立與所述消息接收實體之間的MSRP々某體通道;所述多播媒體傳輸單元通過所述MSRP媒體通道將所述IMS即時消息發(fā) 送給所述多播組內的所有消息接收實體。
全文摘要
本發(fā)明實施例公開了一種IMS即時消息群發(fā)的方法,包括多播組消息群發(fā)實體接收消息發(fā)送實體發(fā)送的IMS即時消息;所述多播組消息群發(fā)實體與所述消息發(fā)送實體屬于同一多播組;所述多播組消息群發(fā)實體將所述IMS即時消息發(fā)送給所述多播組內的所有消息接收實體。本發(fā)明實施例還公開了一種多播組消息群發(fā)實體。本發(fā)明實施例通過利用多播實現(xiàn)群發(fā)IMS即時消息,可以減輕服務器的負載。
文檔編號H04L12/18GK101588251SQ200810067380
公開日2009年11月25日 申請日期2008年5月20日 優(yōu)先權日2008年5月20日
發(fā)明者施有鑄, 漆寶劍, 金曉明 申請人:華為技術有限公司