以下是關于RFC3261的規范說明，內容比較枯燥。具體理解這些概念，建議讀者參考筆者以前的文章：
一封信讀懂SIP注冊消息關鍵詞
To
首先To頭也是最重要設定了期望的請求邏輯，或者用戶的address-of-record，或者是一個請求目標資源。這可能是或者不是最終請求接收方。To頭可能包含一個SIP或者SIPSURL，但是，如果在其他所要求的場景中，它也可以使用其他的URLschemes （例如，tel URL （RFC 2806[9]）。所有的SIP部署必須支持此SIPURI scheme。任何支持TLS部署的，必須也支持SIPS URI scheme。To頭支持一個顯示名稱。
UAC可以通過多種方式學習如何對一個特別的請求映射To頭。通常情況下，用戶建議通過人機界面輸入To頭，也許通過人工輸入URL或從地址薄中選擇其地址。很多情況下，用戶沒有輸入完整的URL地址，而是輸入一個數字字符串或者字母（例如，“Bob”）。這是UA的自定義的輸入方式，用戶自己解析這個輸入結果。使用字符構建SIPURL的用戶部分應用在UA期望名字可以被解析為一種域名格式，植入到SIPURL中的@符號前（例如，sip:bob@example.com）。使用字符構建SIPS的用戶部分應用在用戶希望通信在安全狀態，名稱可以被域名解析。右側域名經常是請求者的主機名稱，支持主機域處理出局的請求。對于某些功能來說非常有用，例如，“快速撥號功能”�？焖贀芴柟δ芤蠼馕鲋鳈C域名的用戶部分內容。tel URL 可以使用在某些環境中，UA不需要設定域名，只是解析用戶已輸入的電話號碼。更準確地說，每個請求通過的domain都會有這樣的機會。舉例，一個在機場的用戶可能登錄系統，通過一個outboundproxy發送請求。如果他輸入號碼是“411”的話（這個號碼是美國當地號碼查詢系統），這個號碼需要解析，然后通過在機場的 outbound proxy做進一步處理，而不是用戶的主機domain處理。這種情況下，tel:411就是一個正確的選擇路由。
一個在dialog外面的請求不能包含一個To tag; 請求中的To來確認dialog的peer。因為沒有創建dialog，因此也沒有tag出現。
關于To 頭域的進一步介紹，請參閱Section 20.39。
以下是一個有效的To 頭域的示例：
To:Carol <sip:carol@chicago.com>
From
From 頭指示初始請求的邏輯實體，可能是用戶address-of-record地址。就像To頭值一樣，它包含一個URL地址和可選顯示名稱。它被SIP要素用來決定一個請求所需要的處理規則（例如，自動拒絕呼叫）。這是非常重要的規則處理，在一個正在運行的UA中，From頭不能包含IP地址和這個主機的FQDN，因為它們都不是邏輯名稱。
From頭支持一個顯示名稱。除了正確的語法以外，一個UAC應該使用這個顯示名稱"Anonymous"，如果客戶實體是隱藏狀態，則是一個無實際意義的URL（例如，sip:thisis@anonymous.invalid）。
通常情況下，在一個指定UA生成的請求中，其From頭的值是由用戶或者用戶本地域名管理員預設臨時值。如果一個指定的UA用來支持多個用戶的話，它可能帶有一個可切換到屬性設置，這個屬性設置文件包括一個URL，這個URL和其用戶屬性實體文件相對應。請求接收方能驗證請求的發起方身份，以便確認它們在From報頭的身份聲明（Section 22規范了更多關于驗證的機制設定）。
From報頭必須包含一個由UAC選擇的新的“tag”參數。具體選擇細節查看Section 19.3。
更多關于From報頭細節，參考Section 20.20。
例如：
- From:"Bob" <sips:bob@biloxi.com> ;tag=a48s
- From:sip:+12125551212@phone2net.com;tag=887s
- From:Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8
Call-ID
Call-ID 頭工作方式類似于一個唯一的標識符，它用來成組一系列的消息。在一個dialog處理過程中，任何一方UA發送的所有請求和響應都必須包含相同的Call-ID。每個UA注冊中的Call-ID應該是相同的。
在一個外部dialog由UAC創建的請求中，Call-ID頭必須由UAC選擇，在整個處理和時間段上，它可以作為一個全局的唯一標識，除非其他設定的methods處理流程修改它。所有SIPUA必須有其含義來確保這個它們生成的Call-ID頭不會被其他UA不經意生成一個新的Call-ID。注意，當獲取到請求時，對于某些失敗響應處理時，這些失敗響應針對此請求要求一個重新修正（例如，認證流程），這些獲取到的請求不會認為是一個新的請求，因此，它們不需要一個新的Call-ID。
具體細節規范請參考Section 8.1.3.5。
規范推薦使用cryptographically random identifiers （RFC 1750[12]）來生成Call-ID。部署格式可以使用此格式"localid@host"。Call-ID是大小寫敏感的，可以進行一比特一比特的簡單對比。
使用cryptographicallyrandom identifiers提供了對會話的保護，防止被黑客篡改，同時也降低了唯一Call-ID的相似度沖突。
對于請求來說，不能通過配置或者界面來提供Call-ID頭選項選擇。
關于更多Call-ID頭的說明，參考Section20.8。
示例：
Call-ID:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
關注微信公眾號：asterisk-cn，獲得有價值的Asterisk行業分享
Asterisk freepbx技術文檔： www.freepbx.org.cn
融合通信商業解決方案，協同解決方案首選產品：www.hiastar.com
Asterisk/FreePBX中國合作伙伴，官方qq技術分享群（3000千人）：589995817
