通常，Invite請求中的Contact頭域是無用的。例如，UAC和UAS位於不同的局域網中。聯繫人字段可能是：在SIP中，爲什麼Contact頭域必須出現在Invite請求中
INVITE sip:[email protected] SIP/2.0
Contact: Alice<[email protected]>
.....
是沒有用的聯繫領域的同時，我們還可以建立一個對話框。那麼，爲什麼聯繫人頭域是強制性的？
聯繫人字段包含被叫方可以到達呼叫方以供未來請求使用的地址。例如，這是必要的，以便被叫方可以向主叫方發送BYE或重新邀請。
Contact頭說：其中你是（或者說，你的用戶代理），而來自於頭說：你是誰。
您可能有多個SIP設備都註冊到相同的記錄地址（您放在From標頭中的URI）。
此外，註冊請求使用Contact頭來維護SIP的位置服務：它們讓用戶代理更新註冊服務商的位置信息。 （如此一來，如果Alice呼叫Bob，則Contact頭部需要處於2xx響應中，以便Alice可以將2xx的ACK路由到Bob。這指向DarkDust關於一些SIP代理變形的評論Contact header：如果它沒有，你發現自己處於一個只有一半建立電話的不舒服的位置：Alice認爲該電話的建立是因爲她發送了她的ACK，但是Bob從未接收到它。替代聯繫人管理代理使用B2BUA作爲網關;它不需要修改Contact頭，因爲頭將指向B2BUA本身。）
針對Phoenix Luo的評論，由於在Contact頭中使用LAN IP的缺點， RFC 5627描述了一個解決方案 - 使用glo在Contact頭/ s中的可路由的用戶代理URI （GRUUs）。
在我參與的項目中，位置服務的代理將Record-route標頭添加到Invite請求中。所以這個通話可以成功建立。但是，UAC無法像DarkDust所說的那樣收到UAS的Bye請求。 – 2012-03-05 01:17:42
是：將BYE發送到呼叫中的_user agent_，並且該用戶代理由Contact標頭標識，而不是From標頭標識。這就是爲什麼我們不得不發明諸如RFC 5627（在會話發起協議（SIP）中獲取和使用全局可路由用戶代理URI（GRUUs））的原因） – 2012-03-05 11:14:17
謝謝。我會仔細閱讀文件。 – 2012-03-06 03:31:11
謝謝。我在pjprojet中進行了測試。如果聯繫人字段如上所述，則被叫方發送的BYE無法到達主叫方。 – 2012-02-29 10:02:54
這可能是因爲聯繫人是私有LAN地址。如果您的被叫方在另一個網絡中，則無法接通。這是SIP代理被使用的一件事情：他們坐在網絡邊界處，並且衝突聯繫人頭部，以便對方能夠到達所提及的地址。 – DarkDust 2012-02-29 10:07:49
謝謝。在你的幫助下，我修復了這個問題。 – 2012-03-01 02:08:12