本文原創自 http://blog.csdn.net/voipmaker 轉載註明出處。
本文是VOIP通信NAT系列專題的第三篇，
本文論述NAT對SIP協議穿越的影響，SIP協議是基於文本的，而他的一些地址是保存在消息頭傳輸，NAT設備在沒開啓ALG情況下不會修改消息頭地址，
多數客戶端填寫的地址都是內網地址，這就導致消息路由問題，SIP 信令穿越涉及兩部分，一個是註冊，另一個是INVITE(呼叫)，涉及的消息頭爲contact頭和via頭，
contact頭是告知對方自己直接可達的地址，via頭告知對方，此消息是從哪個地址，哪個端口送過來，接收端響應時根據via地址做響應，先說register, 客戶端註冊時
會把自己的地址端口填寫到contact頭，但這個地址在nat環境下並不管用，註冊的作用是告知服務器自己的可達地址，後面有呼叫送給他時服務器直接送到這個地址即可，
而客戶端填寫的私有地址在nat環境下並不可達，服務器後續呼叫直接送這個地址是失敗的，解決這個問題需要客戶端支持 sip outbound, 其原理是服務器發現如果客戶端是在nat環境下，則記錄接收到register請求的地址和端口，而不是contact地址和端口。 這個地址和端口通常是NAT設備給客戶端映射的外部端口，而NAT設備維護這個映射是 有時間限制的，爲確保這個映射一直開啓就需要客戶端週期性發keep-alive包，包的類型有多種，有的直接週期發register，有的發options, rfc5626規範要求TCP用回車換行發送，UDP則用stun 的bind request 保持NAT 映射處於活躍狀態。 這就解決了呼叫客戶端問題， SIP穿越的另一個問題是響應發送給誰，前面提到，響應者會根據via頭做 response,但via頭通常是內網地址，NAT環境下是不可達的，RFC 3581解決了這個問題，通過在via頭中增加 rport和received字段支持此擴展，rport在發起請求者的包中是空的，接收到收到後發現有這兩個頭，接收端會檢測實際收到的包的地址和端口，把這兩個值填寫到recived和rport中，告知請求發起者，同時在響應請求時把響應向這個地址和端口發送，通常這個地址和端口是NAT設備映射的地址和端口。
至此SIP信令穿越問題完美解決。
下一篇文章講述VOIP NAT穿越 之媒體穿越。