CN100596108C - 数据传输方法及装置 - Google Patents
数据传输方法及装置 Download PDFInfo
- Publication number
- CN100596108C CN100596108C CN200710098164A CN200710098164A CN100596108C CN 100596108 C CN100596108 C CN 100596108C CN 200710098164 A CN200710098164 A CN 200710098164A CN 200710098164 A CN200710098164 A CN 200710098164A CN 100596108 C CN100596108 C CN 100596108C
- Authority
- CN
- China
- Prior art keywords
- depth
- decode algorithm
- code decode
- degree
- module
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了数据传输方法,包括:在检测到数据传输网络状况变化时,选择压缩比适合于当前网络状况的编解码算法,采用所选择的编解码算法进行后续数据传输。本发明还公开了一种数据传输装置,包括:网络状况监测模块、编解码算法调整模块和数据传输模块。本发明提高了数据传输效率。本发明在网络状况变差时,选择压缩比高于当前编解码算法的编解码算法,使得数据传输占用的网络带宽减少,在一定程度上缓解了网络压力,加快了Jitter Buffer深度的收缩速度,减少了通信延迟;在网络状况变好时,选择压缩比低于当前编解码算法的编解码算法,使得传输的数据信息增多,提高了接收数据质量。本发明不需增加任何硬件设施,实现手段简单、易行。
Description
技术领域
本发明涉及数据通信技术领域,具体涉及数据传输方法及装置。
背景技术
随着因特网技术的发展,通过因特网传送语音、视频等信息的应用越来越广泛。在传输语音、视频数据时,为了减少数据传输占用的带宽、加快数据传输速度,要对传输的语音、视频数据报文进行压缩打包处理。
以下以基于因特网协议(IP)的语音(VOIP)传输为例,对通过因特网传输数据的过程进行说明。图1给出了基于因特网协议(IP)的语音(VOIP)传输的典型组网图,如图1所示,VOIP传输的基本原理如下:两台支持会话发起协议(SIP)的IP语音网关接入到因特网上,IP语音网关提供电话端口,主叫侧用户将电话终端直接连接到IP语音网关,由IP语音网关通过SIP协议进行主叫侧到被叫侧呼叫的建立,同时负责将主叫侧的模拟信号转换为数字信号并通过语音编解码算法进行压缩打包,使之成为可以在IP网络上传输的分组语音信息,然后再经IP网络传送到被叫侧IP语音网关,由被叫侧IP语音网关将分组语音数据包还原为可识别的模拟语音信号,并传送给被叫侧电话终端,这样就完成了一个完整的电话终端到电话终端的通信过程。
在语音、视频等数据的传输过程中,恶劣的网络状况会引起网络中数据分组传送速率的异常变化,导致接收端接收的数据包的顺序和间隔与发送端发送数据包的顺序和间隔不一致,甚至导致数据包的丢失或重复接收等,从而造成抖动。为了缓解恶劣的网络状况对数据包产生的不良影响,在终端侧或网关侧通常使用抖动缓冲区(Jitter Buffer)对接收到的数据包缓存并进行预处理,包括:补偿丢失的数据包、调整乱序的数据包、均匀数据包下发速度、丢弃重复序号的数据包,等等。这样可以有效缓解恶劣的网络状况导致的数据抖动,提高接收数据质量。
Jitter Buffer采用的是缓存机制,Jitter Buffer可根据接收到的数据包的相关信息,确定数据包是否发生乱序、丢包、重复接收等,并动态调整自身的深度,以补偿数据包的乱序、丢包、重复接收等。例如:当Jitter Buffer依次接收到序号为4、5、10的数据包时,Jitter Buffer就可得知当前发生丢包,即:数据包6~9丢失,此时Jitter Buffer会将数据包4、5经解压缩处理后播放给用户,而将数据包10继续缓存,直至接收到数据包6~9后,再将数据包6~10经解压缩处理后播放给用户。可以看出,数据包的异常接收情况如:乱序、丢包情况越严重,Jitter Buffer内缓存的数据包的数目就会越多即:Jitter Buffer的深度就会越高,此时,Jitter Buffer将数据包播放给用户的速度就会减慢,从而增加了通信延迟,数据传输效率较低。
同时,当数据包的异常接收情况较少甚至无异常时,Jitter Buffer的深度会减少,此时,Jitter Buffer会及时将接收到的数据播放给用户,但是,在网络状况很好时,网络可以提供更多的带宽给用户传输数据包,但由于现有技术中通信两端在呼叫建立时协商确定语音编解码算法后,将不再更改编解码算法,因此,用户传输数据包占用的带宽将保持不变,带宽利用率较低,从而数据传输效率较低。
发明内容
本发明提供数据传输方法及装置,以提高数据传输效率。
本发明的技术方案是这样实现的:
一种数据传输方法,包括:
在检测到数据传输网络状况变化时,选择压缩比适合于当前网络状况的编解码算法,采用所选择的编解码算法进行后续数据传输。
预先设置数据传输最低要求,所述检测到数据传输网络状况变化为:检测到数据传输网络状况变为不满足数据传输最低要求,
所述选择压缩比适合于当前网络状况的编解码算法为:选择压缩比高于当前采用的编解码算法的新编解码算法。
预先设置抖动缓冲区,所述预先设置数据传输最低要求为:预先设置该抖动缓冲区的深度上限;
所述选择压缩比适合于当前网络状况的编解码算法之前进一步包括:接收到数据包,将该数据包缓存到抖动缓冲区中;
所述检测到数据传输网络状况变为不满足数据传输最低要求为:检测到所述抖动缓冲区的深度变为超过所述深度上限。
预先设置数据传输最高要求,所述检测到数据传输网络状况变化为:检测到数据传输网络状况变为高于数据传输最高要求,
所述选择压缩比适合于当前网络状况的编解码算法为:选择压缩比低于当前采用的编解码算法的新编解码算法。
预先设置抖动缓冲区,所述预先设置数据传输最高要求为:预先设置该抖动缓冲区的深度下限;
所述选择压缩比适合于当前网络状况的编解码算法之前进一步包括:接收到数据包,,将该数据包缓存在抖动缓冲区中;
所述检测到数据传输网络状况变为高于数据传输最高要求为:检测到所述抖动缓冲区的深度变为低于所述深度下限。
预先设置数据传输最低要求和数据传输最高要求,
所述检测到数据传输网络状况变化为:检测到数据传输网络状况由高于数据传输最高要求变为等于数据传输最高要求,或者由低于数据传输最低要求变为等于数据传输最低要求,
所述选择压缩比适合于当前网络状况的编解码算法为:选择压缩比低于在数据传输网络状况不满足数据传输最低要求时采用的编解码算法、而高于在数据传输网络状况高于数据传输最高要求时采用的编解码算法的新编解码算法。
所述选择压缩比适合于当前网络状况的编解码算法之后、采用所选择的编解码算法进行后续数据传输之前进一步包括:将该新编解码算法信息通过重协商消息发送给对端,并收到对端返回的协商成功消息。
所述数据为语音数据,且所述编解码算法为语音编解码算法;
或者,所述数据为视频数据,且所述编解码算法为视频编解码算法。
一种数据传输装置,包括:网络状况监测模块、编解码算法调整模块和数据传输模块,其中:
网络状况监测模块,在监测到数据传输网络状况变化时,向编解码算法调整模块发送调整指示;
编解码算法调整模块,收到调整指示,根据该调整指示选择压缩比适合于当前网络状况的编解码算法,将该编解码算法信息发送给数据传输模块;
数据传输模块,接收编解码算法调整模块发来的编解码算法信息,采用该编解码算法进行后续数据传输。
所述编解码算法调整模块包括:
编解码算法更新模块,在收到网络状况监测模块发来的调整指示时,选择压缩比适合于当前网络状况的编解码算法,将该编解码算法信息携带在重协商指示中发送给呼叫会话模块,收到呼叫会话模块发来的确认指示,将该编解码算法信息发送给数据传输模块;
呼叫会话模块,将编解码算法更新模块发来的编解码算法信息携带在重协商消息中发送给对端,收到对端返回的协商成功消息,向编解码算法更新模块发送确认指示。
所述呼叫会话模块进一步用于,收到对端发来的携带编解码算法信息的重协商消息,确定自身将采用该编解码算法信息对应的编解码算法,向对端返回协商成功消息,同时将该编解码算法信息发送给数据传输模块。
所述网络状况监测模块包括:
深度上限存储模块,存储深度上限,将该深度上限发送给第一深度监测模块;
第一深度监测模块,接收并保存所述深度上限,在用于存储接收数据包的抖动缓冲区的深度变为超过该深度上限时,向编解码算法调整模块发送变差指示;
所述编解码算法调整模块收到所述变差指示,选择压缩比高于当前编解码算法的新编解码算法。
和/或,所述网络状况监测模块包括:
深度下限存储模块,存储深度下限,将该深度下限发送给第二深度监测模块;
第二深度监测模块,接收并保存所述深度下限,在用于存储接收数据包的抖动缓冲区的深度变为低于该深度下限时,向编解码算法调整模块发送变好指示;
所述编解码算法调整模块收到所述变好指示,选择压缩比低于当前编解码算法的新编解码算法。
当所述网络状况监测模块包括深度上限存储模块深度、第一深度监测模块、深度下限存储模块和第二深度监测模块时,
所述第一深度监测模块进一步,在抖动缓冲区的深度由超过深度上限变为等于深度上限时,向编解码算法调整模块发送正常指示;
或者,所述第二深度监测模块进一步,在抖动缓冲区的深度由低于深度下限变为等于深度下限时,向编解码算法调整模块发送正常指示;
所述编解码算法调整模块收到所述正常指示,选择压缩比低于在抖动缓冲区的深度超过深度上限时所采用的编解码算法、而高于在抖动缓冲区的深度低于深度下限时所采用的编解码算法的新编解码算法。
与现有技术相比,本发明在检测到数据传输网络状况发生变化时,选择压缩比适合于当前网络状况的编解码算法,采用所述选择的编解码算法进行后续数据传输,使得所采用的编解码算法的压缩比能够适应网络传输状况的变化,合理利用了网络带宽,从而获得了最佳数据传输效率。具体地,在网络状况不满足数据传输要求时,重新选择一个压缩比高于当前编解码算法的新编解码算法,使得数据传输占用的网络带宽减少,从而在一定程度上缓解了网络压力,加快了通信两端的Jitter Buffer深度的收缩速度,从而减少了通信延迟,提高了数据传输效率;在网络状况高于数据传输要求时,重新选择一个压缩比低于当前编解码算法的新编解码算法,以占用更多的网络带宽,使得传输的数据信息增多,提高了接收到的数据质量。且本发明不需增加任何硬件设施,实现手段简单、易行。
附图说明
图1为现有的VOIP的组网示意图;
图2为本发明实施例提供的进行数据传输的流程图;
图3为本发明实施例提供的实现数据传输的装置组成图。
具体实施方式
下面结合附图及具体实施例对本发明再作进一步详细的说明。
在语音或视频等数据的传输过程中,要对传输的数据报文进行压缩打包处理。一般地,在建立呼叫时,通信两端会协商用于压缩打包的编解码算法。不同的编解码算法的压缩比不同,采用较高的压缩比将会比采用较低的压缩比占用更少的网络带宽,改善网络状况,最终会导致通信两端的Jitter Buffer的深度减少,从而减少通信延迟;而采用较低的压缩比将会使得接收用户获得更多的数据信息,提高接收到的数据的质量。因此,本发明的核心思想是:在数据传输过程中,根据不同的网络状况,采用不同压缩比的编解码算法,以提高数据传输速率。
由于当网络状况变差如:可用带宽减少时,数据接收异常情况会变严重,Jitter Buffer的深度会增加;当网络状况变好如:可用带宽增加时,数据接收异常情况会减轻,Jitter Buffer的深度会减少。因此,可根据Jitter Buffer的深度确定数据传输的异常程度,从而确定网络状况,以选择压缩比适合于当前网络状况的编解码算法。具体地,在监测到Jitter Buffer的深度变为超过预先设定的深度上限时,可确定网络状况不满足数据传输最低要求,重新选择一个压缩比高于当前编解码算法的新编解码算法,以减少数据传输占用的带宽,缓解网络压力,最终会导致数据传输状况变好,Jitter Buffer的深度减少,从而通信延迟减少;在监测到Jitter Buffer的深度变为低于预先设定的深度下限时,确定网络状况高于数据传输最高要求,则重新选择一个压缩比低于当前编解码算法的新编解码算法,以充分利用网络带宽传输更多的数据信息,提高接收到的数据质量。
图2为以语音数据为例,本发明实施例提供的进行语音传输的消息流程时序图,如图2所示,其具体步骤如下:
步骤200:预先在语音通信两端即:主叫端和被叫端上分别设置深度上限和深度下限。
步骤201:主叫端发送呼叫建立(INVITE)消息,该消息中携带了主叫侧支持的语音编解码能力如:G.711算法信息。
步骤202:被叫端收到该INVITE消息后,向主叫端返回100临时响应(Trying)消息,以通知主叫端该路呼叫正在处理,并向主叫端发送180振铃(Ringing)消息,以表示该路呼叫处于振铃状态。
步骤203:被叫端确定呼叫协商完成,通过200响应(OK)消息通知主叫端本次呼叫建立成功,同时将该路呼叫使用的语音编解码算法如:G.711算法信息发送给主叫端。
步骤204:主叫端收到该200OK消息,向被叫端返回确认(ACK)消息。此后,主、被叫进入通话状态。
通话后该路呼叫将采用协商好的语音编解码算法如:G.711算法对传输的语音报文进行压缩打包。
步骤205:主叫端检测到自身的Jitter Buffer的深度变为超过深度上限,则确定网络状况不满足数据传输最低要求,在自身支持的语音编解码算法中,重新选择一个语音编解码算法如:G.723算法,该选择的语音编解码算法的压缩比高于当前采用的语音编解码算法。
步骤206:主叫端向被叫端发送呼叫重建立(ReINVITE)消息,该消息携带重新选择的语音编解码算法如:G.723算法信息。
步骤207:被叫端接收到ReINVITE消息,向主叫端返回100Trying消息,表示正在处理该消息。
步骤208:被叫端确定自身将采用所述重新选择的语音编解码算法,向主叫端返回200OK消息,该消息携带所述重新选择的语音编解码算法如:G.723算法信息。
步骤209:主叫端收到200OK消息,向被叫端返回ACK消息。
此后,主、被叫端采用步骤205中所述重新选择的语音编解码算法如:G.723算法进行语音传输。
步骤210:主叫端检测到自身的Jitter Buffer的深度变为低于深度下限,确定网络状况高于数据传输最高要求,则在自身支持的语音编解码算法中重新选择一个语音编解码算法如:G.711算法,该语音编解码算法的压缩比低于当前采用的语音编解码算法。
步骤211:主叫端向被叫端发送ReINVITE消息,该消息携带重新选择的语音编解码算法如:G.711算法信息。
步骤212:被叫端接收到ReINVITE消息,向主叫端返回100Trying消息,表示正在处理该消息。
步骤213:被叫端确定自身将采用所述重新选择的语音编解码算法,向主叫端返回200OK消息,该消息携带所述重新选择的语音编解码算法如:G.711算法信息。
步骤214:主叫端收到200OK消息,向被叫端返回ACK消息。
此后,主、被叫端采用步骤210中重新选择的语音编解码算法如:G.711算法进行语音传输。
步骤205~209与步骤210~214并无先后之分,只要确定Jitter Buffer的深度变为超过深度上限,则执行步骤205~209;只要确定Jitter Buffer的深度变为低于深度下限,则执行步骤210~214;在实际应用中,步骤205~209与步骤210~214可以结合进行,也可以分别单独进行。
另外,需要指出的是,步骤205~209与步骤210~214中针对的都是主叫端根据Jitter Buffer的深度检测到网络状况的变化,从而发起语音编解码算法重协商的情况,在实际应用中,被叫端也可根据Jitter Buffer的深度检测网络状况的变化,并发起语音编解码算法的重协商过程,具体过程与步骤205~209与步骤210~214类似,只需将205~209与步骤210~214中的“主叫端”替换为“被叫端”,“被叫端”替换为“主叫端”即可。
图2所示实施例中,深度上限的取值可大于深度下限的取值,也可等于深度下限的取值。
可以看出:在图2所示实施例中,只有在Jitter Buffer的深度变为超过深度下限,或者变为低于深度下限时,才进行语音编解码算法的调整。在实际应用中,为了进一步合理利用网络资源,提高语音传输效率,可在JitterBuffer的深度由超过深度上限变为等于深度上限时,和/或由低于深度下限变为等于深度下限时,也对语音编解码算法进行调整,调整后的语音编解码算法的压缩比要高于低于深度下限时所采用的语音编解码算法、而低于超过深度上限时所采用的语音编解码算法。例如:设预先设定的Jitter Buffer的深度上限为Hmax,深度下限为Hmin,设主、被叫端支持的语音编解码算法按照压缩比的从高到低依次为:G.723、G.729、G.711,设主、叫被端在呼叫建立时协商采用的语音编解码算法为:G.729,则主叫端在检测到Jitter Buffer的深度H变为超过Hmax时,与被叫端重协商将编解码算法调整为G.723;此后,若检测到Jitter Buffer的深度由超过Hmax变为Hmax时,则与被叫端重协商将编解码算法调整为G.729;此后,若再检测到Jitter Buffer的深度H变为低于Hmin时,则与被叫端重协商将编解码算法调整为G.711;此后,若再检测到Jitter Buffer的深度由低于Hmin变为Hmin时,则再与被叫端重协商将编解码算法调整为G.729。
以上给出的是将Jitter Buffer的深度划分为三段,为每段深度设置不同压缩比的语音编解码算法的情况。当然,在主、被叫端支持的语音编解码算法多于三种时,也可根据该支持的语音编解码算法的数目,将Jitter Buffer的深度划分为多于三段,为每段深度设置不同压缩比的语音编解码算法,以更加有效地利用网络资源,提高语音传输效率。
图2所示实施例中提到的主、被叫端可以是语音终端,也可以是语音网关。
需要指出的是,图2所示实施例不仅适用于诸如:VOIP数据的传输过程,同样适用于视频数据的传输过程,在进行视频数据传输时,只需将图2所示实施例中的“语音编解码算法”替换为“视频编解码算法”。
图3为本发明实施例提供的实现数据传输的装置组成图,如图3所示,其主要包括:网络状况监测模块31、编解码算法更新模块32、呼叫会话模块33和数据传输模块34,其中:
网络状况监测模块31:用于监测网络状况,当监测到网络状况变为不满足数据传输最低要求时,向编解码算法更新模块32发送网络状况变差指示;当监测到网络状况变为高于数据传输最高要求时,向编解码算法更新模块32发送网络状况变好指示。
具体地,网络状况监测模块31包括:深度上限存储模块311、第一深度监测模块312、深度下限存储模块313和第二深度监测模块314,其中:
深度上限存储模块311:用于存储深度上限,将该深度上限发送给第一深度监测模块312。
第一深度监测模块312:用于保存深度上限存储模块311发来的深度上限,在检测到Jitter Buffer的深度变为超过该深度上限时,确定网络状况变差,向编解码算法更新模块32发送网络状况变差指示。
本发明实施例中,第一深度监测模块312还可以用于,在抖动缓冲区的深度由超过深度上限变为等于深度上限时,向编解码算法更新模块32发送正常指示。
深度下限存储模块313:用于存储深度下限,将该深度下限发送给第二深度监测模块314。
第二深度监测模块314:用于保存深度下限存储模块313发来的深度下限,在检测到Jitter Buffer的深度变为低于该深度下限时,向编解码算法更新模块32发送网络状况变好指示。
本发明实施例中,第二深度监测模块314还可用于,在抖动缓冲区的深度由低于深度下限变为等于深度下限时,向编解码算法更新模块32发送正常指示。
编解码算法更新模块32:用于存储本端支持的编解码算法,接收并存储呼叫会话模块33发来的编解码算法信息,将呼叫会话模块33最近发来编解码算法信息作为本端当前采用的编解码算法信息;当收到网络状况监测模块31发来的网络状况变差指示时,在本端支持的编解码算法中,选择一个压缩比高于当前采用的编解码算法的编解码算法,将该编解码算法信息携带在更新指示中发送给呼叫会话模块33;当收到网络状况监测模块31发来的网络状况变好指示时,在本端支持的编解码算法中选择一个压缩比低于当前采用的编解码算法的编解码算法,将该编解码算法信息发送给呼叫会话模块33。
本发明实施例中,编解码算法更新模块32还可用于,在收到第一深度监测模块312或第二深度监测模块314发来的正常指示时,在本端支持的编解码算法中,选择压缩比低于在抖动缓冲区的深度超过深度上限时所采用的编解码算法、而高于在抖动缓冲区的深度低于深度下限时所采用的编解码算法的新编解码算法,将该编解码算法信息发送给呼叫会话模块33。
呼叫会话模块33:用于在呼叫建立时,与对端协商本次呼叫所采用的编解码算法,将协商确定的编解码算法信息发送给编解码算法更新模块32和数据传输模块34;收到编解码算法更新模块32发来的更新指示,将该更新指示中携带的编解码算法信息携带在ReINVITE消息中发送给对端,收到对端返回的携带更新指示中的编解码算法信息的200OK消息,将所述更新指示携带的编解码算法信息发送给编解码算法更新模块32和数据传输模块34。
本发明实施例中,呼叫会话模块33还可用于,收到对端发来的携带编解码算法信息的ReINVITE消息,确定自身将采用该编解码算法后,向对端返回携带该编解码算法信息的200OK消息,并将该编解码算法信息发送给编解码算法更新模块32和数据传输模块34。
数据传输模块34:用于接收呼叫会话模块33发来的编解码算法信息,采用该编解码算法对要发送的数据报文进行压缩打包,对对端发来的数据包进行解压缩处理。
本发明实施例中的编解码算法更新模块32和呼叫会话模块33可统称为编解码算法调整模块。
图3所示的装置可位于终端侧,也可位于网关侧。
以上所述仅为本发明的过程及方法实施例,并不用以限制本发明,凡在本发明的精神和原则之内所做的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (9)
1、一种数据传输方法,其特征在于,预先设置抖动缓冲区的深度上限和深度下限,包括:
接收到数据包,将该数据包缓存到抖动缓冲区中,在检测到所述抖动缓冲区的深度变为超过所述深度上限时,选择压缩比高于当前采用的编解码算法的新编解码算法,采用新编解码算法进行后续数据传输;在检测到所述抖动缓冲区的深度变为低于所述深度下限时,选择压缩比低于当前采用的编解码算法的新编解码算法,采用新编解码算法进行后续数据传输。
2、如权利要求1所述的方法,其特征在于,所述方法进一步包括:
在检测到所述抖动缓冲区的深度由超过深度上限变为等于深度上限,或者由低于深度下限变为等于深度下限时,选择压缩比低于超过深度上限时采用的编解码算法、而高于低于深度下限时采用的编解码算法的新编解码算法。
3、如权利要求1所述的方法,其特征在于,所述选择压缩比高于当前采用的编解码算法的新编解码算法之后、采用新编解码算法进行后续数据传输之前进一步包括:将该新编解码算法信息通过重协商消息发送给对端,并收到对端返回的协商成功消息。
4、如权利要求1至3任一所述的方法,其特征在于,所述数据为语音数据,且所述编解码算法为语音编解码算法;
或者,所述数据为视频数据,且所述编解码算法为视频编解码算法。
5、一种数据传输装置,其特征在于,包括:深度上限存储模块模块、第一深度监测模块、深度下限存储模块模块、第二深度监测模块、编解码算法调整模块和数据传输模块,其中:
深度上限存储模块,存储深度上限,将该深度上限发送给第一深度监测模块;
第一深度监测模块,接收并保存所述深度上限,在用于存储接收数据包的抖动缓冲区的深度变为超过该深度上限时,向编解码算法调整模块发送变差指示;
深度下限存储模块,存储深度下限,将该深度下限发送给第二深度监测模块;
第二深度监测模块,接收并保存所述深度下限,在用于存储接收数据包的抖动缓冲区的深度变为低于该深度下限时,向编解码算法调整模块发送变好指示;
编解码算法调整模块,收到所述变差指示,根据该变差指示选择压缩比高于当前编解码算法的新编解码算法,将该新编解码算法信息发送给数据传输模块;收到所述变好指示,选择压缩比低于当前编解码算法的新编解码算法,将该新编解码算法信息发送给数据传输模块;
数据传输模块,接收编解码算法调整模块发来的新编解码算法信息,采用该新编解码算法进行后续数据传输。
6、如权利要求5所述的装置,其特征在于,所述编解码算法调整模块包括:
编解码算法更新模块,在收到第一深度监测模块发来的变差指示时,选择压缩比高于当前编解码算法的新编解码算法,将该新编解码算法信息携带在更新指示中发送给呼叫会话模块,接收呼叫会话模块发来的新编解码算法信息,将该新编解码算法信息作为当前采用的编解码算法信息;
呼叫会话模块,将编解码算法更新模块发来的新编解码算法信息携带在重协商消息中发送给对端,收到对端返回的协商成功消息,向编解码算法更新模块和数据传输模块发送该新编解码算法信息。
7、如权利要求6所述的装置,其特征在于,所述呼叫会话模块进一步用于,收到对端发来的携带新编解码算法信息的重协商消息,确定自身将采用该新编解码算法信息对应的编解码算法,向对端返回协商成功消息,同时将该新编解码算法信息发送给编解码算法更新模块和数据传输模块。
8、如权利要求5所述的装置,其特征在于,所述第一深度监测模块进一步,在抖动缓冲区的深度由超过深度上限变为等于深度上限时,向编解码算法调整模块发送正常指示;
所述编解码算法调整模块收到所述正常指示,选择压缩比低于在抖动缓冲区的深度超过深度上限时所采用的编解码算法、而高于在抖动缓冲区的深度低于深度下限时所采用的编解码算法的新编解码算法。
9、如权利要求5所述的装置,其特征在于,所述第二深度监测模块进一步,在抖动缓冲区的深度由低于深度下限变为等于深度下限时,向编解码算法调整模块发送正常指示;
所述编解码算法调整模块收到所述正常指示,选择压缩比低于在抖动缓冲区的深度超过深度上限时所采用的编解码算法、而高于在抖动缓冲区的深度低于深度下限时所采用的编解码算法的新编解码算法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200710098164A CN100596108C (zh) | 2007-04-20 | 2007-04-20 | 数据传输方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200710098164A CN100596108C (zh) | 2007-04-20 | 2007-04-20 | 数据传输方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101035086A CN101035086A (zh) | 2007-09-12 |
CN100596108C true CN100596108C (zh) | 2010-03-24 |
Family
ID=38731398
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN200710098164A Expired - Fee Related CN100596108C (zh) | 2007-04-20 | 2007-04-20 | 数据传输方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN100596108C (zh) |
Families Citing this family (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101237301B (zh) * | 2008-02-22 | 2013-01-23 | 深圳市深信服电子科技有限公司 | 动态数据压缩方法 |
CN102468903A (zh) * | 2010-11-08 | 2012-05-23 | 北京清华城市规划设计研究院 | 污水厂在线数据编码方法、存储方法及传输方法、以及污水厂在线数据采集存储装置 |
US9355613B2 (en) | 2012-10-09 | 2016-05-31 | Mediatek Inc. | Data processing apparatus for transmitting/receiving compression-related indication information via display interface and related data processing method |
CN110190937B (zh) * | 2013-09-29 | 2021-10-22 | 华为技术有限公司 | 一种数据传输的方法及设备 |
CN104753889A (zh) * | 2013-12-31 | 2015-07-01 | 北京大唐高鸿软件技术有限公司 | 利用sip协议实现加密切换的方法 |
CN104539588B (zh) * | 2014-12-09 | 2019-04-12 | 华为技术有限公司 | 一种确定媒体能力的方法及呼叫控制网元 |
CN105812439B (zh) * | 2014-12-31 | 2019-10-25 | 华为技术有限公司 | 一种音频传输方法及装置 |
CN107104813B (zh) | 2016-02-23 | 2020-08-07 | 华为技术有限公司 | 一种信息传输方法、网关及控制器 |
CN106789562B (zh) * | 2016-12-06 | 2021-09-14 | 腾讯科技(深圳)有限公司 | 一种虚拟物品发送方法、接收方法、装置和系统 |
CN108964855B (zh) * | 2017-05-22 | 2022-05-20 | 中兴通讯股份有限公司 | 一种语音信令传输方法和装置 |
CN107426307A (zh) * | 2017-07-11 | 2017-12-01 | 北京潘达互娱科技有限公司 | 数据处理方法及装置 |
CN108712348A (zh) * | 2018-05-18 | 2018-10-26 | 王逸人 | 流量控制方法、系统、设备及计算机可读存储介质 |
CN110875860B (zh) * | 2020-01-20 | 2020-07-10 | 翱捷科技(上海)有限公司 | 一种处理网络抖动的方法及装置 |
CN113645291B (zh) * | 2021-08-04 | 2022-11-18 | 百度在线网络技术(北京)有限公司 | 数据通信方法及装置、电子设备和存储介质 |
CN116209007A (zh) * | 2021-11-29 | 2023-06-02 | 中兴通讯股份有限公司 | 一种数据传输方法、装置、电子设备和计算机存储介质 |
CN117319509A (zh) * | 2022-06-24 | 2023-12-29 | 中兴通讯股份有限公司 | 网络数据处理方法、装置和计算机可读存储介质 |
CN117412083B (zh) * | 2023-11-07 | 2024-05-14 | 南月(广州)机器人科技有限公司 | 一种用于竞技产品教学的物联网视频传输方法 |
-
2007
- 2007-04-20 CN CN200710098164A patent/CN100596108C/zh not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
CN101035086A (zh) | 2007-09-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN100596108C (zh) | 数据传输方法及装置 | |
KR100878391B1 (ko) | 무선 ip 전화기 | |
CN101227482B (zh) | 一种网络电话通话中媒体协商方法、装置及系统 | |
US20080101338A1 (en) | METHODS AND APPARATUS TO IMPLEMENT HIGHER DATA RATE VOICE OVER INTERNET PROTOCOL (VoIP) SERVICES | |
US7020263B2 (en) | Method and apparatus for dynamically allocating bandwidth utilization in a packet telephony system | |
EP1845687B1 (en) | A method for ip-based service transmission | |
EP1551135B1 (en) | Interworking between domains of a communication network operated based on different switching principles | |
US8184616B2 (en) | Changing codec information to provide voice over internet protocol (VoIP) terminal with coloring service | |
JP2005137007A (ja) | 映像送受信帯域幅及び画質制御機能を持つip映像端末装置及びその制御方法 | |
CN100579105C (zh) | 一种数据流处理的方法和装置 | |
CN106856472A (zh) | 基于VoLTE的视频通话方法、装置及移动终端 | |
CN101998537B (zh) | 一种根据网络负荷筛选用户速率的系统及方法 | |
EP1424836B1 (en) | Encoding selection method and terminal apparatus | |
CN101695102B (zh) | 一种传真的方法和无线网关 | |
AU2005200851B2 (en) | PCM-based data transmission system and voice/data communication switching method | |
WO2012063890A1 (ja) | コアネットワークおよび通信システム | |
CN100527740C (zh) | 一种业务切换的方法 | |
CN102045782A (zh) | 一种语音视频用户速率协商的方法及系统 | |
JP4624323B2 (ja) | Ip通信中継装置、ネットワークシステム、中継処理プログラム、および中継方法 | |
US7242718B2 (en) | Coding standard selecting method and terminal device | |
CN101197892B (zh) | 一种移动通信网络中的传真系统和方法 | |
JP2002354537A (ja) | 通信システム | |
WO2023206910A1 (zh) | 基于局域网和广域网的sip对讲方法、系统及存储介质 | |
CN101835203B (zh) | 一种媒体网关处理多帧媒体报文的方法和系统 | |
CN117768579A (zh) | 面向呼叫中心的抗弱网语音编码自适应切换方法、系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CP03 | Change of name, title or address | ||
CP03 | Change of name, title or address |
Address after: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No. Patentee after: Xinhua three Technology Co., Ltd. Address before: 310053 Hangzhou hi tech Industrial Development Zone, Zhejiang province science and Technology Industrial Park, No. 310 and No. six road, HUAWEI, Hangzhou production base Patentee before: Huasan Communication Technology Co., Ltd. |
|
CF01 | Termination of patent right due to non-payment of annual fee | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20100324 Termination date: 20200420 |