本例子是一個基本的SIP四邊傳送，U1->P1->P2->U2，使用proxy來傳送。下邊是過程。

U1 發送：

INVITE sip:callee@domain.com SIP/2.0

Contact: sip:caller@u1.example.com

發給P1,P1是一個外發的proxy。P1并不管轄domain.com，所以它查找DNS并且發送請求到那里。它也增加一個Record-Route頭域值：

INVITE sip:callee@domain.com SIP/2.0

Contact: sip:caller@u1.example.com

Record-Route:

P2收到這個請求。這是domain.com所以它查找位置服務器并且重寫Request-URI。它也增加一個Record-Route頭域值。請求中沒有Route頭域，所以它解析一個新的Request-URI來決定把請求發送到哪里。

INVITE sip:callee@u2.domain.com SIP/2.0

Contact: sip:caller@u1.example.com

Record-Route:

Record-Route:

在u2.domain.com的被叫方接收到這個請求并且返回一個200OK應答：

SIP/2.0 200 OK

Contact: sip: callee@u2.domain.com

Record-Route:

Record-Route:

u2的被叫方并且設置對話的狀態的remote target URI為：

sip: caller@u1.example.com并且它的路由集合是：

(,)

這個轉發通過P2到P1到U1。現在U1設置它自己的對話狀態的remote target URI為：sip:calle@u2.domain.com并且它的路由集合是：

(,)

由于所有的路由集合元素都包含了lr參數，那么U1構造最后的BYE請求：

BYE sip:callee@u2.domain.com SIP/2.0

Route:,

就像其他所有的節點(包括proxy)會做的那樣，它會使用DNS來解析最上的Route頭域的URI值，這樣來決定往哪里發送這個請求。這就發到了P1。P1發現Request-URI中標記的URI不是它負責的域，于是它就不改變這個Request-URI。然后看到它是Route頭域的第一個值，于是就從Route頭域中移去，并且轉發這個請求到P2：

BYE sip:callee@u2.domain.com SIP/2.0

Route:

P2也發現它自己并非負責這個Request-URI的域(P2負責的是domain.com并非u2.domain.com),于是P2并不改變它。它看到自己在Route的第一個值，于是移去這個，并且向u2.domain.com轉發(根據在Request-URI上查找DNS)：

BYE sip:callee@u2.domain.com SIP/2.0

1.3.3 重寫Record-Route頭域值

總結

以上是生活随笔為你收集整理的java voip 的sip服务器搭建_SIP协议开源SIP服务器搭建和客户端安装的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。