SIP/RTP NAT Traversal

NAT 後面的設備只知道自己的內部位址，不曉得在公網的位址。SIP 訊息裡包含了用於 signaling 及 media 的 IP 及通訊埠，除非是經過 ALG 的 NAT，不然這些位址並不會轉換，公網上的設備並不認得這些內部位址。

在 SIP/SDP 訊息中會有內部位址地方包括：

• SIP Message Header 中的「From:」：似乎沒關係。
• SIP Message Header 中的「Contact:」：SIP 話機註冊時，Contact 欄告知目前的位置，讓其他設備可以查到。若 Contact 用內部位址，在公網並不曉得在哪裡，無法 SIP INVITE。
  
  • registrar 只需要改用 SIP 封包 IP 層的實際來源位址，而不用 SIP Contact 欄位的位址。
  • 需要維持這個 NAT 通道。註冊之後，NAT 開了一個外面的通訊埠，對應到內部的 SIP 話機，公網的封包就可以透過這個通訊埠進到 SIP 話機，但此通訊埠在 NAT 對應到期後就會關閉了，需要持續送收封包來避免到期。SIP 話機註冊週期短於 NAT 對應過期時間可維持 NAT 通道，但 SIP REGISTER 的處理較費力，會加重伺服器的負擔，最好 SIP 話機可以送處理較省力的 SIP OPTIONS，或改由伺服器送 stateless OPTIONS 給 SIP 話機。
• SIP Message Header 中的「Via:」：SIP 回應訊息是依據 Via 的路徑反向送回，若 Via 用內部位址，路徑就斷了而無法回送回應訊息。
  
  • 用 SIP 定義的 received 及 RFC 3581 新增 rport：請求時，Via: 加上 ;rport 來告知支援 rport，伺服器端收到後加上「=<通訊埠號碼>」及「;received=<位址>」。回覆時路徑是依據 received 位址及 rport 通訊埠。這個作法比 STUN 好，支援對稱式 NAT。
• SIP 內容放 SDP 時，欄位「c」和「m」分別是欲接收 RTP 封包的 IP 位址與通訊埠。若這些欄位填入的是內部位址，則通話建立後的 RTP 影音封包將無法收到。 有下列可能的解決方式：
  
  • 靜態指定 (Static Mapping) -- 事先設定 NAT 要轉換的 IP 位址並指定要轉換後的通訊埠。
  • STUN -- 取得公網 IP 及 port，不支援對稱式 NAT
  • UPnP -- SIP 話機透過 UPnP 尋找 NAT 並得知其公眾 IP。UA 可以要求 NAT 對閒置的外部通訊埠建立對應關係，用於 SIP 及 SDP 訊息中。
  • Session Border Controller (SBC，或稱為 Session Controller、Back-to-Back User-Agent、B2BUA)：由公網上的 SBC 修正 SIP/SDP 訊息中的 IP 與通訊埠，並在 SIP 請求訊息加入 Record-Route:，讓之後的 SIP 訊息都會經過 SBC 修正。
  • 將雙方的 SDP 中的「c」與「m」欄位分別修改為 RTP Proxy 的 IP 與通訊埠，讓原本點對點傳送的傳送方式，變成雙方皆和 RTP Proxy 建立通話，由 RTP Proxy 負責轉送和控制雙方 RTP 封包的傳輸。

參考文獻

1. Best practices for SIP NAT traversal

延伸閱讀

1. http://www.cs.nccu.edu.tw/~lien/Writing/NGN/firewall.htm
2. STUN
3. TURN
4. ICE