CN111327580A - 一种报文传输方法及装置 - Google Patents
一种报文传输方法及装置 Download PDFInfo
- Publication number
- CN111327580A CN111327580A CN201811544660.0A CN201811544660A CN111327580A CN 111327580 A CN111327580 A CN 111327580A CN 201811544660 A CN201811544660 A CN 201811544660A CN 111327580 A CN111327580 A CN 111327580A
- Authority
- CN
- China
- Prior art keywords
- message
- decoding
- coding
- video
- audio
- 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.)
- Pending
Links
Images
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
-
- 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/06—Notations for structuring of protocol data, e.g. abstract syntax notation one [ASN.1]
-
- 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/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/56—Arrangements for connecting several subscribers to a common circuit, i.e. affording conference facilities
- H04M3/567—Multimedia conference systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/56—Arrangements for connecting several subscribers to a common circuit, i.e. affording conference facilities
- H04M3/568—Arrangements for connecting several subscribers to a common circuit, i.e. affording conference facilities audio processing specific to telephonic conferencing, e.g. spatial distribution, mixing of participants
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Telephonic Communication Services (AREA)
Abstract
本申请公开了一种报文传输方法及装置,用以解决现有技术中存在的多媒体会议技术占用IPCC处理资源较多的问题。本申请实施例多媒体控制设备获取到的第一网络设备的第一编解码参数,并接收到第二网络设备匹配第一编解码参数后发送的第一指示,该第一指示用于指示该第二网络设备采用该第一编解码参数进行编解码,由于第一网络设备和第二网络设备都采用第一编解码参数,所以在传输报文时,无需转码操作,直接复制该报文净荷,将报文头修改为接收方能够识别的报文头即可,从而能够减少占用处理资源,提高系统性能。
Description
技术领域
本申请涉及多媒体会议技术领域,特别涉及一种报文传输方法及装置。
背景技术
目前,多媒体会议技术通常基于互联网协议呼叫中心(internet protocol callcenter,IPCC)实现,IPCC利用IP传输网来传输会议过程中的语音、图像和文本等信息。
IPCC既支持音频业务,又支持视频业务,比如,IPCC音视频会议,用户需要办理业务或咨询问题时,用户呼叫运营商坐席,用户可以和运营商坐席进行语音通话,也可以和运营商坐席进行视频通话,如果运营商坐席解决不了用户的问题,则运营商坐席会邀请运营商专家坐席和用户以及运营商坐席进行语音通话或进行视频通话。
现有的IPCC音视频会议系统,对会议发送方发送的音视频流进行传输,使会议接收方能够听到发送方的声音以及看到发送方的视频。音视频流的传输的过程为:发送方将音频数据或视频数据封装到报文中发送给IPCC,IPCC对报文进行解析,解析出净荷,再对净荷做解码处理,将解码后的音频信号做音频混音处理或将解码后的视频信号做视频多画面处理,然后对处理后的音频信号或视频信号进行编码压缩,编码压缩成接收方能够识别的格式,最后将编码后的音频信号或视频信号封装到报文中发送给接收方。
由于收发双方支持的音视频流的格式不同,因此IPCC需要对接收到的报文做解码处理后,再将解码后的音频信号或视频信号做编码处理。而编解码的流程比较复杂,并且IPCC音视频会议的特点是实时且高并发量,因此目前的多媒体会议技术会占用IPCC较多的处理资源。
发明内容
本申请提供一种报文传输方法及装置,用以解决现有技术中存在的多媒体会议技术占用IPCC处理资源较多的问题。
第一方面,本申请实施例提供的一种报文传输方法,该方法包括:
多媒体会议控制设备获取第一网络设备的第一编解码参数,所述第一编解码参数用于指示所述第一网络设备的编解码能力;所述多媒体会议控制设备将所述第一编解码参数发送给第二网络设备;所述多媒体会议控制设备接收到所述第二网络设备匹配所述第一编解码参数后发送的第一指示,所述第一指示用于指示所述第二网络设备采用所述第一编解码参数进行编解码;所述多媒体会议控制设备接收来自发送方的第一报文,向接收方发送第二报文;其中,所述第一报文包括第一报文头和第一净荷,所述第二报文包括第二报文头和第二净荷,所述第二报文头由第一报文头转换得到,第二净荷由复制第一净荷得到;所述发送方为所述第一网络设备时,所述接收方为所述第二网络设备,或者所述发送方为所述第二网络设备时,所述接收方为所述第一网络设备。
在上述方法中,多媒体控制设备获取到的第一网络设备的第一编解码参数,并接收到第二网络设备匹配第一编解码参数后发送的第一指示,该第一指示用于指示该第二网络设备采用该第一编解码参数进行编解码,由于第一网络设备和第二网络设备都采用第一编解码参数,所以在传输报文时,无需转码操作,直接复制该报文净荷,将报文头修改为接收方能够识别的报文头即可,从而能够减少占用处理资源,提高系统性能。
在一个可能的设计中,所述多媒体会议控制设备向接收方发送第二报文后,还包括:
所述多媒体会议控制设备接收到所述第二网络设备发送的第二指示,所述第二指示用于指示所述第二网络设备由采用所述第一编解码参数进行编解码切换为采用第二编解码参数进行编解码;所述多媒体会议控制设备接收来自发送方的第三报文,并根据所述第一编解码参数对所述第三报文进行解码处理,并根据所述第二编解码参数对解码处理后的数据进行编码处理,得到第四报文;所述多媒体会议控制设备向所述接收方发送所述第四报文。
在上述方法中,当第一网络设备采用第一编解码参数,第二网络设备由采用第一编解码参数进行编解码切换为采用第二编解码参数进行编解码时,多媒体会议控制设备接收发送方的第三报文后,根据第一编解码参数对第三报文进行解码处理,并根据第二编解码参数对解码处理后的数据进行编码处理,得到第四报文,再将第四报文发送给接收方,从而能够实现在报文传输时,从无需转码操作切换到转码操作的过程,使用更灵活。
在一个可能的设计中,所述多媒体会议控制设备接收来自发送方的第一报文,具体可以为所述多媒体会议控制设备接收来自发送方的视频流,所述视频流包括连续多个所述第一报文;然后所述多媒体会议控制设备还可以进而对连续多个所述第一报文中包括的第一净荷进行拼接处理,将拼接后的净荷存储。
在上述方法中,对视频进行存储时,首先对接收到的连续多个报文中包含的净荷以视频帧为单位进行拼接处理,然后将拼接后的净荷进行存储,不修改视频的分辨率等信息,从而在存储视频之前无需转码,能够节省资源。
在一个可能的设计中,所述第一报文可以为音频报文或也可以为视频报文。当所述第一报文为音频报文时,所述第一编解码参数可以但不限于包括报文时长、对齐模式、采样率或速率集中的至少一项信息;或者当所述第一报文为视频报文时,所述第一编解码参数包括但不限于为帧率和/或分辨率等信息。
第二方面,本申请还提供了一种报文传输装置,该装置具有实现上述第一方面涉及的功能。所述功能可以通过硬件实现,也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。
在一个可能的设计中,所述装置的结构中可以包括通信单元和处理单元,还可以包括存储单元等,这些单元可以执行上述第一方面示例中的相应功能。
第三方面,本申请还提供一种多媒体会议控制设备,该设备的结构中可以包括处理器、存储器和通信接口,所述处理器和存储器耦合,所述存储器用于存储计算机程序;所述处理器被配置为执行所述存储器中存储的计算机程序,通过所述通信接口以完成上述第一方面中的相应功能。
第四方面,本申请还提供了一种计算机存储介质,所述计算机存储介质中存储有计算机可执行指令和程序,所述计算机可执行指令和程序在被所述计算机调用时用于使所述计算机执行上述第一方面中任一可能的设计中所提及的方法。
第五方面,本申请还提供了一种包含指令的计算机程序产品,当其在装置上运行时,使得所述装置可以执行上述第一方面中任一可能的设计中所提及的方法。
第六方面,本申请还提供了一种装置,所述装置可以为芯片,所述芯片与存储器相连,用于读取并执行所述存储器中存储的程序指令,以实现上述第一方面中任一可能的设计中所提及的方法。
附图说明
图1为现有技术中IPCC系统架构图;
图2为现有技术中用户接入IPCC的流程示意图;
图3为现有技术中音频报文传输方法的流程示意图;
图4为现有技术中视频报文传输方法的流程示意图;
图5为本申请实施例提供的一种报文传输方法流程示意图;
图6为本申请实施例提供的两方会议用户和坐席接入IPCC的流程示意图;
图7为本申请实施例提供的两方会议时报文传输的方法流程示意图;
图8为本申请实施例提供的三方会议专家坐席接入IPCC的流程示意图;
图9为本申请实施例提供的三方会议报文传输的方法流程示意图;
图10为本申请实施例提供的文件存储的流程示意图;
图11为本申请实施例提供的第一种装置结构示意图;
图12为本申请实施例提供的第二种装置结构示意图。
具体实施方式
下面将结合附图对本申请实施例作进一步地详细描述。
本申请实施例提供一种报文传输方法及装置,用以解决现有技术中存在的多媒体会议技术占用IPCC较多的资源的问题。其中,方法和装置是基于同一发明构思的,由于方法及装置解决问题的原理相似,因此装置与方法的实施可以相互参见,重复之处不再赘述。
以下,对本申请中的部分用于进行解释说明,以便于本领域技术人员理解。
1)、编解码参数,指网络设备对报文进行解码和编码时使用的参数,例如,编解码参数中的报文时长为20ms,则网络设备对报文进行解码后得到的报文间隔为20ms,即该报文中封装了20ms的音视频净荷。
2)、对齐模式,是针对音频报文的,如字节对齐或带宽节省,使用不同的对齐模式,音频报文中的净荷会有差异。
3)、采样率,也是针对音频报文的,即采样频率,定义了每秒从连续信号中提取并组成离散信号的采样个数,用赫兹(Hz)来表示,通俗的讲采样频率是指计算机每秒钟采集的音频样本个数,是描述音频文件的音质、音调、衡量声卡、声音文件的质量标准,每秒钟采集的音频样本个数越多,提取出来的音频越真实。
4)、速率集,是针对变速率音频的编解码参数,指当前支持的速率模式集合,速率是每秒钟传输的音频净荷字节数。
另外,需要说明的是,本申请中,“至少一个”是指一个或者多个,“多个”是指两个或两个以上。“和/或”,描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B的情况,其中A,B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达,是指的这些项中的任意组合,包括单项(个)或复数项(个)的任意组合。例如,a,b,或c中的至少一项(个),可以表示后续任意一种情况:a,b,c,a和b,a和c,b和c,a和b和c。
音视频会议系统,是为用户和坐席之间进行音频通话或视频通话时提供媒介的系统,当用户通过用户设备呼叫坐席的坐席设备成功后,用户和坐席之间可以进行音频通话或视频通话。下面对音视频会议系统架构做简单介绍。
需要说明的是,用户设备(user equipment,UE)或坐席设备,又可以称之为终端、终端设备、移动台(mobile station,MS)、移动终端(mobile terminal,MT)等,是一种向用户提供语音和/或数据连通性的设备,例如,具有无线连接功能的手持式设备、车载设备等。目前,一些终端的举例为:手机(mobile phone)、平板电脑、笔记本电脑、掌上电脑、移动互联网设备(mobile internet device,MID)等。
参见图1所示,示例性的示出了音视频会议系统架构示意图。音视频会议系统包括IP多媒体子系统(IP multimedia subsystem,IMS)和互联网协议呼叫中心(internetprotocol call center,IPCC)、以及用户通信采用的用户设备和坐席通信采用的坐席设备。如图1中,用户设备VoLTE用户通过LTE网络接入IMS,IMS中包括演进的分组核心(evolved packet core,EPC)网络和IMS核心网(Core)两部分,其中EPC中包括服务/分组数据网关(serving/packet data network gateway,S/P-GW),IMS Core中包括会话边界控制器(session border controller,SBC)/代理呼叫服务控制功能(proxy-call servercontrol function,P-CSCF)和I/S-CSCF(即服务呼叫服务控制功能(serving-call servercontrol function,S-CSCF)和查询呼叫服务控制功能(interrogating-call servercontrol function,I-CSCF))。然后由IMS将VoLTE用户的呼叫接续到IPCC中,IPCC包括会议控制系统和会议资源、文件存储器(File Storage),进而再由IPCC将VoLTE用户的呼叫通过全会话边界控制器(all-session border controller,A-SBC)接续到坐席,最后实现VoLTE用户与坐席的音视或视频通信。下面对音视频会议系统架构中的关键网元做简单介绍。
S-CSCF:是IMS Core的中心节点,主要用于用户的注册、鉴权控制、会话路由和业务触发控制,并维持会话状态信息;
I-CSCF:是IMS网络的统一初步入口点,负责用户注册的S-CSCF的指配和查询;
P-CSCF:是会话启动协议(Session Initiation Protocol,SIP)用户接入IMS网络的入口节点,主要负责信令和消息的代理;
SBC:提供安全接入和媒体处理;
S/P-GW:是EPC网络的核心设备,提供了服务网关和分组数据网(packet datanetwork,PDN)网关逻辑实体的功能;
A-SBC:用于将坐席非信任网络区和运营商信任网络区进行隔离;
会议控制系统:是用户和坐席呼叫的信令处理和会议逻辑控制,IPCC业务中由计算机电话系统集成(Computer Telephony Integration,CTI)和媒体网关控制器(mediagateway controller,MGC)完成;
会议资源:提供会议媒体资源,对媒体流做转码(即编解码)、混音等处理;
file storage:用于存储录音文件。
用户和坐席之间进行音频通话或视频通话时,用户设备和坐席设备需要都接入到IPCC,下面以呼叫者为用户,对用户设备和坐席设备接入到IPCC的具体步骤进行说明。
用户和坐席进行音频通话或视频通话之前,用户设备需要先接入到音视频会议系统的会议控制系统,然后由会议控制系统控制会议资源为用户设备和坐席设备分配资源,资源分配成功以后,用户可以和坐席之间进行音频通话或视频通话,下面基于图1的音视频会议系统架构,对目前的用户和坐席接入到音视频会议系统的过程做简单介绍,请参照图2,具体步骤包括:
步骤200,用户设备通过IMS的CSCF向IPCC的会议控制系统中的用户侧模块发送接入请求;
需要说明的是,IPCC按照功能可以进一步划分为会议控制系统和会议资源,其中会议控制系统可以包括用户侧模块和坐席侧模块,会议资源可以包括用户通道模块、媒体会议模块和坐席通道模块。
步骤201,用户侧模块接收到用户设备发送的请求后,向用户设备返回针对该接入请求的振铃和应答;
步骤202,用户侧模块和用户设备进行SIP会话描述协议(session descriptionprotocol,SDP)协商,确认用户设备传输报文时使用的第一编解码参数;
步骤203,用户设备接收到振铃和应答后,用户设备和用户侧模块进行交互式语音应答(interactive voice response,IVR)模式;
步骤204,用户设备向用户侧模块发送转人工坐席的消息;
步骤205,用户侧模块向会坐席侧模块发送转人工坐席的消息;
步骤206,坐席侧模块向坐席发送邀请坐席接入会议控制系统的请求;
步骤207,坐席设备向坐席侧模块返回针对邀请坐席接入会议控制系统的请求的振铃和应答;
步骤208,坐席侧模块和坐席设备进行SIP SDP协商,确认坐席设备传输报文时使用的第二编解码参数;
步骤209,坐席侧模块向媒体会议模块发送申请媒体会议资源的请求;
步骤210,坐席侧模块建立坐席设备和坐席通道模块之间的连接,建立用户设备和用户通道模块之间的连接;
步骤211,坐席侧模块向用户通道模块发送坐席通道模块对应的信息,以使用户通道模块将接收到的信息发送给对应的坐席通道模块;
示例性地,会议资源中可以包括多个坐席通道模块,用户通道模块向坐席通道模块发送报文时,需要向与坐席设备建立连接的坐席通道模块发送报文,所以在传输报文之前,用户通道模块可以先确定要向哪个坐席通道模块发送报文。
步骤212,坐席侧模块向坐席通道模块发送用户通道模块对应的信息,以使坐席通道模块将接收到的报文发送给对应的用户通道模块。
和步骤210同理,在传输报文之前,用户通道模块需要确认要向哪个坐席通道模块发送报文,坐席通道模块也要确认需要向哪个用户通道模块发送报文。
以上为在用户设备和坐席设备传输报文之前,用户设备和坐席设备接入会议控制系统的过程,下面介绍现有用户设备和坐席设备进行报文传输的过程,由于传输音频报文和视频报文的过程不同,因此以下分别对音频报文的传输和视频报文的传输进行介绍。
这里需要说明的是,目前音频进行编解码时采用的算法主要有G711A和AMR-wb,视频进行编解码时采用的算法主要为H264,本申请音频的编解码算法以G711A为例,视频的编解码算法以H264为例进行说明。以上只是对音频和视频进行编解码时采用的算法进行举例,当然还可以采用其它算法进行编码和解码,具体实施时采用何种算法进行编解码本申请不做限定。
下面先介绍音频报文的传输,基于图1的音视频会议系统架构,参阅图3,传输音频报文的具体过程如下,图3中的实施例以用户设备向坐席设备传输音频报文为例,编解码时采用的算法为G711A:
步骤300,用户设备将第一音频报文发送给用户通道模块;
步骤301,用户通道模块对接收到的第一音频报文进行解析,得到第一音频净荷和第一音频报文头;
步骤302,用户通道模块中的解码器根据第一编解码参数对音频净荷进行解码处理,得到PCM 16bit X 8K的原始音频信号;
需要说明的是,解码后得到的原始音频信号格式为PCM 16bit X 8K,当前原始音频信号格式一般都为PCM 16bit X 8K,当然,也可以不为PCM 16bit X 8K,这里只是举例说明,原始音频信号的格式本申请不做限制。
步骤303,用户通道模块向媒体会议模块发送原始音频信号;
步骤304,媒体会议模块对多个原始音频信号进行叠加处理,得到叠加后的原始音频信号;
这里对解码后的原始信号进行叠加的目的是在同一时刻,媒体会议模块有可能会接收到多个音频报文,比如用户的音频报文,坐席的音频报文,背景音乐等,这时,媒体会议模块可以对接收到的所有音频报文对应的原始音频信号进行叠加处理。
步骤305,媒体会议模块将叠加后的原始音频信号去本通道音频信号;
对原始音频信号进行叠加后,叠加后的音频信号中包含了用户的声音,坐席的声音,背景音乐等,由于坐席不需要听自己的声音,所以媒体会议模块向坐席通道模块发送的音频信号中不包含坐席的声音,可以通过去坐席通道音频信号的方式将坐席的声音去除。
步骤306,媒体会议模块将去除坐席通道的音频信号发送给坐席通道模块;
步骤307,坐席通道模块中的编码器将去本通道音频信号后的音频信号根据第二编解码参数进行编码;
步骤308,坐席通道模块根据上文步骤208中SDP协商的结果生成第二音频报文头;
步骤309,坐席通道模块将编码后的音频信号和第二音频报文头封装到RTP报文中,得到第二音频报文;
步骤310,坐席通道模块将第二音频报文发送给坐席设备,以使坐席通过坐席设备可以听到用户的声音。
在用户和坐席进行语音通话的过程中,还可以对两方(用户设备和坐席设备)的语音信息进行存储,存储时参考图3中的步骤304,媒体会议模块将叠加处理后的原始音频信号进行编码,将编码后的音频信号发送给音频缓存模块,文件缓存模块从音频缓存模块中读取音频数据,然后将读取到的音频数据存储到文件缓存器中,如果音频数据和视频数据同时存储到文件存储中,为了使音频和视频能够对应上,文件缓存可以读取音频数据和视频数据后,解析音频数据和视频数据并交叉保存后,按照固定格式来封装内容,比如3GP格式或MP4格式,文件缓存模块再将封装后的内容写入到文件存储器中。
音频报文由坐席传给用户的过程以及存储的过程和上述图3中的过程一样,这里不做赘述。
音频报文由坐席设备传给用户设备的过程和图3的过程是一样的,这里不做赘述。
综上可见对音频报文进行传输时,会议资源中的相应模块需要对音频报文进行解码和编码(解码和编码统称为转码),转码会占用IPCC中较多的资源。
下面对现有视频报文的传输进行介绍,基于图1的音视频会议系统架构,参阅图4,传输视频报文的具体过程如下,对视频报文的传输以用户设备向坐席设备传输视频报文为例,视频编解码时使用的算法为H264:
步骤400,用户设备将第一视频报文发送给用户通道模块;
步骤401,用户通道模块将连续接收到的第一视频报文进行解析,得到多个第一视频净荷和第一视频报文头;
步骤402,用户通道模块将接收到的多个第一净荷按接收的时间顺序,拼接成一个网络抽象单元(network abstract layer unit,NALU);
NALU为采用H264算法进行编解码时解码输入和编码输出的单位,一个视频帧可以使用一个NALU,单个视频帧拆分成多个切片(slice)后,每个slice可以使用一个NALU,本申请中以一个视频帧使用一个NALU为例进行介绍。
一个视频帧指的是一个完整的画面,由于一个视频帧内容较大,所以一个NALU的内容也较大,在发送报文时可以将NALU分成多个视频报文进行发送。
步骤403,用户通道模块中的解码器根据第一编解码参数对NALU进行解码处理,得到YUV原始视频信号;
这里需要说明的是,解码后得到的原始视频信号格式为YUV,当前原始视频信号格式一般为YUV,当然,也可以不为YUV,这里只是举例说明,原始视频信号的格式本申请不做限制。
步骤404,用户通道模块向会议资源模块发送YUV原始视频信号;
步骤405,会议资源模块对多个原始视频信号进行叠加处理,得到叠加后的原始视频信号;
步骤406,会议资源模块将叠加后的原始视频信号发送给坐席通道模块;
步骤407,坐席通道模块中的编码器将叠加后的原始视频信号根据第二编解码参数进行编码;
步骤408,坐席通道模块将编码后的视频信号进行拆分,得到多个第二视频净荷;
步骤409,坐席通道模块将根据上文步骤208中SDP协商的结果生成第二视频报文头;
步骤410,坐席通道模块将步骤408中的第二视频净荷和步骤409中的第二视频报文头封装到RTP报文中,得到第二视频报文;
步骤411,坐席通道模块将第二视频报文发送给坐席设备,以使坐席能够通过坐席设备看到用户的视频内容。
在用户和坐席进行视频的过程中,还可以对一方(用户设备或坐席设备)的视频画面进行存储,存储时参考图4中的步骤408,用户通道模块将叠加后的原始视频信号发送给视频缓存模块,文件缓存模块从视频缓存模块中读取视频数据,然后将读取的视频数据存储到文件缓存中,如果音频数据和视频数据同时存储到文件存储器中,为了使音频和视频能够对应上,文件缓存器可以读取音频数据和视频数据后,解析音频数据和视频数据并交叉保存后,按照固定格式来封装内容,比如3GP格式或MP4格式,文件缓存模块将封装后的内容再写入到文件存储器中。
视频报文由坐席传给用户的过程以及存储的过程和上述图4中的过程一样,这里不做赘述。
综上也可见对视频报文进行传输时,需要对视频报文进行转码,由于IPCC存在高并发性,转码也会占用IPCC较多的处理资源。
为了缓解目前在音视频通信时,由于会议资源需要进行转码操作,可能会占用IPCC较多处理资源的问题,基于图1所示的音视频会议系统架构图,本申请实施例提供了一种报文传输方法,参阅图5所示,本申请实施例提供的一种报文传输方法的具体流程,包括:
步骤500,多媒体会议控制设备获取第一网络设备的第一编解码参数,该第一编解码参数用于指示该第一网络设备的编解码能力。
示例性地,多媒体会议控制设备(可以为IPCC中的会议控制系统,或者为配置于IPCC的一个或者多个处理器、或者为IPCC中的一个芯片或者芯片系统等)。第一网络设备可以为图1中的用户设备(图1中示意出的是VoLTE用户)或坐席设备(图1中示意出的是坐席),如果第一网络设备为用户设备,图5所示的报文传输方法可以适用于用户设备呼叫坐席设备产生的报文传输,如果第一网络设备为坐席设备,图5所示的报文传输方法可以适用于坐席设备外呼用户设备产生的报文传输。
步骤501,所述多媒体会议控制设备将所述第一编解码参数发送给第二网络设备。
这里的第二网络设备,如果第一网络设备为图1中的用户设备,那么第二网络设备则可以为图1中的坐席设备,如果第一网络设备为图1中的坐席设备,那么第二网络设备则为图1中的用户设备。
一种示例中,当第二网络设备接收到第一编解码参数后,匹配第一编解码参数生成第一指示,第一指示用于指示第二网络设备当前也采用第一编解码参数进行编解码。
另一种示例中,第二网络设备还可以匹配第一编解码参数后生成第二指示,第二指示用于指示第二网络设备当前采用区别于第一编解码参数的其它编解码参数(比如第二编解码参数)进行编解码。
如果第二网络设备采用区别于第一编解码参数的其它编解码参数进行编解码,则第一网络设备和第二网络设备在进行音视频报文传输时,则所述多媒体会议控制设备需要对第一网络设备和第二网络设备之间传输的音视频报文进行转码处理,即可以采用现有技术中的音视频报文传输方式进行后续处理。
步骤502,所述多媒体会议控制设备接收到所述第二网络设备匹配所述第一编解码参数后发送的第一指示,所述第一指示用于指示所述第二网络设备当前也采用第一编解码参数进行编解码。
步骤503,所述多媒体会议控制设备接收来自发送方的第一报文,向接收方发送第二报文。具体地,第一报文包括第一报文头和第一净荷,第二报文包括第二报文头和第二净荷;第二报文头为由第一报文头转换得到的,第二净荷为由复制第一净荷得到的;
如上所述,当发送方为第一网络设备时,则接收方就为第二网络设备,或者当发送方为第二网络设备时,接收方就为第一网络设备。一种示例说明,比如发送方为图1中的VoLTE用户时,则接收方就为图1中的坐席,相反发送方为图1中的坐席时,则接收方就为图中的VoLTE用户。也就是说,这里的发送方和接收方是相对的,如图1所示的系统中,任何一个发送报文的设备既可以是发送方也可以是接收方。
在一种可选的实施方式中,第一报文可以为音频报文,也可以为视频报文,当然,第二报文也一样,可以为音频报文,也可以为视频报文。如果第一报文为音频报文,则第一编解码参数可以但不限于包括报文打包时长、对齐模式、采样率或速率集中的至少一项;如果第一报文为视频报文,则第一编解码参数可以但不限于为帧率和/或分辨率等。
编解码参数可以根据进行编解码时采用的算法进行选择,比如,对于音频报文,在IPCC中常用的编解码算法为G711A和AMR-wb,如果编解码算法为G711A,那么编解码参数可以为报文打包时长,如果编解码算法为AMR-wb,那么编解码参数可以为对齐模式、采样率和速率集中的一项或者多项;对于视频报文,在IPCC中常用的编解码算法为H264,编解码参数可以为分辨率和/或帧率。
如果第一网络设备和第二网络设备之间传输的是音频报文,则接收方可以听到发送方的声音,如果传输的是视频报文,接收方可以看到发送方的视频画面,如果音频报文和视频报文同时传输,则接收方既能听到发送方的声音,又能看到发送方的视频画面。
示例性的,本申请实施例以RTP报文为例来说明,RTP报文包括报文头和净荷,下面对本申请实施例中的报文头和净荷进行说明。下面以H264为例,对视频报文格式进行简单介绍,示例性地,RTP报文头中包含RTP报文中的净荷信息,报文头中包括的参数以及各参数含义如下:
1)M:标记marker,对于不同的净荷M有不同的含义,对于视频,M用于标记一帧的结束;
2)PT值:净荷类型(payload type),表示报文净荷的类型,在SDP协商时确定,用于标示编解码类型,比如静止图像压缩(joint photographic experts group,JPEM)图像;
3)sequence number:序列号,用于表示发送端发送的RTP报文的序列号,每发送一个报文,序列号加1;接收端通过序列号来检测报文丢失情况,接收端可以根据序列号重新排序报文,恢复数据;
4)Timestamp:时戳,标识视频报文的第一个采样点的采样时间,接收端使用时戳来计算延迟和延迟抖动,并进行同步控制;
5)SSRC:同步信源,用于唯一标示一路报文。
H264中位于净荷前的8个字节定义的参数以及各参数的含义如下:
1)F:表示净荷中的数据正确与否,通常0表示数据正确,1表示数据错误。
2)NRI:表示报文优先级,比如00表示NALU不用于重建参考报文。
3)Type:packet type,报文类型,指示NALU传输的内容格式。
本申请实施例的核心思想为,当第一网络设备和第二网络设备的编解码参数一致时,则多媒体会议控制设备在报文传输过程中可以直接进行净荷复制,修改报文头,然后将复制的净荷和修改后的报文头组成新的报文发送给接收方,避免对净荷进行解码再编码的转码处理。
示例性地,在对报文头的修改,可以修改报文头中的以下参数:
1)PT值:在SIP SDP协商时确定,需修改为本通道协商的编解码对应的PT值;
3)sequence number:初始为随机值,按照RTP报文累加即可;
4)Timestamp:时戳是采样点的时间,一帧音频或视频中包含多个采样点,多个采样点可以使用相同的时戳值;
5)SSRC:RTP报文的唯一标识,修改为本通道生成的随机值。
对于时戳的计算方法有很多种,本申请实施例提供一个示例:
当前时戳=初始时戳+帧序号*(采样率/帧率),在音频中,帧率是每秒的打包数,如G711A报文打包时长是20ms,每秒打包50个报文,帧率等于50。
在净荷复制时,需计算时戳,假设将通道A的净荷复制到通道B发送,时戳基于采样率和帧率计算:通道B当前报文时戳=通道B初始时戳+帧序号*(采样率/帧率)。
这里需要说明的是,对于音频流,一个音频报文为一帧,在计算报文当前时戳时,一个音频报文可以对应一个帧序号;而视频存在多个视频报文属于同一帧的情况,为了使同一帧中的多个视频报文的帧序号不同,则可以对视频流中视频报文进行解析,获取当前视频报文的报文头中的时间戳,根据获取到的时间戳计算视频报文的帧序号,再根据计算得到的帧序号计算该视频报文的时间戳;
示例性地,采样率可以在SDP协商时被指定,如H264可以为90000HZ,G711A可以为8000HZ。
音频的帧率按照报文打包时长计算,报文打包时长也可以在SDP协商时指定,视频的帧率可以在SDP协商时指定。
在一种可选的实施方式中,多媒体会议控制设备向接收方发送第二报文后,如果需要由采用第一编解码参数切换为采用第二编解码参数,则第二网络设备还可以向多媒体会议控制设备发送第二指示,该第二指示用于指示第二网络设备由采用第一编解码参数切换为采用第二编解码参数进行编解码,后续多媒体会议控制设备接收到发送方发送的第三报文时,则需要根据第一编解码参数对第三报文先进行解码处理,再根据第二编解码参数对解码处理后的信号或数据进行编码处理,从而生成第四报文,然后再将第四报文发送给第二网络设备。
上述示例可以实现网络设备切换编解码能力的实现过程,即在第一网络设备和第二网络设备进行音视频报文传输时,如果第二网络设备由于一些原因不能再使用第一编解码参数进行编解码,这时第二网络设备可以向多媒体会议控制设备发送第二指示,通知多媒体会议控制设备第二网络设备需要由采用第一编解码参数切换为采用第二编解码参数进行编解码,多媒体会议控制设备接收到第二指示后,不再进行报文净荷的直接复制和报文头的修改,而是通过上述图2或图3中的方式进行报文转码处理后再进行传输。
在一种可能的实施方式中,在报文传输的过程中,还可以对报文进行存储,如果是音频报文,可以将报文净荷直接存储到文件存储器;如果是视频报文,可以将连续多个报文的净荷进行拼接处理后,组成一个完整的帧,然后再存储到文件存储器。
本申请实施例中,第一网络设备和第二网络设备进行报文传输时,由于第一网络设备和第二网络设备都采用第一编解码参数,所以在传输报文过程时,无需转码操作,直接复制报文净荷就可以,将报文头修改为相对应的报文头即可,从而能够减少对IPCC资源的占用,提高系统性能。
下面结合具体应用场景对本申请实施例提供的方案进行详细说明。
参见图6所示,示例性的示出了用户通过用户设备发起与坐席的坐席设备通信的流程示意图。基于图1所示的系统和图4所示的实施例,本申请实施例还提供了两方(用户和坐席)会议中报文传输的完整方法流程图,参阅图6所示,该示例的流程图具体可以包括:
步骤600,用户设备通过IMS的CSCF向IPCC的会议控制系统中的用户侧模块发送接入请求;
步骤601,用户侧模块接收到用户发送的请求后,向用户返回针对该接入请求的振铃和应答;
步骤602,用户侧模块和用户进行SIP SDP协商,确认用户传输报文时使用的第一编解码参数;
步骤603,用户接收到振铃和应答后,用户设备和用户侧模块进行交互式语音应答(interactive voice response,IVR)模式;
步骤604,用户设备向用户侧模块发送转人工坐席的消息;
步骤605,用户侧模块向会坐席侧模块发送转人工坐席的消息;
步骤606,坐席侧模块获取用户设备使用的第一编解码参数;
步骤607,坐席侧模块向坐席设备发送携带第一编解码参数的邀请坐席接入会议控制系统的请求;
步骤608,坐席设备向坐席侧模块返回针对该请求的携带第一指示的振铃和应答;这里的第一指示用于指示坐席侧采用第一编解码参数进行编解码。
步骤609,坐席侧模块向媒体会议模块发送申请媒体会议资源的请求;
步骤610,坐席侧模块建立坐席设备和坐席通道模块之间的连接,建立用户设备和用户通道模块之间的连接;
步骤611,坐席侧模块向用户通道模块发送坐席通道模块对应的通道信息,以使用户通道模块将接收到的报文信息发送给对应的坐席通道模块;
步骤612,坐席侧模块向坐席通道模块发送用户通道模块对应的通道信息,以使坐席通道模块将接收到的报文信息发送给对应的用户通道模块;
用户设备和坐席设备均接入到媒体会议控制系统,且确定用户设备和坐席设备均使用第一编解码参数进行编解码后,以下进行报文传输。
基于图1所示的系统架构和图6所示的用户设备和坐席设备接入到IPCC的流程,参阅图7,图7为本申请实施例提供的用户设备和坐席设备之间传输报文的方法流程示意图,具体包括:
步骤700,用户设备向用户通道模块发送第一报文;示例性的,第一报文可以是音频报文,也可以是视频报文。
步骤701,用户通道模块确定用户设备和坐席设备使用的编解码参数相同;
如果用户通道判断用户设备和坐席设备使用的编解码参数不同,则用户通道可以使用图2或图3中的方式进行报文传输。
步骤702,用户通道模块对接收到的第一报文进行解析,得到第一净荷和第一报文头;
步骤703,用户通道模块对第一净荷和第一报文头发送给坐席通道模块;
步骤704,坐席通道模块修改第一报文头,并将修改后的第一报文头和第一净荷组成第二报文;
步骤705,坐席通道模块将第二报文发送给坐席设备;
步骤706,坐席设备向坐席通道模块发送第三报文;
步骤707,坐席通道模块确定用户设备和坐席设备使用的编解码参数相同;
如果坐席通道模块判断用户设备和坐席设备使用的编解码参数不同,则坐席通道可以使用上述图2或图3中的方式进行报文传输,这里不再过多赘述。
步骤708,坐席通道模块对接收到的第三报文进行解析,得到第三净荷和第三报文头;
步骤709,坐席通道模块将第三净荷和第三报文头发送给用户通道模块;
步骤710,用户通道模块修改第三报文头,并将修改后的第三报文头和第三净荷组成第四报文;
步骤711,用户通道模块将第四报文发送给坐席设备。
坐席设备接收到第四报文后,如果第四报文为音频报文,那么坐席可以通过坐席设备听到用户的声音,如果第四报文为视频报文,那么坐席可以通过坐席设备看到用户的视频内容。
上述图6中的流程是在IPCC中用户呼入的场景,对于坐席主动外呼用户,和用户协商的发起者是坐席,不影响用户编解码协商结果。
在某些安全要求高的场景下,有可能会对报文进行加密,报文加解密过程在报文收发时处理,如用户通道收到报文,先解析获取净荷,进行内容解密,然后再做净荷复制,因此净荷复制同样适用于报文加密场景。
在IPCC中,用户求助于坐席解决问题时,如果坐席解决不了,则坐席可以邀请专家坐席接入,专家坐席接入后,对于音频通话,一方(用户、坐席或专家坐席)需要听两方的声音,比如用户听坐席的声音和专家坐席的声音,坐席听用户的声音和专家坐席的声音,所以不能采用本申请中的复制报文净荷,修改报文头的方式进行报文传输,只能采用现有技术中的转码方式,而对于视频,由于用户可以选择看坐席的视频画面,也可以选择看专家坐席的视频画面,因此可以采用本申请中提供的复制视频净荷,修改视频报文头的方式进行视频报文传输,下面对三方会议中视频报文传输进行说明。
在坐席无法解决用户的问题的情况下,坐席可以通过坐席设备邀请专家坐席加入会议,为了描述方便,将专家坐席采用的设备称为专家坐席设备。在该应用场景下,会议控制系统中还可以包括专家坐席侧模块,会议资源中还可以包括专家坐席通道模块,即在三方会议中,会议控制系统包括用户侧模块、坐席侧模块和专家坐席侧模块;会议资源包括用户通道模块、媒体会议模块、坐席通道模块和专家坐席模块。
基于图5所示的实施例,本申请实施例还提供了三方(用户、坐席和专家坐席)会议中视频报文传输的方法流程图,在三方传输视频报文时,需要专家坐席设备加入到IPCC中,参阅图8所示,专家坐席设备加入到IPCC的流程图具体可以包括:
步骤800,坐席侧模块向专家坐席侧模块发送接入请求;
步骤801,专家坐席侧模块获取用户设备使用的第一编解码参数;
步骤802,专家坐席侧模块向专家坐席设备发送携带第一编解码参数的邀请专家坐席设备接入会议控制系统的请求;
步骤803,专家坐席设备向专家坐席侧模块返回针对该请求的携带第一指示的振铃和应答;
步骤804,专家坐席侧模块建立专家坐席设备和专家坐席通道模块之间的连接;
步骤805,专家坐席侧模块向专家坐席通道模块发送用户通道对应的通道信息。
以上是专家坐席设备接入到IPCC的流程示意图,专家坐席设备接入到IPCC后,三方可以进行报文传输,参阅图9所示,三方报文传输的方法流程图具体可以包括:
步骤900,用户设备向用户通道发送第一视频报文;
步骤901,用户通道模块确定用户设备、坐席设备和专家坐席设备使用的编解码参数相同;
步骤902,用户通道模块对接收到的第一视频报文进行解析,得到第一视频净荷和第一视频报文头;
步骤903,用户通道模块向席通道模块和专家坐席通道模块发送第一视频净荷和第一视频报文;
步骤904,坐席通道模块修改第一视频报文头,并将修改后的第一视频报文头和第一视频净荷组成第二视频报文;
步骤905,坐席通道模块将第二视频报文发送给坐席设备,以使坐席通过坐席设备可以看到用户的视频内容;
步骤906,专家坐席通道模块修改第一视频报文头,并将修改后的第一视频报文头和第一视频净荷组成第三视频报文;
步骤907,专家坐席通道模块将第三视频报文发送给专家坐席设备,以使专家坐席通过专家坐席设备可以看到用户的视频内容;
步骤908,坐席设备向坐席通道发送第四视频报文;
步骤909,坐席通道模块确定用户设备和坐席设备使用的编解码参数相同;
由于用户可以只看坐席的视频内容,所以这里只判断用户设备和坐席设备使用的编解码参数是否相同,如果专家坐席和用户都看坐席的视频内容,则也可以判断用户设备、坐席设备和专家坐席设备三者使用的编解码参数是否相同。
步骤910,坐席通道模块对接收到的第四视频报文进行解析,得到第四视频净荷和第四视频报文头;
步骤911,坐席通道模块将第四视频净荷和第四视频报文头发送给用户通道模块;
步骤912,用户通道模块修改第四视频报文头,并将修改后的第四视频报文头和第四视频净荷组成第五视频报文;
步骤913,用户通道模块将第五视频报文发送给用户设备;
步骤914,专家坐席向专家坐席通道发送第六视频报文;
步骤915,专家坐席通道模块丢弃第六视频报文。
由于在三方视频时,用户和坐席可以不看专家坐席的视频内容,所以可以将专家坐席发送的第六视频报文丢弃。
需要说明的是,会议中音频、视频控制灵活,在转码和RTP复制切换时,源通道(即发送报文的通道)控制RTP报文是复制还是转码,对于音频每个报文都是独立的帧,可以直接切换,对于视频,视频帧可能由多个RTP报文组成,需要等当前帧发送完毕再切换。
在三方正在会议时,可以录制三方的音频信息和用户的视频信息,录制音频信息和视频信息时,包括会议资源、录制缓存和文件保存,其中,会议资源和图7所示的三方会议中传输报文时的会议系统相同,包括用户通道模块、媒体会议模块、坐席通道模块和专家坐席通道模块;录制缓存中可以包括音频缓存模块、视频缓存模块和文件缓存模块。
基于图1所示的系统和图4所示的实施例,本申请实施例还提供了三方会议时对音频内容和视频内容的录制的方法示意图,参阅图10所示,该示例的流程图具体可以包括:
步骤1000,用户通道模块将接收到的第一音频报文中的第一音频净荷进行解码,得到第一PCM原始音频信号;
步骤1001,用户通道模块将第一PCM原始音频信号发送给媒体会议模块;
步骤1002,坐席通道模块将接收到的第二音频报文中的第二净荷进行解码,得到第二PCM原始音频信号;
步骤1003,坐席通道模块将第二PCM原始音频信号发送给媒体会议模块;
步骤1004,专家坐席通道模块将接收到的第三音频报文中的第三净荷进行解码,得到第三PCM原始音频信号;
步骤1005,专家坐席通道模块将第三PCM原始音频信号发送给媒体会议模块;
步骤1006,媒体会议模块将接收到的第一PCM原始音频信号、第二PCM原始音频信号和第三PCM音频;
步骤1007,媒体会议模块确定需要录制音频内容;
步骤1008,媒体会议模块对混音后的音频信号进行编码,得到音频帧;
步骤1009,媒体会议模块向音频缓存模块发送音频帧;
步骤1010,用户通道模块解析接收到的视频报文,得到视频净荷;
步骤1011,用户通道模块确定需要录制视频;
步骤1012,用户通道模块拼接连续多个视频报文中的净荷,拼接成一个NALU;
步骤1013,用户通道模块将NALU发送给媒体会议模块;
步骤1014,媒体会议模块将NALU按预设规则增加视频帧头,得到视频帧;
步骤1015,媒体会议模块向视频缓存模块发送该视频帧;
步骤1016,文件缓存模块从视频缓存模块中读取步骤815得到的视频帧;
步骤1017,文件缓存模块从音频缓存模块中读取步骤808中得到的音频帧;
步骤1018,文件缓存模块解析步骤815和步骤816中读取的视频帧和音频帧,将视频帧和音频帧按时间交叉放在文件缓存模块中;
步骤1019,文件缓存模块按预设文件格式将文件缓存模块中缓存的数据封装到对应的容器(box)中;
比如,文件格式为3GP或MP4。
步骤1020,文件缓存模块将封装后的内容写入到文件存储模块中。
基于以上实施例,本申请实施例还提供了一种报文传输装置,该装置用于实现如图5所示的报文传输方法。参阅图11所示,该装置1100包括:通信单元1101和处理单元1102,其中所述通信单元1101,可以用于执行上述方法实施例中,例如图2至图9中多媒体会议控制设备(可以为图1中的IPCC)中的会议控制系统和会议资源的发送信息和接收信息的处理,处理单元1102可以用于执行上述方法实施例中,例如图2至图9中多媒体会议控制设备(可以为图1中的IPCC)中的会议资源的报文复制净荷并更改报文头的处理,或用于执行会议资源的报文转码处理。
采用本申请实施例提供的装置,获取到的第一网络设备的第一编解码参数,并接收到第二网络设备匹配第一编解码参数后发送的第一指示,该第一指示用于指示该第二网络设备采用该第一编解码参数进行编解码,由于第一网络设备和第二网络设备都采用第一编解码参数,所以在传输报文时,无需转码操作,直接复制该报文净荷,将报文头修改为接收方能够识别的报文头即可,从而能够减少占用IPCC的处理资源,可以进而提高IPCC的系统性能。
需要说明的是,本申请实施例中对单元的划分是示意性的,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式。在本申请的实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质可以包括:U盘、移动硬盘、只读存储器(read-only memory,ROM)、随机存取存储器(random access memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
基于以上实施例,本申请实施例还提供了一种多媒体会议控制设备,参阅图12所示,该多媒体会议控制设备1200包括:处理器1201、存储器1202和通信接口1203,上述通信单元1101可以基于这里的通信接口1203实现,上述的处理单元1102可以基于这里的处理器1201实现。所述处理器1201可以是中央处理器(central processing unit,CPU),网络处理器(network processor,NP)或者CPU和NP的组合。所述处理器1201还可以进一步包括硬件芯片。上述硬件芯片可以是专用集成电路(application-specific integrated circuit,ASIC),可编程逻辑器件(programmable logic device,PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(complex programmable logic device,CPLD),现场可编程逻辑门阵列(field-programmable gate array,FPGA),通用阵列逻辑(generic array logic,GAL)或其任意组合。存储器1202可以包括:U盘、移动硬盘、只读存储器(read-only memory,ROM)、随机存取存储器(random access memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
所述处理器1201、所述存储器1202以及所述通信接口1203之间相互连接。可选的,所述处理器1201、所述存储器1202以及所述通信接口1203可以通过总线1204相互连接;所述总线1204可以是外设部件互连标准(Peripheral Component Interconnect,PCI)总线或扩展工业标准结构(Extended Industry Standard Architecture,EISA)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示,图12中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。
本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。
Claims (12)
1.一种报文传输方法,其特征在于,包括:
多媒体会议控制设备获取第一网络设备的第一编解码参数,所述第一编解码参数用于指示所述第一网络设备的编解码能力;
所述多媒体会议控制设备将所述第一编解码参数发送给第二网络设备;
所述多媒体会议控制设备接收到所述第二网络设备匹配所述第一编解码参数后发送的第一指示,所述第一指示用于指示所述第二网络设备采用所述第一编解码参数进行编解码;
所述多媒体会议控制设备接收来自发送方的第一报文,向接收方发送第二报文;
其中,所述第一报文包括第一报文头和第一净荷,所述第二报文包括第二报文头和第二净荷,所述第二报文头由所述第一报文头转换得到,所述第二净荷由复制所述第一净荷得到;
所述发送方为所述第一网络设备时,所述接收方为所述第二网络设备,或者所述发送方为所述第二网络设备时,所述接收方为所述第一网络设备。
2.如权利要求1所述的方法,其特征在于,所述多媒体会议控制设备向接收方发送第二报文后,还包括:
所述多媒体会议控制设备接收到所述第二网络设备发送的第二指示,所述第二指示用于指示所述第二网络设备由采用所述第一编解码参数进行编解码切换为采用第二编解码参数进行编解码;
所述多媒体会议控制设备接收来自发送方的第三报文,并根据所述第一编解码参数对所述第三报文进行解码处理,并根据所述第二编解码参数对解码处理后的数据进行编码处理,得到第四报文;
所述多媒体会议控制设备向所述接收方发送所述第四报文。
3.如权利要求1所述的方法,其特征在于,所述多媒体会议控制设备接收来自发送方的第一报文,包括:
所述多媒体会议控制设备接收来自发送方的视频流,所述视频流包括连续多个所述第一报文;
所述方法还包括:
所述多媒体会议控制设备对连续多个所述第一报文中包括的第一净荷进行拼接处理,将拼接后的净荷存储。
4.如权利要求1~3任一所述的方法,其特征在于,所述第一报文为音频报文或视频报文。
5.如权利要求4所述的方法,其特征在于,所述第一报文为音频报文时,所述第一编解码参数包括报文打包时长、对齐模式、采样率或速率集中的至少一项;或者
所述第一报文为视频报文时,所述第一编解码参数包括帧率和/或分辨率。
6.一种报文传输装置,其特征在于,包括:
通信单元,用于获取第一网络设备的第一编解码参数,所述第一编解码参数用于指示所述第一网络设备的编解码能力;并将所述第一编解码参数发送给第二网络设备;以及接收到所述第二网络设备匹配所述第一编解码参数后发送的第一指示,所述第一指示用于指示所述第二网络设备采用所述第一编解码参数进行编解码;以及接收来自发送方的第一报文,并向接收方发送第二报文;所述发送方为所述第一网络设备时,所述接收方为所述第二网络设备,或者所述发送方为所述第二网络设备时,所述接收方为所述第一网络设备;
处理单元,用于将所述第一报文处理成所述第二报文,其中,所述第一报文包括第一报文头和第一净荷,所述第二报文包括第二报文头和第二净荷,所述第二报文头由第一报文头转换得到,第二净荷由复制第一净荷得到。
7.如权利要求6所述的装置,其特征在于,所述通信单元,还用于:
向接收方发送第二报文后,接收到所述第二网络的设备发送的第二指示,所述第二指示用于指示所述第二网络设备由采用所述第一编解码参数切换为采用第二编解码参数进行编解码;以及接收来自发送方的第三报文;
所述处理单元,还用于根据所述第一编解码参数对所述第三报文进行解码处理,并根据所述第二编解码参数对解码处理后的数据进行编码处理,得到第四报文;
所述通信单元,还用于向所述接收方发送所述第四报文。
8.如权利要求6所述的装置,其特征在于,所述通信单元接收来自发送方的第一报文时,具体用于:
接收来自发送方的视频流,所述视频流包括连续多个所述第一报文;
所述处理单元,还用于对连续多个所述第一报文中包括的第一净荷进行拼接处理,将拼接后的净荷存储。
9.如权利要求6~8任一所述的装置,其特征在于,所述第一报文为音频报文或视频报文。
10.如权利要求9所述的装置,其特征在于,所述第一报文为音频报文时,所述第一编解码参数包括报文打包时长、对齐模式、采样率或速率集中的至少一项;或者
所述第一报文为视频报文时,所述第一编解码参数包括帧率和/或分辨率。
11.一种多媒体会议控制设备,其特征在于,包括处理器、存储器和通信接口,所述处理器与所述存储器耦合;
所述存储器,存储有计算机程序;
所述处理器,用于执行所述存储器中存储的计算机程序,以使得所述多媒体会议控制设备通过所述通信接口执行如权利要求1-5中任意一项所述的方法。
12.一种计算机可读存储介质,其特征在于,包括程序或指令,当所述程序或指令在计算机上运行时,如权利要求1-5中任意一项所述的方法被执行。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811544660.0A CN111327580A (zh) | 2018-12-17 | 2018-12-17 | 一种报文传输方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811544660.0A CN111327580A (zh) | 2018-12-17 | 2018-12-17 | 一种报文传输方法及装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN111327580A true CN111327580A (zh) | 2020-06-23 |
Family
ID=71170838
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201811544660.0A Pending CN111327580A (zh) | 2018-12-17 | 2018-12-17 | 一种报文传输方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111327580A (zh) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112422851A (zh) * | 2020-11-16 | 2021-02-26 | 新华三技术有限公司 | 视频切换方法、装置及设备 |
CN112422514A (zh) * | 2020-10-26 | 2021-02-26 | 深圳Tcl新技术有限公司 | 多媒体数据传输方法、装置、智能家居设备及存储介质 |
CN114422563A (zh) * | 2021-12-29 | 2022-04-29 | 海南同享数字科技有限公司 | 一种页面调用后台数据方法、装置、设备及存储介质 |
CN114448955A (zh) * | 2021-12-31 | 2022-05-06 | 赛因芯微(北京)电子科技有限公司 | 一种数字音频网络传输方法、装置、设备及存储介质 |
WO2023124587A1 (zh) * | 2021-12-31 | 2023-07-06 | 上海海思技术有限公司 | 一种媒体文件的传输方法和设备 |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20110119394A1 (en) * | 2009-11-04 | 2011-05-19 | Futurewei Technologies, Inc. | System and Method for Media Content Streaming |
CN102256101A (zh) * | 2011-07-26 | 2011-11-23 | 中兴通讯股份有限公司 | 一种视频会议中媒体能力的转换方法、系统及应用服务器 |
CN102263942A (zh) * | 2010-05-31 | 2011-11-30 | 苏州闻道网络科技有限公司 | 一种分级视频转码装置和方法 |
CN102413309A (zh) * | 2011-12-27 | 2012-04-11 | 中兴通讯股份有限公司 | 加入视频会议的方法及装置 |
CN103795958A (zh) * | 2012-10-30 | 2014-05-14 | 中国电信股份有限公司 | 多媒体呼叫协商方法、系统及视频互通网关、多媒体终端 |
CN106921843A (zh) * | 2017-01-18 | 2017-07-04 | 苏州科达科技股份有限公司 | 数据传输方法及装置 |
CN108965914A (zh) * | 2017-12-20 | 2018-12-07 | 北京视联动力国际信息技术有限公司 | 一种基于视联网的视频数据处理方法及装置 |
-
2018
- 2018-12-17 CN CN201811544660.0A patent/CN111327580A/zh active Pending
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20110119394A1 (en) * | 2009-11-04 | 2011-05-19 | Futurewei Technologies, Inc. | System and Method for Media Content Streaming |
CN102263942A (zh) * | 2010-05-31 | 2011-11-30 | 苏州闻道网络科技有限公司 | 一种分级视频转码装置和方法 |
CN102256101A (zh) * | 2011-07-26 | 2011-11-23 | 中兴通讯股份有限公司 | 一种视频会议中媒体能力的转换方法、系统及应用服务器 |
CN102413309A (zh) * | 2011-12-27 | 2012-04-11 | 中兴通讯股份有限公司 | 加入视频会议的方法及装置 |
CN103795958A (zh) * | 2012-10-30 | 2014-05-14 | 中国电信股份有限公司 | 多媒体呼叫协商方法、系统及视频互通网关、多媒体终端 |
CN106921843A (zh) * | 2017-01-18 | 2017-07-04 | 苏州科达科技股份有限公司 | 数据传输方法及装置 |
CN108965914A (zh) * | 2017-12-20 | 2018-12-07 | 北京视联动力国际信息技术有限公司 | 一种基于视联网的视频数据处理方法及装置 |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112422514A (zh) * | 2020-10-26 | 2021-02-26 | 深圳Tcl新技术有限公司 | 多媒体数据传输方法、装置、智能家居设备及存储介质 |
CN112422514B (zh) * | 2020-10-26 | 2024-06-07 | 深圳Tcl新技术有限公司 | 多媒体数据传输方法、装置、智能家居设备及存储介质 |
CN112422851A (zh) * | 2020-11-16 | 2021-02-26 | 新华三技术有限公司 | 视频切换方法、装置及设备 |
CN112422851B (zh) * | 2020-11-16 | 2022-06-28 | 新华三技术有限公司 | 视频切换方法、装置及设备 |
CN114422563A (zh) * | 2021-12-29 | 2022-04-29 | 海南同享数字科技有限公司 | 一种页面调用后台数据方法、装置、设备及存储介质 |
CN114448955A (zh) * | 2021-12-31 | 2022-05-06 | 赛因芯微(北京)电子科技有限公司 | 一种数字音频网络传输方法、装置、设备及存储介质 |
WO2023124587A1 (zh) * | 2021-12-31 | 2023-07-06 | 上海海思技术有限公司 | 一种媒体文件的传输方法和设备 |
CN114448955B (zh) * | 2021-12-31 | 2024-02-02 | 赛因芯微(北京)电子科技有限公司 | 一种数字音频网络传输方法、装置、设备及存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN111327580A (zh) | 一种报文传输方法及装置 | |
US7813492B2 (en) | Method and system for establishing a multimedia connection by negotiating capability in an outband control channel | |
US8560717B2 (en) | Method and system for implementing video call service and video interworking gateway device | |
EP1819097B1 (en) | A system for monitoring video call | |
US10068581B2 (en) | Method and arrangement for providing a backwards compatible payload format | |
US7227922B2 (en) | Method and device for the transmission of data in a packet-oriented data network | |
US20100128715A1 (en) | Protocol Conversion System in Media Communication between a Packet-Switching Network and Circuit-Switiching Network | |
US8582726B2 (en) | Method and an apparatus for handling multimedia calls | |
CN106921843B (zh) | 数据传输方法及装置 | |
WO2003041321A2 (en) | Method and apparatus for packet-based media communication | |
US9826072B1 (en) | Network-terminal interoperation using compatible payloads | |
US8737968B2 (en) | Method and system for handling a multi-media call setup request | |
CN101115011A (zh) | 一种流媒体回放方法、装置及系统 | |
CN101160983B (zh) | 一种数据流处理的方法、装置和系统 | |
JP5242683B2 (ja) | インターネットプロトコル(ip)ドメインでの監視における又はこれに関連する改良 | |
US20220078215A1 (en) | Method and apparatus for processing immersive media | |
CN103151041B (zh) | 一种自动语音识别业务的实现方法、系统和媒体服务器 | |
US9313508B1 (en) | Feeding intra-coded video frame after port reconfiguration in video telephony | |
CN114500914A (zh) | 音视频转发方法、装置、终端与系统 | |
WO2017152566A1 (zh) | 一种协商媒体编解码的方法,及一种终端设备 | |
WO2023019167A1 (en) | Supporting quality of service for media communications | |
EP4356593A1 (en) | Real-time augmented reality communication session | |
KR102109607B1 (ko) | 통신 네트워크에서 송수신 지연을 감소시키기 위한 시스템 및 장치 | |
CN115811570B (zh) | Ims通话语音质量测试方法及系统 | |
US20240340322A1 (en) | Signaling usage of pdu set and end of burst marking for communicating webrtc media data |
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 | ||
RJ01 | Rejection of invention patent application after publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20200623 |