基於VOIP的SIP協議分析
1.1學習VOIP軟體X-Lite的使用;
1.2學習SIP協議的工作流程;
1.3瞭解VOXALOT的工作機制;
1.4練習使用wireshark抓包軟體;
1.5利用wireshark抓包軟體分析SIP協議的通訊過程
PC: win7;
CPU: Intel Core2
記憶體:2G;
主頻:2.0GHz
wireshark: v 1.2.6
VOIP軟體 :X-Lite Version 3.0 build 56125
3.1概念簡述:
.SIP:會話發起協議(Session
Initiation Protocol)是一個應用層的信令控制協議。用於建立、修改和釋放一個或多個參與者的會話。這些會話可以好似
SDP:會話描述協議(Session Description Protocol或簡寫SDP)描述的是流媒體的初始化引數。此協議由IETF發表為 RFC 2327。
RFC:Request For Comments (RFC),是一系列以編號排定的檔案。檔案收集了有關因特網相關資訊,以及UNIX和因特網社群的軟體檔案。目前RFC檔案是由Internet Society(ISOC)所贊助發行。基本的因特網通訊協定都有在RFC檔案內詳細說明。
.RTP:實時傳送協議(Real-time Transport Protocol或簡寫RTP)。RTP協議詳細說明了在網際網路上傳遞音訊和視訊的標準資料包格式。它一開始被設計為一個多播協議,但後來被用在很多單播應用中。RTP協議常用於流媒體系統(配合RTSP協議),視訊會議和一鍵通(Push to Talk)系統(配合H.323或
.RTCP:實時傳輸控制協議(Real-time Transport Control Protocol或RTP Control Protocol或簡寫RTCP)是[[實時傳輸協議|實時傳輸協議(RTP)]]的一個姐妹協議。RTCP由RFC 3550定義(取代作廢的RFC 1889)。RTCP為RTP媒體流提供通道外(out-of-band)控制。RTCP本身並不傳輸資料,但和RTP一起協作將多媒體資料打包和傳送。RTCP定期在流多媒體會話參加者之間傳輸控制資料。RTCP的主要功能是為RTP所提供的服務質量(Quality of Service)提供反饋。
A.SIP通訊概述:
B.SIP客戶端註冊過程
剛啟動X-Lite的時候,X-Lite會將本地號碼註冊到相應的域名伺服器上。註冊過程如下圖所示:
傳送註冊request |
驗證成功 |
Y |
N
C.SIP會話發起
我們假設Alice向Bob發起會話請求,則過程如下圖所示:
圖(4) 會話發起過程
a)Alice首先發起一個INVITE資料包到其代理伺服器,如上圖中INVITE F1;每個INVITE資料包包頭含有如下資料域:
圖(5)INVITE資料包包含域
lVia:Alice用來接收響應包的終端地址。因為,在SIP協議中,是允許主叫方重定位此次通話的。也即是,可以允許主叫方用A手機撥打C的號碼,但是卻通知C將資訊傳到B手機。該域中還包括一個branch,用來標識此次互動。
lMax-Forwards:該域表示包被允許傳送的最大通訊距離
lTo:被叫方的ID
lFrom:主叫方ID
lCall-ID:基於”To”和”From”的會話ID。和前兩者共同標識一個唯一的會話
lCSeq:標識在一次會話中request傳送的個數
lContact:標識資料包發起者
lContent-Type:標識資料包內容的型別
lContent-Length:標識資料包內容的長度
b)Alice的代理端收到Alice的請求之後,會要求Alice對自己的身份進行認證。
這個認證過程如下圖所示:
代理端向Alice傳送認證請求包407 |
Alice出示證件 |
Y |
N |
c)Alice的代理端將INVITE路由到Bob的代理端,並返回一個100 Trying資料包
代理端通過INVITE資料包中的”To”域,獲取到INVITE的下一個目的地址,即Bob的代理端。然後將該資料包轉發出去。而後,再向自己的上一跳返回一個100 Trying資料包,通知Alice,連線正在建立中。
d)Bob的代理端將INVITE轉發給Bob,並返回100 Trying資料包
Bob的代理端在收到INVITE後,通過本地資料庫查詢到Bob,然後將該INVITE資料包發給Bob。同時返回一個100 Trying資料包給上一跳。
e)Bob接受Alice的呼叫,並返回180 Ring和200 OK 資料包到Alice
Bob收到從自己的代理端來的INVITE並開始響鈴。同時,將響鈴訊號傳送給代理端,代理端。之後,該Ringing包將沿著INVITE的逆向路徑到達Alice。如果,Bob在接到響鈴後,接聽電話,那麼Bob的客戶端將傳送一個200 OK包,該包到達Alice的路徑和上面的Ringing資料包的路徑一樣。此時連線其實已經建立起來。
f)Alice返回ACK確認,從而建立起連線
Alice收到相應的200 OK包之後,將向Bob返回一個ACK包進行確認。到此,該連線正式建立起來。
D.SIP通話過程
在建立起會話之後,通訊雙方通過各自的代理伺服器進行通訊。通訊的內容則採用一種稱作RTP的協議來傳輸。通訊的內容:可以包括語音、視訊和電子郵件。
E.SIP會話結束
會話結束動作可以由通訊雙方中的任何一端發起。會話結束動作由資料包BYE標識。一旦某個使用者收到BYE包,那麼就會返回一個ACK資料包,從而徹底中斷連線
實驗內容 |
實驗結果 |
搭建實驗平臺,獲得sip賬號 |
成功 |
通過美國的遠端伺服器實現點到點通話 |
成功 |
區域網內註冊成為sip Server並分配分機 |
成功 |
登入區域網內的sip server成功註冊本分機 |
成功 |
區域網內作為分機與另一分機通話 |
成功 |
a)去官網下載wiresharp軟體
b)執行安裝程式,即可完成安裝
a)去官方網站下載X-Lite
http://www.counterpath.com/x-lite.html
b)執行下載好的安裝程式,即可完成安裝。
為了使得我們能夠順利利用X-Lite進行免費通話,我們需要到VOXALOT去註冊賬號。該賬號的作用類似於我們的手機號碼。
本次實驗中,我註冊的賬號為:198772 伺服器為:us.voxalot.com
Display Name: 本地顯示使用者名稱
User Name: 申請的賬號名
Password: 賬號對應的口令
Authorization user name: 採用預設(空白)
Domain: 伺服器端域名
proxy: 代理端域名
Dialing plan: 採用預設設定
u執行wireshark,啟動wireshark,設定正確的抓包規則,開始抓包.
u撥打對方電話,進行通話
獲取對方的號碼之後,按照正常撥打電話的流程即可完成電話的撥打。
u結束通話,分析資料包
在結束通話之後,停止wireshark抓包動作。在Filter域中輸入”sip”。
5.3區域網內註冊成為sip Server並分配分機
啟動minisipserver,自動將伺服器ip配置為當前主機ip,並分配四個分機100,101,102,103
使用者100和101註冊成功,miniSipServer的MySql資料庫中自動記錄使用者100和101的ip地址,便於在以後的通訊中查詢102使用者的地址。
使用者註冊過程中抓包如下:
5.5區域網內作為分機與另一註冊過的分機通話
在結束通話之後,停止wireshark抓包動作。在Filter域中輸入”sip”。
6.1客戶端向伺服器端註冊
從上圖中可以看出,客戶端在啟動的時候,會主動向伺服器端註冊。註冊過程如下:
a) 客戶端向伺服器端傳送Request REGISTER資料包,請求註冊,該包的SIP頭如下:
b) 伺服器端需要客戶端出示證明,因此針對上面的註冊包,返回一個401包;
c) 客戶端再次向伺服器端發起Request REGISTER資料包,請求認證,其SIP頭如下:
從上面兩幅圖中可以看出,第二次申請認證的資料包中,明顯多了一個Authorization域。
d)針對上面的申請,伺服器端返回一個Status 200 OK包,表示通過認證。
e)註冊成功後,客戶端向伺服器端查詢當前的連線狀況,因此傳送Request SUBSCRIBE
f)同樣伺服器端要求客戶端再次出示“證件”,於是傳送了Status: 407 Proxy Authentication Required
g)客戶端再次發起查詢資料包,並在其中新增相應的認證,如下圖所示:
6.2客戶端之間建立連線
從上面的資料可以看出通訊流程:
a) 客戶端向伺服器端傳送Request INVITE資料包,請求和198771建立連線
b) 伺服器端轉發相應的INVITE資料包(上圖中沒反映出來),並且向客戶端返回一個100 Trying資料包
c) 當被呼叫端發出Ring信後號,代理端再返回相應的Ring資料包
d) 當被呼叫端接受呼叫後,發出Status 200 OK資料包,並被代理端轉發到客戶端
6.3客戶端之間通訊
當經過上述步驟,建立連線之後,就開始雙方的通訊過程。通訊過程中使用RTP協議進行通訊資料的傳送。
上圖中所示即為雙方通訊過程。其中111.186.57.199為主叫伺服器IP;111.186.57.3為被呼叫客戶端IP。
通過和上面連線建立時的圖片相比較,可以發現,當經過代理端建立連線之後的通話資料包將不再通過代理端傳輸,而是直接在通話雙方之間傳輸。這個是非常合理的,因為雙方經過連線建立過程已經相互得知對方的IP地址,因此就沒有必要再通過伺服器端來傳送資料包。這樣使得通話的實時性更加可靠。
由於使用miniserver的sip協議過程與上述過程大致相似,本論文中不進行詳細分析。
6.4通話音訊還原
WireShark自身就整合有語音播放器,可以播放通話中的語音資訊。(之前的VoIP介面點選Player進入,解碼後如下圖所示)
圖12.WireShark Player
此外,通過WireShark強大的功能與相關格式轉換工具Cool Edit,我們能夠成功地將儲存在RTP報文中的語音資訊還原。
具體為選取通話中的RTP報文,進入Telephony->RTP->Stream Analysis。
圖13.Stream Analysis工具
然後將之通過Save payload轉化為.raw格式的音訊檔案,最終通過Cool Edit軟體進行格式轉換,轉換成wav格式。
在試驗過程中,我發現通過wireshark自帶的Telephony功能,只能夠將抓獲的通話資料包還原,但是不能播放還原之後的資料包中的聲音,只有當X-lite開啟record功能時,才能正確擷取資料包中的聲音。然而當我做完實驗,與別人交流時,卻發現有些同學在做實驗時,X-lite沒有開啟record功能也能正確擷取資料包中的聲音,該問題是我大為困惑。後來仔細比對之後,才明白是軟體問題。雖然X-lite和3CX Phone的Server-Client軟體都能成功地進行VOIP電話,然而WireShark進行報文擷取及報文分析過程中,雖然能夠識別SIP協議的相關報文,並能作出流程圖,但卻無法識別具體通話中所使用的RTP。在WireShark中顯示“Unknown RTP version”,可能是X-Lite使用的RTP版本與WireShark不相容。導致WireShark無法根據RTP報文還原出語音。
通過此次實驗,我學到了如下東西:
a) Wireshark軟體的使用
b) X-Lite 電話的使用
C) 對SIP協議有了一個比較深入的認識
d) 對VOIP的通話過程和工作原理也有了比較側地的認識。
由於是大二學生,以前並沒有接觸過wireshark軟體,導致本實驗開始時困難重重。但是在學長們的幫助下,還是順利完成了實驗,並且收穫不小。
注:由於本次實驗進行了多次,而且每次地點不同,導致IP地址也各不相同。而且由於對wirreshark軟體的深入瞭解,聲音提取實驗是在之後的實驗中進行的。所以原始報文比較多,不好意思……
附錄1:SIP常見資料包型別和作用
資料包 |
作用 |
備註 |
Request: Invite |
邀請對方參與會話 |
資料包頭中各域的解釋: via: 記錄SIP的版本/使用傳輸協議,以及會話發起者。 branch: 記錄此次會話 Max-Forwards:最大傳輸跳數 Contact: 本機的IP地址以及正在使用的傳輸協議 To: 呼叫的目的方 From:呼叫的發起方 Call-ID:標識此次通話的ID; 它和To、From唯一標識一個會話 CSeq:每次發起request,該域就增加1;同時後面標識使用的method,該包的作用 Content-Type:描述資料包的內容 Content-Length:內容message body長度。以8進位制計數,單位為byte |
Status 407 |
代理端要求客戶端認證 |
|
Request:ACK |
針對上面407的回覆 |
|
Status:100 Trying |
通知上一跳節點正在為之轉發資料包 |
|
Status:477 |
下一條出錯 |
|
Request:SUBSCRIBE |
查詢當前的服務否可用 |
|
Status:200 OK |
標識對請求的肯定回答 |
|
Request:NOTIFY |
在subscribe查詢過程中,如果會話狀態發生改變,則發出的通知包,收到這個資料包的節點會返回一個Status 200 |
|
Request:REGISTER |
客戶端向代理端發起註冊請求 |
|
Status: 401 |
代理端不接受發客戶端註冊請求包中的證書資訊。之後,客戶端可以通過回覆Status 200,來“強制”代理端檢視相應的資訊 |
|
Request:CANCEL |
用於結束一次呼叫請求request |
|
Status: 603 |
被叫端拒絕連線 |
|
Status: BYE |
作用同CANCEL,但是不需要OK進行確認 |