CN102006295A - 基于atm承载ip语音的数据压缩方法 - Google Patents
基于atm承载ip语音的数据压缩方法 Download PDFInfo
- Publication number
- CN102006295A CN102006295A CN2010105609427A CN201010560942A CN102006295A CN 102006295 A CN102006295 A CN 102006295A CN 2010105609427 A CN2010105609427 A CN 2010105609427A CN 201010560942 A CN201010560942 A CN 201010560942A CN 102006295 A CN102006295 A CN 102006295A
- Authority
- CN
- China
- Prior art keywords
- packet header
- delete
- data
- header module
- add
- 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
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种基于ATM承载IP语音的数据压缩方法，在接入设备与交换网络之间插入加/删包头模块，通过加/删包头模块对数据包头的删除/还原处理，在源端交换网络和目的端交换网络之间只传递数据净荷。本发明的有益技术效果是：通过对包头的删除/还原处理，避免了在网络中传输包头信息，在网络中仅传输数据的有效净荷，节省了网络带宽。
Description
技术领域
本发明涉及一种通信技术，尤其涉及一种基于ATM承载IP语音的数据压缩方法。
背景技术
IP电话由于具有较高的性价比，得到越来越多的应用。话音经过采样、PCM编码后变成二进制数据，再经过一定的压缩编码技术，形成ip数据包，以适合ip网络的传输带宽。
压缩编码技术比较常用的是G.723.1和G.729编码标准，其目的就是对话音数据进行压缩。编码标准针对的是话音采样后的数据。
话音数据的传输过程是，编码器生成的话音数据被逐层封装成RTP，UDP和IP包，这样的语音帧头部长度最少也达到40B（20ip头+8udp头+12rtp头），而经过压缩编码后的话音数据作为有效载荷也只有几十字节。这样对于一个相同的语音流来说，在连续的语音包中语音帧的头部信息大部分是相同的，也就是冗余度很高。为了降低这种冗余度，必须采用头部压缩技术。
IETF提供了多种包头压缩的标准，cRTP就是最有影响力的一种。他可以将 40B的包头最小压缩至2B 。用 cRTP进行头部压缩,必须维护上下文信息( Context ,即未压缩的在通路两端上一次发送的包头)，这样，头部仅仅携带上下文信息的变化即可。但是如果发生丢包或包被损坏，接收端就无法正确地更新上下文信息。所以必须提供相应的机制去监测上下文错误并去修复他。cRTP可以发送上下文更新请求来修复上下文，但是链路上的往返时间会影响这种修复机制的效率。
发明内容
针对背景技术中存在的问题，本发明提出了一种基于ATM承载IP语音的数据压缩方法，在接入设备与交换网络之间插入加/删包头模块，在源端交换网络和目的端交换网络之间只传递数据净荷；步骤为：
1）lsp隧道建立
2）本端和对端的加/删包头模块传递信息，建立压缩信息数据库；
3）源端接入设备发送的数据传递到源端的加/删包头模块，源端的加/删包头模块根据压缩信息数据库对数据作删除包头处理，然后再将处理后的数据传递到源端交换网络；
4）目的端交换网络将数据传递到目的端的加/删包头模块，目的端的加/删包头模块根据压缩信息数据库对数据作包头复原处理，然后再传递到目的端接入设备。
所述的压缩信息数据库中记录有加/删包头模块对本端的接入设备发来的数据，所作的删除处理的删除内容信息。
所述的加/删包头模块，在lsp隧道建立的同时，本端和对端的加/删包头模块互相交换压缩信息数据库中的信息，并记录在对端的压缩信息数据库中。
本发明的有益技术效果是：通过对包头的删除/还原处理，避免了在网络中传输包头信息，在网络中仅传输数据的有效净荷，节省了网络带宽。
附图说明
图1、端到端话音包头部压缩示意图；
图2、加/删话音包头系统原理图。
具体实施方式
现有技术中，按照MPLS域通常的lsp隧道建立模式为三段式，即：源接入端à交换网络à目的接入端；本发明的改进在于：在接入端和交换网络间增加一段lsp隧道，即：源接入端à加/删包头模块à交换网络à加/删包头模块à目的接入端。这样就保证了数据会流过加删包头模块并被处理：源接入端发送的数据，被删除掉包头后，只有净荷在网络上传递，目的接入端接收到的数据，是经加/删包头模块复原处理后的数据，数据在加/删包头模块中被复原成标准的RTP报文。
上述方案具体来说，为：在接入设备与交换网络之间插入加/删包头模块，加/删包头模块中预置有包头增/删策略；其处理步骤为：
1）源端接入设备发送的数据传递到源端的加/删包头模块，源端的加/删包头模块根据包头增/删策略对数据作删除包头处理，然后再将处理后的数据传递到源端交换网络；
2）源端交换网络将数据传递到目的端交换网络，目的端交换网络将数据传递到目的端的加/删包头模块，目的端的加/删包头模块根据包头增/删策略对数据作包头复原处理，然后再传递到目的端接入设备；
在源端交换网络和目的端交换网络之间只传递数据净荷。
所述的包头增/删策略，包括：加/删包头模块内设置有压缩信息数据库；加/删包头模块对本端的接入设备发来的数据，所作的删除处理的删除内容信息记录在本地的压缩信息数据库中；在lsp隧道建立的同时，本端和对端的加/删包头模块互相交换压缩信息数据库中的信息，并记录在对端的压缩信息数据库中，这就在两端的加/删包头模块中形成了包头增/删策略。也可以采用在两端的加/删包头模块中预置包头增/删策略的方式（即预先写入加/删包头模块需要作的删除内容信息），但这种方式相对烦琐。
加/删包头模块在对数据进行处理时，加/删包头模块中的utopia接口收到的atm信元，要先去掉信元头，取出ATM SDU部分，然后根据信元头中的vpi/vci为索引去查找压缩信息数据库，找到匹配的表项，根据表项中的增删标志来决定是增加还是删除报文头部，增加或删除掉报文头部后，再经过AAL5适配成ATM信元从utopia接口发出。信元流过加/删包头模块前后都是atm信元，不过这个atm信元的净荷已经被改变，是重新适配过的信元。重新适配完成了裸传以及复原，大大节省了带宽。由于重新适配的算法固定，为进一步提高效率，重新适配可以考虑采用FPGA来完成，但要注意时序设计，使FPGA系统时钟与cpu数据总线时钟协调工作。
下文对加/删包头模块的复原处理过程进行阐述。
对ip、udp和rtp的头部帧结构进行分析后，可以发现，ip头部和udp头部的信息复原比较容易，从压缩信息数据库中取出源目的ip地址和源目的端口号，然后按照TCP/IP协议标准进行复原修复就可以了。
RTP头部复原：
RTP 固定头部各部分说明如下：版本：2 bit，即所用的 RTP 版本；P：1 bit，填充位。X：1 bit，扩展位。CC：4 bit，表示紧跟在头部后面的 CSRC 标识的数目。M：1 bit，标记位。如果被设置为 1，则表示这个RTP 包有特殊意义，比如在传输视频流时表示一个帧的开始（或结束）。载荷类型：7 bit，用来指出后面的 RTP 载荷的类型。序列号：16 bit，每发送一个 RTP 包它就增加1，使接收端能够实现收到报文的正确排序，为了增强安全性，它的起始值是随机的。时间戳：32 bit，表示 RTP 包中有效载荷第一个字节的采样时刻，用来消除时延抖动和实现声音与图像的同步，同序列号一样，它的起始值也是随机的。同步源标识：32 bit，用来标识 RTP 流的来源，这个标识符是随机选取的，这是为了避免在同一个 RTP会话期间有两个同步源有同样的标识符。参与源标识：每个32 bit，可有0 ～ 15 个，用来标识来源于不同地点的 RTP 流，包中参与源的数目由 CC给出。
经过分析，我们发现，RTP头部信息中的载荷类型（编码方式，比如H323）、序列号、时间戳和同步源标示是必须要复原的有效信息。其他的可以预先知道或填固定值。
载荷类型：在话音流建立前的信令阶段由通信双方的终端协商，所以建立lsp隧道时该信息是可以获取到从而被加到压缩信息数据库中的。
序列号、同步源标示和时间戳是随机产生的，双方并不协商，既然是随机产生而互相不协商，那么由谁来随机就没有区别，基于这一思想，我们把原来通信终端随机生成的值改由加/删包头模块来随机生成并复原RTP包。
序列号的起始值随机产生后，以后每发送一个RTP包就加1，在ip网络中，由于udp报文不基于连接，所以可能存在后发先至的情况，RTP协议正是基于这一考虑才用序列号来进行标记报文顺序以实现流同步，并启用缓存技术来使编解码器得到连续的报文。由于我们采用的是lsp隧道技术，atm基于可靠连接，所以报文不存在乱序的情况，这样在复原报文时，只需要顺次加1即可。
时间戳的起始值产生后，加删包头模块要启动一个计时器，计算收到这个包与前一个包的时间差，即采样时间。由于加删包头模块收到的是atm信元，就存在一个rtp包被适配到多个信元的情况，所以计时器应认为1ms之内收到的atm信元为同一个rtp包。加删包头模块每次计时这个采样时间，然后叠加到起始值上进行rtp包的复原。
同步源标示标示了一个话音流，以区别其他话音流，由于每个话音流对应一个vpi/vci，所以我们只要为每个vpi/vci随机生成一个标识码，在一个话音流过程中保持不变就可以了。
RTCP的检出与复原：
在RTP会话期间，各参与者还要周期性地传送RTCP包，RTCP负责管理传输质量。其功能主要是流量控制和CNNAME。CNAME为RTP源提供一个永久性的规范性名字，用于续传等。由于我们采用了基于连接的atm承载技术，QoS由atm的相关技术来解决，所以RTCP包的意义不大，加/删ip模块应检出RTCP报文并丢弃。由于RTCP包的数量比较少（即使对其进行压缩处理，其节余量也微乎其微），在工程实现时，加/删包头模块检出RTCP报文后，也可以只进行加删28bytes的头部（ip头+udp头）操作。
Claims (3)
1.一种基于ATM承载IP语音的数据压缩方法，其特征在于：在接入设备与交换网络之间插入加/删包头模块，在源端交换网络和目的端交换网络之间只传递数据净荷；步骤为：
1）lsp隧道建立
2）本端和对端的加/删包头模块传递信息，建立压缩信息数据库；
3）源端接入设备发送的数据传递到源端的加/删包头模块，源端的加/删包头模块根据压缩信息数据库对数据作删除包头处理，然后再将处理后的数据传递到源端交换网络；
4）目的端交换网络将数据传递到目的端的加/删包头模块，目的端的加/删包头模块根据压缩信息数据库对数据作包头复原处理，然后再传递到目的端接入设备。
2.根据权利要求1所述的基于ATM承载IP语音的数据压缩方法，其特征在于：所述的压缩信息数据库中记录有加/删包头模块对本端的接入设备发来的数据，所作的删除处理的删除内容信息。
3.根据权利要求1或2所述的基于ATM承载IP语音的数据压缩方法，其特征在于：所述的加/删包头模块，在lsp隧道建立的同时，本端和对端的加/删包头模块互相交换压缩信息数据库中的信息，并记录在对端的压缩信息数据库中。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2010105609427A CN102006295A (zh) | 2010-11-26 | 2010-11-26 | 基于atm承载ip语音的数据压缩方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2010105609427A CN102006295A (zh) | 2010-11-26 | 2010-11-26 | 基于atm承载ip语音的数据压缩方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN102006295A true CN102006295A (zh) | 2011-04-06 |
Family
ID=43813366
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN2010105609427A Pending CN102006295A (zh) | 2010-11-26 | 2010-11-26 | 基于atm承载ip语音的数据压缩方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN102006295A (zh) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104954593A (zh) * | 2015-05-19 | 2015-09-30 | 重庆金美通信有限责任公司 | Voip资源预留和传输压缩实施方法 |
| WO2017143538A1 (zh) * | 2016-02-24 | 2017-08-31 | 华为技术有限公司 | 语音数据传输方法以及装置 |
| CN103731424B (zh) * | 2013-12-30 | 2017-09-15 | 优视科技有限公司 | 一种网络数据的传输方法、装置及系统 |
| CN109547467A (zh) * | 2018-12-19 | 2019-03-29 | 北京东土科技股份有限公司 | 媒体数据纠错传输及纠错方法、装置、设备及存储介质 |
| CN110198345A (zh) * | 2019-05-06 | 2019-09-03 | 视联动力信息技术股份有限公司 | 一种数据请求方法、系统及装置和存储介质 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1399462A (zh) * | 2001-07-27 | 2003-02-26 | 华为技术有限公司 | 一种节约带宽的语音传送方法 |
| US20060159129A1 (en) * | 2005-01-17 | 2006-07-20 | Alcatel | Method of providing multi-media communications over a DSL access network |
| CN101237419A (zh) * | 2008-03-07 | 2008-08-06 | 北京航管科技有限公司 | 航空电信网空地通信中的报头压缩方法 |
-
2010
- 2010-11-26 CN CN2010105609427A patent/CN102006295A/zh active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1399462A (zh) * | 2001-07-27 | 2003-02-26 | 华为技术有限公司 | 一种节约带宽的语音传送方法 |
| US20060159129A1 (en) * | 2005-01-17 | 2006-07-20 | Alcatel | Method of providing multi-media communications over a DSL access network |
| CN101237419A (zh) * | 2008-03-07 | 2008-08-06 | 北京航管科技有限公司 | 航空电信网空地通信中的报头压缩方法 |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103731424B (zh) * | 2013-12-30 | 2017-09-15 | 优视科技有限公司 | 一种网络数据的传输方法、装置及系统 |
| US10122803B2 (en) | 2013-12-30 | 2018-11-06 | Uc Mobile Co., Ltd. | Network data transmission method, device and system |
| CN104954593A (zh) * | 2015-05-19 | 2015-09-30 | 重庆金美通信有限责任公司 | Voip资源预留和传输压缩实施方法 |
| WO2017143538A1 (zh) * | 2016-02-24 | 2017-08-31 | 华为技术有限公司 | 语音数据传输方法以及装置 |
| CN109547467A (zh) * | 2018-12-19 | 2019-03-29 | 北京东土科技股份有限公司 | 媒体数据纠错传输及纠错方法、装置、设备及存储介质 |
| CN110198345A (zh) * | 2019-05-06 | 2019-09-03 | 视联动力信息技术股份有限公司 | 一种数据请求方法、系统及装置和存储介质 |
| CN110198345B (zh) * | 2019-05-06 | 2021-07-20 | 视联动力信息技术股份有限公司 | 一种数据请求方法、系统及装置和存储介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3730835B2 (ja) | パケット伝送方法、中継装置およびデータ端末 | |
| RU2208303C2 (ru) | Эффективная транспортировка пакетов интернет протокола, использующая асинхронный режим передачи уровня адаптации два | |
| US6608841B1 (en) | System and method for achieving robust IP/UDP/RTP header compression in the presence of unreliable networks | |
| EP1427146B1 (en) | Packet transmission system and packet reception system | |
| CN101939967B (zh) | 通信方法 | |
| US6684354B2 (en) | Data transmission method, data transmission apparatus, data receiving apparatus, and packet data structure | |
| US7124202B2 (en) | System and method for aggregating channel segment ID's into a first section and data segments into a second section | |
| US8160106B2 (en) | Method, device and system for transmitting Ethernet packets | |
| CN106162374B (zh) | 一种低复杂度的帧内编码帧鲁棒传输方法及系统 | |
| WO2002025822A2 (en) | Multimedia communications over power lines | |
| CN101568144B (zh) | 一种适用于无线自组织网络的报头压缩方法 | |
| US6999429B1 (en) | Access technology integrated header compression | |
| CN100591053C (zh) | 一种报文传输方法及网络节点装置 | |
| CN101594290B (zh) | 一种鲁棒性头压缩上下文标识的处理方法及装置 | |
| CN102006295A (zh) | 基于atm承载ip语音的数据压缩方法 | |
| CN101146025A (zh) | 压缩实时传输协议的报文传输方法和系统以及压缩端单元 | |
| JP2003522474A (ja) | チェックサムに基づくヘッダ圧縮におけるトランスポート層チェックサムの代替 | |
| CN104917591A (zh) | 一种适用于单向有损链路的卫星网络数据包压缩方法 | |
| CN104967498B (zh) | 一种基于历史的卫星网络数据包压缩传输方法 | |
| US9148257B2 (en) | Method and apparatus for reducing delays in a packets switched network | |
| US20050030944A1 (en) | Method and apparatus for reducing packet size employing payload header suppression (PHS) | |
| US20060268832A1 (en) | Transporting synchronization channel information across a packet network | |
| US6731640B1 (en) | Frame synchronization over multiple networks | |
| CN101102263B (zh) | 压缩报文恢复方法及装置 | |
| US20150016463A1 (en) | Media over ip performance enhancement |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C12 | Rejection of a patent application after its publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20110406 |