专利名称：在网络中传递信号音信息的制作方法
背景技术：
包语音(VOP)技术涉及在数据网络上传送语音信号。除了语音信号，VOP网络还必须经常考虑与语音信号交织的信号音信号(tone signals)。许多系统利用信号音信号在系统和用户之间传递信息，例如，使用双音多频(DTMF)信号音代表电话号码。然而，有些系统可能需要使用独立于语音信号的传输机制来传递信号音信号。所以，需要创造性的技术来处理VOP系统中的信号音信号。
在本说明书的所附部分具体指出和明确要求了视为本发明实施例的主题。然而，结合附图，参考下面的详细描述，可以更好地理解本发明的实施例关于组织和操作方法及其目标、特征和优点，其中图1是适合实施本发明的一个实施例的系统。
图2图示了适于和本发明的一个实施例一起使用的VOP系统。
图3(现有技术)图示了根据RFC 2833规范而创建的常规信号音包。
图4图示了根据本发明的一个实施例而创建的信号音包。
图5是根据本发明的一个实施例，由TMM执行的操作的方框流程图。
具体实施例方式
本发明的实施例包括一种方法和装置，用于在诸如VOP网络这样的网络上传递信号音。例如，本发明的一个实施例涉及在VOP网络中以冗余方式传递信号音，以减少网络中的丢包。
为了提供对本发明实施例的彻底理解，这里提到了许多具体细节。然而，本领域的技术人员将理解，没有这些具体细节，也可以实施本发明的实施例。另一方面，为了不混淆本发明的实施例，没有详细描述公知的方法、过程、组件和电路。应该理解的是，这里公开的具体结构和功能细节是代表性的，并不限制本发明的范围。
还值得注意的是，本说明书中任何对“一个实施例”或“实施例”的引用都意味着结合有关实施例描述的具体特征、结构或特性包括在本发明的至少一个实施例中。本说明书中各处出现的“在一个实施例中”的字样并不都指同一实施例。
现在详细参考附图，其中相同的部分通篇用相同的标号表示；图1中图示了适于实施本发明的一个实施例的系统。图1是系统100的方框图。例如，系统100可以包括呼叫终端102和106，二者通过网络104连接。
呼叫终端的例子可以包括能够在网络上传递音频和信号音信号的任意设备。例如，呼叫终端可以包括常规的电话机、无线电话、配备有收发器和调制解调器的便携式的或手持的计算机、个人数字助理(PDA)、包通话电话(packet telephony telephone)等。
网络104可以包括例如分组网络。在本发明的一个实施例中，网络104可以依据例如一个或多个互联网协议工作，例如由1981年9月采用的因特网工程任务组(IETF)标准7、RFC 793定义的传输控制协议(TCP)和由1981年9月采用的IETF标准5、RFC 791定义的因特网协议(IP)，从“www.ietf.org”上可以获悉它们的相关内容，但是本发明的实施例并不限于这个范围。网络104还可以依据用于传递代表音频、语音或信号音信息的VOP包的一个或多个协议工作。例如，在本发明的一个实施例中，网络104可以依据2000年11月公布的题为“Packet-based MultimediaCommunication Systems”的国际电信联盟(ITU)建议H.323，从“www.itu.int”上可以获悉相关内容(“H.323规范”)；1999年3月公布的题为“SIPSession Initiation Protocol”的IETF建议标准RFC 2543，从“www.ietf.org”上可以获悉相关内容(“SIP规范”)；或者2000年5月公布的题为“RTP Payload for DTMF Digits，Telephony Tones and TelephonySignals”的IETF建议标准RFC 2833，从“www.ietf.org”上可以获悉相关内容(“RFC 2833规范”)来工作。虽然这里讨论了具体示例，应该理解的是本发明的实施例并不限于这个范围。此外，网络104还可以包括电路交换技术和对于分组网络技术的合适接口。
图2图示了一个适于与本发明的一个实施例一起使用的VOP系统。图2是系统200的方框图。系统200可以包括例如图1中示出的系统100的一部分。系统200可以包括一个VOP系统，包含有网关202、网络守卫服务器(gatekeeper)206和内部网关208。网关202还可以包含有信号音管理模块(TMM)204。
网关202可以工作来将常规的电话呼叫转换为包电话呼叫或VOP呼叫。网关202可以接收来自诸如公共交换电话网络(PSTN)这样的电路交换网络的信号，并且将电路交换信号转换成包。根据例如TCP/IP规范、SIP规范、H.323规范和RFC 2833规范来完成这种到包的转换。网关202可以通过系统200的其他组件传递包，直至包到达它们的预定目标，例如连接至内部网关208的呼叫终端。
网络守卫服务器206可以根据例如SIP规范或H.323规范来执行常规的网络守卫服务器功能，例如地址翻译、进入控制、呼叫控制信令、呼叫授权、呼叫管理等。在本发明的一个实施例中，网络守卫服务器206可以提供地址和路由信息，以将包通过系统200传递至诸如呼叫终端106这样的目标呼叫终端。
在本发明的一个实施例中，网关202还可以包括TMM 204。TMM204可以管理信号音信号在诸如VOP网络这样的网络中的传递。在本发明的一个实施例中，TMM 204可以包括作为处理器执行的软件、硬件电路或结构、或二者的组合而实现的功能。处理器可以是通用或专用的处理器，例如英特尔公司、摩托罗拉公司、太阳微系统公司和其他公司生产的处理器系列的处理器。软件可以包括用于实现本发明实施例的某一功能的程序逻辑、指令或数据。软件可以存储在可由机器访问的介质或计算机可读介质上，例如只读存储器(ROM)、随机访问存储器(RAM)、磁盘(例如，软盘和硬盘)、光盘(例如，CD-ROM)或任意其他的数据存储介质。在本发明的一个实施例中，所述介质可以以压缩和/或加密格式存储程序指令，以及在处理器执行之前必须被安装者编译或安装的指令。或者，本发明的实施例可以实现为包含有用于执行所述功能的硬连线逻辑的专用硬件组件，或通过经编程的通用计算机组件和自定义硬件组件的任意组合。
在操作中，TMM 204可以检测在网关处接收的信号音信号，并根据一个或多个信号音协议来处理该信号音，例如RFC 2833规范中阐述的信号音协议。RFC 2833规范是有关使用实时输送协议(RTP)来输送电话信号音的因特网标准。RFC 2833规范指出由于高的压缩率，在编码的语音流内(“带内”)传送的信号音往往在接收器中被扰乱而不可识别。然而，如果通过传统的TCP/IP传送信号音，则由于常规的TCP/IP流量的丢包或本身较低的优先权，会导致严重延迟。RFC 2833规范试图通过定义两种类型的根据用户数据报协议(UDP)传递的信号音RTP包来解决这些问题。然而，根据UDP来传输信号音RTP包并不可靠，仍可能导致丢失大量的包使得接收器不能使用信号音信息。
在解决该问题的尝试中，RFC 2833规范描述了一种冗余机制，其中每个信号音RTP包不仅携带当前信号音信息，而且携带可达5个的先前信号音事件。这里使用的术语“信号音信息”指用来表示信号音信号的任意信息，包括名称、标记、频率成分、时间信息等。这里使用的术语“信号音信号”指任意信号音信号，例如电话、VOP或自动化系统使用的DTMF信号音或其他信号音。这里使用的术语“信号音包”指用来携带信号音信息的任意包。
根据RFC 2833规范，信号音包可以包括两种类型的信号音信息。第一种类型是代表当前信号音事件的信号音信息，这里为方便起见称为“类型一信息”。第二种类型是代表先前信号音事件的信号音信息，这里为方便起见称为“类型二信息”。这里使用的术语“信号音事件”指完整的信号音信号，例如，开始时间、持续期和终止时间。在本发明的一个实施例中，系统200可以使用类型二信息，用于冗余。在丢失了携带有先前信号音事件的包的情况下，可以使用类型二信息来重建该先前信号音事件。
然而，在某些情况下，类型二信息可能不能提供足够的冗余。例如，信号音事件通常持续的时间长于用于传输信号音信息的包或帧的大小。因此，在完成当前信号音事件之前，VOP系统可能需要开始传输类型一信息。如果在信号音事件完成之前，这些包被扰乱或丢失，则接收器可能没有足够的信息来重建信号音事件。在这种情况下，类型二信息的冗余功能可能不起作用，因为它携带的信号音信息来自先前信号音事件，而不是当前信号音事件。
在解决这个和其他问题的尝试中，本发明的一个实施例可以使用第三类型信号音信息，为方便起见这里称为“类型三信息”。类型三信息可以包括例如当前信号音事件的部分信号音信息。例如，类型三信息可以是一个或多个先前包或帧携带的用于当前信号音事件的信号音信息。以这种方式，如果携带有类型一信息的一个或多个包丢失，则接收器能够利用类型三信息及时地重建当前信号音事件。如前所述，在这种情况下，类型二信息的冗余功能不起作用，因为它携带的信号音信息来自先前信号音事件。然而，类型三信息可以在足够的时间内被接收，以供VOP或自动化系统检测和使用。参考以下的图3和图4，可以更好地说明本发明的这个实施例。
图3(现有技术)图示了根据RFC 2833规范创建的常规信号音包。图3图示了通常的RTP包300，其中用户正好在拨打DTMF序列“911”的最后一位数字。第一位数字长200毫秒(ms)(1600个时间戳单位)，开始于时间0处；第二位数字持续250ms(2000个时间戳单位)，开始于时刻800ms(6400个时间戳单位)处；第三位数字在时刻1.4秒(11,200个时间戳单位)处被键入。包300示出了它在1.45秒(11,600个时间戳单位)处被传送。帧持续时间长50ms。值得注意的是，为了说明，图3忽略了字节对齐。假设第一位数字开始时，时间戳和序列号已经为0。如图3所示，RTP信号音包300包括用于冗余的类型二信息。例如，单元302和304分别表示“9”和“1”用的先前信号音事件。虽然类型二信息对于重建“9”和“1”的先前信号音事件可能有用，但该信息对于重建仍有效的最后一位数字“1”的当前信号音事件却没有帮助。
图4图示了根据本发明的一个实施例创建的信号音包。图4图示了RTP包400。类似于RTP包300，RTP包400表示由呼叫者产生的三个信号音事件。这三个信号音事件是DTMF信号音“9”、“1”和“1”。第一信号音在时刻0处键入，持续1600ms。第二信号音在时刻6400ms处键入，持续2000ms。第三信号音在时刻11200ms处键入，但尚未终止。相反，第三信号音事件只有400ms进入总信号音事件。单元402和404表示用于冗余的先前信号音事件“9”和“1”的信号音信息。然而，根据本发明的一个实施例，RTP包400还可以包括来自两个先前的信号音包的信号音信息形式的类型三信息，图4中分别作为单元406和408示出。这两个先前的信号音帧是恰好在当前的或最近的信号音帧之前的两个先前信号音帧，在图4中所述当前的或最近的信号音帧作为单元410示出。
根据本发明的一个实施例，如果在传输中携带有表示为冗余单元406和408的信号音信息的信号音包丢失了，则目标接收器可以使用来自RTP信号音包400的单元406或408来重建“911”序列中的第三信号音事件“1”。
在本发明的一个实施例中，TMM 204可以创建类似于参考图4描述的RTP信号音包400的信号音包。本实施例可以包括当前信号音信息，以及由一个或多个先前的包携带的信号音信息。以这种方式，在传送过程中，如果一个或多个包丢失或被扰乱，接收器就可以恢复信号音信息。这是对通常以信号音事件管理为基础，而不是以信号音包管理为基础的常规的信号音管理技术的一种改进。
参考图5及其附例，进一步描述系统100和200的操作。虽然这里给出的图5包括具体的处理逻辑，但是应该理解，该处理逻辑仅仅给出了怎么实现这里描述的一般功能的例子。此外，在给出的处理逻辑内的各个操作并不必按给出的顺序执行，除非另有说明。
图5是根据本发明的一个实施例的TMM执行的操作的方框流程图。在本发明的一个实施例中，这个或其他模块可以指用于实现这里描述的一个或多个实施例的功能的软件和/或硬件。在本发明的这个实施例中，这个或其他模块可以作为诸如系统200这样的系统的一部分来实现。然而，应该理解，位于通信网络中任意处的任意设备、或设备组合都可以实现该功能，并仍落在本发明的范围内。
图5图示了根据本发明的一个实施例，用于TMM的程序逻辑500。如程序逻辑500所示，在方框502中，信号音信息可以被接收。在本发明的一个实施例中，信号音信息可以代表例如DTMF信号。在方框504中，可以创建具有信号音信息的第一部分的第一包。在方框506中，第一包可以被传送至接收器。在方框508中，可以创建具有所述信息的第一部分和第二部分的第二包。在方框510中，第二包可以被传送至所述接收器。在方框512中，第一包和第二包可以被接收。在方框514中，利用信号音信息的第一和第二部分，接收器可以再现所述信号音。
在本发明的一个实施例中，例如根据利用这里提出的概念而修改的RFC 2833规范，可以创建第一包和第二包。更具体地说，所述包可以是RTP信号音包，具有表示为信号音名称或信号音频率的信号音信息。在本发明的一个实施例中，可以确定信号音的频率和/或持续时间，并用来在表中或存储器中搜索对应的名称或事件。例如，代表DTMF数字的信号音信号可以被接收。TMM接收所述信号音信号，并搜索数据库，以获得对应于所述信号音信号的诸如频率这样的一个或多个特性的名称。TMM可以创建所述信号音包，并使用名称来作为所述信号音信号的标识符。在本发明的另一实施例中，TMM可以在所述信号音包中传送所述信号音信号的一个或多个特性，例如频率自身。
通过例子，可以更好地理解系统100和200的操作，以及图5中示出的处理逻辑。假定呼叫者通过网络104，使用呼叫终端102来启动对呼叫终端106的电话呼叫。呼叫者拨打被网络104接收的10个数字电话号码。网络104通过PSTN，利用常规的电路交换技术启动呼叫建立并传送所述10个DTMF数字。电路交换信号被系统200的网关202接收。网关202包括PSTN接口卡和一些技术，以将电路交换信号转换为包交换信号。网关202的TMM 204检测到DTMF信号，并开始根据RFC 2833规范和这里描述的修改来创建RTP信号音包。通过由网络守卫服务器206获取的路由信息，所述RTP信号音包被路由至呼叫终端106。
根据本发明的一个实施例，在传输至呼叫终端106的过程中，如果一个或多个RTP信号音包被扰乱或丢失，则RTP信号音包包括冗余信息。例如，RTP信号音包可以类似于参考图4所描述的RTP信号音包400。如前面讨论的，RTP信号音包400可以包括关于先前信号音事件，例如先前拨打的DTMF数字的常规的类型二信息。根据本发明的一个实施例，RTP信号音包400还可以包括类型三信息。应该理解，在一些实现中，根据网络104的带宽或其他设计限制，类型二信息可以从RTP信号音包400中省略。
根据本发明的一个实施例，呼叫终端106可以开始接收来自网关202的RTP信号音包。呼叫终端106可以试图利用RTP信号音包来重建信号音事件。如果一个或多个RTP信号音包丢失，则呼叫终端106可以使用类型三信息来获取由被扰乱的或丢失的包所携带的信息。
由于RFC 2833规范已经定义了可达5个级别的冗余，因此应该理解，使用这5个级别的其中一个或多个，类型三信息可以被插入RTP信号音包。以这种方式，TMM 204提供更健全的和更灵活的信号音恢复功能，同时只加入相对较少的额外开销或延迟，并且在某些情况下，根本没有额外开销或延迟。还应该理解，可以使用满足具体系统的设计或性能限制的类型二信息和类型三信息的任意组合来建立RTP包。
虽然如这里描述的，已经说明了本发明实施例的某些特征，但本领域的技术人员可进行许多改进、置换、变化和等同替换。因此，应该理解的是，所附权利要求旨在涵盖所有这些落在本发明实施例的真正精神内的改进和变化。
权利要求
1.一种传递信号音的方法，包括接收代表信号音的信息；创建具有所述信息的第一部分的第一包；传送所述第一包至接收器；创建具有所述信息的所述第一部分和第二部分的第二包；和传送所述第二包至所述接收器。
2.如权利要求1所述的方法，其中所述信息代表双音多频数字。
3.如权利要求1所述的方法，其中根据RFC 2833完成创建所述第一包和所述第二包。
4.如权利要求1所述的方法，其中根据RTP协议完成传送所述第一包和所述第二包。
5.如权利要求1所述的方法，其中所述信息代表所述信号音的名称。
6.如权利要求1所述的方法，其中所述信息代表所述信号音的频率。
7.一种传递信号音的方法，包括接收具有代表信号音的信息的第一部分的第一包；接收具有所述信息的所述第一部分和第二部分的第二包。
8.如权利要求7所述的方法，还包括利用所述第一和第二部分来再现所述信号音。
9.如权利要求7所述的方法，其中所述信息代表双音多频数字。
10.如权利要求7所述的方法，其中根据RFC 2833创建所述第一包和所述第二包。
11.如权利要求7所述的方法，其中根据RTP协议接收所述第一包和所述第二包。
12.如权利要求7所述的方法，其中所述信息代表所述信号音的名称。
13.如权利要求7所述的方法，其中所述信息代表所述信号音的频率。
14.一种传递信号音的方法，包括接收代表信号音的信息；创建具有所述信息的第一部分的第一包；传送所述第一包至接收器；创建具有所述信息的所述第一部分和第二部分的第二包；传送所述第二包至所述接收器；接收所述第一和第二包；和利用所述第一和第二部分再现所述信号音。
15.如权利要求14所述的方法，其中所述信息代表双音多频数字。
16.一种器件，包括存储介质；所述存储介质包括被存储的指令，当处理器执行所述指令时，导致接收代表信号音的信息、创建具有所述信息的第一部分的第一包、传送所述第一包至接收器、创建具有所述信息的所述第一部分和第二部分的第二包以及传送所述第二包至所述接收器。
17.如权利要求16所述的器件，其中当处理器执行所述被存储的指令时，还导致接收所述第一和第二包以及利用所述第一和第二部分再现所述信号音。
18.一种系统，包括适于传递信号音的计算平台；所述平台还适于接收代表信号音的信息、创建具有所述信息的第一部分的第一包、传送所述第一包至接收器、创建具有所述信息的所述第一部分和第二部分的第二包以及传送所述第二包至所述接收器。
19.如权利要求18所述的系统，其中所述平台还适于接收所述第一和第二包，并且利用所述第一和第二部分再现所述信号音。
全文摘要
本说明描述了一种传递信号音的方法和装置。
文档编号H04M7/00GK1623303SQ03800475
公开日2005年6月1日 申请日期2003年8月1日 优先权日2002年8月6日
发明者凯·苗 申请人:英特尔公司