專利名稱：在網絡中傳遞信號音信息的制作方法
背景技術：
包語音(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日
發明者凱·苗 申請人:英特爾公司