以下是關(guān)于RFC3261的規范說(shuō)明，內容比較枯燥。具體理解這些概念，建議讀者參考筆者以前的文章：

　　首先To頭也是最重要設定了期望的請求邏輯，或者用戶(hù)的address-of-record，或者是一個(gè)請求目標資源。這可能是或者不是最終請求接收方。To頭可能包含一個(gè)SIP或者SIPSURL，但是，如果在其他所要求的場(chǎng)景中，它也可以使用其他的URLschemes （例如，tel URL （RFC 2806[9]）。所有的SIP部署必須支持此SIPURI scheme。任何支持TLS部署的，必須也支持SIPS URI scheme。To頭支持一個(gè)顯示名稱(chēng)。

　　UAC可以通過(guò)多種方式學(xué)習如何對一個(gè)特別的請求映射To頭。通常情況下，用戶(hù)建議通過(guò)人機界面輸入To頭，也許通過(guò)人工輸入URL或從地址薄中選擇其地址。很多情況下，用戶(hù)沒(méi)有輸入完整的URL地址，而是輸入一個(gè)數字字符串或者字母（例如，“Bob”）。這是UA的自定義的輸入方式，用戶(hù)自己解析這個(gè)輸入結果。使用字符構建SIPURL的用戶(hù)部分應用在UA期望名字可以被解析為一種域名格式，植入到SIPURL中的@符號前（例如，sip:bob@example.com）。使用字符構建SIPS的用戶(hù)部分應用在用戶(hù)希望通信在安全狀態(tài)，名稱(chēng)可以被域名解析。右側域名經(jīng)常是請求者的主機名稱(chēng)，支持主機域處理出局的請求。對于某些功能來(lái)說(shuō)非常有用，例如，“快速撥號功能”。快速撥號功能要求解析主機域名的用戶(hù)部分內容。tel URL 可以使用在某些環(huán)境中，UA不需要設定域名，只是解析用戶(hù)已輸入的電話(huà)號碼。更準確地說(shuō)，每個(gè)請求通過(guò)的domain都會(huì )有這樣的機會(huì )。舉例，一個(gè)在機場(chǎng)的用戶(hù)可能登錄系統，通過(guò)一個(gè)outboundproxy發(fā)送請求。如果他輸入號碼是“411”的話(huà)（這個(gè)號碼是美國當地號碼查詢(xún)系統），這個(gè)號碼需要解析，然后通過(guò)在機場(chǎng)的 outbound proxy做進(jìn)一步處理，而不是用戶(hù)的主機domain處理。這種情況下，tel:411就是一個(gè)正確的選擇路由。

　　一個(gè)在dialog外面的請求不能包含一個(gè)To tag; 請求中的To來(lái)確認dialog的peer。因為沒(méi)有創(chuàng )建dialog，因此也沒(méi)有tag出現。

　　關(guān)于To 頭域的進(jìn)一步介紹，請參閱Section 20.39。

　　以下是一個(gè)有效的To 頭域的示例：

　　To:Carol <sip:carol@chicago.com>

　　From 頭指示初始請求的邏輯實(shí)體，可能是用戶(hù)address-of-record地址。就像To頭值一樣，它包含一個(gè)URL地址和可選顯示名稱(chēng)。它被SIP要素用來(lái)決定一個(gè)請求所需要的處理規則（例如，自動(dòng)拒絕呼叫）。這是非常重要的規則處理，在一個(gè)正在運行的UA中，From頭不能包含IP地址和這個(gè)主機的FQDN，因為它們都不是邏輯名稱(chēng)。

　　From頭支持一個(gè)顯示名稱(chēng)。除了正確的語(yǔ)法以外，一個(gè)UAC應該使用這個(gè)顯示名稱(chēng)"Anonymous"，如果客戶(hù)實(shí)體是隱藏狀態(tài)，則是一個(gè)無(wú)實(shí)際意義的URL（例如，sip:thisis@anonymous.invalid）。

　　通常情況下，在一個(gè)指定UA生成的請求中，其From頭的值是由用戶(hù)或者用戶(hù)本地域名管理員預設臨時(shí)值。如果一個(gè)指定的UA用來(lái)支持多個(gè)用戶(hù)的話(huà)，它可能帶有一個(gè)可切換到屬性設置，這個(gè)屬性設置文件包括一個(gè)URL，這個(gè)URL和其用戶(hù)屬性實(shí)體文件相對應。請求接收方能驗證請求的發(fā)起方身份，以便確認它們在From報頭的身份聲明（Section 22規范了更多關(guān)于驗證的機制設定）。

　　From報頭必須包含一個(gè)由UAC選擇的新的“tag”參數。具體選擇細節查看Section 19.3。

　　更多關(guān)于From報頭細節，參考Section 20.20。

　　Call-ID 頭工作方式類(lèi)似于一個(gè)唯一的標識符，它用來(lái)成組一系列的消息。在一個(gè)dialog處理過(guò)程中，任何一方UA發(fā)送的所有請求和響應都必須包含相同的Call-ID。每個(gè)UA注冊中的Call-ID應該是相同的。

　　在一個(gè)外部dialog由UAC創(chuàng )建的請求中，Call-ID頭必須由UAC選擇，在整個(gè)處理和時(shí)間段上，它可以作為一個(gè)全局的唯一標識，除非其他設定的methods處理流程修改它。所有SIPUA必須有其含義來(lái)確保這個(gè)它們生成的Call-ID頭不會(huì )被其他UA不經(jīng)意生成一個(gè)新的Call-ID。注意，當獲取到請求時(shí)，對于某些失敗響應處理時(shí)，這些失敗響應針對此請求要求一個(gè)重新修正（例如，認證流程），這些獲取到的請求不會(huì )認為是一個(gè)新的請求，因此，它們不需要一個(gè)新的Call-ID。

　　具體細節規范請參考Section 8.1.3.5。

　　規范推薦使用cryptographically random identifiers （RFC 1750[12]）來(lái)生成Call-ID。部署格式可以使用此格式"localid@host"。Call-ID是大小寫(xiě)敏感的，可以進(jìn)行一比特一比特的簡(jiǎn)單對比。

　　使用cryptographicallyrandom identifiers提供了對會(huì )話(huà)的保護，防止被黑客篡改，同時(shí)也降低了唯一Call-ID的相似度沖突。

　　對于請求來(lái)說(shuō)，不能通過(guò)配置或者界面來(lái)提供Call-ID頭選項選擇。

　　關(guān)于更多Call-ID頭的說(shuō)明，參考Section20.8。

　　Call-ID:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com

　　關(guān)注微信公眾號：asterisk-cn，獲得有價(jià)值的Asterisk行業(yè)分享

　　Asterisk freepbx技術(shù)文檔： www.freepbx.org.cn

　　融合通信商業(yè)解決方案，協(xié)同解決方案首選產(chǎn)品：www.hiastar.com

　　Asterisk/FreePBX中國合作伙伴，官方qq技術(shù)分享群（3000千人）：589995817