posts - 297,  comments - 1618,  trackbacks - 0
           

          RFC3581——SIP中的rport機制

          記錄人:阿蜜果

          日期:2010-5-28

          1.    介紹

          RFC3581的下載地址:http://www.ietf.org/rfc/rfc3581.txt

          該協議比較簡短,主要用于描述rportresponse-port)機制。

          1.1 NAT分類

          NAT:網絡地址轉換(NAT,Network Address Translation)屬接入廣域網(WAN)技術,是一種將私有(保留)地址轉化為合法IP地址的轉換技術,它被廣泛應用于各種類型Internet接入方式和各種類型的網絡中。原因很簡單,NAT不僅完美地解決了lP地址不足的問題,而且還能夠有效地避免來自網絡外部的攻擊,隱藏并保護網絡內部的計算機。

          NAT常用的分類如下:

          Full Cone NAT(完全圓錐型)

          Address Restricted Cone NAT(地址限制圓錐型 )

          Port Restricted Cone NAT(端口限制圓錐型)

          Symmetric NAT(對稱型)

          1.1.1 完全圓錐型NAT

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

          1.1.2 地址限制圓錐型NAT

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

          1.1.3 端口限制圓錐型NAT

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

          1.1.4 對稱型NAT

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

          1.2問題描述

          1.2.1 SIP Proxy無法穿過NAT回送SIP信令

          因為SIP信令中的FromContact頭域記錄的是私網地址和端口,NAT無法識別和轉換。如圖所示:
            

          1.2.2 使用UDP Hole Punching的問題

                 

          這個內網的NAT上打了一個方向為211.136.91.58,(這就是稱為UDP Hole Punching的技術)以后211.136.91.58就可以通過這個洞與內網的192.168.1.223聯系了,但是其他的IP不能利用這個洞。

          在沒有活動的時候,這個Hole會過期:

          NAT對于地址轉換關系是有一定生命期的,某個地址轉換后在一段時間內沒有被使用將會被清除,當這個業務流再次出現時,將會建立一個新的地址轉換關系。

          SIP代理無法穿越

          SIPUDPTCP上操作。當在UDP中使用的時候,對請求的響應被發送給請求所來自的地址,端口字段帶在請求的Via頭字段中。一半以上的信息(例如:IP地址)帶在 IP包頭中,還有一半的信息(例如:端口信息)帶在SIP消息頭中。SIP這樣做的原因是為了監聽所有的信息,包括請求消息和響應消息。

          但是這種方式在客戶端在 NAT中的情況不適用,在NAT的環境中,回應可能發送不過去,因為與在請求中找到的地址不一樣,而且此前也沒有方法讓客戶端來得到源端口信息。

          2.    NAT的常用解決方案

          解決NAT穿越有很多中解決方案,常用的有:

          2.1 ALGApplication Level Gateway

          可以識別SIP信令,能夠適當地修改數據包。ALG可以是單獨的連接于外網和內網之間的設備,也可以是內置于防火墻內的插件。

          FW/NAT發現外網呼叫信令為SIP時,將其轉發到ALG(應用層網關),通過ALG建立起內網偽地址終端與外網終端的通信連接。

          使用ALG需要對現有設備升級改造。例如思科的路由器都支持配置ALG

          2.2 MidComIETF MIDCOM(Middlebox Communications

          允許第三方(MIDCOM Agent )成為受FW/NAT信任的實體,然后代表FW/NAT做出決定,強迫其開放端口傳送媒體流或數據流。這些受信任的實體通過“MidCom”定義的新協議與FW/NAT進行通信。

          協議的識別不由Middlebox完成,而是由外部的MIDCOM Agent完成。

          使用MidCom需要對現有設備升級改造。

          2.3 STUN(Simple Traversalof UDP Through Network)

           
                IETF RFC 3489
          定義了如何確定由NAT分配的公網地址和端口,不需要改造現有NAT。

          主要特色

          能夠讓客戶端發現NAT的存在以及類型;

          能夠讓客戶端發現NAT的綁定生命周期;

          可以工作在多NAT串聯環境下;

          非常簡單的協議,易于實現,負載低;

          STUN服務器可以位于公網任何地方。

          適用范圍

          不適用于Symmetric NAT;

          對于Non- Symmetric NAT都適用;

          如果雙方都位于同一個NAT之后,就不適用。

          2.4 SBC(Session Border Controller)

                       
             
          Signaling Solution

          Ø SBC可以幫助SIP信令穿越已經存在的FW/NAT,而不需要對現有的FW/NAT設備做任何改變;

          Ø 對于SIP終端,SIP終端設備會周期性發送注冊消息到SBC。

          Media Traversal Solution

          SBC可以把相應的媒體流發送到防火墻上的相關IP地址和端口,然后正確地使媒體流到達防火墻后的用戶側。

          3     rport機制講解

          3.1 方案描述

          獲得IP地址是在Via頭中帶上received參數。為了得到端口信息,也參考了這種方式,即在Via頭中帶上rport屬性來指明端口信息。

          當在客戶端和服務器之間是NAT的時候,請求可能會在NAT中創建(或刷新)一個綁定,為了讓客戶端收到響應信息,在事務處理的過程中這個綁定必須保持存在。大多數的NAT綁定有超過1分鐘的超時時間,這超過了non-INVITE事務的持續時間,因而對non-INVITE事務的請求的響應只能在綁定存在的時候存在。INVITE事務倒是不存在這個問題。

          為了保持這個綁定,客戶端應該在每隔20s左右重發INVITE請求,這種重發機制需要發生在收到一個臨時的響應后。

          當然剛才所說的大概1分鐘的超時時間也不是確定的,有時候會比這長,此時重發機制可以發慢一點,否則,可以發快一點。這些問題可參考RFC3489。

          如果是支持rport機制的服務器,它需要在接收到的請求中檢查Via頭是否包含一個沒有值的rport參數。如果有,它需要在回應中帶上rport的值,這與received的處理類似。

          為了穿越對稱性的對稱性的NAT,響應需要發送到相同的IP地址和端口。當服務器在多端口或接口的請求上監聽請求時,它必須記住請求是從何處發的。對一個穩定的Proxy,在一個傳輸的持續時間中,記住這些東西是沒有問題的。但是對于不穩定的Proxy,它不存儲請求和響應中的狀態信息,為了達到本規范的要求,它需要將地址和端口信息加密到Via頭字段中,在響應信息到達的時候,它能提取加密的信息并將它放到響應中。

          rport機制需要終端支持該種機制,因此應用情況比較受限。但是在筆者的應用場景(呼叫中心)中,主要要解決的問題是坐席能在NAT環境中穿越,給服務器發送信息。因為坐席所使用的SIP軟電話是本公司開發的,所以可以保證是支持rportreceived的。

          3.2 實例

          下面舉一個發送REGISTER信息的實例,在請求信息的Via頭中包含了沒有值的rport參數,如下所示:

          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

              發送到的服務器支持rport機制,它看到請求中的rport后,將通過分析UDP包信息得到的的NAT的公網地址(124.42.4.203)和端口信息(15500)分別作為receivedrport屬性帶給客戶端:

          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

             客戶端在得到響應信息后,知道了所使用的公網地址和端口,在而后定期重發的REGISTER信息中,Contact變換成124.42.4.203: 15500,例如新發的REGISTER信息變為:

          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.20315500;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.    參考文檔

          神州泰岳應用開發事業部鄭昀《SIP穿越NAT
             
          RFC3581http://www.ietf.org/rfc/rfc3581.txt

          posted on 2010-05-28 23:37 阿蜜果 閱讀(7797) 評論(1)  編輯  收藏 所屬分類: 協議 、電信知識


          FeedBack:
          # re: 【電信知識】RFC3581——SIP中的rport機制
          2011-12-18 18:20 | Yaping Cao
          每次用到什么知識或者理論在網上一搜就搜到你的博客啦,哈哈,受教了,也多謝博主,哈哈,天天開心~  回復  更多評論
            
          <2010年5月>
          2526272829301
          2345678
          9101112131415
          16171819202122
          23242526272829
          303112345

                生活將我們磨圓,是為了讓我們滾得更遠——“圓”來如此。
                我的作品:
                玩轉Axure RP  (2015年12月出版)
                

                Power Designer系統分析與建模實戰  (2015年7月出版)
                
               Struts2+Hibernate3+Spring2   (2010年5月出版)
               

          留言簿(263)

          隨筆分類

          隨筆檔案

          文章分類

          相冊

          關注blog

          積分與排名

          • 積分 - 2296380
          • 排名 - 3

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 广德县| 汤原县| 金门县| 磐石市| 濉溪县| 神池县| 团风县| 保定市| 四平市| 崇阳县| 石景山区| 赞皇县| 桦南县| 夏邑县| 苏州市| 吴旗县| 北川| 大邑县| 舞阳县| 古蔺县| 三台县| 都江堰市| 从化市| 外汇| 望都县| 会昌县| 奇台县| 油尖旺区| 五华县| 南木林县| 两当县| 寿光市| 云霄县| 尼木县| 施秉县| 阳泉市| 樟树市| 灵璧县| 高阳县| 郯城县| 康乐县|