RFC3581——SIP中的rport機制
記錄人:阿蜜果
日期:2010-5-28
1. 介紹
RFC3581的下載地址:http://www.ietf.org/rfc/rfc3581.txt
該協(xié)議比較簡短,主要用于描述rport(response-port)機制。
1.1 NAT分類
NAT:網(wǎng)絡(luò)地址轉(zhuǎn)換(NAT,Network Address Translation)屬接入廣域網(wǎng)(WAN)技術(shù),是一種將私有(保留)地址轉(zhuǎn)化為合法IP地址的轉(zhuǎn)換技術(shù),它被廣泛應(yīng)用于各種類型Internet接入方式和各種類型的網(wǎng)絡(luò)中。原因很簡單,NAT不僅完美地解決了lP地址不足的問題,而且還能夠有效地避免來自網(wǎng)絡(luò)外部的攻擊,隱藏并保護網(wǎng)絡(luò)內(nèi)部的計算機。
NAT常用的分類如下:
l Full Cone NAT(完全圓錐型)
l Address Restricted Cone NAT(地址限制圓錐型 )
l Port Restricted Cone NAT(端口限制圓錐型)
l Symmetric NAT(對稱型)

1.1.1 完全圓錐型NAT
在完全圓錐型NAT(Full Cone NAT)中,NAT會將客戶機地址{X:y}轉(zhuǎn)換成公網(wǎng)地址{A:b}并綁定。任何包都可以通過地址{A:b}送到客戶主機的{X:y}地址上。如圖所示:

1.1.2 地址限制圓錐型NAT
地址限制圓錐型NAT(Address Restricted Cone NAT)會將客戶機地址{X:y}轉(zhuǎn)換成公網(wǎng)地址{A:b}并綁定,只有來自主機{P}的包才能和主機{X:y}通信。如下圖所示:

1.1.3 端口限制圓錐型NAT
端口限制圓錐型NAT(Port Restricted Cone NAT)會將客戶機地址{X:y}轉(zhuǎn)換成公網(wǎng)地址{A:b}并綁定,只有來自主機{P,q}的包才能和主機{X:y}通信。如下圖所示:

1.1.4 對稱型NAT
對稱型NAT(Symmetric NAT)會將客戶機地址{X:y}轉(zhuǎn)換成公網(wǎng)地址{A:b}并綁定為{X:y}|{A:b}<->{P:q}。對稱型NAT只接受來自{P:q}的incoming packet,將它轉(zhuǎn)給{X:y} ,每次客戶機請求一個不同的公網(wǎng)地址和端口,NAT會新分配一個端口號{C,d} 。如下圖所示:

1.2問題描述
1.2.1 SIP Proxy無法穿過NAT回送SIP信令
因為SIP信令中的From和Contact頭域記錄的是私網(wǎng)地址和端口,NAT無法識別和轉(zhuǎn)換。如圖所示:

1.2.2 使用UDP Hole Punching的問題

這個內(nèi)網(wǎng)的NAT上打了一個方向為211.136.91.58的“洞”,(這就是稱為UDP Hole Punching的技術(shù))以后211.136.91.58就可以通過這個洞與內(nèi)網(wǎng)的192.168.1.223聯(lián)系了,但是其他的IP不能利用這個洞。
在沒有活動的時候,這個Hole會過期:
NAT對于地址轉(zhuǎn)換關(guān)系是有一定生命期的,某個地址轉(zhuǎn)換后在一段時間內(nèi)沒有被使用將會被清除,當(dāng)這個業(yè)務(wù)流再次出現(xiàn)時,將會建立一個新的地址轉(zhuǎn)換關(guān)系。
SIP代理無法穿越
SIP在UDP和TCP上操作。當(dāng)在UDP中使用的時候,對請求的響應(yīng)被發(fā)送給請求所來自的地址,端口字段帶在請求的Via頭字段中。一半以上的信息(例如:IP地址)帶在 IP包頭中,還有一半的信息(例如:端口信息)帶在SIP消息頭中。SIP這樣做的原因是為了監(jiān)聽所有的信息,包括請求消息和響應(yīng)消息。
但是這種方式在客戶端在 NAT中的情況不適用,在NAT的環(huán)境中,回應(yīng)可能發(fā)送不過去,因為與在請求中找到的地址不一樣,而且此前也沒有方法讓客戶端來得到源端口信息。
2. NAT的常用解決方案
解決NAT穿越有很多中解決方案,常用的有:
2.1 ALG(Application Level Gateway)
可以識別SIP信令,能夠適當(dāng)?shù)匦薷臄?shù)據(jù)包。ALG可以是單獨的連接于外網(wǎng)和內(nèi)網(wǎng)之間的設(shè)備,也可以是內(nèi)置于防火墻內(nèi)的插件。
當(dāng)FW/NAT發(fā)現(xiàn)外網(wǎng)呼叫信令為SIP時,將其轉(zhuǎn)發(fā)到ALG(應(yīng)用層網(wǎng)關(guān)),通過ALG建立起內(nèi)網(wǎng)偽地址終端與外網(wǎng)終端的通信連接。
使用ALG需要對現(xiàn)有設(shè)備升級改造。例如思科的路由器都支持配置ALG。
2.2 MidCom(IETF MIDCOM(Middlebox Communications)
允許第三方(MIDCOM Agent )成為受FW/NAT信任的實體,然后代表FW/NAT做出決定,強迫其開放端口傳送媒體流或數(shù)據(jù)流。這些受信任的實體通過“MidCom”定義的新協(xié)議與FW/NAT進行通信。
協(xié)議的識別不由Middlebox完成,而是由外部的MIDCOM Agent完成。
使用MidCom需要對現(xiàn)有設(shè)備升級改造。
2.3 STUN(Simple Traversalof UDP Through Network)

IETF RFC 3489定義了如何確定由NAT分配的公網(wǎng)地址和端口,不需要改造現(xiàn)有NAT。
主要特色:
l 能夠讓客戶端發(fā)現(xiàn)NAT的存在以及類型;
l 能夠讓客戶端發(fā)現(xiàn)NAT的綁定生命周期;
l 可以工作在多NAT串聯(lián)環(huán)境下;
l 非常簡單的協(xié)議,易于實現(xiàn),負載低;
l STUN服務(wù)器可以位于公網(wǎng)任何地方。
適用范圍:
l 不適用于Symmetric NAT;
l 對于Non- Symmetric NAT都適用;
l 如果雙方都位于同一個NAT之后,就不適用。
2.4 SBC(Session Border Controller)
l Signaling Solution
Ø SBC可以幫助SIP信令穿越已經(jīng)存在的FW/NAT,而不需要對現(xiàn)有的FW/NAT設(shè)備做任何改變;
Ø 對于SIP終端,SIP終端設(shè)備會周期性發(fā)送注冊消息到SBC。
l Media Traversal Solution
SBC可以把相應(yīng)的媒體流發(fā)送到防火墻上的相關(guān)IP地址和端口,然后正確地使媒體流到達防火墻后的用戶側(cè)。
3 rport機制講解
3.1 方案描述
獲得IP地址是在Via頭中帶上received參數(shù)。為了得到端口信息,也參考了這種方式,即在Via頭中帶上rport屬性來指明端口信息。
當(dāng)在客戶端和服務(wù)器之間是NAT的時候,請求可能會在NAT中創(chuàng)建(或刷新)一個綁定,為了讓客戶端收到響應(yīng)信息,在事務(wù)處理的過程中這個綁定必須保持存在。大多數(shù)的NAT綁定有超過1分鐘的超時時間,這超過了non-INVITE事務(wù)的持續(xù)時間,因而對non-INVITE事務(wù)的請求的響應(yīng)只能在綁定存在的時候存在。INVITE事務(wù)倒是不存在這個問題。
為了保持這個綁定,客戶端應(yīng)該在每隔20s左右重發(fā)INVITE請求,這種重發(fā)機制需要發(fā)生在收到一個臨時的響應(yīng)后。
當(dāng)然剛才所說的大概1分鐘的超時時間也不是確定的,有時候會比這長,此時重發(fā)機制可以發(fā)慢一點,否則,可以發(fā)快一點。這些問題可參考RFC3489。
如果是支持rport機制的服務(wù)器,它需要在接收到的請求中檢查Via頭是否包含一個沒有值的rport參數(shù)。如果有,它需要在回應(yīng)中帶上rport的值,這與received的處理類似。
為了穿越對稱性的對稱性的NAT,響應(yīng)需要發(fā)送到相同的IP地址和端口。當(dāng)服務(wù)器在多端口或接口的請求上監(jiān)聽請求時,它必須記住請求是從何處發(fā)的。對一個穩(wěn)定的Proxy,在一個傳輸?shù)某掷m(xù)時間中,記住這些東西是沒有問題的。但是對于不穩(wěn)定的Proxy,它不存儲請求和響應(yīng)中的狀態(tài)信息,為了達到本規(guī)范的要求,它需要將地址和端口信息加密到Via頭字段中,在響應(yīng)信息到達的時候,它能提取加密的信息并將它放到響應(yīng)中。
rport機制需要終端支持該種機制,因此應(yīng)用情況比較受限。但是在筆者的應(yīng)用場景(呼叫中心)中,主要要解決的問題是坐席能在NAT環(huán)境中穿越,給服務(wù)器發(fā)送信息。因為坐席所使用的SIP軟電話是本公司開發(fā)的,所以可以保證是支持rport和received的。
3.2 實例
下面舉一個發(fā)送REGISTER信息的實例,在請求信息的Via頭中包含了沒有值的rport參數(shù),如下所示:
REGISTER sip:124.40.120.188:5060 SIP/2.0
Via: SIP/2.0/UDP 124.42.4.203:15500;branch=z9hG4bK-d8754z-1049ed261d2e643d-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:19988888888@192.168.2.65:12344;rinstance=7cd1c532e92fdb0e>;expires=0
To: "19988888888"<sip:19988888888@124.40.120.188:5060>
From: "19988888888"<sip:19988888888@124.40.120.188:5060>;tag=203ba359
Call-ID: Yzc4N2IwMzY5OWU4MTdkMzY0NWY4OWU3NjMzNmJiM2U.
CSeq: 1 REGISTER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
User-Agent: eyeBeam release 1105a stamp 56793
Content-Length: 0
發(fā)送到的服務(wù)器支持rport機制,它看到請求中的rport后,將通過分析UDP包信息得到的的NAT的公網(wǎng)地址(124.42.4.203)和端口信息(15500)分別作為received和rport屬性帶給客戶端:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 124.42.4.203:15500;branch=z9hG4bK-d8754z-1049ed261d2e643d-1---d8754z-;rport=15500;received=124.42.4.203
From: "19988888888"<sip:19988888888@124.40.120.188:5060>;tag=203ba359
To: "19988888888"<sip:19988888888@124.40.120.188:5060>;tag=0005-058-7d6dc90516ae2e21
Call-ID: Yzc4N2IwMzY5OWU4MTdkMzY0NWY4OWU3NjMzNmJiM2U.
CSeq: 4 REGISTER
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,UPDATE,PRACK,REFER,SUBSCRIBE,NOTIFY,MESSAGE
Contact: <sip:124.40.120.188:5060>
Content-Length: 0
客戶端在得到響應(yīng)信息后,知道了所使用的公網(wǎng)地址和端口,在而后定期重發(fā)的REGISTER信息中,Contact變換成124.42.4.203: 15500,例如新發(fā)的REGISTER信息變?yōu)椋?/p>
REGISTER sip:124.40.120.188:5060 SIP/2.0
Via: SIP/2.0/UDP 124.42.4.203:15500;branch=z9hG4bK-d8754z-1049ed261d2e643d-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:19988888888@124.42.4.203: 15500;rinstance=7cd1c532e92fdb0e>;expires=0
To: "19988888888"<sip:19988888888@124.40.120.188:5060>
From: "19988888888"<sip:19988888888@124.40.120.188:5060>;tag=203ba359
Call-ID: Yzc4N2IwMzY5OWU4MTdkMzY0NWY4OWU3NjMzNmJiM2U.
CSeq: 2 REGISTER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
User-Agent: eyeBeam release 1105a stamp 56793
Content-Length: 0
4. 參考文檔
神州泰岳應(yīng)用開發(fā)事業(yè)部鄭昀《SIP穿越NAT》
RFC3581:http://www.ietf.org/rfc/rfc3581.txt
posted on 2010-05-28 23:37
阿蜜果 閱讀(7789)
評論(1) 編輯 收藏 所屬分類:
協(xié)議 、
電信知識