TWI829058B - 用於在多媒體通訊中使用壓縮並行轉碼器的方法和裝置 - Google Patents

用於在多媒體通訊中使用壓縮並行轉碼器的方法和裝置 Download PDF

Info

Publication number
TWI829058B
TWI829058B TW110148867A TW110148867A TWI829058B TW I829058 B TWI829058 B TW I829058B TW 110148867 A TW110148867 A TW 110148867A TW 110148867 A TW110148867 A TW 110148867A TW I829058 B TWI829058 B TW I829058B
Authority
TW
Taiwan
Prior art keywords
transcoder
listed
parallel
list
terminal
Prior art date
Application number
TW110148867A
Other languages
English (en)
Other versions
TW202218416A (zh
Inventor
尼古拉康拉德 梁
葉奎 王
拉瑪恰德蘭 蘇巴馬尼恩
Original Assignee
美商高通公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 美商高通公司 filed Critical 美商高通公司
Publication of TW202218416A publication Critical patent/TW202218416A/zh
Application granted granted Critical
Publication of TWI829058B publication Critical patent/TWI829058B/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/15—Conference systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/756—Media network packet handling adapting media to device capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/403—Arrangements for multi-party communication, e.g. for conferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/141—Systems for two-way working between two video terminals, e.g. videophone
    • H04N7/147—Communication arrangements, e.g. identifying the communication as a video-communication, intermediate storage of the signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/15—Conference systems
    • H04N7/152—Multipoint control units therefor

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Telephonic Communication Services (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Telephone Function (AREA)

Abstract

揭示用於會議中的通信期啟動的方法和裝置。在一個態樣中，揭示一種用於多方之間的通訊的方法。該方法包括以下步驟：在第一設備處，產生第一訊息以向第二設備傳輸。該方法亦包括以下步驟：在第一設備處，接收第二訊息以建立會議。第二訊息包括第二設備支援的一或多個並行轉碼器能力的列表。第二設備支援的一或多個並行轉碼器能力的列表包括如下指示：可用於第一列出的轉碼器的一或多個並行實例的一或多個資源，是否可以替代地用於第二列出的轉碼器的一或多個並行實例。

Description

用於在多媒體通訊中使用壓縮並行轉碼器的方法和裝置
本案內容係關於轉碼器協商領域，具體而言，本案內容係關於分散式多媒體會議和通訊中的壓縮並行轉碼器協商。
能夠將數位視訊和音訊能力併入到各種各樣的設備中，其包括數位電視、數位直接廣播系統、無線廣播系統、個人數位助理（PDA）、膝上型電腦或桌面型電腦、數位相機、數位記錄設備、數位媒體播放機、視訊遊戲設備、視訊遊戲控制台、蜂巢或衛星無線電電話、視訊電話會議設備等等。數位視訊和音訊設備實現視訊和音訊壓縮技術，例如，由運動圖像專家組2（MPEG-2）、MPEG-4、國際電報聯盟電信標準化部門（ITU-T）H.263、ITU-T H.264/MPEG-4、第10部分所定義的標準、高級視訊編碼（AVC）、高效率視訊編碼（HEVC）標準，以及該等標準的擴展裡所描述的彼等技術。視訊和音訊設備可以經由實現該等視訊和音訊編碼技術，來更有效地傳輸、接收、編碼、解碼及/或儲存數位視訊和音訊資訊。
諸如可伸縮HEVC（SHVC）和多視角HEVC（MV-HEVC）的視訊和音訊編碼標準提供用於定義解碼器能力的層級（level）定義。在下文中，基於在進行發明時SHVC的現有層級定義和其他上下文來描述問題和解決方案，但該等解決方案亦適用於MV-HEVC以及其他多層轉碼器。
落入所附請求項的保護範疇內的系統、方法和設備的各種實施方式各具有一些態樣，該等態樣中沒有單個態樣單獨地對本文描述的所期望的屬性負責。在不限制所附請求項的保護範疇的情況下，本文描述了一些突出的特徵。
在附圖和下文的描述中，闡述了本說明書中描述的標的的一或多個實施方式的細節。經由該等描述、附圖和請求項，其他特徵、態樣和優點將變得顯而易見。應當注意，附圖中的相對尺寸可能沒有按比例進行圖示。
在一個態樣中，揭示一種用於多方之間進行通訊的方法。該方法包括以下步驟：在第一設備處，產生第一訊息以向第二設備傳輸。該方法亦包括以下步驟：在該第一設備處，接收第二訊息以建立會議。該第二訊息包括該第二設備支援的一或多個並行轉碼器能力的列表。該第二設備支援的一或多個並行轉碼器能力的該列表包括如下指示：可用於第一列出的轉碼器的一或多個並行實例的一或多個資源，是否可以替代地用於第二列出的轉碼器的一或多個並行實例。
本案內容的另一態樣是一種用於啟動採用複數個轉碼器的多方、多串流會議的裝置。該裝置包括處理器和接收器。該處理器被配置為產生第一訊息以向第一設備傳輸。該接收器被配置為，從該第一設備接收第二訊息以建立會議。該第二訊息包括該第一設備支援的一或多個並行轉碼器能力的列表。該第一設備支援的一或多個並行轉碼器能力的該列表包括如下指示：可用於第一列出的轉碼器的一或多個並行實例的一或多個資源，是否可以替代地用於第二列出的轉碼器的一或多個並行實例。
本案內容的另一態樣是一種用於啟動採用複數個轉碼器的多方、多串流會議的裝置。該裝置包括：用於產生第一訊息以向第一設備傳輸的構件以及用於從該第一設備接收第二訊息以建立會議的構件。該第二訊息包括該第一設備支援的一或多個並行轉碼器能力的列表。該第一設備支援的一或多個並行轉碼器能力的該列表包括如下指示：可用於第一列出的轉碼器的一或多個並行實例的一或多個資源，是否可以替代地用於第二列出的轉碼器的一或多個並行實例。
本案內容的額外的態樣是一種包括指令的非暫時性電腦可讀取媒體，當執行該等指令時，該等指令使處理器執行方法。該方法包括以下步驟：在第一設備處，產生第一訊息以向第二設備傳輸。該方法亦包括以下步驟：在該第一設備處，接收第二訊息以建立會議。該第二訊息包括該第二設備支援的一或多個並行轉碼器能力的列表，其中該第二設備支援的一或多個並行轉碼器能力的該列表包括如下指示：可用於第一列出的轉碼器的一或多個並行實例的一或多個資源，是否可以替代地用於第二列出的轉碼器的一或多個並行實例。
下文結合附圖闡述的具體實施方式意欲作為對本發明的某些實施方式的描述，而不是要表示可以實踐本發明的唯一實施方式。遍及本描述所使用的術語「示例性」意味著「用作示例、實例或說明」，並且不應被解釋為對於其他示例性實施方式是較佳的或有優勢的。具體實施方式包括出於提供對所揭示的實施方式的透徹理解目的的具體細節。在一些實例中，以方塊圖的形式圖示一些設備。
視訊編碼標準包括ITU-T H.261、ISO/IEC MPEG-1視訊、ITU-T H.262或ISO/IEC MPEG-2視訊、ITU-T H.263、ISO/IEC MPEG-4 視訊和ITU-T H.264（其亦稱為ISO/IEC MPEG-4 AVC），包括其可伸縮視訊編碼（SVC）擴展和多視角視訊編碼（MVC）擴展。
此外，ITU-T視訊編碼專家組（VCEG）的視訊編碼聯合協調小組（JCT-VC）和ISO/IEC MPEG已經開發一種視訊編碼標準，亦即高效率視訊編碼（HEVC）。針對HEVC草案10的全文引用是Bross等人於2013年1月14日至2013年1月23日在瑞士日內瓦的ITU-T視訊編碼聯合協調小組（JCT-VC） SG16 WP3和ISO/IEC JTC1/SC29/WG11，第12次會議上的題為「High Efficiency Video Coding (HEVC) Text Specification Draft 10」的文件JCTVC-L1003。此外，JCT-3V（ITU-T/ISO/IEC三維視訊編碼擴展開發聯合協調小組）和JCT-VC亦分別正在開發HEVC多視角擴展，亦即MV-HEVC，和HEVC可伸縮擴展，亦即SHVC。MV-HEVC的最新工作草案（WD）將在下文中稱為MV-HEVC WD7。SHVC的最新WD將在下文稱為SHVC WD5。
層級定義的現有方法有時不能提供足夠的資訊以定義解碼器能力來高效解碼多層位元串流。例如，為了對多於4個的各具有720p解析度的訊雜比（SNR）可伸縮層（具有等同解析度的層）進行解碼，將需要層級5解碼器或者更高層級的解碼器。因此，亮度編碼樹區塊（CTB）大小將等於32x32或64x64（亦即，不能使用諸如16x16的更小的編碼大小）。但是，對於一些層，例如具有720p或更低的解析度的彼等層，此種限制可能導致次優的編碼效率。
在一些實例中，可以經由重用多個現有的單層解碼器來製造解碼器。在實例中，由4個單層HEVC 層級3.1解碼器組成的SHVC解碼器將必須符合層級4或者更高層級，以根據現有的層級定義來解碼720p的4個SNR層。經由該定義，解碼器將必須能夠對任何層級4位元串流進行解碼。然而，除非對解碼器硬體進行改變，否則此種解碼器將不能解碼具有1080p解析度的2個SNR層的SHVC 層級4位元串流。
現有HEVC層級定義的另一問題是，以能夠解碼1080p的單層HEVC位元串流和720p的雙層SHVC位元串流兩者的方式實現的解碼器將被標記為層級3.1。但是，層級3.1標記並不表示對1080p的單層位元串流進行解碼的能力。
在另一實例中，對於根據現有的層級定義，能夠對720p的4個SNR層進行解碼的使用4個單層HEVC 3.1解碼器實現的解碼器而言，該解碼器將必須符合層級4或者更高層級。因此，將需要解碼器能夠對具有多於3個並聯（tile）行和多於3個並聯（tile）列的位元串流進行解碼，每個並聯具有256個亮度取樣的寬度和144個亮度取樣的高度。但是，解碼器的層級3.1限制將不能對一些此種位元串流進行解碼。
在SHVC的現有設計下，將HEVC文字的A.4.1節中的所有項目指定為適用於每個層。但是，一些項目不能直接適用於每個層。例如，針對解碼圖像緩衝區（DPB）大小上的項目d，序列參數集（SPS）語法元素不適用於增強層。此外，SHVC WD5中的DPB是共享子DPB設計，因此不能直接將項目d應用於每個層。作為另一實例，針對編碼圖像緩衝區（CPB）大小上的項目h和i，針對位元串流特定的CPB操作，不能將參數應用於每個層。
需要對CPB大小（按照HEVC文字的A.4.1節中的項目h和i）進行位元串流特定的限制。然而，不能將HEVC文字的A.4.1節中的項目h和i直接應用於位元串流層級，因為若直接應用，則針對單層位元串流的相同CPB大小限制亦將是針對多層位元串流的限制。此情形對於多個層而言將是不可縮放的，並且當有很多層時，此情形將僅允許低的圖像品質。
將經由HEVC文字A.4.2節中的項目b、c、d、g、h、i和j進行的限制指定為僅是層特定的。但是，應該指定經由該等項目進行位元串流特定的限制，而不管是否指定了其層特定的對應物。
儘管本文在HEVC及/或H.264標準的上下文中描述了某些實施例，但一般技術者應當理解，本文所揭示的系統和方法可以適用於任何適當的視訊編碼標準或者非標準視訊轉碼器設計。例如，本文所揭示的實施例可以適用於以下標準中的一或多個標準：國際電信聯盟（ITU）電信標準化部門（ITU-T）H.261、國際標準組織/國際電子電機委員會（ISO/IEC）MPEG 1視訊、ITU-T H.262或ISO/IEC MPEG-2視訊、ITU-T H.263、ISO/IEC MPEG 4視訊和ITU-T H.264（其亦稱為ISO/IEC MPEG-4 AVC），包括可伸縮擴展和多視角擴展。
在很多態樣中，HEVC整體上遵循先前的視訊編碼標準的框架。HEVC中的預測單元與某些先前的視訊編碼標準中的預測單元（例如，巨集區塊）不同。事實上，如某些先前的視訊編碼標準中理解的，在HEVC中不存在巨集區塊的概念。巨集區塊由基於四叉樹方案的層次結構來代替，此舉可以提供高靈活性以及其他可能的益處。例如，在HEVC方案內，定義了三種類型的區塊：編碼單元（CU）、預測單元（PU）和變換單元（TU）。CU可以代表區域分離的基本單元。可以將CU認為是類似於巨集區塊的概念，但是HEVC並不限制CU的最大大小，並且可以允許遞迴地分離成四個相等大小的CU以提高內容自我調整性。可以將PU認為是訊框間/訊框內預測的基本單元，並且單個PU可以包含多個任意形狀的分區以有效地編碼不規則圖像模式。可以將TU認為是變換的基本單元。能夠獨立於PU來定義TU；但是，可能將TU的大小限制為TU所屬的CU的大小。將區塊結構分成三個不同的概念可以允許每個單元根據單元的相應角色進行最佳化，此舉可以實現改良的編碼效率。
僅僅為了說明的目的，利用僅包括視訊及/或音訊資料的兩個層（例如，諸如基本層的下層以及諸如增強層的上層）的實例來描述本文揭示的某些實施例。視訊資料的「層」通常可以代表具有至少一個諸如視角、訊框速率、解析度等的共同特徵或者參數的圖像序列。例如，層可以包括與多視角視訊資料的特定視角（例如，視點）相關聯的視訊資料。作為另一實例，層可以包括與可伸縮視訊資料的特定層相關聯的視訊資料。因此，本案內容可以互換地代表視訊資料的層和視角。亦即，視訊資料的視角可以稱為視訊資料的層，視訊資料的層可以稱為視訊資料的視角。此外，多層轉碼器（其亦稱為多層視訊轉碼器或者多層編碼器-解碼器）可以聯合地代表多視角轉碼器或者可伸縮轉碼器（例如，被配置為使用MV-HEVC、3D-HEVC、SHVC或者另一多層編碼技術對視訊資料進行編碼及/或解碼的轉碼器）。視訊編碼和視訊解碼二者通常可以稱為視訊編碼。應當理解的是，該等實例可適用於包括多個基本層及/或增強層的配置。此外，為了便於解釋，下文的揭示內容包括參照某些實施例的術語「訊框」或者「區塊」。但是，該等術語並不意味著是限制性的。例如，下文描述的技術可以利用諸如區塊（例如，CU、PU、TU、巨集區塊等等）、切片（slice）、訊框等的任何適當的視訊單元來使用。 視訊編碼標準
諸如視訊圖像、TV圖像、靜止圖像或者由視訊記錄器或電腦產生的圖像的數位圖像，可以由以水平和垂直線排列的圖元或取樣組成。單個圖像中的圖元數量通常為數萬。每個圖元通常包含亮度和色度資訊。在不壓縮的情況下，要從圖像編碼器傳送到圖像解碼器的全量的資訊將使得即時圖像傳輸變得不可能。為了減少要傳輸的資訊量，已經開發了許多不同的壓縮方法，例如JPEG、MPEG和H.263標準。視訊編碼標準包括本文先前所描述的彼等標準。 多串流 多方會議
在一些實施例中，在多串流多方會議中，期望支援多串流視訊、至少兩個視訊內容（例如，一個主要內容和一個演示內容）、多串流音訊、至少2個音訊內容，以及其他額外的能力。在一些態樣中，中央處理器或者橋接器可以用於支援該等功能。中央處理器或橋接器可以接收多串流視訊/音訊資料、對視訊/音訊資料進行混合並將混合後的資料串流發送給參與方中每一個參與方。
圖1是用於多個參與方的示例性會議架構100的圖。會議架構100包括終端110A-D和中央處理器125。在一些態樣中，中央處理器125可以包括伺服器或者會議橋接器提供器。中央處理器125可以從終端110A-D中的每一個終端接收資料串流、解碼、混合並向終端110A-D傳輸混合後的資料串流。在一些態樣中，中央處理器125可以使用多播傳輸來傳輸混合後的資料串流。在一些實施例中，資料串流可以包括一或多個音訊、視訊及/或媒體串流。在一些態樣中，終端110A-D各可以包括處理器、接收器、傳輸器、收發機、天線、記憶體、資料庫和使用者介面中的一者或多者。
在一些實施例中，可能期望建立不具有中央處理器125的多串流多方會議。例如，中央處理器125可能需要單獨的基礎設施和服務，此舉可能增加成本及/或複雜度。在一些實施例中，複雜度可以是至少部分地基於多串流會議的一或多個媒體串流的複雜度的。額外地，可能需要參與方在多串流多方會議之前，與中央處理器125進行建立或者註冊。因此，可能期望參與方在其終端（例如，電腦、平板設備、智慧型電話、其他使用者設備等）上建立多串流多方會議，而不使用中央處理器125（例如，分散式會議）。
圖2是用於多個參與方的分散式會議架構200的實例的圖。如圖2中所示，分散式會議架構200可以包括終端110A、110B和110C。終端110A、110B和110C可以彼此之間交換資料串流，並且可以對其接收及/或發送的資料串流進行解碼、編碼及/或混合。例如，如圖2中所示，參與方110A從終端110B和110C接收資料串流，並向終端110B和110C傳輸資料串流。該等資料串流可以包括媒體串流、音訊串流、視訊串流或者該等串流的組合。可以在每個終端處獨立地和並行地對該等多個資料串流進行解碼並且隨後混合在一起（較佳地具有一些感知的空間分離），然後將混合後的資料串流渲染給觀看者或收聽者。終端110A、110B和110C中的每一個終端可能對於其能夠並行操作的解碼器/編碼器實例的數量具有計算限制。在一些態樣中，當建立採用終端內混合的多串流多方會議（例如，分散式會議）時，可能期望會議啟動方考慮該等限制。
如上文參照圖2描述的，可能需要終端110A、110B和110C中的每一個終端並行解碼從其他會議參與方接收的多個資料串流。每個終端110可能對於其能夠並行操作的解碼器實例的數量具有計算限制。此計算限制限制了能夠與終端進行會議的參與方的數量，或者要求終端具有優先解碼某些資料串流並忽略其他資料串流的能力。例如，若終端沒有忽略其接收的任何資料串流，則參與方的數量必須小於或等於解碼器的最大數量加1（N＜=MaxDec+1）。其中N是會議中的包括會議啟動方在內的參與方的數量，以及MaxDec是能夠由終端並行執行的解碼器的最大數量。在一些實施例中，終端110A可以經由與終端110B和110C連接來啟動會議，並且隨後終端110B和110C可以彼此連接以完成會議。
參照圖2，若終端110A是會議啟動方，則終端110A可以使用上文的計算來決定邀請多少撥叫者/終端到該會議（亦即，N-1）。此外，若其他終端（例如，終端110B和110C）中的每一個終端沒有對其接收的資料串流進行優先化和忽略，則每個終端亦可能能夠解碼N-1個資料串流。因此，可能期望啟動方終端110A考慮下文的限制：N＜=Min [每個終端的MaxDec]+1。因此，啟動方終端110A考慮會議之每一者參與終端能夠並行執行的解碼器的最大數量，並能夠確保參與方的數量不超過各解碼器最大數量中的最小值加1。
類似地，採用終端內混合的會議可能需要終端對發送給其他參與終端的多個資料串流進行並行編碼。當啟動方針對資料類型提供多於一種類型的轉碼器，並且其他參與方選擇使用不同的轉碼器時，就可能發生此種情形。在一些態樣中，資料類型可以包括音訊類型、視訊類型或者其他媒體類型。
在圖1和圖2中描述的集中式或分散式會議架構中，在向參與會議的一或多個終端傳送通信期描述協定（SDP）要約（offer）訊息之前，中央處理器或啟動方終端（取決於架構的類型）可以經由SDP前的協商階段，決定將何種資訊包括在SDP要約訊息中。在該協商階段期間，中央處理器或啟動方終端可以請求形成適用的會議架構的其他終端的編碼和解碼能力。可以在離散的協商訊息中傳送針對其他終端的編碼和解碼能力的請求。協商訊息可以被配置為包括發送終端或者處理器的能力的資訊，以及關於將作為會議的一部分傳送的一或多個媒體串流的資訊。
在一些實施例中，協商訊息可以用作並行轉碼器能力交換（CCCex）。在一些實施例中，要約訊息和應答訊息亦可以用作CCCex，如本文所描述的。因此，可以將協商訊息實現為包括，關於傳輸設備的編碼和解碼能力的屬性及/或鑒於會議中可能涉及的媒體串流的編碼和解碼要求。可以將該等能力和需求資訊中的大部分資訊包括在終端和中央處理器之間傳送的SDP要約訊息和回應訊息中。但是，經由在傳送SDP要約訊息和回應訊息之前執行能力的協商或者交換，可以對SDP要約訊息和回應訊息進行精簡和簡化，以僅包括對於在會議架構的設備之間建立會議有用的資訊。對於會議啟動方能夠建立不超過任何一個參與方的並行編碼和解碼能力的會議而言，先前的通訊和能力交換亦是必需的。因此，被傳送以交換並行轉碼器能力的協商訊息可以包括SDP要約訊息和回應訊息將包括的資訊中的至少一些資訊。
協商訊息可以被配置為包括級聯形式的必要的SDP要約資訊和回應資訊，使得可以有效地在終端及/或處理器之間傳送協商訊息，並且不會對網路及/或處理資源造成壓力。例如，在協商訊息中，可以可選地包括各種參數，同時該等各種參數可以始終保持在SDP要約訊息和回應訊息中。在一些實施例中，協商訊息可以在單行訊息中，傳送包括在SDP要約訊息和回應訊息中的超過40行資訊。
在一些實施例中，本文描述的協商訊息可以是作為請求一或多個終端提供其並行轉碼器能力的協商請求訊息發送的。在一些實施例中，本文描述的協商訊息可以是作為回應於協商請求訊息的協商回應訊息發送的。在一些實施例中，協商請求訊息可以包括發送請求的終端或處理器的能力。在一些實施例中，協商回應訊息可以包括與請求終端或處理器的能力有關的回應終端或處理器的能力，或者獨立於請求終端或處理器的能力的回應終端或處理器的能力。在一些實施例中，協商訊息，作為請求訊息或者作為回應訊息，可以包括轉碼器能力的列表的指示，如本文更詳細描述的。
例如，可以將從啟動方終端傳送的協商訊息定義為包括如下所述的期望的屬性及/或資訊。應當注意，下文是協商訊息結構的增強型Backus-Naur形式（ABNF）表示： codec_list = "a" "=" "codec_list" ":" codeclist ":" "ENC:" num [*63(rule num)] ":" "DEC:" num [*63(rule num)] codeclist = "{" codec SP [level] SP [profile] "};" *63(";{" codec SP [level] SP [profile] "}") codec = byte-string; RFC 4566中定義的位元組串 level = 1*3DIGIT profile = 1*3DIGIT rule = ";" / "," num = %d1-16
因此，上文的ABNF代碼對應於如何可以產生包括並行轉碼器能力資訊的協商訊息以進行傳送。協商訊息可以包括發送訊息的實體能夠使用的轉碼器的列表（例如，由發送訊息的實體支援的轉碼器的列表）。在一些實施例中，發送協商訊息（作為回應或者請求）的任何實體能夠接收相應的協商（請求或者回應）訊息。
為了減少與SDP要約訊息和回應訊息有關的協商訊息的大小，可以在協商訊息中排除或者調整各種參數及/或資訊。例如，在一些實施例中，可以將能夠標識視訊轉碼器解析度的轉碼器層級參數可選地包括在協商訊息中，因為不是所有轉碼器皆可以包括轉碼器層級及/或轉碼器層級資訊。類似地，可以可選地包括各種其他參數，因此與SDP要約訊息和回應訊息相比，協商訊息能夠在大小上減小。
此外，協商訊息可以被配置為指示一或多個轉碼器可以何時或者如何由其他轉碼器替代（例如，用於一或多個轉碼器的資源可以替代地由其他轉碼器使用）。例如，協商訊息可以指示中央終端能夠經由複數個轉碼器對通訊進行解碼。例如，中央終端可以指示其能夠解碼增強型語音服務（EVS）、自我調整多速率（AMR）和自我調整多速率寬頻（AMR-WB），同時指示根據需要，在處理器上執行的EVS的實例可以由AMR-WB的實例替代，AMR-WB的實例可以由AMR的實例替代。額外地，協商訊息亦可以被配置為要求與＜codec＞實例的數量相同的＜num＞實例（如本文的訊息定義中所展示的）。在一些實施例中，儘管一或多個參數被包括在SDP要約訊息及/或回應訊息中，但是可以從協商訊息中排除該一或多個參數。
在一些實施例中，如上文的協商訊息定義中指示的，＜codec＞項對應於如在即時通訊協定（RTP）有效負荷格式中針對轉碼器定義的該轉碼器的媒體類型名稱。在一些實施例中，＜codec＞項的實例可以分別地包括對應於H.264視訊壓縮轉碼器的「video/H264」及/或對應於H.265視訊壓縮轉碼器的「video/H265」。由＜codec＞項標識的轉碼器可以對應於發送協商訊息的終端或處理器被配置為用於對媒體串流進行編碼及/或解碼的轉碼器。協商訊息可以包括由＜codec＞項標識的一或多個轉碼器；例如，如＜codec＞項標識的轉碼器，本文展示的協商訊息#1包括EVS、AMR和ARM-WB。
如前述，＜level＞項是可選的。＜level＞項可以指定轉碼器的層級，該層級針對視訊轉碼器標識支援何種解析度。例如，當＜codec＞項指示H.264或H.265轉碼器時，＜level＞項可以分別等於level_idc或者level-id。當＜codec＞項指示EVS轉碼器時，＜level＞項可以等於1、2、3及/或4，其分別指定窄頻（NB）、WB、超寬頻（SWB）和全頻段（FB）。
額外地，＜profile＞項在協商訊息中亦是可選的。＜profile＞項可以指定轉碼器的簡介（profile），該簡介針對視訊轉碼器標識視訊轉碼器使用何種標準化的工具。例如，針對＜codec＞項指示的轉碼器H.264和H.265，＜profile＞項可以分別指示或者等於profile_idc和profile-id。若在協商訊息中包括＜profile＞項，則亦必須包括＜level＞項。另一態樣，准許協商訊息在不包括＜profile＞項的情況下，包括＜level＞項。
協商訊息的＜rule＞項可以指定用於轉碼器的並行實例的資源是否可以替代地由在該轉碼器之前或者之後列出的轉碼器的並行實例使用。例如，在本文描述的協商訊息#1中，＜codec＞項標識AMR、AMR-WB和EVS轉碼器（但不必以該順序）。基於＜rule＞項，下一個列出的轉碼器可以是計算複雜度更低的，並因此可以與先前列出的轉碼器在相同的處理器上執行。例如，當＜rule＞項等於「，」時，則＜codec＞項的一或多個實例可以由接下來的一或多個列出的轉碼器替代。但是，＜rule＞項亦可以指示下一個列出的轉碼器是計算複雜度更大的，或者是在單獨的處理器上實現的，並因此不能與先前列出的轉碼器在相同的處理器上執行。例如，當＜rule＞項等於「；」時，則＜codec＞項的一或多個實例可能 不由下一個列出的轉碼器替代。因此，＜rule＞項可以被配置為向接收協商訊息的終端及/或處理器展示解碼處理器比編碼處理器更靈活。
在本文的協商訊息#1中展示的＜num＞項可以指定所支援的並行編碼器或並行解碼器的最大數量。例如，當＜num＞項在協商訊息中跟著文字「ENC」時，＜num＞項指示所支援的由＜codec＞項（當存在時，在指定的層級和簡介處）指定的轉碼器中的每一個轉碼器的並行編碼器的最大數量。類似地，當＜num＞項在協商訊息中跟著文字「DEC」時，＜num＞項指示由＜codec＞項（當存在時，在指定的層級和簡介處）指定的轉碼器的所支援的並行解碼器的最大數量。由緊跟著文字「ENC」的＜num＞項標識的實例數量，以及由緊跟著文字「DEC」的＜num＞項標識的實例的數量兩者皆應當與由＜codec＞項標識的實例的數量相同。此外，在一些實施例中，可以以相同的順序，將由＜num＞項標識的實例映射到由＜codec＞項標識的實例上。
在一些實施例中，終端及/或處理器可以具有修剪其實際解碼的接收到的媒體串流的數量（m行）的能力。因此，終端及/或處理器可以通告具有指示以下內容的值的＜num＞項：與終端及/或處理器實際具有的進行解碼的並行解碼能力相比，該終端及/或處理器能夠解碼更大數量的媒體串流。
根據本文的描述，協商訊息可以在單個SDP行中，提供由終端及/或處理器支援的並行轉碼器能力（其包括編碼器能力和解碼器能力兩者）的通訊及/或協商。例如，下文的表1描述了典型的SDP要約訊息。該SDP要約訊息可以對應於被配置成MSMTSI終端的啟動方終端的配置「A」，如結合表2描述的。 表1
SDP 要約
**m=audio 49152 RTP/AVP 96 97 98b=AS:42 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 **a=rtpmap:96 EVS/16000/1 **a=fmtp:96 br=13.2-24.4; bw=wb-swb; max-red=220 **a=rtpmap:97 AMR-WB/16000/1 **a=fmtp:97 mode-change-capability=2; max-red=220 **a=rtpmap:98 AMR/8000/1 **a=fmtp:98 mode-change-capability=2; max-red=220 a=ptime:20 a=maxptime:240 **a=simulcast: send pt:96;97;98 recv pt:96,97,98  **m=audio 49154 RTP/AVP 101 102 103b=AS:42 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 **a=recvonly **a=rtpmap:101 EVS/16000/1 **a=fmtp:101 br=13.2-24.4; bw=wb-swb; max-red=220 **a=rtpmap:102 AMR-WB/16000/1 **a=fmtp:102 mode-change-capability=2; max-red=220 **a=rtpmap:103 AMR/8000/1 **a=fmtp:103 mode-change-capability=2; max-red=220 a=ptime:20 a=maxptime:240 **a=simulcast: recv pt:101,102,103  **m=audio 49156 RTP/AVPF 104 105 106b=AS:42 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 **a=recvonly **a=rtpmap:104 EVS/16000/1 **a=fmtp:104 br=13.2-24.4; bw=wb-swb; max-red=220 **a=rtpmap:105 AMR-WB/16000/1 **a=fmtp:105 mode-change-capability=2; max-red=220 **a=rtpmap:106 AMR/8000/1 **a=fmtp:106 mode-change-capability=2; max-red=220 a=ptime:20 a=maxptime:240 **a=simulcast: recv pt:104,105,106  **m=audio 49158 RTP/AVP 107 108b=AS:42 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 **a=recvonly **a=rtpmap:107 AMR-WB/16000/1 **a=fmtp:107 mode-change-capability=2; max-red=220 **a=rtpmap:108 AMR/8000/1 **a=fmtp:108 mode-change-capability=2; max-red=220 a=ptime:20 a=maxptime:240 **a=simulcast: recv pt:107,108  **m=audio 49160 RTP/AVPF 109b=AS:29 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 **a=recvonly **a=rtpmap:109 AMR/8000/1 **a=fmtp:109 mode-change-capability=2; max-red=220 a=ptime:20 a=maxptime:240 **a=simulcast: recv pt:109
如上所示，SDP要約訊息包括超過40個SDP行。該等SDP行中的大部分SDP行可以包括在本文描述的協商訊息中包括的資訊。但是，儘管該等行可以包括SDP要約訊息中的將近40個單獨的SDP行，但本文描述的協商訊息可以將該40行減少到單個行。此種可擴展SDP要約訊息的減少，降低了每一個終端及/或處理器進行接收、處理以及對於SDP要約訊息和回應訊息進行回應本該需要的通訊和計算資源的數量。例如，本文描述的協商訊息將上文的表1中的以「**」偏移的SDP要約訊息行（等於38個SDP行）減少到單個行的協商訊息#1： 協商訊息 #1a = codec_list:EVS;AMR-WB;AMR:ENC:1;1;1:DEC:3,1,1
此外，當在協商訊息中進行傳送時，下文的表2中展示的針對配置「B」和「C」的SDP要約訊息亦可以進行類似地減少。例如，用於下文的組合「B」的SDP要約訊息的42個SDP行，可以經由協商訊息#2的單個SDP行來替代： 協商訊息 #2a = codec_list:EVS;AMR-WB;AMR:ENC:1;1;0:DEC:4,1,0
類似地，下文的組合「C」的SDP要約訊息的44個SDP行，可以經由協商訊息#3的單個SDP行來替代： 協商訊息 #3a = codec_list:EVS;AMR-WB;AMR:ENC:1;0;0:DEC:5,0,0 表 2 ： MSMTSI 終端中的示例性並行轉碼器能力配置
參與方的數量 在MSMTSI終端處支援的CCCEx組合
N = 6 A.[Encoder/send: AMR, AMR-WB, EVS] [Decoder/recv: 1 AMR, 1 AMR-WB, 3 EVS]   B.[Encoder/send: AMR-WB, EVS] [Decoder/recv: 1 AMR-WB, 4 EVS]   C.[Encoder/send: EVS] [Decoder/recv: 5 EVS]
因此，總之，使用如本文描述的協商訊息可以在三個SDP行中傳送124個SDP行，同時維持具有六個參與方的CCCex（如表2中所述），其等於通訊管理負擔的大於41：1的減少。因此，使用本文描述的協商訊息，通常可以根據下文的壓縮比來減少SDP行。 壓縮比 1≥(5*(N-2)+4):1，其中 l N是並行解碼器（例如，使用者）的數量；及 l m是支援並行解碼器的轉碼器的組合的數量。 因此，可以提供顯著的通訊和處理管理負擔和資源的節省。
在一些實施例中，為了進一步減少通訊和計算資源，終端可以被配置為在對接收到的串流進行解碼之前，「修剪」接收到的串流的數量。修剪可以涉及減少將被解碼的接收到的串流的數量並且修剪可以節省終端處的解碼計算資源。此種「修剪」能力可以經由以下方式來指示：終端經由列出與該終端能夠並行解碼的媒體串流相比更多的媒體串流（例如，m行）來廣播SDP要約。因此，該終端可以被配置為產生新的壓縮SDP屬性以包括上至12個或更多個並行解碼器，從而將壓縮比增加到≥54:1。
在一些實施例中，如本文進一步描述的，一旦如前述地交換了協商訊息，則終端或處理器中的一或多個終端或處理器就可以產生和傳送一或多個要約訊息及/或資料串流，以傳送給一或多個其他終端或設備。在一些實施例中，可以使用轉碼器能力的列表的指示以選擇用於通訊的轉碼器的類型，如本文更詳細描述的。例如，協商回應訊息可以指示終端被配置為處理何者轉碼器，並且處理器（或者啟動方終端）可以基於協商回應訊息的指示來選擇轉碼器類型。在一些實施例中，可以將針對任何給定處理器或終端的轉碼器能力的列表的指示符或指示儲存在資料庫或其他儲存位置，及/或可以從資料庫或其他儲存位置取得針對任何給定處理器或終端的轉碼器能力的列表的指示符或指示。在一些實施例中，會議支援的轉碼器能力的列表可以是至少部分地基於兩個或更多個設備中的每一個設備支援的轉碼器能力的列表的指示。
圖3圖示用於多個參與方的分散式會議架構300的另一實例。在一些實施例中，啟動方終端110A可以向終端110B和110C要約提供（offer）多個轉碼器。可以在使用上文描述的協商訊息的協商完成之後傳送該等要約（offer）。例如，如圖3中所示，終端110A向終端110B和110C要約提供增強型語音服務（EVS）轉碼器和自我調整多速率寬頻（AMR-WB）兩者。在一些態樣中，該要約可以包括通信期描述協定（SDP）要約訊息。如圖所示，終端110C支援EVS並利用選擇EVS的訊息進行回應。終端110B可以僅支援AMR-WB，並且在其對終端110A的回應中選擇AMR-WB。在一些態樣中，終端110B和110C回應於來自終端110A的要約而發送的訊息可以包括SDP應答訊息。此外，終端110B和110C亦可以執行其自己的轉碼器協商（例如，經由來自終端110A的通信期啟動協定（SIP）REFER方法來建立），其中終端110B和110C選擇AMR-WB，因為終端110B不支援EVS。如從圖3能夠看到的，終端110A和110C必須在EVS和AMR-WB格式兩者中並行地編碼其內容，而終端110B僅需要在AMR-WB格式中進行編碼/解碼。
圖4是在終端/媒體閘道450用作混合器的情況下，用於多個參與方的示例性混合會議架構400的圖。如圖4中所示，終端110A-C各可以向終端/媒體閘道450發送資料串流，該終端/媒體閘道450隨後向終端110A-C發送多個資料串流。例如，終端/媒體閘道450可以從終端110B和110C接收資料串流，對該等資料串流進行解碼並將該等資料串流發送給終端110A。在一些態樣中，終端/媒體閘道450可以對來自終端110B和110C的資料串流進行混合，向終端110A發送混合後的資料串流。
在一個實施方式中，終端110A可以基於某些限制或者會議參數來調整該終端110A從終端/媒體閘道450接收的資料串流的數量。例如，終端110A可以使用終端/媒體閘道450（或者圖1的中央處理器125）處理能力以減少或者卸載其自己的處理，或者確保會議架構（無論集中式、分散式還是混合的）限制內的高效通訊。在一個態樣中，終端110A可以請求終端/媒體閘道450僅發送一個混合後的資料串流，因為終端110A可能僅能夠解碼一個資料串流，或者因為終端110A具有有限的處理能力。
額外地，可能的是，圖1-圖4（和下文的圖5）中的終端110A-D、中央處理器125及/或終端/媒體閘道450能夠切換能力。例如，終端110A-D和中央處理器125可以在圖1的會議架構100中進行操作並且中央處理器125可能丟失功率或者丟失混合能力。在一些態樣中，終端110D可以從作為會議參與方進行操作切換到作為圖4的非參與的終端/媒體閘道450進行操作，本質上是替代中央處理器125功能。額外地，圖4的終端/媒體閘道450亦可以經由向會議中的一或多個參與方（例如，終端110A-D）發送其自己的資料串流來作為會議中的參與的終端/媒體閘道450進行操作。因此，終端110A-D、中央處理器125及/或終端/媒體閘道450中的每一者皆可以被配置為在圖1的集中式會議架構100、圖2和圖3的分散式會議架構200和300以及圖4的混合會議架構400中的一或多個架構中進行操作。
在一個實例中，會議（例如，會議架構100、200、300、400和500[下文將論述]）可以具有包括第一持續時間和第二持續時間的會議持續時間。在一些態樣中，在第一持續時間期間，終端110D可以作為會議參與方進行操作，如圖1中所示。在一些態樣中，在第二持續時間期間，終端110D可以切換到作為終端/媒體閘道450進行操作，如圖4（和下文的圖5）中描述的。在一些態樣中，終端110D可以請求將操作功能切換到中央處理器125、切換到終端110A-C中的一或多個終端（如圖1中所示）或者切換到另一控制器或設備。在其他態樣中，中央處理器125或者終端110A-C中的一或多個終端（如圖1中所示）可以決定終端110D能夠切換到作為終端/媒體閘道450進行操作。
在一些態樣中，可以在第一持續時間期間發生會議啟動或者關聯，並且可以在第二持續時間期間發生會議資料的交換。例如，參照圖2和圖3，在第一持續時間期間，終端110A可以向終端110B和110C傳輸包括終端110A支援的轉碼器能力的列表的要約訊息。終端110A可以從終端110B和110C中的每一個終端接收回應訊息。回應訊息可以包括相應的終端110B或110C的轉碼器能力的列表以及終端110B和110C選擇的轉碼器類型。終端110A可以基於每一個回應訊息中的轉碼器能力的列表來決定終端110B和110C中的每一個終端是否能夠參與會議。在第二持續時間期間，終端110A-C可以彼此之間交換資料串流。
在一些態樣中，中央處理器125或者終端110A-C中的一或多個終端可以請求終端110D切換到作為終端/媒體閘道450進行操作。在一些實施例中，請求可以是基於終端110D的編碼/解碼能力的，及/或基於中央處理器125或者終端110A-C中的一或多個終端的編碼/解碼能力的。例如，終端110A可以決定其僅能夠接收兩個資料串流，並且可以請求終端110D切換操作。請求可以包括：請求終端110D對來自終端110B和110C的通訊進行處理和混合，以及請求終端110D向終端110A發送混合後的資料串流。在一些態樣中，可以從終端110A、110D或者中央處理器125中的一者向終端110B和110C傳輸請求，該請求指示新的會議標識符或針對終端110B和110C的會議統一資源標識項（URI）是針對終端110D的位址。在一些態樣中，可以經由帶外通訊來發送用於處理和混合終端110B和110C的資料串流的請求或者新目的地（亦即，終端110D）的指示。回應於該請求，終端110B和110C可以隨後從向中央處理器125發送資料串流切換到向終端110D發送資料串流。為了減少切換涉及的潛在延時問題，終端110B和110C可以向中央處理器125和終端110D兩者發送資料串流，直到中央處理器125及/或終端110D決定切換完成的時間為止。
圖5是當終端/媒體閘道450用作混合器和參與方時，用於多個參與方的示例性混合會議架構500的圖。如圖5中所示，終端110A可以啟動與作為會議的參與方的終端110B、終端/媒體閘道450和終端110D-E的會議。終端110A可以經由任何方法來啟動會議，使得參與方（終端110B、終端/媒體閘道450和終端110D-E）加入該會議。例如，終端110A可以使用與參與方的帶外通訊（例如，指示會議的電子郵件通訊及/或會議橋接器）來啟動會議。在一些態樣中，終端110A亦可以經由採用上文描述的針對終端110B和終端/媒體閘道450的REFER方法，結合對終端110D和110E的帶外通訊來啟動會議，以使該等終端經由終端/媒體閘道450加入會議。在其他態樣中，終端110A可以經由宣告會議的開始的輪詢訊息來啟動該會議，並且終端110B和110D-E和終端/媒體閘道450可以傳輸具有其轉碼器能力的訊息以加入會議。如前述，啟動會議的其他方法亦是可以的。
如上文參照圖1-圖4論述的，終端110A可以在啟動會議時，考慮每一個參與方的編碼/解碼能力。在圖5中，終端110A可以向終端110B傳輸資料串流516、向終端/媒體閘道450傳輸資料串流519並且分別從終端110B和終端/媒體閘道450接收資料串流517和521。終端110B亦可以向終端/媒體閘道450傳輸資料串流518，並且從終端/媒體閘道450接收資料串流520。終端/媒體閘道450亦可以分別從終端110D和110E接收資料串流524和525，並且分別向終端110D和110E傳輸資料串流522和523。資料串流516-525中的每一個資料串流可以包括一或多個音訊及/或視訊（媒體）串流。
在一些實施例中，終端/媒體閘道450用作會議中的混合器和參與方兩者。例如，終端/媒體閘道450可以從終端110A接收資料串流519、從終端110B接收資料串流518、從終端110D接收資料串流524、從終端110E接收資料串流525。在一些態樣中，終端110D和110E僅能夠各對一個資料串流進行解碼，而終端110A和110B能夠各對三個資料串流進行解碼。在一些態樣中，與終端110D和110E相比，可以將終端110A和110B認為是新型的或者更高效的終端。在一些態樣中，與終端110A和110B相比，可以將終端110D和110E認為是傳統的或者更舊的設備。在一個實施例中，終端/媒體閘道450可以向終端110D傳輸單個混合後的資料串流522，並且向終端110E傳輸單個混合後的資料串流523。在一些態樣中，終端/媒體閘道450可以向終端110D和110E傳輸多播混合後的資料串流，同時並行地向終端110A和110B發送單播資料串流521和520。額外地，終端/媒體閘道450可以向終端110A傳輸資料串流521，該資料串流521可以包括來自終端110B的資料串流、來自終端/媒體閘道450的資料串流以及來自終端110D和110E的混合後的資料串流。
在其他態樣中，終端/媒體閘道450可以傳輸來自會議中的其他參與方的資料串流的其他組合。例如，終端/媒體閘道450可以忽略來自終端110E的資料串流，並且僅向終端110A傳輸來自終端110B、110D和終端/媒體閘道450的資料串流。終端/媒體閘道450（以及終端110A、110B、110D和110E中的任何終端）可以根據本文描述的任何實施方式或者組合來優先化、選擇及/或忽略某些資料串流。在另一示例性實施例中，終端/媒體閘道450可以從終端接收資料串流並且標識是活動語音（例如，110B、110C）的串流以及是背景/非活動語音（例如，110D、110E）的串流。終端/媒體閘道450可以選擇對DTX/非活動訊框進行解碼和混合，並將其作為一個非活動訊框連同多個活動訊框一起進行傳輸（例如，向終端110A傳輸）。在具有較大數量的參與方（例如，N＞10）的多方會議中，上文論述的在終端/閘道450處的對於DTX/非活動訊框的選擇性預解析和混合，可以減少在終端處接收到的用於處理的多個串流的數量。現在，接收終端（例如，110A）可以具有更少的串流以針對解碼進行檢查和優先化。在另一示例性實施例中，終端/媒體閘道450可以決定與DTX/非活動訊框相關聯的相應的視訊串流，並執行該等視訊/圖像資料串流向一個視訊串流的並聯/重新編碼，從而減少在終端處接收到的用於處理的多個視訊串流的數量。
如上文參照圖4論述的，在一些態樣中，圖5的終端110A、110B、110D、110E和終端/媒體閘道450中的任何一者可以以各種方式來切換操作功能。例如，終端110B和終端/媒體閘道450可以決定（例如，經由帶外通訊或者經由轉碼器能力的分析）將終端/媒體閘道450的混合操作轉移到終端110B。在一些態樣中，終端/媒體閘道450及/或終端110B可以直接或者間接地（例如，帶外或者經由另一個終端）向其他會議參與方廣播：終端110B正在接管終端/媒體閘道450的處理和混合操作。儘管將終端110B論述成接管終端/媒體閘道450的處理操作，但在其他實施例中，終端110A、110D或110E中的任何一個終端或者另一設備可以類似地替代終端/媒體閘道450的處理及/或混合操作。
在其他實施例中，終端/媒體閘道450可以使用REFER方法以向其他會議參與方廣播，以將會議參與方正在向終端/媒體閘道450發送的會議資料串流轉移到現在向終端110B發送會議資料串流。此外，會議參與方可以在一段時間內，向終端/媒體閘道450和終端110B兩者發送其相應的資料串流，直到所有的會議參與方皆向終端110B傳輸其資料串流。類似地，終端/媒體閘道450和終端110B可以在一段時間內，對其從其他會議參與方接收的多個資料串流進行並行地處理和混合，直到終端/媒體閘道450及/或終端110B決定所有終端皆已經進行了切換，以減少潛在的中斷或者延時問題。
在一些實施例中，在要提供的資訊的細微性以及用於指示能夠支援更多並行操作的能力的功能（ability）之間，可能存在某種平衡。可能存在下文的場景或者設備：供應商或服務供應商希望傳送關於能夠支援的並行通信期的細節資訊，例如，為多方會議專門設計的高端商業終端。另一態樣，可能存在沒有被設計為在通信期中支援多於3-4個參與方的中端或者低端終端，對於該等終端供應商或服務供應商僅希望暴露非常基本的功能。由於要傳送的資訊的合適的量可能取決於場景和設備，因此可能期望適應不同的情況。不是選擇上文描述的格式中的一種格式，而是在一些態樣中，終端（例如，終端110A-E或者終端/媒體閘道450）可以能夠選擇所描述的格式中的任何格式。必須從會議參與方接收所有轉碼器能力資訊的啟動方終端（例如，終端110A），應當能夠對所有格式進行解碼和理解。
滿足針對轉碼器能力資訊的上文格式要求的一個實例是傳送每一個資料類型（例如，音訊或視訊）或者每一個轉碼器的並行實現的最大數量。
每資料類型的限制
例如，能夠如下地定義新的通信期級SDP屬性： a = max_dec_audio:＜num_instances＞ a = max_dec_video:＜num_instances＞ a = max_enc_audio:＜num_instances＞ a = max_enc_video:＜num_instances＞
在一些態樣中，＜num_instances＞是位於包括性的1到16的範圍內的整數，其指定由終端支援的該資料類型（例如，針對第一和第三的音訊，或者針對第二和第四的視訊）的並行解碼器（針對前兩個）或者編碼器（針對後兩個）的最大數量。
或者，能夠如下地定義新的資料級SDP屬性： a = max_dec:＜num_instances＞ a = max_enc:＜num_instances＞
在一些態樣中，＜num_instances＞是位於包括性的1到16的範圍內的整數，其指定由終端支援的（在「m=」行上的最後項的）資料類型的並行解碼器的最大數量（針對a=max_dec）或者並行編碼器的最大數量（針對a=max_enc）。
在一些實施例中，此種示例性解決方案可能不能滿足上文描述的對轉碼器能力資訊的格式要求。在一些態樣中，可以經由最計算密集的轉碼器來約束並行實例的最大數量。在示例性實施例中，針對其中終端支援H.265轉碼器並宣稱其能夠支援多達兩個視訊轉碼器事件（H.264和H.265）且知道其必須針對該兩個視訊轉碼器預留足夠的資源的視訊電話通信期，終端可能在其能夠處理的資料（例如，視訊或語音）的解碼器實例的數量上受限制。
在一些態樣中，對於解碼器實例的數量的限制，可能阻止終端被包括在具有更大數量的使用較不複雜解碼器的參與方的會議中，或者阻止會議中的所有參與方在該通信期中使用更高級的可選的轉碼器。
每轉碼器類型的限制
額外地，能夠如下地定義新的SDP參數： a=max_dec:＜codec＞ ＜num_instances＞ a=max_enc:＜codec＞ ＜num_instances＞
在一些態樣中，＜codec＞是如針對轉碼器的RTP有效負荷格式中定義的該轉碼器的資料類型名稱，例如分別地，如IETF RFC 6184中定義的用於H.264的「video/H.264」（在https://tools.ietf.org/html/rfc6184可獲得），以及如H.265 RTP有效負荷格式中定義的用於H.265的「video/H.265」（其最新版本位於：https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-14）。在一些態樣中，＜num_instances＞是位於包括性的1到16的範圍內的整數，其指定：指定的轉碼器的並行解碼器的最大數量（針對a=max_dec）或者並行編碼器的最大數量（針對a=max_enc）。
在其他實施方式中，為了考慮不同層級的視訊轉碼器可能具有不同的能力，能夠如下地定義新的資料級SDP屬性： a=max_dec:＜codec＞ ＜level＞ ＜num_instances＞ [＜profile＞] a=max_enc:＜codec＞ ＜level＞ ＜num_instances＞ [＜profile＞]
在一些態樣中，＜codec＞與上文的相同。在一些態樣中，＜level＞指定轉碼器的層級，例如，針對H.264和H.265，該值分別等於如ITU-T H.264規範中定義的level_idc和如H.265 RTP有效負荷格式（其最新版本位於：https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-14）中定義的level-id，並且當轉碼器是EVS時，該欄位的值為1、2、3和4分別指定NB、WB、SWB和FB。在一些態樣中，＜num_instances＞是位於包括性的1到16的範圍內的整數，其指定：在指定的層級和簡介（當存在時）處的指定的轉碼器的並行解碼器的最大數量（針對a=max_dec）或者並行編碼器的最大數量（針對a=max_enc）。在一些態樣中，＜profile＞是可選的，其指定轉碼器的簡介，例如，針對H.264和H.265，該值分別等於如ITU-T H.264規範中定義的profile_idc和如H.265 RTP有效負荷格式（其最新版本位於：https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-14）中定義的profile-id。
在一些實施例中，對於所有上文的替代方案，針對＜num_instances＞亦可以允許0的值，值0指定終端能夠對資料串流進行挑選和修剪。在一些態樣中，能夠對資料串流進行挑選和修剪的終端能夠處理無限數量的資料串流。
在其他實施方式中，用於視訊轉碼器的另一替代方案可以是要定義新的SDP屬性，如下所述： a=max_vdec_cap:＜codec＞ ＜max_block_ps＞ a=max_venc_cap:＜codec＞ ＜max_block_ps＞
在一些態樣中，＜codec＞與如前述的相同。在一些態樣中，＜max_block_ps＞指定：指定的視訊轉碼器的所有並行視訊解碼器能夠處理的每秒8x8亮度區塊的最大數量（針對a=max_vdec_cap）或者所有並行編碼器能夠處理的每秒8x8亮度區塊的最大數量（針對a=max_venc_cap）。
在一些實施例中，該示例性解決方案可能不滿足上文描述的針對轉碼器能力資訊的格式要求。在一些態樣中，可能不清楚的是，當存在轉碼器的混合時，會議啟動方終端（例如，圖2-圖5的終端110A）如何能夠準確地決定能夠支援多少並行編碼器和解碼器。在一些實施例中，用於估計能夠支援多少並行編碼器和解碼器的方式，是使用正在使用的計算最為繁重的轉碼器的編碼器/解碼器限制。在一些態樣中，編碼器/解碼器限制可以經由最複雜轉碼器來約束，該最複雜轉碼器可以限制終端能夠處理的資料（例如，視訊或語音）的解碼器實例的數量。例如，在一些態樣中，對解碼器實例的數量的限制，可能阻止終端被包括在具有更大數量的使用較不複雜解碼器的參與方的會議中，或者可以阻止會議中的所有參與方在該通信期中使用更高級的可選的轉碼器。
滿足上文的針對轉碼器能力資訊的格式要求的另一實例，是描述針對每個編碼/解碼功能可用的或者分配的處理器資源的百分比。此舉允許啟動方終端混合並匹配轉碼器（包括不同資料類型的彼等轉碼器）以及其編碼器和解碼器，只要其保持總複雜度負荷不大於給定處理器中的所分配資源的100%。描述上文的資訊的一種方式，可以是引入兩個新的SDP屬性： a=enc_use:＜codec＞ ＜alloc_factor＞ ＜proc_idx＞ a=dec_use:＜codec＞ ＜alloc_factor＞ ＜proc_idx＞ 其中＜alloc_factor＞的範圍從0到1.0，並且描述當使用具有處理器索引＜proc_idx＞的處理器以進行編碼（針對a=enc_use）或者解碼（針對a=dec_use）時，用於指定的轉碼器的資源分配因數。
在其他實施例中，描述上文的資訊的另一方式可以是引入兩個新的SDP屬性： a=enc_use:＜codec＞ ＜level＞ ＜alloc_factor＞ ＜proc_idx＞ [＜profile＞] a=dec_use:＜codec＞ ＜level＞ ＜alloc_factor＞ ＜proc_idx＞ [＜profile＞]
在一些態樣中，＜codec＞、＜level＞和＜profile＞與如前述的相同。在一些態樣中，＜alloc_factor＞的範圍從0到1.0，並且描述當使用具有處理器索引＜proc_idx＞的處理器以進行編碼（針對a=enc_use）或者解碼（針對a=dec_use）時，用於指定的層級處的指定的轉碼器的資源分配因數。在一些實施例中，啟動方終端可以使用上文的來自每個參與方的資訊以確保所提議的會議不超過參與方的並行轉碼器能力中的任何並行轉碼器能力。 能夠如下文的表3來將資訊概念化： 表 3
資料類型 轉碼器名稱 用於編碼器的資源分配因數 用於解碼器的資源分配因數 proc_num
音訊 AMR-NB 0.1 0.02 1
音訊 AMR-WB 0.2 0.04 1
音訊 EVS (WB) 0.24 0.09 2
音訊 EVS (SWB) 0.28 0.12 2
視訊 AVC/H.264 0.6 0.15 1
視訊 HEVC/H.265 0.9 0.23 2
列出轉碼器的並行轉碼器組合簡介
滿足上文的用於轉碼器能力資訊的格式要求的另一示例性解決方案，是列出終端能夠同時處理的轉碼器操作的所有組合。此舉可以具有不需要傳送由每個轉碼器功能消耗的處理器負荷的優點。下文的表4提供了基於在先前部分中描述的處理器負荷因數的所支援的簡介的非詳盡列表。例如，處理器負荷因數可以包括上文參照表3描述的資源分配因數。在一些態樣中，終端對於轉碼器類型或者資料類型的選擇可以是基於處理器負荷因數或者資源分配因數的。
在一些實施例中，（在增強型backus-naur形式（ABNF）中）定義了兩個新的SDP屬性：a=enc_list和a=dec_list，如下所述： enc_list = "a" "=" "enc_list" ":" combination [*63(";" combination)] dec_list = "a" "=" "dec_list" ":" combination [*63(";" combination)] combination = 1*32(num SP codec SP level SP [profile])) num = %d1-16 codec = byte-string ; RFC 4566中定義的位元組串 level = 1*3DIGITDIGIT profile = 1*3DIGIT
在一些態樣， num指定列表的條目中的指定的層級和簡介（當存在時）處的指定的轉碼器的所支援的並行編碼器的最大數量（針對a=enc_list）或者並行解碼器的最大數量（針對a=enc_list）。在一些態樣中，上文的列表的條目中給定的 codec、 level和 profile分別與＜codec＞、＜level＞和＜profile＞具有相同的語義。
或者，可以在ABNF中定義新的SDP屬性，如下所述： codec_list = "a" "=" "enc_list" ":" function ":" combination [*63(";" combination)] function = "ENC" / "DEC" combination = 1*32(num SP codec SP level SP [profile]) num = %d1-16 codec = byte-string ; RFC 4566中定義的位元組串 level = 1*3DIGIT profile = 1*3DIGIT
在一些態樣中， num指定列表的條目中的指定的層級和簡介（當存在時）處的指定的轉碼器的所支援的並行編碼器（當 function=「ENC」時）或者並行解碼器（當 function=「DEC」時）的最大數量。在一些實施例中，上文給定的 codec、 level和 profile分別與＜codec＞、＜level＞和＜profile＞具有相同的語義。
在其他實施例中，可以在ABNF中定義新的SDP屬性，如下所述： codec_list = "a" "=" "codec_list" ":" codeclist ":" "ENC:" combination [*63(";" combination)] ":" "DEC:" combination [*63(";" combination)] codeclist = "{" codec SP level SP [profile] "};" *15(";{" codec SP level SP [profile] "}") combination = 1*32(num SP codec_idx) codec = byte-string ; RFC 4566中定義的位元組串 level = 1*3DIGIT profile = 1*3DIGIT num = %d1-16 codec_idx = %d1-16
在一些態樣中，上文給定的 codec、 level和 profile分別與＜codec＞、＜level＞和＜profile＞具有相同的語義。在一些態樣中， num指定在指定的層級和簡介（當存在時）處的指定的轉碼器的所支援的並行編碼器（當「combination」跟隨「ENC」時）或者並行解碼器（當「combination」跟隨「DEC」時）的最大數量。在一些態樣中，codec_idx指定在指定的層級和簡介（當存在時）處的指定的轉碼器的列表轉碼器列表的索引。
在一些實施例中，可以將 num定義為num=%d0-16。除了上文的描述和等式之外，值0指定該終端能夠對資料串流進行挑選和修剪。在一些態樣中，能夠對資料串流進行挑選和修剪的終端能夠處理無限數量的資料串流。
在其他實施例中，在上文的替代方案中，其中 num位於包括性的1到16的範圍內，如下地定義一或多個新的SDP屬性： a=stream_trimming
在一些態樣中，該屬性的存在指定該終端能夠對資料串流進行挑選和修剪。在一些態樣，能夠對資料串流進行挑選和修剪的終端可以處理無限數量的資料串流。組合中的 num的值仍然指定特定的轉碼器、簡介和層級實際支援的並行編碼器或並行解碼器的最大數量。在該情況下，終端能夠接收任意數量的資料串流，並且能夠將資料串流修剪成針對每個轉碼器/簡介/層級組合的a=codec_list屬性允許的數量。
在一些態樣中，可能存在多個轉碼器組合，其隨著所支援的轉碼器的數量增加而指數地增加。此情形能夠增加訊息大小，例如，SDP/SIP。例如，能夠經由應用諸如以複雜度的降冪來列出轉碼器功能的額外的規則來實現訊號傳遞的某種減少。隨後，應當理解，若更高複雜度的轉碼器功能的實例的數量減少一個，則相同處理器上的較不複雜的轉碼器功能中的一個功能的實例能夠增加至少一個。儘管在一些態樣中，當實例數量減少的轉碼器程序比其他轉碼器程序更複雜時，此情形可能提供次最優的限制，但其可以允許省略多個簡介。在一些態樣中，若終端需要產生與完全解析度圖像進行聯播的縮略圖，則相同視訊轉碼器的並行操作可能是必需的。 表 4
簡介 編碼器 解碼器
視訊 音訊 視訊 音訊
H.265 H.264 EVS AMR-WB AMR-NB H.265 H.264 EVS AMR-WB AMR-NB
負荷因數 0.8 0.6 0.5 0.2 0.08 0.2 0.15 0.1 0.04 0.02
A 1     1 1 1 4   1 4
B 1     1 1 1 4   2 2
C 1     1 1 1 4   3  
D 1     1 1 1 1   10 8
E   1 1   1 1 1 3 2 4
F     1 1 1     5 12 12
G   1 1   1   2 5   1
H   1 1   1 1 2 3   1
I   1 1   1 1 1 3 2 4
…                    
所支援的並行轉碼器組合的簡介
表4中列出的簡介不能很好地應用於需要使用相同轉碼器的視訊聯播的使用情形（亦即，低和高解析度圖像），因為在一個時間僅支援一個編碼器。此情形可能是處理器負荷而不是簡介方案本身的限制。
在一些實施例中，表4中的簡介A到D能夠被認為是以不允許使用EVS為代價來使用H.265的「HD Video」簡介。儘管簡介A到C可以處理四個H.264串流的解碼，但簡介A到C可能不能用於典型的多點單播（multi-unicast）視訊會議，因為簡介A到C可能僅能夠對一個視訊串流進行編碼。在一些態樣中，該終端的使用者可能希望僅向其他參與方中的一個參與方發送視訊，例如，用於傳送符號語言的視訊側欄對話。
除了簡單的兩方視訊通信期之外，簡介A到D可能更適用於多播或者「基於聚焦的多播（focused-based multicast）」會議，其中已知所有終端皆支援H.265轉碼器。應當注意，若AMR-NB是用於正在提供的服務的強制性轉碼器，則簡介C可以認為是無效的，因為不支援AMR-NB解碼。
在一些態樣中，簡介F能夠被認為是要用於僅有語音的會議中的「HD Voice only」簡介。由於還要標識需要使用相同的編碼器來同時編碼語音的使用情形，所以僅有語音的簡介可以僅需要考慮並行操作每個語音編碼器的一個實例。此舉可以簡化針對僅有語音的會議需要列出的簡介的數量，並且簡介F呈現為是僅有的相關的僅有語音的簡介，因為支援多於13個參與方的會議是不可能的，並且非常可能超過終端的RTP串流處理限制（下文將進一步描述）。
針對在不需要解碼所有接收到的媒體串流的情況下，對接收到的媒體串流執行修剪或者減少的終端而言（如下文進一步描述的），如以下表5中所示，能夠將解碼器功能的實例的數量指示為「無限（infinity）」。表5說明針對能夠向下修剪到三個接收到的音訊資料串流的終端的示例性實施例： 表 5
簡介 編碼器 解碼器
視訊 音訊 視訊 音訊
H.265 H.264 EVS AMR-WB AMR-NB H.265 H.264 EVS AMR-WB AMR-NB
負載因數 0.8 0.6 0.5 0.2 0.08 0.2 0.15 0.1 0.04 0.02
A 1     1 1 1 4   1 Inf
B 1     1 1 1 4   2 2
C 1     1 1 1 4   Inf 0
D 1     1 1 1 1   Inf Inf
E   1 1   1 1 1 Inf 2 Inf
F     1 1 1     Inf Inf Inf
G   1 1   1   2 Inf   1
H   1 1   1 1 2 Inf   1
I   1 1   1 1 1 Inf 2 Inf
…                    
如上文參照圖1-圖5描述的，接收終端或者設備（例如，終端110B、終端/媒體閘道450等）能夠對特定的資料串流進行優先化和忽略，以減少其必須並行操作/解碼的解碼器實例的數量。若終端採用此種「修剪」演算法，並能夠限制其必須解碼的資料串流的數量以匹配其並行解碼能力，則該終端不需要會議啟動方基於該終端的解碼能力來限制撥叫中的參與方的數量。在該情況下，終端能夠指示與該等資料串流相對應的0的資源分配因數，如下文的表6的實例中所示： 表 6
資料類型 轉碼器名稱 用於編碼器的資源分配因數 用於解碼器的資源分配因數 proc_num
音訊 AMR-NB 0.1 0 1
音訊 AMR-WB 0.2 0 1
音訊 EVS (WB) 0.24 0 2
音訊 EVS (SWB) 0.28 0 2
視訊 AVC/H.264 0.6 0.15 1
視訊 HEVC/H.265 0.9 0.23 2
RTP串流處理限制
支援並行解碼很多資料串流的能力，使得解碼可能不是設置會議的大小的限制因素成為可能。終端的協定堆疊能夠處理的即時傳輸協定（RTP）資料串流的數量變成限制因素。因此，傳送該資訊亦可能是有益的。此外，能夠定義兩個新的通信期級SDP屬性，以指定對並行RTP堆疊的數量的限制： a=rtp_tx_limit:＜rtp_instances＞ a=rtp_rx_limit:＜rtp_instances＞
在一些態樣中，＜rtp_instances＞是位於包括性的1到32的範圍內的整數，其指定所支援的並行RTP通信期的最大數量。在一些態樣中，會議啟動方終端（例如，圖2-圖5的終端110A）使用來自於會議之每一者參與方的上述資訊以確保提議的會議不超過參與方的轉碼器或RTP處理能力。
在一些實施例中，啟動方終端可以基於其並行轉碼器能力以及預先知道其並行能力的其他參與方的並行轉碼器能力來發送要約訊息。在接收到該要約訊息之後，每個參與方的終端可以檢查要約訊息以決定N和所要約提供的轉碼器的最大數量，以決定其是否能夠滿足在先前部分中描述的約束。若終端能夠參與，則其可以用經選擇的轉碼器進行回應。
在另一實施例中，其他參與終端（例如，終端110B和110C）亦能夠在回應訊息中，包括其並行轉碼器能力。此舉允許啟動方終端儲存並保證針對相同的啟動方終端啟動的任何未來的會議恰當地考慮了終端的能力。在一些態樣中，啟動方終端可以將該等能力儲存在資料庫中。
若參與終端決定其不能夠參與，則其在回應訊息中指示該情況，並發送其並行轉碼器能力。隨後，啟動方終端可以對來自其他參與終端的回應進行處理，如下所述：（1）若啟動方終端未接收到否定回應，則其允許會議繼續；（2）若啟動方終端接收到否定回應，則其使用所有接收到的並行轉碼器能力來構建可行的要約訊息，並在新的訊息（例如，SIP Re-INVITE/UPDATE訊息）中向參與方中的一些參與方或全部參與方傳輸該可行的要約訊息。
在一些實施例中，每個終端可以將其位址簿或者資料庫中的每一個終端的並行轉碼器能力簡介進行儲存。該簡介能夠包括針對每個終端的每種資料類型的MaxEnc和MaxDec。在其他態樣中，該簡介能夠包括針對所有資料類型的終端的轉碼器的列表，以及轉碼器的每個實例使用的資源分配因數或者處理器複雜度的百分比。例如，下文的表7說明針對所有資料類型的終端的轉碼器的示例性列表，以及轉碼器的每個實例使用的處理器複雜度的百分比。 表 7
資料類型 轉碼器名稱 編碼器複雜度 解碼器複雜度
音訊 AMR-NB 10% 2%
音訊 AMR-WB 20% 4%
音訊 EVS 60% 20%
視訊 H.264/AVC 60% 15%
視訊 H.265/HEVC 90% 23%
在一些態樣中，啟動方終端能夠隨後使用每個參與方的上文簡介以決定在使用本文描述的約束考慮的情況下每個參與方皆能夠滿足的要約訊息。
在傳送終端的並行轉碼器能力時，終端亦能夠指示其能夠處理更多資料串流的接收，因為其能夠對特定資料類型的資料串流進行優先化和忽略。例如，終端110A可以指示其能夠並行地解碼多達三個EVS資料串流（每個使用其處理器的20%），之後，其將會忽略接收到的任何額外的資料串流。
在一些態樣中，終端亦能夠在啟動會議之前，交換並行轉碼器能力資訊，以更好地保證將可行的要約訊息包括在第一個啟動訊息（例如，第一個SIP INVITE）中。能夠如下所述地執行此種並行轉碼器能力資訊的交換：當使用者向終端上的其位址簿或者目錄增加另一使用者時，位址簿應用程式進行彼此聯絡以交換並行轉碼器能力以及任何其他個人資訊（家庭位址等），或者當終端的轉碼器能力發生改變時（經由下載或者終端硬體的交換）。能夠使用在使用者之間提供的任意聯絡資訊標識符（ID），來執行資訊/簡介的此種交換。例如，若ID是電子郵寄位址，則經由電子郵件交換中的嵌入的簡介多目的網際網路郵件擴展（MIME）類型；若ID是電話號碼，則經由經由簡訊服務（SMS）發送的可擴展標示語言（XML）方案；經由某種其他訊息傳輸協定發送的XML方案。能夠以多種方式來更新簡介資訊。例如，使用者彼此之間或者經由先前描述的協定進行撥叫，來建立採用終端內混合的會議，亦即，能夠在回應中發送並行轉碼器能力。在另一實例中，儲存該簡介的終端可以設置計時器，以自主地和定期地（例如，每月）檢查其他使用者的終端，以查看能力是否發生了改變。因為使用者的軟體更新或者軟體下載或者改變了其手持裝置，所以該等能力可能發生改變。在一些態樣中，每當已經提供簡介的終端自身的能力發生變化時，其可以更新其位址簿中的所有使用者。或者，當會議中的兩個或更多個參與方（該等參與方不是啟動方）在其之間建立資料通信期時，該會議中的兩個或更多個參與方能夠交換其並行轉碼器能力。
在一些態樣中，能夠使用OPTIONS請求以經由如下方式來查詢另一終端的轉碼器能力：要求終端發送用於描述終端的轉碼器能力的終端將要約提供的通信期描述協定（SDP）的副本。該SDP將包含如前述的並行轉碼器能力資訊。能夠在會議撥叫的很長時間之前來進行OPTIONS請求，並且可以將SDP回應儲存在用於受查詢的終端的簡介中。在一些實施例中，在緊鄰建立會議之前，會議啟動方能夠查詢其計畫邀請的、會議啟動方對其沒有預先儲存的資訊的所有終端的轉碼器能力。
圖6是用於會議中的轉碼器協商的另一示例性方法的流程圖。圖10中所圖示的方法600可以經由會議架構100、200、300及/或400中的一或多個設備來實現。在一些態樣中，方法可以由類似於圖1-圖4中的使用者終端110A-D及/或中央處理器125的設備或者任何其他適當的設備來實現。
在方塊605處，終端或者處理器可以向兩個或更多個設備傳輸請求訊息，該請求訊息請求兩個或更多個設備中的每一個設備支援的轉碼器能力的列表。訊息可以包括終端或者處理器支援的轉碼器能力的列表的指示。在一些態樣中，訊息可以是基於啟動方終端或者處理器的並行轉碼器能力的。在一些實施例中，訊息亦可以是基於預先知道其並行能力的其他參與方的轉碼器能力的。
在方塊610處，終端從兩個或更多個設備中的每一個設備接收回應訊息，該回應訊息包括兩個或更多個設備中的每一個設備支援的轉碼器能力的列表的指示。在一些態樣中，在接收到回應之後，終端或處理器可以對接收到的訊息進行處理，以決定多個參與方的轉碼器能力的經過指示的列表。
在一些實施例中，可以使用壓縮CCC SPD要約和應答，在多串流多方會議媒體處理（MMCMH）通信期建立中類似地減少SDP參數。本文描述的壓縮CCC SDP參數的ABNF定義可以應用於針對MMCMH通信期建立的壓縮CCCEx和CCC兩者。但是，儘管使用針對CCCEx的壓縮CCC允許將CCC壓縮到單個SDP行，但使用壓縮CCC進行MMCMH通信期啟動可能會受到以下內容的限制：針對SDP要約的需要是要符合SDP要約/應答模型或期望的。例如，在MMCMH通信期建立中，SDP要約可以包含足夠的媒體行，以允許SDP應答選擇終端（例如，要約方（offeror）終端和應答終端）支援的轉碼器配置的任意組合。例如，在要約中必須存在至少R個媒體行，其中R是要約方終端能夠並行地接收和解碼的最大數量的串流。
如本文演示的，能夠執行針對MMCMH通信期建立的壓縮CCC SDP要約參數。在一些實施方式中，要約方終端（例如，尋求建立MMCMH通信期的終端）可以獲得三種音訊轉碼器（AMR-NB、AMR-WB和EVS）。「A」對應於並行AMR-NB轉碼器的最大數量，而「B」對應於並行AMR-WB轉碼器的最大數量，並且「C」對應於並行EVS轉碼器的最大數量，其中由於A、B和C的相對複雜性，因此A＞=B＞=C。因此，當產生要約訊息時，要約方終端可以列出總共A個媒體行，其中該A個媒體行中的每一個媒體行包括AMR-NP作為轉碼器。類似地，要約方終端可以列出總共B個媒體行，其中B個媒體行將包括AMR-WB作為轉碼器，接收到與AMR-NB的聯播。額外地，要約方終端可以列出將包括EVS作為轉碼器的總共C個媒體行，接收到與AMR-WB和AMR-NB兩者的聯播。當指示要約方終端的發送/編碼能力時，上文的媒體行中的一或多個媒體行亦可以在聯播發送配置中包括所有轉碼器。
上文的A個媒體行可以覆蓋能夠在SDP應答中進行選擇的所有可能的媒體配置。為了對於選擇一或多個可接受配置的要約進行回應，應答終端可以在依賴於亦包括在該要約中的壓縮CCC SDP行的情況下，傳送其應答。
如本文所描述的，不使用壓縮CCC SDP行的SDP要約可以包括以下媒體行的集合以傳送基本相同的資訊： l 「A」個媒體行，其指示支援最大數量的可解碼串流時的配置。此情形可以對應於使用壓縮CCC，除了在聯播接收配置中將至少存在具有兩個轉碼器的B個媒體行和具有三個轉碼器的C個媒體行。該等額外的轉碼器中的每一個轉碼器將在媒體行中增加兩個更多的SDP行；及 l 用於能夠支援並行解碼的串流的不同數量和集合的每個配置的媒體行集合。
例如，若要約方終端支援單個EVS解碼器，則要約方終端將AMR-NB串流的最大數量從A減少到要約訊息中的A 1EVS。額外地，要約訊息可以包括列出多個AMR-NB轉碼器的A 1EVS+1個接收媒體行的單獨集合以及一個包含EVS轉碼器的行。此外，當未使用壓縮CCC SDP行時，媒體行集合中的每一個將需要不同的媒體配置，如在MediaCapNeg框架中指定的。
在下文的表中，說明當未使用壓縮CCC SDP參數時，可以傳送的不同的配置集合的實例。該表包括針對N=6的三個配置（A、B和C）。但是，針對N的不同值可能存在不同的配置集合，其中N是會議中的參與方的數量，包括要約方終端和所有應答終端。
參與方的數量 在終端處支援的並行轉碼器組合 從終端到 MRF 的針對簡介 A 、 B 和 C 的 SDP 要約實例（出於說明目的，下文僅僅展示音訊） ; 在下文所展示的實例中，終端將發送與簡介 A 或 B 或 C 的 CCCEx 相關聯的 SDP 要約中的一個要約 在接收到例如 SDP 要約 A (N=6) 之後，從 MRF 到終端的 SDP 應答
N＜=6 [Enc/send: AMR, AMR-WB, EVS] [Dec/recv: 1 AMR, 1 AMR-WB, 3 EVS]   [Enc/send: AMR-WB, EVS] [Dec/recv: 1 AMR-WB, 4 EVS]   [Enc/send: AMR, EVS] [Dec/recv: 1 AMR, 4 EVS] A   m=audio 49200 RTP/AVP 99 100 101 a=rtpmap:99 AMR/8000/1 a=rtpmap:100 AMR-WB/16000/1 a=rtpmap:101 EVS/16000/1 a=simulcast: send 99;100;101 recv 99,100,101 ... m=audio 49300 RTP/AVP 99 100 101 a=rtpmap:99 AMR/8000/1 a=rtpmap:100 AMR-WB/16000/1 a=rtpmap:101 EVS/16000/1 a=simulcast: recv 99,100,101 ... m=audio 49400 RTP/AVP 99 100 101 a=rtpmap:99 AMR/8000/1 a=rtpmap:100 AMR-WB/16000/1 a=rtpmap:101 EVS/16000/1 a=simulcast: recv 99,100,101 ... m=audio 49500 RTP/AVP 99 100 a=rtpmap:99 AMR/8000/1 a=rtpmap:100 AMR-WB/16000/1 a=simulcast: recv 99,100 ... m=audio 49600 RTP/AVP 99 a=rtpmap:99 AMR/8000/1 a=recv 99 ...     m=audio 49200 RTP/AVP 99 100 101 a=rtpmap:99 AMR/8000/1 a=rtpmap:100 AMR-WB/16000/1 a=rtpmap:101 EVS/16000/1 a=simulcast: recv 99;100;101 send 99,100,101 ... m=audio 49300 RTP/AVP 99 100 101 a=rtpmap:99 AMR/8000/1 a=rtpmap:100 AMR-WB/16000/1 a=rtpmap:101 EVS/16000/1 a=simulcast: send 99,100,101 ... m=audio 49400 RTP/AVP 99 100 a=rtpmap:99 AMR/8000/1 a=rtpmap:100 AMR-WB/16000/1 a=simulcast: send 99,100 ... m=audio 49500 RTP/AVP 99 a=rtpmap:99 AMR/8000/1 a=send 99 ... m=audio 49600 RTP/AVP 99 a=rtpmap:99 AMR/8000/1 a=send 99 ...  
B m=audio 49200 RTP/AVP 100 101 a=rtpmap:100 AMR-WB/16000/1 a=rtpmap:101 EVS/16000/1 a=simulcast: send 100;101 recv 100,101 ... m=audio 49300 RTP/AVP 100 101 a=rtpmap:100 AMR-WB/16000/1 a=rtpmap:101 EVS/16000/1 a=simulcast: recv 100,101 ... m=audio 49400 RTP/AVP 100 101 a=rtpmap:100 AMR-WB/16000/1 a=rtpmap:101 EVS/16000/1 a=simulcast: recv 100,101 ... m=audio 49500 RTP/AVP 100 101 a=rtpmap:100 AMR-WB/16000/1 a=rtpmap:101 EVS/16000/1 a=simulcast: recv 100,101 ... m=audio 49600 RTP/AVP 100 a=rtpmap:100 AMR-WB/16000/1 a=recv 100 ...   可以針對B進行類似於上文所展示的那些選擇的選擇。
C m=audio 49200 RTP/AVP 99 101 a=rtpmap:99 AMR/8000/1 a=rtpmap:101 EVS/16000/1 a=simulcast send 99;101 recv 99,101 ... m=audio 49300 RTP/AVP 99 101 a=rtpmap:99 AMR/8000/1 a=rtpmap:101 EVS/16000/1 a=simulcast recv 99,101 ... m=audio 49400 RTP/AVP 99 101 a=rtpmap:99 AMR/8000/1 a=rtpmap:101 EVS/16000/1 a=simulcast recv 99,101 ... m=audio 49500 RTP/AVP 99 101 a=rtpmap:99 AMR/8000/1 a=rtpmap:101 EVS/16000/1 a=simulcast recv 99,101 ... m=audio 49700 RTP/AVP 99 a=rtpmap:99 AMR/8000/1 a=recv 99 ...   可以針對C進行類似於上文所展示的那些選擇的選擇。
表 8
但是，經由實現具有要約訊息和應答訊息的壓縮CCC SDP參數，可以避免列出除了A個媒體行之外的任何配置，並因此可以避免使用MediaCapNeg框架。經由實現具有MMCMH通信期建立的壓縮CCC SDP參數所節省的SDP行的數量，可以取決於每一個轉碼器之間的相對複雜度。相對複雜度的變化越大，非壓縮CCC SDP參數要約中將會需要的媒體行的集合就越多，因為將一個轉碼器實例替換為另一個轉碼器實例可能對並行解碼器的數量具有更大的影響。
例如，假定轉碼器C的複雜度是轉碼器B的複雜度的兩倍，轉碼器B的複雜度是轉碼器A的複雜度的兩倍，並且其中轉碼器A代表能夠執行的最簡單轉碼器的實例的最大數量。當針對要約訊息使用壓縮CCC SDP參數時，在SDP要約訊息中將僅有A個媒體行的一個集合，該要約訊息將包含以下數量的SDP行： l 用於共用SDP態樣的7行 l 用於包括轉碼器A的A個媒體行中的每一個媒體行的2行 l 用於包括轉碼器B的B個媒體行中的每一個媒體行的2行 l 用於包括轉碼器C的C個媒體行中的每一個媒體行的2行 l 用於壓縮CCC SDP參數的1行 因此，針對SDP要約訊息，將存在總共8+2A+2B+2C=8+2A+A+0.5A=8+3.5A個SDP行。
但是，當針對要約訊息未使用壓縮CCC SDP參數時，可能存在以下媒體行的集合：
媒體行的集合 轉碼器的數量 SDP 行的數量 SDP 行的總數 
1 轉碼器 A: A 轉碼器B: 0 轉碼器C: 0 l 用於共用SDP態樣的7行 l 針對具有轉碼器A的A個媒體行中的每一個媒體行的2行 2A+7
2 轉碼器A: A-2 轉碼器B: 1 轉碼器C: 0 l 用於共用SDP態樣的7行 l 針對包括轉碼器A的(A-4)個媒體行中的每一個媒體行的2行 l 針對包括轉碼器B的兩個媒體行的2行 2A+5
3A 轉碼器A: A-4 轉碼器B: 2 轉碼器C: 0 l 用於共用SDP態樣的7行 l 針對包括轉碼器A的(A-4)個媒體行中的每一個媒體行的2行 l 針對包括轉碼器B的兩個媒體行的2行 2A+3
3B 轉碼器A: A-4 轉碼器B: 0 轉碼器C: 1 l 用於共用SDP態樣的7行 l 針對包括轉碼器A的(A-4)個媒體行中的每一個媒體行的2行 l 針對包括轉碼器B的兩個媒體行的2行 2A+1
4A 轉碼器A: A-6 轉碼器B: 3 轉碼器C: 0 l 用於共用SDP態樣的7行 l 針對包括轉碼器A的(A-6)個媒體行中的每一個媒體行的2行 l 針對包括轉碼器B的三個媒體行的2行 2A+1
4B 轉碼器A: A-6 轉碼器B: 1 轉碼器C: 1 l 用於共用SDP態樣的7行 l 針對包括轉碼器A的(A-6)個媒體行中的每一個媒體行的2行 l 針對包括轉碼器B的一個媒體行的2行 l 針對包括轉碼器C的一個媒體行的2行   2A-1
等等…      
擴展上文的模式，能夠看到，當未使用壓縮CCC SDP參數時，指示所有的可能配置所需要的SDP行的總數量是A (1+2+3+…A/4)x(2A+m i)，其中m i是針對獨立於A的特定媒體行集合的常數。至少，上文的下限是媒體行的數量至少為0.25 A 4+A 3。
因此，在SDP要約中使用壓縮CCC SDP格式的增益，以近似(0.25 A 4+A 3)/(3.5A+8)~=0.0714A 3+0.286A 2的因數減少SDP要約中的SDP行的數量。
因此，對於A=4，存在5.81的壓縮增益因數；對於A=8，存在42.67的壓縮增益因數；對於A=16，存在320的壓縮增益因數。此情形表明減少SDP要約的大小獲得的壓縮增益可能是巨大的，特別是對於具有支援大量的不同計算複雜度的並行轉碼器的能力的要約方終端。
在一些實施例中，如本文描述的使用壓縮CCC SDP參數來壓縮SDP要約中的媒體行的數量，可能需要將應答方終端配置為理解壓縮CCC SDP參數，使得應答方終端知道不是 所有的在壓縮CCC SDP要約中描述的媒體配置皆被支援。若應答方終端不理解壓縮CCC SDP參數，則其可能不恰當地選擇要約方終端不支援的並行轉碼器的集合。
因此，只要要約方使用壓縮CCC SDP參數以及A個媒體行的單個媒體配置，則要約方終端可以知道應答方終端能夠恰當地理解壓縮CCC SDP參數。例如，要約方終端可能先前已經使用任何方法（例如，OPTION方法）查詢了應答方終端的CCC，並接收到包括壓縮CCC SDP參數的回應，要約方終端以此為基礎來記錄應答方終端理解壓縮CCC格式，並當啟動MMCMH通信期時，能夠使用該格式。或者，要約方終端可以防止未理解壓縮CCC格式的應答方終端選擇不支援的配置。例如，要約方終端能夠經由定義針對CCC的新標籤來完成該目標，該標籤填充在SIP INVITE（邀請）的Require標頭以及主體中的壓縮CCC SDP參數中。若應答方終端理解CCC標籤，則其相應地將對INVITE進行回應。若應答方終端不理解CCC標籤，則其將拒絕INVITE，並且要約方終端將必須發送不具有該CCC的並且具有所有相關聯的媒體行配置的更詳細要約的re-INVITE。
在一些實施例中，要約方終端可以向一或多個應答方終端傳輸壓縮CCC SDP要約參數。壓縮CCC SDP要約參數可以包括要約方終端支援的一或多個CCC。要約方終端可以隨後從一或多個應答方終端中的至少一個應答方終端接收到回應。回應可以包括：對要約方終端支援且該至少一個應答方終端亦支援的一個CCC的選擇。基於該回應，要約方終端可以向該至少一個應答方終端傳輸資料串流。
圖7是用於使用壓縮並行轉碼器以啟動會議通信期的示例性方法700的流程圖。圖7中展示的方法700可以經由會議架構100、200、300及/或400中的一或多個設備來實現。在一些態樣中，方法700可以由類似於圖1-圖4中的使用者終端110A-D及/或中央處理器125的設備或者任何其他適當的設備來實現。
在方塊705處，終端或者處理器可以向一或多個設備傳輸要約訊息以建立會議。要約訊息可以包括會議支援的並行轉碼器能力的列表的指示。在一些態樣中，訊息可以是基於啟動方終端或者處理器的並行轉碼器能力的。在一些實施例中，訊息亦可以是基於預先知道其並行能力的其他參與方的轉碼器能力的。
在方塊710處，終端從一或多個設備接收應答訊息。應答訊息可以包括從並行轉碼器能力的列表的指示中進行的選擇。
在方塊715處，終端基於應答訊息，向一或多個設備選擇性地傳輸資料串流。
圖8是用於使用壓縮並行轉碼器來啟動會議通信期的示例性方法800的另一流程圖。圖8中展示的方法800可以經由會議架構100、200、300及/或400中的一或多個設備來實現。在一些態樣中，方法800可以由類似於圖1-圖4中的使用者終端110A-D及/或中央處理器125的設備或者任何其他適當的設備來實現。
在方塊805處，第一設備的終端或者處理器可以產生第一訊息以向第二設備傳輸。第一訊息可以包括要約訊息或者請求訊息。第一訊息可以包括終端或者處理器支援的並行轉碼器能力的列表的指示，或者可以請求第二設備支援的並行轉碼器能力的列表的指示。在一些實施例中，經由用於產生第一訊息以向第二設備傳輸的構件可以產生第一訊息。在一些實施例中，用於產生第一訊息的構件可以包括，會議架構100、200、300及/或400中的一或多個設備。在一些態樣中，用於產生第一訊息的構件，可以由類似於圖1-圖4中的使用者終端110A-D及/或中央處理器125的設備或者任何其他適當的設備來實現。
在方塊810處，終端接收第二訊息以在終端和第二設備之間建立會議。第二訊息可以包括第二設備支援的一或多個並行轉碼器能力的列表。第二設備支援的一或多個並行轉碼器能力的列表可以包括如下指示：可用於第一列出的轉碼器的一或多個並行實例的一或多個資源，是否可以替代地用於第二列出的轉碼器的一或多個並行實例。在一些實施例中，經由用於接收第二訊息以在終端和第二設備之間建立會議的構件可以接收第二訊息。在一些實施例中，用於接收第二訊息的構件可以包括：會議架構100、200、300及/或400中的一或多個設備。在一些態樣中，用於產生第一訊息的構件，可以由類似於圖1-圖4中的使用者終端110A-D及/或中央處理器125的設備或者任何其他適當的設備來實現。
在一些實施例中，第二訊息可以包括第二設備回應於要約訊息而傳輸的回應訊息。在一些實施例中，第二訊息可以包括應答訊息。
上文描述的方法的各種操作，可以由能夠執行該等操作的任何適當的構件來執行，例如，各種硬體及/或軟體元件、電路及/或模組。通常，在附圖中圖示的任何操作，可以由能夠執行該等操作的相應功能構件來執行。例如，用於向兩個或更多個設備傳輸要約訊息的構件，可以包括終端110A-D的傳輸器或天線。額外地，用於接收回應訊息的構件，可以包括終端110A-D的接收器或天線。額外地，用於決定兩個或更多個設備是否可以繼續參與會議的構件，可以包括使用者終端110A-D的處理器。此外，用於從設備接收要約訊息的構件，可以包括終端110A-D的接收器或天線。此外，用於傳輸回應訊息的構件，可以包括終端110A-D的傳輸器或天線。
資訊和訊號可以使用多種不同的技術和技藝中的任意一種來表示。例如，遍及上文的描述可能提及的資料、指令、命令、資訊、訊號、位元、符號和碼片可以由電壓、電流、電磁波、磁場或磁粒子、光場或光粒子或者其任意組合來表示。
結合本文揭示的實施例描述的各種說明性邏輯方塊、模組、電路和演算法步驟均可以實現成電子硬體、電腦軟體或二者的組合。為了清楚地說明硬體和軟體之間的此種可交換性，上文已經以其功能的用語整體描述了各種說明性的元件、方塊、模組、電路和步驟。此種功能是實現成硬體還是實現成軟體，取決於特定的應用和對整體系統所施加的設計約束。可以針對每個特定應用，以不同的方式實現所描述的功能，但是，此種實現決策不應當解釋為導致偏離本發明的實施例的範疇。
利用被設計為執行本文所述功能的通用處理器、數位訊號處理器（DSP）、特殊應用積體電路（ASIC）、現場可程式設計閘陣列（FPGA）或其他可程式設計邏輯設備、個別閘門或者電晶體邏輯、個別硬體元件或者其任意組合，可以實現或執行結合本文揭示的實施例描述的各種說明性方塊、模組和電路。通用處理器可以是微處理器，但是在替代方案中，處理器可以是任何習知處理器、控制器、微控制器或者狀態機。處理器亦可以實現為計算設備的組合，例如，DSP和微處理器的組合、複數個微處理器、一或多個微處理器與DSP核心的結合，或者任何其他此種配置。
結合本文所揭示的實施例描述的方法或者演算法的步驟和功能可直接體現為硬體、由處理器執行的軟體模組或二者的組合。當利用軟體實現時，可以將該等功能儲存在有形、非暫時性電腦可讀取媒體上，或者作為有形、非暫時性電腦可讀取媒體上的一或多個指令或代碼進行傳輸。軟體模組可以位於隨機存取記憶體（RAM）、快閃記憶體、唯讀記憶體（ROM）、電子可程式設計ROM（EPROM）、電子可抹除可程式設計ROM（EEPROM）、暫存器、硬碟、可移除磁碟、CD ROM，或者本領域已知的任何其他形式的儲存媒體。儲存媒體耦合到處理器，使得處理器能夠從儲存媒體讀取資訊，以及向儲存媒體寫入資訊。在替代方案中，可以將儲存媒體整合到處理器。如本文使用的，磁碟和光碟包括壓縮光碟（CD）、鐳射光碟、光碟、數位多功能光碟（DVD）、軟碟和和藍光光碟，其中磁碟通常磁性地複製資料，而光碟則利用鐳射來光學地複製資料。上文的組合亦應當包括在電腦可讀取媒體的範疇之內。處理器和儲存媒體可以位於ASIC中。
出於概括本案內容的目的，本文已經描述了本發明的某些態樣、優點和新穎特徵。應當理解的是，根據本發明的任何特定實施例不一定可以獲得所有該等優點。因此，本發明可以以實現或者最佳化如本文所教示的一個優點或者一組優點的方式來體現或者執行，而不必實現如本文可能教示或者建議的其他優點。
對上文所描述的實施例的各種修改將是顯而易見的，並且，本文定義的整體原理可以在不脫離本發明的精神或保護範疇的情況下適用於其他實施例。因此，本發明並不是要限於本文所展示的實施例，而是要符合與本文所揭示的原理和新穎特徵的相一致的最廣範疇。
100:會議架構/集中式會議架構 110A:終端 110B:終端 110C:終端 110D:終端 110E:終端 125:中央處理器 200:會議架構/分散式會議架構 300:會議架構/分散式會議架構 400:會議架構/混合會議架構 450:終端/媒體閘道 500:會議架構/混合會議架構 516:資料串流 517:資料串流 518:資料串流 520:資料串流 521:資料串流 522:資料串流 523:資料串流 524:資料串流 525:資料串流 600:方法 605:方塊 610:方塊 700:方法 705:方塊 710:方塊 715:方塊 800:方法 805:方塊 810:方塊
圖1圖示用於多個參與方的會議架構的實例。
圖2圖示用於多個參與方的分散式會議架構的實例。
圖3圖示用於多個參與方的分散式會議架構的另一實例。
圖4圖示在終端用作混合器的情況下，用於多個參與方的混合會議架構的實例。
圖5圖示在終端用作混合器和參與方的情況下，用於多個參與方的混合會議架構的實例。
圖6是用於會議中的轉碼器協商的另一示例性方法的流程圖。
圖7是用於使用壓縮並行轉碼器以啟動會議通信期的示例性方法的流程圖。
圖8是用於使用壓縮並行轉碼器以啟動會議通信期的示例性方法的另一流程圖。
國內寄存資訊(請依寄存機構、日期、號碼順序註記) 無 國外寄存資訊(請依寄存國家、機構、日期、號碼順序註記) 無
110A:終端
110B:終端
110C:終端
450:終端/媒體閘道

Claims (44)

  1. 一種用於多方之間的通訊的方法，該方法包括以下步驟： 在一第一設備處，產生一要約（offer）訊息以向一第二設備傳輸，該要約訊息被配置為建立與至少該第二設備的一會議，該要約訊息包括該第一設備支援的一或多個並行轉碼器能力的一列表，其中該第一設備支援的一或多個並行轉碼器能力的該列表包括如下一指示：用於對一媒體串流進行編碼以向該第一設備傳輸的一第一列出的轉碼器的一或多個並行實例是否能夠被用於對該媒體串流進行編碼以向該第一設備傳輸的一第二列出的轉碼器的一或多個並行實例替代；及在該第一設備處，接收一應答訊息以回應於該要約訊息。
  2. 根據請求項1之方法，其中該指示指出，該第一列出的轉碼器的該一或多個並行實例能夠被該第二列出的轉碼器的該一或多個並行實例替代。
  3. 根據請求項1之方法，其中該指示指出：該第一列出的轉碼器的該一或多個並行實例不能被該第二列出的轉碼器的該一或多個並行實例替代。
  4. 根據請求項1之方法，其中該第一列出的轉碼器和該第二列出的轉碼器是在一通信期描述協定（SDP）格式中呈現的。
  5. 根據請求項1之方法，其中該列表中的該一或多個並行轉碼器能力是根據計算複雜度來排序的。
  6. 根據請求項5之方法，其中該第二列出的轉碼器的計算複雜度低於該第一列出的轉碼器的計算複雜度，並且其中在一SDP格式中，該第二列出的轉碼器是在該第一列出的轉碼器之後列出的。
  7. 根據請求項1之方法，其中該應答訊息包括該第二設備支援的一或多個並行轉碼器能力的一列表，並且該方法亦包括以下步驟：在該第一設備處，基於該第二設備支援的一或多個並行轉碼器能力的該列表來決定該第二設備是否能夠參與一會議。
  8. 根據請求項7之方法，其中該第二設備支援的一或多個並行轉碼器能力的該列表包括以下至少一者：對應於一列出的轉碼器支援的一媒體串流的一複雜度的一層級、及指示能夠用於一列出的轉碼器的一或多個工具集的一簡介指示符。
  9. 根據請求項7之方法，亦包括以下步驟：基於該第二設備支援的一或多個並行轉碼器能力的該列表，從該第一設備向該第二設備選擇性地傳輸該媒體串流。
  10. 根據請求項7之方法，亦包括以下步驟：在該第一設備處，基於出自該第一設備支援的一或多個並行轉碼器能力的該列表及該第二設備支援的一或多個並行轉碼器能力的該列表的共用並行轉碼器能力，向該第二設備選擇性地傳輸該媒體串流。
  11. 根據請求項10之方法，其中該等列表的至少一者包括一轉碼器的一層級，該層級對應於一列出的轉碼器能夠支援的一媒體串流的一複雜度。
  12. 一種用於啟動採用複數個轉碼器的一多方、多串流會議的第一設備，該第一設備包括： 一處理器，該處理器被配置為產生一要約（offer）訊息以向一第二設備傳輸，該要約訊息被配置為建立與至少該第二設備的一會議，該要約訊息包括該第一設備支援的一或多個並行轉碼器能力的一列表，其中該第一設備支援的一或多個並行轉碼器能力的該列表包括如下一指示：用於對一媒體串流進行編碼以向該第一設備傳輸的一第一列出的轉碼器的一或多個並行實例是否能夠被用於對該媒體串流進行編碼以向該第一設備傳輸的一第二列出的轉碼器的一或多個並行實例替代；及一接收器，該接收器被配置為從該第二設備接收一應答訊息以回應於該要約訊息。
  13. 根據請求項12之第一設備，其中該指示指出，該第一列出的轉碼器的該一或多個並行實例能夠被該第二列出的轉碼器的該一或多個並行實例替代。
  14. 根據請求項12之第一設備，其中該指示指出：該第一列出的轉碼器的該一或多個並行實例不能被該第二列出的轉碼器的該一或多個並行實例替代。
  15. 根據請求項12之第一設備，其中該第一列出的轉碼器和該第二列出的轉碼器是在一通信期描述協定（SDP）格式中呈現的。
  16. 根據請求項12之第一設備，其中該列表中的該一或多個並行轉碼器能力是根據計算複雜度來排序的。
  17. 根據請求項16之第一設備，其中該第二列出的轉碼器的計算複雜度低於該第一列出的轉碼器的計算複雜度，並且其中在一SDP格式中，該第二列出的轉碼器是在該第一列出的轉碼器之後列出的。
  18. 根據請求項12之第一設備，其中該應答訊息包括該第二設備支援的一或多個並行轉碼器能力的一列表，並且其中該處理器亦被配置為基於該第二設備支援的一或多個並行轉碼器能力的該列表來決定該第二設備是否能夠參與該會議。
  19. 根據請求項18之第一設備，其中該第二設備支援的一或多個並行轉碼器能力的該列表包括以下至少一者：對應於一列出的轉碼器支援的一媒體串流的一複雜度的一層級、及指示能夠用於一列出的轉碼器的一或多個工具集的一簡介指示符。
  20. 根據請求項18之第一設備，亦包括一傳輸器，該傳輸器被配置為基於該第二設備支援的一或多個並行轉碼器能力的該列表，向該第二設備選擇性地傳輸該媒體串流。
  21. 根據請求項18之第一設備，亦包括一傳輸器，該傳輸器被配置為基於出自該第一設備支援的一或多個並行轉碼器能力的該列表及該第二設備支援的一或多個並行轉碼器能力的該列表的共用並行轉碼器能力，向該第一設備選擇性地傳輸該媒體串流。
  22. 根據請求項21之第一設備，其中該等列表的至少一者包括一轉碼器的一層級，該層級對應於一列出的轉碼器能夠支援的一媒體串流的一複雜度。
  23. 一種用於啟動採用複數個轉碼器的一多方、多串流會議的第一設備，該第一設備包括： 用於產生一要約（offer）訊息以向一第二設備傳輸的構件，該要約訊息被配置為建立與至少該第二設備的一會議，該要約訊息包括該第一設備支援的一或多個並行轉碼器能力的一列表，其中該第一設備支援的一或多個並行轉碼器能力的該列表包括如下一指示：用於對一媒體串流進行編碼以向該第一設備傳輸的一第一列出的轉碼器的一或多個並行實例是否能夠被用於對該媒體串流進行編碼以向該第一設備傳輸的一第二列出的轉碼器的一或多個並行實例替代；及用於從該第二設備接收一應答訊息以回應於該要約訊息的構件。
  24. 根據請求項23之第一設備，其中該指示指出，該第一列出的轉碼器的該一或多個並行實例能夠被該第二列出的轉碼器的該一或多個並行實例替代。
  25. 根據請求項23之第一設備，其中該指示指出：該第一列出的轉碼器的該一或多個並行實例不能被該第二列出的轉碼器的該一或多個並行實例替代。
  26. 根據請求項23之第一設備，其中該第一列出的轉碼器和該第二列出的轉碼器是在一通信期描述協定（SDP）格式中呈現的。
  27. 根據請求項23之第一設備，其中該列表中的該一或多個並行轉碼器能力是根據計算複雜度來排序的。
  28. 根據請求項27之第一設備，其中該第二列出的轉碼器的計算複雜度低於該第一列出的轉碼器的計算複雜度，並且其中在一SDP格式中，該第二列出的轉碼器是在該第一列出的轉碼器之後列出的。
  29. 根據請求項23之第一設備，其中該應答訊息包括該第二設備支援的一或多個並行轉碼器能力的一列表，並且該第一設備亦包括：用於基於該第二設備支援的一或多個並行轉碼器能力的該列表來決定該第二設備是否能夠參與該會議的構件。
  30. 根據請求項29之第一設備，其中該第一設備支援的一或多個並行轉碼器能力的該列表包括以下一或多者：對應於一列出的轉碼器支援的一媒體串流的一複雜度的一層級、及指示能夠用於一列出的轉碼器的一或多個工具集的一簡介指示符。
  31. 根據請求項29之第一設備，亦包括一傳輸器，該傳輸器被配置為： 基於該第二設備支援的一或多個並行轉碼器能力的該列表，向該第二設備選擇性地傳輸該媒體串流。
  32. 根據請求項29之第一設備，亦包括：用於基於該第一設備支援的一或多個並行轉碼器能力的該列表及該第二設備支援的一或多個並行轉碼器能力的該列表的共用並行轉碼器能力，向該第二設備選擇性地傳輸該媒體串流的構件。
  33. 根據請求項32之第一設備，其中該等列表的至少一者包括一轉碼器的一層級，該層級對應於一列出的轉碼器能夠支援的一媒體串流的一複雜度。
  34. 一種包括指令的非暫時性電腦可讀取媒體，當執行該等指令時，該等指令使一處理器執行以下一方法： 在一第一設備處，產生一要約（offer）訊息以向一第二設備傳輸，該要約訊息被配置為建立與至少該第二設備的一會議，該要約訊息包括該第一設備支援的一或多個並行轉碼器能力的一列表，其中該第一設備支援的一或多個並行轉碼器能力的該列表包括如下一指示：用於對一媒體串流進行編碼以向該第一設備傳輸的一第一列出的轉碼器的一或多個並行實例是否能夠被用於對該媒體串流進行編碼以向該第一設備傳輸的一第二列出的轉碼器的一或多個並行實例替代；及 在該第一設備處，從該第二設備接收一應答訊息以回應於該要約訊息。
  35. 根據請求項34之非暫時性電腦可讀取媒體，其中該指示指出，該第一列出的轉碼器的該一或多個並行實例能夠被該第二列出的轉碼器的該一或多個並行實例替代。
  36. 根據請求項34之非暫時性電腦可讀取媒體，其中該指示指出：該第一列出的轉碼器的該一或多個並行實例不能被該第二列出的轉碼器的該一或多個並行實例替代。
  37. 根據請求項34之非暫時性電腦可讀取媒體，其中該第一列出的轉碼器和該第二列出的轉碼器是在一通信期描述協定（SDP）格式中呈現的。
  38. 根據請求項34之非暫時性電腦可讀取媒體，其中該列表中的該一或多個並行轉碼器能力是根據計算複雜度來排序的。
  39. 根據請求項38之非暫時性電腦可讀取媒體，其中該第二列出的轉碼器的計算複雜度低於該第一列出的轉碼器的計算複雜度，並且其中在一SDP格式中，該第二列出的轉碼器是在該第一列出的轉碼器之後列出的。
  40. 根據請求項34之非暫時性電腦可讀取媒體，其中該應答訊息包括該第二設備支援的一或多個並行轉碼器能力的一列表，並且其中該方法亦包括以下步驟：在該第一設備處，基於該第二設備支援的一或多個並行轉碼器能力的該列表來決定該第二設備是否能夠參與該會議。
  41. 根據請求項40之非暫時性電腦可讀取媒體，其中該第二設備支援的一或多個並行轉碼器能力的該列表包括以下一或多者：對應於一列出的轉碼器支援的一媒體串流的一複雜度的一層級、及指示能夠用於一列出的轉碼器的一或多個工具集的一簡介指示符。
  42. 根據請求項40之非暫時性電腦可讀取媒體，其中該等指令的執行使該處理器執行操作亦包括：基於該第二設備支援的一或多個並行轉碼器能力的該列表，從該第一設備向該第二設備選擇性地傳輸該媒體串流。
  43. 根據請求項40之非暫時性電腦可讀取媒體，其中該等指令的執行使該處理器執行操作亦包括：在該第一設備處，基於該第一設備支援的一或多個並行轉碼器能力的該列表及該第二設備支援的一或多個並行轉碼器能力的該列表的共用並行轉碼器能力，向該第二設備選擇性地傳輸該媒體串流。
  44. 根據請求項43之非暫時性電腦可讀取媒體，其中該等列表的至少一者包括一轉碼器的一層級，該層級對應於一列出的轉碼器能夠支援的一媒體串流的一複雜度。
TW110148867A 2016-07-21 2017-07-21 用於在多媒體通訊中使用壓縮並行轉碼器的方法和裝置 TWI829058B (zh)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US201662365348P 2016-07-21 2016-07-21
US62/365,348 2016-07-21
US201662381559P 2016-08-30 2016-08-30
US62/381,559 2016-08-30
US15/652,946 2017-07-18
US15/652,946 US11171999B2 (en) 2016-07-21 2017-07-18 Methods and apparatus for use of compact concurrent codecs in multimedia communications

Publications (2)

Publication Number Publication Date
TW202218416A TW202218416A (zh) 2022-05-01
TWI829058B true TWI829058B (zh) 2024-01-11

Family

ID=60990163

Family Applications (2)

Application Number Title Priority Date Filing Date
TW110148867A TWI829058B (zh) 2016-07-21 2017-07-21 用於在多媒體通訊中使用壓縮並行轉碼器的方法和裝置
TW106124495A TWI753928B (zh) 2016-07-21 2017-07-21 用於在多媒體通訊中使用壓縮並行轉碼器的方法和裝置

Family Applications After (1)

Application Number Title Priority Date Filing Date
TW106124495A TWI753928B (zh) 2016-07-21 2017-07-21 用於在多媒體通訊中使用壓縮並行轉碼器的方法和裝置

Country Status (9)

Country Link
US (2) US11171999B2 (zh)
EP (2) EP4380147A1 (zh)
JP (1) JP6940587B2 (zh)
KR (2) KR102689601B1 (zh)
CN (1) CN109479113B (zh)
AU (2) AU2017298381B2 (zh)
BR (1) BR112019000850A2 (zh)
TW (2) TWI829058B (zh)
WO (1) WO2018017736A1 (zh)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3049140A1 (fr) * 2016-03-15 2017-09-22 Orange Procede de gestion dynamique de chemins de communication entre routeurs en fonction de besoins applicatifs
JP6847115B2 (ja) * 2016-08-12 2021-03-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 端末、基地局及び通信方法
US10915521B2 (en) * 2018-08-21 2021-02-09 Syniverse Technologies, Llc Blockchain gateway device and associated method of use
CN112640390B (zh) * 2018-09-07 2023-06-16 苹果公司 用于在ims多媒体电话会话中发信号通知ran辅助的编解码器自适应能力的设备和方法
WO2021087734A1 (zh) * 2019-11-05 2021-05-14 海能达通信股份有限公司 宽窄带互通环境下语音通讯方法及系统
CN111050108A (zh) * 2019-12-19 2020-04-21 维沃移动通信有限公司 多路视频通话的实现方法、装置及电子设备
KR20220027577A (ko) * 2020-08-27 2022-03-08 삼성전자주식회사 복수의 모드들에 따른 통화를 지원하기 위한 방법 및 장치
CN112511788B (zh) * 2020-11-27 2022-04-01 厦门亿联网络技术股份有限公司 一种视频会议的视频传输控制方法及视频传输系统
US12113845B2 (en) * 2021-03-12 2024-10-08 Tencent America LLC Techniques for signaling audio mixing gain in teleconferencing and telepresence for remote terminals
CN113316129B (zh) * 2021-04-22 2022-05-20 荣耀终端有限公司 一种蓝牙设备中编解码能力的获取方法及电子设备
CN113316013B (zh) * 2021-05-31 2022-04-26 烽火通信科技股份有限公司 一种视频投屏方法及系统
CN113438230B (zh) * 2021-06-23 2022-08-30 中移（杭州）信息技术有限公司 协议协商方法、装置、代理服务器及存储介质
KR20230029122A (ko) * 2021-08-23 2023-03-03 삼성전자주식회사 영상 통화를 수행하는 동안 복수의 이미지 스트림을 전송하는 전자 장치 및 전자 장치의 동작 방법
WO2024147675A1 (en) * 2023-01-05 2024-07-11 Samsung Electronics Co., Ltd. Method and apparatus for media adaptation in media service
CN117412062A (zh) * 2023-09-28 2024-01-16 协创芯片(上海)有限公司 一种支持h265编码的多媒体芯片

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006019380A1 (en) * 2004-07-19 2006-02-23 Thomson Licensing S.A. Non-similar video codecs in video conferencing system
US20060168637A1 (en) * 2005-01-25 2006-07-27 Collaboration Properties, Inc. Multiple-channel codec and transcoder environment for gateway, MCU, broadcast and video storage applications

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI112140B (fi) 2001-05-23 2003-10-31 Nokia Corp Informaation kommunikointi
US20040260827A1 (en) 2003-06-19 2004-12-23 Nokia Corporation Stream switching based on gradual decoder refresh
JP2006067124A (ja) 2004-08-25 2006-03-09 Nec Corp 画像符号化データの切り替え方法および装置、システムならびにプログラム
CN101064863A (zh) 2006-04-27 2007-10-31 华为技术有限公司 一种ims网络下提供媒体资源服务的方法和系统
CN101119292B (zh) 2006-07-31 2010-07-21 华为技术有限公司 一种网关之间协商传送数据业务的方法
JP5227403B2 (ja) 2007-08-14 2013-07-03 テレフオンアクチーボラゲット エル エム エリクソン（パブル） コーデックのネゴシエーションおよび選定における、またはそれらに関する改善
KR101427416B1 (ko) * 2007-09-05 2014-08-08 엘지전자 주식회사 통신 시스템
US9161286B2 (en) 2009-04-07 2015-10-13 Telefonaktiebolaget L M Ericsson (Publ) Method and arrangement for session negotiation
US8860779B2 (en) 2011-05-23 2014-10-14 Broadcom Corporation Two-way audio and video communication utilizing segment-based adaptive streaming techniques
CN102710617A (zh) 2012-05-21 2012-10-03 深圳市共进电子股份有限公司 Sip终端sdp协商方法
US9356987B2 (en) 2012-10-09 2016-05-31 Vantrix Corporation System and method for optimizing a communication session between multiple terminals involving transcoding operations
US20150229487A1 (en) 2014-02-12 2015-08-13 Talk Fusion, Inc. Systems and methods for automatic translation of audio and video data from any browser based device to any browser based client
WO2015129181A1 (ja) 2014-02-28 2015-09-03 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 音声通信端末、中間ノード、処理装置、接続方法およびプログラム
JP6405804B2 (ja) 2014-09-02 2018-10-17 沖電気工業株式会社 コーデック調停装置及びプログラム
US9137187B1 (en) * 2014-09-29 2015-09-15 Edifire LLC Dynamic conference session state management in secure media-based conferencing
US10063609B2 (en) 2015-08-19 2018-08-28 Qualcomm Incorporated Methods and apparatus for multimedia conferences using single source multi-unicast

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006019380A1 (en) * 2004-07-19 2006-02-23 Thomson Licensing S.A. Non-similar video codecs in video conferencing system
US20060168637A1 (en) * 2005-01-25 2006-07-27 Collaboration Properties, Inc. Multiple-channel codec and transcoder environment for gateway, MCU, broadcast and video storage applications

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
網路文獻 J. Rosenberg et.al An Offer/Answer Model with the Session Description Protocol (SDP), Network Working Group Request for Comments: 3264 June 2002 https://www.ietf.org/rfc/rfc3264.txt *

Also Published As

Publication number Publication date
AU2017298381B2 (en) 2022-04-28
TW201808001A (zh) 2018-03-01
JP2019530996A (ja) 2019-10-24
EP4380147A1 (en) 2024-06-05
AU2017298381A1 (en) 2018-12-20
WO2018017736A1 (en) 2018-01-25
AU2022209216A1 (en) 2022-08-18
US20220030039A1 (en) 2022-01-27
CN109479113A (zh) 2019-03-15
EP3488605B1 (en) 2024-02-21
CN109479113B (zh) 2021-03-26
KR102577373B1 (ko) 2023-09-11
US11171999B2 (en) 2021-11-09
TWI753928B (zh) 2022-02-01
JP6940587B2 (ja) 2021-09-29
KR20190031239A (ko) 2019-03-25
US20180027027A1 (en) 2018-01-25
KR102689601B1 (ko) 2024-07-29
TW202218416A (zh) 2022-05-01
BR112019000850A2 (pt) 2019-04-30
EP3488605A1 (en) 2019-05-29
AU2022209216B2 (en) 2024-06-13
KR20230133936A (ko) 2023-09-19
EP3488605C0 (en) 2024-02-21

Similar Documents

Publication Publication Date Title
TWI829058B (zh) 用於在多媒體通訊中使用壓縮並行轉碼器的方法和裝置
US10063609B2 (en) Methods and apparatus for multimedia conferences using single source multi-unicast
US10791261B2 (en) Interactive video conferencing
CN101578884B (zh) 提供和使用译码的媒体流的互操作点的预定信令的系统和方法
US20170006078A1 (en) Methods and apparatus for codec negotiation in decentralized multimedia conferences
CN105794204B (zh) 交互式视频会议
US20140229529A1 (en) Enabling devices without native broadcast capability to access and/or receive broadcast data in an efficient manner
CN101518087A (zh) 用于指示媒体文件中轨道关系的系统和方法
US11044278B2 (en) Transcoding capability configuration method and device and computer storage medium
US20220078215A1 (en) Method and apparatus for processing immersive media
WO2019228534A1 (zh) 一种媒体传输方法及h323-sip网关
US20230362214A1 (en) 5g support for webrtc