專利名稱：在網(wǎng)絡(luò)中傳遞信號音信息的制作方法
背景技術(shù)：
包語音(VOP)技術(shù)涉及在數(shù)據(jù)網(wǎng)絡(luò)上傳送語音信號。除了語音信號，VOP網(wǎng)絡(luò)還必須經(jīng)?？紤]與語音信號交織的信號音信號(tone signals)。許多系統(tǒng)利用信號音信號在系統(tǒng)和用戶之間傳遞信息，例如，使用雙音多頻(DTMF)信號音代表電話號碼。然而，有些系統(tǒng)可能需要使用獨立于語音信號的傳輸機制來傳遞信號音信號。所以，需要創(chuàng)造性的技術(shù)來處理VOP系統(tǒng)中的信號音信號。


在本說明書的所附部分具體指出和明確要求了視為本發(fā)明實施例的主題。然而，結(jié)合附圖，參考下面的詳細描述，可以更好地理解本發(fā)明的實施例關(guān)于組織和操作方法及其目標、特征和優(yōu)點，其中圖1是適合實施本發(fā)明的一個實施例的系統(tǒng)。
圖2圖示了適于和本發(fā)明的一個實施例一起使用的VOP系統(tǒng)。
圖3(現(xiàn)有技術(shù))圖示了根據(jù)RFC 2833規(guī)范而創(chuàng)建的常規(guī)信號音包。
圖4圖示了根據(jù)本發(fā)明的一個實施例而創(chuàng)建的信號音包。
圖5是根據(jù)本發(fā)明的一個實施例，由TMM執(zhí)行的操作的方框流程圖。
具體實施例方式
本發(fā)明的實施例包括一種方法和裝置，用于在諸如VOP網(wǎng)絡(luò)這樣的網(wǎng)絡(luò)上傳遞信號音。例如，本發(fā)明的一個實施例涉及在VOP網(wǎng)絡(luò)中以冗余方式傳遞信號音，以減少網(wǎng)絡(luò)中的丟包。
為了提供對本發(fā)明實施例的徹底理解，這里提到了許多具體細節(jié)。然而，本領(lǐng)域的技術(shù)人員將理解，沒有這些具體細節(jié)，也可以實施本發(fā)明的實施例。另一方面，為了不混淆本發(fā)明的實施例，沒有詳細描述公知的方法、過程、組件和電路。應(yīng)該理解的是，這里公開的具體結(jié)構(gòu)和功能細節(jié)是代表性的，并不限制本發(fā)明的范圍。
還值得注意的是，本說明書中任何對“一個實施例”或“實施例”的引用都意味著結(jié)合有關(guān)實施例描述的具體特征、結(jié)構(gòu)或特性包括在本發(fā)明的至少一個實施例中。本說明書中各處出現(xiàn)的“在一個實施例中”的字樣并不都指同一實施例。
現(xiàn)在詳細參考附圖，其中相同的部分通篇用相同的標號表示；圖1中圖示了適于實施本發(fā)明的一個實施例的系統(tǒng)。圖1是系統(tǒng)100的方框圖。例如，系統(tǒng)100可以包括呼叫終端102和106，二者通過網(wǎng)絡(luò)104連接。
呼叫終端的例子可以包括能夠在網(wǎng)絡(luò)上傳遞音頻和信號音信號的任意設(shè)備。例如，呼叫終端可以包括常規(guī)的電話機、無線電話、配備有收發(fā)器和調(diào)制解調(diào)器的便攜式的或手持的計算機、個人數(shù)字助理(PDA)、包通話電話(packet telephony telephone)等。
網(wǎng)絡(luò)104可以包括例如分組網(wǎng)絡(luò)。在本發(fā)明的一個實施例中，網(wǎng)絡(luò)104可以依據(jù)例如一個或多個互聯(lián)網(wǎng)協(xié)議工作，例如由1981年9月采用的因特網(wǎng)工程任務(wù)組(IETF)標準7、RFC 793定義的傳輸控制協(xié)議(TCP)和由1981年9月采用的IETF標準5、RFC 791定義的因特網(wǎng)協(xié)議(IP)，從“www.ietf.org”上可以獲悉它們的相關(guān)內(nèi)容，但是本發(fā)明的實施例并不限于這個范圍。網(wǎng)絡(luò)104還可以依據(jù)用于傳遞代表音頻、語音或信號音信息的VOP包的一個或多個協(xié)議工作。例如，在本發(fā)明的一個實施例中，網(wǎng)絡(luò)104可以依據(jù)2000年11月公布的題為“Packet-based MultimediaCommunication Systems”的國際電信聯(lián)盟(ITU)建議H.323，從“www.itu.int”上可以獲悉相關(guān)內(nèi)容(“H.323規(guī)范”)；1999年3月公布的題為“SIPSession Initiation Protocol”的IETF建議標準RFC 2543，從“www.ietf.org”上可以獲悉相關(guān)內(nèi)容(“SIP規(guī)范”)；或者2000年5月公布的題為“RTP Payload for DTMF Digits，Telephony Tones and TelephonySignals”的IETF建議標準RFC 2833，從“www.ietf.org”上可以獲悉相關(guān)內(nèi)容(“RFC 2833規(guī)范”)來工作。雖然這里討論了具體示例，應(yīng)該理解的是本發(fā)明的實施例并不限于這個范圍。此外，網(wǎng)絡(luò)104還可以包括電路交換技術(shù)和對于分組網(wǎng)絡(luò)技術(shù)的合適接口。
圖2圖示了一個適于與本發(fā)明的一個實施例一起使用的VOP系統(tǒng)。圖2是系統(tǒng)200的方框圖。系統(tǒng)200可以包括例如圖1中示出的系統(tǒng)100的一部分。系統(tǒng)200可以包括一個VOP系統(tǒng)，包含有網(wǎng)關(guān)202、網(wǎng)絡(luò)守衛(wèi)服務(wù)器(gatekeeper)206和內(nèi)部網(wǎng)關(guān)208。網(wǎng)關(guān)202還可以包含有信號音管理模塊(TMM)204。
網(wǎng)關(guān)202可以工作來將常規(guī)的電話呼叫轉(zhuǎn)換為包電話呼叫或VOP呼叫。網(wǎng)關(guān)202可以接收來自諸如公共交換電話網(wǎng)絡(luò)(PSTN)這樣的電路交換網(wǎng)絡(luò)的信號，并且將電路交換信號轉(zhuǎn)換成包。根據(jù)例如TCP/IP規(guī)范、SIP規(guī)范、H.323規(guī)范和RFC 2833規(guī)范來完成這種到包的轉(zhuǎn)換。網(wǎng)關(guān)202可以通過系統(tǒng)200的其他組件傳遞包，直至包到達它們的預(yù)定目標，例如連接至內(nèi)部網(wǎng)關(guān)208的呼叫終端。
網(wǎng)絡(luò)守衛(wèi)服務(wù)器206可以根據(jù)例如SIP規(guī)范或H.323規(guī)范來執(zhí)行常規(guī)的網(wǎng)絡(luò)守衛(wèi)服務(wù)器功能，例如地址翻譯、進入控制、呼叫控制信令、呼叫授權(quán)、呼叫管理等。在本發(fā)明的一個實施例中，網(wǎng)絡(luò)守衛(wèi)服務(wù)器206可以提供地址和路由信息，以將包通過系統(tǒng)200傳遞至諸如呼叫終端106這樣的目標呼叫終端。
在本發(fā)明的一個實施例中，網(wǎng)關(guān)202還可以包括TMM 204。TMM204可以管理信號音信號在諸如VOP網(wǎng)絡(luò)這樣的網(wǎng)絡(luò)中的傳遞。在本發(fā)明的一個實施例中，TMM 204可以包括作為處理器執(zhí)行的軟件、硬件電路或結(jié)構(gòu)、或二者的組合而實現(xiàn)的功能。處理器可以是通用或?qū)Ｓ玫奶幚砥?，例如英特爾公司、摩托羅拉公司、太陽微系統(tǒng)公司和其他公司生產(chǎn)的處理器系列的處理器。軟件可以包括用于實現(xiàn)本發(fā)明實施例的某一功能的程序邏輯、指令或數(shù)據(jù)。軟件可以存儲在可由機器訪問的介質(zhì)或計算機可讀介質(zhì)上，例如只讀存儲器(ROM)、隨機訪問存儲器(RAM)、磁盤(例如，軟盤和硬盤)、光盤(例如，CD-ROM)或任意其他的數(shù)據(jù)存儲介質(zhì)。在本發(fā)明的一個實施例中，所述介質(zhì)可以以壓縮和/或加密格式存儲程序指令，以及在處理器執(zhí)行之前必須被安裝者編譯或安裝的指令?；蛘?，本發(fā)明的實施例可以實現(xiàn)為包含有用于執(zhí)行所述功能的硬連線邏輯的專用硬件組件，或通過經(jīng)編程的通用計算機組件和自定義硬件組件的任意組合。
在操作中，TMM 204可以檢測在網(wǎng)關(guān)處接收的信號音信號，并根據(jù)一個或多個信號音協(xié)議來處理該信號音，例如RFC 2833規(guī)范中闡述的信號音協(xié)議。RFC 2833規(guī)范是有關(guān)使用實時輸送協(xié)議(RTP)來輸送電話信號音的因特網(wǎng)標準。RFC 2833規(guī)范指出由于高的壓縮率，在編碼的語音流內(nèi)(“帶內(nèi)”)傳送的信號音往往在接收器中被擾亂而不可識別。然而，如果通過傳統(tǒng)的TCP/IP傳送信號音，則由于常規(guī)的TCP/IP流量的丟包或本身較低的優(yōu)先權(quán)，會導(dǎo)致嚴重延遲。RFC 2833規(guī)范試圖通過定義兩種類型的根據(jù)用戶數(shù)據(jù)報協(xié)議(UDP)傳遞的信號音RTP包來解決這些問題。然而，根據(jù)UDP來傳輸信號音RTP包并不可靠，仍可能導(dǎo)致丟失大量的包使得接收器不能使用信號音信息。
在解決該問題的嘗試中，RFC 2833規(guī)范描述了一種冗余機制，其中每個信號音RTP包不僅攜帶當前信號音信息，而且攜帶可達5個的先前信號音事件。這里使用的術(shù)語“信號音信息”指用來表示信號音信號的任意信息，包括名稱、標記、頻率成分、時間信息等。這里使用的術(shù)語“信號音信號”指任意信號音信號，例如電話、VOP或自動化系統(tǒng)使用的DTMF信號音或其他信號音。這里使用的術(shù)語“信號音包”指用來攜帶信號音信息的任意包。
根據(jù)RFC 2833規(guī)范，信號音包可以包括兩種類型的信號音信息。第一種類型是代表當前信號音事件的信號音信息，這里為方便起見稱為“類型一信息”。第二種類型是代表先前信號音事件的信號音信息，這里為方便起見稱為“類型二信息”。這里使用的術(shù)語“信號音事件”指完整的信號音信號，例如，開始時間、持續(xù)期和終止時間。在本發(fā)明的一個實施例中，系統(tǒng)200可以使用類型二信息，用于冗余。在丟失了攜帶有先前信號音事件的包的情況下，可以使用類型二信息來重建該先前信號音事件。
然而，在某些情況下，類型二信息可能不能提供足夠的冗余。例如，信號音事件通常持續(xù)的時間長于用于傳輸信號音信息的包或幀的大小。因此，在完成當前信號音事件之前，VOP系統(tǒng)可能需要開始傳輸類型一信息。如果在信號音事件完成之前，這些包被擾亂或丟失，則接收器可能沒有足夠的信息來重建信號音事件。在這種情況下，類型二信息的冗余功能可能不起作用，因為它攜帶的信號音信息來自先前信號音事件，而不是當前信號音事件。
在解決這個和其他問題的嘗試中，本發(fā)明的一個實施例可以使用第三類型信號音信息，為方便起見這里稱為“類型三信息”。類型三信息可以包括例如當前信號音事件的部分信號音信息。例如，類型三信息可以是一個或多個先前包或幀攜帶的用于當前信號音事件的信號音信息。以這種方式，如果攜帶有類型一信息的一個或多個包丟失，則接收器能夠利用類型三信息及時地重建當前信號音事件。如前所述，在這種情況下，類型二信息的冗余功能不起作用，因為它攜帶的信號音信息來自先前信號音事件。然而，類型三信息可以在足夠的時間內(nèi)被接收，以供VOP或自動化系統(tǒng)檢測和使用。參考以下的圖3和圖4，可以更好地說明本發(fā)明的這個實施例。
圖3(現(xiàn)有技術(shù))圖示了根據(jù)RFC 2833規(guī)范創(chuàng)建的常規(guī)信號音包。圖3圖示了通常的RTP包300，其中用戶正好在撥打DTMF序列“911”的最后一位數(shù)字。第一位數(shù)字長200毫秒(ms)(1600個時間戳單位)，開始于時間0處；第二位數(shù)字持續(xù)250ms(2000個時間戳單位)，開始于時刻800ms(6400個時間戳單位)處；第三位數(shù)字在時刻1.4秒(11,200個時間戳單位)處被鍵入。包300示出了它在1.45秒(11,600個時間戳單位)處被傳送。幀持續(xù)時間長50ms。值得注意的是，為了說明，圖3忽略了字節(jié)對齊。假設(shè)第一位數(shù)字開始時，時間戳和序列號已經(jīng)為0。如圖3所示，RTP信號音包300包括用于冗余的類型二信息。例如，單元302和304分別表示“9”和“1”用的先前信號音事件。雖然類型二信息對于重建“9”和“1”的先前信號音事件可能有用，但該信息對于重建仍有效的最后一位數(shù)字“1”的當前信號音事件卻沒有幫助。
圖4圖示了根據(jù)本發(fā)明的一個實施例創(chuàng)建的信號音包。圖4圖示了RTP包400。類似于RTP包300，RTP包400表示由呼叫者產(chǎn)生的三個信號音事件。這三個信號音事件是DTMF信號音“9”、“1”和“1”。第一信號音在時刻0處鍵入，持續(xù)1600ms。第二信號音在時刻6400ms處鍵入，持續(xù)2000ms。第三信號音在時刻11200ms處鍵入，但尚未終止。相反，第三信號音事件只有400ms進入總信號音事件。單元402和404表示用于冗余的先前信號音事件“9”和“1”的信號音信息。然而，根據(jù)本發(fā)明的一個實施例，RTP包400還可以包括來自兩個先前的信號音包的信號音信息形式的類型三信息，圖4中分別作為單元406和408示出。這兩個先前的信號音幀是恰好在當前的或最近的信號音幀之前的兩個先前信號音幀，在圖4中所述當前的或最近的信號音幀作為單元410示出。
根據(jù)本發(fā)明的一個實施例，如果在傳輸中攜帶有表示為冗余單元406和408的信號音信息的信號音包丟失了，則目標接收器可以使用來自RTP信號音包400的單元406或408來重建“911”序列中的第三信號音事件“1”。
在本發(fā)明的一個實施例中，TMM 204可以創(chuàng)建類似于參考圖4描述的RTP信號音包400的信號音包。本實施例可以包括當前信號音信息，以及由一個或多個先前的包攜帶的信號音信息。以這種方式，在傳送過程中，如果一個或多個包丟失或被擾亂，接收器就可以恢復(fù)信號音信息。這是對通常以信號音事件管理為基礎(chǔ)，而不是以信號音包管理為基礎(chǔ)的常規(guī)的信號音管理技術(shù)的一種改進。
參考圖5及其附例，進一步描述系統(tǒng)100和200的操作。雖然這里給出的圖5包括具體的處理邏輯，但是應(yīng)該理解，該處理邏輯僅僅給出了怎么實現(xiàn)這里描述的一般功能的例子。此外，在給出的處理邏輯內(nèi)的各個操作并不必按給出的順序執(zhí)行，除非另有說明。
圖5是根據(jù)本發(fā)明的一個實施例的TMM執(zhí)行的操作的方框流程圖。在本發(fā)明的一個實施例中，這個或其他模塊可以指用于實現(xiàn)這里描述的一個或多個實施例的功能的軟件和/或硬件。在本發(fā)明的這個實施例中，這個或其他模塊可以作為諸如系統(tǒng)200這樣的系統(tǒng)的一部分來實現(xiàn)。然而，應(yīng)該理解，位于通信網(wǎng)絡(luò)中任意處的任意設(shè)備、或設(shè)備組合都可以實現(xiàn)該功能，并仍落在本發(fā)明的范圍內(nèi)。
圖5圖示了根據(jù)本發(fā)明的一個實施例，用于TMM的程序邏輯500。如程序邏輯500所示，在方框502中，信號音信息可以被接收。在本發(fā)明的一個實施例中，信號音信息可以代表例如DTMF信號。在方框504中，可以創(chuàng)建具有信號音信息的第一部分的第一包。在方框506中，第一包可以被傳送至接收器。在方框508中，可以創(chuàng)建具有所述信息的第一部分和第二部分的第二包。在方框510中，第二包可以被傳送至所述接收器。在方框512中，第一包和第二包可以被接收。在方框514中，利用信號音信息的第一和第二部分，接收器可以再現(xiàn)所述信號音。
在本發(fā)明的一個實施例中，例如根據(jù)利用這里提出的概念而修改的RFC 2833規(guī)范，可以創(chuàng)建第一包和第二包。更具體地說，所述包可以是RTP信號音包，具有表示為信號音名稱或信號音頻率的信號音信息。在本發(fā)明的一個實施例中，可以確定信號音的頻率和/或持續(xù)時間，并用來在表中或存儲器中搜索對應(yīng)的名稱或事件。例如，代表DTMF數(shù)字的信號音信號可以被接收。TMM接收所述信號音信號，并搜索數(shù)據(jù)庫，以獲得對應(yīng)于所述信號音信號的諸如頻率這樣的一個或多個特性的名稱。TMM可以創(chuàng)建所述信號音包，并使用名稱來作為所述信號音信號的標識符。在本發(fā)明的另一實施例中，TMM可以在所述信號音包中傳送所述信號音信號的一個或多個特性，例如頻率自身。
通過例子，可以更好地理解系統(tǒng)100和200的操作，以及圖5中示出的處理邏輯。假定呼叫者通過網(wǎng)絡(luò)104，使用呼叫終端102來啟動對呼叫終端106的電話呼叫。呼叫者撥打被網(wǎng)絡(luò)104接收的10個數(shù)字電話號碼。網(wǎng)絡(luò)104通過PSTN，利用常規(guī)的電路交換技術(shù)啟動呼叫建立并傳送所述10個DTMF數(shù)字。電路交換信號被系統(tǒng)200的網(wǎng)關(guān)202接收。網(wǎng)關(guān)202包括PSTN接口卡和一些技術(shù)，以將電路交換信號轉(zhuǎn)換為包交換信號。網(wǎng)關(guān)202的TMM 204檢測到DTMF信號，并開始根據(jù)RFC 2833規(guī)范和這里描述的修改來創(chuàng)建RTP信號音包。通過由網(wǎng)絡(luò)守衛(wèi)服務(wù)器206獲取的路由信息，所述RTP信號音包被路由至呼叫終端106。
根據(jù)本發(fā)明的一個實施例，在傳輸至呼叫終端106的過程中，如果一個或多個RTP信號音包被擾亂或丟失，則RTP信號音包包括冗余信息。例如，RTP信號音包可以類似于參考圖4所描述的RTP信號音包400。如前面討論的，RTP信號音包400可以包括關(guān)于先前信號音事件，例如先前撥打的DTMF數(shù)字的常規(guī)的類型二信息。根據(jù)本發(fā)明的一個實施例，RTP信號音包400還可以包括類型三信息。應(yīng)該理解，在一些實現(xiàn)中，根據(jù)網(wǎng)絡(luò)104的帶寬或其他設(shè)計限制，類型二信息可以從RTP信號音包400中省略。
根據(jù)本發(fā)明的一個實施例，呼叫終端106可以開始接收來自網(wǎng)關(guān)202的RTP信號音包。呼叫終端106可以試圖利用RTP信號音包來重建信號音事件。如果一個或多個RTP信號音包丟失，則呼叫終端106可以使用類型三信息來獲取由被擾亂的或丟失的包所攜帶的信息。
由于RFC 2833規(guī)范已經(jīng)定義了可達5個級別的冗余，因此應(yīng)該理解，使用這5個級別的其中一個或多個，類型三信息可以被插入RTP信號音包。以這種方式，TMM 204提供更健全的和更靈活的信號音恢復(fù)功能，同時只加入相對較少的額外開銷或延遲，并且在某些情況下，根本沒有額外開銷或延遲。還應(yīng)該理解，可以使用滿足具體系統(tǒng)的設(shè)計或性能限制的類型二信息和類型三信息的任意組合來建立RTP包。
雖然如這里描述的，已經(jīng)說明了本發(fā)明實施例的某些特征，但本領(lǐng)域的技術(shù)人員可進行許多改進、置換、變化和等同替換。因此，應(yīng)該理解的是，所附權(quán)利要求旨在涵蓋所有這些落在本發(fā)明實施例的真正精神內(nèi)的改進和變化。
權(quán)利要求
1.一種傳遞信號音的方法，包括接收代表信號音的信息；創(chuàng)建具有所述信息的第一部分的第一包；傳送所述第一包至接收器；創(chuàng)建具有所述信息的所述第一部分和第二部分的第二包；和傳送所述第二包至所述接收器。
2.如權(quán)利要求1所述的方法，其中所述信息代表雙音多頻數(shù)字。
3.如權(quán)利要求1所述的方法，其中根據(jù)RFC 2833完成創(chuàng)建所述第一包和所述第二包。
4.如權(quán)利要求1所述的方法，其中根據(jù)RTP協(xié)議完成傳送所述第一包和所述第二包。
5.如權(quán)利要求1所述的方法，其中所述信息代表所述信號音的名稱。
6.如權(quán)利要求1所述的方法，其中所述信息代表所述信號音的頻率。
7.一種傳遞信號音的方法，包括接收具有代表信號音的信息的第一部分的第一包；接收具有所述信息的所述第一部分和第二部分的第二包。
8.如權(quán)利要求7所述的方法，還包括利用所述第一和第二部分來再現(xiàn)所述信號音。
9.如權(quán)利要求7所述的方法，其中所述信息代表雙音多頻數(shù)字。
10.如權(quán)利要求7所述的方法，其中根據(jù)RFC 2833創(chuàng)建所述第一包和所述第二包。
11.如權(quán)利要求7所述的方法，其中根據(jù)RTP協(xié)議接收所述第一包和所述第二包。
12.如權(quán)利要求7所述的方法，其中所述信息代表所述信號音的名稱。
13.如權(quán)利要求7所述的方法，其中所述信息代表所述信號音的頻率。
14.一種傳遞信號音的方法，包括接收代表信號音的信息；創(chuàng)建具有所述信息的第一部分的第一包；傳送所述第一包至接收器；創(chuàng)建具有所述信息的所述第一部分和第二部分的第二包；傳送所述第二包至所述接收器；接收所述第一和第二包；和利用所述第一和第二部分再現(xiàn)所述信號音。
15.如權(quán)利要求14所述的方法，其中所述信息代表雙音多頻數(shù)字。
16.一種器件，包括存儲介質(zhì)；所述存儲介質(zhì)包括被存儲的指令，當處理器執(zhí)行所述指令時，導(dǎo)致接收代表信號音的信息、創(chuàng)建具有所述信息的第一部分的第一包、傳送所述第一包至接收器、創(chuàng)建具有所述信息的所述第一部分和第二部分的第二包以及傳送所述第二包至所述接收器。
17.如權(quán)利要求16所述的器件，其中當處理器執(zhí)行所述被存儲的指令時，還導(dǎo)致接收所述第一和第二包以及利用所述第一和第二部分再現(xiàn)所述信號音。
18.一種系統(tǒng)，包括適于傳遞信號音的計算平臺；所述平臺還適于接收代表信號音的信息、創(chuàng)建具有所述信息的第一部分的第一包、傳送所述第一包至接收器、創(chuàng)建具有所述信息的所述第一部分和第二部分的第二包以及傳送所述第二包至所述接收器。
19.如權(quán)利要求18所述的系統(tǒng)，其中所述平臺還適于接收所述第一和第二包，并且利用所述第一和第二部分再現(xiàn)所述信號音。
全文摘要
本說明描述了一種傳遞信號音的方法和裝置。
文檔編號H04M7/00GK1623303SQ03800475
公開日2005年6月1日 申請日期2003年8月1日 優(yōu)先權(quán)日2002年8月6日
發(fā)明者凱·苗 申請人:英特爾公司