CN109274634A - 多媒体通信方法及装置、存储介质 - Google Patents

多媒体通信方法及装置、存储介质 Download PDF

Info

Publication number
CN109274634A
CN109274634A CN201710587065.4A CN201710587065A CN109274634A CN 109274634 A CN109274634 A CN 109274634A CN 201710587065 A CN201710587065 A CN 201710587065A CN 109274634 A CN109274634 A CN 109274634A
Authority
CN
China
Prior art keywords
client
opposite end
data channel
local terminal
end client
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
CN201710587065.4A
Other languages
English (en)
Other versions
CN109274634B (zh
Inventor
黄柳文
薛笛
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
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 Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN201710587065.4A priority Critical patent/CN109274634B/zh
Priority to PCT/CN2018/092017 priority patent/WO2019015440A1/zh
Publication of CN109274634A publication Critical patent/CN109274634A/zh
Priority to US16/547,376 priority patent/US11108570B2/en
Application granted granted Critical
Publication of CN109274634B publication Critical patent/CN109274634B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • 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/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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/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/60—Network streaming of media packets
    • 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/80—Responding to QoS
    • 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/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • 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/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1087—Peer-to-peer [P2P] networks using cross-functional networking aspects
    • H04L67/1091—Interfacing with client-server systems or between P2P systems
    • 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
    • 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/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开了一种多媒体通信方法，包括：通过本端客户端中集成的浏览器内核加载会话页面，并通过浏览器内核执行所述会话页面中的脚本而实现以下操作：通过信令服务器与对端客户端交换控制参数；通过网络参数包括的本端客户端、以及对端客户端的地址和端口，建立与对端客户端之间数据通道；采集多媒体数据并通过数据通道传输至所述对端客户端，供对端客户端通过所述本端客户端的媒体流参数进行播放，以及，通过数据通道接收对端客户端采集的多媒体数据，根据对端客户端的媒体流参数在会话页面进行播放。本发明还公开了一种多媒体通信装置及存储介质。

Description

多媒体通信方法及装置、存储介质
技术领域
本发明涉及通信技术，尤其涉及一种多媒体通信方法及装置、存储介质。
背景技术
互联网特别是移动互联网得到快速发展，在终端中可供使用的客户端呈现多样化的趋势，涵盖工作、学习、消费和娱乐等许多方面。客户端的一个典型的应用是经由互联网进行音频/视频等形式的多媒体通信，以社交客户端为例，用户通过社交客户端可以与社交平台的其他用户进行即时通信，再以线上购物客户端为例，用户能够与卖家随时随地进行售前和售后的咨询。
目前，用户之间的通信局限在相同类型的客户端中，例如，同一社交平台的用户可以通过社交平台客户端进行通信，而不同类型的客户端无法进行跨客户端(类型)的多媒体通信，例如，社交平台客户端不能与线上购物客户端直接通信，这不可避免地影响了用户通信的效率。
例如，实际应用中经常存在用户在不同客户端之间切换，以与不同客户端的用户通信的场景，包括：用户在社交客户端中接收到好友发送的卖家网店链接，用户希望与卖家进行暂时的语音沟通，则需要将社交客户端切换到后台并调出线上购物客户端与卖家联系，之后再将社交客户端切换到前台继续与好友进行语音或视频的聊天。
相关技术目前提供将不同类型的客户端的后台服务器对接进行文本消息转发的方案，而多媒体通信的情况更为复杂，由于客户端类型的多样性，需要对不同类型客户端之间的通信协议和多媒体数据进行适配，一方面导致难以提供统一的跨客户端多媒体通信的解决方案，另一方面不同客户端之间的音/视频数据的适配、转发将消耗后台服务器的大量资源，延迟或数据丢失将难以避免。
发明内容
本发明实施例提供一种多媒体通信方法及装置、存储介质，能够以高效、资源集约化的方式实现跨客户端的多媒体通信。
本发明实施例的技术方案是这样实现的：
第一方面，本发明实施例提供一种多媒体通信方法，包括：
通过本端客户端中集成的浏览器内核加载会话页面，并通过所述浏览器内核执行所述会话页面中的脚本而实现以下操作：
通过信令服务器与对端客户端交换控制参数，所述控制参数包括网络参数和媒体流参数；
通过所述网络参数包括的所述本端客户端、以及所述对端客户端的地址和端口，建立与所述对端客户端之间数据通道；
采集多媒体数据并通过所述数据通道传输至所述对端客户端，供所述对端客户端通过所述本端客户端的媒体流参数进行播放，以及，
通过所述数据通道接收所述对端客户端采集的多媒体数据，根据所述对端客户端的媒体流参数在所述会话页面进行播放。
第二方面，本发明实施例提供一种多媒体通信装置，包括：
存储器，配置为存储可执行程序；
处理器，配置为通过执行所述存储器中存储的可执行程序时，实现本发明实施例提供的多媒体通信方法。
第三方面，本发明实施例提供一种存储介质，存储有可执行程序，所述可执行程序被处理器执行时，实现本发明实施例提供的多媒体通信方法。
应用本发明上述实施例具有以下有益效果：
第一、客户端通过内置浏览器内核而执行会话页面中的脚本，为建立数据通道交换控网络参数和媒体流参数，一方面，网络参数保证了数据通道能够克客户端的不同类型的限制而建立；另一方面，媒体流参数使得多媒体数据的采集和播放不会超出通信双方能力限制，确保了多媒体通信的质量；
第二、客户端通过内置浏览器内核的方式，能够容易地实现不同类型客户端之间在会话页面内的多媒体通信，同时也兼容相同类型的客户端之间在会话页面内的多媒体通信。
第三、客户端之间的数据通道是基于客户端的地址和端口建立，不需要经由客户端的后台服务器，一方面节约后台服务器资源，另一方面避免了经由后台服务器适配转发导致的延迟或数据丢失的问题，保证多媒体通信质量。
附图说明
图1是本发明实施例提供的终端的一个可选的软硬件结构示意图；
图2是本发明实施例提供的在客户端13中集成浏览器内核14的一个可选的结构示意图；
图3是本发明实施例提供的进行音/视频通信的一个可选的架构示意图；
图4是本发明实施例提供的多媒体通信方法的一个可选的流程示意图，涉及本端客户端、对端客户端、信令/房间服务器和中转服务器；
图5-1是本发明实施例提供的本端客户端与对端客户端之间进行多媒体通信而建立数据通道的一个可选的架构示意图；
图5-2是本发明实施例提供的本端客户端与对端客户端之间进行多媒体通信而建立数据通道的一个可选的架构示意图；
图6-1是本发明实施例提供的多个客户端进行多媒体通信的一个可选的实现示意图；
图6-2是本发明实施例提供的多个客户端进行多媒体通信的一个可选的实现示意图；
图7是本发明实施例提供的QQ客户端和微信客户端之间音视/频通信的架构示意图；
图8是本发明实施例提供的微信与QQ进行跨客户端音/视频通信的一个可选的流程示意图；
图9为以手机QQ与微信建立音/视频聊天为例建立中转数据通道的流程示意图；
图10是本发明实施例提供的微信客户端与手机QQ客户端通信的一个可选的场景示意图。
具体实施方式
以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
对本发明进行进一步详细说明之前，对本发明实施例中涉及的名词和术语进行说明，本发明实施例中涉及的名词和术语适用于如下的解释。
1)客户端，终端中用于实现网络通信的客户端，可以采用支持在终端中安装的移动应用(App)的形式，例如浏览器、社交客户端，等等，本文中客户端也称为节点(Peer)。
2)终端，支持安装客户端的电子设备，如智能手机、平板电脑和车载终端等。
3)浏览器内核，用于显示网页，并执行网页中的JavaScript(简称JS)实现网页中的交互功能，本文中所涉及的浏览器内核包括网络套件(Webkit)内核，以及以Webkit内核为基础修改形成的第三方的内核，例如QQ浏览器中集成的X5内核。
4)网络实时通信(WebRTC，Web Real-Time Communication)组件，包括在浏览器内核中实现的、用于实时通信的应用程序接口(API，Application Interface)，供集成浏览器内核的客户端调用，以在客户端显示的会话页面内与其他客户端实现直连的多媒体通信如音/视频的通信功能，所谓直连的多媒体通信是指，客户端与其他客户端之间建立点对点(P2P，Peer to Peer)的链路传输多媒体数据，链路中传输的数据不需要通过第三方服务器中转，仅由链路中的分组转发设备进行数据的传输，终端也无需再安装额外的应用或插件。
5)数据通道，客户端之间建立的用于传输数据的链路，还可以包括基于链路进行多媒体数据传输的控制(如开始、中止和结束)以及服务质量(QoS，Quality of Service)的控制。当链路仅包括分组转发设备，而不包括其他的服务器(如客户端的后台服务器、中转服务器)时，客户端之间的链路称为直连链路，直连链路所承载的数据通道称为直连数据通道；当链路中传输的数据需要通过中转服务器进行中转才能从一个客户端到达另一个客户端时，客户端之间的链路称为中转链路，所承载的数据通道称为中转数据通道。
6)房间，多媒体通信的客户端形成的会话，房间是分配有唯一地址的会话，会话的页面使用如统一资源定位符(URL，Uniform Resource Locator)表示，访问房间的任一客户端都会接收到来自访问该房间的其他客户端的音/视频数据。
下面说明本发明实施例所涉及的终端，参见图1，图1是本发明实施例提供的终端的一个可选的软硬件结构示意图，包括硬件层11、操作系统层12、客户端13、浏览器内核14和网络实时通信组件(也称为WebRTC组件)17，分别进行说明。
硬件层11，包括以下结构：
存储器112，可以提供为各种形式的非易失性存储器，例如可以是只读存储器(ROM，Read Only Memory)、可编程只读存储器(PROM，Programmable Read-Only Memory)、可擦除可编程只读存储器(EPROM，Erasable Programmable Read-Only Memory)等用于存储各种类型的数据以支持客户端13的操作，这些数据的示例包括：用于在客户端13上操作的任何计算机程序，如操作系统层12和客户端13等；本发明实施例提供的多媒体通信方法可以JS文件的形式预先存储在存储器112中，或者，由客户端13中的浏览器内核14在访问房间的页面时下载至存储器112中，用于供处理器111运行客户端13时，通过客户端13中集成的浏览器内核14执行JS文件，实现本发明实施例记载的多媒体通信方法。
处理器111，可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，本发明实施例提供的多媒体通信方法的各步骤可以通过处理器111中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器111可以是通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。
网络接口113，用于客户端13有线或无线方式的通信，网络接口113可以接入基于通信标准的无线网络，如WiFi、2G、3G、4G和4G的演进或它们的组合。
操作系统层12，包含各种系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件层11的任务，本发明实施例中不排除使用任意类型的操作系统，包括基于Linux内核的操作系统如安卓系统，还可以包括iOS系统和类Unix系统。
客户端13，是具有网络通信需求的客户端如微信/QQ等应用程序，本发明实施例不排除终端10中运行任意类型的客户端。
客户端13用于实现客户端的具体业务逻辑，以客户端为微信为例，业务逻辑用于通过与微信后台服务器的交互，实现用户在社交平台的通信、分享等功能。
客户端13中集成有浏览器内核14，用于在客户端13中实现浏览器功能和直连的多媒体通信功能，需要指出地，虽然浏览器内核14集成于客户端13，可以理解，客户端13与浏览器内核14能够作为两个相互独立的实例运行，因此下文中客户端13与浏览器内核14的通信不应视为与图1示出的结构冲突，结合浏览器内核14的结构就上述功能分别进行说明：
1)浏览器功能
浏览器内核14中集成有两个基本的模块：页面渲染引擎15，例如可以采用网络核心(Web Core)引擎，用于在客户端13中实现网页的显示，包括加载网页的数据并渲染网页，典型的应用是包含了请求网页、加载数据、渲染网页的过程；JS解释器16，用于解释、并执行页面渲染引擎15渲染的网页中的JS，例如可以采用Javascript(简称JS)Core引擎，通过解释执行JS实现网页的交互功能、以及网页的增强功能，例如提交表单前先验证数据的合法性，根据客户操作实现一些页面中的动画效果，等等。
2)直连的多媒体通信功能
浏览器内核14中还集成有网络实时通信组件17，以向客户端13提供进行实时通信的API，当API为JS接口时，网络实时通信组件17可以提供为后缀名为“.js”的JS文件的软件实施方式，根据需要下发到客户端13由浏览器内核14中的JS解释器16解释执行，使得客户端13调用API能够建立与其他客户端的数据通道，这个数据通道可以传输任何数据，而且不需要通过第三方服务器(如客户端13的后台服务器)进行中转；网络实时通信组件17还向客户端13提供调用终端10的外设如摄像头/麦克风的接口，采用音频/视频数据在通道中传输而实现多媒体通信的功能。
举例来说，网络实时通信组件17中实现了三个API，分别是：
2.1)点连接(Peer Connection)接口172，供客户端13调用，封装了一系列的通过信令供进行多媒体通信的客户端进行以下控制参数的交换/协商的方法：
2.1.1)网络参数，包括：
2.1.1.1)客户端13的网际协议(IP，Internet Protocol)地址和端口(即客户端的宿主终端中为客户端13所分配的用于网络通信的端口)，例如，当客户端13处于局域网时为局域网的IP地址和端口，当处于广域网时为广域网的网际协议(IP，Internet Protocol)地址和端口；
2.1.1.2)客户端13的带宽，即客户端13的接入网络所能提供的接入互联网时能够提供的带宽；
2.1.1.3)客户端13所处局域网或防火墙的IP地址和端口，客户端13所处局域网或防火墙的IP地址是指，局域网的网络地址转换(NAT，Network Address Translators)设备或防火墙的广域网IP地址；客户端13所处局域网或防火墙的端口是指，局域网的NAT设备或防火墙为向局域网或防火墙传入数据包而开通的端口。
2.1.2)媒体流参数，包括：客户端13的媒体支持的音频的编/解码器、采样率和比特率；客户端支持的视频的编/解码器、帧率、分辨率和比特率；
2.1.3)会话控制参数，用于在客户端13之间同步数据通道的状态，创建、保持、监控和关闭与对端客户端(相应地，客户端13可以称为本端客户端)之间的数据通道；
需要指出地，客户端13与对端客户端之间的数据通道可以使用基于用户数据报协议(UDP，User Datagram Protocol)的链路承载以保证数据传输效率，并可以使用DTLS保证会话的安全性，当然本文中不排除客户端之间的数据通道使用基于传输控制协议(TCP，Transmission Control Protocol)链路承载时，相应地，使用安全套接层(SSL，SecureSockets Layer)/传输层安全(TLS，Transport Layer Security)时实现数据通道的加密传输。
以上参数仅为举例，客户端13通过调用点连接接口172，可以是与对端客户端之间交换会话相关的任意参数，本发明实施例不排除交换任何与会话相关的参数，例如用于实现加密通信的相关安全参数如密钥算法、服务质量(QoS，Quality of Service)参数以及需要进行加密的情况时用于协商加密密钥的安全参数如数字证书和加密算法等。
2.2)媒体流(Media Stream)接口173，供客户端13调用，封装了一系列的用于进行以下操作的方法：获得终端10通过外设如麦克风/摄像头而对应采集同步的音/视频流；
2.3)数据通道(Data Channel)接口171，供客户端13调用，封装了一系列的用于进行以下操作的方法：通过与对端客户端之间的数据通道传输音/视频流。
下面说明在客户端13中集成浏览器内核14的结构，参见图2，图2是本发明实施例提供的在客户端13中集成浏览器内核14的一个可选的结构示意图，浏览器内核14能够在不同的操作系统上运行。
在操作系统层12之上的是浏览器内核14赖以运行的第三方库，通常来讲，包括图形(Graphics)库、网络(Network)库、存储(Storage)库、字体(Fonts)库、传感器(Sensors)库、音频/视频(A/V)库、定位库和小工具(Widgets)库等，完成基本的加载和渲染网页的操作，这些第三方库以平台API(区别于前述的API)的方式向浏览器内核14提供调用。
图2中，浏览器内核14的页面渲染引擎15采用WebCore引擎，JS解释器16采用JSCore引擎，WebCore引擎包括显示网页的基础组件，例如超文本标记语言(HTML，Hyper TextMarkup Language)解释器、层叠样式表(CSS，Cascading Style Sheets)解释器、可缩放矢量图形(SVG)解释器等；WebCore引擎渲染网页的一个示例性的过程包括：用户发起访问网页的命名，联网获得HTML网页的数据，解析网页数据生成HTML文本对象模型(DOM，DocumentObject Model)，生成渲染树(Render)树，使用CSS排版网页，并渲染网页。
JSCore引擎是浏览器内核14中的默认的JS的解释器，但不排除替换为其他类型的解释器的情况，在浏览器内核14之上主要供客户端13调用的网络实时通接口17。
前文为了方便说明，对于网络实时通信组件17只示出了面向客户端以供客户端调用的结构，下文中将对网络实时通信组件17的具体结构对通过网络实时通信组件17进行音/视频通信的架构进行说明，参见图3，图3是本发明实施例提供的进行音/视频通信的一个可选的架构示意图，在图3中隐去了图2中示出的客户端13的部分结构，以客户端13为本端客户端，以客户端23为对端客户端为例，可以理解本端客户端与对端客户端是相对的概念，二者是运行于不同终端的客户端，客户端13与客户端23进行音/视频通信的架构涉及：信令机制和数据通道；每个客户端中集成网络实时通信组件17，分别进行说明。
信令机制，协调客户端13与客户端23之间为建立数据通道，而经由信令服务器进行信息交换的过程，客户端13(或客户端23)与信令服务器(Signaling Server)的连接也称为信令信道，涉及以下几个方面：
1)通过信令交换通信双方的媒体流参数
根据会话描述协议(Session Description Protocol)，客户端13将自身的媒体流参数封装到请求(Offer)SDP信令中，通过信令服务器发送到客户端23；客户端23建立一个包含自身的源数据的应答(Answer)SDP信令，通过信令服务器传输给客户端23，这样，客户端13与客户端23均获知了对方的媒体流参数；
另外，对于会话控制参数，以及客户端的数据通道需要进行加密的情况时用于协商加密密钥的安全参数如数字证书、加密算法等，都可以通过请求/应答的信令机制进行交换，同样地，用于音/视频通信的服务质量(QoS，Quality of Service)参数也可以通过上述请求/应答的信令机制进行交换。
2)通过信令交换网络参数
根据ICE协议，客户端13将网络参数封装在ICE竞争(Candidate)信令中，通过信令服务器中转以传递给客户端23，客户端23从信令服务器所发送过来交互式连接建立ICECandidate信令时，提取得到网络参数；同样，客户端23将网络参数封装在ICE Candidate信令中，通过信令服务器中转，传递给客户端13，客户端13从信令服务器所发送过来ICECandidate信令时，解析并获得网络参数；这样，客户端13与客户端23均获得了对方的网络参数。
一个可能的情况是，客户端处于防火墙内，因而无法直接建立直连的数据通道，这种情况下客户端之间需要通过中转服务器进行数据交互，网络实时通信组件17使用ICE协议来整合各种NAT穿透技术，如NAT的用户数据报(UDP，User Datagram Protocol)的简单穿透(STUN，Simple Traversal of UDP Through NAT)协议、中继NAT的穿透(TURN，TraversalUsing Relay NAT)协议；作为示例，客户端13首先使用STUN尝试获得广域网IP地址，以建立与客户端23之间的使用UDP的直连数据通道(例如，通过发送探测数据的方式检测数据通道是否可用)，如果失败，就会去尝试建立使用传输控制协议(TCP，Transmission ControlProtocol)的直连数据通道，其中按照超文本传输协议(HTTP)、超文本传输(先尝试HTTP，然后尝试HTTPS)，如果依旧失败，则会通过一个中继的TURN服务器与客户端23建立用于进行数据中转的中转数据通道。
需要指出，客户端13与信令服务器之间的信令信道可以采用网络套接字(Websocket)连接，Websocket连接支持客户端13(或客户端23)与信令服务器执行握手操作后，形成与信令服务器之间的全双工的信令信道；当然，客户端13(或客户端23)与信令服务器之间的信令信道不排除使用其他机制，如客户端13(或客户端23)与信令服务器定期建立连接，轮询信令然后释放连接。
针对客户端13的网络实时通信组件17进行说明，同样适用于客户端13的网络实时通信组件17，涉及以下部分：
1)网络接口(Web API)层174，面向客户端13的API，包括如图1示出的点连接接口172、媒体流接口173和数据通道接口171；
2)本地C++API层175，是给客户端13提供的实现Web API的入口，屏蔽底层操作系统的差异，对数字信号的处理过程抽象为本地C++API，从而具有跨平台的特性；
3)会话管理层176，提供客户端13与对端客户端之间的直连的数据通道的建立和管理功能，当客户端13与客户端23能够建立直连的数据通道时数据通道传输音/视频数据，当客户端13与客户端23不能建立直连的数据通道时，如因为客户端处于防火墙或局域网内无法建立直连的数据通道时，由STUN/ICE协议层177负责经由中转服务器交换音/视频数据。
4)STUN/ICE协议层177，NAT的用户数据报(UDP，User Datagram Protocol)的简单穿透(STUN，Simple Traversal of UDP Through NAT)协议，用于使用隧道技术跨越NAT/防火墙，建立处于NAT/防火墙的客户端之间的数据通道；ICE框架用于从STUN服务器(位于广域网)获得用于NAT/防火墙穿透的IP地址和端口，使目的地址为客户端的广域网IP地址和端口的多媒体数据能够被NAT设备分发至对端客户端。
5)音频引擎(Voice Engine)178，是包含一系列音频多媒体处理的框架，涉及以下组件：
5.1)因特网语音解码器(iSAC，Internet Speech Audio Codec)，针对网络电话协议(VoIP，Voice over Internet Protocol)音频流的宽带/超宽带音频编解码器，是音频引擎178的默认的编解码器；
5.2)因特网低速率解码器(iLBC，Internet Low Bitrate Codec)，VoIP音频流的窄带语音编解码器；
5.3)网络语音均衡器(Net EQualizer for Voice)，通过软件实现的语音信号处理元件，自适应抖动控制算法以及语音包丢失隐藏算法，能够快速且高解析度地适应不断变化的网络环境，确保音质并减小缓冲延迟；
5.4)回声消除器(AEC，Acoustic Echo Canceler)，通过软件实现的信号处理元件，能实时的去除麦克风采集到的回声；
5.5)噪声抑制(NR，Noise Reduction)，通过软件的信号处理元件，用于消除与相关VoIP的某些类型的背景噪声。
6)视频引擎(Video Engine)179，包含一系列视频处理的框架，提供从摄像头采集视频到视频数据网络传输、视频数据界面显示的功能，涉及以下组件：
6.1)视频图像编解码器(记为VP8Codec)，视频引擎179的默认的编解码器；
6.1)视频抖动缓冲器，用于可以降低由于视频抖动和视频信息包丢失带来的不良影响；
6.2)图像质量增强模块，用于对网络摄像头采集到的图像进行处理，包括明暗度检测、颜色增强、降噪处理等功能，用来提升视频质量。
至此，已经对终端10、终端中运行的客户端13、浏览器内核14以及网络实时通信组件17进行了说明，下面，以首先建立会话的客户端为本端客户端，请求加入会话的客户端为对端客户端为例，对客户端进行多媒体通信的过程进行说明，可以理解，本端客户端与对端客户端是相对的概念，例如在一个会话中的本端客户端，在另一个会话中可以为对端客户端；另外，对于本端客户端与对端客户端而言，可以是相同类型客户端，当然，也可以是不同类型的客户端，例如客户端13是微信客户端，客户端23是QQ客户端。
参见图4，图4是本发明实施例提供的多媒体通信方法的一个可选的流程示意图，涉及本端客户端、对端客户端、信令/房间服务器和中转服务器，其中，信令/房间服务器是指，单独部署的信令服务器和房间服务器，当然，也可以是指将房间服务器的房间管理的功能融合到信令服务器中；针对图4示出的各个步骤进行说明。
步骤101a，本地客户端需要进行跨客户端的多媒体通信时，向房间服务器请求访问用于会话的房间。
作为示例，本端客户端中预先配置信令服务器的IP地址，预先向房间服务器请求分配房间，即可以访问房间的会话页面的地址，当本端客户端需要进行多媒体通信时，根据房间服务器分配的对应房间的会话页面的地址，向房间服务器发送访问请求。
作为示例，本端客户端需要与其他客户端进行跨客户端的多媒体通信，或者，需要向其他客户端提供跨客户端的接入支持时，向房间服务器提交必要的鉴权信息，如本地客户端的版本、登录用户的标识信息(如登录用户名称、登录用户账号等)，房间服务器中配置有允许进行多媒体通信的客户端的描述信息(如客户端的类型、版本等等)，根据鉴权信息鉴权成功，针对本端客户端分配房间，包括对应房间的会话页面的地址；将本地客户端定向至分配的会话页面的地址进行访问。
客户端之间进行多媒体通信的一个可能的情况是，不同类型的客户端的用户标识难以识别；针对这种情况，房间服务器对于每个申请房间或请求加入已有房间的客户端分配全局统一的序列号(ID)，房间服务器维护ID与客户端类型(如客户端是微信还是QQ)、登录用户名(微信账户名、QQ账户名)的映射关系，并同步至下文记载的中转服务器和信令服务器，使得用于实现多媒体通信的各服务器使用ID即可区分不同客户端，保证后续信令/数据处理的效率。
将继续根据步骤102a对本端客户端向对端为客户端分享房间的会话页面的后续处理说明。
步骤102a，本端客户端调用本端客户端中集成的浏览器内核，根据房间服务器返回的房间的会话页面的数据，显示对应的会话页面，并通过浏览器内核执行会话页面中的脚本。
其中，本端客户端中集成的浏览器内核执行会话页面中的脚本，除了实现会话页面中的基本交互功能，还执行网络实时通信组件17的JS文件，与对端客户端交换控制参数、建立数据通道以及通过数据通道传输多媒体数据，将在下文中根据步骤103a至步骤105a、步骤106至步骤111进行说明。
步骤103a，本端客户端向信令服务器请求分配中转服务器。
在本发明可选实施例中，一个可能的情况是，本端客户端与对端客户端因为各种原因(如处于防火墙内，或配置了NAT即处于局域网中)时，由于本端客户端与对端客户端不具有广域网IP地址，因而无法建立直连的TCP链路或UDP链路(以用于承载直连的数据通道)；针对这种情况，有必要为本端客户端配置中转服务器，用以实现NAT/防火墙的穿透，以及，在未能实现NAT/防火墙的穿透时，经由中转服务器建立本端客户端与对端客户端之间的中转数据通道。
举例来说，借助于中转服务器为本端客户端以及对端客户端探测的NAT设备或防火墙配置的广域网IP地址和端口，本端客户端发送的数据的目的地址和目的端口，如果对应设置为对端客户端的NAT设备或防火墙的广域网IP地址和端口，那么，NAT设备或防火墙通过自身的广域网IP地址和端口、与对端客户端的局域网IP地址和端口的映射关系，可以识别出来自本端客户端的数据的目的地为对端客户端，从而实现NAT/防火墙的穿透；借助于中转服务器探测的广域网IP地址和端口尝试建立本端客户端与对端客户端之间的直连数据通道，如果失败，则通过中转服务器建立中转数据通道。
为此，步骤101a中，当本端客户端向房间服务器发送访问请求时，还可以通过执行步骤103a向信令服务器请求分配中转服务器，可以理解，步骤103a为可选执行的步骤。
另外，客户端之间进行多媒体通信的一个可能的情况是，不同类型的客户端的用户标识难以识别；针对这种情况，房间服务器对于每个申请房间或请求加入已有房间的客户端分配全局统一的序列号(ID)，信令服务器维护ID与客户端类型(如客户端是微信还是QQ)、登录用户名(微信账户名、QQ账户名)的映射关系，并同步给中转服务器，使得用于实现多媒体通信的各服务器使用ID即可区分不同客户端，提升后续信令/数据处理的效率。
步骤104a，本端客户端获得信令服务器返回的中转服务器的IP地址和鉴权信息。
在本发明可选实施例中，如前步骤103a所述，当本端客户端还向信令服务器请求分配中转服务器时，信令服务器根据筛选规则(如链路最短的规则、优先保证链路QoS的规则等)选择中转服务器，将选择的中转服务器的IP地址发送给本端客户端；此外，为了避免非法客户端对中转服务器的滥用、并保证中转服务器的负载均衡，信令服务器还可以向本端客户端发送访问中转服务器的鉴权信息，包括登录中转服务器的有效时间(time)，登录中转服务器的用户名(记为user)和密码(记为password)，本端客户端根据鉴权信息的操作将在步骤104a说明，可以理解，步骤104a为可选执行的步骤。
步骤105a，本端客户端根据中转服务器的鉴权信息，请求中转服务器探测本端客户端的NAT设备/防火墙的广域网IP地址和端口，并获得探测结果。
局域网中所有客户端发送到互联网中的数据包，被NAT设备发送到互联网中之前，替换为NAT设备的广域网IP地址，源端口被替换为客户端分配的端口(允许互联网中的数据传入客户端所使用的端口)，NAT设备在端口映射表中记录为客户端分配的端口、以及客户端的局域网IP地址和端口，对于来自互联网的数据包，替换数据包的目的地址和端口，即替换为根据数据包的目的端口查找对应的客户端的局域网IP地址和端口，使得数据包能够在局域网中传输至对应的客户端。
防火墙的处理类似，由上可知，本端客户端与所处局域网中的其他客户端所发送的数据包，在互联网中传输时携带的源地址为相同的广域网IP地址(即NAT设备的广域网IP地址)，源端口根据客户端而存在区别，NAT设备记录不同客户端与为客户端发出的源端口的映射关系，NAT设备根据传回数据包的目的端口，以及映射关系实现数据包在局域网内的分发；当本端客户端向中转服务器发送请求时，请求携带的广域网IP地址和端口为NAT设备为本端客户端分配的，返回本端客户端即可使本端客户端获知NAT设备的广域网IP地址和端口。
至此，已经说明了本端客户端在与对端客户端交换控制参数、建立数据通道以及传输多媒体数据之前所执行的操作，对于对端客户端来说，当需要加入房间与本端客户端进行多媒体通信时，需要执行与前述步骤类似的处理，下面进行说明。
本端客户端与对端客户端执行控制参数交换、数据通道建立以及传输多媒体数据之前，对端客户端需要加入本端客户端的房间，以获得相应会话页面的JS文件，通过执行JS文件，完成控制参数交换、数据通道建立以及传输多媒体数据；下面根据步骤106、步骤101b至步骤105b，针对对端客户端访问同一房间的会话页面的实现过程进行说明，需要指出，由于本端客户端一旦获知房间的会话页面的地址，可以随时发起分享操作，因此，步骤106、步骤101b至步骤105b的执行顺序，与前述步骤101a至步骤105a之间不存在先后顺序的限制。
步骤106，本端客户端分享房间的会话页面的地址给对端客户端。
作为示例，本端客户端通过明文和二维码等形式，将房间的会话页面的地址分享给对端客户端，以本端客户端为QQ客户端为例，QQ客户端的用户可以将会话页面的地址在QQ客户端中发送到其他用户的QQ客户端，或者，QQ客户端的用户调用用户本地的微信客户端的分享接口，将会话页面的地址发送到其他用户的微信客户端，分享的方式多样，不再一一说明。
步骤101b，对端客户端需要与本端客户端在房间内进行跨客户端的多媒体通信时，根据本端客户端的房间的会话页面的地址，向房间服务器请求访问房间。
作为示例，对端客户端向房间服务器提交必要的鉴权信息，如本地客户端的版本、登录用户的标识信息(如登录用户名称、登录用户账号等)，房间服务器中配置有允许进行多媒体通信的客户端的描述信息(如客户端的类型、版本等等)，根据鉴权信息鉴权成功，通知本端客户端对端客户端的用户加入房间，例如，根据客户端的登录用户名与客户端的全局ID的对应关系，提示当前加入房间的用户的名称，并向对端客户端将向对端客户端下发会话页面的数据以及相关的JS文件，定向对端客户端至房间的会话页面的地址进行访问。
步骤102b，对端客户端调用对端客户端中集成的浏览器内核，根据房间服务器返回的房间的会话页面的数据，显示对应的会话页面，并通过所述浏览器内核执行会话页面中的脚本。
对端客户端中集成的浏览器内核执行会话页面中的脚本，除了实现会话页面中的基本交互功能，还执行网络实时通信组件17的JS文件，与本端客户端交换控制参数、建立数据通道以及通过数据通道传输多媒体数据，将在下文中根据步骤108至步骤111进行说明。
步骤103b，对端客户端向信令服务器请求分配中转服务器。
在本发明可选实施例中，一个可能的情况是，如前所述，本端客户端与对端客户端因为各种原因(如处于防火墙内，或处于配置NAT的局域网中)时，有必要为本端客户端和对端客户端配置中转服务器，借助于中转服务器为本端客户端以及对端客户端探测NAT设备或防火墙的广域网IP地址和端口，尝试建立本端客户端与对端客户端之间的直连数据通道，如果失败，则通过中转服务器建立中转数据通道；为此，步骤101b中，当本端客户端向房间服务器发送访问请求时，还可以通过执行步骤103b向信令服务器请求分配中转服务器，可以理解，步骤103b为可选执行的步骤。
步骤104b，对端客户端获得信令服务器返回的中转服务器的IP地址和鉴权信息。
在本发明可选实施例中，如前步骤103b所述，当对端客户端还向信令服务器请求分配中转服务器时，信令服务器根据筛选规则(如链路最短的规则、优先保证链路QoS的规则等)选择中转服务器，将选择的中转服务器的IP地址发送给对端客户端；此外，为了避免非法客户端对中转服务器的滥用、并保证中转服务器的负载均衡，信令服务器还可以向对端客户端发送访问中转服务器的鉴权信息，包括登录中转服务器的有效time，登录中转服务器的user和password，对端客户端根据鉴权信息的操作将在步骤105b说明，可以理解，步骤105b为可选执行的步骤。
步骤105b，对端客户端根据中转服务器的鉴权信息，请求中转服务器探测对客户端的NAT设备/防火墙的广域网IP地址和端口。
与步骤105a类似，至此，已经说明了对端客户端在与本端客户端交换控制参数、建立数据通道以及传输多媒体数据之前所执行的操作，下面结合后续步骤对本端客户端和对端客户端执行JS文件所执行的交换/协商控制参数、建立数据通道以及传输数据的处理进行说明。
步骤107a，本端客户端进行初始化。
步骤107b，对端客户端进行初始化。
作为示例，本端客户端和对端客户端的初始化涉及以下几个方面：1)本地音/视频流的初始化；2)初始化点连接(Peer Connection)对象，当需要传输音/视频流时，利用PeerConnection对象进行音/视频传输的相关控制；3)初始化用于创建SDP信令和Candidate信令的对象，后续在对象中填充控制信息生成携带相应控制信息的信令。
步骤108，本端客户端通过信令服务器与对端客户端交换/协商控制参数。
控制参数包括前述的网络参数、媒体流参数以及其他类型的控制参数，如QoS参数、安全参数等，通过信令机制经由信令服务器与对端客户端进行控制参数的交换，或者，可以进行控制参数的协商，分别对上述的参数的交换/协商说明。
1)媒体流参数的交换/协商
本地客户端收集自身的媒体流参数，携带在Offer SDP信令中，通过信令服务器中转发送到对端客户端，对端客户端从Offer SDP信令提取本端客户端的媒体流参数存储，并将对端客户端的媒体流参数携带在Answer Offer信令中发送给本端客户端，同样地，本端客户端从Answer Offer信令中提取对端客户端的网络参数并存储，至此完成媒体流参数的交换；
对于媒体流参数的协商而言，本端客户端将自身支持的音频编/解码的候选参数、以及自身支持的视频编/解码的候选参数，携带在Answer Offer信令中通过信令服务器发送至对端客户端，对端客户端提取出相关的参数，根据自身的能力选择使用的音频编/解码的参数、以及视频编/解码的参数，携带在Answer Offer信令中通过信令服务器发送至本端客户端，本端客户端从Answer Offer信令提取参数，至此完成媒体流参数的协商，双方使用协商的参数进行编/解码处理。
对于其他类型的控制参数，如QoS参数和安全参数等，本地客户端可以参考上述媒体流参数的交换/协商方式。
2)网络参数的交换/协商
本地客户端将自身所支持的网络参数，如本端客户端的广域网IP地址和端口(如果有)、本端客户端局域网的IP地址和端口(如果有)、NAT设备/防火墙的广域网IP地址和端口(如果有)等，携带在Candidate信令中，通过信令服务器发送到对端客户端，对端客户端从Candidate信令中提取本端客户端的网络参数并存储；同样地，对端客户端将自身配置的网络参数携带在Candidate信令中，通过信令服务器发送到本端客户端，本端客户端从Candidate信令中提取对端客户端的网络参数并存储，至此完成网络参数的交换；
对于网络参数的协商而言，本端客户端将自身支持候选的网络参数如带宽，携带在Answer Offer信令中通过信令服务器发送至对端客户端，对端客户端提取出相关的参数，根据自身的能力选择使用的音频编/解码的参数、以及视频编/解码的参数，携带在Answer Offer信令中通过信令服务器发送至本端客户端，本端客户端从Answer Offer信令提取参数，至此完成媒体流参数的协商，双方使用协商的参数进行编/解码处理。
步骤109，本端客户端通过网络参数包括的本端客户端、以及对端客户端的地址和端口，建立与对端客户端之间的数据通道。
针对本端客户端与对端客户端的网络情况，对数据通道的建立方式进行说明。
1)本地客户端与对端客户端均处于广域网，即具有用于进行多媒体通信的广域网的IP地址和端口。
参见图5-1，图5-1是本发明实施例提供的本端客户端与对端客户端之间进行多媒体通信而建立数据通道的一个可选的架构示意图；通过前述步骤记载的本端客户端与对端客户端交换网络参数的交换，本端客户端与对端客户端已经获知了对方的广域网IP地址和端口，本端客户端与对端客户端通过TCP三次握手操作建立基于TCP的直连链路，用于承载本端客户端与对端客户端之间的直连数据通道，基于TCP的链路能够保证数据的可靠传输；
作为替换方案，本端客户端与对端客户端之间的直连数据通道使用基于UDP的直连链路承载，一旦本端客户端向对端客户端发送探测数据，当接收到(例如在超时时间内)对端客户端在接收到探测数据而返回的探测数据时，说明UDP直连链路已经成功建立；UDP直连链路用于承载本端客户端与对端客户端之间的直连数据通道，由于UDP是面向无连接的，不保证数据的可靠到达，因此对于用户感知来讲，网络抖动、延迟仅会导致音/视频通信的卡顿但是不会导致通信的中断，具有良好的容错性能。
2)本地客户端与对端客户端处于防火墙内或者处于局域网(即配置NAT设备)中，并建立直连数据通道。
参见图5-2，图5-2是本发明实施例提供的本端客户端与对端客户端之间进行多媒体通信而建立数据通道的一个可选的架构示意图；由于防火墙的过滤功能，因此即使客户端具有广域网IP地址也无法建立直连的数据通道；由于客户端处于局域网中不具有广域网IP地址，因此客户端同样无法建立直连数据通道，
图5-2中示出了STUN服务器和TURN服务器两种中转服务器；STUN服务器用于探测客户端的NAT设备/防火墙的广域网IP地址和端口，例如与本端客户端通信的STUN服务器用于探测对端客户端的广域网IP地址和端口，并通知本端客户端，与对端客户端通信的STUN服务器用于探测本端客户端的广域网IP地址和端口，并通知对端客户端；TURN服务器用于提供数据中转功能。
本端客户端和对端客户端会尝试通过STUN服务器探测的广域网IP地址和端口建立直连数据通道，根据承载直连数据通道使用的协议，建立直连数据通道的方式有所区别，分别进行说明：
2.1)直连数据通道使用基于UDP的链路承载时，本端客户端与对端客户端互相发送探测数据检测链路是否建立。
本端客户端发送探测数据，目的地址和端口对应为对端客户端的NAT设备/防火墙的广域网IP地址和端口，对端客户端的NAT设备/防火墙根据记录的端口映射表查询到的对端客户端的局域网IP地址和端口，将探测数据发送到对端客户端；
对端客户端接收到探测数据后发送探测数据，目的地址和端口对应为本端客户端的NAT设备/防火墙的广域网IP地址和端口，本端客户端的NAT设备/防火墙根据记录的端口映射表查询到的本端客户端的局域网IP地址和端口，将探测数据发送到本端客户端，至本端客户端接收到对端客户端返回探测数据为止，表示直连链路已经成功建立。
2.2)直连数据通道使用基于UDP的链路承载时，本端客户端与对端客户端通过三次握手尝试建立TCP链路，如果成功，则表示TCP链路已经成功穿透了防火墙/NAT设备，客户端之间的直连数据通道已经建立。
本端客户端与对端客户端握手过程，涉及以下的步骤：
第一次握手：本端客户端发送同步序列编号(SYN，Synchronize SequenceNumbers)包(SYN＝j)包到对端客户端，并进入SYN_SENT状态，等待对端客户端确认；
SYN包的目的地址和端口对应为对端客户端的NAT设备/防火墙的广域网IP地址和端口，对端客户端的NAT设备/防火墙根据记录的端口映射表查询到的对端客户端的局域网IP地址和端口，将数据包发送到对端客户端。
第二次握手：对端客户端收到SYN包，发送确认本端客户端的SYN包的确认包(ACK)(ACK＝j+1)，并发送一个SYN包(SYN＝k)，即SYN+ACK包，此时对端客户端进入SYN_RECV状态；
SYN+ACK包，目的地址和端口对应为本端客户端的NAT设备/防火墙的广域网IP地址和端口，本端客户端的NAT设备/防火墙根据记录的端口映射表查询到的本端客户端的局域网IP地址和端口，将SYN+ACK包发送到本端客户端。
第三次握手：本端客户端受到对端客户端的SYN+ACK包，向对端客户端发送确认包ACK(ACK＝k+1)，发送完毕，双方进入连接成功状态，完成三次握手，至此，本端客户端与对端客户端之间基于TCP链路承载的直连数据通道建立。
3)本端客户端和对端客户端会尝试通过STUN服务器探测的广域网IP地址和端口建立直连数据通道失败，通过TURN服务器建立中转数据通道。
本端客户端向TURN服务器发送探测数据，在经过NAT设备/防火墙时，探测数据的源IP地址和端口被替换为NAT设备/防火墙的广域网IP地址和端口(NAT设备/防火墙允许向本地客户端传入数据所使用的端口)，TURN服务器将探测数据转发至对端客户端，对端客户端回复的探测数据在经过NAT设备/防火墙时进行了相似的处理，源IP地址和端口被替换为NAT设备/防火墙的广域网IP地址和端口(NAT设备/防火墙允许向对端客户端传入数据所使用的端口)，这样，TURN服务器将本端客户端的NAT设备/防火墙的广域网IP地址和端口、对端客户端的NAT设备/防火墙的广域网IP地址和端口、以及中转数据通道的标识进行绑定，绑定的一个示例为<对端客户端IP地址和端口；本端客户端IP地址和端口；数据通道序列号>，中转服务器能够根据记录的绑定关系在对端客户端和本端客户端之间进行数据中转。
步骤110，本端客户端和对端客户端采集多媒体数据，并通过数据通道传输。
在本发明可选实施例中，在通过数据通道传输多媒体数据的过程中，本端客户端和对端客户端仍然可以通过信令服务器交换网络参数、媒体流参数和会话控制参数等控制参数。
例如，通过交换更新的网络参数，在已经建立中转数据通道的情况下可以继续尝试建立直连数据通道，并在建立成功时将多媒体数据切换到直连数据通道传输，反之亦然，保证本端客户端与对端客户端能够建立数据通道的基础上，优先使用直连数据通道，最大程度降低音/视频通信的延迟；
再例如，通过交换会话控制参数，可以随时对音/视频聊天进行控制，如暂停、继续和结束等；又例如，通过交换QoS参数，可以根据本端客户端与对端客户端之间的链路质量进行适配，实现音/视频通信效果根据链路质量的自适应；
步骤111，本端客户端和对端客户端通过数据通道接收多媒体数据，根据媒体流参数解码多媒体数据，在会话页面进行播放。
作为示例，本端客户端与对端客户端通过信令服务器交换了媒体流参数，双方均或者对方传输的媒体流的编/解码器信息，接收方根据发送方采用的编码器而使用对应的解码器进行解码播放；当然，在解码播放的过程中双方仍可以交换媒体流参数，例如对帧率和分辨率等进行协商，实现在音/视频通信过程中仍然可以根据用户需求动态调整的效果。
在本发明可选实施例中，为了保证音/视频通信不被第三方监听，有必要对数据通道中传输的多媒体数据进行加密，为了尽量减少加/解密过程的资源消耗，采用对称加密算法对数据加密以及解密，当然，不排除使用不对称加密算法的情况；对本端客户端与对端客户端在采集多媒体数据并通过数据通道传输至对端客户端之前，通过数据通道与对端客户端进行加密协商操作，确定在数据通道中传输多媒体数据使用的加密算法和会话密钥，对数据通道中传输/接收的数据对应进行加密/解密处理，适用于数据通道(包括直连数据通道和中转数据通道)使用TCP链路或UDP链路的情况。
举例来说，首先，本端客户端向对端客户端发送所支持的加密算法集的列表给对端客户端进行选择；每个加密算法集包括一系列用于实现加密的信息，如证书认证算法(用于验证数字证书是否有效的算法)、密钥交换算法(用于生成对数据通道中传输的数据进行加密的密钥)、加密算法和消息验证算法(用于对密钥交换算法生成的密钥再次添加一段后缀，以形成完整的密钥)；
其次，对端客户端将所选定的加密算法集、数字证书发送给本端客户端，数字证书中携带对端客户端的公钥以及对端客户端的对称密钥；
再次，本端客户端根据证书验证算法(即对端客户端选定的加密算法集中的证书认证算法)、结合对端客户端的公钥对来自对端客户端的数字证书进行验证，验证通过后，发送本端客户端的数字证书、本端客户端的公钥以及本端客户端的密钥至对端客户端；
最后，对端客户端同样根据证书验证算法(即对端客户端选定的加密算法集中的证书认证算法)、结合本端客户端的公钥对来自本端客户端的数字证书进行验证，验证通过后，使用消息验证算法对本端客户端以及对端客户端的密钥进行处理形成会话密钥，本端客户端根据消息验证算法进行与对端客户端相同的处理，这样，本端客户端与对端客户端得到了相同的会话密钥。
本发明实施例前述记载的是本端客户端与对端客户端两个客户端进行多媒体通信为例，本发明实施例记载的多媒体通信同样适用于多个客户端进行多媒体通信的情况，当然，多个客户端可以相同类型或不同类型的客户端，其架构仍然可以根据图1至图3而理解。
作为多个客户端进行多媒体通信的示例，参见图6-1，图6-1是本发明实施例提供的多个客户端进行多媒体通信的一个可选的实现示意图，以客户端1、客户端2和客户端3为例，任意两个客户端根据前述的本端客户端与对端客户端，经由信令服务器进行控制参数的交换，建立点对点的数据通道，其中建立直连数据通道还是中转数据通道取决于客户端所处网络的情况。
另外，当加入一个房间的客户端的数量比较多时，根据图6-1示出的客户端之间两两建立数据通道的方案，客户端的负荷会显著提高，甚至出现不稳定的情况；以客户端1为例，客户端1为本端客户端，客户端2和客户端3为相对于客户端1的对端客户端，那么，参见图6-2，图6-2是本发明实施例提供的多个客户端进行多媒体通信的一个可选的实现示意图，当对端客户端的数量超出预定数量(例如，可以根据本端客户端承受负荷的能力而设定，这里设定为2个，包括2个)时，如果客户端1与客户端2/3之间存在直连数据通道的情况，那么，通过信令服务器进行网络参数的交换，经由中转服务器建立中转数据通道，并通过中转数据通道传输多媒体数据。
从而，本端客户端与对端客户端之间的承载直连数据通道的相关链路能够得到释放，实现节约客户端资源的技术效果；当然，本端客户端与对端客户端之间的直连数据通道可以一致保持(或保持预定时间)，这样，当对端客户端退出所加入的房间而使得对端客户端的数量减少至低于预定数量时，本端客户端可以将与房间中剩余的对端客户端之间的多媒体数据的传输迅速切换到直连数据通道，最大程度减小数据传输延迟。
可以理解，当房间中对端客户端的数量低于数量，且本端客户端与对对端客户端切换(或建立)直连数据通道传输多媒体数据时，本端客户端与对端客户端之间已经建立的中转数据通道的链路承载可以立即释放以节省资源，当然，可以采用心跳机制进行保持，例如在会话的存活期间一直保持或保持预定时间，从而在必要时可以实现快速切换。
至此，已经对两个以及多个客户端之间进行多媒体通信的实现过程进行了说明，需要指出，虽然前述实施例以本端客户端与对端客户端之间进行音/视频通信为例进行说明，但是可以理解，本端客户端与对端客户端之间的数据通道同样适用于文本数据的传输，因此，本发明实施例上述记载的方案同样适用于不同客户端之间的文本消息的传输，例如微信客户端用户建立聊天的房间后，QQ客户端用户加入房间与微信客户端用户进行文本方式的聊天。
下面，再以微信客户端和QQ手机客户端进行音/视频通信为例进行说明，根据以下记载，本领域技术人员可以轻易实施其他的不同类型客户端之间的音/视频通信，当然，也可以实施相同类型客户端之间的音/视频通信。
1)跨客户端音/视频通信的架构
参见图7，图7是本发明实施例提供的QQ客户端(下文中也简称QQ)和微信客户端(下文中也简称为微信)之间音视/频通信的架构示意图，主要涉及：
1.1)信令服务器：主要负责客户端的登录鉴权，在登录鉴权通过时为客户端分配中转服务器，以及登录中转服务器的鉴权信息；支持微信与QQ协商以下信息：控制参数(如媒体参数、网络参数和会话控制参数)，数据通道的安全参数；房间管理，包括针对每个房间分配唯一的URL，当有客户端加入和退出房间时，通知房间中的其他客户端。
1.2)中转服务器：主要负责使用STUN穿越客户端配置的NAT设备，以尝试建立直连数据通道，建立失败时，建立客户端之间的中转的数据通道；在建立数据通道后，进行数据包传输层安全性协议(DTLS，Datagram Transport Layer Security)密钥的协商，安全实时传输协议(SRTP，Secure Real-time Transport Protocol)音/视频数据的中转传输、以及实时传输控制协议(RTCP，Real-time Control Protocol)音/视频质量控制。
1.3)X5内核：为浏览器内核，支持封装WebRTC实时通信组件。
参见图8，图8是本发明实施例提供的微信与QQ进行跨客户端音/视频通信的一个可选的流程示意图，涉及通过信令通道的协商、数据通道的建立及使用，分别进行说明。
QQ通过HTTP请求到信令服务器建立信令通道，进入房间、交换各种控制参数，之后通过中转服务器与微信建立直连或中转的加密数据通道；信令通道、数据通道的建立过程在后面详细叙述。
信令通道的协商建立
A、QQ手机客户端发送访问的房间(会话，每个房间对应一个会话)的URL的HTTP请求到房间服务器。
房间服务器对QQ手机客户端进行登录鉴权，例如验证发送的请求是否来自允许进行音/视频通信的客户端的类型，包括QQ手机客户端或微信客户端；登录验证通过后，将房间对应的会话页面的页面数据、JS文件(WebRTC组件173的JS实现)、分配的中转服务器的IP地址和端口以及鉴权信息下发QQ手机客户端，鉴权信息包括登录中转服务器的有效时间(time)，用于登录中转服务器的用户名(记为user)和密码(记为password)。
B、QQ手机客户端X5内核解释JS文件，实现以下操作：
1)建立本地流，即获取客户端的宿主终端本地的音/视频流；
2)创建点连接(PeerConnection)对象，调用Media Stream接口173建立QQ手机客户端的宿主终端本地的音/视频流，添加到PeerConnection对象中。
PeerConnection对象是Media Stream接口173中已经封装好的对象，每一个音视频会话都对应一个PeerConnection对象，QQ手机客户端X5内核通过这个PeerConnection对象进行音/视频的发起、传输、接收和结束操作。
3)建立本地的SDP对象，SDP对象包括控制参数，如网络参数(如QQ手机客户端的IP地址、端口)、媒体流参数(QQ手机客户端所支持的音/视频编解码器等)。
QQ手机客户端创建一个SDP对象，SDP对象中包括网络参数、媒体流参数、安全参数等各种控制参数，将该SDP对象保存，用于创建SDP信令。
C、QQ手机客户端请求中转服务器探测QQ手机客户端NAT设备/防火墙的广域网IP地址和端口，中转服务器根据鉴权信息对QQ手机客户端进行鉴权，探测QQ手机客户端的NAT设备/防火墙的广域网IP地址和端口，返回QQ手机客户端。
步骤C中，以QQ手机客户端和微信处于局域网为例，由于不具有广域网IP地址，无法建立直连的数据通道，需要尝试通过中转服务器探测的NAT设备/防火墙的广域网IP地址和端口进行NAT/防火墙穿透，建立QQ手机客户端与微信之间的直连数据通道，如果未能建立，则经由中转服务器建立中转的数据通道。
D、微信采用同样的方式加入房间，房间服务器通知QQ手机客户端有用户加入。
例如，微信用户通过扫描会话页面的二维码、或在微信直接输入房间的URL的方式，向中转服务器发送访问房间的HTTP请求，执行前述QQ手机客户端执行的步骤A、B和C，至此，微信获得NAT设备/防火墙的广域网IP地址和端口。
E、微信本地建立音/视频流、PeerConnection对象和数据通道等。
F、QQ手机客户端收到用户加入的通知后，发送请求SDP信令(携带Offer SDP对象)经信令服务器转给微信，微信对双方支持的能力选择，将选择结果封装到SDP对象中，携带在应答SDP信令中并通过信令服务器返回QQ手机客户端。
G、QQ将可用的直连、中转的数据通道的连接信息(包括IP地址和端口、中转服务器的地址)封装到Candidate信令，通过信令服务器发给微信，微信将选择结果封装到SDP对象中形成Candidate信令，并通过信令服务器返回QQ手机客户端。
例如，微信可以优先选用直连的数据通道，当直连的数据通道尝试不可用时，使用中转的数据通道。
参见图9，图9为以手机QQ与微信建立音/视频聊天为例建立中转数据通道的流程示意图，其他跨APP互通音视频聊天的数据通道建立过程相同。
A、QQ手机客户端通过标准的ICE协议建立中转数据通道。
首先发送的访问房间的请求未带用户名、密码等参数，中转服务器返回401鉴权失败信息，401鉴权失败信息中带回以下字段：域(realm)，即访问的房间是受保护的资源，需要提供用户名和密码、随机数(nonce)值；然后QQ手机客户端再次发送携带user、password、realm和nonce值来再次请求分配连接，此时中转服务器分配给QQ手机客户端与中转服务器的连接信息，即QQ手机客户端向中转服务器发送数据的目的IP地址和端口，也就是中转服务器的广域网IP地址和端口(中转服务器允许QQ手机客户端向中转服务器传入数据所使用的端口)。
B、微信侧执行以上相同的逻辑。
C、QQ通过前面分配传输数据的IP地址、端口发送创建(中转数据通道)请求到中转服务器，中转服务器返回许可，接下来发送探测数据包经中转服务器发到微信，微信回复探测数据包时，QQ向中转服务器发送绑定通道消息，(微信与QQ的IP地址和端口绑定到通道)，中转服务器将向手机QQ客户端分配的广域网IP地址和端口、为微信分配的广域网IP地址和端口、以及通道序列号绑定，返回绑定成功。
D、微信重复执行QQ侧逻辑。
E、数据包传输层安全性协议(DTLS，Datagram Transport Layer Security)握手协商。
第一步、QQ发送DTLS client hello包，带上DTLS版本，所支持的加密算法集列表等信息，经中转服务器转发给微信。
第二步、微信选定其中一个加密算法集发送给手机QQ客户端，每个加密算法集包括证书认证算法、密钥交换算法、用于SRTP数据传输的加密算法、消息验证算法，微信的数字证书、公钥及交换的对称密钥发送给手机QQ客户端。
第三步、手机QQ客户端使用证书认证算法验证数字证书后，发送手机QQ客户端的数字证书、公钥和交换的对称密钥到微信，并通知后续启用对称密钥的加密通道。
第四步、微信验证手机QQ客户端的证书后，回复会话凭证(Ticket)，并通知启用对称密钥加密的数据通道。
数据加密使用的对称密钥采用如下方式形成：微信生成一个随机数X，手机QQ客户端生成一个随机数Y；微信将X使用密钥交换算法加密后形成交换的对称密钥发送到手机QQ客户端，手机QQ客户端将对称密钥与Y相乘，再使用消息验证算法添加一段后缀，形成完整的密钥；手机QQ客户端将Y使用密钥交换算法加密后形成交换的对称密钥发送到微信，微信将对称密钥与X相乘，再使用消息验证算法添加一段后缀，形成完整的密钥，保证了微信与手机QQ客户端形成相同的对称密钥。
F、双方使用通过DTLS交换得到的对称密钥，加密使用SRTP传输的音/视频数据。
微信和QQ手机客户端使用协商的解码器解码音/视频数据，在会话页面中播放，从而实现跨客户端的音/视频通信。
需要指出，对于房间服务器来说，为了实现不同类型客户端之间的音/视频通信，鉴于不同客户端的用户标识差异较大难以识别的情况，对于每个发送请求的客户端可以分配全局唯一的ID，维护ID与客户端用户名(微信账户名、QQ账户名)的映射关系，并同步给中转服务器和信令服务器，使得用于实现多媒体通信的中转服务器和信令服务器使用ID即可区分不同客户端，保证后续信令/数据处理的效率。
基于图8和图9，参见图10，图10是本发明实施例提供的微信客户端与手机QQ客户端通信的一个可选的场景示意图，针对加入房间、参数交换和数据通道建立几个方面说明。
一、加入房间
微信用户希望与手机QQ客户端用户进行音/视频的聊天，微信用户向房间服务器申请房间的会话页面的地址，并将对应的二维码分享给手机QQ客户端用户，当然，手机QQ客户端可以访问房间服务器选择需要加入的房间。
一旦有手机QQ客户端访问微信用户的房间，微信用户就会接收到房间服务器的通知，包括加入房间的用户的名称、所使用的客户端(房间服务器根据加入房间的客户端提交的全局ID，可以迅速定位加入房间的客户端的类型和客户端的名称)，同样，当手机QQ客户端退出房间时微信用户也会接收到相应的通知。
二、参数交换
房间内的任意用户可以通过信令服务器发送会话控制参数，实现起音/视频的聊天的发起、暂停和退出的控制，此外，微信用户和手机QQ客户端可以在房间的会话页面内设置音/视频的相关参数，如音频的采样率、视频的分辨率等，并通过信令服务器进行交换/协商，选定音/视频聊天时所使用的相关参数。
在需要对音/视频的通信质量进行控制时，微信与手机QQ客户端还通过信令服务器协商QoS参数，例如微信通过信令服务器向手机QQ客户端发送候选的QoS参数，用于音/视频编码的质量、数据传输质量(如传输速度、丢包率等)控制在期望的水平。
三、直连数据通道的建立
微信用户和手机QQ用户通过信令服务器协商建立数据通道，例如为了减小延迟而约定优先建立直连数据通道，建立直连数据通道失败时经过TRUN服务器建立中转数据通道，对于建立直连数据通道，较为常见的情况是，微信和手机QQ客户端处于局域网/防火墙中，即不具有广域网IP地址，此时需要通过STUN服务器尝试建立直连数据通道。
微信和手机客户端向STUN服务器探测NAT设备/防火墙的广域网IP地址和端口，STUN服务器探测到微信的NAT设备/防火墙的广域网IP地址和端口为19.18.17.16:253，手机QQ客户端的广域网IP地址和端口为：122.144.155.166:254，微信和手机QQ客户端通过交换网络参数获知了上述IP地址和端口，微信向122.144.155.166:254发送UDP探测数据包，如果接收到来自19.18.17.16:253的UDP探测数据包，说明微信与客户端之间成功建立UDP链路承载的直连数据通道。
对于微信与手机QQ客户端之间的TCP链路，通过尝试进行三次握手建立，微信与手机QQ客户端之间首选建立UDP链路承载的直连数据通道，避免网络延迟和抖动等问题导致的通信中断而需要重新连接的情况。
四、中转数据通道的建立
微信和手机QQ客户端尝试建立直连数据通道失败时，向中转服务器请求分配连接，中转服务器对应为微信和手机QQ客户端对应分配：122.144.155.166:255，122.144.155.166:254；
微信向122.144.155.166:254发送UDP探测数据包，探测数据包被中转服务器转发到手机QQ客户端的NAT设备/防火墙，如果探测数据包穿透手机QQ客户端的NAT设备/防火墙到达手机QQ客户端，手机QQ客户端将向122.144.155.166:255探测数据包，同样，如果探测数据包穿透微信的NAT设备/防火墙，微信将向中转服务确认，中转服务器将122.144.155.166:255和122.144.155.166:254绑定，后续根据该绑定关系为微信和手机客户端转发数据。
五、加密传输
以对称算法加密在数据通道中传输的数据为例，微信和手机QQ客户端通过交换密钥材料，使用相同的算法对密钥材料进行处理，从而能够得到相同的会话密钥；由于密钥材料通过信令服务器可以随时进行交换，因此，微信和手机客户端可以通过定时更换会话密钥，避免会话密钥被截获破解的可能性。
综上所述，本发明实施例所产生的有益效果
第一、客户端通过内置浏览器内核而执行会话页面中的脚本，为建立数据通道交换控网络参数和媒体流参数，一方面，网络参数保证了数据通道能够建立；另一方面，媒体流参数使得多媒体数据的采集和播放不会超出通信双方能力限制，确保了多媒体通信的质量；
第二、客户端通过内置浏览器内核的方式，能够容易地实现不同类型客户端之间在会话页面内的多媒体通信，同时也兼容相同类型的客户端之间在会话页面内的多媒体通信。
第三、客户端之间优先尝试建立直连数据通道以最大程度减小传输延迟，在未能建立直连数据通道时通过中转服务器建立中转数据通道，确保客户端在任意网络状态中都能够建立数据通道传输数据，对不同网络环境具有广泛的适应性。
第四、数据通道采用加密算法加密传输，避免了传输的数据被截获破解的情况，有效保证了通信安全。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (15)

1.一种多媒体通信方法，其特征在于，包括：
通过本端客户端中集成的浏览器内核加载会话页面，并通过所述浏览器内核执行所述会话页面中的脚本而实现以下操作：
通过信令服务器与对端客户端交换控制参数，所述控制参数包括网络参数和媒体流参数；
通过所述网络参数包括的所述本端客户端、以及所述对端客户端的地址和端口，建立与所述对端客户端之间数据通道；
采集多媒体数据并通过所述数据通道传输至所述对端客户端，供所述对端客户端通过所述本端客户端的媒体流参数进行播放，以及，
通过所述数据通道接收所述对端客户端采集的多媒体数据，根据所述对端客户端的媒体流参数在所述会话页面进行播放。
2.如权利要求1所述的多媒体通信方法，其特征在于，所述通过信令服务器与对端客户端交换控制参数，包括：
获取所述本端客户端配置的控制参数：
将所述网络参数携带在信令消息中，通过所述信令服务器传输至所述对端客户端；
接收所述对端客户端通过所述信令服务器传输的信令消息，从所接收的信令消息中提取得到所述对端客户端配置的控制参数。
3.如权利要求1所述的多媒体通信方法，其特征在于，所述通过所述网络参数包括的所述本端客户端、以及所述对端客户端的地址和端口，建立与所述对端客户端之间的数据通道，包括：
当所述本端客户端与所述对端客户端均处于广域网时，
通过所述网络参数包括的所述本端客户端的广域网地址和端口、以及所述对端客户端的广域网地址和端口，建立所述本端客户端与所述对端客户端之间的直连的数据通道，且承载所述数据通道的链路使用预定协议。
4.如权利要求1所述的多媒体通信方法，其特征在于，所述通过所述网络参数包括的所述本端客户端、以及所述对端客户端的地址和端口，建立与所述对端客户端之间的数据通道，包括：
当所述本端客户端与所述对端客户端中的至少一个处于防火墙内或配置网络地址转换设备时，
通过所述本端客户端、所述对端客户端所对应配置的防火墙或网络地址转换设备的广域网地址和端口，对应对所述防火墙或网络地址转换设备进行穿透操作，形成所述本端客户端与所述对端客户端之间的直连的数据通道；
其中，所述直连的数据通道经由所述防火墙或网络地址转换设备、且承载所述数据通道的链路使用预定协议。
5.如权利要求4所述的多媒体通信方法，其特征在于，还包括：
采集多媒体数据并通过所述数据通道传输至所述对端客户端之前，探测所述数据通道；
当探测成功时，通知中转服务器记录所述数据通道的标识与所述本端客户端的地址和端口的绑定关系；
所述通过所述数据通道传输至所述对端客户端，包括：
通过所述数据通道向所述中转服务器发送所述本端客户端采集的多媒体数据，供所述中转服务器根据所述绑定关系，转发所述本端客户端采集的多媒体数据至所述对端客户端。
6.如权利要求4所述的多媒体通信方法，其特征在于，还包括：
所述网络信息包括所述本端客户端的广域网地址和端口；
通过信令服务器与对端客户端交换所述网络信息之前，向所述信令服务器请求用于登录中转服务器的鉴权信息；
接收所述信令服务器认证所述本端客户端成功时返回的鉴权信息；
通过所述鉴权信息登录所述中转服务器，获取所述中转服务器探测到的所述防火墙或网络地址转换设备的广域网地址和端口。
7.如权利要求4所述的多媒体通信方法，其特征在于，还包括：
当通过所述穿透操作建立直连的数据通道失败时，经由所述中转服务器建立与所述对端客户端之间的中转的数据通道；
其中，所述中转的数据通道包括：所述本端客户端与所述中转服务器之间的链路、以及所述中转服务器与所述对端客户端之间的链路。
8.如权利要求1所述的多媒体通信方法，其特征在于，还包括：
采集多媒体数据并通过所述数据通道传输至所述对端客户端之前，
通过所述数据通道与所述对端客户端进行加密协商操作，确定在所述数据通道中传输的多媒体数据的加密算法和会话密钥。
9.如权利要求8所述的多媒体通信方法，其特征在于，所述通过所述数据通道与所述对端客户端进行加密协商操作，确定在所述数据通道中传输的多媒体数据的加密算法和会话密钥，包括：
验证所述对端客户端的数字证书；
与所述对端客户端通过协商操作确定密钥交换算法，并与所述对端客户端交换密钥；
根据所述密钥交换算法对所述本端客户端、所述对端客户端生成的所述密钥加密，形成用于对所述多媒体数据进行加密的所述会话密钥。
10.如权利要求1所述的多媒体通信方法，其特征在于，还包括：
当加入所述会话页面的所述对端客户端的数量超出预定数量时，
经由所述中转服务器与所述对端客户端建立中转的数据通道，通过所述中转的数据通道与所述对端客户端传输多媒体数据。
11.如权利要求10所述的多媒体通信方法，其特征在于，还包括：
当所述本端客户端与所述对端客户端已经建立直连的数据通道时，释放所述本端客户端与所述对端客户端之间的直连的数据通道；
通过所述中转服务器与各所述对端服务器建立中转的数据通道。
12.如权利要求10所述的多媒体通信方法，其特征在于，还包括：
当加入所述会话页面的所述对端客户端的数量低于预定数量时，
与所述对端客户端建立直连的数据通道，通过所述直连的数据通道与所述对端客户端传输多媒体数据。
13.如权利要求12所述的多媒体通信方法，其特征在于，还包括：
当所述本端客户端与所述对端客户端已经建立中转的数据通道时，释放所述本端客户端与所述对端客户端之间的中转的数据通道。
14.一种多媒体通信装置，其特征在于，包括：
存储器，配置为存储可执行程序；
处理器，配置为通过执行所述存储器中存储的可执行程序时，实现权利要求1至13任一项所述的多媒体通信方法。
15.一种存储介质，其特征在于，存储有可执行程序，所述可执行程序被处理器执行时，实现权利要求1至13任一项所述的多媒体通信方法。
CN201710587065.4A 2017-07-18 2017-07-18 多媒体通信方法及装置、存储介质 Active CN109274634B (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN201710587065.4A CN109274634B (zh) 2017-07-18 2017-07-18 多媒体通信方法及装置、存储介质
PCT/CN2018/092017 WO2019015440A1 (zh) 2017-07-18 2018-06-20 多媒体通信方法及装置、存储介质
US16/547,376 US11108570B2 (en) 2017-07-18 2019-08-21 Method and apparatus for multimedia communication, and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710587065.4A CN109274634B (zh) 2017-07-18 2017-07-18 多媒体通信方法及装置、存储介质

Publications (2)

Publication Number Publication Date
CN109274634A true CN109274634A (zh) 2019-01-25
CN109274634B CN109274634B (zh) 2021-06-11

Family

ID=65016266

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710587065.4A Active CN109274634B (zh) 2017-07-18 2017-07-18 多媒体通信方法及装置、存储介质

Country Status (3)

Country Link
US (1) US11108570B2 (zh)
CN (1) CN109274634B (zh)
WO (1) WO2019015440A1 (zh)

Cited By (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110740300A (zh) * 2019-11-01 2020-01-31 普联技术有限公司 多媒体数据的传输方法、系统、客户端及视频监控设备
CN111062025A (zh) * 2019-12-09 2020-04-24 Oppo广东移动通信有限公司 应用数据处理方法及相关装置
CN111163363A (zh) * 2019-12-26 2020-05-15 武汉兴图新科电子股份有限公司 一种动态调整视频传输路由的方法
CN111356024A (zh) * 2020-03-11 2020-06-30 厦门亿合恒拓信息科技有限公司 网页端和微信小程序端的在线视频通信方法及存储介质
CN111491126A (zh) * 2020-04-10 2020-08-04 贵州新致普惠信息技术有限公司 提高多人联机视频语音稳定性的方法、系统以及设备
CN111629011A (zh) * 2020-07-28 2020-09-04 深圳诚一信科技有限公司 一种即时视频通信方法、设备、系统及可读存储介质
CN112073378A (zh) * 2020-08-12 2020-12-11 福建升腾资讯有限公司 一种基于WebRTC的流媒体端口复用方法、设备及介质
CN112153087A (zh) * 2019-06-27 2020-12-29 山东华软金盾软件股份有限公司 一种第三方网络终端跨Net通讯方法
CN112202882A (zh) * 2020-09-29 2021-01-08 联想(北京)有限公司 一种传输方法、客户端及传输系统
CN112565367A (zh) * 2020-11-27 2021-03-26 北京三维天地科技股份有限公司 一种基于对称算法的数据交换平台和数据交换方法
CN112671944A (zh) * 2020-12-18 2021-04-16 杭州叙简科技股份有限公司 一种基于webrtc和ice探测的音视频交互方法
CN112804213A (zh) * 2020-12-31 2021-05-14 Oppo广东移动通信有限公司 通信断线重连方法及装置、系统、可读介质和电子设备
CN113014544A (zh) * 2021-01-25 2021-06-22 阳光凯讯(北京)科技有限公司 基于webRtc无中心媒体链路建立方法及装置
CN113194550A (zh) * 2021-04-30 2021-07-30 深圳市道通科技股份有限公司 数据通道的构建方法、服务器及数据集群系统
CN113315823A (zh) * 2021-05-21 2021-08-27 广州赞赏信息科技有限公司 一种低延迟音视频传输方法
CN113347391A (zh) * 2021-05-31 2021-09-03 北京字跳网络技术有限公司 一种数据传输方法、数据传输中断方法及装置
WO2021197469A1 (zh) * 2020-04-03 2021-10-07 维沃移动通信有限公司 传输通道变更方法、接入网设备及核心网设备
WO2022028198A1 (zh) * 2020-08-07 2022-02-10 腾讯科技（深圳）有限公司 基于即时通讯的数据处理方法、装置、设备及介质
CN114124933A (zh) * 2021-11-09 2022-03-01 民商数字科技(深圳)有限公司 实现点对点网盘的方法
CN114390037A (zh) * 2022-01-12 2022-04-22 中国科学院软件研究所 一种终端访问家庭网络设备的方法及系统
CN114553839A (zh) * 2022-02-25 2022-05-27 阿里巴巴（中国）有限公司 Rtc数据的处理方法以及装置
CN114979098A (zh) * 2021-06-21 2022-08-30 中移互联网有限公司 一种基于WebRTC的通讯方法、装置及电子设备
WO2024032102A1 (zh) * 2022-08-09 2024-02-15 腾讯科技（深圳）有限公司 数据传输方法、装置、设备、存储介质和计算机程序产品

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10868802B2 (en) * 2015-07-15 2020-12-15 Telefonaktiebolaget Lm Ericsson (Publ) Enabling setting up a secure peer-to-peer connection
CN109274634B (zh) * 2017-07-18 2021-06-11 腾讯科技（深圳）有限公司 多媒体通信方法及装置、存储介质
CN110290140B (zh) * 2019-06-28 2021-09-24 腾讯科技（深圳）有限公司 多媒体数据处理方法及装置、存储介质、电子设备
CN111092904B (zh) * 2019-12-27 2022-04-26 杭州迪普科技股份有限公司 网络连接方法和装置
CN111314378B (zh) * 2020-03-18 2022-07-29 浩云科技股份有限公司 一种码流数据处理方法
CN112217862A (zh) * 2020-09-03 2021-01-12 视联动力信息技术股份有限公司 一种数据通信方法、装置、终端设备和存储介质
CN113312577B (zh) * 2021-06-01 2024-06-25 平安证券股份有限公司 网页资源处理方法、装置、电子设备和存储介质
CN115086284B (zh) * 2022-05-20 2024-06-14 阿里巴巴（中国）有限公司 云应用的流媒体数据传输方法
CN115884108A (zh) * 2022-11-29 2023-03-31 杭州雅赫网络科技有限公司 一种提高大数据传输稳定性的方法

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101291241A (zh) * 2008-06-23 2008-10-22 北京国际汉语学院 结合p2p传输方式以浏览器实现实时音视频会议的方法
CN103404132A (zh) * 2013-03-08 2013-11-20 华为终端有限公司 视频通信方法及家庭终端、家庭服务器
CN103580986A (zh) * 2012-07-30 2014-02-12 华为终端有限公司 一种实时通信方法、终端设备、实时通信服务器及系统
CN103650458A (zh) * 2013-08-16 2014-03-19 华为技术有限公司 媒体流的传输方法、装置与系统
CN103702062A (zh) * 2013-12-27 2014-04-02 Tcl集团股份有限公司 一种音视频通讯方法、装置及系统
EP2770667A1 (en) * 2013-02-22 2014-08-27 Telefonica Digital España, S.L.U. Method and system for combined Peer-to-Peer (P2P) and central relay server-based telecommunication conferencing using a telephony and conferencing protocol
CN104219257A (zh) * 2013-05-29 2014-12-17 华为终端有限公司 一种网页实时通信方法、系统及服务器和客户端
CN104780335A (zh) * 2015-03-26 2015-07-15 中兴通讯股份有限公司 一种WebRTC P2P音视频通话的方法及装置
CN105407176A (zh) * 2015-12-21 2016-03-16 Tcl集团股份有限公司 一种数据共享的方法、系统及服务器端
CN105869027A (zh) * 2016-06-28 2016-08-17 谢飞 基于互联网的商家与买家个性化平台
CN106657179A (zh) * 2015-10-28 2017-05-10 广东电网有限责任公司佛山供电局 文件传输方法和系统

Family Cites Families (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070050510A1 (en) * 2005-03-14 2007-03-01 Roamware, Inc. Session-based multimedia messaging service
US20040034622A1 (en) * 2002-08-13 2004-02-19 Espinoza Danny Javier Applications software and method for authoring and communicating multimedia content in a multimedia object communication and handling platform
KR100606016B1 (ko) * 2002-09-13 2006-07-26 삼성전자주식회사 이동 통신시스템에서 양방향 데이터 서비스 제공 방법
US9652758B2 (en) * 2002-10-01 2017-05-16 Dylan T X Zhou Systems and methods for messaging, calling, digital multimedia capture and payment transactions
US7089319B2 (en) * 2002-12-09 2006-08-08 Anton Lysenko Method and system for instantaneous on-demand delivery of multimedia content over a communication network with aid of content capturing component, delivery-on-demand client and dynamically mapped resource locator server
KR101095769B1 (ko) * 2004-02-09 2011-12-21 액세스 시스템즈 어메리카즈 인코포레이티드 컴퓨팅 디바이스에서의 보안 모델을 위한 방법 및 시스템
US20050235048A1 (en) * 2004-04-20 2005-10-20 Jose Costa-Requena Exchanging multimedia data via a communications device
US7957733B2 (en) * 2004-07-16 2011-06-07 Sellerbid, Inc. Method and apparatus for multimedia communications with different user terminals
US20070115933A1 (en) * 2005-11-22 2007-05-24 Sbc Knowledge Ventures Lp Method for maintaining continuity of a multimedia session between media devices
US20070177606A1 (en) * 2006-01-13 2007-08-02 Dilithium Networks Pty Ltd. Multimedia streaming and gaming architecture and services
US9021134B1 (en) * 2006-03-03 2015-04-28 Juniper Networks, Inc. Media stream transport conversion within an intermediate network device
CN101102185B (zh) * 2006-07-06 2012-03-21 朗迅科技公司 Ims会话的媒体安全
US8131311B2 (en) * 2007-03-26 2012-03-06 Bandemar Networks, Llc Just-in-time training of deployed skill support personnel via cell phone multimedia
US20090182999A1 (en) * 2008-01-16 2009-07-16 Scott Krig Method And System For Security Certificate Properties For Protocol Exchange
TWI393423B (zh) * 2008-05-21 2013-04-11 Mobile communication platform across heterogeneous platform for multimedia transmission system
IL195323A0 (en) * 2008-11-16 2011-08-01 Clip In Touch Internat Ltd A device, system and method for creating and transmitting multimedia messages
US10419266B2 (en) * 2010-05-28 2019-09-17 Ram Caspi Methods and apparatus for interactive social TV multimedia communication
US20150156814A1 (en) * 2010-07-27 2015-06-04 Humax Holdings Co., Ltd. Cross-layer optimization method in a multimedia transmission system
US8881180B1 (en) * 2011-11-17 2014-11-04 Jargon Technologies LLC Cross platform discovery and communication over a local network
WO2013119802A1 (en) * 2012-02-11 2013-08-15 Social Communications Company Routing virtual area based communications
CN102841792B (zh) * 2012-09-07 2016-02-17 腾讯科技（深圳）有限公司 Sns应用中的信息编辑方法及装置
US9118630B2 (en) * 2013-05-14 2015-08-25 Morega Systems Inc. Client proxy for key exchange in HTTP live streaming
CN104333727B (zh) * 2013-07-22 2019-04-12 腾讯科技（深圳）有限公司 音视频传输通道调控方法、装置和系统
CN103702238B (zh) * 2013-12-23 2017-11-28 华为终端有限公司 一种多屏视频共享方法及终端、服务器
US20150180857A1 (en) * 2013-12-23 2015-06-25 Joseph Schulman Simple user management service utilizing an access token
US9699237B2 (en) * 2015-03-30 2017-07-04 Oracle International Corporation Managed media relay selection for real-time communications
US10311251B2 (en) * 2015-03-30 2019-06-04 Adheraj Singh System and method for masking and communicating modified multimedia content
US10841268B2 (en) * 2015-08-04 2020-11-17 Vmware, Inc. Methods and apparatus to generate virtual war rooms via social media in enterprise network environments
CN105142011A (zh) * 2015-08-12 2015-12-09 青岛海信电器股份有限公司 一种基于web的电视终端多屏互动方法与装置
US20170078226A1 (en) * 2015-09-14 2017-03-16 At&T Intellectual Property I, L.P. Communication adaptation
US10250548B2 (en) * 2016-08-30 2019-04-02 Sap Se Social media engagement engine
CN109274634B (zh) * 2017-07-18 2021-06-11 腾讯科技（深圳）有限公司 多媒体通信方法及装置、存储介质

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101291241A (zh) * 2008-06-23 2008-10-22 北京国际汉语学院 结合p2p传输方式以浏览器实现实时音视频会议的方法
CN103580986A (zh) * 2012-07-30 2014-02-12 华为终端有限公司 一种实时通信方法、终端设备、实时通信服务器及系统
EP2770667A1 (en) * 2013-02-22 2014-08-27 Telefonica Digital España, S.L.U. Method and system for combined Peer-to-Peer (P2P) and central relay server-based telecommunication conferencing using a telephony and conferencing protocol
CN103404132A (zh) * 2013-03-08 2013-11-20 华为终端有限公司 视频通信方法及家庭终端、家庭服务器
CN104219257A (zh) * 2013-05-29 2014-12-17 华为终端有限公司 一种网页实时通信方法、系统及服务器和客户端
CN103650458A (zh) * 2013-08-16 2014-03-19 华为技术有限公司 媒体流的传输方法、装置与系统
CN103702062A (zh) * 2013-12-27 2014-04-02 Tcl集团股份有限公司 一种音视频通讯方法、装置及系统
CN104780335A (zh) * 2015-03-26 2015-07-15 中兴通讯股份有限公司 一种WebRTC P2P音视频通话的方法及装置
CN106657179A (zh) * 2015-10-28 2017-05-10 广东电网有限责任公司佛山供电局 文件传输方法和系统
CN105407176A (zh) * 2015-12-21 2016-03-16 Tcl集团股份有限公司 一种数据共享的方法、系统及服务器端
CN105869027A (zh) * 2016-06-28 2016-08-17 谢飞 基于互联网的商家与买家个性化平台

Cited By (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112153087A (zh) * 2019-06-27 2020-12-29 山东华软金盾软件股份有限公司 一种第三方网络终端跨Net通讯方法
CN112153087B (zh) * 2019-06-27 2022-06-24 山东华软金盾软件股份有限公司 一种第三方网络终端跨Net通讯方法
CN110740300A (zh) * 2019-11-01 2020-01-31 普联技术有限公司 多媒体数据的传输方法、系统、客户端及视频监控设备
CN111062025A (zh) * 2019-12-09 2020-04-24 Oppo广东移动通信有限公司 应用数据处理方法及相关装置
CN111163363A (zh) * 2019-12-26 2020-05-15 武汉兴图新科电子股份有限公司 一种动态调整视频传输路由的方法
CN111356024A (zh) * 2020-03-11 2020-06-30 厦门亿合恒拓信息科技有限公司 网页端和微信小程序端的在线视频通信方法及存储介质
CN111356024B (zh) * 2020-03-11 2022-02-01 厦门亿合恒拓信息科技有限公司 网页端和微信小程序端的在线视频通信方法及存储介质
WO2021197469A1 (zh) * 2020-04-03 2021-10-07 维沃移动通信有限公司 传输通道变更方法、接入网设备及核心网设备
CN111491126A (zh) * 2020-04-10 2020-08-04 贵州新致普惠信息技术有限公司 提高多人联机视频语音稳定性的方法、系统以及设备
CN111629011A (zh) * 2020-07-28 2020-09-04 深圳诚一信科技有限公司 一种即时视频通信方法、设备、系统及可读存储介质
WO2022028198A1 (zh) * 2020-08-07 2022-02-10 腾讯科技（深圳）有限公司 基于即时通讯的数据处理方法、装置、设备及介质
CN112073378A (zh) * 2020-08-12 2020-12-11 福建升腾资讯有限公司 一种基于WebRTC的流媒体端口复用方法、设备及介质
CN112073378B (zh) * 2020-08-12 2022-07-08 福建升腾资讯有限公司 一种基于WebRTC的流媒体端口复用方法、设备及介质
CN112202882A (zh) * 2020-09-29 2021-01-08 联想(北京)有限公司 一种传输方法、客户端及传输系统
CN112565367A (zh) * 2020-11-27 2021-03-26 北京三维天地科技股份有限公司 一种基于对称算法的数据交换平台和数据交换方法
CN112671944A (zh) * 2020-12-18 2021-04-16 杭州叙简科技股份有限公司 一种基于webrtc和ice探测的音视频交互方法
CN112804213A (zh) * 2020-12-31 2021-05-14 Oppo广东移动通信有限公司 通信断线重连方法及装置、系统、可读介质和电子设备
CN113014544B (zh) * 2021-01-25 2023-02-10 阳光凯讯(北京)科技有限公司 基于webRtc无中心媒体链路建立方法及装置
CN113014544A (zh) * 2021-01-25 2021-06-22 阳光凯讯(北京)科技有限公司 基于webRtc无中心媒体链路建立方法及装置
CN113194550A (zh) * 2021-04-30 2021-07-30 深圳市道通科技股份有限公司 数据通道的构建方法、服务器及数据集群系统
CN113194550B (zh) * 2021-04-30 2022-12-02 深圳市道通科技股份有限公司 数据通道的构建方法、服务器及数据集群系统
CN113315823A (zh) * 2021-05-21 2021-08-27 广州赞赏信息科技有限公司 一种低延迟音视频传输方法
CN113347391B (zh) * 2021-05-31 2022-12-06 北京字跳网络技术有限公司 一种数据传输方法、数据传输中断方法及装置
CN113347391A (zh) * 2021-05-31 2021-09-03 北京字跳网络技术有限公司 一种数据传输方法、数据传输中断方法及装置
CN114979098A (zh) * 2021-06-21 2022-08-30 中移互联网有限公司 一种基于WebRTC的通讯方法、装置及电子设备
CN114124933A (zh) * 2021-11-09 2022-03-01 民商数字科技(深圳)有限公司 实现点对点网盘的方法
CN114390037A (zh) * 2022-01-12 2022-04-22 中国科学院软件研究所 一种终端访问家庭网络设备的方法及系统
CN114553839A (zh) * 2022-02-25 2022-05-27 阿里巴巴（中国）有限公司 Rtc数据的处理方法以及装置
CN114553839B (zh) * 2022-02-25 2024-03-15 阿里巴巴（中国）有限公司 Rtc数据的处理方法以及装置
WO2024032102A1 (zh) * 2022-08-09 2024-02-15 腾讯科技（深圳）有限公司 数据传输方法、装置、设备、存储介质和计算机程序产品

Also Published As

Publication number Publication date
US11108570B2 (en) 2021-08-31
WO2019015440A1 (zh) 2019-01-24
CN109274634B (zh) 2021-06-11
US20190379735A1 (en) 2019-12-12

Similar Documents

Publication Publication Date Title
CN109274634A (zh) 多媒体通信方法及装置、存储介质
CN110301126B (zh) 会议服务器
Grigorik High Performance Browser Networking: What every web developer should know about networking and web performance
US9473581B2 (en) Integrated web-enabled session border controller
US9055139B1 (en) Display protocol interception in the network for services and network-based multimedia support for VDI
JP6359184B2 (ja) Ｒｔｃクライアントとｒｔｃサーバとの間のｒｔｃ通信コネクションを確立するときにアプリケーションレイヤ・ゲートウェイ・ファイアウォールをトラバースするための通信装置および方法
CN107277612A (zh) 用于在web浏览器上播放媒体流的方法和设备
US20140372517A1 (en) Systems and Methods for a Video Sharing Social Network
US11601519B2 (en) Edge communication locations
CN109309866B (zh) 图像处理方法及装置、存储介质
CN107077432A (zh) Https请求充实
US11412013B2 (en) System and method for implementing video soft phone applications
CN110741614B (zh) 数据通信系统和方法
Davids et al. SIP APIs for voice and video communications on the web
US8443057B1 (en) System, method, and/or apparatus for establishing peer-to-peer communication
Emmanuel et al. A peer-to-peer architecture for real-time communication using Webrtc
CN110266736A (zh) 一种针对基于https协议的portal认证的优化方法及装置
JP2010283762A (ja) 通信経路設定装置、通信経路設定方法、プログラム、及び記憶媒体
Shreya et al. Internetworking Gateway between WebRTC to SIP to Integrate Real-Time Audio Video Communication
Kullberg Implementing remote customer service api using webrtc and jitsi sdk
US12041145B2 (en) Edge communication locations
Tiamiyu On the design and implementation of peer–to peer communication using webrtc
Jadhav et al. Performance Evaluation of WebRTC for Peer-to-Peer Communication
Muranyi et al. Identity management in WebRTC domains
Sandholm et al. On-Demand WebRTC Tunneling in Restricted Networks

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant