什麼是空號識別
全稱應該是撥號音分析或者號碼狀態識別，大家都叫空號檢測，或者空號識別。原理就是通過分析撥打電話接通之前的聲音，一般有這幾種類型，長嘟的回鈴音，短嘟嘟的忙音，彩鈴，通話中，空號，關機等交換機給出的各種提示。分析程序通過分析聲音的頻率和特徵，可以識別出現回鈴音、忙音、彩鈴，通過語音識別或者樣本庫比較可以識別出通話中，空號，關機，無人接聽等交換機給出的被叫狀態。
空號識別的用處
主要用戶自動外呼系統準確的獲取呼叫失敗原因，執行各種業務操作比如電話會議，電話通知，呼叫轉接可以快速返回呼叫失敗，不需要等60秒後電路主動掛斷才知道呼叫失敗。也可以用於外呼系統節省線路資源，提高線路使用率和加快外呼速度，提高坐席接通率。
可以識別出多少狀態
回鈴，忙音，彩鈴等信號音以及下面的da2的狀態列表
| id | name | alias | description |
|---|---|---|---|
| 2 | 關機 | power off | 關機 |
| 3 | 空號 | does not exis | 空號 |
| 4 | 停機 | out of service | 停機 |
| 5 | 正在通話中 | hold on | 正在通話中 |
| 6 | 用戶拒接 | not convenient | 用戶拒接 |
| 7 | 無法接通 | is not reachable | 無法接通 |
| 8 | 暫停服務 | not in service | 暫停服務 |
| 9 | 用戶正忙 | busy now | 用戶正忙 |
| 10 | 撥號方式不正確 | not a local number | 撥號方式不正確 |
| 11 | 呼入限制 | barring of incoming | 呼入限制 |
| 12 | 來電提醒 | call reminder | 各類祕書服務 |
| 13 | 呼叫轉移失敗 | forwarded | 呼叫轉移失敗 |
| 14 | 網絡忙 | line is busy | 網絡忙 |
| 15 | 無人接聽 | not answer | 無人接聽 |
| 16 | 欠費 | defaulting | 欠費 |
| 17 | 無法接聽 | cannot be connected | 無法接聽 |
| 18 | 改號 | number change | 改號 |
| 19 | 線路故障 | line fault | 線路不能呼出，比如SIM卡欠費 |
| 20 | 稍後再撥 | redial later | 各種稍後再撥提示 |
怎麼使用它
- FreeSWITCH
有爲FreeSWITCH開發專用模塊，mod_da2。 - Asterisk
使用SIP抓包識別接口，SIP抓包識別接口。 - 錄音文件
使用文件識別接口，錄音文件識別接口。 - VOS GOIP 語音網關
使用直接外呼識別，直接外呼識別。 - 其他
使用二次開發接口，二次開發接口。
開發過程
大約2008年的時候，有一天老闆問我：“我們外呼很多都是無法接通的號碼，需要大約1分鐘纔會掛斷，這樣即浪費線路資源（那個時候每E1大約需要3000月租費用），又導致坐席很久纔可以接通一個電話。有沒有辦法把無法接通的立即掛斷了呢？”。
我想了想說：“雖然7號信令協議裏有一個掛斷原因，但是大部分時候不管空號，關機，還是通話中，掛斷原因碼都是一樣的，而且都需要大約60s纔會返回呼叫失敗，應該沒辦法實現這個功能的。”
老闆說：“用語音識別呢？”
我：“這個我得研究研究。”
我的號碼狀態識別（簡稱空號檢測）研究就這樣開始了。
插曲：大約這個時候藍星際公司的老總朱東寧先生成功開發出了一個聲音模式匹配的識別引擎。我有向老闆推薦直接購買，大家都懂老闆需要的是免費的，我只能自己慢慢摸索了。
剛開始我嘗試用 XP系統自帶的《Microsoft Speech SDK》的命令識別，做了一個demo，錄製了一些聲音，設置了‘關機’，‘空號’，‘通話中’等命令，識別率實在太差，沒法實用。那個時候除了微軟的SDK，能知道的就是 IBM也有一個識別系統，可是根本沒地方下載。朱總的模式識別是怎麼個原理我又不懂，我只能另闢蹊徑，到處搜索波形比較算法。功夫不負有心人。經過長達2個星期的到處搜索和分析後，終於找到一個感覺靠譜的波形比較算法，於是我按照那個算法寫了一個代碼，然後把1個聲音文件稍微修改一點和原文件比較，奇蹟發生了，返回的文件相識度和文件實際差異是一致的，但美中不足的是這個算法要求2個波形長度必須一樣。經過我一個晚上的苦思冥想後，這個問題也想到了解決辦法，號碼狀態識別的第一個雛形就這樣產生了。
雛形版本上線運行後發現的主要問題 聲音文件聽上去感覺一樣的，但是不同設備的錄音文件用cooledit打開，波形卻有些變化，算法比較的結果是相識度低於閾值，導致無法識別。
後面，公司停止運營呼叫中心了，我沒事的時候，還在繼續想着怎麼提高號碼狀態識別的準確性，後來看了很多資料，語音識別等等都是對頻域的數據進行分析，而不是時域的數據。也就是FFT後的數據。
FFT後的數據到底什麼含義，好吧繼續研究，看了大部分文章還是一頭霧水，終於在看過《FFT結果的物理意義》這個文章後5遍之後，我大徹大悟，明白了FFT後數據的含義。很多年前我研究過一個圖像相識度比較算法，我把那個算法套用到FFT後的數據，號碼狀態識別1.0 就這樣誕生了。
插曲 任何識別算法都需要對聲音進行VAD，也就是端點檢測，沒有一種可靠的VAD算法，相識度比較算法是沒法在實際環境中使用的，我花了大量時間寫出可靠的VAD算法 號碼狀態識別1.0纔開始具備商用條件
電話回鈴聲音 一般可能是 忙音信號，回鈴音信號，彩鈴聲音，空號、關機等提示音。號碼狀態識別1.0 對彩鈴的檢測原理是如果持續大聲超過一定時間認爲是彩鈴，彩鈴歌曲千變萬化，1.0檢測原理過於單一，對彩鈴的識別率不高，爲了解決這個問題，樂器識別，鳥聲識別，哼唱識別的等等代碼和算法我都下載來測試和研究，這樣沒頭緒的折騰了好幾個月，終於我寫出了一個比較可靠的伴奏識別算法，可以 1-2秒內識別出是否是音樂。 號碼狀態識別 1.1,就這樣誕生了。
隨着用戶的增加，號碼狀態識別 1.1的缺陷也暴露出來，每個用戶都要花費時間去收集樣本庫，G729,GSM等轉碼後的聲音識別率會下降，於是我決定重新設計一個新的算法來解決這些問題。2.0就這樣開始了。
插曲 在研究彩鈴識別的時候發現python的dejavu項目（音樂指紋算法）， https://github.com/worldveil/dejavu http://willdrevo.com/fingerprinting-and-audio-recognition-with-python/ 我一度準備使用這個算法作爲 號碼狀態識別2.0算法。花費了3個月時間把這個算法改成C++代碼，經過測試效果太差，只能用於音樂聲音檢索，不能用於人說話聲檢索。
號碼狀態識別2.0開發過程也是非常曲折，先是花費大量時間把《Audio Fingerprinting with Python and Numpy》這個改成c++，然後是研究梅爾頻率倒譜系數(MFCC)，（MFCC用於號碼狀態檢測也不是很靠譜，主要問題1不同編碼聲音MFCC後比較差異太大，2速度慢）等中間爲了維持生活，也得不斷接些外包項目中斷一下，每每是剛有點眉目，中間接一個外包項目，然後重新開始思路又亂了。有一次躺在牀上想到一個新算法，其他項目忙幾天這個思路就再也想不起來了，不過幸運是今天，號碼狀態識別2.0終於可以發佈了。