一種二次撥號接收的方法
【專利摘要】本發明公開一種二次撥號接收的方法，該方法包含以下步驟：定義RFC2833事件類型；在組建媒體傳輸報文時，添加RFC2833的包頭結構；根據媒體傳輸報文攜帶的RFC2833數據結構判斷對方為二次撥號；根據負載類型的值，判斷本次撥號為RFC2833二次撥號事件；根據RFC2833的數據結構來判斷一次撥號結束，以及下一次撥號的開始；最終二次撥號結束。本發明組建媒體傳輸報文時加上RFC2833的包頭結構，根據包頭結構獲取每一次遠端所撥號的號碼，并進行保存統計來對比遠端傳輸的號碼是否相符合，在這里設定一個狀態機制，來判斷每次傳輸的號碼的結束，以防收到重復的號碼。
【專利說明】一種二次撥號接收的方法
【技術領域】
[0001]本發明涉及一種遠程撥號接收方法，具體涉及一種用RFC2833傳輸方式實現二次撥號接收的方法。
【背景技術】
[0002]雙音多頻(Dual-toneMult1-frequency, DTMF), 一個 DTMF 信號由兩個頻率的音頻信號疊加構成。這兩個音頻信號的頻率來自兩組預分配的頻率組:行頻組或列頻組。每一對這樣的音頻信號唯一表示一個數字或符號(通常就是按鍵號碼)。
[0003]例如，假如撥打了 10086，它會有相應的語音提示信息:撥O鍵，接入人工幫助....撥I鍵，然后進行相應的操作。那么10086是如何了解你到底撥了哪個鍵，這就需要一種方式將我們具體撥哪個號碼通知給它，這就是DTMF的用途，DTMF之前使用特定的脈沖來代表相應的號碼。
[0004]目前傳送DTMF信號普遍有三種方式:
A.通過通信協議傳輸(會話發起協議(SIP, Session Initiation Protocol)信令):
用SIP信令的INFO方法攜帶DTMF信號。
[0005]該方法是用SIP信令的INFO方法來明文定義來代表DTMF信號。主要缺陷是因為SIP控制信令和媒體傳輸(RTP)是分開傳輸，很容易造成DTMF信號和媒體包不同步。
[0006]舉個例子，在Voice Mail應用中，用戶根據提示音輸入一個DTMF信號，隨后開始留言。Server是在接受到該DTMF信號后開始保存用戶的留言。然而由于DTMF信號是通過SIP信令來傳輸的，而媒體流是通過RTP來傳輸的，有可能用戶留言的RTP包先到，而該DTMF信號的INFO消息延遲，導致Server不保存用戶的語音留言直至接受到INFO消息。
[0007]B.通過RTP的數據內容傳輸(Inband):1n Band是指直接將DTMF的音頻數字信號不經任何處理直接打成RTP包在IP網中傳輸。其中可能和用戶的語音媒體流混合在一起傳輸。程序要獲知哪個包有DTMF信號，是什么DTMF信號，必須實時檢查每個RTP包里面的媒體流數據，分析它的頻域。主要缺陷是由于網絡丟包的影響，有時會造成DTMF信號丟失，而且DTMF音混合在語音包中，容易產生偏差，造成信號失真。
[0008]C.通過rfc2833的規則和格式包傳輸:
RFC2833是DTMF信號按照一個的規則和格式組成一個數據包，有專門的RTP包進行標識，在RTP包的頭域中就可得知該包是DTMF包，并且知道是什么DTMF信號。RFC2833專門對此有定義。該方法是將DTMF信號和媒體流一樣，用RTP包來傳輸，因而沒有DTMF信號和媒體流不同步的問題，接收端接收后進行解析，再還原成相應的DTMF信號，對丟包的容錯性強以及識別差錯率低，相對來說比較成熟。
[0009]目前，現有技術中很少有通過RFC2833來獲取dtmf信號傳輸的，一般都是采用帶內方式，以及SIP的INFO方式獲取。
【發明內容】
[0010]本發明提供一種二次撥號接收的方法，準確快速的獲取遠端撥號的號碼，并存儲起來，便于統計和確認對方的撥號號碼。
[0011]為實現上述目的，本發明提供一種二次撥號接收的方法，其特點是，該方法包含以下步驟:
定義RFC2833事件類型；
在組建媒體傳輸報文時，添加RFC2833的包頭結構；
根據媒體傳輸報文攜帶的RFC2833數據結構判斷對方為二次撥號；
根據負載類型的值，判斷本次撥號為RFC2833 二次撥號事件；
根據RFC2833的數據結構來判斷一次撥號結束，以及下一次撥號的開始；
最終二次撥號結束。
[0012]上述定義RFC2833事件類型包含:定義RFC2833報文頭，以及對應判斷確認本次操作為RFC2833事件，并通過RFC2833傳輸方式繼續二次撥號接收。
[0013]若本次操作不是RFC2833事件，則采用現有技術通用的方式進行二次撥號。
[0014]若根據媒體傳輸報文攜帶的RFC2833數據結構判斷對方不是二次撥號，則按照正常的媒體傳輸報文傳輸，并去除RFC2833報文頭。
[0015]若根據負載類型的值判斷撥號不是RFC2833 二次撥號事件，則按照正常的RFC2833報文發出。
[0016]上述最終二次撥號結束后，將對應的所有的撥號結果存儲，發送到遠端的模擬電話業務口。
[0017]本發明用RFC2833傳輸方式實現二次撥號接收的方法和現有技術相比，其優點在于，本發明在組建媒體傳輸報文的時候，加上一個RFC2833的包頭結構，并根據這個包頭結構，來獲取每一次遠端所撥號的號碼，并進行保存統計來對比遠端傳輸的號碼是否相符合，在這里設定一個狀態機制，來判斷每次傳輸的號碼的結束，以防收到重復的號碼。
【專利附圖】
【附圖說明】
[0018]圖1為本發明一種二次撥號接收的方法的流程圖。
【具體實施方式】
[0019]以下結合附圖，進一步說明本發明的具體實施例。
[0020]如圖1所示，本發明公開一種用RFC2833傳輸方式實現二次撥號接收的方法，該方法包含以下步驟:
步驟1、定義RFC2833事件類型。該定義操作包含:定義RFC2833報文頭，以及對應判斷本次操作是否是RFC2833事件，若是RFC2833事件則采用本發明的所公開的二次撥號接收方法，若否，則采用現有技術通用的方式進行二次撥號。
[0021]步驟2、在組建媒體傳輸(RTP)報文時，添加RFC2833的包頭結構。
[0022]步驟3、根據媒體傳輸(RTP)報文攜帶的RFC2833數據結構，來判斷對方是否是二次撥號，若是，則跳轉到步驟4，若否，則按照正常的RTP報文傳輸，去除RFC2833報文頭。
[0023]步驟4、如果是二次撥號,payload代表負載類型,通過payload的值來判斷是否為RFC2833 二次撥號事件。判斷RFC2833數據結構的payload值是否對應為101，若是，則跳轉到步驟5 ;若否，則按照正常的RFC2833報文發出。通常中興華為的mgc服務器payload都為101。
[0024]步驟5、根據RFC2833的數據結構來判斷一次撥號結束，以及下一次撥號的開始。
[0025]具體實現可如下示例:判斷endOfEvent是否等于I,如果不是I,為O的話,需要同時判斷 RecvState 為 WAIT4NextEvStart ;如果是 I,將 RecvState 置為 WAIT4CurEvEnd,然后返回。
[0026]只有當endOfEvent等于I與state等于WAIT4CurEvEnd的時候才代表一個digitev的結束。
[0027]步驟6、最終二次撥號結束，將對應的所有的撥號結果存儲，發送到遠端的模擬電話業務(pots) P ο
[0028]盡管本發明的內容已經通過上述優選實施例作了詳細介紹，但應當認識到上述的描述不應被認為是對本發明的限制。在本領域技術人員閱讀了上述內容后，對于本發明的多種修改和替代都將是顯而易見的。因此，本發明的保護范圍應由所附的權利要求來限定。
【權利要求】
1.一種二次撥號接收的方法，其特征在于，該方法包含以下步驟: 定義RFC2833事件類型； 在組建媒體傳輸報文時，添加RFC2833的包頭結構； 根據媒體傳輸報文攜帶的RFC2833數據結構判斷對方為二次撥號； 根據負載類型的值，判斷本次撥號為RFC2833 二次撥號事件； 根據RFC2833的數據結構來判斷一次撥號結束，以及下一次撥號的開始； 最終二次撥號結束。
2.如權利要求1所述的二次撥號接收的方法，其特征在于，所述定義RFC2833事件類型包含:定義RFC2833報文頭，以及對應判斷確認本次操作為RFC2833事件，并通過RFC2833傳輸方式繼續二次撥號接收。
3.如權利要求2所述的二次撥號接收的方法，其特征在于，若本次操作不是RFC2833事件，則采用現有技術通用的方式進行二次撥號。
4.如權利要求1所述的二次撥號接收的方法，其特征在于，若根據媒體傳輸報文攜帶的RFC2833數據結構判斷對方不是二次撥號，則按照正常的媒體傳輸報文傳輸，并去除RFC2833報文頭。
5.如權利要求1所述的二次撥號接收的方法，其特征在于，若根據負載類型的值判斷撥號不是RFC2833 二次撥號事件，則按照正常的RFC2833報文發出。
6.如權利要求1所述的二次撥號接收的方法，其特征在于，所述最終二次撥號結束后，將對應的所有的撥號結果存儲，發送到遠端的模擬電話業務口。
【文檔編號】H04L29/06GK103747007SQ201410026588
【公開日】2014年4月23日 申請日期:2014年1月21日 優先權日:2014年1月21日
【發明者】趙勇 申請人:上海斐訊數據通信技術有限公司