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

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

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

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

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

　　以下是一個有效的To 頭域的示例：

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

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

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

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

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

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

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

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

　　具體細節(jié)規(guī)范請參考Section 8.1.3.5。

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

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

　　對于請求來說，不能通過配置或者界面來提供Call-ID頭選項選擇。

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

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

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

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

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

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