本發(fā)明涉及但不限于ip多媒體子系統(tǒng)(ims，ipmultimediasubsystem)技術(shù)，尤指一種多方會議系統(tǒng)及其實現(xiàn)多方會議的方法和裝置。

背景技術(shù)：

多媒體通信一直是通信領(lǐng)域的追求目標(biāo)，并在不斷完善。4g背景下，基于ip多媒體子系統(tǒng)(ims，ipmultimediasubsystem)的語音業(yè)務(wù)(volte，voiceoverlte)為移動用戶普及使用多媒體通信帶來了機遇窗，多方視頻，在volte和ims背景下，也成為可能。因為volte的核心控制使用的是ims，下文將針對ims展開描述。

多方視頻的關(guān)鍵在于視頻混屏。目前，ims使用的視頻混屏方式為：使用網(wǎng)絡(luò)側(cè)集中的媒體服務(wù)器(mcu)進行視頻混屏的方式。典型的應(yīng)用如企業(yè)級視頻會議、ims媒體資源控制器(mrfc，mediaresourcefunctioncontroller)/媒體資源處理器(mrfp，mediaresourcefunctionprocessor)。

目前由網(wǎng)絡(luò)側(cè)集中進行視頻混屏的實現(xiàn)方式，對于傳統(tǒng)企業(yè)級視頻會議模式遷移到ims領(lǐng)域使用，技術(shù)相對成熟，但是，mcu使用硬解碼或軟解碼處理，均存在過程復(fù)雜、成本高等問題；而且，統(tǒng)一在mcu實現(xiàn)編解碼，存在使用不同廠商的volte手機會有業(yè)務(wù)體驗不一致的問題如由于操作界面的不同而存在的差異或多方視頻畫面的布局存在差異等，難以得到推廣普及。

技術(shù)實現(xiàn)要素：

為了解決上述技術(shù)問題，本發(fā)明實施例提供一種多方會議系統(tǒng)及其實現(xiàn)多方會議的方法和裝置，能夠簡化網(wǎng)絡(luò)側(cè)處理，并有利于推廣普及。

為了達到本發(fā)明目的，本發(fā)明實施例提供了一種多方會議系統(tǒng)，包括；應(yīng)用服務(wù)器as、視頻分發(fā)服務(wù)器、音頻服務(wù)器，以及終端；其中，

as，用于多方會議功能的控制，以及指示對音頻服務(wù)器和視頻分發(fā)服務(wù) 器的控制；

視頻分發(fā)服務(wù)器，用于按照as的指示，對來自終端的視頻流進行處理和傳送；

音頻服務(wù)器，用于按照as的指示，對來自終端的音頻流進行處理并傳送；

終端包括第一類終端、和/或第二類終端、和/或第三類終端，其中，第一類終端支持多方視頻應(yīng)用下接收多個視頻流，并支持混屏處理；第二類終端為支持視頻通話的終端；第三類終端為僅支持音頻通話的終端。

可選地，所述第一類終端與所述as之間的控制接口使用會話初始協(xié)議sip，信令采用sip信令；

所述第一類終端與所述視頻分發(fā)服務(wù)器之間的視頻媒體流接口，上行包含采集的視頻信號的一條視頻流，下行包含非自身的多個遠端用戶的視頻信號的多條視頻流；

所述第一類終端與所述音頻服務(wù)器之間的音頻媒體接口包括包含從用戶側(cè)采集的視頻信號的一路上行音頻，以及一路下行音頻。

可選地，對于信令面屏蔽多流的模式，所述多個視頻流封包在一個實時傳輸協(xié)議rtp流中；

對于信令面識別多流的模式，所述多個視頻流分別獨立封裝在多個rtp流中。

可選地，所述第二類終端與所述as之間的控制接口使用sip協(xié)議，信令采用sip信令；

所述第二類終端與所述視頻分發(fā)服務(wù)器之間的視頻媒體接口，上行包含從用戶側(cè)采集的視頻信號的一條視頻流，下行包含當(dāng)前發(fā)言者的視頻信號的一條視頻流；

所述第二類終端與所述音頻服務(wù)器的音頻媒體接口包括包含從用戶側(cè)采集的視頻信號的一路上行音頻，以及一路下行音頻。

可選地，所述第三類終端與所述as之間的控制接口使用sip協(xié)議，信令采用現(xiàn)有sip信令；

所述第三類終端與所述音頻服務(wù)器的音頻媒體接口包括從用戶側(cè)采集的音頻信號的一路上行音頻，以及一路下行音頻。

可選地，所述視頻分發(fā)服務(wù)器至少包括第二接收模塊，第二處理模塊；其中，

第二接收模塊，用于接收來自as的視頻信息；

第二處理模塊，用于根據(jù)接收到的視頻信息實現(xiàn)視頻的媒體協(xié)商并返回給as；與終端之間傳遞視頻媒體流；

其中，視頻媒體流包括上行實時傳輸協(xié)議rtp流、下行rtp流，其中，下行的rtp流中會承載多路視頻流；

可選地，所述第二接收模塊還用于：接收來自所述as的需要信令面指示的參數(shù)；當(dāng)接收來自所述as的信令面指示時，相應(yīng)地，

所述第二處理模塊還用于：在所述下行rtp流中加入新增終端對應(yīng)的視頻流。

可選地，所述在下行rtp流中加入新用戶對應(yīng)的視頻流具體包括：在一路所述下行rtp流中包括所述多方視頻中所有用戶的視頻流；或者，所述多方會議中各用戶的視頻流分別對應(yīng)一路所述下行rtp流。

可選地，所述第二接收模塊還用于：接收來自所述as的將所有終端接收的視頻內(nèi)容切換為當(dāng)前發(fā)言人對應(yīng)的上行視頻的內(nèi)容的請求；

所述第二處理模塊還用于：完成相應(yīng)的轉(zhuǎn)發(fā)關(guān)系變換，以使當(dāng)前多方會議中所有的終端接收的視頻內(nèi)容被切換至當(dāng)前發(fā)言人對應(yīng)的上行視頻的內(nèi)容。

可選地，所述第二處理模塊還用于：在有新增終端加入時，直接在所述下行rtp流中加入新用戶對應(yīng)的視頻流。

可選地，所述第二處理模塊還用于：根據(jù)所述多方會議的用戶數(shù)調(diào)整用戶上行視頻分辨率。

可選地，所述第二處理模塊還用于：接收來自各終端的上行視頻流，按照終端類型和模式進行轉(zhuǎn)發(fā)。

可選地，所述按照終端類型和模式進行轉(zhuǎn)發(fā)具體包括：

對于第一類終端，當(dāng)采用信令面屏蔽多流的模式時，將所述來自各終端的多個視頻封裝在一個rtp流中發(fā)送給所述第一類終端；當(dāng)采用信令面識別多流的模式時，將所述來自各終端的多個視頻分別封裝在各自的rtp流中發(fā)送給所述第一類終端；

對于第二類終端，根據(jù)所述as最新指示的當(dāng)前發(fā)言人，選定對應(yīng)當(dāng)前發(fā)言人的一路視頻流進行轉(zhuǎn)發(fā)。

可選地，所述視頻分發(fā)服務(wù)器為視頻中繼videorelay。

本發(fā)明實施例還提供了一種實現(xiàn)多方會議的方法，包括：as接收來自終端的加入多方會議的請求；

將請求中的音頻信息發(fā)送給音頻服務(wù)器，以實現(xiàn)音頻的媒體協(xié)商；和/或?qū)⒁曨l信息發(fā)送給視頻分發(fā)服務(wù)器，以實現(xiàn)視頻的媒體協(xié)商；

將協(xié)商好的視頻和/或音頻進行處理后返回給終端。

可選地，該方法還包括：所述在向視頻分發(fā)服務(wù)器發(fā)送視頻信息時，同時將需要信令面指示的參數(shù)發(fā)送給視頻分發(fā)服務(wù)器。

可選地，當(dāng)接收到來自音頻服務(wù)器的需要將多方視頻切換至當(dāng)前發(fā)言人的請求消息，該方法還包括：

所述as根據(jù)當(dāng)前發(fā)言人的信息，向視頻分發(fā)服務(wù)器請求將所有終端接收的視頻內(nèi)容切換為當(dāng)前發(fā)言人對應(yīng)的上行視頻的內(nèi)容；并接收來自視頻分發(fā)服務(wù)器的完成相應(yīng)的轉(zhuǎn)發(fā)關(guān)系變換的響應(yīng)。

可選地，如果有新的用戶加入，該方法還包括：

所述as向終端請求重協(xié)商視頻參數(shù)，并攜帶單個視頻流，或者所有視頻流；

接收到來自終端的完成媒體協(xié)商的響應(yīng)，向視頻分發(fā)服務(wù)器發(fā)送信令面指示，以指示信令面更新完成。

本發(fā)明實施例再提供了一種實現(xiàn)多方會議的方法，包括：視頻分發(fā)服務(wù)器接收到來自as的視頻信息，根據(jù)接收到的視頻信息實現(xiàn)視頻的媒體協(xié)商 并返回給as；與終端之間傳遞視頻媒體流；

其中，視頻媒體流包括上行rtp流、下行rtp流，其中，下行的rtp流中會承載多路視頻流。

可選地，如果所述視頻分發(fā)服務(wù)器接收來自as的需要信令面指示的參數(shù)，則當(dāng)接收來自as的信令面指示，該方法還包括：

所述視頻分發(fā)服務(wù)器在所述下行rtp流中加入新用戶對應(yīng)的視頻流。

可選地，在下行rtp流中加入新用戶對應(yīng)的視頻流具體包括：

一路所述下行rtp流中包括多方會議中所有用戶的視頻流；或者，多方視頻會中各用戶的視頻流分別對應(yīng)一路所述下行rtp流。

可選地，當(dāng)接收到來自as的將所有終端接收的視頻內(nèi)容切換為當(dāng)前發(fā)言人對應(yīng)的上行視頻的內(nèi)容的請求消息，該方法還包括：

完成相應(yīng)的轉(zhuǎn)發(fā)關(guān)系變換，以使當(dāng)前多方會議中所有的終端接收的視頻內(nèi)容被切換至當(dāng)前發(fā)言人對應(yīng)的上行視頻的內(nèi)容。

可選地，在有新用戶加入時，該方法還包括：所述視頻分發(fā)服務(wù)器直接在所述下行rtp流中加入新用戶對應(yīng)的視頻流。

可選地，該方法還包括：所述視頻分發(fā)服務(wù)器根據(jù)多方會議的用戶數(shù)調(diào)整用戶上行視頻分辨率。

可選地，該方法還包括：所述視頻分發(fā)服務(wù)器接收來自各終端的上行視頻流，按照終端類型和模式進行轉(zhuǎn)發(fā)。

可選地，所述按照終端類型和模式進行轉(zhuǎn)發(fā)包括：

對于第一類終端，當(dāng)采用信令面屏蔽多流的模式時，將多個視頻流封裝在一個所述下行rtp流中發(fā)送給第一類終端；當(dāng)采用信令面識別多流的模式時，將多個視頻流分別封裝在各自的一路下行rtp流中發(fā)送給第一類終端；

對于第二類終端，根據(jù)所述as最新指示的當(dāng)前發(fā)言人，選定對應(yīng)當(dāng)前發(fā)言人的一路視頻進行轉(zhuǎn)發(fā)。

本發(fā)明實施例又提供了一種實現(xiàn)多方會議的方法，包括：

第一類終端向as發(fā)送加入多方會議的請求，其中攜帶音頻信息和/或視 頻信息；

接收到來自as的處理后的協(xié)商好的視頻和/或音頻，與音頻服務(wù)器和/或視頻分發(fā)服務(wù)器傳遞音頻媒體流和/或視頻媒體流。

可選地，當(dāng)接收到來自as的重協(xié)商視頻參數(shù)的請求，該方法還包括：

所述第一類終端完成媒體協(xié)商；

當(dāng)采用信令面屏蔽多流的模式時，接收來自視頻分發(fā)服務(wù)器的封裝有多個視頻流的一個rtp流；當(dāng)采用信令面識別多流的模式時，接收來自視頻分發(fā)服務(wù)器的分別封裝有與不同用戶對應(yīng)的視頻流的多個rtp流。

本發(fā)明實施例還提供了一種實現(xiàn)多方會議的裝置，至少包括第一接收模塊、控制模塊，以及第一處理模塊，其中，

第一接收模塊，用于接收來自終端的加入多方會議的請求，

控制模塊，用于將請求中的音頻信息發(fā)送給音頻服務(wù)器，以實現(xiàn)音頻的媒體協(xié)商；和/或?qū)⒁曨l信息發(fā)送給視頻分發(fā)服務(wù)器，以實現(xiàn)視頻的媒體協(xié)商；

第一處理模塊，用于將協(xié)商好的視頻和/或音頻進行處理后返回給終端。

可選地，所述控制模塊在向視頻分發(fā)服務(wù)器發(fā)送視頻信息時還用于：同時將需要信令面指示的參數(shù)發(fā)送給視頻分發(fā)服務(wù)器。

可選地，所述第一接收模塊還用于：接收來自音頻服務(wù)器的需要將多方視頻切換至當(dāng)前發(fā)言人的請求；

所述控制模塊還用于：根據(jù)當(dāng)前發(fā)言人的信息，向視頻分發(fā)服務(wù)器請求將所有終端接收的視頻內(nèi)容切換為當(dāng)前發(fā)言人對應(yīng)的上行視頻流的內(nèi)容；并接收來自視頻分發(fā)服務(wù)器的完成相應(yīng)的轉(zhuǎn)發(fā)關(guān)系變換的響應(yīng)。

可選地，如果有新的用戶加入，所述控制模塊還用于：向終端請求重協(xié)商視頻參數(shù)，并攜帶單個視頻流或者所有視頻流。

可選地，所述第一處理模塊還用于，接收到來自終端的完成媒體協(xié)商的響應(yīng)，向視頻分發(fā)服務(wù)器發(fā)送信令面指示，以指示信令面更新完成。

可選地，所述裝置設(shè)置在as中。

本發(fā)明實施例再提供了一種實現(xiàn)多方會議的裝置，至少包括第二接收模 塊，第二處理模塊；其中，

第二接收模塊，用于接收來自as的視頻信息；

第二處理模塊，用于根據(jù)接收到的視頻信息實現(xiàn)視頻的媒體協(xié)商并返回給as；與終端之間傳遞視頻媒體流；

其中，視頻媒體流包括上行rtp流、下行rtp流，其中，下行的rtp流中會承載多路視頻流。

可選地，所述第二接收模塊還用于：接收來自as的需要信令面指示的參數(shù)；

當(dāng)所述第二接收模塊接收到來自as的信令面指示，所述第二處理模塊還用于：在所述下行rtp流中會加入新用戶對應(yīng)的視頻流。

可選地，所述在下行rtp流中會加入新用戶對應(yīng)的視頻流包括：在一路所述下行rtp流中包括多方視頻會中所有用戶的視頻流；或者，多方視頻會中各用戶的視頻流分別對應(yīng)在一路所述下行rtp流中。

可選地，所述第二接收模塊還用于：接收來自as的將所有終端接收的視頻內(nèi)容切換為當(dāng)前發(fā)言人對應(yīng)的上行視頻的內(nèi)容的請求；

第二處理模塊還用于：完成相應(yīng)的轉(zhuǎn)發(fā)關(guān)系變換，以使當(dāng)前多方會議中所有的終端接收的視頻內(nèi)容被切換至當(dāng)前發(fā)言人對應(yīng)的上行視頻的內(nèi)容。

可選地，所述第二處理模塊還用于：在有新用戶加入時，直接在下行rtp流中加入新用戶對應(yīng)的視頻流。

可選地，所述第二處理模塊還用于：根據(jù)多方會議的用戶數(shù)調(diào)整用戶上行視頻分辨率。

可選地，所述第二處理模塊還用于：接收來自各終端的上行視頻流，按照終端類型和模式進行轉(zhuǎn)發(fā)。

可選地，所述按照終端類型和模式進行轉(zhuǎn)發(fā)包括：

對于第一類終端，當(dāng)采用信令面屏蔽多流的模式時，將所述來自各終端的多個視頻封裝在一個所述下行rtp流中發(fā)送給第一類終端；當(dāng)采用信令面識別多流的模式時，將所述來自各終端的多個視頻分別封裝在各自的一個所 述下行rtp流中發(fā)送給第一類終端；

對于第二類終端，根據(jù)as最新指示的當(dāng)前發(fā)言人，選定對應(yīng)當(dāng)前發(fā)言人的一路視頻流進行轉(zhuǎn)發(fā)。

可選地，所述裝置設(shè)置在視頻分發(fā)服務(wù)器中。

可選地，所述視頻分發(fā)服務(wù)器為視頻中繼。

本發(fā)明實施例又提供了一種實現(xiàn)多方會議的裝置，至少包括發(fā)送模塊，第三處理模塊；其中，

發(fā)送模塊，用于向as發(fā)送加入多方會議的請求，其中攜帶音頻信息和/或視頻信息；

第三處理模塊，用于接收來自as的處理后的協(xié)商好的視頻和/或音頻；與音頻服務(wù)器和/或視頻分發(fā)服務(wù)器傳遞音頻媒體流和/或視頻媒體流。

可選地，對于新用戶加入后，所述第三處理模塊還用于：

接收來自as的重協(xié)商視頻參數(shù)的請求，完成媒體協(xié)商；

當(dāng)采用信令面屏蔽多流的模式時，接收來自視頻分發(fā)服務(wù)器的封裝有多個視頻的一個所述下行rtp流；當(dāng)采用信令面識別多流的模式時，接收來自視頻分發(fā)服務(wù)器的分別封裝有與不同用戶對應(yīng)的視頻的多個所述下行rtp流。

可選地，所述裝置設(shè)置在第一類終端中。

與現(xiàn)有技術(shù)相比，本申請?zhí)峁┑亩喾揭曨l架構(gòu)包括應(yīng)用服務(wù)器、視頻分發(fā)服務(wù)器、音頻服務(wù)器，以及終端；其中，as，用于多方會議功能的控制，以及指示對音頻服務(wù)器和視頻分發(fā)服務(wù)器的控制；視頻分發(fā)服務(wù)器，用于按照as的指示，對來自終端的視頻流進行處理和傳送；音頻服務(wù)器，用于按照as的指示，對來自終端的音頻流進行處理并傳送；終端包括第一類終端、和/或第二類終端、和/或第三類終端，其中，第一類終端支持多方視頻應(yīng)用下接收多個視頻流，并支持混屏處理；第二類終端為支持視頻通話的終端；第三類終端為僅支持音頻通話的終端。本發(fā)明提供的架構(gòu)，無需在網(wǎng)絡(luò)側(cè)集中進行混屏處理，簡化了網(wǎng)絡(luò)側(cè)處理，并有利于推廣普及。而且由于不需要mcu，也降低了硬件成本。

本發(fā)明的其它特征和優(yōu)點將在隨后的說明書中闡述，并且，部分地從說明書中變得顯而易見，或者通過實施本發(fā)明而了解。本發(fā)明的目的和其他優(yōu)點可通過在說明書、權(quán)利要求書以及附圖中所特別指出的結(jié)構(gòu)來實現(xiàn)和獲得。

附圖說明

此處所說明的附圖用來提供對本發(fā)明的進一步理解，構(gòu)成本申請的一部分，本發(fā)明的示意性實施例及其說明用于解釋本發(fā)明，并不構(gòu)成對本發(fā)明的不當(dāng)限定。在附圖中：

圖1為本發(fā)明實施例多方視頻架構(gòu)的組成結(jié)構(gòu)示意圖；

圖2為圖1中的a類終端的視頻/音頻媒體接口a的媒體流構(gòu)成示意圖；

圖3為圖1中的b類終端的視頻/音頻媒體接口b的媒體流構(gòu)成示意圖；

圖4為圖1中的c類終端的視頻/音頻媒體接口c的媒體流構(gòu)成示意圖；

圖5為本發(fā)明實施例中的第一類終端/第二類終端加入多方視頻的第一實施例的流程圖；

圖6為本發(fā)明實施例中的第一類終端/第二類終端加入多方視頻的第二實施例的流程圖；

圖7為本發(fā)明實施例中第三類終端加入多方視頻的實施例的流程圖；

圖8為本發(fā)明實施例中第二類終端單視頻流切換畫面的實施例的流程圖；

圖9為本發(fā)明實施例中新用戶加入后，信令面屏蔽多流的模式下網(wǎng)絡(luò)側(cè)的實現(xiàn)過程的第一實施例的流程圖；

圖10為本發(fā)明實施例中新用戶加入后，信令面屏蔽多流的模式下網(wǎng)絡(luò)側(cè)的實現(xiàn)過程的第二實施例的流程圖；

圖11為本發(fā)明實施例中新用戶加入后，信令面識別多流的模式下網(wǎng)絡(luò)側(cè)的實現(xiàn)過程的實施例的流程圖；

圖12為本發(fā)明實施例中videorelay通過rtcp調(diào)整用戶上行視頻分辨率的實施例的示意圖；

圖13為本發(fā)明實施例中videorelay封包處理的實施例的示意圖；

圖14為本發(fā)明實施例實現(xiàn)多方會議的一種裝置的組成結(jié)構(gòu)示意圖；

圖15為本發(fā)明實施例實現(xiàn)多方會議的另一種裝置的組成結(jié)構(gòu)示意圖；

圖16為本發(fā)明實施例實現(xiàn)多方會議的又一種裝置的組成結(jié)構(gòu)示意圖。

具體實施方式

為使本發(fā)明的目的、技術(shù)方案和優(yōu)點更加清楚明白，下文中將結(jié)合附圖對本發(fā)明的實施例進行詳細說明。需要說明的是，在不沖突的情況下，本申請中的實施例及實施例中的特征可以相互任意組合。

圖1為本發(fā)明實施例多方視頻架構(gòu)的組成結(jié)構(gòu)示意圖，如圖1所示，至少包括：應(yīng)用服務(wù)器(as，applicationserver)、視頻分發(fā)服務(wù)器、音頻服務(wù)器，以及終端；其中，

as，可以是多方視頻功能的應(yīng)用服務(wù)器，用于指示多方會議功能的控制如創(chuàng)建多方視頻、加成員、踢成員等，以及指示對音頻服務(wù)器和視頻分發(fā)服務(wù)器的控制。as與各類終端之間通過相應(yīng)的控制接口實現(xiàn)控制、與視頻分發(fā)服務(wù)器和音頻服務(wù)器之間分別通過視頻控制接口和音頻控制接口實現(xiàn)控制的指示。

視頻分發(fā)服務(wù)器，用于按照as的指示，對來自終端(即用戶)的視頻流進行處理如復(fù)制和傳送如中繼，但是對視頻流本身不進行編碼/解碼操作；本文中，視頻分發(fā)服務(wù)器也可以稱為視頻中繼(videorelay)。其中，復(fù)制是指復(fù)制各終端的視頻流，中繼是指將復(fù)制的視頻流轉(zhuǎn)發(fā)給多方會議中的終端，這里轉(zhuǎn)發(fā)給終端的復(fù)制的視頻流中可以包括當(dāng)前多方會議中所有終端的視頻流，也可以是除該接收終端自身的視頻流之外的其它所有終端的視頻流即非自身的多個遠端用戶的視頻信號的多條視頻流。

音頻服務(wù)器，用于按照as的指示，對來自終端(即用戶)的音頻流進行處理如采用混音、復(fù)制等處理并傳送給用戶。這里，對音頻流需要進行編碼/解碼操作。音頻服務(wù)器可以是音頻mrfp。

終端，可以包括第一類終端、和/或第二類終端、和/或第三類終端，其中，

第一類終端即擴展的終端，如圖1中的a類終端，支持多方視頻應(yīng)用下 接收多個視頻流，并支持混屏處理。典型的第一類終端如擴展的volte終端。其中，如何實現(xiàn)混屏可以采用如四宮格、九宮格等技術(shù)，這里并不做限制，也不用于限定本發(fā)明實施例的保護范圍。混屏的實現(xiàn)具體可以是采用內(nèi)置在手機中的native模式來實現(xiàn)，也可以是采用app模式來實現(xiàn)，對于本領(lǐng)域技術(shù)人員來講，具體如何實現(xiàn)是容易實現(xiàn)的，方式也很多，并不用于限定本發(fā)明實施例的保護范圍，這里不再贅述，這里強調(diào)的是在第一類終端出采進行混屏處理。

第二類終端即支持視頻通話的終端，如圖1中的b類終端。典型的第二類終端如普通的volte終端。

第三類終端即僅支持音頻通話的終端，如圖1中的c類終端。典型的第三類終端如傳統(tǒng)的2g/3g的電路域(cs，circuitswitch)終端。第三類終端接入ims需要通過媒體網(wǎng)關(guān)控制功能/媒體網(wǎng)關(guān)(mgcf，mediagatewaycontrolfunction)/(mgw，mediagateway)進行信令、媒體轉(zhuǎn)換，這里不再贅述。

需要說明的是：videorelay的中繼功能的意義主要在于視頻，本文中僅以對視頻采用relay為例進行描述，但是，本質(zhì)上音頻也可以用relay，因此，本文并不限定relay僅應(yīng)用于視頻的情況，也包括應(yīng)用于音頻的情況。

下面結(jié)合圖1對不同的控制接口介紹如下：

控制接口a為a類終端與as之間的控制接口，使用會話初始協(xié)議(sip，sessioninitiationprotocol)，信令采用現(xiàn)有sip信令。

視頻媒體接口a為a類終端與videorelay之間的視頻媒體流接口，如圖2所示，上行為一條視頻流，為從用戶側(cè)采集的視頻信號；下行為多條視頻流(即非自身的多個遠端用戶的視頻信號)。根據(jù)信令面屏蔽多流的模式或信令面識別多流的模式，多個視頻流可以由videorelay封包在一個實時傳輸協(xié)議(rtp，real-timetransportprotocol)流中，也可以是分別封裝在多個獨立的rtp流中。

音頻媒體接口a包括一路上行音頻，為從用戶側(cè)采集的視音頻信號；一路下行音頻，為混音的音頻。音頻媒體接口a與現(xiàn)有的終端的音頻媒體接口相同。

控制接口b為b類終端與as之間的控制接口，使用sip協(xié)議，信令采用現(xiàn)有sip信令。

視頻媒體接口b為b類終端與videorelay之間的視頻媒體流接口，如圖3所示，上行為一條視頻流，為從用戶側(cè)采集的視頻信號；下行為一條視頻流(即當(dāng)前發(fā)言者的視頻信號)。

音頻媒體接口b包括一路上行音頻，為從用戶側(cè)采集的視頻信號；一路下行音頻，為混音的音頻。音頻媒體接口b與現(xiàn)有的終端的音頻媒體接口相同。

控制接口c為c類終端與as之間的控制接口，使用sip協(xié)議，信令采用現(xiàn)有sip信令。

音頻媒體接口c包括一路上行音頻，為從用戶側(cè)采集的視頻信號；一路下行音頻，為混音的音頻。音頻媒體接口c與現(xiàn)有的終端的音頻媒體接口相同。

相應(yīng)地，本發(fā)明實施例實現(xiàn)多方會議的方法包括：

as接收來自終端的加入多方會議的請求；將請求中的音頻信息發(fā)送給音頻服務(wù)器，以實現(xiàn)音頻的媒體協(xié)商；和/或?qū)⒁曨l信息發(fā)送給視頻分發(fā)服務(wù)器，以實現(xiàn)視頻的媒體協(xié)商；將協(xié)商好的視頻和/或音頻進行處理后返回給終端。

該方法還包括：在向視頻分發(fā)服務(wù)器發(fā)送視頻信息時，同時將需要信令面指示的參數(shù)發(fā)送給視頻分發(fā)服務(wù)器。

當(dāng)接收來自音頻服務(wù)器的需要將多方視頻切換至當(dāng)前發(fā)言人的請求，該方法還包括：

as根據(jù)當(dāng)前發(fā)言人的信息，向視頻分發(fā)服務(wù)器請求將所有終端接收的視頻內(nèi)容切換為當(dāng)前發(fā)言人對應(yīng)的上行視頻的內(nèi)容；并接收來自視頻分發(fā)服務(wù)器的完成相應(yīng)的轉(zhuǎn)發(fā)關(guān)系變換的響應(yīng)。

進一步地，如果有新的用戶加入即新增終端，該方法還包括：

as向終端請求重協(xié)商視頻參數(shù)，并攜帶單個視頻流，或者所有視頻流；as接收到來自終端的完成媒體協(xié)商的響應(yīng)，向視頻分發(fā)服務(wù)器發(fā)送信令面 指示，以指示信令面更新完成。

而對于視頻分發(fā)服務(wù)器，相應(yīng)地，包括：接收到來自as的視頻信息，根據(jù)接收到的視頻信息實現(xiàn)視頻的媒體協(xié)商并返回給as；與終端之間傳遞視頻媒體流；其中，視頻媒體流包括上行rtp流、下行rtp流，其中，下行的rtp流中會承載多路視頻流。

如果視頻分發(fā)服務(wù)器接收來自as的需要信令面指示的參數(shù)，則當(dāng)接收來自as的信令面指示，該方法還包括：

視頻分發(fā)服務(wù)器在下行rtp流中加入新用戶對應(yīng)的視頻流。

其中，在下行rtp流中加入新用戶對應(yīng)的視頻流具體包括：

一路下行rtp流中包括多方視頻中所有用戶的視頻流；或者，多方視頻中各用戶的視頻流分別對應(yīng)一路下行rtp流。

當(dāng)接收來自as的將所有終端接收的視頻內(nèi)容切換為當(dāng)前發(fā)言人對應(yīng)的上行視頻的內(nèi)容的請求時，該方法還包括：

完成相應(yīng)的轉(zhuǎn)發(fā)關(guān)系變換，以使當(dāng)前多方會議中所有的終端接收的視頻內(nèi)容被切換至當(dāng)前發(fā)言人對應(yīng)的上行視頻的內(nèi)容。

進一步地，在有新用戶加入時，該方法還包括：視頻分發(fā)服務(wù)器直接在下行rtp流中加入新用戶對應(yīng)的視頻流。

該方法還包括：視頻分發(fā)服務(wù)器根據(jù)多方會議的用戶數(shù)調(diào)整用戶上行視頻分辨率。

該方法還包括：視頻分發(fā)服務(wù)器接收來自各終端的上行視頻流，按照終端類型和模式進行轉(zhuǎn)發(fā)。其中，

按照終端類型和模式進行轉(zhuǎn)發(fā)包括：

對于第一類終端，當(dāng)采用信令面屏蔽多流的模式時，將多個視頻封裝在一個下行rtp流中發(fā)送給第一類終端；當(dāng)采用信令面識別多流的模式時，將多個視頻分別封裝在各自的一路下行rtp流中發(fā)送給第一類終端；

對于第二類終端，根據(jù)所述as最新指示的當(dāng)前發(fā)言人，選定對應(yīng)當(dāng)前發(fā)言人的一路視頻進行轉(zhuǎn)發(fā)。

對于第一終端，相應(yīng)地，包括：第一類終端向as發(fā)送加入多方會議的請求，其中攜帶音頻信息和/或視頻信息；接收到來自as的處理后的協(xié)商好的視頻和/或音頻，與音頻服務(wù)器和/或視頻分發(fā)服務(wù)器傳遞音頻媒體流和/或視頻媒體流。

當(dāng)接收到來自as的重協(xié)商視頻參數(shù)的請求，該方法還包括：

所述第一類終端完成媒體協(xié)商；

當(dāng)采用信令面屏蔽多流的模式時，接收來自視頻分發(fā)服務(wù)器的封裝有多個視頻流的一個rtp流；當(dāng)采用信令面識別多流的模式時，接收來自視頻分發(fā)服務(wù)器的分別封裝有與不同用戶對應(yīng)的視頻流的多個rtp流。

下面結(jié)合具體實施例和本發(fā)明實施例架構(gòu)詳細描述本發(fā)明實施例實現(xiàn)多方會議的方法。

圖5為本發(fā)明實施例中第一類終端/第二類終端加入多方視頻的第一實施例的流程圖，本實施例為無后續(xù)as指示的實施例，即新用戶加入后，videorelay的后續(xù)操作無需按照as的指示進行，如圖5所示，包括以下步驟：

步驟500：a類終端或b類終端(ue_a/ue_b)向as發(fā)送邀請(invite)請求，以請求獲取會議的統(tǒng)一資源標(biāo)識符(uri，uniformresourceidentifier)，invite請求中攜帶的會話描述協(xié)議(sdp，sessiondescriptionprotocol)包含音頻信息和頻信息。

本步驟也可以是由as直接邀請終端加入多方視頻會議。

步驟501：as收到邀請(invite)請求，將sdp音頻部分通過invite請求發(fā)送給voicemrfp。

步驟502：voicemrfp在返回的200ok中攜帶sdp，完成音頻的媒體協(xié)商。

步驟503：as向voicemrfp返回響應(yīng)ack。

步驟504：as將sdp視頻部分通過invite請求發(fā)送給videorelay。

步驟505：videorelay在返回的200ok中攜帶sdp，完成視頻的媒體協(xié)商。

步驟506：as向videorelay返回ack。

需要說明的是，步驟501～步驟503所述的音頻的媒體協(xié)商，以及步驟504～步驟506所述的視頻的媒體協(xié)商之間并沒有嚴(yán)格的先后執(zhí)行順序。

步驟507：as將音頻sdp和視頻sdp進行合并處理，并攜帶在200ok中發(fā)送給ue_a/ue_b。

至此，即建立好了ue_a/ue_b與voicemrfp之間的音頻媒體流，音頻媒體流包括上行、下行各一路實時傳輸協(xié)議(rtp，real-timetransportprotocol)流；以及，建立好了ue_a/ue_b與videorelay之間的視頻媒體流，視頻媒體流包括上行、下行各一路rtp流，其中，下行的rtp流中會承載多路視頻流。

這樣，videorelay會按照新的視頻流組合對各a類終端進行轉(zhuǎn)發(fā)，即對于新加入多方視頻的ue_a，會在一路rtp流中接收到多個視頻流，而對于原有的ue_a，會在原有的一路rtp流中加入新加入的ue_a的視頻流即在原有的一路rtp流中多接收新加入的ue_a的視頻流。

圖5所示的方法中，需要加入多方視頻的新用戶ue_a在發(fā)送invite請求之前，還可以包括：

預(yù)先計算出多個視頻的帶寬需求，然后根據(jù)計算出的帶寬折算出sdp中的視頻參數(shù)。比如基于900*900的分辨率，如果后續(xù)最大支持9人會議，也就是說需要同時接收8路300*300分辨率的視頻，這樣容易得出，8路的視頻帶寬折算出需要按照720p(一般的會高于一路900*900)設(shè)置視頻參數(shù)。

圖6為本發(fā)明實施例中第一類終端/第二類終端加入多方視頻的第二實施例的流程圖，本實施例為有后續(xù)as指示的實施例，即新用戶加入后，videorelay的后續(xù)操作需要按照as的指示進行。如圖6所示，包括以下步驟：

步驟600：ue_a/ue_b向as發(fā)送invite請求，以請求獲取會議的uri，invite請求中攜帶的sdp包含音頻信息和視頻信息。

本步驟也可以是由as直接邀請終端加入多方視頻會議。

步驟601：as收到invite請求，將sdp音頻部分通過invite請求發(fā)送給voicemrfp。

步驟602：voicemrfp在返回的200ok中攜帶sdp，完成音頻的媒體協(xié)商。

步驟603：as向voicemrfp返回響應(yīng)ack。

步驟604：as將sdp視頻部分通過invite請求發(fā)送給videorelay，同時，在invite請求中攜帶“需要信令面指示”的參數(shù)，即新用戶加入后，videorelay后續(xù)如何操作是需要按照as的指示進行的。

步驟605：videorelay在返回的200ok中攜帶sdp，完成視頻的媒體協(xié)商。

步驟606：as向videorelay返回ack。

步驟607：as將音頻sdp和視頻sdp進行合并處理，并攜帶在200ok中發(fā)送給ue_a/ue_b。

至此，即建立好了ue與voicemrfp之間的音頻媒體流，音頻媒體流包括上行、下行各一路rtp流；以及，建立好了ue與videorelay之間的視頻媒體流，視頻媒體流包括上行、下行各一路rtp流。而且，videorelay后續(xù)如何操作是需要按照as的后續(xù)指示進行的。

需要說明的是，對于信令面識別多流的模式，加入多方視頻采用圖6所示的流程，即videorelay后續(xù)如何操作，需要等as與各ue重協(xié)商媒體后再指示。對于信令面屏蔽多流的模式，也可能使用圖6所示的流程，比如as發(fā)現(xiàn)新用戶加入多方視頻會議后，如果存在ue_a/ue-b當(dāng)前的視頻參數(shù)不滿足多流的帶寬需要時，可能會帶來承載層無法保障服務(wù)質(zhì)量(qos)，這種情況下，videorelay后續(xù)如何操作也是需要等到as與各相關(guān)ue重協(xié)商媒體后指示的。其中，視頻參數(shù)是否滿足多流的帶寬需要，可以有終端自行根據(jù)視頻的情況計算得出，或者按照預(yù)先存儲的視頻情況與所需帶寬需求之間的映射關(guān)系確定。具體實現(xiàn)屬于本領(lǐng)域技術(shù)人員容易想到的，這里并不用于限定本發(fā)明實施例的保護范圍，這里不再贅述。

圖7為本發(fā)明實施例中第三類終端加入多方視頻的實施例的流程圖，如圖7所示，包括以下步驟：

步驟700：第三類終端(ue_c)向as發(fā)送invite請求，以請求獲取 會議的uri，invite請求中攜帶的sdp包含音頻信息。

步驟701：as收到invite請求，將sdp音頻部分通過invite請求發(fā)送到voicemrfp。

步驟702：voicemrfp在返回的200ok中攜帶sdp，完成音頻的媒體協(xié)商。

步驟703：as向voicemrfp返回響應(yīng)ack。

步驟704：as將音視頻sdp攜帶在200ok中發(fā)送給ue_c。

至此，即建立好了ue_c與voicemrfp之間的音頻媒體流，音頻媒體流包括上行、下行各一路rtp流。

圖8為本發(fā)明實施例中第二類終端單視頻流切換畫面的實施例的流程圖，如圖8所示，當(dāng)?shù)诙惤K端的發(fā)言人發(fā)生改變時，需要將多方視頻切換至當(dāng)前發(fā)言人，具體切換包括以下步驟：

步驟800：voicemrfp向as發(fā)送事件報告，其中攜帶當(dāng)前發(fā)言人的信息。as與voicemrfp之間可以使用如msml控制協(xié)議，即為<asn>event。

步驟801：as向voicemrfp返回事件報告響應(yīng)。

步驟802：as根據(jù)當(dāng)前發(fā)言人的信息，向videorelay發(fā)送切換ue_b的視頻流內(nèi)容的請求，以請求將所有ue_b接收的視頻內(nèi)容切換為當(dāng)前發(fā)言人對應(yīng)的上行視頻的內(nèi)容。

步驟803～步驟804：videorelay根據(jù)指示，完成相應(yīng)的轉(zhuǎn)發(fā)關(guān)系變換并向as返回請求響應(yīng)。

這樣，ue_b即當(dāng)前多方視頻會議中所有的b類終端接收的視頻內(nèi)容被切換至當(dāng)前發(fā)言人對應(yīng)的上行視頻的內(nèi)容。

圖9為本發(fā)明實施例中新用戶加入后，信令面屏蔽多流的模式下網(wǎng)絡(luò)側(cè)的實現(xiàn)過程的第一實施例的流程圖，本實施例基于無后續(xù)as指示的實施例，即新用戶加入后，videorelay的后續(xù)操作無需按照as的指示進行的實施例，如圖9所示，本實施例以有新的ue_a用戶即新的第一類終端加入視頻會議為例，需要將多方視頻會議中的所有ue_a的下行rtp流更新為包含所有的視頻流，包括：

步驟900：對于信令面屏蔽多流的模式，此操作由videorelay在新用戶加入后單獨完成，即在下行rtp流中加入新用戶對應(yīng)的視頻流。

假設(shè)該ue_a原先下行rtp流包括有視頻流1、視頻流2，當(dāng)一個新用戶加入，假設(shè)該新用戶對應(yīng)的視頻流經(jīng)過videorelay封包轉(zhuǎn)發(fā)后為視頻流3，那么，videorelay會將該新加入的ue_a的視頻流3加入針對ue_a的下行rtp流中，也就是說，在發(fā)送給a類終端機ue_a的下行rtp流中包括視頻流1、視頻流2和視頻流3。

從如圖5或圖6所示的流程可見，用戶加入多方視頻會議時，是向as請求加入的，而as在有新用戶加入，會指示videorelay有新的視頻流加入到videorelay，因此，videorelay是能夠感知有新用戶加入的。

需要說明的是，有新的第二類終端即ue_b加入時，同樣適用圖9所示的方法。

圖10為本發(fā)明實施例中新用戶加入后，信令面屏蔽多流的模式下網(wǎng)絡(luò)側(cè)的實現(xiàn)過程的第二實施例的流程圖，本實施例基于有后續(xù)as指示的實施例，即新用戶加入后，videorelay的后續(xù)操作需要按照as的指示進行的實施例，如圖10所示，本實施例以有新的ue_a用戶即新的第一類終端加入視頻會議為例，需要將多方視頻會議中的所有ue_a的下行rtp流更新為包含所有的視頻流，包括：

步驟1000：有新的ue_a用戶即新的第一類終端加入多方視頻會議，并且在加入時，as已經(jīng)指示videorelay等待信令面指示如圖6中步驟604所示。

步驟1001：as向ue_a發(fā)送重邀請(re-invite)請求以重協(xié)商視頻參數(shù)。需要說明的是，本步驟也可以是由ue_a主動發(fā)起加入請求。

由于本實施例中假設(shè)采用的是信令面屏蔽多流的模式，因此，re-invite請求中攜帶的sdp只有單個視頻(onevideo)流。

步驟1002：ue返回200ok以完成媒體協(xié)商。

步驟1003：as返回響應(yīng)ack。

步驟1004：as向videorelay發(fā)送信令面指示，以指示信令面更新完成。

步驟1005：videorelay返回指示響應(yīng)。

這樣，在下行rtp流中會加入新用戶對應(yīng)的視頻流。

比如ue_a原先下行rtp流包括有視頻流1、視頻流2，當(dāng)一個新用戶加入，假設(shè)該新用戶對應(yīng)的視頻流經(jīng)過videorelay封包轉(zhuǎn)發(fā)后為視頻流3，那么，videorelay會將該新加入的ue_a的視頻流3加入針對ue_a的下行rtp流中，也就是說，在發(fā)送給a類終端即ue_a的下行rtp流中包括視頻流1、視頻流2和視頻流3。

需要說明的是，有新的第二類終端即ue_b加入時，同樣適用圖10所示的方法。

圖11為本發(fā)明實施例中新用戶加入后，信令面識別多流的模式下網(wǎng)絡(luò)側(cè)的實現(xiàn)過程的實施例的流程圖，本實施例基于有后續(xù)as指示的實施例，即新用戶加入后，videorelay的后續(xù)操作需要按照as的指示進行的實施例，如圖10所示，本實施例以有新的ue_a用戶即新的第一類終端加入視頻會議為例，需要將多方視頻會議中的所有ue_a的下行rtp流更新為包含所有的視頻流，包括：

步驟1100：有新的ue_a用戶即新的第一類終端加入視頻會議，并且在加入時，as已經(jīng)指示videorelay等待信令面指示如圖6中步驟604所示。

步驟1101：as向ue_a發(fā)送重邀請(re-invite)請求以重協(xié)商視頻參數(shù)。需要說明的是，本步驟也可以是由ue_a主動發(fā)起加入請求。

由于本實施例中采用的是信令面識別多流的模式，因此，re-invite請求中攜帶的sdp包含所有視頻(allvideo)流即原先所有的video流和新加入的終端的這一路rtp流對應(yīng)的video流。

步驟1102：ue返回200ok以完成媒體協(xié)商，即增加了一路下行的視頻；

步驟1103：as返回響應(yīng)ack。

步驟1104：as向videorelay發(fā)送信令面指示，以指示信令面更新完成。

步驟1105：videorelay返回指示響應(yīng)。

這樣，在下行rtp組中會加入新用戶對應(yīng)的rtp流。如該ue原先下行有包含視頻流1的rtp1流、包含視頻流2的rtp2流，當(dāng)一個新用戶加入 (該新用戶對應(yīng)的視頻流經(jīng)過videorelay封包轉(zhuǎn)發(fā)后為包含視頻流3的rtp3流)，該ue的下行將包含rtp1流、rtp2流、rtp3流。

需要說明的是，有新的第二類終端即ue_b加入時，同樣適用圖11所示的方法。

圖12為本發(fā)明實施例中videorelay通過實時流協(xié)議(rtcp，real-timestreamingprotocol)調(diào)整用戶上行視頻分辨率的實施例的示意圖，如圖12所示，假設(shè)當(dāng)前會議中有4個提供視頻的用戶即ue_a1、ue2、ue3和ue4，其中，對于a類終端，此時可以按照如表1(a)的四宮格顯示：整個畫面分辨率為900*900，每一路(包括1、2、3和4路)分辨率為450*450。

假設(shè)有新加入的ue5，此時，多方視頻會議中有5個用戶，需要按九宮格顯示：每一路分辨率可以降為300*300，當(dāng)videorelay識別出需要調(diào)整用戶的上行視頻分辨率時，會通過rtcp與各ue(支持視頻的ue)交互，調(diào)整分辨率及相應(yīng)的視頻參數(shù)，具體如何調(diào)整可參見相關(guān)協(xié)議，這里不再詳述。

各ue(支持視頻的ue)都按照調(diào)整后的300*300分辨率采樣，并在上行視頻中發(fā)送給videorelay；videorelay將收到的多路(包括1、2、3、4和5路)300*300視頻流封包轉(zhuǎn)發(fā)給每個a類ue，a類ue的呈現(xiàn)效果為表1(b)的九宮格所示。

當(dāng)有第6個用戶如ue6再加入時，還可以繼續(xù)按當(dāng)前的九宮格(多路300*300)呈現(xiàn)，videorelay就不需要通過rtcp調(diào)整用戶的上行視頻分辨率了。

圖13為本發(fā)明實施例中videorelay封包處理的實施例的示意圖，如圖13所示，videorelay接收來自各ue(支持視頻的ue)的上行視頻，按照終端類型和模式進行轉(zhuǎn)發(fā)，具體地：

對于a類終端，

當(dāng)采用信令面屏蔽多流的模式時，videorelay將多個視頻封裝在一個rtp流中發(fā)送給終端，即videorelay需要對rtp包進行封包處理，并且需要替換地址信息為videorelay的地址信息。如13圖中videorelay對于ue_a1的處理；

當(dāng)采用信令面識別多流的模式時，videorelay將多個視頻分別封裝在各自的rtp流中發(fā)送給ue，即videorelay需要替換地址信息為videorelay的地址信息。如圖13中videorelay對于ue_a2的處理。

對于b類終端，

videorelay根據(jù)as最新指示的當(dāng)前發(fā)言人，選定對應(yīng)的視頻進行轉(zhuǎn)發(fā)，即僅轉(zhuǎn)一路視頻即可。

本發(fā)明實施例中各終端的視頻格式是統(tǒng)一的，目前volte、gsma可以采用如h.264(未來h.265)等協(xié)議。

圖14為本發(fā)明實施例實現(xiàn)多方會議的裝置的一種組成結(jié)構(gòu)示意圖，該張志可以設(shè)置在as中，如圖14所示，至少包括第一接收模塊、控制模塊，以及第一處理模塊，其中，

第一接收模塊，用于接收來自終端的加入多方會議的請求，

控制模塊，用于將請求中的音頻信息發(fā)送給音頻服務(wù)器，以實現(xiàn)音頻的媒體協(xié)商；和/或?qū)⒁曨l信息發(fā)送給視頻分發(fā)服務(wù)器，以實現(xiàn)視頻的媒體協(xié)商；

第一處理模塊，用于將協(xié)商好的視頻和/或音頻進行處理后返回給終端。

對于新用戶加入后，videorelay的后續(xù)操作需要按照as的指示進行的情況，進一步地，

控制模塊在向視頻分發(fā)服務(wù)器發(fā)送視頻信息時，還用于同時將需要信令面指示的參數(shù)發(fā)送給視頻分發(fā)服務(wù)器。

進一步地，

第一接收模塊還用于：接收來自音頻服務(wù)器的需要將多方視頻切換至當(dāng)前發(fā)言人的請求；相應(yīng)地，

控制模塊還用于：根據(jù)當(dāng)前發(fā)言人的信息，向視頻分發(fā)服務(wù)器請求將所有終端接收的視頻內(nèi)容切換為當(dāng)前發(fā)言人對應(yīng)的上行視頻流的內(nèi)容；并接收來自視頻分發(fā)服務(wù)器的完成相應(yīng)的轉(zhuǎn)發(fā)關(guān)系變換的響應(yīng)。

進一步地，對于已經(jīng)建立的多方會議，如果有新的用戶加入，且對于新用戶加入后，videorelay的后續(xù)操作需要按照as的指示進行的情況，

控制模塊還用于：向終端請求重協(xié)商視頻參數(shù)，并攜帶單個視頻(onevideo)流(信令面屏蔽多流的模式)或者所有視頻(allvideo)流(信令面識別多流的模式)。

第一處理模塊還用于，接收到來自終端的完成媒體協(xié)商的響應(yīng)，向視頻分發(fā)服務(wù)器發(fā)送信令面指示，以指示信令面更新完成。

圖15為本發(fā)明實施例實現(xiàn)多方會議的另一種裝置的組成結(jié)構(gòu)示意圖，該裝置可以設(shè)置在視頻分發(fā)服務(wù)器如videorelay中，如圖15所示，至少包括第二接收模塊，第二處理模塊；其中，

第二接收模塊，用于接收來自as的視頻信息；

第二處理模塊，用于根據(jù)接收到的視頻信息實現(xiàn)視頻的媒體協(xié)商并返回給as；與終端之間傳遞視頻媒體流。

其中，視頻媒體流包括上行rtp流、下行rtp流，其中，下行的rtp流中會承載多路視頻流。

值得注意的是：本發(fā)明實施例提供的視頻分發(fā)服務(wù)器對視頻流本身并不進行編碼/解碼操作。

進一步地，

第二接收模塊還用于：接收來自as的需要信令面指示的參數(shù)；這種情況下，當(dāng)接收來自as的信令面指示時，相應(yīng)地，

第二處理模塊還用于：在下行rtp流中會加入新用戶對應(yīng)的視頻流。具體包括：在一路下行rtp流中包括多方會議中所有用戶的視頻流；或者，多方會議中各用戶的視頻流分別對應(yīng)一路下行rtp流中(也可稱為下行rtp組)。

進一步地，

第二接收模塊還用于：接收來自as的將所有終端接收的視頻內(nèi)容切換為當(dāng)前發(fā)言人對應(yīng)的上行視頻的內(nèi)容的請求；

第二處理模塊還用于：完成相應(yīng)的轉(zhuǎn)發(fā)關(guān)系變換，以使當(dāng)前多方會議中所有的終端接收的視頻內(nèi)容被切換至當(dāng)前發(fā)言人對應(yīng)的上行視頻的內(nèi)容。

進一步地，第二處理模塊還用于：在有新用戶加入時，直接在下行rtp流中加入新用戶對應(yīng)的視頻流。

進一步地，第二處理模塊還用于：根據(jù)多方會議的用戶數(shù)調(diào)整用戶上行視頻分辨率。

進一步地，第二處理模塊還用于：接收來自各終端的上行視頻流，按照終端類型和模式進行轉(zhuǎn)發(fā)。具體包括：

對于第一類終端，當(dāng)采用信令面屏蔽多流的模式時，將來自各終端的多個視頻封裝在一個下行rtp流中發(fā)送給第一類終端；當(dāng)采用信令面識別多流的模式時，將來自各終端的多個視頻分別封裝在各自的一個下行rtp流中發(fā)送給第一類終端。

對于第二類終端，根據(jù)as最新指示的當(dāng)前發(fā)言人，選定對應(yīng)當(dāng)前發(fā)言人的一路視頻流進行轉(zhuǎn)發(fā)。

圖16為本發(fā)明實施例實現(xiàn)多方會議的又一種裝置的組成結(jié)構(gòu)示意圖，該裝置可以設(shè)置在第一類終端中，如圖16所示，至少包括發(fā)送模塊，第三處理模塊；其中，

發(fā)送模塊，用于向as發(fā)送加入多方會議的請求，其中攜帶音頻信息和/或視頻信息；

第三處理模塊，用于接收來自as的處理后的協(xié)商好的視頻和/或音頻；與音頻服務(wù)器和/或視頻分發(fā)服務(wù)器傳遞音頻媒體流和/或視頻媒體流。

對于新用戶加入后，videorelay的后續(xù)操作需要按照as的指示進行的情況，進一步地，

第三處理模塊還用于：接收來自as的重協(xié)商視頻參數(shù)的請求，完成媒體協(xié)商；當(dāng)采用信令面屏蔽多流的模式時，接收來自視頻分發(fā)服務(wù)器的封裝有多個視頻流的一個下行rtp流；當(dāng)采用信令面識別多流的模式時，接收來 自視頻分發(fā)服務(wù)器的分別封裝有與不同用戶對應(yīng)的視頻流的多個下行rtp流。

以上所述，僅為本發(fā)明的較佳實例而已，并非用于限定本發(fā)明實施例的保護范圍。凡在本發(fā)明實施例的精神和原則之內(nèi)，所做的任何修改、等同替換、改進等，均應(yīng)包含在本發(fā)明實施例的保護范圍之內(nèi)。