CN117411991A - 基于无流量网络的视频通话方法 - Google Patents
基于无流量网络的视频通话方法 Download PDFInfo
- Publication number
- CN117411991A CN117411991A CN202311387054.3A CN202311387054A CN117411991A CN 117411991 A CN117411991 A CN 117411991A CN 202311387054 A CN202311387054 A CN 202311387054A CN 117411991 A CN117411991 A CN 117411991A
- Authority
- CN
- China
- Prior art keywords
- protocol
- video
- network
- audio
- transmission
- 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
- 238000000034 method Methods 0.000 title claims abstract description 60
- 230000005540 biological transmission Effects 0.000 claims abstract description 74
- 230000006854 communication Effects 0.000 claims abstract description 45
- 238000004891 communication Methods 0.000 claims abstract description 44
- 230000011664 signaling Effects 0.000 claims abstract description 44
- 230000008569 process Effects 0.000 claims abstract description 38
- 238000012545 processing Methods 0.000 claims description 25
- 238000005516 engineering process Methods 0.000 claims description 15
- 239000000872 buffer Substances 0.000 claims description 12
- 238000005538 encapsulation Methods 0.000 claims description 6
- 230000003139 buffering effect Effects 0.000 claims description 4
- 230000007246 mechanism Effects 0.000 claims description 4
- 229920002776 polycyclohexyl methacrylate Polymers 0.000 claims description 4
- 238000001228 spectrum Methods 0.000 claims description 4
- 238000012858 packaging process Methods 0.000 claims description 2
- 230000009286 beneficial effect Effects 0.000 description 8
- 238000007726 management method Methods 0.000 description 7
- 238000010586 diagram Methods 0.000 description 3
- 230000000977 initiatory effect Effects 0.000 description 3
- 239000008186 active pharmaceutical agent Substances 0.000 description 2
- 238000006243 chemical reaction Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 230000003044 adaptive effect Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000014759 maintenance of location Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 238000005070 sampling Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N7/00—Television systems
- H04N7/14—Systems for two-way working
- H04N7/141—Systems for two-way working between two video terminals, e.g. videophone
- H04N7/147—Communication arrangements, e.g. identifying the communication as a video-communication, intermediate storage of the signals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- 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/10—Architectures or entities
- H04L65/1045—Proxies, e.g. for 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/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1108—Web based protocols, e.g. webRTC
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明涉及基于无流量网络的视频通话方法，包括S1：建立支持视频数据包传输的运营商电话网的IMS网络；S2：开发软交换系统，通过使用SIP协议完成在话务服务架构之间的信令交换，实现了传统电路交换转换为基于IP网络的数据交换；S3：在话务服务架构中的浏览器中实现SIP协议的功能的基础上，浏览器可以使用WebSocket Secure协议与SIP服务器进行信令交换；S4：通过RTP协议实现通话过程中音视频媒体数据的传输；S5：基于DTLS‑SRTP协议，在浏览器和IMS网络之间实现音视频数据实时、安全传输；从而在无流量网络的情况下，保证了视频通话的正常进行，从而满足用户对于更丰富通信方式的需求。
Description
技术领域
本发明属于数据业务技术领域，尤其涉及基于无流量网络的视频通话方法。
背景技术
在传统的网络环境下，视频通话通常需要APP，小程序或浏览器进行发起和接收，还需要较高的带宽和稳定的网络连接。然而，在无流量网络的情况下，传统的视频通话方式往往无法正常工作；在无流量网络的情况下，只能进行传统的音频通话方式，而音频通话方式只能够提供声音的传输，无法满足用户对于更丰富通信方式的需求。
发明内容
有鉴于此，本发明的目的在于提供基于无流量网络的视频通话方法，以解决现有技术中在无流量网络的情况下，只能进行传统的音频通话方式，而无法进行视频通话的技术问题。
为实现上述目的，本发明基于无流量网络的视频通话方法所采用的技术方案是：
基于无流量网络的视频通话方法，包括以下步骤：
S1：建立支持视频数据包传输的运营商电话网的IMS网络；
在无流量网络的情况下，终端向运营商电话网提出视频通话请求，运营商电话网的IMS网络允许视频数据包传输，为运营商电话网进行视频通话打下基础；
S2：开发软交换系统，通过使用SIP协议完成在话务服务架构之间的信令交换，实现了传统电路交换转换为基于IP网络的数据交换；
S3：在话务服务架构中的浏览器中实现SIP协议的功能的基础上，浏览器可以使用WebSocket Secure连接与SIP服务器进行信令交换；
结合了SIP协议和WebSocket Secure协议的技术原理，为浏览器提供了与SIP服务器进行实时通信的能力；
S4：通过RTP协议实现通话过程中音视频媒体数据的传输；
在视频通话完成信令交换后，开始进行视频通话，通过RTP协议将音视频数据按照标准化方式分隔成小的数据包，并对数据包进行传输和接收；在视频传输过程中提供实时传输所需的低延迟和高带宽效率；
S5：基于DTLS-SRTP协议，在浏览器和IMS网络之间实现音视频数据实时、安全传输；
在发送端和接收端实现DTLS协议的实时传输功能，而且SRTP协议的加密、认证和序列号处理功能，使发送端和接收端能够对音视频数据进行保护和处理。
有益效果：本发明的基于无流量网络的视频通话方法，通过运营商电话网的IMS网络的建立，实现了运营商电话网能够传输视频数据，为无流量网络情况下进行视频通话打下基础；另外，软交换系统的开发，能够通过使用SIP协议完成在话务服务架构之间的信令交换，实现了传统电路交换转换为基于IP网络的数据交换；不仅如此，在浏览器与SIP服务器之间通过WebSocket Secure协议进行信令交换，从而保证了浏览器与SIP服务器之间实时通信的能力，进一步加强了话务服务架构之间的信令交换。通过RTP协议保证了视频通话过程中音视频媒体数据的传输，且DTLS-SRTP协议保证了浏览器和IMS网络之间音视频数据传输的实时性和安全性，从而在无流量网络的情况下，保证了视频通话的正常进行，从而满足用户对于更丰富通信方式的需求。
进一步的，S1中，运营商电话网的IMS网络包括LTE网络和NR技术，NR技术拥有更高的频谱效率和网络利用率，且能够支持与LTE网络之间进行平滑切换；LTE网络支持3GHz以下的频段，NR技术将IMS网络中的频段扩展到6GHz以下，以及24.25-52.6GHz区间；从而保证运营商电话网支持视频数据包的传输。
有益效果：改进后的运营商电话网的IMS网络不仅能够支持3GHz以下的频段的音视频数据传输，而且还支持6GHz以下，以及24.25-52.6GHz区间频段的音视频数据传输，从而保证了IMS网络支持视频数据包的传输，为在运营商电话网的IMS网络上进行视频通话打下基础。
在实施软交换过程中，首先搭建话务服务架构；其次，进行呼叫路由；再者，软交换处理呼叫媒体流，对媒体流进行编解码、传输、保存和处理；最后，软交换需要进行用户管理，用户管理包括用户的注册、认证和权限控制。
有益效果：通过软交换的实施，将传统电路交换转换为基于IP网络的数据交换，提供了灵活性、可扩展性和成本效益的优势。同时，软交换使用SIP协议进行信令交换，提供了一种灵活的方式来管理呼叫的建立、终止和修改，并支持多种媒体类型，如语音、视频和即时消息。
进一步的，所述软交换系统包括信令服务处理子系统、媒体服务子系统和数据库服务处理子系统，信令服务处理子系统负责呼叫的信令交换，媒体服务处理子系统负责通话过程中的媒体流，数据库服务处理子系统用来存储用户信息和呼叫记录。软交换通过使用SIP协议完成信令交换，实现了基于IP网络的电话呼叫处理。
有益效果：软交换系统不仅能够进行信令处理，还能够对媒体流进行编解码、传输、保存和处理，而且，软交换还能够提供灵活的用户管理功能，从而提供个性化的呼叫服务和安全的通信环境。
所述WebSocket Secure协议是基于TLS（Transport Layer Security）的安全协议，它允许浏览器和服务器之间进行双向的实时通信，WebSocket Secure协议使用TLS协议进行安全通信，可以保护信令数据的机密性和完整性；浏览器和SIP服务器可以使用身份验证机制。
有益效果：可以有效的保护信令数据的机密性和完整性，实现了浏览器与SIP服务器之间的信令交换，为浏览器提供了与SIP服务器记性实时通信的能力。
在音视频媒体传输过程中，采用RTP协议与UDP（User Datagram Protocol）协议结合，UDP提供了无连接的传输方式，适合实时传输的要求，提供较低的延迟和较高的带宽效率；RTP协议保证数据包的可靠性和顺序性。
有益效果：保证了视频通话过程中，在保证数据包传输的可靠性和顺序性的同时，还能够保证音视频数据传递具有较低的延迟和较高的带宽效率。
进一步的，RTP协议需要对数据包进行封装和解封装；封装过程将音视频数据分割成小的数据包，并为每个数据包添加RTP头部信息；RTP头部信息包括版本号、负载类型、序列号、时间戳等；解封装过程则是根据RTP头部信息将数据包重新组装成音视频数据；RTP协议需要对数据包进行传输和接收，传输过程将封装好的RTP数据包通过UDP协议发送到目标地址，接收过程则是在目标地址接收RTP数据包，接收端根据时间戳和序列号对接收到的数据包进行排序和重组，保证音视频数据的连续性和正确性。
有益效果：通过RTP协议实现音视频媒体数据的传输涉及到确定编码格式、选择传输协议、封装和解封装数据包、传输和接收数据包以及同步和控制等多个方面的原理和实现方案。这种实践可以提供实时传输所需的低延迟和高带宽效率。
进一步的，视频通话过程中，音频数据和视频数据均通过抖动缓冲器维护，抖动缓冲器通过缓冲和调整数据包的发送时间，有效地处理抖动问题，提供更稳定、连续的音视频数据流；视频通话过程中，音频数据编码格式为PCMA，视频编码格式为H.264，在视频通话过程中，采用RTCP和INFO信令两种处理方式，用来发送H.264关键帧。
有益效果：抖动缓冲器能够处理网络传输中抖动（jitter）问题；采用了RTCP和INFO信令两种处理方式，用于发送H.264关键帧，这两种方式可以有效的解决通话开始一段时间内收不到画面问题。
附图说明
图1是本发明的运营商电话网的IMS网络结构图；
图2是本发明的话务服务架构图；
图3是本发明的通话流程图。
附图标记：1-终端；2-运营商网络；3-SIP服务器；4-负载；5-话务平台；6-互联网终端。
具体实施方式
下面结合附图及具体实施方式对本发明基于无流量网络的视频通话方法作进一步详细描述：
在传统的移动通信网络中，音频通信主要通过电话网进行，而互联网上的音频通信相对独立，本发明通过将移动终端与运营商网络进行结合，实现了移动终端通过运营商电话网进行音视频通信的互联互通，也即，用户能够通过移动终端使用运营商电话网进行高质量的音视频通话。
为了便于理解本发明，对于本发明基于无流量网络的视频通话涉及到的协议具体介绍如下：
SIP（Session initialization Protocol，会话初始协议）是一种信令协议，用于启动，维护和终止用于语音，视频和消息传递的通信会话。SIP是一种源于互联网的IP 语音会话控制协议，主要用于互联网电话，专用IP电话系统以及LTE移动电话呼叫(VoLTE)。
SDP（Session Description Protocol，会话描述协议）。SDP是一种用来描述多媒体通信会话的格式。用来在结点之间协商网络指标，媒体类型和其他关联属性。其中SIP建立和维护会话，其会话的媒体类型，参数通常是由会话描述协议(SDP)所指定。
RTP全名是Real-time Transport Protocol（实时传输协议）。它是IETF提出的一个标准，对应的RFC文档为RFC3550（RFC1889为其过期版本）。RFC3550不仅定义了RTP，而且定义了配套的相关协议RTCP（Real-time Transport ControlProtocol，即实时传输控制协议）。RTP用来为IP网上的语音、图像、传真等多种需要实时传输的多媒体数据提供端到端的实时传输服务。RTP为Internet上端到端的实时传输提供时间信息和流同步，但并不保证服务质量，服务质量由RTCP来提供。RTCP主要功能是通过定期向会话参与者发送统计信息，来提供有关媒体分发中服务质量的反馈，它与RTP合作交付和打包所媒体数据。
SRTP安全实时传输协议（或SRTP）是在实时传输协议（Real-time TransportProtocol或RTP）基础上所定义的一个协议，旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。SRTP就像DTLS一样，是用于WebRTC技术的安全协议之一，且在设计上比较灵活，适应了许多新的加密算法。
H.264，同时也是MPEG-4第十部分，是由ITU-T视频编码专家组（VCEG）和ISO/IEC动态图像专家组（MPEG）联合组成的联合视频组（JVT，Joint Video Team）提出的高度压缩数字视频编解码器标准。这个标准通常被称之为H.264/AVC（或者AVC/H.264或者H.264/MPEG-4 AVC或MPEG-4/H.264 AVC）而明确的说明它两方面的开发者。H.264较之于前身MPEG-2，具有改进错误并进行恢复，运动估计能力，因此能够在低数据速率产生高质量，其效率是MPEG-2编解码器的两倍。
STUN是一种解决P2P应用NAT穿越问题的常用技术。它允许网络设备找出通信端点经NAT设备后的IP地址和端口号，并利用这些信息在通信双方之间建立一条可以穿越NAT设备的数据通道，实现P2P通信。
WebRTC（Web Real-Time Communication）是一个谷歌开源项目，它提供了一套标准 API，使 Web 应用可以直接提供实时音视频通信功能，不再需要借助任何插件。原生通信过程采用 P2P 协议，数据直接在浏览器之间交互，理论上不需要服务器端的参与。
抖动缓冲器（JitterBuffer）是一种用于处理网络传输中抖动（jitter）问题的缓冲器。在实时音视频通信中，由于网络延迟和传输不稳定性等原因，接收到的数据包的到达时间可能会有所不同，导致抖动现象。抖动会对音视频质量产生负面影响，例如声音断断续续或视频画面卡顿。JitterBuffer通过缓冲和调整数据包的发送时间，有效地处理抖动问题，提供更稳定、连续的音视频数据流，从而改善通信质量和用户体验。
DTLS（Datagram Transport Layer Security）是一种基于UDP的安全传输协议，它建立在传输层之上，为实时通信提供端到端的安全性。DTLS使用公钥加密和数字证书来确保通信的机密性和身份验证。它通过握手过程来建立安全连接，并使用对称加密算法来加密和解密数据。通过使用DTLS来为SRTP提供可靠的密钥，实时音视频通信可以在不安全的网络环境中进行，同时保护数据的机密性和完整性。
本发明的基于无流量网络的视频通话方法包括以下步骤：
S1：建立支持视频数据包传输的运营商电话网的IMS网络。
在无流量网络的情况下，终端向运营商电话网提出视频通话请求，运营商电话网的IMS网络允许视频数据包传输，为运营商电话网进行视频通话打下基础。
在传统的IMS网络中，主要用于语音通信，本发明中为了在运营商电话网进行音视频通话，对IMS网络进行改进，使IMS网络能够同时支持对音频和视频数据的传输。
IMS代表IP多媒体子系统，是一种与4G和5G移动核心网集成的网络架构，可实现基于IP的实时服务，包括传统的语音/视频通话、短信（SMS）和彩信（MMS）。
在步骤S1中，如图1所示，运营商电话网的IMS网络包括LTE网络和NR技术，NR技术拥有更高的频谱效率和网络利用率，且能够支持与LTE网络之间进行平滑切换；LTE网络支持3GHz以下的频段，NR技术将IMS网络中的频段扩展到6GHz以下，以及24.25-52.6GHz区间；从而保证运营商电话网支持视频数据包的传输。
视频通话通常需要较高的带宽和较低的延迟，而电路交换的传输方式无法提供足够的带宽和低延迟来支持高质量的视频传输，4G VoLTE技术是基于IMS的语音业务，VoLTE允许语音服务在交付时采用LTE数据承载器内的数据流的形式。这样做的结果是不需要传统的电路交换机网络，并且允许比2G和3G网络更多的语音和数据容量。
5G 引入新无线电技术NR，拥有具有更高的频谱效率和网络利用率，且支持与LTE网络之间进行平滑的切换，LTE只支持3GHz以下的频段，NR扩展到6GHz以下，以及毫米波24.25-52. 6GHz，确保频率范围全球可用，且主要频率范围为 3.4 GHz 至 4 GHz 和26GHz 至 44 GHz。因此5G技术具有更高的容量和连接密度，更低的延迟，可以获得更好地视频通话体验。
S2：开发软交换系统，通过使用SIP协议完成在话务服务架构之间的信令交换，实现了传统电路交换转换为基于IP网络的数据交换。
软交换是一种基于软件的电话交换系统，通过使用SIP（Session InitiationProtocol）协议完成信令交换；也即，软交换系统的实施为SIP协议及其他协议、媒体流、数据库信息等在运营商电话网与互联网之间的顺利实施提供了路径。软交换将传统的电路交换转换为基于IP网络的数据交换，提供了灵活性、可扩展性和成本效益的优势。软交换系统保证了SIP协议及其他协议、媒体流、数据库信息在运营商电话网与互联网之间的顺利运行。
在实施软交换过程中，首先搭建话务服务架构；本实施例中，如图2所示，话务服务架构包括呼叫终端1（例如手机）、运营商网络2、SIP服务器3、负载4、话务平台5（话务平台包括多个话务）、互联网终端6（手机或者电脑）或者浏览器。运营商网络2与互联网之件通过SIP协议完成信令交换，从而使呼叫终端1与互联网终端6（手机或者电脑）能够实现电话呼叫功能。
软交换系统包括信令服务处理子系统、媒体服务子系统和数据库服务处理子系统，信令服务处理子系统负责呼叫的信令交换，媒体服务处理子系统负责通话过程中的媒体流，数据库服务处理子系统用来存储用户信息和呼叫记录。
其次，软交换需要进行呼叫路由；呼叫路由是选择合适的路由进行呼叫转发的过程，呼叫路由可以基于多种因素进行选择，如呼叫目的地、呼叫的优先级和网络负载情况。通过智能的路由算法，软交换能够实现呼叫的高效转发和负载均衡。
再者，软交换还需要处理呼叫媒体流，对媒体流进行编解码、传输、保存和处理，以确保呼叫的质量、留存和稳定性；
最后，软交换需要进行用户管理，用户管理包括用户的注册、认证和权限控制。软交换能够通过用户数据库来存储和管理用户信息，以便进行呼叫的身份验证和权限控制。通过灵活的用户管理功能，软交换能够提供个性化的呼叫服务和安全的通信环境。
开发软交换通过使用SIP协议完成运营商电话网与互联网之间的信令交换，实现了基于IP网络的电话呼叫处理。它涉及到服务器架构、SIP协议、呼叫路由、媒体处理和用户管理等多个方面的远离和实现方案。这种软交换系统具有灵活性、可扩展性和成本效益的优势，逐渐取代了传统的电路交换系统。
S3：在话务服务架构中的浏览器中实现SIP协议的功能的基础上，浏览器可以使用WebSocket Secure协议与SIP服务器进行信令交换。
结合了SIP协议和WebSocket Secure协议的技术原理，为浏览器提供了与SIP服务器进行实时通信的能力。
技术原理方面，SIP协议和WebSocket Secure协议的基本原理不同，SIP协议是一种应用层协议，用于建立、修改和终止多媒体会话。它使用文本格式的消息进行通信，包括请求消息和响应消息。SIP协议通常使用UDP或TCP作为传输层协议。
WebSocket Secure协议是基于TLS（TransportLayer Security）的安全协议，它允许浏览器和服务器之间进行双向的实时通信，WebSocket Secure协议使用TLS协议进行安全通信，可以保护信令数据的机密性和完整性；浏览器和SIP服务器可以使用身份验证机制。
在实现方案方面，由于在浏览器中已经实现了SIP协议的功能，本方案使用JavaScript库JsSIP，来实现SIP协议的功能。这些库提供了SIP协议的解析、封装和处理功能，使浏览器能够与SIP服务器进行通信。
在此基础上，在浏览器和SIP服务器之间建立WebSocket Secure连接。浏览器可以使用WebSocket API来创建WebSocket Secure连接，并通过TLS协议进行安全通信。在建立连接之前，浏览器需要与SIP服务器进行握手，验证服务器的身份，并升级到WebSocket协议。
接下来，浏览器可以使用WebSocket Secure连接与SIP服务器进行信令交换。浏览器可以发送SIP请求消息到SIP服务器，并接收SIP响应消息。通过WebSocket Secure连接，浏览器和SIP服务器可以实现实时的信令交换，包括呼叫的建立、终止和修改。
此外，还需要考虑安全性和身份验证的问题。WebSocket Secure协议使用TLS协议进行安全通信，可以保护信令数据的机密性和完整性。另外，浏览器和SIP服务器可以使用身份验证机制，如基于令牌的身份验证或基于证书的身份验证，来确保通信的安全性和合法性。
总结起来，基于WebSocket Secure的SIP协议实现和浏览器的信令交换结合了SIP协议和WebSocket Secure协议的技术原理。通过在浏览器中实现SIP协议的功能，并使用WebSocket Secure连接与SIP服务器进行实时通信，可以实现浏览器与SIP服务器之间的实时信令交换，为浏览器提供了与SIP服务器进行实时通信的能力，适用于WebRTC应用、在线会议等场景。
S4：通过RTP协议实现通话过程中音视频媒体数据的传输。
在视频通话完成信令交换后，开始进行视频通话，通过RTP协议将音视频数据按照标准化方式分隔成小的数据包，并对数据包进行传输和接收；在视频传输过程中提供实时传输所需的低延迟和高带宽效率。
在实现方案中，通过SIP信令中携带的SDP消息来确定音视频数据的编码格式和采样率。常见的音频编码格式包括PCMA、PCMU、MP3等，而常见的视频编码格式包括H.264、VP9、AV1等。本方案采用的音频数据编码格式为PCMA，采用的视频编码格式为H.264。
RTP通常与UDP（User Datagram Protocol）协议结合使用，因为UDP提供了无连接的传输方式，适合实时传输的要求。提供较低的延迟和较高的带宽效率。
然后，需要进行RTP数据包的封装和解封装。封装过程将音频数据分割成小的数据包，并为每个数据包添加RTP头部信息。RTP头部信息包括版本号、负载类型、序列号、时间戳等。解封装过程则是根据RTP头部信息将数据包重新组装成音视频数据。RTP协议保证数据包的可靠性和顺序性。
此外，还需要进行RTP数据包的传输和接收。传输过程将封装好的RTP数据包通过UDP协议发送到目标地址。接收过程则是在目标地址接收RTP数据包，并根据头部信息进行解封装和处理。接收端可以根据时间戳和序列号对接收到的数据包进行排序和重组，以保证音视频数据的连续性和正确性。
最后，保证实时媒体流的同步和控制。在媒体流传输过程中，可能存在音频和视频的抖动问题。为了解决这个问题，本实施例中，为音频数据和视频数据均维护着一个抖动缓冲器（JitterBuffer），用来处理网络传输中抖动问题。
在实时音视频通信中，由于网络延迟和传输不稳定等原因，接收到的数据包的到达时间可能会有所不同，导致抖动现象。抖动会对音视频质量产生负面影响，例如声音断断续续或视频画面卡顿，JitterBuffer通过缓冲和调整数据包的发送时间，有效地处理抖动问题，提供更稳定、连续的音视频数据流，从而改善通信质量和用户体验。
在视频传输过程中，因H.264的编码方式和通话建立顺序的原因，会存在视频通话开始前收不到对方画面现象。为了解决这个问题，本方案采用了RTCP和INFO信令两种处理方式，用于发送H.264关键帧，这两种方式可以有效的解决通话开始一段时间内收不到画面问题。
本实施例中，通过RTP协议实现音视频媒体数据的传输涉及到确定编码格式、选择传输协议、封装和解封装数据包、传输和接收数据包以及同步和控制等多个方面的原理和实现方案。满足实时传输所需要的低延迟和高带宽效率，适用于音视频通信好、媒体流等应用场景。
S5：基于DTLS-SRTP协议，在浏览器和IMS网络之间实现音视频数据实时、安全传输。
在发送端和接收端实现DTLS协议的实时传输功能，而且SRTP协议的加密、认证和序列号处理功能，使发送端和接收端能够对音视频数据进行保护和处理。
DTLS-SRTP实现音视频媒体数据的传输是一种常见的实践，它结合了DTLS和SRTP协议的技术原理，为音视频传输提供了安全性和可靠性。
技术原理方面，DTLS是基于TLS协议的一种实时传输协议，用于保护数据在不可靠的传输层协议（UDP）上的安全性。SRTP是一种安全的实时传输协议，用于保护音视频数据的机密性、完整性和抗重放攻击。
在实现方案方面，首先，选取开源库OpenSSL，来实现DTLS协议的功能。这些库提供了DTLS协议的解析、封装和处理功能，使发送端和接收端能够进行DTLS握手和密钥协商。
其次，需要在发送端和接收端实现SRTP协议的功能。本实施例采用自主实现SRTP加解密代码来实现SRTP协议的功能。SRTP加解密的实现提供了SRTP协议的加密、认证和序列号处理功能，使发送端和接收端能够对音视频出具进行保护和处理。
接下来，需要在发送端和接收端之间建立DTLS连接，发动端和接收端通过DTLS握手过程建立安全的传输通道，并协商加密算法和密钥。一旦建立DTLS连接，发送端能够将音视频数据进行加密和认证，并通过SRTP协议进行传输。接收端接收并解密音视频数据，并进行相应的处理和传输。
此外，还需要考虑安全性和可靠性的问题。DTLS-SRTP协议使用DTLS协议保护传输通道的安全性，使用SRTP协议保护音视频数据的安全性。通过加密、认证和序列号处理，能够确保音视频数据在传输过程中的机密性、完整性和抗重放攻击能力。
总结起来，通过DTLS和SRTP协议实现音视频媒体数据的传输结合了DTLS和SRTP协议的技术优点。通过在发送端和接收端实现DTLS和SRTP协议的功能，并建立DTLS连接，可以实现安全可靠的音视频传输。这种实践为音视频通信、实时流媒体等应用场景提供了安全性和可靠性的保障。
本发明中的通话流程如图3所示，首先主叫终端发出通话请求，负载接收通话请求并将通话请求发送至话务平台，话务平台再向负载发送认证请求，认证请求通过负载发送至主叫终端，主叫终端确认认证请求，并将确认信息经过负载发送至话务平台。接下来话务平台向负载发送手机号账户认证，然后经过负载将通话SIP流程发送至被叫终端，被叫终端向负载发送手机号响铃，负载将手机号响铃发送至话务平台，话务平台对负载发送会话进行，负载向主叫终端发送会话进行，然后被叫终端向负载发动会话接通通知，并将会话接通发送至主叫终端，至此，主叫终端与被叫终端之间会话接通，然后在主叫终端与被叫终端之间进行RTP媒体流传输，直至被叫终端向负载发送会话结束请求，并最终在主叫终端与被叫终端之间结束会话。
本发明中，移动终端用户能够在传统的电话网环境下实现与其他用户的实时视频通话，这种扩展的通信方式不仅提供了更直观、更丰富的沟通方式，还增强了用户之间的交流效果和沟通体验。同时，方案的实施也为运营商提供了增值服务的机会，提升了用户满意度和竞争力。
本发明通过优化视频传输算法，使用适应性编码技术和利用VoLTE/VoNR技术，使得在无流量网络的情况下，仍然能够进行视频通话。用户通过电话原生通道入口进行拨号，这样，用户能够在没有流量的情况下，通过运营商网络与互联网终端（手机或者电脑）进行视频通话。
Claims (8)
1.基于无流量网络的视频通话方法，其特征是，包括以下步骤：
S1：建立支持视频数据包传输的运营商电话网的IMS网络；
在无流量网络的情况下，终端向运营商电话网提出视频通话请求，运营商电话网的IMS网络允许视频数据包传输，为运营商电话网进行视频通话打下基础；
S2：开发软交换系统，通过使用SIP协议完成在话务服务架构之间的信令交换，实现了传统电路交换转换为基于IP网络的数据交换；
S3：在话务服务架构中的浏览器中实现SIP协议的功能的基础上，浏览器可以使用WebSocket Secure协议与SIP服务器进行信令交换；
结合了SIP协议和WebSocket Secure协议的技术原理，为浏览器提供了与SIP服务器进行实时通信的能力；
S4：通过RTP协议实现通话过程中音视频媒体数据的传输；
在视频通话完成信令交换后，开始进行视频通话，通过RTP协议将音视频数据按照标准化方式分隔成小的数据包，并对数据包进行传输和接收；在视频传输过程中提供实时传输所需的低延迟和高带宽效率；
S5：基于DTLS-SRTP协议，在浏览器和IMS网络之间实现音视频数据实时、安全传输；
在发送端和接收端实现DTLS协议的实时传输功能，而且SRTP协议的加密、认证和序列号处理功能，使发送端和接收端能够对音视频数据进行保护和处理。
2.根据权利要求1所述的基于无流量网络的视频通话方法，其特征是，其特征是，S1中，运营商电话网的IMS网络包括LTE网络和NR技术，NR技术拥有更高的频谱效率和网络利用率，且能够支持与LTE网络之间进行平滑切换；LTE网络支持3GHz以下的频段，NR技术将IMS网络中的频段扩展到6GHz以下，以及24.25-52.6GHz区间；从而保证运营商电话网支持视频数据包的传输。
3.根据权利要求1或2所述的基于无流量网络的视频通话方法，其特征是，在实施软交换过程中，首先搭建话务服务架构；其次，进行呼叫路由；再者，软交换处理呼叫媒体流，对媒体流进行编解码、传输、保存和处理；最后，软交换需要进行用户管理，用户管理包括用户的注册、认证和权限控制。
4.根据权利要求3所述的基于无流量网络的视频通话方法，其特征是，所述软交换系统包括信令服务处理子系统、媒体服务子系统和数据库服务处理子系统，信令服务处理子系统负责呼叫的信令交换，媒体服务处理子系统负责通话过程中的媒体流，数据库服务处理子系统用来存储用户信息和呼叫记录。
5.根据权利要求1或2所述的基于无流量网络的视频通话方法，其特征是，所述WebSocket Secure协议是基于TLS（Transport Layer Security）的安全协议，它允许浏览器和服务器之间进行双向的实时通信，WebSocket Secure协议使用TLS协议进行安全通信，可以保护信令数据的机密性和完整性；浏览器和SIP服务器可以使用身份验证机制。
6.根据权利要求1或2所述的基于无流量网络的视频通话方法，其特征是，在音视频媒体传输过程中，采用RTP协议与UDP（User Datagram Protocol）协议结合，UDP提供了无连接的传输方式，适合实时传输的要求，提供较低的延迟和较高的带宽效率；RTP协议保证数据包的可靠性和顺序性。
7.根据权利要求6所述的基于无流量网络的视频通话方法，其特征是，RTP协议需要对数据包进行封装和解封装；封装过程将音视频数据分割成小的数据包，并为每个数据包添加RTP头部信息；RTP头部信息包括版本号、负载类型、序列号、时间戳等；解封装过程则是根据RTP头部信息将数据包重新组装成音视频数据；RTP协议需要对数据包进行传输和接收，传输过程将封装好的RTP数据包通过UDP协议发送到目标地址，接收过程则是在目标地址接收RTP数据包，接收端根据时间戳和序列号对接收到的数据包进行排序和重组，保证音视频数据的连续性和正确性。
8.根据权利要求7所述的基于无流量网络的视频通话方法，其特征是，视频通话过程中，音频数据和视频数据均通过抖动缓冲器维护，抖动缓冲器通过缓冲和调整数据包的发送时间，有效地处理抖动问题，提供更稳定、连续的音视频数据流；视频通话过程中，音频数据编码格式为PCMA，视频编码格式为H.264，在视频通话过程中，采用RTCP和INFO信令两种处理方式，用来发送H.264关键帧。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311387054.3A CN117411991A (zh) | 2023-10-25 | 2023-10-25 | 基于无流量网络的视频通话方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311387054.3A CN117411991A (zh) | 2023-10-25 | 2023-10-25 | 基于无流量网络的视频通话方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117411991A true CN117411991A (zh) | 2024-01-16 |
Family
ID=89486621
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311387054.3A Pending CN117411991A (zh) | 2023-10-25 | 2023-10-25 | 基于无流量网络的视频通话方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117411991A (zh) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN118337961A (zh) * | 2024-05-22 | 2024-07-12 | 深圳市友联天美科技有限公司 | 一种可视对讲方法、系统以及门禁机 |
| CN118612194A (zh) * | 2024-08-07 | 2024-09-06 | 海马云（天津）信息技术有限公司 | 连接建立方法与装置、电子设备及存储介质 |
-
2023
- 2023-10-25 CN CN202311387054.3A patent/CN117411991A/zh active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN118337961A (zh) * | 2024-05-22 | 2024-07-12 | 深圳市友联天美科技有限公司 | 一种可视对讲方法、系统以及门禁机 |
| CN118612194A (zh) * | 2024-08-07 | 2024-09-06 | 海马云（天津）信息技术有限公司 | 连接建立方法与装置、电子设备及存储介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7944862B2 (en) | Accelerated session establishment in a multimedia gateway | |
| US7266611B2 (en) | Method and system for improved transcoding of information through a telecommunication network | |
| US20030028643A1 (en) | Method and apparatus for transcoding video and speech signals | |
| CN117411991A (zh) | 基于无流量网络的视频通话方法 | |
| EP1389862A1 (en) | Lawful interception for VoIP calls in IP based networks | |
| CN102387081A (zh) | 一种NAT场景下通信业务QoS保障方法、装置及系统 | |
| US10630656B2 (en) | System and method of encrypted media encapsulation | |
| US8339439B2 (en) | Method of speeding up video recovery of videotelephony after an interruption and mobile terminal and system using the same | |
| US8417942B2 (en) | System and method for identifying encrypted conference media traffic | |
| JP4832959B2 (ja) | 音声通信端末装置、音声通信制御方法および音声通信端末プログラム | |
| US9035993B2 (en) | Method and system for bypassing an anchor point | |
| KR101121230B1 (ko) | Ｓｉｐ 기반 인터넷 전화 서비스 보안 시스템 및 그 방법 | |
| KR100928832B1 (ko) | 광-동축 혼합망에서 ｉｐ 기반 비디오 서비스 시스템 구축장치 및 방법 | |
| CN109672692B (zh) | 一种VoIP通信网络中基于RTP的媒体数据加密方法 | |
| US8605712B1 (en) | Method and apparatus for distributing video with offload engine | |
| Li et al. | Network services and protocols for multimedia communications | |
| Kuwadekar et al. | Real time video adaptation in next generation networks | |
| Nalawade et al. | Efficient IP-based voice & video communication through session initiation protocol (SIP) | |
| Stadler et al. | Simultaneous usage of WLAN and UTRAN for improved multimedia and data applications | |
| KR20200062140A (ko) | 방송 시스템에서 멀티미디어 데이터의 전송 특징 정보 송신 방법 | |
| CN117041610A (zh) | 低延迟直播应用场景下的非对称式sfu媒体网关架构 | |
| Xu et al. | Session mobility based on compensation mechanism | |
| Perkins | Reflections on security options for the real-time transport protocol framework | |
| Esaki et al. | Broadband Internet Applications | |
| STANCU et al. | Universal multimedia information access concept over wireless systems |
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 |