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