CN112770072A - 一种数据传输方法、装置及存储介质 - Google Patents

一种数据传输方法、装置及存储介质 Download PDF

Info

Publication number
CN112770072A
CN112770072A CN202011601774.1A CN202011601774A CN112770072A CN 112770072 A CN112770072 A CN 112770072A CN 202011601774 A CN202011601774 A CN 202011601774A CN 112770072 A CN112770072 A CN 112770072A
Authority
CN
China
Prior art keywords
data packet
udp
packet
udp data
sending
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
CN202011601774.1A
Other languages
English (en)
Other versions
CN112770072B (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.)
Beijing North Source Software Co ltd
Original Assignee
Beijing North Source Software 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 Beijing North Source Software Co ltd filed Critical Beijing North Source Software Co ltd
Priority to CN202011601774.1A priority Critical patent/CN112770072B/zh
Publication of CN112770072A publication Critical patent/CN112770072A/zh
Application granted granted Critical
Publication of CN112770072B publication Critical patent/CN112770072B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/14Systems for two-way working
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/04Real-time or near real-time messaging, e.g. instant messaging [IM]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441Countermeasures against malicious traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/14Systems for two-way working
    • H04N7/15Conference systems

Abstract

本申请实施例提供一种数据传输方法、装置及存储介质,方法包括:当进行音视频会话时,通过预先创建的一个用户数据报协议UDP端口接收至少一个发送端所发送的至少一个UDP数据包;基于每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,将每个UDP数据包发送给所述UDP数据包所对应的接收端。本申请实施例实现了单端口对音视频数据的转发过程,大幅度减少webrtc音视频数据转发所占用的UDP端口数量,解决了端口随接入人数不断增加的问题。

Description

一种数据传输方法、装置及存储介质
技术领域
本申请涉及数据传输技术领域,尤其涉及一种数据传输方法、装置及存储介质。
背景技术
在非安全网络使用源自网页即时通信(Web Real-Time Communication,Webrtc)音视频技术进行媒体数据转发时,采用多端口用户数据报协议(User Datagram Protocol,UDP)对应转发。该种方式UDP端口数量会随参与人数倍数增加,对非安全网络造成多UDP端口放行的潜在需求,大幅度增加了非安全网络的网络攻击潜在风险。
发明内容
本申请实施例提供一种数据传输方法、装置及存储介质,以解决音视频过程中所需端口随接入人数不断增加的问题。
本申请实施例提供一种数据传输方法,包括:
当进行音视频会话时,通过预先创建的一个用户数据报协议UDP端口接收至少一个发送端所发送的至少一个UDP数据包;
基于每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,将每个UDP数据包发送给所述UDP数据包所对应的接收端。
可选地,所述基于每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,将每个UDP数据包发送给所述UDP数据包所对应的接收端之前,还包括:
获取每个UDP数据包的类型;
基于所述每个UDP数据包的类型,获取所述每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系。
可选地,所述基于所述每个UDP数据包的类型,获取所述每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,包括:
当所述UDP数据包的类型为网络地址转换会话穿越应用程序STUN时,通过UDP协议确定所述UDP数据包的来源IP和发送端口,并基于所述UDP数据包的来源IP和发送端口确定所述UDP数据包的发送端;
获取与所述发送端进行同一音视频会话的其他客户端,并将所述其他客户端确定为所述UDP数据包的接收端;
建立所述UDP数据包、所述UDP数据包的发送端以及所述UDP数据包的接收端之间的映射关系。
可选地,还包括:
基于所述UDP数据包、所述UDP数据包的发送端以及所述UDP数据包的接收端之间的映射关系,确定所述发送端的端口和IP地址;
基于所述发送端的端口和IP地址,向所述发送端发送STUN协议的数据回包。
可选地,所述基于所述每个UDP数据包的类型,获取所述每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,包括:
当所述UDP数据包的类型为实时传输协议RTP或实时传输控制协议RTCP时,解析所述UDP数据包的包头,获取同步信源SSRC标识符;
基于预先建立的音视频会话中的会话流SSRC标识符、发送端和接收端之间的映射关系,得到所述UDP数据包的发送端和接收端;
建立所述UDP数据包、所述UDP数据包的发送端以及所述UDP数据包的接收端之间的映射关系。
可选地,所述基于每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,将每个UDP数据包发送给所述UDP数据包所对应的接收端,包括:
当所述UDP数据包的类型为RTP或RTCP时,对所述UDP数据包的包头进行修改,以使所述UDP数据包的接收端能够正常接收,并对修改后的UDP数据包进行数据包校验以及安全套接字协议SSL加密操作,将通过校验以及加密后的RTP数据包发送给所述UDP数据包所对应的接收端;
其中,所述RTCP类型的数据包包括发送端报告SR数据包、收端报告RR数据包、反馈报告FB数据包或结束传输BYE数据包。
可选地,还包括:
实时更新每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系。
本实施例还提供一种数据传输装置,包括:
接收模块,用于当进行音视频会话时,通过预先创建的一个用户数据报协议UDP端口接收至少一个发送端所发送的至少一个UDP数据包;
发送模块,用于基于每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,将每个UDP数据包发送给所述UDP数据包所对应的接收端。
本申请实施例提供一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述程序时实现所述的数据传输方法的步骤。
本申请实施例提供一种非暂态计算机可读存储介质,其上存储有计算机程序,该计算机程序被处理器执行时实现所述的数据传输方法的步骤。
本申请实施例提供的数据传输方法、装置及存储介质,当进行音视频会话时,通过预先创建的一个UDP端口接收至少一个发送端所发送的至少一个UDP数据包,并基于每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,将每个UDP数据包发送给UDP数据包所对应的接收端,实现了通过UDP单端口转发UDP数据,大幅度减少webrtc音视频数据转发所占用的UDP端口数量,使得端口数量不会因为人数而不断增加,降低了因为端口过多造成的非安全网络攻击风险,解决了端口随接入人数不断增加的问题。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍,显而易见地,下面描述中的附图是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本申请实施例中数据传输方法的步骤流程图;
图2为本申请实施例中数据转发的过程示意图;
图3为本申请实施例中数据传输装置的模块框图;
图4为本申请实施例中电子设备的结构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
如图1所示,为本申请实施例中数据传输方法的步骤流程图,该方法包括如下步骤:
步骤101:当进行音视频会话时,通过预先创建的一个UDP端口接收至少一个发送端所发送的至少一个UDP数据包。
具体的,音视频会话可以为Webrtc音视频会话。
数据传输过程中,本申请中的数据传输装置创建唯一一个用户数据报协议(简称UDP)端口,并通过该唯一的一个UDP端口接收至少一个发送端所发送的至少一个UDP数据包,实现了单UDP端口转发Webrtc媒体数据,使得端口数量不会因为人数而不断增加。
发送端的数量可以为多个,在此并不对此进行具体限制。此外,多个发送端可以同时或不同时发送UDP数据包,在此也不对此进行具体限制。
步骤102:基于每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,将每个UDP数据包发送给UDP数据包所对应的接收端。
具体的,发送端和接收端为客户端,可以为电脑、手机或平板等,本实施例中一个客户端即可以为发送端也可以为接收端,并将发送数据时的客户端确定为发送端,将接收数据的客户端确定为接收端。
在本步骤中,可以先获取所接收到的每个UPD数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,然后基于该映射关系,将每个UDP数据包发送给UDP数据包所对应的接收端,从而实现UDP单端口对数据的转发过程,降低了因为端口过多造成的非安全网络攻击风险。
当然,UDP数据包的接收端可以为一个或多个,在此不对此进行限定。此外,接收端在接收到UDP数据包后,可以通过建立的DUP数据包、发送端和接收端之间的动态映射关系,对UDP数据包进行回复,实现准确高效的实时音视频数据转发。
此外,需要说明的是,UDP端口转发所接收到的UDP数据包时,可以使用安全传输协议(简称SRTP)传输方案,并使用会话描述协议(简称SDP)密钥交换方式,保证音视频会话的安全传输。此外,UDP数据包的加解密可以使用安全套接字协议(简称SSL)方式进行,以保证音视频会话的安全传输。
这样本实施例通过创建唯一一个UDP端口,并通过该唯一一个UDP端口接收多个UDP数据包,然后将每个UDP数据包发送给该UDP数据包所对应的接收端,实现了以单端口转发媒体数据,解决了端口随接入人数不断增加的问题。
可选地,在本实施例中,在基于每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,将每个UDP数据包发送给所述UDP数据包所对应的接收端之前,还需要执行如下步骤:
步骤A1:获取每个UDP数据包的类型。
具体的,本实施例可以对接收到的UDP数据包进行分包以及分类,具体可以通过解析UDP数据包的包头,来确定数据包的长度以及数据包的类型。
具体的,UDP数据包的类型可以包括网络地址转换会话穿越应用程序(简称STUN)、实时传输协议(简称RTP)以及实时传输控制协议(简称RTCP),即UDP数据包可以为STUN数据包、RTP数据包或RTCP数据包。
步骤A2:基于每个UDP数据包的类型,获取每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系。
具体的,本实施例可以基于每个UDP数据包的类型,以不同的方式,获取每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系。
其中,获取映射关系时可以包括如下几种方式:
其一,当UDP数据包的类型为STUN时,可以通过UDP协议确定UDP数据包的来源IP和发送端口,并基于UDP数据包的来源IP和发送端口确定UDP数据包的发送端,然后获取与发送端进行同一音视频会话的其他客户端,并将所述其他客户端确定为所述UDP数据包的接收端,最后建立所述UDP数据包、所述UDP数据包的发送端以及所述UDP数据包的接收端之间的映射关系。
具体的,当UDP数据包的类型为STUN时,即当UDP数据包为STUN数据包时,可以通过UDP协议确定UDP数据包的来源IP和发送端口,即确定UDP数据包的发送端;此外,本实施例还可以获取与UDP数据包的发送端进行同一音视频会话的其他客户端,并将其他客户端确定为UDP数据包的接收端,进而可以动态建立UDP数据包、所述UDP数据包的发送端以及所述UDP数据包的接收端之间的映射关系。
具体的,在此需要说明的是,当UDP数据包的类型为STUN时,还可以通过STUN协议中的username来确定数据包来源,从而建立username与STUN数据包的映射关系,并通过UDP协议确定数据包的来源IP和发送端口,进而建立uersname与数据包的来源IP和端口的绑定关系,即由uersname表示数据包,建立uersname与数据包的发送端的映射关系,最后建立uersname、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系。
另外,可选地,在本实施例中,当UDP数据包为STUN数据包时,在解析SUTN数据包后需进行STUN协议的数据回包,此时可以基于UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,确定所述发送端的端口和IP地址,并基于发送端的端口和IP地址,向所述发送端发送STUN协议的数据回包,从而保证会话链接连通。
此外,本实施例需要实时更新数据包的来源IP、端口,来确保UDP链接在发送端切换网络地址时能正确回包给发送端,例如:发送端在发送数据过程中切换网络,4G网络切换到WiFi网络,仍能保证会话正常,从而保证音视频会话不受网络切换影响。
其二,当UDP数据包的类型为RTP或RTCP时,解析UDP数据包的包头,获取同步信源(简称SSRC)标识符,然后基于预先建立的音视频会话中的会话流SSRC标识符、发送端和接收端之间的映射关系,得到所述UDP数据包的发送端和接收端,然后建立所述UDP数据包、所述UDP数据包的发送端以及所述UDP数据包的接收端之间的映射关系。
具体的,音视频会话过程中可以首先使用安全传输层协议(简称TLS)方式进行SDP协议交互,进行会话多方的密钥交互,以及约定会话流的唯一标识SSRC标识符,并建立每个客户端(包括发送端和接收端)与SSRC标识符的映射关系。
然后,当UDP数据包的类型为RTP或RTCP,即UDP数据包为RTP数据包或RTCP数据包时,可以解析UDP数据包的包头,获取SSRC标识符,然后可以基于该SSRC标识符和接收端之间的映射关系确定该UDP数据包的接收端,从而使得能够建立UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系。
此外,可选地,在本实施例中,将每个UDP数据包发送给所述UDP数据包所对应的接收端时,可以当UDP数据包的类型为RTP或RTCP时,对UDP数据包的包头进行修改,以使所述UDP数据包的接收端能够正常接收,并对修改后的UDP数据包进行数据包校验以及安全套接字协议SSL加密操作,将通过校验以及加密后的UDP数据包发送给所述UDP数据包所对应的接收端。
其中,RTCP类型的数据包包括发送端报告(简称SR)数据包、收端报告(简称RR)数据包、反馈报告(简称FB)数据包或结束传输(简称BYE)数据包。
具体的,当UDP数据包的类型为RTP或RTCP时,在对数据包的包头进行修改时,可以变更时间戳,修改数据MAPPING值,从而使得数据包的接收端能够正常接收,然后可以进行数据包校验以及SSL数据加密,最后发送给接收端。
此外,当DUP数据包的类型为RTCP时,可以进一步对RTCP包进行分类,检测是SR数据包、RR数据包、FB数据包还是BYE数据包,然后分别对SR数据包、RR数据包、FB数据包以及BYE数据包进行修改,修改时可以变更时间戳以及修改数据MAPPING值等。
这样,通过上述过程实现了建立UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,并且使得能够正确的将UDP数据包发送给接收端。
此外,可选地,在本实施例中,还需要实时更新每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,从而使得能够保证会话的正常进行,保证音视频会话不受网络切换影响。
需要说明的是,在本实施例中,接收端在接收数据的同时,也可作为发送端发送自己产生的音视频数据,从而形成双方音视频互通的单端口数据转发过程。
下面通过图2对本申请的过程进行具体说明。
首先,发送端与接收端以LTS方式进行SDP协议交互,交换密钥以及确定SSRC会话流标识。
然后,发送端Client A、Client B、Client C以及Client n等发送数据包,此时UDP端口接收该多个发送端所发送的数据包,即接收混合数据,并通过解析数据包头进行不同数据包的分包及分类,以及数据溯源和数据解密。
再然后,在经过数据溯源和数据解密后,在数据映射区中建立数据包、数据包的发送端以及数据包的接收端之间的映射关系。
其中,当为STUN数据包时,通过STUN协议中的username来确定数据包来源,建立username与STUN数据包的映射关系,并通过UDP协议确定数据包的来源IP和发送端口,建立uersname与数据包的来源IP和端口的绑定关系,并实时更新发送端IP和端口。此外,解析STUN数据包后进行STUN协议的数据回包,通过UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,确定回包客户端,即发送端的端口和IP地址,并进行STU回包,保证会话链接连通。
当为RTP数据包时,通过解析RTP协议头,来获取SSRC会话流唯一标识,确定RTP数据包的接收端,然后对RTP数据包的包头进行修改,变更时间戳,修改数据MAPPING值,然后再进行数据包校验以及SSL数据加密,转发给对应的接收端。例如,发送端A1将数据包发送给接收端(Client)A’,发送端B将数据包发送给接收端B’,发送端An将数据包发送给接收端Bn。
当为RTCP数据包时,通过解析RTP数据包的包头,来获取SSRC会话流唯一标识,并进一步判断数据包是否是RTCP数据包,如果是,再进行RTCP数据包分类,来确认是SR包、RR包、FB包还是BYE包。
最后,在数据校准区分别对RTP包、SR包、RR包、FB包、BYE包等的包头进行改造,变更时间戳,修改数据MAPPING值,再进行数据包校验,以及在数据加密区进行SSL数据加密,并转发给对应的接收端。例如,基于映射关系,接收端Client A’接收发送端Client A的实时数据,接收端Client B’接收发送端Client B的实时数据,接收端Client C’接收发送端Client C的实时数据,接收端Client n’接收发送端Client n的实时数据。
在上述过程中,需要实时更新数据包的来源IP、端口,来确保UDP链接在发送端切换网络地址,能正确回包给发送端,例如:发送端在发送数据过程中切换网络,4G网络切换到WiFi网络时,仍能保证会话正常,保证音视频会话不受网络切换影响。
这样,本实施例通过单一UDP端口转发音视频数据,大幅度减少了webrtc音视频数据转发所占用的UDP端口数量,降低了技术使用时的维护成本。
此外,如图3所示,为本申请中数据传输装置的模块框图,该装置包括:
接收模块301,用于当进行音视频会话时,通过预先创建的一个用户数据报协议UDP端口接收至少一个发送端所发送的至少一个UDP数据包;
发送模块302,用于基于每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,将每个UDP数据包发送给所述UDP数据包所对应的接收端。
可选地,所述装置还包括:
第一获取模块,用于获取每个UDP数据包的类型;
第二获取模块,用于基于所述每个UDP数据包的类型,获取所述每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系。
可选地,第二获取模块具体用于,当所述UDP数据包的类型为网络地址转换会话穿越应用程序STUN时,通过UDP协议确定所述UDP数据包的来源IP和发送端口,并基于所述UDP数据包的来源IP和发送端口确定所述UDP数据包的发送端;获取与所述发送端进行同一音视频会话的其他客户端,并将所述其他客户端确定为所述UDP数据包的接收端;建立所述UDP数据包、所述UDP数据包的发送端以及所述UDP数据包的接收端之间的映射关系。
可选地,第二获取模块具体用于,当所述UDP数据包的类型为实时传输协议RTP或实时传输控制协议RTCP时,解析所述UDP数据包的包头,获取同步信源SSRC标识符;基于预先建立的音视频会话中的会话流SSRC标识符、发送端和接收端之间的映射关系,得到所述UDP数据包的发送端和接收端;建立所述UDP数据包、所述UDP数据包的发送端以及所述UDP数据包的接收端之间的映射关系。
在此需要说明的是,本装置能够实现上述方法所实现的方法步骤,并能够达到相同的技术效果,在此不再对此进行赘述。
另外,如图4所示,为本申请实施例提供的电子设备的实体结构示意图,该电子设备可以包括:处理器(processor)410、通信接口(Communications Interface)420、存储器(memory)430和通信总线440,其中,处理器410,通信接口420,存储器430通过通信总线440完成相互间的通信。处理器410可以调用存储在存储器430上并可在处理器410上运行的计算机程序,以执行上述各实施例提供的方法,例如包括:
当进行音视频会话时,通过预先创建的一个用户数据报协议UDP端口接收至少一个发送端所发送的至少一个UDP数据包;基于每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,将每个UDP数据包发送给所述UDP数据包所对应的接收端。
可选地,所述基于每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,将每个UDP数据包发送给所述UDP数据包所对应的接收端之前,还包括:
获取每个UDP数据包的类型;基于所述每个UDP数据包的类型,获取所述每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系。
可选地,所述基于所述每个UDP数据包的类型,获取所述每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,包括:
当所述UDP数据包的类型为网络地址转换会话穿越应用程序STUN时,通过UDP协议确定所述UDP数据包的来源IP和发送端口,并基于所述UDP数据包的来源IP和发送端口确定所述UDP数据包的发送端;获取与所述发送端进行同一音视频会话的其他客户端,并将所述其他客户端确定为所述UDP数据包的接收端;建立所述UDP数据包、所述UDP数据包的发送端以及所述UDP数据包的接收端之间的映射关系。
可选地,还包括:
基于所述UDP数据包、所述UDP数据包的发送端以及所述UDP数据包的接收端之间的映射关系,确定所述发送端的端口和IP地址;基于所述发送端的端口和IP地址,向所述发送端发送STUN协议的数据回包。
可选地,所述基于所述每个UDP数据包的类型,获取所述每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,包括:
当所述UDP数据包的类型为实时传输协议RTP或实时传输控制协议RTCP时,解析所述UDP数据包的包头,获取同步信源SSRC标识符;基于预先建立的音视频会话中的会话流SSRC标识符、发送端和接收端之间的映射关系,得到所述UDP数据包的发送端和接收端;建立所述UDP数据包、所述UDP数据包的发送端以及所述UDP数据包的接收端之间的映射关系。
可选地,所述基于每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,将每个UDP数据包发送给所述UDP数据包所对应的接收端,包括:
当所述UDP数据包的类型为RTP或RTCP时,对所述UDP数据包的包头进行修改,以使所述UDP数据包的接收端能够正常接收,并对修改后的UDP数据包进行数据包校验以及安全套接字协议SSL加密操作,将通过校验以及加密后的RTP数据包发送给所述UDP数据包所对应的接收端;
其中,所述RTCP类型的数据包包括发送端报告SR数据包、收端报告RR数据包、反馈报告FB数据包或结束传输BYE数据包。
可选地,还包括:
实时更新每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系。
此外,上述的存储器430中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
本申请实施例还提供一种非暂态计算机可读存储介质,其上存储有计算机程序,该计算机程序被处理器执行时实现以执行上述各实施例提供的方法。
以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下,即可以理解并实施。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件。基于这样的理解,上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在计算机可读存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。
最后应说明的是:以上实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (10)

1.一种数据传输方法,其特征在于,包括:
当进行音视频会话时,通过预先创建的一个用户数据报协议UDP端口接收至少一个发送端所发送的至少一个UDP数据包;
基于每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,将每个UDP数据包发送给所述UDP数据包所对应的接收端。
2.根据权利要求1所述的数据传输方法,其特征在于,所述基于每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,将每个UDP数据包发送给所述UDP数据包所对应的接收端之前,还包括:
获取每个UDP数据包的类型;
基于所述每个UDP数据包的类型,获取所述每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系。
3.根据权利要求2所述的数据传输方法,其特征在于,所述基于所述每个UDP数据包的类型,获取所述每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,包括:
当所述UDP数据包的类型为网络地址转换会话穿越应用程序STUN时,通过UDP协议确定所述UDP数据包的来源IP和发送端口,并基于所述UDP数据包的来源IP和发送端口确定所述UDP数据包的发送端;
获取与所述发送端进行同一音视频会话的其他客户端,并将所述其他客户端确定为所述UDP数据包的接收端;
建立所述UDP数据包、所述UDP数据包的发送端以及所述UDP数据包的接收端之间的映射关系。
4.根据权利要求3所述的数据传输方法,其特征在于,还包括:
基于所述UDP数据包、所述UDP数据包的发送端以及所述UDP数据包的接收端之间的映射关系,确定所述发送端的端口和IP地址;
基于所述发送端的端口和IP地址,向所述发送端发送STUN协议的数据回包。
5.根据权利要求2所述的数据传输方法,其特征在于,所述基于所述每个UDP数据包的类型,获取所述每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,包括:
当所述UDP数据包的类型为实时传输协议RTP或实时传输控制协议RTCP时,解析所述UDP数据包的包头,获取同步信源SSRC标识符;
基于预先建立的音视频会话中的会话流SSRC标识符、发送端和接收端之间的映射关系,得到所述UDP数据包的发送端和接收端;
建立所述UDP数据包、所述UDP数据包的发送端以及所述UDP数据包的接收端之间的映射关系。
6.根据权利要求5所述的数据传输方法,其特征在于,所述基于每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,将每个UDP数据包发送给所述UDP数据包所对应的接收端,包括:
当所述UDP数据包的类型为RTP或RTCP时,对所述UDP数据包的包头进行修改,以使所述UDP数据包的接收端能够正常接收,并对修改后的UDP数据包进行数据包校验以及安全套接字协议SSL加密操作,将通过校验以及加密后的RTP数据包发送给所述UDP数据包所对应的接收端;
其中,所述RTCP类型的数据包包括发送端报告SR数据包、收端报告RR数据包、反馈报告FB数据包或结束传输BYE数据包。
7.根据权利要求1至6任一项所述的数据传输方法,其特征在于,还包括:
实时更新每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系。
8.一种数据传输装置,其特征在于,包括:
接收模块,用于当进行音视频会话时,通过预先创建的一个用户数据报协议UDP端口接收至少一个发送端所发送的至少一个UDP数据包;
发送模块,用于基于每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,将每个UDP数据包发送给所述UDP数据包所对应的接收端。
9.一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,其特征在于,所述处理器执行所述程序时实现如权利要求1至7任一项所述的数据传输方法的步骤。
10.一种非暂态计算机可读存储介质,其上存储有计算机程序,其特征在于,该计算机程序被处理器执行时实现如权利要求1至7任一项所述的数据传输方法的步骤。
CN202011601774.1A 2020-12-30 2020-12-30 一种数据传输方法、装置及存储介质 Active CN112770072B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011601774.1A CN112770072B (zh) 2020-12-30 2020-12-30 一种数据传输方法、装置及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011601774.1A CN112770072B (zh) 2020-12-30 2020-12-30 一种数据传输方法、装置及存储介质

Publications (2)

Publication Number Publication Date
CN112770072A true CN112770072A (zh) 2021-05-07
CN112770072B CN112770072B (zh) 2022-12-02

Family

ID=75697210

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011601774.1A Active CN112770072B (zh) 2020-12-30 2020-12-30 一种数据传输方法、装置及存储介质

Country Status (1)

Country Link
CN (1) CN112770072B (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113630439A (zh) * 2021-06-30 2021-11-09 网宿科技股份有限公司 实时通信rtc连接方法、服务器及存储介质
CN114531473A (zh) * 2022-02-17 2022-05-24 辽宁向日葵教育科技有限公司 一种基于虚拟仿真引擎的图像实时渲染方法

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150033300A1 (en) * 2013-07-23 2015-01-29 Broadcom Corporation User equipment having web real time communication architecture
CN104821909A (zh) * 2015-04-22 2015-08-05 北京云艾科技有限公司 端对端的数据传输方法和系统
CN107079021A (zh) * 2014-10-21 2017-08-18 统有限责任两合公司 在建立rtc客户端与rtc服务器之间的rtc通信连接时穿越应用层网关防火墙的电信装置和方法
CN108173928A (zh) * 2017-12-26 2018-06-15 北京百度网讯科技有限公司 Udp数据传输的方法、装置、存储介质及终端设备
CN111182257A (zh) * 2020-01-14 2020-05-19 中国平安财产保险股份有限公司 通信组建立方法、装置、计算机设备及存储介质
CN111343083A (zh) * 2020-05-22 2020-06-26 支付宝(杭州)信息技术有限公司 即时通信方法、装置、电子设备及可读存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150033300A1 (en) * 2013-07-23 2015-01-29 Broadcom Corporation User equipment having web real time communication architecture
CN107079021A (zh) * 2014-10-21 2017-08-18 统有限责任两合公司 在建立rtc客户端与rtc服务器之间的rtc通信连接时穿越应用层网关防火墙的电信装置和方法
CN104821909A (zh) * 2015-04-22 2015-08-05 北京云艾科技有限公司 端对端的数据传输方法和系统
CN108173928A (zh) * 2017-12-26 2018-06-15 北京百度网讯科技有限公司 Udp数据传输的方法、装置、存储介质及终端设备
CN111182257A (zh) * 2020-01-14 2020-05-19 中国平安财产保险股份有限公司 通信组建立方法、装置、计算机设备及存储介质
CN111343083A (zh) * 2020-05-22 2020-06-26 支付宝(杭州)信息技术有限公司 即时通信方法、装置、电子设备及可读存储介质

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113630439A (zh) * 2021-06-30 2021-11-09 网宿科技股份有限公司 实时通信rtc连接方法、服务器及存储介质
CN113630439B (zh) * 2021-06-30 2023-05-05 网宿科技股份有限公司 实时通信rtc连接方法、服务器及存储介质
CN114531473A (zh) * 2022-02-17 2022-05-24 辽宁向日葵教育科技有限公司 一种基于虚拟仿真引擎的图像实时渲染方法

Also Published As

Publication number Publication date
CN112770072B (zh) 2022-12-02

Similar Documents

Publication Publication Date Title
Karpisek et al. WhatsApp network forensics: Decrypting and understanding the WhatsApp call signaling messages
White et al. A firewall concept for both control-flow and data-flow in regression integration testing
US8788805B2 (en) Application-level service access to encrypted data streams
Wang et al. Censorspoofer: asymmetric communication using ip spoofing for censorship-resistant web browsing
US9369491B2 (en) Inspection of data channels and recording of media streams
US8549614B2 (en) Establishing internet protocol security sessions using the extensible messaging and presence protocol
CN112770072B (zh) 一种数据传输方法、装置及存储介质
US20140337967A1 (en) Data Transmission Method, System, and Apparatus
CN111343083B (zh) 即时通信方法、装置、电子设备及可读存储介质
US11108814B2 (en) Distributed denial of service mitigation for web conferencing
Emmanuel et al. A peer-to-peer architecture for real-time communication using Webrtc
CN108989486B (zh) 一种通信方法及通信系统
CN112165494A (zh) 报文分析方法、装置、电子设备及存储介质
EP3714587B1 (en) Method and apparatus for improving privacy of communications through channels having excess capacity
Chatterjee et al. SIP-based enterprise converged networks for voice/video-over-IP: implementation and evaluation of components
CN114826748B (zh) 基于rtp、udp及ip协议的音视频流数据加密方法和装置
CN108270717B (zh) VoIP通信方法、设备及通信系统
CN102185827A (zh) 一种voip系统中语音穿透防火墙的方法
Muranyi et al. Identity management in WebRTC domains
Koistinen Tietoturvan toteutus ja arviointi verkkopohjaiseen reaaliaikaiseen kommunikointiin tarkoitetussa yhdyskäytävässä
Ott Implementation and Evaluation of Security on a Gateway for Web-based Real-Time Communication
Chavhan et al. Multiple design patterns for voice over IP security
Li Large-Scale Measurement of Real-Time Communication on the Web
Sjöström Detecting SQL Injection Attacks in VoIP using Real-time Deep Packet Inspection: Can a Deep Packet Inspection Firewall Detect SQL Injection Attacks on SIP Traffic with Reasonable Performance?
DE102006047650A1 (de) Kryptographische Berechnungen für VoIP-Verbindung

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