SIP ALG穿透NAT的實現

摘要：為解決SIP應用穿透NAT的問題，剖析了NAT的工作原理，並針對SIP協議信令過程的特點，提出了採用ALG設備解決NAT的穿透問題，具體設計了ALG的結構和相關實現算法，並給出了詳細的實現方案。關鍵詞：會話發起協議(SIP)網絡地址轉換(NAT)會話描述協議(SDP)信令

　　

　　會話發起協議SIP ^[1] (Session Initiation Protocol)是由IETF組織於1999年提出的在Internet網絡環境中實現實時通信應用的一種信令協議。SIP引發了現代通信體系結構的變革，然而它卻在視頻能力、會議控制方面沒有一個完善的標準；同時，由於大量企業和駐地網都採用了私有編址^[2]，並通過網絡地址轉換NAT (Network Address Translation)來控制與公共網絡的通信，而SIP數據包需通過信令消息中的IP地址和端口號來實現目的地尋址，且它的媒體流端口是動態分配的，這就為在NAT上配置固定的包過濾策略帶來了困難。因此，SIP穿透NAT是絕大多數VoIP運營商亟待解決的問題。
　　當前，幾種主要的NAT穿透技術有SIP ALG、Full Proxy、MidCom、VPN、隧道穿透、STUN等。其中，SIP ALG方式是在傳統的NAT上進行擴展，使之具備感知SIP呼叫控制協議的能力，從而對基於SIP呼叫的地址實現穿透。它是一種比較簡單的方案，最突出的特點是ALG和具體的SIP系統無關，對於一個SIP系統不需要做任何修改，只要在響應的NAT上加載SIP ALG，就能完成私網到公網甚至私網中的兩個用戶之間的SIP連接。1 SIP應用穿透NAT面臨的問題1.1 NAT的工作原理　　NAT ^[3]被置於兩網間的邊界。NAT技術使得一個私有網絡可以通過Internet註冊IP連接到外部世界。位於內網和外網中的NAT路由器在發送數據包之前，負責把內部IP翻譯成外部合法地址。當從外網來的含公網地址信息的數據包到達NAT時，NAT使用預設好的規則(其組元包含源地址、源端口、目的地址、目的端口、協議)來修改數據包，然後再轉發給內網接收點。NAT的基本工作原理如圖1所示，NAT設備實際上是在維護一個狀態表，該表用於把非法的IP地址映射到合法的IP地址上。

1.2技術難點　　與傳統NAT支持HTTP等數據的穿透不同，SIP應用中的語音和視頻數據需通過信令消息中的IP地址和端口號來實現目的地尋址，因此信令消息在地址穿透中不僅需要對TCP/UCP層的端口信息以及IP層的源地址和目的地址進行變換，還需對IP包載荷中的相關地址信息進行變換。同時，對於SIP應用來說，是在控制信息中動態地協商媒體流端口，信令協議中的IP地址也是私有的，因此要準確把握相關的地址和端口信息，並進行正確的轉換。這是本文需要解決的首要技術難點。
　　其次，SIP ALG實現對NAT的穿透會因呼叫方處在內網和外網而不同，因此對進出NAT的SIP消息在解析時要判斷是內網之間的呼叫請求(內部消息)、外網呼叫請求內網(對內消息)，還是內網呼叫請求外網(對外消息)，以便對該消息進行正確處理。這也是本文需要解決的技術難點。2 SIP ALG的設計思想　　由於媒體流端口是在呼叫雙方SIP信令建立連接後動態協商的，因此對SIP消息穿透NAT設備要綜合考慮這兩個方面因素。2.1 SIP信令的穿透原理　　SIP信令穿透NAT與HTTP穿透類似，NAT設備只要打開固定的端口，就能保證SIP信令穿透NAT並與外界建立連接。　　本文基於SIP終端設備的特殊性來考慮信令穿透NAT。SIP終端設備會周期性地發送Register消息^[1]到註冊服務器上，由於不斷有信令消息經過NAT設備，致使NAT設備對通過的消息流始終 ​​保持一個確定的端口；同時，當Register消息經過ALG ，ALG就會記錄信令穿透NAT時經NAT轉換後的IP地址和端口等信息，並將此信息與NAT後面的終端用戶ID(如890010098)等信息進行綁定。這樣，當一個信令到來，ALG將通過NAT上正確的地址和端口發送給被叫方。2.2媒體流的穿透原理　　當信令穿透NAT後，NAT後面的SIP終端就可以收到來自外網的呼叫請求。這時呼叫方的Invite消息和響應方的200(OK)消息中都攜帶了用於描述與會話相關的信息及與流媒體相關參數的SDP(Session Description Protocol)消息體^[4]。當該消息通過ALG時，ALG將通過與該媒體流相關的呼叫——會話層消息中的用戶ID(如890010098)識別出NAT上的IP地址和端口並進行相應的轉換，這樣當呼叫方收到200(OK)消息時就能從SDP消息體中獲取該IP地址和端口等信息並發送ACK確認消息，從而完成一個會話的建立。3 SIP ALG的實現　　利用SIP ALG實現對NAT的穿透，主要是對流經ALG的SIP消息進行處理和維護。按照各部分功能的差異，可以將SIP ALG劃分為消息解析模塊、消息修改模塊和消息轉發模塊，SIP ALG的整體結構如圖2所示，該圖體現了各功能模塊間的相互關係。

下面以一個典型的兩個不同NAT內的用戶(Joe：890010098@192.168.1.4和Bob：810000004@10.10.15.44)通過註冊服務器(SER服務器)完成連接的過程為例，來說明SIP ALG的具體實現。SIP ALG解決NAT穿透的示意圖如圖3所示。

3.1前提條件　　SIP ALG的實現主要是對Request、Response消息進行解析、修改與轉發。因此在實現ALG前首先要了解SIP請求(Request)的方法(Register、Invite、ACK、Options、Cancel、Bye) ^[1]，SIP回答(Response，包括Trying、Ringing、OK和ACK) ^[1]以及SIP消息中的相關頭域(Request-URI、Via、From、To、Call-ID、Cseq、Contact等)^[1]。3.2消息解析模塊的實現　　消息解析模塊主要對流經ALG的SIP消息進行解析，並判斷該消息是內部消息、對外消息還是對內消息，以便消息修改模塊能對這些消息進行正確的處理。消息解析模塊的工作流程如圖4所示。它主要判斷數據包From、To、Via等頭域中的IP地址信息，以準確解析消息類型。

3.3消息修改模塊的實現　　由於同一NAT內部的用戶間可以直接通信，因此“內部消息處理”模塊不需要對消息體進行修改。這樣就把消息修改模塊分為對內消息修改與對外消息修改。這兩個過程實際上是可逆的。對內消息修改主要根據地址映射表把外網IP和端口號轉換成內部IP和端口號，以便外部請求能準確到達NAT內側的用戶端；對外消息修改則根據地址映射表把內部IP和端口號轉化成外網可用的IP和端口號，這樣，來自外網的請求就能準確定位到該地址。但無論哪個模塊，最終結果都是對相應的Request和Response消息中與NAT有關的IP地址和端口號進行修改。消息修改模塊的處理流程如圖5所示。

對信令消息的修改需要對Invite、ACK、BYE和Register等Request消息和100(Tring)、180(Ringing)以及200(OK)等Response消息中的Via、From、To、Call-ID、Contact等頭域中包含的私有IP地址和端口信息進行修改。而對SDP消息體的處理是SIP ALG實現其功能的關鍵所在，因為SDP消息體的交換是實 ​​現呼叫雙方媒體流通信的前提和關鍵。對SIP控制的向內的媒體流轉發，ALG分析向外的Invite和200(OK)消息中的SDP消息體中“Media Description”和“Connection Information”行，根據這兩行中的描述地址在NAT上啟用未用端口，完成向內接收媒體流的目的地址翻譯，從而實現媒體流通信的建立。需要注意的是，在對Response消息進行修改時，還需通過Call-ID匹配呼叫的上下文環境，也要加入Record-Route頭域以告知內網上的SIP終端，本次呼叫中以後所有的SIP消息都要流經該SIP ALG，這樣才能保證ALG的正確轉發。最後，對消息修改完畢後，需要重新計算消息的長度，並保存在Content-Length中。3.4消息轉發模塊的實現　　消息轉發模塊主要是通過控制NAT，對修改後的SIP消息進行轉發，以完成一個會話的建立。消息轉發模塊在ALG中保留並維護當前呼叫的上下文環境，也就是一個地址映射信息表，如表1所示。以記錄相關的地址映射信息。

　表1中的數據表示所有目的地址為202.205.11.230、60012的SIP包都會被NAT網關轉發到主機10.10.15.44：5060上處理。消息修改模塊在做修改前，要首先查詢ALG內記錄的地址映射信息表，如果表內已建立了該用戶的信息，則按此信息對向NAT處的SIP消息做相應修改，否則丟棄該消息。
　　為生成相關地址映射信息表，ALG首先需要分析向外的Register消息。ALG記錄Register中的To和Contact頭域，按它們的值在NAT設備上啟用一個未用的端口，然後ALG記錄生成的映射信息並填入地址映射信息表。生成地址映射信息表後，消息修改模塊再按映射信息修改向外的Invite和Register等報文，然後再通過消息轉發模塊實現對NAT的穿透。
　　本文通過分析NAT的工作原理以及SIP信令與媒體流的特點，詳細講述了SIP ALG的具體實現方法。實驗證明，本文設計的SIP ALG能很好地解決NAT穿透問題，且運行穩定，互通性好。

Wi-Fi Multimedia (WMM)

Wi-Fi Multimedia (WMM)是第一個以802.11標準為基礎和通過Wi-Fi聯盟認證的QoS協定，Wi-Fi聯盟已採用這種優先權式的QoS方法做為QoS功能基準，這功能基準是802.11e所定義最新QoS功能的子集。WMM透過增強型分散式協議功能(EDCF: Enhanced Distributed Channel Access)、許可控制、爆發模式傳輸確認以及執行4個優先權式 QoS佇列的能力來提供QoS服務WMM基準功能很適合負載較小的環境；EDCF是以機率為基礎，在統計上來說，對於高優先權流量較為有利。雖然 EDCF無法完全保証QoS(尤其在高負載環境下)，但這些功能對於無線網路語音應用在低負載卻有用處EDCF是以增強型協調通道存取(EDCA)做為通道存取機制。

IEEE 802.11e共指定了EDCA和混合協調通道存取(HCCA)兩種通道存取機制。Wi-Fi多媒體方案存取(WMM-SA)規格除了EDCA外，還支援以HCCA為基礎的集中式排程機制。HCCA包含更多QoS功能，能提供參數化QoS以及更精確的QoS參數控制，像是延遲時間、排程和頻寬保證。EDCA主要是在傳輸媒體使用權的競爭階段工作，但是QoS接取點(QAP)有權在競爭階段控制傳輸媒體，然後以輪詢方式決定使用權。

參數化QoS會用到流量規範(TSPEC)，QoS Station (QSTA)用TSPEC對QAP發出QoS要求。QAP接取點可以接受或拒絕TSPEC要求。HCCA還增加了一項功能，就是無需確認的傳輸方式，這對於語音和串流媒體等即時應用極有幫助，因為即時應用對於延遲時間和延遲時間變動(jitter)的要求極為嚴苛，所以無法容忍重傳封包所造成的時間延誤，因為重新傳送的封包也會因為太晚抵達而變得毫無用處。

未提供Wi-Fi QoS功能的典型802.11b網路約能同時支援5通VoIP電話，採用WMM-SA HCCA的802.11a/g則能支援20通以上電話，這是因為802.11a/g頻寬的提升，及HCCA會利用TDMA集中式輪詢機制減少VoIP裝置爭奪控制權的情形。

在OSI第二層加入QoS功能的最終目的是支援802.11e標準，這套標準包含WMM以及WMM-SA兩種方法其中還有許多其它功能對於串流應用也很有幫助，像是直接鏈路設定(DLS)、區塊確認和省電功能DLS可將覆蓋率提高一倍以上，因此對於視訊應用極為重要，尤其是經常利用同一個無線網路傳送視訊和聲音的家庭環境。

乙太網路流量在OSI第二層的資料鏈結子層中有802.1D和802.1P所提供的QoS功能支援。乙太網路QoS採用優先權機制，它不是一種保證式QoS，不會為語音或串流媒體提供延遲時間或頻寬保證。優先權式QoS在低負載量的表現相當良好。


引用自：http://163.23.24.147/ya/rewrite.php/read-5.html

功率單位mW和dBm換算

無線基地台輸出的射頻信號，通過電纜傳送到天線，由天線以無線波形式射頻出去。無線波形到達接收地點後，由天線接收下來（僅僅接收很小很小一部分功率），並通過電纜送到無線基地台接收。因此在無線網路架設規劃中，如何知道無線基地台的發射功率與天線的無線波型射頻能力是非常重要的。 Tx是發射（ Transmits ）的簡稱。無線基地台的發射功率是指在使用頻段範圍內的能量，通常有兩種測量標準： 1、功率（ W ）: 相對 1 瓦（ Watts ）的線性水平。例如，WiFi 無線網卡的發射功率通常為 0.063W ，或者說63mW 。 2、增益（ dBm ）:相對 1 毫瓦（ milliwatt ）的比例水準。例如是市售 WiFi 無線網卡的發射 增益 為 15.56dBm~18dBm 。 兩種表達方式可以互相轉換： 1、dBm = 10 x log[ 功率 mW]2、mW = 10[ 增益 dBm / 10 dBm]在無線網路系統中，天線被用來把電流波轉換成電頻波，在轉換過程中還可以對發射和接收的信號進行"放大"，這種能量放大的度量成為 "增益（Gain）"。 天線增益的度量單位為" dBi "。由於無線系統中的電頻波能量是由發射設備的發射能量和天線的放大總和產生，因此計算發射能量最好同一單位－增益（ dB ），例如，發射設備的功率為 100mW ，或20dBm；天線的增益為 10dBi ，則:發射總能量＝發射功率（ dBm ）＋天線增益（ dBi ） ＝ 20dBm ＋ 10dBi ＝ 30dBm或者: ＝ 1000mW ＝ 1W在"無線產品功率"中（例如無線區域網路設備）每個 dB 都非常重要，特別要記住" 3 dB 法則"。每增加或降低 3 dB ，意味著增加一倍或降低一半的功率： -3 dB = 1/2 功率 -6 dB = 1/4 功率 +3 dB = 2x 功率 +6 dB = 4x 功率 例如， 100mW 的無線發射功率為 20dBm ，而 50mW 的無線發射功率為 17dBm ，而200mW 的發射功率為 23dBm 。 （dBm）：放大器的輸出能力，一般單位為W、mW、dBm。dBm是取1mW作基準值，以分貝表示的絕對功率。

換算公式：Power值（dBm）=10lgW5W → 10lg5000 = 37dBm10W → 10lg10000 = 40dBm20W → 10lg20000 = 43dBm

所以功率每增加一倍，Power值增加3dBm

Regex Cheat Sheet

http://regexlib.com/CheatSheet.aspx

Linux C function() 參考手册

Ref:http://net.pku.edu.cn/~yhf/linux_c/

ACCEL-PPP

Overview
--------
The ACCEL-PPP v1.0 is completly new implementation of PPTP/PPPoE/L2TP which was written from scratch.
Userspace daemon has its own PPP implementation, so it does not uses pppd and one process (multi-threaded) manages all connections.
ACCEL-PPP uses only kernel-mode implementations of pptp/l2tp/pppoe.


Features
--------
1.  Modular architecture
2.  High-performance multi-threaded I/O core
3.  Supported PPTP
4.  Supported PPPoE (including TR-101 extension)
5.  Supported L2TPv2 (without IPsec)
5.  Radius authentication/accounting
6.  Radius DM/CoA extention
7.  Supported authentication types: PAP, CHAP (md5), Microsoft CHAP Extentions (including version 2), not supported - EAP
8.  Supported MPPE
9.  Compression is not supported
10. Extensible logging engine with per session logging support, implemented log to file, log to remote host and log to PostgreSQL targets
11. Extensible user/password database, implemented Radius, pppd compatible chap-secrets sources
12. Extensible IP pool, implemented Radius, chap-secrets and static pools
13. Supported pppd compatible ip-up/ip-down scripts
14. Builtin tbf/htb shaper manager
15. Command line interface via telnet
16. SNMP support (master or subagent via AgentX)


Requirment
----------
1. modern linux distribution
2. kernel-2.6.25 or later
4. cmake-2.6 or later
5. libnl-2.0 or probably later (required for builtin shaper)
6. libcrypto-0.9.8 or probably later (openssl-0.9.8)
7. libpcre
8. net-snmp-5.x 


Compilation and instalation
-----------
Make sure you have configured kernel headers in /usr/src/linux,
or specify other location via KDIR.
1. cd /path/to/accel-ppp-1.3.5
2. mkdir build
3. cd build
4. cmake [-DBUILD_DRIVER=FALSE] [-DKDIR=/usr/src/linux] [-DCMAKE_INSTALL_PREFIX=/usr/local] [-DCMAKE_BUILD_TYPE=Release] [-DLOG_PGSQL=FALSE] [-DSHAPER=FALSE] [-DRADIUS=TRUE] [-DNETSNMP=FALSE] ..
   Please note that the double dot record in the end of the command is essential. You'll probably get error or misconfigured sources if you miss it.
   BUILD_DRIVER, KDIR, CMAKE_INSTALL_PREFIX, CMAKE_BUILD_TYPE, LOG_PGSQL, SHAPER, RADIUS  are optional,
   But while pptp is not present in mainline kernel you probably need BUILD_DRIVER.
   For example:
   cmake -DBUILD_DRIVER=TRUE ..
   will configure sources to build pptp driver, search kernel headers at /usr/src/linux, install to /usr/local,
   build with no debug, pgsql and shaper support, build with radius support.
5. If you want to use chap-secrets for authentication purpose then you need to disable radius support, configure as following:
   cmake -DBUILD_DRIVER=TRUE -DRADIUS=FALSE ..
   of course you can include additional options if needed.
6. make
7. make install


Configuration
-------------
read man accel-ppp.conf


Built-in shaper
--------------
accel-ppp supports tbf and htb based shaper manager.
To enable it uncomment shaper in [modules] section.
It accepts radius attributes in various formats: rate, down-rate/up-rate and cisco-like. Values have to be in kilobits except cisco-like.
For example:
Filter-Id=1000 (means 1000Kbit both up-stream and down-stream rate)
Filter-Id=2000/3000 (means 2000Kbit down-stream rate and 3000Kbit up-stream rate)
To change radius attribute which containes rate information use 'attr' option, for example:
[shaper]
attr=My-Custom-Rate-Attribute
of course this attribute have to be in radius dictionary.
To specify different attributes for down-stream and up-stream rates use 'attr-down' and 'attr-up' options, for example:
[shaper]
attr-down=PPPD-Downstream-Speed
attr-up=PPPD-Upstream-Speed

If you want to use cisco-like format configure accel-ppp as following:
[shaper]
vendor=Cisco
attr=Cisco-AVPair
and send two attributes:
Cisco-AVPair=lcp:interface-config#1=rate-limit input 2000000 8000 8000 conform-action transmit exceed-action drop (which means 2000Kbit up-stream rate and 8Kb burst)
Cisco-AVPair=lcp:interface-config#1=rate-limit output 2000000 8000 8000 conform-action transmit exceed-action drop (which means 2000Kbit down-stream rate and 8Kb burst)


Advanced shaper using
---------------------
1. Burst configuration.
If you not using cisco-like format then burst calculates from rate and specified burst factors.
To specify burst factors use 'down-burst-factor' and 'up-burst-factor' options, for example:
[shaper]
down-burst-factor=1.0
up-burst-factor=10.0
which means that burst for tbf/htb qdisc will be calculated as down-stream rate multiply to 1.0 and burst for policer/htb will be calculated as up-stream rate multiply to 10.0.

2. Time ranges.
You can specify time ranges to authomatic rate reconfiguration.
To specify time ranges use following sample configuration:
[shaper]
time-range=1,1:00-3:00
time-range=2,3:00-5:00
time-range=3,5:00-7:00
first number is time range identifier.
To specify time range specific rates use following format of radius attributes: range-id,rate, range-id,down-rate/up-rate or cisco-like, for example:
Filter-Id=1000
Filter-Id=1,2000
Filter-Id=2,3000
Filter-Id=3,4000
which means: set 1000Kbit by default, set 2000Kbit in time range 1, set 3000Kbit in time range 2, set 4000Kbit in time range 3.
You have to pass multiple Filter-Id attributes to utilize this functionality.
Or cisco-like:
Cisco-AVPair=lcp:interface-config#1=rate-limit output access-group 1 1000000 8000 8000 conform-action transmit exceed-action drop
Cisco-AVPair=lcp:interface-config#1=rate-limit input access-group 1 1000000 8000 8000 conform-action transmit exceed-action drop
and so on...

3. chap-secrets.
If you use chap-secrets instead of radius then there is way to utilize built-in shaper too.
The optional fifth column in chap-secrets file is used to pass rate information to shaper.
Its format is same as for radius attributes, except you cann't utilize time ranges functionality.


SNMP
----
SNMP is implemented using net-snmp libraries. By default accel-ppp starts in subagent mode,
so make sure that net-snmp configured with subagent control turned on (read net-snmp's README.agentx for more details).
Also you can start accel-ppp as master agent using following configuration:
[snmp]
master=1

Usage:
Place accel-pppd/extra/net-snmp/ACCEL-PPP-MIB.txt to your mibs directory.
Also you can find used numerical oids in this file.
1. Requesting statistics:
snmpwalk -m +ACCEL-PPP-MIB -v 2c -c local 127.0.0.1 ACCEL-PPP-MIB::accelPPPStat
2. Requesting sessions:
snmptable -m +ACCEL-PPP-MIB -v 2c -c local 127.0.0.1 ACCEL-PPP-MIB::sessionsTable
3. Terminate session by session identifier (Acct-Session-ID):
snmpset -m +ACCEL-PPP-MIB -v 2c -c local 127.0.0.1 ACCEL-PPP-MIB::termBySID.0 = 0000000000000001
4. Terminate session by interface name:
snmpset -m +ACCEL-PPP-MIB -v 2c -c local 127.0.0.1 ACCEL-PPP-MIB::termByIfName.0 = ppp2
5. Terminaten session by IP address (Framed-IP-Address):
snmpset -m +ACCEL-PPP-MIB -v 2c -c local 127.0.0.1 ACCEL-PPP-MIB::termByIP.0 = 192.168.10.10
6. Terminate session by username:
snmpset -m +ACCEL-PPP-MIB -v 2c -c local 127.0.0.1 ACCEL-PPP-MIB::termByUsername.0 = user1
7. Execute cli command:
snmpset -m +ACCEL-PPP-MIB -v 2c -c local 127.0.0.1 ACCEL-PPP-MIB::cli.0 = "shaper change all 1024 temp"



Warning !!!
-----------
1. The pptp driver conflicts with ip_gre driver (in kernel), so make sure that ip_gre is not built-in or loaded at run time
   (don't matter if you have 2.6.37 or later kernel).
2. Don't mix connections of accel-ppp and poptop's pptpd, before starting accel-ppp make sure that no connections
   of pptpd exists.


Contacts
--------
http://accel-ppp.sourceforge.net/
mail: xeb@mail.ru
ICQ: 337258064
Jabber: xeb@xeb.homelinux.net

Using pppoe kernel-mode, HOW-TO

Ref:http://norean.freecontrib.org/nakooki/SVN/snapshot/nakooki/0.3/docs/pppoe-HOW-TO.html