關(guān)于rfc3581/rport參數(shù)的闡述

一：簡(jiǎn)述

一般情況下，服務(wù)器在接收到request后，應(yīng)答發(fā)向哪里呢？服務(wù)器在計(jì)算回應(yīng)應(yīng)答的算法是一種混合模式，具體說(shuō)來(lái)是這樣的：

1，IP：從哪里接收到的就會(huì)給哪里，即ip包上記錄的源地址

2，port：根據(jù)sip報(bào)文的頭解析出來(lái)，

對(duì)于處理被NAT包裹的環(huán)境中的客戶端，請(qǐng)求是可以發(fā)出去的，但是應(yīng)答卻無(wú)法穿透NAT，就要借助rport這個(gè)位于via 類型header的param來(lái)處理了

? 附：目前還借助了“received”這個(gè)param in topmost via header，原理是這樣的

?

? ? ? ? ?服務(wù)器會(huì)將自己實(shí)際從哪個(gè)ip上接收到的請(qǐng)求記錄在“received”，通過(guò)他可以有助于讓應(yīng)答穿越NAT。但是沒(méi)有指定port，那怎么半呢？

?

二，客戶端

可以在其聲稱的請(qǐng)求中，包含"rport" 這個(gè)參數(shù)in the top? via header，但是不能有值，這個(gè)只是表示我支持該擴(kuò)展屬性。

當(dāng)客戶端使用udp將請(qǐng)求發(fā)送出去后，他必須在其發(fā)送請(qǐng)求的那個(gè)ip：port上準(zhǔn)備好接收回來(lái)的應(yīng)答，

同時(shí)，他還需要在“sent-by”中指定的端口上準(zhǔn)備接收。

?

一旦在客戶端和服務(wù)器之間有一個(gè)NAT存在，那么當(dāng)請(qǐng)求經(jīng)過(guò)NAT的時(shí)候會(huì)在nat上創(chuàng)建一條綁定，這個(gè)綁定記錄還要保有一個(gè)超時(shí)時(shí)間，保證在這個(gè)時(shí)間內(nèi)能夠接收到服務(wù)器端的應(yīng)答。

大部分的udp NAT,這個(gè)超時(shí)時(shí)間設(shè)置的是1min，這個(gè)遠(yuǎn)遠(yuǎn)超過(guò)了non-invite傳輸?shù)臅r(shí)間。所以，對(duì)于non-invite請(qǐng)求，接收到應(yīng)答是沒(méi)問(wèn)題的。

而，INVITE傳輸則可以是任意的超時(shí)時(shí)長(zhǎng)，所以為了不讓nat把我關(guān)掉，客戶端應(yīng)該每20s就傳一次，這種重傳必須一直延續(xù)著，盡管接收到臨時(shí)應(yīng)答了

?

三，服務(wù)端

服務(wù)器(這里的服務(wù)器包括proxy 或者 UAS)在接收到請(qǐng)求之后，會(huì)檢查topmost via的頭域，如果頭域中包含“rport”參數(shù) with no value，則把該值設(shè)置成接收到請(qǐng)求的源端口號(hào)

這個(gè)原理等同于服務(wù)端在向topmost via中insert “reseived”一樣。實(shí)際上，服務(wù)端必須要insert一個(gè)包含接收請(qǐng)求的源地值的?“reseived”到via中，即使這個(gè)源地值域sent-by是一樣的。

注：以上處理域傳輸層協(xié)議無(wú)關(guān)

當(dāng)一個(gè)服務(wù)器想要發(fā)送應(yīng)答的時(shí)候，他會(huì)檢查應(yīng)答中的topmost via ，如果“sent-protocol”組件指示要使用不可靠傳輸協(xié)議比如udp，那么時(shí)不可以有“maddr”這個(gè)參數(shù)的，但是有?“reseived”和“rport”參數(shù)，

這個(gè)應(yīng)答必須發(fā)送給“reseived”中列出的所有ip，對(duì)應(yīng)的端口為“rport”中指定的，而這個(gè)應(yīng)答必須經(jīng)由接收請(qǐng)求的那個(gè)ip:port發(fā)送出去，這么做是為了穿越對(duì)稱NAT

當(dāng)一個(gè)server監(jiān)聽(tīng)在多interface或者多port上時(shí)，他需要記住從哪一個(gè)上接收到了請(qǐng)求。對(duì)于有狀態(tài)proxy，在傳輸期間存儲(chǔ)這些信息也不是什么難題。然而對(duì)于無(wú)狀態(tài)proxy，不會(huì)存儲(chǔ)請(qǐng)求和應(yīng)答的關(guān)系，所以不能記住從哪里接收到的請(qǐng)求。

所以，為了實(shí)現(xiàn)上述的要求，一個(gè)無(wú)狀態(tài)的proxy就需要把請(qǐng)求中的目的地址和端口號(hào)編碼進(jìn)via 頭域中，一旦這個(gè)應(yīng)答來(lái)了，他就可以提取這個(gè)信息用于指導(dǎo)如何轉(zhuǎn)發(fā)應(yīng)答。

?

四，例子

1，A client sends an INVITE to a proxy server which looks like, in part:INVITE sip:user@example.com SIP/2.0Via: SIP/2.0/UDP 10.1.1.1:4540;rport;branch=z9hG4bKkjshdyff

這個(gè)INVITE 請(qǐng)求從源地址：10.1.1.1：4540這個(gè)客戶端發(fā)出來(lái)的，想要到達(dá)的目的地是user@example.com

服務(wù)proxy的地址為192.0.2.2即proxy.example.com，他會(huì)在5060和5070端口上。

于是，請(qǐng)求會(huì)發(fā)向proxy的5060端口
這個(gè)過(guò)程會(huì)經(jīng)過(guò)nat，所以ip包上的源地值會(huì)變成192.0.2.1，而端口號(hào)變成9988
proxy接收請(qǐng)求再轉(zhuǎn)發(fā)，但是轉(zhuǎn)發(fā)之前要把"rport"參數(shù)insert到via中，于是頭變成了這樣：

INVITE sip:user@example.com SIP/2.0Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77   ---因?yàn)榻?jīng)過(guò)了一個(gè)proxy嘛，所以肯定要加一個(gè)viaVia: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988;branch=z9hG4bKkjshdyff    　　---因?yàn)榘l(fā)現(xiàn)接收request的源ip和via中指定的ip不同，所以這里要加上received和rportThis request generates a response which arrives at the proxy:
   （wxy：針對(duì)這個(gè)請(qǐng)求，proxy會(huì)生成一個(gè)應(yīng)答,是如下這個(gè)樣子的：）SIP/2.0 200 OKVia: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988;branch=z9hG4bKkjshdyff


The proxy strips its top Via header field value, and then examinesthe next one.  It contains both a "received" parameter and an "rport"parameter.  The server follows the rules specified in Section 4 andsends the response to IP address 192.0.2.1, port 9988, and sends itfrom port 5060 on 192.0.2.2:

   proxy首先找到top via header，然后檢查他的下一個(gè)，他既包含了received也包含了rport參數(shù)
   于是這個(gè)服務(wù)器就會(huì)根據(jù)之前說(shuō)的原則，將應(yīng)答發(fā)給192.0.2.1:9988,并且是從192.0.2.2：5060上發(fā)出去的

   SIP/2.0 200 OKVia: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988;branch=z9hG4bKkjshdyffThis packet matches the binding created by the initial request.Therefore, the NAT rewrites the destination address of this packetback to 10.1.1.1, and the destination port back to 4540.  It forwardsthis response to the client, which is listening for the response onthat address and port.  The client properly receives the response.

?

轉(zhuǎn)載于:https://www.cnblogs.com/shuiguizi/p/11235982.html

總結(jié)

以上是生活随笔為你收集整理的SIP协议的传输层原理报文解析(解读rfc3581)(待排版)的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。