SIP協議整理
本文記錄開發、實現IMS項目時，整理的SIP協議基礎知識；如有侵權，請告之。html
SIP協議
- 1. SIP協議簡介
SIP是一個應用層的控制協議，能夠用來創建、修改、和終止多媒體會話（或者會議）例如Internet電話。SIP也能夠邀請參與者參加已經存在的會話，好比多方會議。媒體能夠在一個已經存在的會話中方便的增長（或者刪除）。SIP顯示的支持名字映射和重定向服務，這個用於支持我的移動業務－用戶能夠使用一個惟一的外部標誌而不用關係他們的實際網絡地點。SIP在創建和維持終止多媒體會話協議上，支持5個方面：前端
用戶定位：檢查終端用戶的位置，用於通信。node
用戶有效性：檢查用戶參與會話的意願程度。算法
用戶能力：檢查媒體和媒體的參數。數據庫
創建會話：」ringing」,創建會話參數在呼叫方和被叫方。數組
會話管理：包括髮送和終止會話，修改會話參數，激活服務等等。緩存
SIP不是一個垂直集成的通信系統。SIP可能叫作是一個部件更合適，它能夠用做其餘IETF協議的一個部分，用來構造完整的多媒體架構。好比，這些架構將會包含實時數據傳輸協議（RTP）（RFC1889）用來傳輸實時的數據而且提供QoS反饋，實時流協議（RSTP）(RFC2326)用於控制流媒體的的傳輸，媒體網關控制協議（MEGACO）(RFC3015)用來控制到公共電話交換網（PSTN）的網關，還有會話描述協議（SDP）（RFC2327）用於描述多媒體會話。所以，SIP應該和其餘的協議一塊兒工做，才能提供完整的對終端用戶的服務。雖然基本的SIP協議的功能組件並不依賴於這些協議。安全
SIP自己並不提供服務。可是，SIP提供了一個基礎，能夠用來實現不一樣的服務。好比，SIP能夠定位用戶和傳輸一個封裝好的對象到對方的當前位置。而且若是咱們利用這點來經過SDP傳輸會話的描述，對方的用戶代理馬上能夠獲得這個會話的參數。若是咱們用這個像傳輸會話描述（SESSIONDESCRIPTIONSD）同樣呼叫方的照片，一個」呼叫ID」服務很容易就創建了。這個簡單的例子說明了，SIP做爲一個基礎，能夠在其上提供不少不一樣的服務。服務器
SIP並不提供會議控制服務（好比議席控制或者投票系統），而且並無建議會議應該則那樣管理。能夠經過在SIP上創建其餘的會議控制協議來發起一個會議。因爲SIP能夠管理參與會議的各方的會話，因此會議能夠跨異構的網絡，SIP並不能，也不打算提供任何形式的網絡資源預留管理。cookie
安全對於提供的服務來講特別重要。要達到理想的安全程度，SIP提供了一套安全服務，包括防止拒絕服務，認證服務（用戶到用戶，代理到用戶），完整性保證，加密和隱私服務。
SIP能夠基於IPV4也能夠基於IPV6
- 2. SIP協議經常使用術語說明
Address-of-Record：Address-of-Record（AOR）是一個SIP或SIPS URI，它指向帶位置服務的一個域，位置服務能夠將一個URI與另外一個URI（可能找到用戶的URI）映射。典型的，經過註冊來填寫位置服務。一般認爲AOR是用戶的「公開地址」。
Back-to-Back User Agent：背對背用戶代理（B2BUA）是一個邏輯實體，它接收請求，並做爲用戶代理服務器（UAS）處理該請求。爲肯定如何應答一個請求，它做爲用戶代理客戶端（UAC）並生成請求。與代理服務器不一樣，B2BUA保持對話狀態，並參與其創建的對話中發送的全部請求。因爲B2BUA是UAC和UAS間的鏈接，因此不須要明肯定義其行爲。
Call：呼叫是一個非正式術語，它是指對等實體間的通訊，一般是創建多媒體對話。
Call Leg：對話[31]的另外一個名稱，本規範中沒有使用。
Call Stateful：若是一個代理從初始INVITE到終止BYE請求都保留了對話的狀態，那麼該代理有呼叫狀態。有呼叫狀態代理一般是有狀態事務。但反之則不必定成立。
Client：代理是發送SIP請求和接收SIP響應的任何網絡元素。客戶端能夠與也能夠不與用戶直接交互。用戶代理客戶端和代理都是客戶端。
Conference：包含多個參與者的多媒體會話。
Core：核心指明特殊SIP實體類型特有的功能，即有狀態或無狀態代理、用戶代理和註冊員特有的。全部核心，除無狀態代理的核心外，都是事務用戶。
Dialog：對話是兩個UA間持續一段時間的對等SIP關係。對話由SIP消息創建，如INVITE請求的2xx響應。用呼叫標識符、本地標籤和遠程標籤標識對話。對話即RFC2543中的呼叫腿。
Downstream：在一個事務中轉發消息的方向，它是指請求從用戶代理客戶端流向用戶代理服務器的方向。
Final Response：終止SIP事務的響應，與不終止SIP事務的臨時響應相反，全部2xx、3xx、4xx、5xx和6xx響應都是最終響應。
Header：頭是SIP消息的一個組件，它傳遞消息的信息。構造頭字段做爲頭字段序列。
Header Field：頭字段是SIP消息頭的一個組件。一個頭字段能夠是一個或多個頭字段行。頭字段行由一個頭字段名和零或多個頭字段值組成。給定的頭字段行中的多個頭字段值用逗號隔開。某些頭字段只能有一個頭字段值，所以，它們一般只有一個頭字段行。
Header Field Value：頭字段值是一個值，頭字段由零或多個都字段值組成。
Home Domain：此域爲SIP用戶提供服務。典型的，它一般是註冊的記錄地址中URI中出現的域。
Informational Response：與臨時響應相同。
Initiator, Calling Party, Caller：用INVITE請求發起會話（和對話）的一方。從發送創建對話的初始INVITE請求到該對話終止，呼叫者保持此角色。
Invitation：一個INVITE請求。
Invitee, Invited User, Called Party, Callee：接收用於創建新會話的INVITE請求的一方。從接收用於創建對話的初始INVITE請求到該對話終止，被呼叫者保持此角色。
Location Service：SIP重定向或代理服務器使用位置服務，以得到被呼叫者可能位置的信息。它包含記錄地址與零或多個聯繫地址的綁定列表。有多種建立和刪除這種綁定的方法。本規範定義了更新這種綁定的REGISTER方法。
Loop：一個請求到達代理，而後被轉發，最後又返回到同一個代理。當請求第二次到達代理時，Request-URI與第一次相同，其它影響代理操做的頭字段也不變，所以代理能對該請求做出與第一次相同的處理決定。循環的請求是錯誤的，由協議描述檢測和處理循環請求的程序。
Loose Routing：若是代理遵循本規範定義的處理路由頭字段的程序，那麼咱們就稱其爲鬆散路由選擇。該程序將請求的目的地址（在Request-URI中）與請求在路由中要訪問的代理（在路由頭字段中）相分離。符合此機制的代理便是鬆散路由器。
Message：協議中SIP元素間發送的數據。SIP消息是請求或響應。
Method：方法是請求調用服務器上的基本功能。方法在請求消息中。方法的實例有INVITE和BYE等。
Outbound Proxy：從客戶端接收請求的代理，儘管它可能不是Request-URI解析的服務器。通常手動爲UA配置一個出站代理，或經過自動配置協議獲知一個代理。
Parallel Search：在並行搜索中，代理在接收到入站請求後，向可能的用戶位置發佈幾個請求。在順序搜索中，發送一個請求後，代理等待最終響應，而不是當即發送下一個請求；並行搜索在發送請求時，不等待先前請求的結果。
Provisional Response：服務器使用該響應指示進行的響應，該響應不終止SIP事務。1xx響應是臨時響應，其它響應都認爲是最終響應。
Proxy, Proxy Server：一個媒介（中間）實體，它既做爲服務器，也做爲客戶端（代替其它客戶端發送請求）。代理服務器主要執行路由選擇，即其職責是確保請求發送到一個離目標用戶「更近」的實體。代理也可用於執行策略（例如，肯定一個用戶能夠發起呼叫）。代理負責解釋，若是須要的話，在轉發請求前重寫請求消息的特定部分。
Recursion：當客戶端在響應的Contact頭字段中產生一個或多個URI的請求時，客戶端遞歸一個3xx響應。
Redirect Server：重定向服務器是用戶代理服務器，它爲接收到的請求生成3xx響應，告訴客戶端聯繫一個可能的URI集。
Registrar：註冊員是服務器，它接收REGISTER請求，並把從請求中接收的信息放入其所在的域的位置服務中。
Regular Transaction：正常事務是方法非INVITE、ACK和CANCEL的事務。
Request：爲調用一個特殊的操做。客戶端向服務器發送的SIP消息。
Response：爲指明客戶端向服務器發送的請求的狀態，服務器向客戶端發送的SIP消息。
Ringback：回鈴是呼叫者的應用產生的信令音調（signalingtone），代表被呼叫者正在響鈴。
RouteSet：路由集是按順序的SIP或SIPSURI的集合，它是發送特殊請求時必須遍歷的代理的列表。路由集是可經過頭如Record-Route識別的，或是可配置的。
Server：服務器是一個網絡元素，它接收請求，併爲這些請求發送響應。服務器的實例有代理、用戶代理服務器、重定向服務器和註冊員。
Sequential Search：在順序搜索中，代理服務器按順序嘗試每一個聯繫地址，在前一個產生最終響應後再開始嘗試下一個。一般用2xx或6xx最終響應終止一個順序搜索。
Session：在SDP規範中這樣描述：「多媒體會話是多媒體發送者、接收者以及發送者和接收者間數據流的集合。多媒體會議是多媒體會話的實例。」（RFC2327[1]）（定義的SDP會話包含一個或多個RTP會話。）正如所定義的，在同一會話中，被呼叫者能夠被不一樣的呼叫邀請屢次。若是使用SDP，會話由源字段中的SDP用戶名、會話ID、網絡類型、地址類型和地址元素的串接定義。
SIPTransaction：SIP事務在客戶端和服務器之間發生，包含從客戶端向服務器端發送的第一個請求到服務器端向客戶端發送的最後一個響應（非1xx）間的全部消息。若是請求是INVITE而最後的響應不是2xx，那麼事務也包含響應的ACK。INVITE請求的2xx響應的ACK是一個獨立的事務。
Spiral：螺旋是發送到代理，繼續轉發，再次回到該代理的SIP請求，可是此次將作出不一樣於原始請求的處理決定，一般表示請求的Request-URI與先前的不一樣。螺旋不是一個錯誤狀況，與循環不一樣。典型的緣由是呼叫轉發。一個用戶呼叫joe@example.com.com，代理將其轉發到Joe的PC，PC反之將其轉發給bob@example.com。該請求再次轉發到.com代理。可是，這不是循環。由於此時該請求的目標用戶不一樣於上次，它被稱爲螺旋，這是一種有效的狀況。
Stateful Proxy：本規範定義的在處理請求過程當中，維持客戶端和服務器事務狀態機的邏輯實體，也稱爲事務有狀態代理。有狀態代理行爲的詳細定義見第16節。（事務）有狀態代理不一樣於呼叫有狀態代理。
Stateless Proxy：本規範定義的在處理請求過程當中，不維持客戶端和服務器事務狀態機的邏輯實體。無狀態代理轉發它從下游接收到的每一個請求和從上游接收的每一個響應。
Strict Routing：若是代理遵循RFC2543以及本版本的先前工做中的路由處理規則，則稱代理爲嚴格路由。使用嚴格路由規則時，當出現Route頭字段時，代理會損壞Request-URI的內容。本規範沒有使用嚴格路由行爲，而是使用鬆散路由行爲。實現嚴格路由的代理稱爲嚴格路由器。
Target Refresh Request：將在對話中發送的目標更新請求定義爲請求，它能修改對話的遠程目標。
Transaction User(TU)：傳輸層上的協議處理層。事務用戶包括UAC核心、UAS核心和代理核心。
Upstream：事務中消息的轉發方向，它是指響應從用戶代理服務器流向用戶代理客戶端的方向。
URL-encoded：根據RFC2396編碼的字符串，見第2.4[5]節。
User Agent Client(UAC)：用戶代理客戶端是建立新請求，而後使用客戶端事務狀態機發送請求的邏輯實體。UAC角色僅存在事務的持續時間內。換言之，若是軟件發起一個請求，它僅在該事務的持續時間內是一個UAC。若是隨後它接收到一個請求，在處理此事務時，它被假想成一個用戶代理服務器角色。
UAC Core：事務和傳輸層上的UAC的處理功能集。
User Agent Server(UAS)：用戶代理服務器是一個邏輯實體，它產生SIP請求的響應。響應接收、拒絕和重定向請求。該角色僅存在於事務期間。換言之，若是軟件對請求做出響應，那麼它在事務期間就是UAS。若是隨後它產生一個請求，那麼在處理事務的期間咱們就把它假想成用戶代理客戶端。
UASCore：事務和傳輸層上UAS的處理功能集。
User Agent(UA)：既能做爲用戶代理客戶端又能做爲用戶代理服務器的邏輯實體。角色UAC和UAS，以及代理和重定向服務器都是定義在事務的基礎上的。例如，當用戶發起一個呼叫發送初始INVITE請求時，它做爲UAC；當它從被呼叫者接收BYE請求時，做爲UAS。相似的，同一軟件能做爲一個請求的代理服務器和下一個請求的重定向服務器。以上定義的代理、位置和註冊服務器都是邏輯實體。實現時可能將它們結合到一個應用中。
- 3. SIP協議結構
SIP是一個分層協議，這就意味着其行爲用相對獨立的處理階段集來描述，每一個階段間鬆耦合。爲便於表述，協議的行爲用層來描述，容許對功能的描述跨越元素。可是它沒有規定實現。當咱們說一個元素「包含」一層，咱們的意思是說元素聽從該層定義的規則。並不是協議指定的每一個元素都包含每一層。並且，SIP所指的元素都是邏輯元素，而非物理元素。物理實現可做爲不一樣邏輯元素，甚至是基於事務（transaction-by-transaction）的。
SIP的最低層是語法和編碼。其編碼指定使用巴科斯範式（BNF）
第二層是傳輸層。它定義在網絡上客戶端如何發送請求和接收響應，服務器如何接收請求和發送響應。全部SIP元素都包含傳輸層。
第三層是事務層。事務是SIP的基礎組件。事務是客戶端事務（使用傳輸層）向服務器事務發送的請求，以及服務器事務向客戶端發回的該請求的響應。事務層處理應用層轉播、響應與請求的匹配以及應用層超時。用戶代理客戶端（UAC）完成任何任務都使用一系列事務。用戶代理包含一個事務層，若有狀態代理。無狀態代理不包含事務層。事務層有一個客戶端組件（稱爲客戶端事務）和服務器組件（稱爲服務器事務），它們都用有限狀態機表示，用來處理特殊請求。
事務層之上的層稱爲事務用戶（TU）。每一個SIP實體，除無狀態代理外，都是事務用戶。當事務用戶想發送請求時，它就建立一個客戶端事務實例，並將請求與目的IP 地址、端口一塊兒發送。建立客戶端事務的TU 也能夠取消事務。客戶端取消事務的時候，就要求服務器中止進一步處理，並恢復到初始化事務前的狀態，而後返回該事務的一個錯誤響應。可經過CANCEL請求完成取消事務，CANCEL請求包含本身的事務，同時也說起須要取消的事務。
SIP元素即用戶代理客戶端和服務器、無狀態和有狀態代理、註冊服務器，包含區分這些元素的核心（Core）。除無狀態代理外，核心是事務用戶。UAC 和UAS核心的行爲依賴於方法，全部方法有一些通用規則（見第8 章）。對UAC 而言，規則支配請求的結構；對UAS而言，規則管理請求的處理和響應的生成。因爲註冊在SIP中扮演很重要的角色，處理REGISTER 的UAS有一個特殊的名稱「註冊員」。第10 章描述了REGISTER 方法的UAC、UAS核心行爲。
其它的請求都在對話中發送。對話是在兩個用戶代理間持續必定時間的對等SIP關係。對話促成兩個代理間消息順序和請求的正確路由。INVITE方法是本規範中定義的用於創建對話的惟一方法。當UAC 在對話的鏈接中發送一個請求時，它遵通用UAC規則以及對話中請求規則。
SIP中最重要的方法是INVITE方法，它用於在參與者間創建會話。會話是參與者和參與者間通訊的媒體流的集合。
- 4. SIP消息結構
SIP消息是從客戶端到服務器的請求，或從服務器到客戶端的響應。
儘管語法在字符集和語法細節上不一樣，請求和響應都使用基本的RFC 2822格式。（SIP容許頭字段不是有效的RFC 2822頭字段。）兩種類型的消息都由一個起始行、一個或多個頭字段、一個標識頭字段結束的空行和一個可選消息體組成。
generic-message=start-line
*message-header
CRLF
[message-body]
start-line=Request-Line/Status-Line
起始行、每一個消息頭行和空行必須以回車換行序列（CRLF）終止。注意：即便沒有消息體，也必須有空行。
除了上面所述的字符集不一樣外，SIP消息和頭字段語法大部分與HTTP/1.1相同。
4.1. 請求
SIP請求的起始行有Request-Line，做爲與其它消息的區分。Request-Line包含一個方法名、一個Request-URI和由空格（SP）字符分開的協議版本。
Request-Line以CRLF結束。除在終止行CRLF序列中外，其它的地方都不容許CR或LF。在元素中不容許任意數量的空格(LWS)。
Request-Line=Method SP Request-URI SP SIP-Version CRLF
Method：用於註冊Contact信息的REGISTER；用於創建會話的INVITE、ACK和CANCEL；用於終止會話的BYE和用於查詢服務器能力的OPTIONS。用於即時消息的MESSAGE；SIP擴展在RFC中可能有附加方法。
Request-URI：Request-URI是SIP或SIPS URI，描述見第17.1節，或是普通URI（RFC 2396）。它指明請求的目的用戶或服務。Request-URI不能包含未保留空間（unescaped spaces）或控制字符，也不能包圍在「<>」中。
SIP元素可能支持「SIP」和「SIPS」之外的Request-URI模式，如RFC 2806中的「tel」URI模式。SIP元素可以使用任何機制將非SIPURI轉換成SIPURI、SIPS URI或其它模式。
SIP-Version：請求和響應消息都包含所使用的SIP版本號，遵循[H3.1]（用SIP替換HTTP、SIP/2.0替換HTTP/1.1）中關於版本次序、規範要求和版本號更新的描述。爲聽從本規範，發送SIP消息的應用必須包含SIP-Version「SIP/2.0」。SIP-Version字符串區分大小寫，實現時必須發送大寫形式的字符串。
與HTTP/1.1不一樣，SIP將版本號視爲字符串。而實際上，這是沒有區別的。
例如：
4.2. 應答
SIP響應在起始行中有一個Status-Line，做爲與請求的區分。Status-Line依次由協議版本號、數字Status-Code和以及相關的文本分析（textual phrase）組成，它們之間用字符SP隔開。
除在最後的CRLF序列中，其餘地方不容許有CR或LF。
Status-Line=SIP-Version SP Status-Code SP Reason-Phrase CRLF
Status-Code是一個三位整數的結果代碼，它指明嘗試理解和知足請求的結果。Reason-Phrase是Status-Code的簡短的文本描述。Status-Code用於自動控制，Reason-Phrase便於人理解。客戶端不須要檢查或顯示Reason-Phrase。
建議這些緣由分析的一些特定用語，實現能夠先用其它的文本，例如，在請求的Accept-Language頭字段中指明的語言。
Status-Code的第一個數字定義響應類型。後面的兩位數字沒有類別的意義。所以，狀態代碼在100到199之間的響應成爲「1xx」響應，狀態代碼在200到299之間的響應成爲「2xx」響應，依此類推。SIP/2.0中第一個數字有六種值：
1xx:informational－已經收到請求、繼續處理請求。
2xx:success－已經成功收到，理解和介紹行動。
3xx:Redirection－爲完成呼叫請求，還須採起進一步地動做。
4xx:ClientError－請求有語法錯誤或服務器不能執行請求。
5xx:ServerError－服務器出錯，不能執行合法請求。
6xx:GLOBALFAILURE－任何服務器都不能執行請求。
例如：
4.3. 頭字段
在語法和語義方面，SIP頭字段和HTTP頭字段很類似。特別的，SIP頭字段遵循HTTP/1.1中消息頭語法的定義，以及擴展多行頭字段的規則。可是，後者在HTTP中有隱含的空白和摺疊（white space and folding）。本規範聽從RFC 2234，使用明確的空白和摺疊做爲語法的完整部分。
HTTP/1.1中指出其值用逗號分隔的、具備相同字段名的多個頭字段能組合成一個頭字段。這一樣適用於SIP，但對不一樣的語法有特殊的規則。特別的，SIP頭的語法格式以下：
header=header-name HCOLON header-value *(COMMA header-value)
它容許將名稱相同的頭字段組合成用逗號分隔的一列。除非頭字段值爲「*」，Contact頭字段容許用逗號分隔。
4.3.1. 頭字段格式
頭字段遵循RFC 2822的第2.2節中的通用頭格式。每一個頭字段依次由：字段名、冒號「：」和字段值組成。
field-name:field-value
消息頭的正式語法容許冒號的兩邊有任意多個空格；可是，實現時應避免字段名和冒號間的空白，在冒號和字段值間使用一個空格（SP）。
Subject: lunch
Subject : lunch
Subject :lunch
Subject: lunch
所以，以上格式都是有效格式，且意義相同，但最後一個是首選格式。
頭字段可擴展爲多行，方法是在每一個附加行前添加一個空格（SP）或橫向製表（HT）。一行的結束以及下一行開始的空格都看做一個空格（SP）字符。所以，如下兩種方式意義相同：
Subject: I know you’re there,pick up the phone and talk to me!
Subject: I know you’re there,
pick up the phone
and talk to me!
不一樣字段名的頭字段的相對順序並不重要。但推薦須要代理處理的頭字段（例如，Via、Route、Record-Route、Proxy-Require、Max-Forwards和Proxy-Authorization）放在消息的頭部，以便於快速解析。相同字段名的頭字段行的相對順序很是重要。帶相同字段名的多個頭字段行僅出如今這樣的消息中：頭字段的整個字段值的定義是用冒號分隔的一列。咱們能夠將多個頭字段行組合成一個「field-name:fieldvalue」對，而不改變消息的語義，方法是依次將每一個字段值添加到第一個後，它們之間用逗號分隔。WWW-Authenticate、Authorization、Proxy-Authenticate和Proxy-Authorization不符合本規則，字段名爲上述項的多個頭字段行可能在一個消息中同時出現，所以不能將它們組合成一個頭字段行。
實現應能以每行一值或逗號分隔值的格式處理相同名稱的多個頭字段行。
如下幾組頭字段行是合法的而且意義相同：
Route: <sip:alice@atlanta.com>
Subject: Lunch
Route: <sip:bob@biloxi.com>
Route: <sip:carol@chicago.com>
Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>
Route: <sip:carol@chicago.com>
Subject: Lunch
Subject: Lunch
Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>, <sip:carol@chicago.com>
如下幾組是合法的，但意義不一樣：
Route: <sip:alice@atlanta.com>
Route: <sip:bob@biloxi.com>
Route: <sip:carol@chicago.com>
Route: <sip:bob@biloxi.com>
Route:<sip:alice@atlanta.com>
Route: <sip:carol@chicago.com>
Route: <sip:alice@atlanta.com>, <sip:carol@chicago.com>, <sip:bob@biloxi.com>
頭字段值的格式按頭名定義。它一般是一個TEXT-UTF8八位位組序列，或一個空格、標記、分隔符和引用串的組合。許多現用的頭字段遵循這樣的通用格式：字段值，隨後是分號分隔的參數名、參數值對：
field-name: field-value*(;parameter-name=parameter-value)
儘管在頭字段值後可附加任意多個參數對，但任何給定的參數名不能出現屢次。比較頭字段時，字段名是不區分大小寫的。除非在特定頭字段的定義中有說明外，字段值、參數名和參數值都是不分大小寫的。標記一般不區分大小寫。除非特殊說明，引用串值要區分大小寫。例如：
Contact:<sip:alice@atlanta.com>;expires=3600
與CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600意義相同；
且Content-Disposition: session;handling=optional與
content-disposition: Session;HANDLING=OPTIONAL意義相同。
如下兩個頭字段意義不一樣：
Warning: 370 dev null "Choose a bigger pipe"
Warning:370 dev null "CHOOSE A BIGGER PIPE"
4.4. 消息體
4.4.1. 消息體類型
消息體的Internet媒體類型由Content-Type頭字段指定。若是對體進行了任何編碼，如壓縮，那麼必須在Content-Encoding頭字段中指出。不然，必須省略Content-Encoding。若是可行，消息體的字符集做爲Content-Type頭字段值的一部分。
能夠在消息體中使用RFC2046 [10]中定義的「多方」MIME 類型。若是遠程實現請求，經過不包含多方的Accept頭字段請求非多方消息體，那麼發送包含多方消息體的請求的實現，必須發送一個會話描述，做爲非多方消息體。
SIP消息可能包含二進制體或體部分。若是發送者沒有明確指定字符集參數，定義「文本」類型的媒體子類型有默認的字符集值「UTF-8」。
4.4.2. 消息體長度
在Content-Length 頭字段中指定以字節計算的體長度。第20.14 節詳細描述了頭字段的必須內容。
HTTP/1.1 的「分塊」傳輸編碼不能用於SIP。（注意，爲以分塊序列傳輸消息，「分塊」編碼修改消息體，每個都有大小指示器）
- 5. 通用用戶代理行爲
用戶代理表示終端系統。它包括用戶代理客戶端 (UAC)和用戶代理服務器(UAS)，UAC生成請求，UAS響應請求。外部因素（用戶點擊按鈕或PSTN線信號）促使UAC生成請求，並處理響應。UAS接收請求，而且根據用戶輸入、外部因素、程序執行結果或者其它機制，生成響應。
當UAC發送請求時，請求經過代理服務器，能夠將這些請求轉發給UAS。當UAS生成響應，響應將轉發給UAC。
UAC和UAS過程取決於兩個因素。第一個是，請求或響應是在對話的內部仍是外部；第二個是，請求的方法。
在本章，咱們討論了處理對話外的請求時，UAC和UAS行爲獨立於方法的規則。這固然包括本身創建對話的請求。
5.1. UAC行爲
介紹對話外的UAC 行爲。
5.1.1. 生成請求
UAC 制定的有效SIP請求，至少必須包括如下頭字段：To、From、Cseq、Call-ID、Max-Forwards 和Via。在全部的SIP請求中，這些頭字段都是必需的。這六個頭字段是SIP消息基本的構件塊，它們共同提供大部分關鍵性消息路由服務，包括消息的尋址、響應的路由、限制消息的傳播、消息的排序和事務的惟一標識符。UAC 制定的有效SIP請求除了包含這些頭字段外，還有必需的請求行。這個請求行包含了方法、Request-URI和SIP版本。
Request-URI消息初始Request-URI應該設置成To字段的URI值。但應注意，REGISTER方法例外。保密性緣由或者便於將這些字段設置成相同的值（特別是在傳輸過程當中，原始UA指望改變Request-URI），可能不符合須要。
在一些特殊的狀況中，預有的路由集合的存在可能影響消息的Request-URI。預有的路由集合多是用來識別一系列服務器的URI有序集合，UAC將對話外的出站請求發送到其中一個服務器上。一般，預有的路由集合由用戶或者服務提供商在UA上手動配置，或者經過一些其它的非SIP機制配置。當提供商但願用帶外代理配置UA時，推薦經過爲UA提供一個帶外代理預有的帶單一URI的路由集合來配置UA。
To To頭字段首先指明瞭想要的請求的「邏輯」接收者或者用戶的記錄地址或者做爲請求目標的資源。這不必定是請求的最終接收者。To字段可能包含SIP或者SIPS URI，在適當的時候，它也能夠使用其它URI模式（例如，tel URL (RFC 2806 [8])）。全部SIP執行必須支持SIPS URI模式。任何支持TLS的執行必須支持SIPS URI模式。
UAC能夠知道怎樣以多種方法爲特定的請求填充To頭字段。一般，用戶建議To頭字段經過用戶界面填充——多是手動輸入URI或者從地址本中選擇。一般，用戶沒必要鍵入完整的URI，而是鍵入數字或字符串（如，「bob」）。這由UA來選擇怎樣解釋此輸入。使用字符串來造成用戶SIPS URI的一部分，意味着UA但願此名字能夠在SIPS URI註冊的右邊（RHS）進行域名解析(如，sip:bob@example.com)。使用字符串來造成用戶SIPS URI的一部分，意味着UA 但願能夠安全地通訊，同時，此名字能夠在[@]的右邊進行域名解析。右邊一般是請求者的歸屬域，這考慮了處理出站請求的歸屬域。這種像「快速撥號」的特徵頗有用，它須要歸屬域的用戶部分的解釋。
當UA 不但願指明應該解釋用戶輸入的電話號碼的域時，能夠使用tel URL。相反，UA但願指明請求經過的每一個域。例如，在飛機場的用戶可能已經登機，經過飛機場的帶外代理髮送請求。若是鍵入「411」（美國本地目錄幫助的電話號碼），這須要經過飛機場——而不是用戶歸屬域的帶外代理解釋並處理它。在這種狀況中，tel:411 將是正確的選擇。
對話外的請求不能包含To 標籤，請求中的To 字段標籤表示對等對話。由於沒有創建對話，因此不存在標籤。
From From頭字段表示請求發起者的邏輯身份，有多是用戶的記錄地址。和To字段同樣，它包含了URI和顯示名稱，顯示名稱是可選的。SIP元素用它來肯定應用於請求的處理規則（如，自動呼叫拒絕）。一樣地，由於沒有邏輯名字，不包含IP地址或者UA運行主機的正式域名的From URI很重要。
From頭字段考慮了顯示名稱。若是客戶端的身份是隱藏時，UAC應該使用顯示語法正確的名字「匿名的（anonymous）」，而不是無心義的URI(像sip:thisis@anonymous.invalid)。
一般，特殊UA產生的、在請求中填充到From頭字段的值是用戶或者用戶本地域的管理員預先提供的。若是多個用戶使用特殊UA，那麼，它具備可交換的描述，包括對應於描述用戶身份的URI。爲了肯定它們是From 頭字段所聲稱的人，請求的接收者能夠認證請求的發起者。
From 字段必須包含UAC選擇的新標籤參數。
Call-ID Call-ID頭字段做爲集合一系列消息的惟一標識符。在對話中，每一個UA 發送的全部請求和響應中，Call-ID 必須是同樣的。UA 的每一個註冊中，它應該是同樣的。
在UAC 建立的對話外的新請求中，若是不是特定方法行爲覆蓋的，UAC選擇的Call-ID頭字段必須是在時間和空間上全球惟一的標識符。全部的SIPUA必須有一種方法來保證其餘UA 不會產生它們產生的Call-ID頭字段。注意，當在特定的失效響應後，重發請求以修正請求時（如，認證挑戰），重的請求將不做爲新的請求，所以不須要新的Call-ID 頭字段；
推薦在生成Call-ID 時，使用密碼學上的隨機標識符（RFC 1750 [11]）。執行時能夠使用這種格式「localid@host」。Call-ID 是區分大小寫的，而且逐字節比較的。
使用密碼學上的隨機標識符提供了會話截獲保護，並減小了Call-ID 衝突的可能性。
對於選擇請求的Call-ID 頭字段的值，不須要規章界面或用戶界面。
CSeq CSeq頭字段是用做識別和指示事務的。它由序列號和方法組成。此方法必須和請求相匹配。對於對話外的非REGISTER 請求，此序列號是任意的。此序列號的值必須是值小於2~31 的32 位的無符號整數。只要遵循上述原則，客戶端就能夠隨意地使用一種機制來選擇CSeq 頭字段值。
Max-Forwards Max-Forwards頭字段是用做限制請求傳輸到其目的地跳躍的點數。它是一個整數，在每一個跳躍點上減一。若是請求在到達其目的地以前，Max- Forwards 值到0，將返回483(太多跳躍點)錯誤響應，拒絕其請求。
UAC必須在每一個請求中插入Max-Forwards頭字段，並賦初始值爲70。此數字足夠長，可保證在沒有環路時，請求不會在SIP網絡中丟失；當存在環路時，此數字不會消耗代理太多的資源。要謹慎地使用更小的值，只有在UA知道網絡拓撲時，才能夠使用更小的值。
Via Via頭字段表示事務中使用的傳輸，並標識了響應發送的位置。僅在選擇了要到達的下一個跳躍點後(這可能包括[4]中過程的使用)，纔在傳輸中加上Via 頭字段的值。
當UAC建立請求時，它必須在請求中插入Via。在頭字段中的協議名和協議版本必須分別是SIP和2.0。Via頭字段值必須包含分支參數（branch parameter）。此參數用來識別請求建立的事務。此參數同時用於客戶端和服務器。
對於UA發送的全部請求，其分支參數的值必須在時間和空間上是惟一的。此規則的異常是CANCEL和非2xx 響應的ACK。CANCEL請求有與它取消的請求相同的分支值。非2xx 響應的ACK也有與它所應答的INVITE響應相同的分支ID。
分支ID 參數惟一的特性，有助於其做爲事務ID使用，和本規範一致的元素插入的分支ID 必須是以「z9hG4bk」字符開頭。這七個字符用做magic cookie（7 認爲是足以確保舊RFC 2543 執行不會選擇這個值），以便於接收請求的服務器能夠肯定以本規範描述的格式（即全球惟一）構造分支ID。在本規範內，分支標籤的精確格式是執行定義的(implementation-defined)。
當請求是經過傳輸層處理的，那麼將發送Via頭的maddr、ttl 和sent-by組件。
Contact Contact頭字段提供了SIP或者SIPS URI，可用於爲隨後請求聯繫UA的具體實例。必須正確地表示Contact頭字段，幷包含任何請求中的SIP或者SIPS URI，這將致使創建對話。Contact的範圍是全局的。即Contact頭字段值包括UA要接收請求的URI，即便是在任何對話外的隨後請求中使用，此URI都必須是有效的。
若是Request-URI或top Route頭字段值包含SIPS URI，Contact頭字段也必須包含SIPS URI。
Supported and Require 若是UAC支持SIP擴展，服務器可將此擴展用於響應，UAC應該在請求中引用Supported頭字段，
列出的可選標籤必須引用標準協議棧RFC中定義的擴展。這就防止了服務器爲了接收
服務而堅持客戶端執行非標準的、供應商定義的特性。由於，供應商也常常參考實驗和情報的RFC 中定義的擴展，定義本身的擴展，因此，它們顯然不能用在請求中的Supported頭字段。
若是UAC堅持要UAS理解，UAC爲處理請求而用於請求的擴展，它必須在請求中插入Require頭字段，列出這些擴展的可選標籤。若是UAC但願將擴展用於請求中，並堅持它所要經歷的任何代理均可以理解這些擴展，它必須在請求中插入Proxy-Require頭字段，列出這些擴展的可選標籤。
和Supported 頭字段一塊兒，Require 和Proxy-Require 中頭字段可選的標籤必須僅僅引用標準協議棧RFC中定義的擴展。
Additional Message Components 在建立了新請求，併合理地構造上面所介紹的頭字段後，能夠添加任何其餘的可選頭字段，做爲具體方法的頭字段。
SIP請求可能包含MIME編碼的消息體。無論請求包含的消息體是什麼類型，必須闡明特定的頭字段來講明主題內容的特徵。
5.1.2. 發送請求
請求的目的地是可計算的。除非有本地的策略指明，目的地必須經過[4]中介紹的DNS過程才能夠肯定。若是路由集合中的第一個元素指示了嚴格的路由器，那麼必須將DNS過程用於請求的Request-URI。不然，必須將DNS過程用於請求中的第一個Route頭字段（若是存在），若是沒有Route 頭字段，將DNS過程用於請求的Request-URI。這些過程產生有序的地址集合、端口和傳輸。若是Request-URI指定SIP源，那麼與過程[4]使用哪一個URI無關；若是輸入的URI是SIPS URI，那麼UAC必須遵循過程[4]。
本地策略能夠指定可選的目的地。若是Request-URI包含SIPS URI，那麼，任何可選的目的地必須和TLS 聯繫。除此之外，若是請求中沒有包含Route頭字段，那麼，就不約束可選的目的地。這提供了簡單的可選機制——爲預有的路由集合指定帶外代理。然而，不推薦配置帶外代理，反而應該使用單一URI 的預有的路由集合。若是請求包括路由頭字段，那麼請求應該發送到來自其最上面值的位置；可是也能夠遵循本文檔指定的路由和Request-URI策略發送至任何UA信任的服務器（與RFC 2543中相反）。特別的是，帶外代理配置的UAC 應該試圖發送請求給第一個Route頭字段值指明的位置，而不是採用策略發送全部消息給帶外代理。
這確保了沒有添加Record-Route頭字段值的帶外代理將不參與隨後請求的路徑。它也容許不能解析第一個Route URI的終端，將此任務委派給帶外代理。
對於有狀態元素，UAC應該遵循[4]中定義的過程——嘗試每一個地址，直到聯繫到服務器。每次嘗試構成新的事務，所以，每次用新的分支參數攜帶不一樣的最上面的Via頭字段值。此外，在Via 頭字段的傳輸值設置成每一個目標服務器肯定的傳輸。
5.1.3. 處理應答
響應最初是在傳輸層處理，而後傳輸處處理層。處理層完成其處理，而後將響應傳輸到TU。TU的大多數響應處理是指定方法的。可是，還有一些通用的行爲與方法無關。
Transaction Layer Errors 在不少狀況中，處理層返回的響應不是SIP消息，而是處理層錯誤。當從處理層接收到超時錯誤時，必須視爲接收到了408（請求超時）狀態代碼。若是傳輸層報告了重大的傳輸錯誤（一般，因爲UDP 的重大ICMP錯誤或者TCP鏈接錯誤），這種狀況必須視爲503（服務不可用）狀態代碼。
Unrecognized Responses UAC必須將其不識別的最終響應視爲對等於x00類的響應代碼，而且，UAC必須可以處理全部的x00響應代碼。
例如，UAC接收到了不識別的響應代碼431，它能夠安全地設想此請求有問題，並將響應處理爲接收到了400（錯誤請求）響應代碼。UAC必須將不一樣於100 的、不識別的臨時響應視爲183（會話進行）。UAC 必須可以處理100和183 響應。
Vias 若是在響應中存在不止一個Via頭字段，那麼UAC應該丟棄這些信息。在請求發起者以前的其餘Via 頭字段值的狀態，暗示消息是錯誤指向的或者是不可靠的。
Processing 3xx Responses 在接收到重定向響應後（如，301響應狀態代碼），客戶端應該使用Contact頭字段的URI來講明一個或者多個基於重定向請求的新請求。客戶端從正確包含URI和原始請求Request-URI的初始目標集合開始。若是客戶端但願闡明此請求的基於3xx類響應的新請求，它將此URI放在目標集合中。服從本規範的約束，客戶端能夠選擇將哪一個Contact URI放在目標集合中。隨着代理遞歸，處理3xx 類響應的客戶端不可以再在目標集合中添加任何給定的URI。若是原始請求有Request-URI中的SIPS URI，那麼客戶端能夠選擇換成非SIPS URI，可是應該通知用戶不安全URI的重定向。
任何新請求均可能接收到包含其本身原始URI的3xx響應做爲聯繫。兩個位置能夠互相配置成重定向。將任何給定的URI 僅在目標集合放置一次能夠防止無窮的重定向環路。
隨着目標集合的增加，客戶端能夠以任何順序生成URI 新請求。通用的機制是按照Contact頭字段值的‘q’參數值排序。URI請求能夠是連續的，也能夠是並行的。其中一種方法是，連續地處理遞減的q 值排序，並行地處理URI 的每一個q值。另外一種方法是，僅僅連續地處理遞減的q值排序，任意選擇相等q值之間的聯繫。
若是聯繫列表中的地址形成錯誤，與在下一章所定義的同樣，元素移到列表中的下一地址，直到列表用完爲止。若是列表已經用完，那麼此請求錯誤。
錯誤應該經過錯誤響應代碼（比399大的代碼）來檢測；若是是網絡錯誤，那麼客戶端事務將向事務用戶報告傳輸層錯誤。注意，有些響應代碼說明了重試的請求，重試的請求不該該認爲是錯誤。
當接收到具體聯繫地址失敗時，客戶端應該嘗試下一個鏈接地址。這包括建立新的客戶端事務來傳遞新的請求。
爲了在3xx 響應中建立基於聯繫地址的請求，UAC必須將目標集合中的整個URI複製到Request-URI，除了method-param和header URI參數。它使用頭參數來建立新請求的頭字段值。
注意，在一些實例中，在聯繫地址中通訊的頭字段能夠改成添加到原始重定向請求的現有請求的頭字段中。做爲通用規則，若是頭字段接受了逗號分隔的列標值，那麼新的頭字段能夠添加到原始重定向請求的現有值中。若是頭字段不能接受多個值，那麼，能夠用聯繫地址中通訊的頭字段值重寫原始重定向請求。例如，若是與下列值一塊兒返回聯繫地址：
sip:user@host?Subject=foo&Call-Info=<http://www.foo.com>
那麼，將重寫原始重定向請求的Subject 頭字段，HTTP URI 不過是附加在現有的Call-Info 頭字段值後面。
推薦UAC重用原始重定向請求中相同的To、From和Call-ID，可是UAC能夠選擇更新新請求的Call-ID 頭字段值。
最後，一旦構造了新請求，那麼，使用新的客戶端事務來發送新請求，所以，必須在最上面Via字段中有新的分支ID。
不管從其餘哪一個方面來看，在接收重定向響應基礎上發送的請求應該重用原始請求的頭字段和消息體。
在一些實例中，與接收到的狀態代碼和逾時間隔的狀態有關，能夠在UAC中臨時或者永久地緩存Contact頭字段值。
Processing 4xx Responses 具體的4xx響應代碼與方法無關，須要具體的UA處理。
若是接收到401（未經許可）或407（須要代理認證）響應，那麼UAC應該遵循認證過程，使用憑證來重試請求。
若是接收到413（請求實體太大）響應，請求包含的消息體比UAS願意接受的消息體長，若是可能的話，UAC應該忽略消息體或者使用較短的消息體重試請求。
若是接收到415(不支持的媒體類型)響應，UAS不支持請求中包含的媒體類型。UAC應該重試請求，此時僅使用響應中Accept頭字段列出的類型，響應中Accept-Encoding頭字段列出的編碼和響應中Accept-Language頭字段列出的語言。
若是接收到 416(不支持的URI 模式)響應，服務器不支持Request-URI使用的URI模式。客戶端應該重試請求，此時使用SIPS URI。
若是接收到420（錯誤的擴展）響應，此請求包含Require 或者Proxy- Require頭字段，列出了代理或者UAS不支持的可選標籤特徵。UAC應該重試請求，此時，忽略響應中擴展列出的Unsupported頭字段。
在上面全部的狀況中，經過適當的修改建立新請求，重試請求。新請求組成新事務，應該有與原來請求相同的Call-ID、To 和From 值，可是Cseq應該包含比原來高的新序列號。
其它的4xx響應，包括仍然在定義的，重試能夠與也能夠不與方法和使用案例有關。
5.2. UAS行爲
當UAS處理對話外的請求時，與方法無關，要遵循一套處理規則。
注意，請求處理是基本的。若是接受請求，全部與其相關的狀態改變必須執行。若是拒絕請求，全部的狀態改變都不能執行。
5.2.1. 方法檢查
一旦請求經過了認證（或者跳過認證），UAS必須檢查請求的方法。若是UAS識別可是不支持請求的方法，它必須生成405（方法不容許）響應。UAS必須爲405（方法不容許）響應添加Allow頭字段。Allow頭字段必須列出UAS生成消息支持的方法集合。
若是方法是服務器支持的一種，那麼，將繼續處理。
5.2.2. 包頭檢查
若是UAS不能理解請求中的頭字段（便是沒有在本規範或者其它支持的擴展中定義此頭字段），那麼服務器必須忽略此頭字段，並繼續處理消息。UAS應該忽略任何在處理請求中非必需的、非格式化的頭字段。
To and Request-URI To頭字段標識了原始請求中From字段中標識的用戶。因爲呼叫轉移或者其它代理操做，原始接收者能夠是也能夠不是UAS處理此請求。當To頭字段不是UAS身份時，UAS能夠應用任何策略來肯定是否接受請求。然而，即便在To頭字段中有它們不識別的URI模式（如，tel:URI），或者To頭字段沒有指明UAS已知的或者當前用戶，推薦UAS接受請求。另外一方面，若是UAS決定拒絕此請求，它應該生成響應403(Forbidden)狀態代碼，並將其傳送給服務器事務發送。
然而，Request-URI識別處理請求的UAS。若是Request-URI使用了UAS不支持的模式，它應該拒絕此請求，返回416（不支持URI 模式）響應。若是Request-URI不識別UAS將要接受請求的地址，它應該拒絕此請求，返回404（沒找到）響應。典型地，使用REGISTER方法來爲具體的聯繫地址綁定其記錄地址的UA，將查找Request-URI與聯繫地址相等的請求。接收Request-URI的其它潛在資源包括，UA發送的、創建或者更新對話的請求和響應的Contact 頭字段。
Merged Requests 若是請求在To頭字段中沒有標籤，那麼UAS核心必須檢查正在進行事務的請求。若是From標籤、Call-ID和Cseq和事務精確匹配，那麼UAS核心應該生成482（發現環路）響應，並將其發送到服務器事務。
因爲分發，相同的請求從不一樣的路徑屢次發送到UAS。UAS處理第一個接收到的這樣的請求，對於第一個之外的請求，生成482（發現環路）響應。
Require 假定UAS認爲Require是處理請求的要素，那麼，若是存在Require的話，它將檢查Require 頭字段。
UAC使用Require頭字段告訴UAS——爲了正確地處理請求，UAC但願UAS支持的SIP擴展。若是UAS不理解Require 頭字段中列出的可選標籤，它必須返回狀態代碼420（錯誤的擴展）。UAS必須添加Unsupported頭字段，並列出請求的Require 頭字段中它所不理解選項。
注意，在SIPCANCEL中不能使用Require和Proxy-Require，或者發送ACK請求非2xx響應。若是在請求中出現了這些頭字段，必須忽略它們。
ACK 請求2xx 響應必須僅包含在初始請求中出現的Require和Proxy-Require值。
如下是Require 的實例：
UAC -> AS: INVITEsip:watson@bell-telephone.com SIP/2.0
Require: 100rel
UAS-> UAC: SIP/2.0 420 Bad Extension
Unsupported: 100rel
當兩邊都理解了全部選項時，此行爲確保了無延時地進行客戶端-服務器交互；若是不理解選項，將減慢速度（如上例）。對於無缺匹配的客戶端-服務器對，節省了協商機制常常須要的來回路程，交互處理很快。
此外，當服務器不理解客戶端請求的特徵時，它能夠模糊地移動。有些特徵，如呼叫處理字段，僅是終端系統感興趣的。
5.2.3. 內容處理
假定UAS理解客戶端須要的任何擴展，UAS檢查了消息體和描述它的頭字段。若是不理解某一消息體的類型（Content-Type指明的）、語言（Content-Language指明的）或者編碼（Content-Encoding指明的），而且此消息體部分不是可選（Content-Disposition字段指明的），那麼UAS必須拒絕此請求，返回415（不支持的媒體類型）響應。若是請求中包含了UAS不支持的消息體類型，響應必須包括Accept頭字段，列出它所理解的全部消息體。若是請求中包含了UAS不理解的編碼，響應必須包括Accept-Encoding頭字段，列出UAS所理解的編碼。若是請求中包含了UAS不理解的語言，響應必須包括Accept-Language頭字段，列出UAS所理解的語言。除了這些檢查外，消息體處理還與方法及類型有關。
5.2.4. 應用擴展
除非是請求的Supported頭字段中指明瞭支持的擴展，不容許UAS生成響應時應用擴展。若是不支持想要的擴展，那麼服務器應該依靠基準SIP和客戶端支持的擴展。在少數狀況中，沒有擴展，服務器不處理請求，服務器可能發送421（必需擴展）響應。此響應表示，沒有支持指定的擴展，不能生成響應。此必需的擴展必須包含在響應的Require頭字段中。不推薦使用此行爲，由於它將破壞互操做性。
適用於非421響應的任何擴展必須在響應的Require頭字段中列出來。固然，服務器不能應用響應的Require頭字段沒有列出來的擴展。結果，響應的Require頭字段僅包含標準協議棧RFC中定義的可選標籤。
5.2.5. 處理請求
假定經過了前面子章節的全部檢查，UAS處理就成爲面向具體方法的。後面章節分別介紹了REGISTER、OPTIONS 、INVITE、BYE、MESSAGE等請求處理。
5.2.6. 生成響應
當UAS但願爲請求構造響應時，那麼它遵循後面章節介紹的通用過程。在本節沒有詳細介紹的，正在討論的響應代碼的其餘行爲，也是必需的。
一旦與建立響應相關的全部過程完成，UAS就將這些響應發送給它所接收請求的服務器事務。
Sending a Provisional Response 生成響應大的、非面向具體方法的原則是，UAS不該該發佈非INVITE請求的臨時響應；而是，應該儘量地生成非INVITE請求的最終響應。
當生成100(Trying)響應時，請求中的Timestamp頭字段必須複製到100(Trying)響應中。若是在生成響應時有延時，那麼UAS應該將延時加到響應的Timestamp 值中。此值必須包含以秒計算的、發送響應和接收請求的時間差。
Headers and Tags 響應的From 字段必須和請求的From 頭字段相同，響應的Call-ID字段必須和請求的Call-ID 頭字段相同，響應的CSeq 字段必須和請求的CSeq 頭字段相同，
響應的Via字段必須和請求的Via頭字段相同，而且必須保持相同的順序。若是請求中包含請求的To標籤，那麼，響應中的To頭字段必須和請求中的相同。然而，若是請求的To字段沒有包含標籤，那麼，響應中的To頭字段的URI必須和請求中的To頭字段的URI 相同，此外，UAS必須在響應的To頭字段中添加標籤（除了100Trying）響應外，其中可能有標籤）。這用於識別正在響應的UAS，可能會生成對話ID的組件。相同的標籤必須用於該請求的全部響應，包括最終和臨時的（也包括100(Trying)）響應。
5.2.7. 無狀態UAC行爲
無狀態UAS是不能保持事務狀態UAS。它正常地回覆請求，可是丟棄響應發送後的狀態——一般UAS會保留其狀態的。若是無狀態UAS接收轉發的請求，它將從新生成響應，並從新發送響應，就像它第一次收到請求同樣。若是請求是同樣的，除非請求處理的方法老是致使相同的結果，不然UAS不能是無狀態的。例如，此規則輸出無狀態註冊服務器。無狀態代理不使用處理層，它們直接從傳輸層接收到請求，並直接將響應發送給傳輸層。
無狀態UAS角色主要是處理髮布挑戰響應的不需認證的請求。若是對不需認證的請求進行有狀態的處理，那麼，惡意的不需認證的請求能夠建立大量的事務狀態，可能會減慢或者掛掉UAS的呼叫處理，實際上，將形成拒絕服務。
無狀態UAS的大多數重要的行爲以下：
² 無狀態UAS不可以發送臨時(1xx)響應。
² 無狀態UAS不可以轉發響應。
² 無狀態UAS必須忽略ACK請求。
² 無狀態UAS必須忽略CANCEL請求。
² 必須以無狀態方式生成To 頭字段——爲相同請求一向地生成相同標籤的方式。
在其它各個方面，無狀態UAS和有狀態UAS是同樣的。對於每一個新請求，UAS能夠以有狀態或無狀態的方式來操做
- 6. 註冊（REGISTER）
SIP提供了發現機制。若是用戶要發起和另外一個用戶的會話，SIP必須發現可到達目的用戶的當前主機。發現處理常常是SIP網絡元素完成，好比代理服務器和重定向服務器——它們負責接收請求，決定要發送請求的用戶位置，而後將它發送到相應的位置。爲了完成這些，SIP網絡元素查詢了抽象服務——定位服務，這提供了特定域的地址綁定。這些地址綁定將輸入的SIP和SIPS URI（如，sip:bob@biloxi.com）映射到想要的用戶「更近」的一個或多個URI（如，sip:bob@engineering.biloxi.com）。最後，代理將查詢定位服務，將接收到的URI映射到想要的接收者常駐的用戶代理。
註冊建立了特定域中定位服務的綁定，它將記錄地址 URI和一個或者多個聯繫地址相關聯。所以，當域中的代理接收Request-URI和記錄地址匹配的請求時，代理將請求轉發給記錄地址已註冊的地址。一般，當請求記錄地址路由到域中時，在域定位服務註冊記錄地址纔有意義。在大多數狀況中，這意味着註冊的域須要與記錄地址的URI域匹配。
創建定位服務內容有不少種方法。其中之一是管理。在上面的實例中，經過訪問公司數據庫能夠知道Bob是工程部門的一員。可是，SIP爲UA提供了一種機制明確地建立綁定。這種機制就是註冊。
註冊必須發送REGISTER請求給特定類型的UAS——便是註冊服務器。註冊服務器做爲域中定位服務的前端，發送和寫基於REGISTER內容的映射。隨後主要是負責此域路由請求的代理服務器查詢此定位服務。
SIP不強制執行定位服務的具體機制。惟一的要求是域中的註冊服務器必須可以在定位服務中讀和寫數據，域中的代理和重定向服務必須可以讀取相同的數據。在同一域內，註冊服務器與特定的SIP代理服務器能夠在同一接點。
6.1. 構造REGISTER請求
REGISTER請求添加、刪除和查詢綁定。REGISTER請求能夠在記錄地址和一個或多個聯繫地址之間添加新綁定。合適地經過認證的第三方能夠完成表明特定記錄地址的註冊。客戶端也能夠刪除之前的綁定或者查詢綁定，肯定記錄地址綁定當前所在的位置。
除非另有說明，REGISTER請求的構造和客戶端發送REGISTER請求的行爲與第5.1節中介紹的通用UAC行爲是同樣。
REGISTER請求不創建對話。UAC能夠在REGISTER請求中包括基於第5.1節介紹的預有的路由集合的Route頭字段。在REGISTER請求和響應中的Record-Route頭字段沒有意義，若是存在，必須忽略。特別的，UAC不能根據REGISTER請求的任何響應中存在和缺乏的Record-Route頭字段建立新的路由集合。
下列頭字段，除了Contact外，必須包含在REGISTER請求中。固然，也能夠包括Contact頭字段。
Request-URI: Request-URI指定了註冊服務器指明的定位服務域。( 如sip:chicago.com)。不能出現SIPS URI的userinfo和@組件。
To: To頭字段包括記錄地址，能夠建立、查詢和修改其註冊。To頭字段和Request-URI字段主要的不一樣是，前者包含用戶名。此記錄地址必須是SIP或者SIPS URI。
From: From頭字段包含負責註冊的人的記錄地址。除非是第三方註冊，此值和To頭字段的值是同樣的。
Call-ID: UAC全部的註冊應該使用與發送到註冊服務器的註冊相同的Call-ID頭字段值。
若是相同的客戶端使用不一樣的Call-ID值，那麼註冊服務器不能檢測延時的REGISTER請求是否沒有排序到達。
CSeq:CSeq值保證REGISTER請求適當的排序。對於每一個使用相同的Call-ID的REGISTER請求，UA必須逐一增長Cseq值。
Contact: REGISTER請求可能包括有一個或多個地址綁定值的Contact頭字段。直到它們接收到來自注冊服務器的前一請求的最終響應，或以前的REGISTER請求超時，UA才能發送新的註冊（便是包含與轉發相對的新Contact頭字段值）。
在REGISTER請求中，下面的Contact頭參數有特定的意義。
action:RFC 2543 不同意action 參數。UAC 不該該使用action 參數。
expires:expires參數表示了UA綁定的有效時間。此參數值是表示秒的數字。若是不提供此參數，那麼將使用expires頭字段的值代替。不規範的值應該視爲等於3600。
6.1.1. 添加綁定
發送給註冊服務器的REGISTER請求包括SIP請求應該轉發給記錄地址的地址。記錄地址包括在REGISTER請求的To頭字段中。
請求的Contact頭字段值主要是由SIP和SIPS URI組成的，它肯定具體的SIP終端（如，「sip:carol@cube2214a.chicago.com」），同時，也能夠使用其它的URI模式。例如，SIPUA能夠選擇註冊電話號碼（使用tel URL，RFC 2806）和email 地址（使用mail to URL，RFC 2368 ）做爲的記錄地址的聯繫人。
例如， Carol，使用記錄地址「 sip:carol@chicago.com 」在SIP註冊服務器的chicago.com 域註冊。chicago.com 域的代理服務器將使用Carol 的註冊，將Carol 的記錄地址請求路由到其SIP終端。
一旦客戶端在註冊服務器上創建了綁定，若是須要，它能夠發送包含新綁定和修訂現有綁定的隨後註冊。REGISTER 請求的2xx 響應，將在Contact 頭字段中包含完整的、在此註冊服務器上註冊記錄地址的綁定列表。
若是REGISTER請求To頭字段的記錄地址是SIPS URI，那麼，請求的Contact頭字段值也應該是SIPS URI。當以其它方式來保證聯繫地址 表示的資源的安全時，客戶端僅註冊SIP記錄地址下的非SIPS URI。這可適用於調用不是SIP協議的URI和不是TLS協議保證其安全性的SIP設備。
註冊不須要更新綁定。典型的是，UA僅更新其本身的聯繫地址。Setting the Expiration Interval of Contact Addresses 當客戶端發送REGISTER請求時，它能夠建議逾時間隔的狀態，表示客戶端註冊有效的時間。（註冊服務器基於其本地策略選擇實際的時間間隔。）
有兩種方法可用於客戶端建議綁定的逾時間隔：經過Expires 頭字段或者expiresContact 頭參數。當在單個REGISTER 請求中給出多個綁定時，後者容許在預先綁定的基礎上建議逾時間隔，可是前者建議的逾時間隔適用於不包含expires 參數的全部Contact 頭字段值。
若是在REGISTER中，表示建議到期時間的兩種機制都不存在，那麼，客戶端表示，它要服務進行選擇。
Preferences among Contact Addresses 若是REGISTER 請求發送多個Contact，那麼，註冊UA要將全部的Contact頭字段值的URI和To字段的記錄地址相關聯。此列表能夠使用Contact頭字段的‘q’參數排出優先級。Q參數表示具體Contact頭字段值與記錄地址其它綁定的相關優先級。
6.1.2. 刪除綁定
註冊是軟狀態，除非是更新纔到期，可是也能夠明確地刪除。客戶端能夠影響註冊服務器選擇的逾時間隔。經過在REGISTER 請求的聯繫地址指定「0」逾時間隔，UA請求當即刪除綁定。UA應該支持這種機制，以便於能夠在逾時間隔到期以前刪除綁定。
REGISTER-specific Contact頭字段值「*」用於全部的註冊，可是，若是Expires頭字段不用值「0」表示，不能使用「*」。
使用「*」Contact 頭字段值容許註冊——在不知道精確值時，刪除與記錄地址相關的全部綁定。
6.1.3. 提取綁定
無論請求是否包含有Contact 頭字段，REGISTER 請求成功的響應包含所有的現有綁定。若是REGISTER 請求中沒有Contact 頭字段，那麼綁定列表左邊不改變。
6.1.4. 更新綁定
每一個UA負責更新它以前創建的綁定。UA不該該更新其它UA創建的綁定。註冊服務器的200（OK）響應包含一系列的Contact頭，列舉了全部的當前綁定。UA 比較每一個聯繫地址，檢查它是否建立了聯繫地址。若是是，根據expires參數——若是沒有，就根據Expires 字段值更新逾時間隔。UA隨後在逾時間隔結束以前，爲其每一個綁定發佈REGISTER請求。它也能夠在REGISTER請求中，組合幾個更新。
在單個引導週期，UA應該爲全部的註冊使用相同的Call-ID。除非有重定向，註冊更新應該發送到與原始註冊相同的網絡地址。
6.1.5. 設置內部時鐘
若是REGISTER 請求的響應包含有Data 頭字段，那麼客戶端能夠使用此頭字段獲取當前的時間，設置內部時鐘。
6.1.6. 發現註冊服務器
UA能夠使用三種方法來肯定發送註冊的地址：經過配置、使用記錄地址和多播。能夠用註冊服務器地址配置UA，這種方法超出了本規範的範圍。若是沒有可配置的註冊服務器地址，那麼，UA應該使用通用的SIP服務器定位機制，將主機部分的記錄地址做爲請求的Request-URI和地址。例如，UA爲用戶「sip:carol@chicago.com」將REGISTER請求尋址到「sip:chicago.com」。
最後，UA能夠配置成多播。多播註冊都編址爲已知的「全部SIP服務器」多播地址「sip.mcast.net」(224.0.1.75 for IPv4)。如今沒有分配已知的Ipv6的多播地址；當須要時，將單獨說明這種分配。SIPUA能夠偵聽此地址，並使用它來知道其它本地用戶的當前位置；可是，它們並不響應請求。
在有些狀況中，多播註冊可能不適用，例如，若是多播事務共享相同的本地網絡。
6.1.7. 發送請求
一旦構造了REGISTER方法，並肯定了消息的目的地，那麼，UAS遵循第5.1.2節介紹的過程，將REGISTER請求發送給處理層。若是由於REGISTER沒有響應，處理層返回超時錯誤，UAS不該該當即向相同的註冊服務器再嘗試註冊。
當即再嘗試有可能也超時。爲形成超時的條件等待合理的時間間隔，能夠減小沒必要要的網絡負載。沒有強制具體的時間間隔。
6.1.8. 錯誤響應
若是UA 接收到423(Interval Too Brief)響應，在使得REGISTER 請求中的全部聯繫地址逾時間隔等於或大於423(Interval Too Brief)響應Min-Expires 頭字段的逾時間隔後，它能夠再註冊。
6.2. 處理REGISTER請求
註冊服務器是UAS，在其管理域內，它響應REGISTER請求，並保留能夠訪問代理服務器和重定向服務器的一系列綁定。註冊服務器遵循第5.2節處理響應，可是它只接受REGISTER請求。註冊服務器不能生成6xx響應。
在適當的時候，註冊服務器能夠重定向REGISTER請求。通用的用法是，註冊服務器偵聽多播接口，用302（暫時清除）響應將多播REGISTER請求重定向到其本身單播接口。
若是Record-Route包含在REGISTER請求中，那麼，註冊服務器必須忽略Record-Route頭字段。註冊服務器不能在REGISTER 請求的響應中包含Record-Route 頭字段。
註冊服務器可能接收到穿越代理的請求，它認爲REGISTER是未知的請求，並添加Record-Route頭字段值。
註冊服務器必須知道（例如，經過配置）它所保留綁定的域。註冊服務器必須按照其接收的順序處理REGISTER請求。必須可以基本處理REGISTER 請求，意味着具體的REGISTER請求能夠徹底處理，也能夠一點都不處理。必須獨立於其它註冊和綁定改變，處理每一個REGISTER 請求。
當接收到REGISTER請求，註冊服務器遵循如下步驟：
1. 註冊服務器檢查Request-URI，肯定它是否能夠訪問Request-URI指定域的綁定。若是不能，而且，若是服務器也看成代理服務器，那麼，服務器應該遵循第14章介紹的代理消息的通用行爲，將請求轉發給尋址域。
2. 爲了保證註冊服務器支持任何須要的擴展，註冊服務器必須像第5.2.2節介紹的UAS同樣處理Require 頭字段。
3. 註冊服務器應該認證UAC。註冊服務器的行爲絕對不會不考慮SIP通用認證框架。若是認證機制不可用，那麼註冊服務器能夠將From地址做爲請求發起者聲明的身份。
4. 註冊服務器應該肯定，認證用戶是否有權修改記錄地址的註冊。例如，註冊服務器可能查詢受權數據庫——它映射了用戶名和用戶有權修改的一系列記錄地址。若是認證用戶無權修改綁定，註冊服務器必須返回403(Forbidden)，並跳過剩下的步驟。
在支持第三方註冊的架構中，實體能夠負責更新多個記錄地址相關的註冊。
5. 註冊服務器從請求的To頭字段取出記錄地址。若是記錄地址不可用於Request-URI域，那麼註冊服務器發送404(Not Found)響應，並跳過剩下的步驟。URI必須轉換成規範的格式。爲了實現這一點，必須刪除全部的URI 參數（包括user-param），同時將全部的轉義字符串轉換成保留格式。此結果用做一系列綁定的索引。
6. 註冊服務器檢查請求是否包含Contact頭字段。若是沒有，跳到最後一步。若是有Contact頭字段，註冊服務器檢查，Contact頭字段是否包含了特殊值「*」和Expires字段。
若是請求有其餘的Contact頭或者非零的到期時間，那麼，請求是無效的，服務器返回400(Bad Request)響應，並跳過剩下的步驟。若是沒有，註冊服務器檢查，Call-ID是否和每一個綁定的存儲值一致。若是沒有，它必須刪除這些綁定。若是一致，僅在請求的Cseq高於綁定的存儲值時，刪除綁定。不然，必須放棄更新，同時請求失敗。
7. 註冊服務器如今依次處理Contact頭字段的每一個聯繫地址。對於每一個地址，它按照下面的方法肯定逾時間隔：
² 若是字段值有expires參數，此值必須看成請求的到期時間。
² 若是沒有這樣的參數，可是請求有Expires頭字段，此值必須看成請求的到期時間。
² 若是都沒有，本地配置的默認值必須看成請求的到期時間。
註冊服務器能夠選擇小於請求的逾時間隔的到期時間。當且僅當請求的到期時間大於零，而且小於一個小時，同時小於註冊服務器配置的最小值，註冊服務器能夠拒絕註冊，並返回423(Interval Too Brief)響應。此響應必須包含Min-Expires 頭字段——說明註冊服務器想要的最小逾時間隔。而後，它跳過剩下的步驟。
在限制須要保持的狀態和減小可能的註冊停滯的同時，容許註冊服務器設置註冊時間間隔，防止過於頻繁的註冊更新。註冊的逾時間隔頻繁地用於建立服務上。其中一個實例是，follow-me服務，在這裏，終端用戶可能僅在一個很短的週期內可用。所以，註冊服務器應該接受簡短註冊，若是時間間隔很短以致於更新會下降註冊服務器的性能，那麼，應該拒絕該請求。
對於每一個地址，註冊服務器隨後使用URI 比較規則搜索當前的綁定列表。若是綁定不存在，將暫時添加它。若是綁定存在，註冊服務器檢查Call-ID 值。若是現有綁定的Call-ID值與請求中的Call-ID 值不一樣，若是逾時間隔爲零或者有其它更新，必須刪除綁定。若是它們是相同的，那麼註冊服務器比較CSeq 值。若是此值高於現有綁定的值，它必須更新或者刪除綁定。不然，必須放棄更新，同時請求失敗。
此算法確保了忽略相同UA 無序的請求。
每一個綁定記錄記錄了請求的Call-ID 和Cseq 值。
當且僅當，綁定更新和添加成功，必須提交綁定更新（便是使得代理和重定向服務器可見）。若是其中之一失敗了（例如，由於後臺數據庫提交失敗），那麼，請求必須失敗，返回500(Server Internal Error)響應，同時必須刪除全部嘗試的綁定更新。
8. 註冊服務器返回200（OK）響應。響應必須包含列出了全部當前綁定的Contact 頭字段值。每一個Contact 值必須對註冊服務器選擇的、說明其逾時間隔的「expires」參數起做用。此響應應該包含Date 頭字段。
- 7. 查詢（OPTIONS）
SIP方法OPTIONS容許UA 查詢其它UA 和代理服務器的能力。這就容許客戶端沒必要「Ringing」另外一方，發現關於支持的方法、內容類型、擴展和編碼等等的信息。例如，在客戶端將Require 頭字段插入到INVITE 列出的它所不肯定目的UAS 支持的選項時，客戶端能夠使用OPTIONS查詢目的UAS，檢查Supported頭字段是否返回此選項。全部的UA必須支持OPTIONS 方法。
Request-URI肯定OPTIONS請求的目標，它能夠識別其它的UA和SIP服務器。若是OPTIONS尋址到代理服務器，那麼Request-URI設置爲沒有用戶部分，和REGISTER請求的Request-URI 設置同樣。
換言之，服務器接收到Max-Forwards頭字段爲0的OPTIONS請求，可能無論Request-URI而直接響應請求。
此行爲和HTTP/1.1相同。經過發送一系列有遞增Max-Forwards值的OPTIONS請求，此行爲能夠用做「路由跟蹤」功能，檢查單個跳躍點服務器的能力。
做爲通用UA的行爲，若是OPTIONS沒有響應，處理層能夠返回超時錯誤。這能夠說明目標不可到達，所以是無效的。
OPTIONS請求能夠做爲創建對話的一部分發送，查詢在對話中之後可能使用的對等物的能力。
7.1. 構造OPTIONS請求
使用第5.1.1節討論的SIP請求的標準規則來構造OPTIONS請求。
Contact頭字段可能出如今OPTIONS中。
應該包括Accept頭字段，說明在響應中UAC想要接收到的消息體的類型。這主要用來設置一種用於描述UA媒體能力的格式，如SDP（application/sdp）。
OPTIONS請求的響應假定爲是在原始請求Request-URI的範圍內的。然而，僅當OPTIONS做爲創建對話的一部分發送時，它才能保證生成OPTIONS響應的服務器能夠接收到未來的請求。
如下是OPTIONS請求的實例：
OPTIONS sip:carol@chicago.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
Max-Forwards: 70
To: <sip:carol@chicago.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:alice@pc33.atlanta.com>
Accept: application/sdp
Content-Length: 0
7.2. 處理OPTIONS請求
使用第5.2.6 節討論的SIP響應的標準規則來構造OPTIONS響應。選擇的響應代碼必須和INVITE請求已經選擇的同樣。即便，若是準備接受呼叫，返回200 (OK)；若是UAS 忙，返回486（這兒正忙）等等。這容許OPTIONS請求用做肯定UAS 的基本狀態，這能夠是UAS是否接受INVITE 請求的指示。
在對話中接收到OPTIONS請求生成200 (OK)響應，和對話外構造的同樣，對對話沒有任何影響。
由於代理處理OPTIONS和INVITE請求的不一樣，OPTIONS的使用有侷限性。分發的INVITE可能返回多個200(OK)響應，而分發的OPTIONS可能只返回一個200(OK)響應，由於代理使用非INVITE 處理機制處理的。
若是代理服務器生成OPTIONS響應，那麼，代理返回200(OK)，列出服務器的能力。此響應不包括消息體。
Allow、Accept、Accept-Encoding、Accept-Language和Supported頭字段應該出如今OPTIONS請求的200 (OK)響應中。若是代理產生此響應，由於代理不知道方法，Allow是模糊的，因此代理應該忽略Allow頭字段。Contact頭字段可能出如今200 (OK)響應中，並和3xx 響應有相同的語義。便是它們可能列出到達用戶的一系列可選名字和方法。Warning頭字段也可能出現。
消息體可能發送，其類型由OPTIONS請求的Accept頭字段肯定（若是Accept頭字段不存在，默認值爲application/sdp）。若是此類型包括能夠描述媒體能力的類型，那麼，UAS應該爲此目的在響應中包括消息體。在[12]中介紹了在application/sdp狀況下，構造此消息體的詳情。
如下是UAS建立的OPTIONS響應實例(和第11.1 節的請求相對應):
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 ;received=192.0.2.4
To: <sip:carol@chicago.com>;tag=93810874
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:carol@chicago.com>
Contact: <mailto:carol@chicago.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Accept: application/sdp
Accept-Encoding: gzip
Accept-Language: en
Supported: foo
Content-Type: application/sdp
Content-Length: 274
(SDP not shown)
- 8. 對話
一個UA的核心概念就是對話。對話是表現爲兩個用戶代理（UA）之間的持續一段時間的點對點的SIP關係。對話（Dialog）使得用戶代理之間的消息順序傳遞和兩個用戶代理之間的請求正確路由更加容易。對話（Dialog）能夠認爲是對SIP消息解釋的上下文關係。第8節講述了方法無關的UA處理和響應對話（Dialog）外的請求。本節將討論如何經過請求和應答來建立一個對話（Dialog），而且在對話（Dialog）中如何發起和響應後續的請求。
一個對話在參與對話的UA中都有一個dialog ID做爲標記，這個ID由Call-ID，和一個本地tag和遠程tag組成。各個UA的dialog ID在對話中是不同的。特別是，在一邊UA的本地tag，在另一方就是遠程tag。這些tag都是互相不透明的，而且使得整個dialog ID是惟一的。
dialog ID一樣是和全部的To頭域中包含了tag參數的請求及應答相關。
填寫一個消息中的dialog ID的規則依賴於SIP元素是UAC仍是UAS。對於UAC來講，dialog ID中的Call-ID的值會填寫到消息中的Call-ID域中，遠程tag放在消息中的To的tag參數中，本地tag放在From的tag參數中。（這些規則對請求和應答都適用）。對於UAS來講，dialog ID的Call-ID值放在消息的Call-ID頭域中，遠程tag放在From頭域的tag中，本地tag放在To頭域的tag參數中。
一個對話包含一些特定的狀態用於之後的對話中的消息傳送。這個狀態由dialog ID,本地序列號（用來排序UA到對方的請求的序列），遠程序列號（用來排序請求從遠端到本UA）,本地URI,遠端URI,remote target,一個布爾類型的標記」secure」，路由集合（一組有序的URI）組成。
路由集合是由發送請求到對方須要途徑的一組服務器列表組成。一個對話能夠處於」early」狀態，這是因爲當這個對話收到了臨時應答而建立，而且當收到了2xx終結應答的時候轉換到」confirmed」狀態。對於其餘應答，或者沒有應答，」early」對話將會終結。
8.1. 建立一個對話
對話是由對一組特定請求的沒有失敗的應答來建立的。在本規範中，只有包含To tag的2xx和101－199應答，而且請求是INVITE的，會創建一個對話。當收到一個非終結應答的時候，對話會創建成」early」狀態，而且成爲early dailog。建立對話的時候能夠使用Extension來定義擴展。13節描述了INVITE請求的更多細節。在這裏，咱們描述與方法無關的對建立對話狀態的處理。
UA必須按照下邊描述的方法對dialog ID進行賦值。
8.1.1. UAS行爲
當UAS響應一個請求給出一個應答，而且這個應答會創建一個對話的時候（好比對INVITE的2xx應答），UAS必須拷貝全部的請求中的Record-Route頭域到應答中去（包括URI,URI參數，和其餘任何Record-Route頭域的參數，不管UAS是否是認識的參數都須要原樣拷貝），而且必須維持這些參數的順序。UAS必須增長一個Contact頭域給應答。這個Contact頭域包含一個UAS在後續對話請求中接收請求的地址（這個包含了給INVITE請求的2xx應答的ACK請求處理的地址）。一般狀況下，UAS會用IP地址或者FQDN形式來發布本身的這個Contact地址。這個在Contact頭域中的URI必須是一個SIP或者SIPS URI。若是建立對話的請求在Request-URI中包含的是SIPS URI，或者在Record-Route頭域的最上的一個值是SIPS URI,或者若是請求中沒有Record-Route頭域可是請求中的Contact頭域是SIPS URI,那麼給出的應答中的Contact頭域必須是一個SIPS URI。 這個URI應該是全局有效的（就是說，這個URI能夠用於對話外的消息）。一樣的，在請求INVITE中的Contact頭域的URI也不該當僅限於這個對話中使用。所以它能夠用於對話外的消息中。
UAS接着建立這個對話的狀態。對話狀態必須維持直到對話結束。
若是請求是經過TLS過來的，而且Request-URI包含一個SIPS URI,」secure」標誌將被賦值成爲TRUE。
路由集合必須設置成爲請求中的Record-Route的URI列表，保留全部的URI參數和順序。若是請求中沒有Record-Route頭域，那麼路由集合必須設置成爲空。這個路由集合，即使是空的，爲了之後的對話中的請求，也要覆蓋任何預先存在(pre-existing)的路由集合。remote taget必須設置成爲請求的Contact頭域中的URI。
遠程序列號必須設置成爲請求中的Cseq頭域的序列號。本地序列號必須設置成爲空。dialog ID中的呼叫標誌應該設置成爲請求的Call-ID頭域的值。dialog ID的本地tag必須設置成爲對請求的應答包中的To頭域的tag，而且dialog ID的遠程tag必須設置成爲請求中的From 頭域中的tag。UAS必須可以處理接收到的請求中的From頭域沒有tag標誌，在這種狀況下，這個tag就是空值。這是爲了兼容RFC2543協議，它並無定義From tag。
遠程URI（remote URI）必須設置成爲From頭域中的URI，而且本地URI必須設置成爲TO頭域中的URI。
8.1.2. UAC行爲
當一個UAC發出一個請求，這個請求可以創建一個對話（好比這個請求是INVITE），它必須在Contact頭域中提供一個基於全局的SIP或者SIPS URI（例如，能夠在對話外使用的SIP URI）。若是請求包含一個Request-URI或者最上的Route頭域是SIPS URI,Contact頭域也必須包含的是SIPS URI。
當一個UAC接收到應答，而且這個應答創建對話的時候，它也一樣構造這個對話的狀態。這個狀態必須維持到對話的結束。
若是這個請求是基於TLS發送的，而且Request-URI包含一個SIPS URI,那麼」secure」標誌被設置成爲TRUE。
路由集合必須設置成爲應答中的Record-Route頭域的URI列表，保留全部的URI參數和順序。若是在應答中沒有Record-Route頭域，那麼這個路由集合必須設置成爲空集合。這個路由集合即使是空的，爲了之後的對話中的請求，也要覆蓋任何預先存在(pre-existing)的路由集合。remote taget必須設置成爲應答中的Contact頭域的URI。
本地序列號必須設置成爲請求中的Cseq頭域的序列號。遠程序列號必須設置成爲空（他會由遠端的UA在對話中發送請求而創建）。dialog ID中的呼叫標誌必須設置成爲請求的Call-ID頭域的值。dialog ID的本地tag必須設置成爲請求中的From頭域的tag，dialog ID的遠程tag必須設置成爲應答中的To頭域的tag。UAC必須可以處理接收到的應答的To頭域中沒有tag的狀況，在這個狀況下，tag值取值成爲空。這是爲了可以向下兼容RFC2543，它沒有規定To的tag。
remote URI必須設置成爲To頭域的URI，local URI必須設置成爲From頭域的URI。
8.2. 對話中的請求
當兩個UA之間的對話創建之後，他們均可以在對話中初始化一個新的事務（transaction）。若是UA發送請求，將遵循UAC的事務規則。UA接收請求將遵循UAS的規則。在創建對話的事務過程當中，UA扮演的角色多是不同的。
在對話中的請求能夠包含Record-Route和Contact頭域。不過，雖然他們會修改remote target的URI，可是這些請求也不會致使對話的路由集被改變。明確說，若是請求不是刷新target的請求，那麼這個請求不會更改對話的remote target URI,若是請求是刷新target的請求，那麼這個請求才會更改對話的remote target URI。對於用INVITE創建的對話來講，惟一的可以刷新target的請求就是re-INVITE(見14節說明)。可能會有其餘擴展定義經過其餘方法來刷新target的請求。
注意ACK不是一個刷新target的請求。
刷新target請求只會更改對話的remote target URI，而且更改由Record-Route指定的路由集合。若是更新路由集合會帶來嚴重的和RFC2543向後兼容問題。
8.2.1. UAC行爲
8.2.1.1. 產生請求
在對話中的請求是經過用許多對話的狀態部分來構造的。在TO頭域中的URI部分必須設置成爲對話狀態中的remote URI。To頭域的tag參數必須設置成爲dialog ID中的remote tag部分。請求的From URI必須設置成爲對話狀態中的local URI。From頭域的tag參數必須設置成爲dialog ID的local tag部分。若是remote或者local tag是空值，那麼tag參數必須分別從From或者To頭域中去除。
在請求序列中的原始請求的To和From頭域的URI的使用方法是爲了向下兼容RFC2543協議的，在RFC2543協議中，使用URI做爲對話的標誌。在這個規範中，只有tags用於區分對話。有可能在本協議的後續版本中，在對話中的請求必須強制反應原始請求的To和From頭域的URI將會去除。
請求的Call-ID必須設置成爲對話的Call-ID。在對話中的請求必須嚴格遵循單個遞增的Cseq序列號（每次增長1）（固然要除了ACK和CANCEL，這兩個請求中的Cseq必須和原始的請求或者確認請求同樣）。所以，若是本地序列號（local sequence number）不爲空，那麼本地序列號碼必須依次增長1，而且這個數值要存放到Cseq頭域中。若是本地序列號碼是空的，那麼在8.1.1.5節約定的初始值必須填寫進去。在Cseq頭域中的method字段必須和請求的方法（method）一致。
經過使用32位的長整數，使得即便每秒種產生1筆請求，也會要136年纔會用完這個整數出現重複。這個序列號的初始值的選取是爲了讓對話中後續的請求序列號不會重複。非0的初始值能夠考慮採用時間來做爲初始的序列號。一個客戶端能夠用31位有符號整數或者32位無符號整數來存放時間做爲初始化的序列號。
UAC使用remote target和路由集合來構造請求中的Request-URI和Route頭域。若是路由集合是空的，那麼UAC必須把remote target URI放到Request-URI中，而且UAC不能添加Route頭域到請求中。
若是路由集合不爲空，而且路由集合的第一個URI包含lr參數（見19.1.1），那麼UAC必須填寫remote target URI到Request-URI，而且必須包含Route頭域，這個Route頭域按照順序填寫路由集合和路由集合的參數。
若是路由集合不爲空，而且路由集合的第一個URI沒有包含lr參數，那麼UAC必須把第一個URI放在Request-URI中，而且拆去全部不被Request-URI容許的參數。UAC必須增長一個Route頭域順序包含全部剩下的路由集合元素，及其參數。UAC接着必須把remote target URI放在Route頭域的最後一項。
例如，若是remote targe是: sip:user@remoteua 而且路由集合包括：
<sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>
那麼請求應該有下列的Request-URI和Route頭域
METHOD sip:proxy1
Route: <sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua>
若是路由集合的第一個URI不包含lr參數，那麼對應的說明proxy並不能支持本文檔所約定的路由機制，而是支持RFC2543文檔所約定的路由機制，那麼在發送信息的時候須要經過替換Request-URI爲接收到的第一個Route頭域的值。將Request-URI的值放在Route頭域的目的是爲了保護Request－URI，使得它通過嚴格路由的時候不丟失（當請求遇到一個鬆散路由的時候會返回到Request-URI中？？？？？。）
在對話內的任何一個刷新target的請求中，都應當包含一個Contact頭域，而且這個URI除非有必要，不然都應當是和對話內上次請求的URI值同樣。若是」secure」標誌設置成爲TRUE,那麼URI也應當是SIPS URI。
若是在12.2.2節討論的那樣，在刷新target請求中的Contact頭域會更新remote target URI。這個容許UA提供一個新的聯繫地址（Contact address），代表它在對話中改變了本身的地址。不過，若是請求不是刷新target的請求，那麼不會影響對話中的remote target URI。請求中的剩下的部分請按照8.1.1節描述的填寫。一旦請求被建立了，請求將按照對話外請求發送標準步驟（8.1.2節）來解析服務器的地址而且發送請求。
8.1.2節中的步驟通常把請求發送到Route頭域的最上一個地址，或者若是沒有Route頭域，那麼就發送到Request-URI地址。因爲受到特定的限制，這些步驟也容許把請求發送到另一個地址（好比在route set中沒有的缺省的外發proxy）
8.2.1.2. 處理應答
UAC將會從transaction層收到請求的應答。若是客戶端的事務層返回一個超時，這會等同於一個408(請求超時)的應答。UAC處理3xx應答的時候，在這個應答是在對話內的請求的應答的處理方法和在對話外的處理方法是同樣的。這個方法在8.1.3.4節中描述。須要注意的是，雖然UAC會嘗試新的地址（處理3xx應答的時候），可是它依舊使用對話內的路由集合來構造請求的Route頭域。
當UAC收到一個刷新target請求的2xx應答的時候，若是對話的remote target URI存在，那麼它必須用這個應答的Contact頭域的值來替換對話的remote target URI。
若是對話那的請求的應答是481應答（呼叫/事務不存在Call/Transaction Does Not Exits）或者一個408（請求超時），那麼UAC應當終止這個對話。而且UAC應當在請求徹底沒有應答的時候（客戶端transaciton將會通知TU這個超時）客戶端transaction終止這個對話。
對於INVITE初始化的對話，終止對話須要發送一個BYE。
8.2.2. UAS行爲
在對話中發送的請求，就像其餘請求同樣，是原子請求。若是UAS收到某個請求，全部的相關狀態要麼一塊兒改變，要麼就一塊兒不變。在某些請求中，請求會影響好幾個狀態（好比INVITE請求）。
UAS從transaction層收到請求。若是請求的To頭域有tag字段，UAS的處理核心須要校驗對話的ID，拿請求中的tag和現存的對話相比較。若是匹配成功，那麼就是一個在對話中的請求。在這種狀況下，UAS首先使用8.2節中的對話外請求處理的步驟。若是請求To頭域包括了一個tag字段，可是對話的ID並不匹配現存的對話，UAS多是由於崩潰而從新啓動，或者收到了一個另外（多是錯誤的）UAS(UAS能夠構造To的tags，這樣UAS在災備恢復下，能夠把這個tag當作它本身的)。還有一種簡單的多是請求發送錯誤了。在這個基礎上，UAS能夠選擇接受或者拒絕請求。在容許的狀況下，儘可能處理這些請求會提供災難恢復的機制。UAS若是但願支持這樣的特性就必須遵循一些原則，好比用始終使用單調遞增的Cseq序列號，甚至是在從新啓動以後也這樣，在重啓動後重建路由集合，處理越界的RTP時間戳和序列號等等。
若是UAS因爲不但願重構對話而拒絕這個請求，它必須應答對方一個481（呼叫/事務不存在。Call / Transaction不存在）應答。
對於在對話中接收到的，那些不會用任何形式更改對話狀態的請求，好比OPTIONS請求，他們等同於在對話外的處理請求。
若是遠端的序列號（remote sequence number）是空的，它必須設置成爲請求中的Cseq頭域的序列號（sequence number）。若是remote sequence number不是空的，可是請求中的sequence number小於這個remote sequence number,請求就是非順序的，而且必須經過應答500（服務器內部錯誤）打回去。若是remote sequence number不是空的，而且請求中的序列號大於這個remote sequence number,請求就是按照順序的。這個請求中的Cseq的序列號能夠比remote sequence number大不止1。在這種狀況下，並不是是錯誤的，而且UAS應當準備接收和處理比上次處理的請求Cseq值大於1 的請求。UAS必須設置remote sequence number成爲請求中的Cseq頭域中的序列號。
若是一個proxy廢棄掉一個UAC產生的請求，而且UAC從新遞交這個請求的時候。這個請求是會具備一個全新的Cseq序列號。UAS是不會收到第一個請求的，這樣，Cseq序列號就會出現間隔，這樣的間隔並不是是一種錯誤的狀況。
當UAS接收到一個target刷新請求的時候，若是請求中存在Contact頭域，它必須用Contact頭域中的URI來替換對話的remote target URI。
8.3. 終止對話
在創建對話中的終結對話，跟請求方法無關，若是對話外的請求產生了一個非2xx終結應答，任何前邊請求建立的」早期對話」(early dialogs)將會終止。在已經創建的對話中，終結對話就是請求方法相關的。在這個定義中，BYE方法將會終結一個對話。15節有細緻的討論。
- 9. 初始化一個會話（INVITE）
當UAC但願初始化一個會話（好比，audio,video或者遊戲），它首先構造一個INVITE請求。這個INVITE請求一個服務器來創建一個會話。這個請求可能會由proxy層層轉發，最後到達一個或者多個可能可以處理這個邀請的UAS。這些UAS須要看看是否用戶接收這個邀請。而後UAS能夠接收這個請求（也就是會話創建了），經過發送2xx應答。若是邀請被拒絕，根據拒絕的緣由，3xx，4xx，5xx或者6xx應答將會發送。在發送終結應答以前，UAS能夠發送一些臨時應答（1xx）應答給UAC，以便UAC可以掌握創建會話的進度。
當收到了一個或者多個臨時應答，UAC可能收到一個或者多個2xx應答或者一個非2xx終結應答。因爲在INVITE終結應答以前，可能有很多時間，在INVITE事務的可靠性機制和其餘的請求不一樣（好比OPTIONS）。當UAC收到了終結應答，UAC須要給每個INVITE的終結應答，發送一個ACK請求。發送ACK請求的步驟依賴於應答的類別。對於在300到699的終結應答，ACK是在transaction層處理的，而且遵循一系列規則（17節）。對於2xx應答，ACK是由UAC處理核心產生的。
INVITE的一個2xx應答會創建一個會話，同時也創建了一個基於發送INVITE請求的UA和產生2xx應答的UA之間的對話。所以，當從多個遠程UA收到了多個2xx應答（可能因爲INVITE的分支），每個2xx創建一個不一樣的對話（dialog）。全部這些對話都是同一個呼叫的組成部分。
本節介紹了INVITE請求創建會話的詳細過程。支持INVITE的UA也必定同時支持ACK,CANCEL和BYE。
9.1. UAC處理
9.1.1. 建立一個初始化的INVITE
因爲初始化的INVITE請求是一個對話外的請求，它遵循8.1.1節的步驟建立。除此以外還有專門針對INVITE的附加處理步驟。
在INVITE中應當包括一個Allow頭域（20.5節）。它用來標誌在這個INVITE創建的這個對話（dialog）中什麼樣的方法能夠接受。好比，一個UA能夠在對話中接收和處理INFO請求[34]，那麼在INVITE請求的Allow頭域中應當列出這個INFO方法。在INVITE請求中，Supported頭域應當包含。這個頭域包含了全部這個UAC支持的擴展部分。
在INVITE中能夠包含一個Accept頭域（20.1節）。這個標誌了UA在後續創建的對話中，能兼容的接收和發送的Content-Type。Accept頭域支持不一樣會話描述格式（session descrioption format）的時候特別有用。
UAC能夠經過包含一個Expire頭域(20.19節)來限制邀請的有效期限。若是Expire頭域的時間到了尚未接收到INVITE的終結應答，UAC處理核心應當像9節描述的那樣產生一個對INVITE請求的CANCEL請求，
UAC還能夠根據須要增長Subject(20.36節)，Organization(20.25節)和User-Agent(20.41節)頭域。這些頭域都包含了INVITE的相關資料。UAC能夠給INVITE增長一個消息體。8.1.1.10節講述瞭如何構造Content-Type頭域來描述消息體。
對於消息體，有一些特別的規定――他們是基於某種磋商機制的，他們對應的Content-Disposition 是」session」(會話的)。SIP使用一個請求/應答模型，UA發出一個會話描述，稱做是請求，裏邊包含了會話的描述。這個請求標誌了特定的聯繫內涵（好比audio，vidio，game），這些內涵的參數（好比解碼器等等），而且從應答方接收媒體信息的地址。對方UA會迴應另一個會話的描述，稱之爲應答，標誌了能接受的聯繫內涵，這些內涵的參數。這個請求/應答的交換實在對話的上下文進行中的，因此若是一個SIP INVITE請求致使了多個對話，每個對話都包含本身獨立的請求/應答的交換。請求/應答模型定義了對於請求和應答的限制。（好比在上一個請求還沒有處理完成狀況下不能發起下一個請求）。這也致使了請求/應答在SIP消息中出現的位置限制。在這個規範中，請求和應答只能出如今INVITE、ACK請求和其應答中。請求和應答的使用中更進一步被限制。在初始化一個INVITE事務中，規則以下：
o 初始化請求必須在INVITE中，若是不在INVITE請求中，就必須在UAS回送給UAC的第一個非失敗的可靠消息中。在這個規範中，這個應答就是2xx應答。
o 若是初始的請求是一個INVITE，那麼應答必須是由UAS發送回給對應發出INVITE請求的UAC的可靠的非失敗的消息。在本規範中，只有2xx應答對應這個INVITE請求。一樣相同的應答可能在以前發送的零食應答中存在。UAC必須把它接收到的第一個會話描述看成是應答，而且必須忽略任何在初始INVITE請求中後續的會話描述應答描述。
o 若是初始請求是在第一個可靠的非失敗的UAS回送給UAC的消息中，那麼應答必須在這個消息的確認消息中（在本規範中，就是給2xx應答的ACK確認消息）
o 在發送或者接收到第一個請求的應答以後，UAC能夠一樣依據這樣的問答方法產生後續的請求。可是隻能在收到每個請求的應答以後才能發起下一個請求。不能在上一個請求還沒有收到應答的時候發起下一個請求。
o 當UAS發送或者接收到初始化的請求的時候，禁止在它給初始的INVITE請求的應答中產生後續的請求（協商會話描述請求）。這就意味着基於本規範的UAS在完成初始化的事務以前，不會產生任何會話描述請求。
具體來講，根據本規範，上邊的規則分別定義了兩種UA之間交換信息的方法。請求實在INVITE中，應答是在2xx（可能在1xx中也存在，具有相同的值）中，或者請求在2xx中，應答在ACK中。（這個意思是說，兩個UA之間創建鏈接的時候，首先須要協商一下兩個UA可以支持的消息體正文，那麼這個協商關係也是經過問答形式的，也就是經過請求/應答的，這個媒體磋商的請求既能夠在UAC發起的INVITE請求中，也能夠在UAS迴應的2xx應答中。一樣的，媒體磋商的應答既能夠在UAS的2xx應答或者1xx應答中，也能夠在ACK確認請求中）。全部的支持INVITE請求的UA都必須支持兩種交換方式。會話描述協議（session description protocol sdp）(RFC 2327[1])在全部的UA中都必須獲得支持，而且它的用法和請求/應答的構造必須遵循[13]中定義的步驟。
在上邊講述的請求/應答模型中，只能適用於在包頭域Content-Disposition中的值是」session」的包體狀況。所以，有可能會INVITE和ACK請求中都包含一個包體信息（好比，INVITE包含一個相片（Content-Disposition:render）而且ACK包含一個會話描述(Content-Disposition:session)）。
若是Content-Disposition頭域不存在，Content-Type 是application/sdp的包體實現就等同於Content-Disposition」session」，其餘Content-Type的狀況就是實現」render」。
當INVITE請求建立之後，UAC遵循對話外請求發送的步驟進行發送（8節）。這也就是建立一個客戶事務而且由這個客戶事務發送請求而且處理應答。
9.1.2. 處理INVITE應答
當INVITE請求被傳送給INVITE的客戶事務層進行處理，UAS等待INVITE的應答。若是INVITE客戶事務層返回一個超時而不是收到一個應答，那麼這個TU就應當像收到一個408（請求超時）應答（8.1.3節）那樣進行處理。
9.1.2.1. 1xx應答
有可能在收到一個或者多個終結應答以前，UAC會收到0個或者1個或者多個臨時應答。INVITE的臨時應答會創建」early dialogs」（早期對話）。若是一個臨時應答在To頭域中有一個tag子頓，而且應答的dialog ID並非已經存在的對話的ID，那麼就應當遵循12.1.2節定義的步驟建立一個對話（早期對話）。
early dialog只會在下邊這個狀況中須要：若是一個UAC須要在完成初始的INVITE事務以前，給對方發送一個對話內的請求的時候，就須要early dialog。在臨時應答中的頭域能夠在當對話是early state的時候都有效（也就是說，好比一個臨時應答的Allow 頭域包含的方法，在對話狀態是early state的時候都是有效的。[因爲Allow是容許的方法集合，因此，當對話狀態是早期對話的時候，這個Allow的集合是不會改變的，可是當建立正式的dialog以後，Allow的集合可能會改變哦]。）
9.1.2.2. 3xx應答
一個3xx應答可能包含一個或者多個Contact頭域值，這個頭域值提供了被叫方可能存在的地點。UAC能夠根據3xx應答的狀態碼（21.3節）來決定是否嘗試這些新的地址。
9.1.2.3. 4xx,5xx,6xx應答
在INVITE請求中，可能會收到單個非2xx終結應答。4xx，5xx，6xx應答若是包含了Contact頭域，那麼這個頭域值指示了錯誤的詳細信息的解釋地點。後續的終結應答（只有可能在發生錯誤的狀況下），必須被忽略掉。
全部的早期對話都會因爲接收到非2xx終結應答而結束。
一旦接收到了非2xx終結應答，UAC處理核心就認爲INVITE事務結束了。INVITE客戶事務處理生成對這個應答的ACK（參見17節）。
9.1.2.4. 2xx 應答
單個INVITE請求可能會致使多個2xx應答返回給UAC，這是由於proxy能夠分支。每個應答都是由To中的tag參數來進行區分的，而且每個應答都表明了一個獨立的對話，具有單獨的對話ID。
若是在2xx應答中的對話ID和一個現存的對話匹配，那麼這個對話必須切換到」confirmed」狀態，而且對話的路由集合必須基於2xx的應答進行從新計算（參見12.2.1.2）。若是不匹配，那麼必須建立一個新的對話，這個對話具有」confirmed」狀態，參見12.1.2的步驟進行建立。
注意在對話狀態中，只有路由集合不須要從新計算。其餘部分好比對話內的最大的序列號（遠程的和本地的）等都不須要從新計算。路由集合只是因爲須要向後兼容而須要從新計算。RFC 2543並無要求在1xx應答中反射Record-Route頭域回來，只在2xx請求中要求了。咱們不能更新對話狀態的所有部分，由於在早期對話（early dialog）中可能會存在對話中的請求，好比更改序列號等等。UAC核心必須爲每個2xx應答，產生一個ACK請求。除了在Cseq和身份認證相關的頭域以外，ACK請求的頭域的建立和在對話中的請求建立的方法同樣（12節）。Cseq頭域的序列號部分必須和須要確認的INVITE請求同樣，可是Cseq的方法部分必須是ACK。ACK必須包含和INVITE請求相同的信任狀。若是2xx包含一個媒體磋商請求（基於上述的規則），ACK必須在包體中包含一個媒體磋商應答。若是2xx應答的媒體磋商請求不能被接收，UAC核心必須產生一個有合法的應答ACK，而且馬上發送一個BYE請求。
當ACK建立之後，[附件4]中規定的步驟用來檢測對方地址，端口和transport。這個請求是直接交給通信層進行通信的，而不是交給一個客戶事務層進行發送。這是因爲UAC核心直接處理ACK的重發，而不是事務層進行重發的處理。每次收到一個重發的2xx終結應答的時候都必須發送一個ACK到通信層。
UAC核心認爲INVITE事務在接收到第一個2xx應答後的64×T1秒後完成。在這個時間點後，全部沒有轉換成爲創建鏈接狀態的早期對話都會被終止。一旦UAC確認INVITE事務完成了，那麼缺省認爲不會收到新的2xx應答了。若是，在相應了對INVITE請求的所有應答以後，UAC並不但願建立這個對話，那麼UAC必須經過15節描述的那樣發送BYE請求來結束對話。
9.2. UAS處理
9.2.1. 處理INVITE
UAS核心從事務層收到INVITE請求。首先根據8.2節定義的步驟進行處理請求，8.2節中定義的是跟對話內外無關的請求的處理。若是處理順利完成（沒有產生應答），UAS核心根據以下步驟進行額外處理：
一、 若是INVITE請求包含一個Expires頭域，UAS核心就設置一個時鐘計數＝這個頭域值。若是時鐘到了，這個邀請就過時了。若是在UAS還沒有產生終結應答的時候就超時了，那麼487（請求終止）應答應當產生給UAC。
二、 若是請求是一個對話中的請求，12.2.2節定義的方法無關的處理步驟將首先進行處理。這個處理可能會影響到會話；14節講述了細節。
三、 若是請求的To頭域包含了一個tag，可是對話的ID與現存的任何一個對話都不匹配，那麼UAS多是因爲崩潰而從新啓動的，或者是因爲接收到了本應當發送給另一個UAS的請求（或者就簡單是因爲請求填寫錯誤）。12.2.2節提供了這種狀況的處理指引。從這開始的處理將假定這個INVITE是在對話外的，而且INVITE請求的目的是創建一個新的會話。INVITE請求可能包含一個會話描述，在這種狀況下是但願和UAS進行會話媒體的磋商。即便INVITE請求是對話外發出的，這個INVITE參與的用戶也有可能正是那個會話中的參與方。這個是因爲在多方會議中，某個正在會議中的用戶，被其餘參與方邀請參加。若是須要鑑別這樣的狀況，UAS能夠使用會話描述來檢查是否重複邀請。好比，SDP包含了會話的ID和版本號。若是這個用戶自己就是會話中的一方，而且session參數包含的會話描述沒有改變，UAS可能就悄悄接受這個邀請（就是說，在不提示用戶的狀況下發送2xx應答）。
若是INVITE並無包含某個會話描述（session description），UAS就是被邀請建立一個會話，而且UAC已經但願UAS來提供這個會話offer。UAS必須在它的給UAC的第一個非失敗的可靠消息中提供這個offer。在本規範中，給INVITE請求的2xx應答中就應當提供這個offer。
UAS能夠提示進度，接受，轉發，或者拒絕這個邀請。在這些狀況下，它經過按照8.2.6節描述的步驟創建應答。
9.2.1.1. 提示進度
若是UAS不能立刻接受或者拒絕邀請，那麼它能夠提示某種形式的進度給UAC（好比提示一個回鈴聲等等）。這是經過一個101到199的臨時應答實現的。這些臨時應答創建了早期對話（early dialog）（經過8.2.6和12.1.1）。若是UAS願意，UAS能夠發送多個臨時應答。每個臨時應答都必須包含相同的dialog ID。這些臨時應答都並不是可靠傳送的。
若是UAS打算延長一點時間來響應這個INVITE請求，它須要請求一個」extension」來防止proxy來取消這個事務。proxy有權利來取消超過3分鐘未完成的事務。要防止這個取消，UAS必須每分鐘發送一個非100臨時應答，防止因爲1xx臨時應答的非可靠傳輸致使的臨時應答丟失。
若是呼叫出於等待狀態（好比用戶設置成爲呼叫等待的）或者這個呼叫正在和PSTN電話系統進行通信（PSTN系統容許呼叫沒有應答），一個INVITE事務是能夠被延長處理時間的。
9.2.1.2. INVITE請求轉發
若是UAS決定轉發這個呼叫，就須要發出3xx的應答。300（多重選擇），301（永久轉移），302（臨時轉移）應答中應當包含一個Contact頭域，這個頭域包含了一個或者多個代表須要重試的URI新地址。這個應答交給INVITE服務端事務層，由服務端事務層負責應答的重發。
9.2.1.3. INVITE請求的拒絕
拒絕INVITE請求的常見情景是被叫方不想或者不能在終端系統上接收這個呼叫。486（用戶忙）應當在這樣的狀況下返回。若是UAS知道沒有其餘終端系統可以響應這個呼叫，就應當返回一個600（Busy Everywhere）。不過，一般狀況下UAS是不太會知道這個狀況的，而且這個應答也是罕見的。這些應答是交給INVITE服務端的事務層進行發送的，由這個事務層來保證應答的重發機制的。若是UAS拒絕的是INVITE請求包含的媒體磋商offer，UAS應當返回一個488（Not Acceptable Here）應答。這個應答應當包含一個Warning頭域來解釋爲什麼offer被拒絕。
9.2.1.4. 接受INVITE請求
UAS核心產生一個2xx應答。這個應答創建一個對話，而後遵循8.2.6節和12.1.1節的描述進行處理。
響應INVITE請求的2xx應答包含Allow頭域和Supported頭域，而且可能包含Accept頭域。包含這些頭域的目的是爲了讓UAC不須要再次請求就可以知道UAS的特性以及UAS的擴展支持。
若是INVITE請求包含了一個媒體磋商請求offer，而且UAS尚未發送應答，2xx應答中必須包含針對這個offer的應答。若是INVITE請求沒有包含這個offer，並且UAS也還沒有發出offer，2xx應答必須包含這個媒體磋商offer。
當應答構建好了之後，它會交給INVITE的服務端事務層進行發送。注意，INVITE的服務端事務將會因爲收到這個終結應答而且交給通信層進行發送而銷燬。所以，有必要在沒有收到ACK的時候，每隔必定的時間就直接交給通信層進行發送。2xx交給通信層進行發送的時間間隔是從T1秒開始，而且每次發送後就加倍，直到到達T2秒的時間間隔（T1和T2的時間間隔定義在17節）。當收到了針對這個應答的ACK請求以後，重發就終止了。這個是與使用什麼通信協議來發送這個應答是無關的。
因爲2xx的重發是端到端的，而且在UAS和UAC之間存在採用UDP通信的節點。因此要保證經過這些節點進行可靠的傳送，就必須採用間隔時間重發的機制，哪怕UAS自己的通信機制是可靠的。
若是服務端的對2xx應答的重發通過了64×T1秒尚未收到ACK請求，那麼dialog就認爲是confirmed，可是會話卻應當終止。這個是用過15節描述的方法發送BYE請求來結束。
10. 更新已經存在的會話（UPDATE）
成功的INVITE請求同時創建兩個用戶代理之間的對話和呼叫-應答模式的會話。第8章說明了怎樣使用目標更新請求修改現有的對話（如，修改對話的遠程目標URI）。本章介紹了怎樣修改當前會話。此修改包括，修改地址或端口、添加媒體流、刪除媒體流等等。經過在創建會話的相同對話中發送新的INVITE來完成。在現有對話中發送INVITE是re-INVITE。
注意，單個的re-INVITE能夠同時修改對話和會話的參數。
呼叫者和被呼叫者均可以修改現有的會話。
UA檢測媒體錯誤的行爲是本地策略的事情。可是，當網絡擁塞時，爲了不大量的網絡流量，不推薦自動生成re-INVITE和BYE。在任何請狀況中，若是要自動發送這些消息，應該在隨機的間隔後發送這些消息。
注意，上面的章節說起了自動生成re-INVITE和BYE。若是用戶由於媒體錯誤而掛斷，那麼，UA 應該和日常同樣發送BYE 請求。
10.1. UAC行爲
在INVITEs中用於會話描述的呼叫-應答模式也一樣適用於re-INVITE。例如，想要添加媒體流的UAC，將建立包含此媒體流的新呼叫，並在INVITE請求中將其發送給其對等物。重點要指出的是，要發送會話的所有描述，而不只僅是改變。這支持在不一樣元素中的無狀態處理，也支持自動恢復能力。固然，UAC 能夠發送無狀態描述的re-INVITE，在這種狀況中，re-INVITE的第一個可信非錯誤的響應將包含呼叫（在本規範中，便是2xx響應）。
若是會話描述格式有版本號，那麼，呼叫應該指出已經改變了會話描述的版本。
按照第8 章介紹的，遵循與在現有對話內的規則請求相同的方法，設置re-INVITE 的To、From、Call-ID、Cseq和Request-URI。
由於，UAS通常不會警告用戶接受re-INVITE，UAC能夠選擇不爲re-INVITE添加Alert-Info頭字段和Content-Disposition「Alert」消息體。
不像INVITE能夠分發，re-INVITE不會分發，所以，它僅能產生單一的最終響應。re-INVITE 不會分發的緣由是，Request-URI肯定了目標是和它創建對話的UA，而不是肯定用戶的記錄地址。
注意，當正在任一方向進行其它的INVITE事務時，UAC不能在對話內發起新的INVITE事務。
1．若是有正在進行的INVITE客戶端事務，那麼TU必須等到事務完成或結束狀態，才能夠發起新的INVITE。
2．若是有正在進行的INVITE服務器事務，那麼TU必須等到事務完成或結束狀態，才能夠發起新的INVITE。
然而，當INVITE事務正在處理時，UA能夠發起普通的事務。當普通的事務正在處理時，UA能夠發起INVITE事務。
若是UA 接收到re-INVITE的非2xx最終響應，那麼，將像沒有發佈re-INVITE同樣，
不改變會話參數。注意，若是非200 最終響應是481（呼叫/事務不存在）或者408（請求超時），或者請求根本沒有接收到re-INVITE 的響應（便是INVITE 客戶端事務返回超時），那麼，UA將結束對話。
若是UAC接收到re-INVITE的491響應，那麼，它應該啓動有T值的計時器，T選擇以下：
² 若是對話ID有本身的Call-ID（指它生成的值），那麼，T是以10ms爲單位、在2.1到4 秒內隨機選擇的值。
² 若是對話ID沒有本身的Call-ID，那麼，T是以10ms 爲單位、在0到2秒內隨機選擇的值。
當計時器溢出，若是它仍然要修改會話狀態，那麼，UAC 應該再次嘗試re-INVITE。例如，若是呼叫已經用BYE 掛斷，那麼將不能出現re-INVITE。
發送re-INVITE和爲re-INVITE的2xx響應生成ACK的規則和初始INVITE的規則相同。
10.2. UAS行爲
UAS在發送第一個INVITE的最終響應以前，接收到相同會話的、低Cseq序列號的第二個INVITE，UAS必須對第二個INVITE返回500響應（服務器內部錯誤），而且必須包括在0到10秒之間隨機選擇值的Retry-After 頭字段。
UAS正在處理會話已經發送的INVITE時，接收到INVITE，它必須給接收到的INVITE返回491響應（請求待處理）。
若是UA接收到現有對話的re-INVITE，它必須檢查會話描述的版本標識符，若是沒有版本標識符，認爲會話描述的內容已經改變。
若是會話描述已經改變，那麼，可能在要求用戶確認後，UAS 必須調整會話參數。
會話描述的版本能夠用來調節新到達會議的能力——添加刪除媒體、從單點到多播會議。
若是不能接受新會話描述，UAS能夠經過對re-INVITE返回488響應（在此不能接受）拒絕它。此響應應該包含Warning 頭字段。
若是UAS生成2xx響應，但不能接受ACK，那麼，它應該生成BYE結束會話。
由於，UAC通常不將此信息返回給用戶，UAS能夠選擇不爲re-INVITE生成180（響鈴）響應。由於此緣由，在響應re-INVITE 時，UAS能夠選擇不使用Alert-Info頭字段和Content-Disposition「Alert」消息體。
在2xx中提供呼叫（由於INVITE不包含呼叫）的UAS應該服從發送呼叫更新現有會話的約束，創建呼叫，就像UAS正在作出新的呼叫。特別的是，此方法應該包括UA願意支持的媒體格式和媒體類型。UAS必須確保會話描述與UAS先前的會話描述在對等物須要支持的媒體格式、傳輸和其它參數等方面重疊。這就避免了對等物拒絕會話描述。若是UAC不能接受它，UAC應該生成帶有有效會話描述的響應，而後發送BYE，結束會話。
11. 結束會話（BYE）
會話的狀態和對話的狀態是緊密相關的。當用INVITE發起會話時，不一樣UAS產生的1xx和2xx響應都建立對話，若是此響應完成呼叫/應答交換，那麼，它也建立會話。結果，每一個會話都與建立它的對話相關聯。若是初始的INVITE生成非2xx最終響應，那麼，它將結束經過此請求的響應建立的全部會話（若是有）和對話（若是有）。因爲完成了事務，非2xx最終響應也防止了INVITE建立更深層次的會話做爲INVITE的結果。BYE請求用來結束具體的會話和還沒有創建的會話。在這種狀況中，具體的會話和對話是一個UA與對話中另外一個對等UA創建的。當在對話中接收到BYE，應該結束和此對話相關的全部會話。UA不能在對話外發送BYE。呼叫者UA能夠在確認的和早期的對話中發送BYE；被呼叫者UA 能夠在確認的對話中發送BYE，可是不能在早期的對話中發送BYE。然而，在被呼叫者UA接收到其2xx響應的ACK和服務器事務超時以前，它不能在確認的對話中發送BYE。若是在此對話相關的應用層狀態中沒有定義SIP擴展，那麼，BYE也能夠結束對話。
對話和會話中INVITE的非2xx最終響應的效果是使用CANCEL attractive。CANCEL嘗試將非2xx最終響應強制發送給INVITE（特別是，487）。所以，若是UAC但願徹底放棄其呼叫嘗試，它發送CANCEL。若是INVITE致使了INVITE的2xx最終響應，這意味着正在處理CANCEL時，UAS接受了此邀請。UAC能夠繼續2xx響應創建的會話，也能夠使用BYE 結束會話。
在SIP中，沒有很好的定義「掛斷」的概念。掛斷是很具體的細節，可是也是很通用的用戶接口。通常，當用戶掛斷，它表示想要結束創建會話的嘗試和結束已經建立的會話。對於呼叫者UA，若是初始的INVITE沒有建立最終響應，那麼掛斷意味着CANCEL請求；對於在最終響應後全部確認的對話，掛斷意味着BYE。對於被呼叫者UA，通常來講，掛斷意味着BYE。
多是，當用戶拿起電話，生成2xx，在接收到ACK後，掛斷可能會致使BYE。這並非指，用戶在接收到ACK前不能掛斷電話，僅僅是指，爲了正確的清除，用戶電話的軟件須要在一小段時間維持狀態。若是特定的UI 容許用戶在其應答以前拒絕呼叫，403(Forbidden)是一個很好的表示方式。按上面的規則，能夠發送BYE。
| Item |
Headerfield |
Sending |
Receiving |
||||
| Ref. |
RFCstatus |
Profilestatus |
Ref. |
RFCstatus |
Profilestatus |
||
| 1 |
Accept |
[26]20.1 |
o |
o |
[26]20.1 |
m |
m |
| 1A |
Accept-Contact |
[56B]9.2 |
c18 |
c18 |
[56B]9.2 |
c22 |
c22 |
| 2 |
Accept-Encoding |
[26]20.2 |
o |
o |
[26]20.2 |
m |
m |
| 3 |
Accept-Language |
[26]20.3 |
o |
o |
[26]20.3 |
m |
m |
| 3A |
Allow |
[26]20.5 |
o |
o |
[26]20.5 |
m |
m |
| 4 |
Allow-Events |
[28]7.2.2 |
c1 |
c1 |
[28]7.2.2 |
c2 |
c2 |
| 5 |
Authorization |
[26]20.7 |
c3 |
c3 |
[26]20.7 |
c3 |
c3 |
| 6 |
Call-ID |
[26]20.8 |
m |
m |
[26]20.8 |
m |
m |
| 7 |
Content-Disposition |
[26]20.11 |
o |
o |
[26]20.11 |
m |
m |
| 8 |
Content-Encoding |
[26]20.12 |
o |
o |
[26]20.12 |
m |
m |
| 9 |
Content-Language |
[26]20.13 |
o |
o |
[26]20.13 |
m |
m |
| 10 |
Content-Length |
[26]20.14 |
m |
m |
[26]20.14 |
m |
m |
| 11 |
Content-Type |
[26]20.15 |
m |
m |
[26]20.15 |
m |
m |
| 12 |
CSeq |
[26]20.16 |
m |
m |
[26]20.16 |
m |
m |
| 13 |
Date |
[26]20.17 |
c4 |
c4 |
[26]20.17 |
m |
m |
| 14 |
From |
[26]20.20 |
m |
m |
[26]20.20 |
m |
m |
| 14A |
Geolocation |
[89]4.1 |
c23 |
c23 |
[89]4.1 |
c23 |
c23 |
| 14B |
Geolocation-Routing |
[89]4.2 |
c23 |
c23 |
[89]4.2 |
c23 |
c23 |
| 14C |
Max-Breadth |
[117]5.8 |
n/a |
c29 |
[117]5.8 |
c30 |
c30 |
| 15 |
Max-Forwards |
[26]20.22 |
m |
m |
[26]20.22 |
n/a |
c31 |
| 16 |
MIME-Version |
[26]20.24 |
o |
o |
[26]20.24 |
m |
m |
| 16A |
P-Access-Network-Info |
[52]4.4 |
c9 |
c10 |
[52]4.4 |
c9 |
c11 |
| 16B |
P-Asserted-Identity |
[34]9.1 |
n/a |
n/a |
[34]9.1 |
c6 |
c6 |
| 16C |
P-Charging-Function-Addresses |
[52]4.5 |
c13 |
c14 |
[52]4.5 |
c13 |
c14 |
| 16D |
P-Charging-Vector |
[52]4.6 |
c12 |
n/a |
[52]4.6 |
c12 |
n/a |
| 16E |
P-Debug-ID |
[140] |
o |
c27 |
[140] |
o |
c28 |
| 16F |
P-Preferred-Identity |
[34]9.2 |
c6 |
x |
[34]9.2 |
n/a |
n/a |
| 16G |
Privacy |
[33]4.2 |
c7 |
n/a |
[33]4.2 |
c7 |
c7 |
| 17 |
Proxy-Authorization |
[26]20.28 |
c5 |
c5 |
[26]20.28 |
n/a |
n/a |
| 18 |
Proxy-Require |
[26]20.29 |
o |
n/a |
[26]20.29 |
n/a |
n/a |
| 18A |
Reason |
[34A]2 |
c17 |
c21 |
[34A]2 |
c24 |
c24 |
| 19 |
Record-Route |
[26]20.30 |
n/a |
c31 |
[26]20.30 |
n/a |
c31 |
| 19A |
Referred-By |
[59]3 |
c19 |
c19 |
[59]3 |
c20 |
c20 |
| 19B |
Reject-Contact |
[56B]9.2 |
c18 |
c18 |
[56B]9.2 |
c22 |
c22 |
| 19C |
Request-Disposition |
[56B]9.1 |
c18 |
c18 |
[56B]9.1 |
c22 |
c22 |
| 20 |
Require |
[26]20.32 |
m |
m |
[26]20.32 |
m |
m |
| 20A |
Resource-Priority |
[116]3.1 |
c25 |
c25 |
[116]3.1 |
c25 |
c25 |
| 21 |
Route |
[26]20.34 |
m |
m |
[26]20.34 |
n/a |
c31 |
| 21A |
Security-Client |
[48]2.3.1 |
c15 |
c15 |
[48]2.3.1 |
n/a |
n/a |
| 21B |
Security-Verify |
[48]2.3.1 |
c16 |
c16 |
[48]2.3.1 |
n/a |
n/a |
| 21C |
Session-ID |
[162] |
o |
c32 |
[162] |
o |
c32 |
| 22 |
Supported |
[26]20.37 |
o |
o |
[26]20.37 |
m |
m |
| 23 |
Timestamp |
[26]20.38 |
c8 |
c8 |
[26]20.38 |
m |
m |
| 24 |
To |
[26]20.39 |
m |
m |
[26]20.39 |
m |
m |
| 25 |
User-Agent |
[26]20.41 |
o |
o |
[26]20.41 |
o |
o |
| 25A |
User-to-User |
[126]7 |
c26 |
c26 |
[126]7 |
c26 |
c26 |
| 26 |
Via |
[26]20.42 |
m |
m |
[20]20.42 |
m |
m |
| c1: IFA.4/22THENoELSEn/a--actingasthenotifierofeventinformation. c2: IFA.4/23THENmELSEn/a--actingasthesubscribertoeventinformation. c3: IFA.4/7THENmELSEn/a--authenticationbetweenUAandUA. c4: IFA.4/11THENoELSEn/a--insertionofdateinrequestsandresponses. c5: IFA.4/8ATHENmELSEn/a--authenticationbetweenUAandproxy. c6: IFA.4/25THENoELSEn/a--privateextensionstotheSessionInitiationProtocol(SIP)forassertedidentitywithintrustednetworks. c7: IFA.4/26THENoELSEn/a--aprivacymechanismfortheSessionInitiationProtocol(SIP). c8: IFA.4/6THENoELSEn/a--timestampingofrequests. c9: IFA.4/34THENoELSEn/a--theP-Access-Network-Infoheaderextension. c10: IFA.4/34ANDA.3/1THENmELSEn/a--theP-Access-Network-InfoheaderextensionandUE. c11: IFA.4/34AND(A.3/7AORA.3/7DORA3A/84)THENmELSEn/a--theP-Access-Network-InfoheaderextensionandASactingasterminatingUA,ASactingasthird-partycallcontrollerorEATF. c12: IFA.4/36THENoELSEn/a--theP-Charging-Vectorheaderextension. c13: IFA.4/35THENoELSEn/a--theP-Charging-Function-Addressesheaderextension. c14: IFA.4/35THENmELSEn/a--theP-Charging-Function-Addressesheaderextension. c15: IFA.4/37ORA.4/37ATHENoELSEn/a--securitymechanismagreementforthesessioninitiationprotocolormediasecheaderfieldparameterformarkingsecuritymechanismsrelatedtomedia(note). c16: IFA.4/37ORA.4/37ATHENmELSEn/a--securitymechanismagreementforthesessioninitiationprotocolormediasecheaderfieldparameterformarkingsecuritymechanismsrelatedtomedia. c17: IFA.4/38THENoELSEn/a--theReasonheaderfieldforthesessioninitiationprotocol. c18: IFA.4/40THENoELSEn/a--callerpreferencesforthesessioninitiationprotocol. c19: IFA.4/43THENmELSEn/a--theSIPReferred-Bymechanism. c20: IFA.4/43THENoELSEn/a--theSIPReferred-Bymechanism. c21: IFA.3/2THENmELSEIFA.4/38THENoELSEn/a--P-CSCF,theReasonheaderfieldforthesessioninitiationprotocol. c22: IFA.4/40THENmELSEn/a--callerpreferencesforthesessioninitiationprotocol. c23: IFA.4/60THENmELSEn/a--SIPlocationconveyance. c24: IFA.4/38THENmELSEn/a--theReasonheaderfieldforthesessioninitiationprotocol. c25: IFA.4/70BTHENmELSEn/a--inclusionofCANCEL,BYE,REGISTERandPUBLISHincommunicationsresourcepriorityforthesessioninitiationprotocol. c26: IFA.4/76THENoELSEn/a--transportingusertouserinformationforcallcentersusingSIP. c27: IFA.4/80THENoELSEn/a--theP-Debug-IDheaderfieldforthesessioninitiationprotocol. c28: IFA.4/80THENmELSEn/a--theP-Debug-IDheaderfieldforthesessioninitiationprotocol. c29: IFA.4/71AND(A.3/9BORA.3/9C)THENmELSEIFA.3/1ANDNOTA.3C/1THENn/aELSEo--addressinganamplificationvulnerabilityinsessioninitiationprotocolforkingproxies,IBCF(IMS-ALG),IBCF(ScreeningofSIPsignalling),UE,UEperformingthefunctionsofanexternalattachednetwork. c30: IFA.4/71THENmELSEn/a--addressinganamplificationvulnerabilityinsessioninitiationprotocolforkingproxies. c31: IFA.3/1ANDNOTA.3C/1THENn/aELSEo--UE,UEperformingthefunctionsofanexternalattachednetwork. c32: IFA.4/91THENmELSEn/a--theSession-IDheader. |
|||||||
| NOTE: Supportofthisheaderinthismethodisdependentonthesecuritymechanismandthesecurityarchitecturewhichisimplemented.Useofthisheaderinthismethodisnotappropriatetothesecuritymechanismdefinedby3GPPTS33.203[19]. |
|||||||
11.1. UAC行爲
一旦構造了BYE，UAC核心建立新的非INVITE客戶端事務，並將其傳送給BYE請求。BYE請求一旦發送給客戶端事務，UAC 必須認爲會話結束了（並所以中止發送和偵聽媒體）。若是BYE響應是481（呼叫/事務不存在）或者408（請求超時），或者請求根本沒有接收到BYE的響應（便是INVITE客戶端事務返回超時），那麼，UAC必須認爲會話和對話結束了。
11.2. UAS行爲
UAS首先遵循第5.2 節介紹的通用UAS處理過程來處理BYE請求。
UAS核心接收到BYE請求，檢查它是否和現有對話匹配。若是BYE不能和現有對話匹配，那麼，UAS核心必須生成481（呼叫/事務不存在）響應，並將其發送給服務器事務。
此規則意味着，將拒絕UAC 發送的無標籤BYE。這是對RFC 2543的修改——它容許無標籤的BYE。
UAS核心接收現有對話的BYE請求，而且發現和現存的對話匹配，必須遵循對話處理過程處理請求。一旦完成，UAS應該結束會話（並所以中止發送和偵聽媒體）。它惟一不能夠選擇的狀況是多播會話，在多播會話中，即便會話的其餘參與者已經結束了其包含的會話，都有可能參與（participation）。無論它是否結束參與會話，UAS核心必須對BYE生成2xx 響應，並將其發送到服務器事務傳輸。
UAS必須響應任何此對話中接收的掛起的請求。推薦對於這些掛起的請求生成487（請求結束）響應。
12. 取消請求（CANCEL）
CANCEL請求，是用於取消客戶端發送的前一請求。特別的是，它要求UAS 中止處理請求，併爲請求生成錯誤響應。對佔用服務器很長時間才能響應的請求來講，CANCEL請求是最有用的。由於這樣，CANCEL請求在佔用服務器很長時間響應的地方頗有用。爲此，對須要很長時間生成響應的INVITE請求，CANCEL是最好的。按照常例，接收到INVITE的CANCEL請求，可是沒有發送最終響應的UAS，可能會「中止響鈴」，而後給INVITE發送特定的錯誤代碼（487）。
代理和用戶代理客戶端均可以構造CANCEL請求。
有狀態代理對CANCEL作出響應，而不是簡單地轉發它從下游元素接收的響應。所以，由於每一個有狀態代理的跳躍點都響應它，CANCEL被稱爲「逐跳」請求。
12.1. UAC行爲
不該該發送CANCEL取消INVITE外的請求。
由於INVITE外的請求是當即響應的，爲非INVITE發送CANCEL會創造競態條件。
使用下列過程來構造CANCEL請求。CANCEL請求中的Request-URI、Call-ID、To、Cseq的數字部分和From 頭字段，必須與要取消的請求中的同樣，包括標籤。客戶端構造的CANCEL必須有單一的Via與要取消的請求中的最上面Via值匹配。這些頭字段使用相同的值，容許CANCEL和它要取消的請求匹配。然而，此方法的CSeq頭字段必須有CANCEL值。這容許它憑藉自身的實力肯定和處理爲事務。
若是要取消的請求包括Route 頭字段，那麼CANCEL請求必須包括此Route 頭字段值。
這是必需的以便於無狀態代理能夠正確地路由CANCEL請求。
CANCEL請求不能包含任何Require和Proxy-Require頭字段。
一旦構造了CANCEL，客戶端應該檢查是否接收到要取消請求（這裏指「原始請求」）的任何（臨時或者永久）響應。
若是沒有接收到臨時響應，必須發送CANCEL請求，固然，客戶端必須等待發送請求以前的臨時響應。若是原始請求產生最終響應，不該該發送CANCEL，由於它是有效的無操做，而CANCEL對已經生成最終響應的請求沒有影響。
當客戶端決定發送CANCEL時，它爲CANCEL建立客戶端事務，並將其和CANCEL請求以及目的地址、端口和傳輸一塊兒發送。CANCEL請求的目的地址、端口和傳輸必須和發送請求的同樣。
在接收到以前請求的響應以前，若是容許發送CANCEL，那麼，服務器將在原始請求以前接收到CANCEL。
注意，原始請求對應的事務和CANCEL事務是徹底獨立的。然而，UAC 取消請求不依靠接收原始請求的487（請求超時）響應，由於與RFC2543 兼容的UAS 不會生成這樣的響應。若是在64*T1 秒內沒有原始請求的最終響應，客戶端應該考慮取消的原始事務，而且應該破壞客戶端事務處理原始請求。
12.2. UAS行爲
CANCEL方法要求服務器邊的TU取消掛起的事務。TU肯定使用CANCEL請求取消的事務，而後假定請求方法是CANCLE和ACK以外的任何方法，並進行事務匹配過程。取消匹配事務。
服務器的CANCEL程序請求與服務器的類型有關。無狀態代理將轉發CANCEL，有狀態代理能夠響應CANCEL，並生成本身的CANCEL請求，同時，UAS將響應CANCEL。
UAS 首先根據第5.2節介紹的通用UAS 處理方法處理CANCEL請求。然而，由於CANCEL請求是逐跳的，而且不能夠從新提交，爲了在Authorization頭字段獲得正確的憑證，服務器不會向它們發出挑戰。注意，CANCEL請求也不包含Require頭字段。
若是UAS 沒有找到與上面過程的CANCEL匹配的事務，那麼它應該返回481（呼叫腿/事務不存在）響應。若是原始請求的事務仍然存在，接收到CANCEL請求的UAS行爲與它是否已經發送了原始請求的最終響應有關。若是它對會話狀態和原始請求生成的響應沒有影響，那麼CANCEL請求對原始請求的處理沒有影響。若是UAS沒有發佈原始請求的最終響應，那麼，其行爲和原始請求的方法有關。若是原始請求是INVITE，UAS應該當即響應INVITE，返回487（請求結束）。CANCEL請求對本規範中定義的其它方法的事務處理沒有影響。無論原始請求的方法是什麼，只要CANCEL能夠匹配現有的事務，那麼，UAS回答CANCEL請求200（OK）響應。遵循第5.2.6 節介紹的過程構造此響應。注意，CANCEL響應的To標籤和原始請求響應的To標籤應該是同樣的。CANCEL響應傳送給服務器事務發送。
13. 即時消息（MESSAGE）
即時消息被定義爲一組參與實體之間的實時消息交互，一般狀況下，這些消息是文字信息，而且這些消息不須要存儲。SIP即時消息經過擴展方法MESSAGE實現。
當用戶想要發送即時消息時，該用戶經過MESSAGE方法發起一個SIP請求。MESSAGE請求的Request –URI能夠是SIP URI，也能夠是其它類型的地址。
傳遞消息內容包含在MESSAGE請求的消息體中，該消息體能夠是任何MIME類型，包括message/ CPIM 。但更建議message/cpim，由於已有的IM系統標準是message/cpim格式
MESSAGE消息被送達以前，可能通通過一系列SIP proxy，每一個SIP proxy須要重寫請求URI以提供消息傳遞的路由信息。
像SIP其它請求同樣，收到MESSAGE應回臨時應答和最終應答。200-OK只說明消息成功到達了目的地，並不代碼用戶已經閱讀。
MESSAGE請求並不建立對話。
13.1. UAC行爲
MESSAGE body必須支持plain/text格式。能夠選擇支持message/cpim格式。因爲不建立一個dialog，因此MESSAGE不該該包含contact頭域。MESSAGE能夠在in dialog裏發送，此時表明這個消息和某個dialog有關聯關係（即發消息的URI爲SIP URI）。
最終應答的含義，
200-OK：消息已成功送達目的地，但不保證對方用戶已閱；
202-Accept：消息已成功發送到某網關，但不保證網關必定能把該消息送達目的地。
外發proxy有可能把MESSAGE分叉，能夠加Expire頭域，Date頭域代表消息的生存時間。
13.2. 使用IM URI
Request URI，From頭域，To頭域能夠填SIP URI，實在不行也能夠填IM URI，此時會有proxy解析成SIP URI。
和路由相關的頭域中的URI必須是SIP URI。
13.3. UAS的操做
和SIP相關的操做參見rfc3261。
200-OK：UAS收到MESSAGE，應當即回200-OK，可是是否把消息的內容顯示給用戶與本地策略有關 (是否是能夠用來製做黑名單功能？) 。200-OK不能帶body,，也不能攜帶Contact頭域。
202-Accepted：若是本身不是MESSAGE的最終用戶，就回202-Accepted。意味着該MESSAGE會被盡力轉發，但不保證必定能到達目的地。
4xx, 5xx ：4xx, 5xx表示消息未被成功發送。
6xx ：6xx表示消息雖被成功發送，但已被拒收。
支持MESSAGE就必須支持text/plain格式的MIME type。也能夠選擇支持message/cpim格式。
若是消息攜帶有Expire頭域，就處理超時，不然沒有超時的概念。
若是UAS收到消息時該消息已經超時，能夠選擇處理該消息這和本地策略有關。例如能夠選擇丟棄，也能夠正常顯示給用戶（標明超時），或採起其它策略。
若是消息不能被正確中繼，如何處理該消息也與本地策略有關。
13.4. 擁塞控制
MESSAGE用信令攜帶媒體，因此流量會很大，須要特殊考慮。 若是可能，MESSAGE最好使用有擁塞控制的傳輸層協議，如TCP，SCTP。
消息自己的大小不一不要超過1300個字節，除非你知道確切的PMTU大小。
對於不採用Dialog方式的消息，發往同一個目的URI的MESSAGE，若是上一個transaction尚未結束，就不容許發送下一個MESSAGE；並且若是不是路由設置每一跳在傳輸中採用擁塞控制，用Dialog傳送的MESSAGE也禁止這麼作。
有人曾建議爲了減小擁塞，MESSAGE沒必要回臨時應答。實際上沒有必要規定這個。由於不少代理服務器根本就不關心是不是MESSAGE方法，他們只管轉發。
14. Proxy行爲
SIP代理是將SIP請求路由到用戶代理服務器和將SIP響應路由到用戶代理客戶端的元素。到達UAS 的請求能夠穿透其間的多個代理。每一個代理均可以做出路由決定，並在將請求轉發到下一個元素以前對其修改。響應將經過代理路由，該代理與逆序請求穿透的代理相同。代理做爲SIP元素的邏輯角色。當請求到達時，該元素在做爲代理以前先肯定是否須要響應其上的請求。例如，在充當代理以前，該請求可能難以理解或者該元素須要客戶端的憑證。該元素可能用適當的錯誤代碼做出響應。當直接響應請求時，該元素則扮演UAS 的角色，而且其行爲必須如第5.2 節所述。
對於每一個新的請求，代理能夠以有狀態或者無狀態模式操做。當採用無狀態模式時，代理僅充當一種簡單轉發元素。它轉發每個請求下行到一個由請求所決定的目的地，該目的地是基於請求由目標和路由決定肯定的。它簡單地轉發它接收的每一個上流響應。一旦請求被轉發，無狀態代理將丟棄該請求相關的全部狀態信息。
有狀態代理將保留每一個入站請求的信息（特別是事務狀態），而且它所發送的任何請求都做爲入站請求處理結果。有狀態代理使用入站請求信息來影響與該請求相關的下一步消息處理。有狀態代理能夠選擇「分發」請求，並將它路由到多個目的地。轉發給多個位置的請求都必須有狀態處理。
在某些狀況中，代理可能在未成爲有狀態事務時就使用有狀態傳輸協議（如TCP）轉發請求。例如，代理能夠將請求從一個TCP 鏈接轉發到另外一個無狀態事務，只要它在消息裏放有足夠多的信息以將該響應向下轉發給該請求所到達的相同鏈接上。在不一樣傳輸類型之間所轉發的請求必須有狀態的轉發事務，這裏代理的TU 必須主動地確保在每個傳輸上都是可靠傳輸。
在請求處理期間，只要有狀態代理不做阻止其回到初始無狀態的事情（例如，分發或生成一個100 響應），它就能夠轉換爲無狀態操做模式。當完成這樣的轉換時，丟棄了全部狀態。代理不該發起CANCEL 請求。
不管請求是有狀態仍是無狀態，相關的許多處理都是相同的。
14.1. 有狀態代理
當處於有狀態模式時，代理則徹底做爲一個SIP事務處理引擎。在此按照服務器和客戶端事務模擬其行爲。有狀態代理經過高級代理處理組件（做爲代理核心）將一個服務器事務與多個客戶端事務聯繫在一塊兒。入站請求由服務器事務來處理。服務器事務處理後的請求傳送到代理核心。代理核心肯定將該請求路由到何處，並選擇一個或者多個下一跳位置。每一個下一跳位置的出站請求都由其自身相關的客戶端事務來處理。代理核心收集來自客戶端事務的響應，而後使用客戶端事務將響應發送到服務器事務。
有狀態代理爲每一個所接收的新請求建立新的服務器事務。隨後按第14章介紹的服務器事務，處理請求的轉發。在發送及時的臨時請求給第5.2.6節介紹的服務器事務（如，100(Trying)）時，代理核心必須做爲UAS。所以，有狀態代理不該該對非INVITE請求生成100(Trying)響應。
這是代理行爲的模型，而不是軟件。能夠自由地採用任何方法來複制該模型定義的外部行爲。
對於全部新的請求，包括未知方法、做爲代理的元素，請求必須：
1. 確認請求
2. 預處理路由信息
3. 肯定請求目標
4. 向每一個目標轉發請求
5. 處理全部響應
14.2. 請求確認
在元素代理請求以前，它必須確認消息的有效性。有效消息必須通過如下檢查：
1. 合理語法
2. URI 模式
3. Max-Forwards
4. (可選)循環檢測
5. Proxy-Require
6. Proxy-Authorization
若是其中任何檢查失敗，該元素必須做爲用戶代理服務器（參見第5.2節），而後響應錯誤代碼。
注意代理不須要檢測已合併的請求，它不該將已合併的請求做爲錯誤的條件。接收請求的端點將解析合併，如第5.2.2節所述。
一、合理的語法檢查
請求必須足夠規格化，以便於與服務器事務一塊兒處理。在剩餘的這些請求確認步驟中或者請求轉發章節所涉及的組件必須是規格化組件。對於其它組件，則對規格化的要求不是很嚴格，當轉發消息時，能夠忽略此組件或者該組件保持不變。舉個例子來講，因爲Date頭字段的格式很差，元素將不能接受請求。一樣的，代理不該該在轉發請求以前將格式很差的Date頭字段刪除。
本協議可用來擴展。新擴展能夠隨時定義一些新的方法和頭字段。這樣元素不能由於請求中包含它所不知道的方法和頭字段而拒絕代理請求。
二、URI 模式檢查
若是Request-URI的URI模式不爲代理所理解，代理應拒絕該請求，並返回416（不支持URI 模式）響應。
三、Max-Forwards 檢查
Max-Forwards頭字段用於限制SIP請求能夠穿透的元素數。
若是請求不包含Max-Forwards頭字段，Max-Forwards檢查經過。
若是該請求包含Max-Forwards頭字段，該字段是比零大的字段值，則Max-Forwards檢查也經過。
若是該請求包含Max-Forwards頭字段，該字段值爲零，元素不需轉發請求。若是該請求用於OPTION，該元素能夠做爲最終接受者，並做出響應。此外，元素必須返回483（太多跳躍點）響應代碼。
四、可選循環檢測檢查
在轉發請求前，元素能夠對轉發循環做檢查。若是請求包含了Via頭字段，所發送的值等於代理預先放置在請求中的值，該請求先由該元素轉發。請求經過該元素循環或者合理的螺旋。爲了肯定了請求是否循環，該元素能夠完成分支參數計算，並將它與Via 頭字段中所接收的參數進行比較。若是參數匹配，請求循環。若是它們不相同，則請求正螺旋，處理繼續。若是探測出發生循環，則該元素返回482（循環探測）響應。
五、Proxy-Require檢查
對協議做進一步擴展，則能夠引入代理特殊處理的功能。端點在請求中加入使用這些特性的Proxy-Require（代理需求）頭字段，告知代理除非理解該特性，不然不處理該請求。若是該請求包含Proxy-Require頭字段，它帶有一個或者多個該元素所不理解的可選標籤，元素必須返回420（錯誤擴展）響應。該響應必須包括Unsupported頭字段，該字段列出了該元素不理解的可選標籤。
六、Proxy-Authorization若是代理要求在轉發請求以前進行身份認證，那麼必須進行請求檢查。
14.3. 路由信息處理
代理必須檢查請求的Request-URI。若是請求的Request-URI包含了該代理預先放置在Record-Route 頭字段值，代理必須使用Route 頭字段中的最後一個值代替請求中Request-URI 的值，而且將該值從Route 頭字段中去掉。一旦代理接收到已修改的請求，它將繼續處理。
這種狀況只有在元素向做爲嚴格路由器的代理（能夠是一個端點）發送請求時發生。對所接收的請求重寫必須具備這些元素的向後兼容性。它也容許遵循本規範的元素，經過嚴格路由代理保留Request-URI。
本規範不強制代理保持狀態，以便於它檢查先前放置在Record-Route頭字段中的URI。反過來講，代理只須要在這些URI中放置足夠多的信息，它就能夠在隨後出現時能夠識別其值。
若是Request-URI包含maddr參數，那麼代理必須檢查所配置代理負責的值是否在地址集或者域中。若是Request-URI包含帶值的maddr參數，該值由代理負責，而且使用Request-URI中所指示（明確指示或者默認）的端口和傳輸來接收請求，那麼，代理必須去除maddr參數和任何非默認端口或者傳輸參數，而且繼續處理，就像這些值從未在請求中出現同樣。
若是所接收請求帶有與代理匹配的maddr，可是該maddr參數與URI中所指示的端口或者傳輸不一樣。這樣就須要使用所指示的端口和傳輸將請求轉發給代理。
若是Route 頭字段中的第一個值指明這個代理，該代理必須將此值從請求中去掉。
14.4. 肯定請求目標
接下來，代理計算出請求的目標。目標集合能夠由請求的內容預先肯定，也能夠從抽象定位服務中得到。集合中的每一個目標都做爲URI。
若是請求的Request-URI包含maddr參數，Request-URI必須做爲惟一的目標URI放在目標集合中，而且，代理必須繼續請求轉發。
若是Request-URI的域表示此域不是該元素負責的域，那麼，Request-URI 必須做爲惟
一的目標URI 放在目標集合中，同時，此元素必須繼續請求轉發的任務（第16.6 節）。
在不少狀況中，代理可能接收到其不負責的域的請求。防火牆代理處理出站呼叫（HTTP
代理處理出站請求的方式）是可能發生此狀況的一個實例。
若是請求的目標集合沒有如上所述預先肯定，那麼，它意味着元素是對Request-URI的域負責任的，同時，元素能夠使用它想要的任何機制，肯定發送請求的地址。這些機制能夠做爲訪問抽象定位服務的模型。這可能由如下幾個部分組成——獲取SIP註冊服務器建立的定位服務信息、讀取數據庫、查詢狀態服務器、使用其餘協議和在Request-URI中簡單地執行算法替代。當訪問註冊服務器構造的定位服務時，在將其用做索引以前，首先要將Request-URI規範化。這些機制的輸出用做構造目標集合。
若是Request-URI沒有爲代理提供足夠的信息來肯定目標集合，那麼，它應該返回485（模糊）響應。此響應應該包含Contact頭字段——包含已做嘗試的新地址的URI。如，對sip:John.Smith@company.com的INVITE可能有些含糊不清，其定位服務列出了多個John Smiths。
在請求中或關於請求或元素當前環境的任何信息均可以用做構造目標集合。例如，依賴於頭字段和消息體的內容和狀態、請求間隔的延遲、請求到達的接口、以前請求的錯誤、甚至是元素的當前利用率，能夠構造不一樣的目標集合。
當經過這些服務對潛在的目標定義時，將其URI添加到目標集合中。目標僅能在目標集合中放置一次。若是在目標集合中已經有目標URI（以URI 類型相同的定義爲基礎），那麼，不能再添加目標URI。
若是原始請求的Request-URI沒有指出代理負責的資源，那麼，代理不能在目標集合中添加其它的目標。
只有代理對此URI負責時，代理才能夠在轉發期間修改Request-URI的URI。若是代理不對此URI負責，那麼，它將不能使用下面介紹的3xx和416響應。
若是原始請求的Request-URI指出了代理負責的資源，那麼，在開始請求轉發後，代理能夠在目標集合中添加目標。它能夠使用在處理過程當中獲取的任何信息來肯定新目標。例如，代理能夠選擇將重定向響應（3xx）中獲取的聯繫信息合併到目標集合中。若是在創建目標集合的同時，代理使用一個動態信息資源（如，它查詢SIP 註冊服務器），那麼，在處理請求的過程當中，它應對資源監控。一旦新的地址有效，應該將其添加到目標集合中。如上所述，任何給定的URI不能屢次添加到目標集合中。
僅容許URI 在目標集合中添加一次，能夠減小沒必要要的網絡流量，從重定向請求中獲取的合併聯繫信息的狀況，防止了無窮的網絡遞歸。
例如，當目標URI和入站的請求URI相同時，一般的定位服務是「無操做」。爲了進一步處理，請求發送到指定的下一跳代理。在請求轉發期間，以SIP和SIPS URI表示的下一跳識別符做爲最上面的Route頭字段值插入到請求中。
若是Request-URI指出此代理上的資源不存在，那麼，代理必須返回404（沒找到）響應。
若是在應用以上全部以後，目標集合仍然爲空，代理必須返回480（暫時不可用）錯誤響應。
14.5. 轉發請求
一旦目標集非空時，代理便開始轉發請求。有狀態代理能夠以任何順序處理這個目標集合。它能夠串行處理多個目標，即容許客戶端事務在下一個事務開始前完成。它也能夠採用每一個目標並行處理的方式啓動客戶端事務。它還能夠將目標集合任意分組，對這些組串行處理，或者對每一個組中的目標並行處理。
經常使用的排序機制是使用目標的q值參數，這些參數可從Contact頭字段中獲取。目標的處理順序是從最高q值到最低q值。具備相同q值的目標可並行處理。
當接收響應時，有狀態代理必須具備維護對象集合的機制，而後將對每一個轉發請求的響應與原始請求相關聯。對於該模型而言，這種機制就是由代理層在轉發第一個請求以前建立的「響應上下文」。
對於每一個目標，代理都遵循如下步驟發送請求：
一、 複製所接收的請求
二、 更新Request-URI
三、 更新Max-Forwards頭字段
四、 添加Record-Route頭字段值（可選的）
五、 添加其它頭字段（可選）
六、 後處理路由信息
七、 肯定下一跳的地址、端口和傳輸協議
八、 添加一個Via頭字段值
九、 若是須要，添加一個Content-Length頭字段
十、 轉發新請求
十一、 設置計時器C
每一個步驟詳述以下：
一、 複製請求
代理首先將接收到的請求複製。這個副本最初必須包含所接收到的請求的全部頭字段。在一下描述中沒有明確說明的字段不能夠去掉。副本應與所接收的請求保持相同的頭字段順序。代理不能用通用字段名對字段值從新排序。代理也不能添加、修改或刪除消息體。
在實際執行中有時並不須要完成複製請求；可是主要前提條件是每一個下一跳的處理都以相同的請求開始。
二、 Request-URI
必須用目標的URI代替位於副本起始行的Request-URI。若是這個目標的URI含有Request-URI中不容許的任何參數，那麼必須刪除它們。
這就是代理角色的本質。代理會經過這種機制將請求路由到目的地。
在某些狀況下，接收到的Request-URI 未經修改便放到了目標集合中。對於該目標而言，無需執行以上替換操做。
三、 Max-Forwards
若是副本包含Max-Forwards頭字段，那麼代理必須將其值減1。
若是副本不含Max-Forwards頭字段，那麼代理必須添加一個Max-Forwards字段值，其值爲70。
現有的某些UA 在請求中沒有提供Max-Forwards 字段。
四、 Record-Route
若是這個代理但願保留在該請求所建立的對話中後續請求的路徑上（假定這個請求會建立一個對話），那麼即便已經存在Route頭字段，它也必須在副本中任何已有的Record-Route頭字段值以前插入一個Record-Route頭字段值。
創建對話的請求能夠包含一個預先加載的Route頭字段。
若是這個請求已是對話的一部分，那麼，若是代理但願保留在對話中後續請求的路徑上，它就應當插入一個Record-Route頭字段值。在一般端點操做的狀況下，這些Record-Route 頭字段值不會對端點使用的路由集合產生任何影響。
若是代理選擇不向已是對話的一部分的請求中添加Record-Route頭字段值，那麼代理將會保留在該路徑上。可是當失敗端點從新構建對話時，將會從這個路徑上去掉這個代理。
代理會向任何請求添加Record-Route頭字段值。若是請求不啓動對話，那麼端點將忽略這個值。欲瞭解端點如何使用Record-Route頭字段值構建Route頭字段的詳情。
請求路徑中的每一個代理都會單獨選擇是否添加Record-Route頭字段值——請求中Record-Route頭字段的狀態並不迫使該代理添加一個值。
放入Record-Route 頭字段值中的URI 必須是SIP或SIPS URI。這個URI必須包含一個lr參數。這個URI 能夠與請求轉發到的每一個目的地不一樣。除非代理知道（如在私有網絡中）下一個將在後續請求路徑中的下游元素支持此傳輸協議，URI不該包含傳輸參數。
這個代理提供的URI將被其它元素用來做路由決策。通常說來，這個代理沒法知道其它元素的性能，所以它必須將其自己限制爲SIP執行的強制元素：SIP URI和TCP/UDP傳輸。
當對放置在Record-Route頭字段的URI應用服務器定位的第四步時，這個URI必須對插入此URI的元素解析，這樣後續請求就能夠訪問相同的SIP元素。若是Request-URI 包含SIPS URI，或頂端Route頭字段值（在步驟6 的後處理後）包含SIPS URI，那麼放置在Record-Route頭字段的URI必須是SIPS URI。此外，若是沒有在TLS之上接收到這個請求，代理就必須插入一個Record-Route頭字段。與之相似的狀況：代理在TLS 上接收請求，可是生成的請求沒有在Request-URI或頂端Route頭字段值中（在步驟6 的後處理後）的SIPS URI，那麼代理必須插入一個非SIPS URI的Record-Route頭字段。
在整個對話期間，位於安全邊界的代理必須保留此邊界。
當放置在Record-Route頭字段中的URI以響應的形式回傳時，若是它須要重寫，那麼這個URI必須不同凡響，以便在此時能夠定位。（這個請求可經過此代理螺旋，致使了添加多個Record-Route頭字段值）。
代理可在Record-Route頭字段值中包含參數。這些參數值將在對該請求的某些響應中獲得迴應，這些響應如：對INVITE的200（OK）響應。這樣的參數對於在消息中而不是在代理中保持狀態會頗有用。
若是某代理須要存在於任何類型的對話（如一用戶要跨越防火牆）路徑中，那麼它應當用一個它不理解具備對話語義的方法向每一個請求添加一個Record-Route頭字段值。
代理放置在Record-Route 頭字段中的URI，僅僅在出現URI 的事務所建立的任何對話的生命週期內有效。例如，對話有狀態代理可在對話終止後能夠拒絕接受在Record-Route中有該值的後續請求。固然，非對話有狀態協議沒有對話什麼時候終止的概念，但它們能夠對值中信息編碼，以將其與後續請求的對話標識符相比較，而後會拒絕與那些信息不匹配的請求。
端點不能在提供它的對話外使用從Record-Route頭字段得到的URI。
代理須要觀察對話中全部消息的某些服務可能須要Record-Routing。可是，Record-Routing會減慢處理過程，並下降可擴展性，使得代理只在特定服務須要的狀況下進行Record-Route。
Record-Route過程旨在爲啓動對話的任何SIP 請求工做。INVITE 是本規範中惟一屬於這類的請求，可是這個協議的擴展能夠定義其它請求。
五、 添加其餘頭字段
在這一點上，代理能夠向副本添加任何其它適當的頭字段。
六、 對路由信息進行後處理
代理能夠設置本地策略，要求請求在傳送到目的地以前訪問特定代理集合。代理必須確保全部這些代理都是鬆散路由。通常說來，若是這些代理位於同一管理域中，這點可能比較容易明白。該代理集合由URI集合（每一個URI都包含lr參數）表示。該代理集合必須放入副本中的Route頭字段中，而且位於任何現有的值以前，若是這些值存在的話。
若是代理能夠設置本地策略，要求請求訪問一個特定代理，那麼將Route值放入Route頭字段中的可選辦法是跳過下面描述的第10步的轉發步驟，而僅向那個特定代理的地址、端口以及傳輸協議肯定的目的地發送請求。若是這個請求有Route頭字段，那麼除非知道下一跳代理是鬆散路由，不然不能使用這種可選方法。此外，雖然這個方法也可用，但對於操做的健壯性、靈活性、通用性和連貫性來講，Route插入機制是更可取的。並且，若是Request-URI包含SIPS URI，那麼必須使用TLS與該代理進行通訊。
若是副本包含一個Route頭字段，那麼代理對其第一個值中URI檢查。若是此URI不含有lr參數，這個代理必須對該副本作以下修改：
這個代理必須將Request-URI做爲最後一個值放入Route頭字段中。
而後該代理必須將第一個Route頭字段值放在Request-URI 中，並將第一個Route頭字段值從Route頭字段中刪除。
將Request-URI附加在Route頭字段中，是經過嚴格路由元素傳送Request-URI中的信息的機制的一部分。將第一個Route頭字段值加到Request-URI中會將消息格式化，嚴格路由元素指望以這種格式來接收這條消息（其自身的URI在Request-URI中，下一個要訪問的位置在第一個Route頭字段值中）。
七、 肯定下一跳的地址、端口和傳輸協議
代理可設置本地策略將請求發送到特定IP地址、端口和傳輸協議肯定的目的地，而這個目的地與Route值和Request-URI值無關。若是代理不肯定這個IP地址、端口和傳輸協議是否與做爲鬆散路由器的服務器對應，那麼不能夠使用此策略。可是，對於經過特定下一跳發送請求的這種機制，咱們並不推薦；對於這種狀況，能夠使用Route頭字段。
在沒有這種替換機制狀況下，代理應按照第四條中所列出的步驟肯定往何處發送請求，以下描述。若是代理已對請求從新格式化以將其發送到前面第六步描述的嚴格路由元素，代理應將這些步驟應用到請求的Request-URI。不然，若是Route頭字段的第一個值存在，也就是Request-URI存在，代理必須對其應用這些步驟。這些步驟將產生一個有序的數據集（地址、端口、傳輸協議）。無論使用哪一個URI做爲第四條步驟的輸入，若是Request-URI指定一個SIPS資源，代理就必須將輸入URI看成SIPS URI，按照第四條步驟的規定執行。
正如第四條所描述的，代理必須不斷嘗試將消息傳送到元組集的第一個元組，而後依次傳送元組集的第二個元組、第三個元組，直到傳送成功爲止。
對於準備接收消息的元組，代理必須爲將消息格式化爲適合於該元組的消息，並使用第八條和第10條所描述的新的客戶端事務發送請求。因爲每一次嘗試都使用一個新客戶端事務，所以每一次嘗試都表明一個新的分支。於是，由第8步中插入的Via頭字段提供的分支參數必須互不相同。
若是客戶端事務報告發送請求失敗或者狀態機超時，該代理將繼續發送到有序元組系列的下一個地址。若是到了這個有序系列的末尾，請求便沒法轉發到目標集合的這個元素中。
代理不須要在響應上下文中放入任何東西，可是它的行爲就像是這個目標集合的元素返回408（請求超時）最終響應。
八、 添加一個Via 頭字段值
代理必須在副本中現有的Via頭字段值以前插入一個Via頭字段值。這個值的構造遵循第5.1.1節相同的規定。這意味着代理將計算本身的分支參數，分支參數對於其對應的分支來講要具備全局惟一性，而且包含必備的magic cookie。請注意，這意味着對於由代理產生的螺旋請求或者循環請求的不一樣實例來講，分支參數應有所區別。
選擇檢測循環的代理在它們用來構造分支參數的值上還有其它限制。選擇檢測循環的代理應當建立一個分支參數，這個參數由應用分爲兩部分。第一部分必須知足上述第5.1.1節所述的限制。第二部分用來完成循環檢測並區別循環請求與螺旋請求。當請求返回給代理時，經過驗證那些對請求處理產生影響的字段沒有改變，完成循環檢測。分支參數這一部分中的值應當反映全部字段，包括任何Route頭字段、Proxy-Require頭字段和Proxy-Authorization頭字段。這是爲了確保若是請求路由回代理，而且這些字段中的其中一個發生更改，那麼它將被視爲螺旋請求而不是循環請求。建立此值的通用方法是對如下內容做加密哈希運算：所接收請求（在轉換以前）的TO標記、From標記、Call-Id頭字段、Request-URI、最上面的Via頭、Cseq頭字段的序列號，而且若是Proxy-Require和Proxy-Authorization頭字段出現時，還包括它們。用於計算哈希的算法是與執行程序有關，然而以16進製表示的MD5，是一個不錯的選擇。（對於標記來講，不容許使用Base64。）
若是代理但願對循環進行檢測，那麼它提供的branch參數必須依賴於全部影響請求處理的信息，包括入站的Request-URI和任何影響該請求的進入或路由的頭字段。對於區分循環請求與那些在返回給服務器以前其路由參數發生更改的請求，這是必需的。
請求方法不能包含在分支參數的運算中。特別是CANCEL請求和ACK請求（用於non-2xx響應）必須與它們取消或確認的對應的請求有相同的分支參數值。在服務器端處理分支參數的那些相關的請求中使用這些分支參數。
九、 若是須要，添加一個Content-Length頭字段
若是使用流傳輸協議將請求發送到下一跳，而且副本不包含Content-Length頭字段，那麼這個代理必須插入一個帶有請求主體的正確值的Content-Length頭字段。
十、 轉發請求
有狀態代理必須爲這個請求建立新的客戶端事務，並指導這個事務使用第7 步肯定的地址、端口和傳輸協議發送請求。
十一、 設置計時器C
爲了處理INVITE請求從不生成最終響應這種狀況，TU使用一個稱爲計時器C的計時器。
當INVITE請求獲得代理時，必須爲每一個客戶端事務設置計時器C。必須將計時器設置爲大於三分鐘。
14.6. 響應處理
當某元素接收到響應時，它首先會試圖對匹配該響應的客戶端事務定位。若是沒有找到匹配的客戶端事務，這個元素必須將這個響應（即便這個響應是一個信息響應）做爲無狀態代理（以下所述）處理。若是找到了匹配的客戶端事務，那麼這個響應便會傳遞到客戶端事務。
在沒有客戶端事務（或更廣泛地說，知道發送了一個相關請求）的狀況下轉發響應會提升健壯性。特別是它確保將對INVITE請求的「延遲的」2xx響應恰當地轉發。
客戶端事務將響應傳送到代理層時，必須通過如下的處理步驟：
1. 找到合適的響應上下文
2. 爲臨時響應更新計時器C
3. 去掉最上面的Via
4. 對響應上下文添加響應
5. 檢查響應是否應當當即轉發
6. 當須要的時候，從響應上下文中選擇最佳最終響應
若是在每一個與響應上下文相關聯的客 戶端事務終止後沒有最終響應獲得轉發，那麼代理必須選擇並轉發它目前所見到的「最合適」的響應。
所轉發的每個響應必須執行如下處理。每一個請求可能有多個響應獲得轉發：至少每一個請求有一個臨時響應和一個最終響應。
7. 若是須要，集合受權頭字段值
8. 選擇性重寫Record-Route頭字段值
9. 轉發這個響應
10. 生成任何所需的CANCEL 請求
上面的每一個步驟詳述以下：
1. 查找上下文
代理對其建立的「響應上下文」進行定位。餘下的處理步驟將在這個上下文中進行。
2. 爲臨時響應更新計時器C
對於INVITE事務來講，若是該響應是一個臨時響應，其狀態代碼爲包含101和199在內，從101至199（即除100 之外）的任意值，那麼代理必須對那個客戶端事務的計時器C進行從新設置。能夠給計時器從新設置一個不一樣的值，可是這個值必須大於3分鐘。
3. Via
代理從響應中刪除最上面Via頭字段值。
若是響應中沒有保留Via頭字段值，那麼這個響應就是這個元素的響應，沒必要轉發。本
節所描述的剩餘處理工做不將對該消息執行，而是遵循第5.1.3 節描述的UAC處理規則（已
經發生了傳輸層處理）。
例如，當元素生成CANCEL 請求時，這種狀況會發生。
4. 向上下文添加響應
在與上下文相關聯的服務器事務上生成最終響應以前，所接收到的最終響應存儲在響應上下文中。這個響應多是那個服務器事務上所返回的候選最佳最終響應。即便這個響應沒有被選中，構成最佳響應可能也須要這個響應中的信息。
若是代理選擇經過向目標集合添加聯繫人來在3xx響應中對聯繫人進行遞歸操做，那麼它必須在將這個響應添加到響應上下文以前將這些聯繫人從響應中刪除。可是，若是原先請求的Request-URI是SIPS URI，那麼代理不該當對非SIPS URI進行遞歸操做。若是代理對3xx響應中的全部聯繫人都進行遞歸操做，那麼代理不該當向響應上下文添加所產生的無聯繫人響應。
在向響應上下文添加響應以前去掉聯繫人能夠避免下一個上游元素從新嘗試該代理已經嘗試過的位置。
3xx響應既可包含SIP，也包含SIPS和非SIP URI。代理能夠選擇遞歸SIP和SIPS URI，並將其他部分放在將要返回的響應上下文，有多是在最終響應中。
若是代理接收到了一個請求的416（不支持的URI 模式）響應，該請求的Request-URI模式不是SIP，可是原始接收請求中的模式是SIP或者SIPS（即在代理該請求時，代理將模式從SIP或SIPS更改到了其它模式），那麼該代理應當向目標集合添加一個新的URI。這個URI 應當是剛剛嘗試過的非SIP URI的SIP URI版本。在tel URL的狀況下，這一步經過將tel URL的電話訂閱用戶部分放在SIP URI的用戶部分中，並將主機部分設置爲優先請求所發送的區域。
就像3xx 響應同樣，若是代理經過嘗試SIP或SIPS URI來「遞歸」416，416不該添加到響應上下文中。
5. 爲轉發檢查響應
直到最終響應在服務器事務發送以前，必須當即轉發如下響應：
² 除100（Trying）之外的任何臨時響應
² 任何2xx響應
若是接收到一個6xx響應，那麼它不會被當即轉發，可是有狀態代理應當取消全部的客戶端待處理事務，並且它不能在該上下文中建立任何新的分支。
這是對RFC 2543 所作的更改，RFC 2543 要求代理將6xx響應當即轉發。對於INVITE事務來講，該方法有個問題：2xx響應可以到達另外一個分支，而在這種狀況下，代理就必須轉發2xx。結果是UAC能夠在接收到2xx 響應以前接收到6xx 響應，而這是不容許發生的。根據新規則，在接收6xx以前，代理將發佈一條CANCEL請求，一般這條請求會從全部的未決客戶端事務中產生487響應，而後此刻6xx便會上游轉發。
在服務器事務上發送一條最終響應以後，必須當即轉發如下響應：
² 對INVITE 請求的任何2xx 響應
有狀態代理沒必要當即轉發任何其它響應。特別是有狀態代理不能夠轉發任何100（Trying）響應。那些後來有可能做爲「最佳」響應轉發的響應已經集中在一塊兒，如「向上下文添加響應」這一步驟所述。
任何被選擇用來當即轉發的響應，必須按照從「 集合受權頭字段值」步驟到「Record-Route」步驟中所描述的內容處理。
這一步驟與下一個步驟會確保有狀態代理能向非INVITE請求準確轉發一個最終響應，或者能向INVITE請求準確轉發一個非2xx響應或者或者多個2xx響應。
6. 選擇最佳響應
若是沒有最終響應按照上述規則獲得傳送，而且該響應上下文中的全部客戶端事務都已經終止，那麼有狀態代理必須向響應上下文的服務器事務發送一個最終響應。
有狀態代理必須從那些所接收到的以及在響應上下文中存儲的響應中選擇「最佳」最終響應。
若是在上下文中沒有最終響應，那麼代理必須向服務器事務發送一個408（響應超時）響應。
不然，代理必須轉發來自響應上下文中所存儲的響應中的一個響應。若是6xx類響應存在於該響應上下文中，代理必須從6xx 類響應中選擇。若是目前沒有6xx類響應，代理應當從存儲在響應上下文中的最低級響應類中選擇。代理能夠在所選類中任意選擇響應。對於能夠提供影響請求從新提交的信息的響應，代理應給予優先選擇權。例如，若是選擇4xx類，應首先選擇的響應爲40一、40七、41五、420 和484。
一個接收503（服務不可用）響應的代理不該該將該響應上游轉發，除非該代理能夠肯定它代理的任何後續請求也能夠生成503 響應。換句話說，轉發503 意味着這個代理明白它沒法爲任何請求提供服務，而不只僅是不能爲生成503 的請求中的Request-URI 提供服務。若是所接收到的惟一響應是503，那麼這個代理應當生成一個500響應並將其上游轉發。所傳送的響應必須按照從「集合受權頭字段值」步驟到「Record-Route」步驟中所描述內容處理。
例如，若是代理將一個請求轉發到4 個位置，而後接收到50三、40七、501 和404這幾個響應，那麼它能夠選擇傳送407（須要代理認證）響應。
在創建對話過程當中可能會涉及到1xx響應和2xx響應。當請求不包含To 標記時，UAC使用響應中的To標記來區分由一個建立請求的對話的多個響應。若是請求不包含標記，代理不能向1xx和2xx的To頭字段中插入一個標記。代理也不容許修改1xx或2xx響應的To頭字段中的標記。
因爲代理不能夠向不包含標記的請求的1xx響應的To頭字段插入標記，那麼它自身沒法發佈非100臨時響應。可是它能夠將請求分支給一個與代理共享相同元素的UAS。這個UAS能夠返回其自身臨時響應，進入一個帶有該請求啓動程序的早期對話中。UAS不須要成爲代理的謹慎處理。它能夠是用與代理相同的代碼空間實現的虛擬UAS。
3-6xx響應是逐跳傳送的。當發佈一個3-6xx響應時，元素會有效地充當UAS，一般根據從下游元素接收到的響應來發送本身的響應。當一個元素只是簡單地將一個3-6xx響應轉發到一個不包含To標記的請求時，該元素應當保存To標記。
代理不能對包含To標記的請求所轉發的任何響應中的To標記進行修改。
若是代理替換了所轉發的3-6xx響應中的To標記，對於上游元素來講沒有什麼不一樣，但保存原來的標記能夠有助於調試。
當代理將幾個響應的消息集合在一塊兒時，能夠任意從它們當中選擇一個To標記，可是生成新的To標記可能會使調試容易一些。例如，當把401（未受權）和407（須要代理認證）結合在一塊兒，或把從未加密的3xx響應的Contact值和未受權的3xx響應的Contact值結合在一塊兒時，這種狀況會發生。
7. 集合Authorization頭字段值
若是選擇的響應是401（未受權）或407（須要代理驗證），那麼代理必須從這個響應上下文目前接收到的全部的其它401（未受權）響應和407（須要代理認證）響應中，收集全部的WWW-Authenticate頭字段值和Proxy-Authenticate頭字段值，並在轉發以前將它們不加修改地添加到這個響應中。產生的401（未受權）響應或407（須要代理認證）響應可能會有幾個WWW-Authenticate頭字段值和Proxy-Authenticate頭字段值。
這是必需的，由於請求轉發到的某些或者全部目的地，可能具備已請求的憑證。客戶端須要解決全部的這些難題，並在它從新嘗試請求時爲它們中的每個提供憑證。
8. Record-Route
若是選中的響應包含一個原先由該代理提供的Record-Route頭字段值，那麼該代理可在轉發這個響應以前選擇重寫該值。這使得代理能夠下一個上游元素或下游元素提供與其不一樣的URI。代理能夠以任何理由選擇使用本機制。例如，本機制對於多宿主主機來講頗爲有用。
若是代理經過TLS接收到請求，並經過非TLS鏈接發送這個請求，那麼代理必須將Record-Route頭字段中的URI 重寫爲SIPS URI。若是代理經過非TLS鏈接接收到請求，但將其經過TLS發送，那麼代理必須將Record-Route頭字段中的URI 重寫爲SIP URI。由代理提供的新的URI 所知足的條件必須與對請求中Record-Route的URI的約束相同，而且要作如下修改：
該URI不該包含傳輸參數，除非代理知道在後續請求的路徑中的下一個上游（與下游相對）元素支持此傳輸協議。
當代理決定修改響應中的Record-Route頭字段值時，它執行的一個操做是定位它已經插入的Record-Route值。若是請求螺旋，而且這個代理在每一個螺旋的迭代中插入了Record-Route值，那麼在響應（它必須以逆時針方向進行適當的迭代）中定位正確的值便比較棘手。以上規則建議但願重寫Record-Route頭字段值的代理會將足夠明顯的URI插入到Record-Route頭字段中，以即可以選擇正確的URI來進行重寫操做。達到這一目標的一個推薦的機制是，對於代理來講，要向URI的用戶部分附加一個惟一的用於代理實例的標識符。
當響應到達時，代理會對標識符與代理實例相匹配的第一個Record-Route進行修改。修改的結果是，沒有這部分數據的URI會附加到URI 的用戶部分。進行了下一個迭代以後，相同的算法（即用參數查找頂端Record-Route 頭字段值）將會正確提取那個代理插入的下一個Record-Route頭字段值。
並非請求的每一個響應都包含Record-Route頭字段， 代理向該請求添加了Record-Route 頭字段值。若是響應含有Record-Route頭字段，它將包含代理添加的值。
9. 轉發響應
執行了「集合受權頭字段值」步驟到「Record-Route」步驟的處理後，代理可對選中的響應執行任何特定於功能的操做。代理不能添加、修改或刪除消息體。除非另指明，不然代理不能刪除Via 頭字段值之外的任何頭字段值。特別是，代理在處理與該響應相關的請求時，不能刪除任何它已經添加到下一個Via頭字段值中所接收的參數。代理必須將這個響應傳送到與該響應上下文相關聯的服務器事務。這將致使響應被髮送到目前位於最上面Via頭字段值中的位置。若是服務器事務不能夠再處理傳輸，那麼該元素必須經過將響應發送到服務器傳輸來將其無狀態轉發。該服務器事務可指示發送響應失敗或狀態機器中信令超時。這些錯誤能夠做爲診斷使用，可是協議並不須要代理進行補救。直到全部與其相關的事務都終止爲止，即便在轉發最終響應以後，代理都必須對響應上下文進行維護。
10. 生成CANCEL
若是所轉發的響應是一個最終響應，那麼代理必須爲全部與該響應上下文相關聯的、待處理的客戶端事務生成CANCEL請求。代理也應當在接收到一個6xx響應時爲全部與該響應上下文相關聯的、待處理的客戶端事務生成CANCEL請求。待處理的客戶端事務是這樣的：
它已收到臨時響應，但未收到最終響應（即該事務處於進行狀態），而且還沒有具備爲其產生的相關的CANCEL 請求。
轉發最終請求時對CANCEL 待處理客戶端事務的需求不能確保端點不會收到INVITE的多個200(OK)響應。多個分支上的200(OK)響應可在CANCEL請求獲得發送並處理以前生成。此外，未來的擴展有望不考慮發佈CANCEL 請求的需求。
14.7. 處理計時器C
若是計時器C 應當觸發，那麼代理必須用任何它所選擇的值來重置這個計時器，或者終止客戶端事務。若是客戶端事務接收到臨時響應，那麼代理必須生成一個與該事務相匹配的CANCEL請求。若是客戶端事務未收到臨時響應，那麼代理的行爲與事務接收到一個408（請求超時）響應相同。
容許代理能夠重置計時器使得代理在計時器觸發時能夠根據當前狀況（如利用率）對事務的生命週期進行動態擴展。
14.8. 處理傳輸錯誤
若是傳輸層在代理試圖轉發一個請求時通知它出現了錯誤，那麼這個代理的行爲與所轉發請求接收到了一個503（服務不可用）響應相同。
若是傳輸層在代理轉發響應時通知有錯誤產生，那麼它將會中止轉發這個響應。代理不該當由於這個通知而取消任何與這個響應上下文相關聯的還沒有處理的客戶端事務。
若是代理取消了其還沒有處理的客戶端事務，那麼單一的惡意或不正常的客戶端可能會致使全部的事務因其Via頭字段而失敗。
14.9. CANCEL處理
有狀態代理可能會向它在任什麼時候間生成的任何其它請求生成CANCEL。當代理接收到一個匹配的CANCEL請求時，它必須取消任何與這個響應上下文相關的還沒有處理的客戶端事務。
根據INVITE的Expires頭字段中指定的消逝的時間段，有狀態代理能夠爲還沒有處理的INVITE客戶端事務生成CANCEL請求。可是，這一般是不須要的，由於所涉及到的端點會注意對事務的端點發信號。
當CANCEL請求由其自身的服務器事務在有狀態代理中處理時，新的響應上下文不會爲其產生。但代理層會爲處理與這個CANCEL相關的請求的服務器事務搜索其現有的響應上下文。若是找到了匹配的響應上下文，那麼這個元素必須當即向CANCEL請求返回一條200（OK）響應。在這種狀況下，該元素的做用如同第8.2 節中定義的用戶代理服務器。此外，該元素必須爲這個上下文中全部的待處理的客戶端事務生成CANCEL請求。
若是沒有找到響應上下文，那麼這個元素沒有能夠請求應用CANCEL的任何信息。它必須將這個CANCEL請求無狀態轉發（它可能先前已經無狀態轉發了相關的請求）。
14.10. 無狀態代理
當進行無狀態操做時，代理是一個簡單的消息轉發裝置。無狀態操做的多數處理與有狀態操做相同。下面詳細描述了二者的不一樣之處。
無狀態代理沒有事務的任何概念，也沒有用來描述有狀態代理行爲的響應上下文的概念。可是無狀態代理會從傳輸層直接接收消息，包括請求和響應。結果是，無狀態代理不能在其自身重傳消息。可是它們卻會將接收到的全部重傳的消息轉發（它們沒有區分原始請求與重傳請求的能力）。此外，當對無狀態處理一條請求時，元素不能生成其本身的100(Trying)響應或任何其它臨時響應。
無狀態代理必須對請求進行驗證。無狀態代理必須遵循第14.4至第14.5節描述的請求處理步驟，如下狀況除外：無狀態代理必須從目標集合中選擇一個惟一的目標。這個選擇必須只取決於消息中的字段和服務器的時間不變量屬性。特別是每次處理重傳的請求時，必須將其轉發到相同的目的地。並且，CANCEL和非路由ACK請求必須生成與和它們相關的INVITE相同的選擇。
無狀態代理必須遵循第14.6節描述的請求處理步驟，如下狀況除外：
² 跨時空的對惟一分支ID的需求也可應用到無狀態代理中。可是無狀態代理不能簡單地使用隨機數生成器來計算分支ID的第一個組件（如第14.6節第8條所述）。這是由於，請求的重傳須要具備相同的值，而無狀態代理沒法辨別原始請求和重傳請求。所以，每次轉發重傳請求時，使其具備惟一性的分支參數的組件必須相同。因此對無狀態代理而言，分支參數必須做爲在重傳過程當中不變的消息參數的組合功能進行計算。
無狀態代理能夠使用任何它樂意使用的技術來保證其分支ID在事務中的惟一性。可是推薦如下步驟。代理對接收到的響應的頂端Via頭字段中的分支ID進行檢查。若是它以magic cookie開始，那麼出站請求的分支ID的第一個組件可用接收到的分支ID的哈希來計算。不然，分支ID的第一個組件使用所接收的請求的頂端Via、To頭字段中的標記、From頭字段中的標記、Call-ID頭字段、Cseq號（但不是方法）以及Request-URI的哈希來計算。在經過兩個不一樣的事務時，這些字段中的一個會改變。
² 第14.6節指定的全部其它消息轉化都必須使得重傳請求能獲得相同的轉化。特別是，若是代理向Route頭字段插入Record-Route值或將在Record-Route頭字段中加入URI，該代理必須在重傳請求中設置相同的值。至於Via分支參數，這意味着這種轉變的根據必須是時間不變量配置或請求的重傳不變量屬性。
² 無狀態代理將肯定從哪裏轉發請求，如第14.6節第10條對有狀態代理的描述。這個請求將被直接發送到傳輸層，而非通過客戶端事務發送。
因爲無狀態代理必須將重傳的請求轉發到相同的目的地，還要向這些請求中的每一條添加相同的分支參數，因此它只能使用消息自己的信息和時間不變量配置數據來進行計算。若是配置狀態不是時間不變量（例如，若是更新了一個路由表），那麼變化影響到的任何請求可能在至關於變化前或變化後的事務超時窗口的時間間隔中不會被無狀態傳送。在這個間隔中處理受到影響的請求的方法是肯定一種解決方案轉發請求。通常的解決方案是將這些請求有狀態地轉發到事務。
無狀態代理不能對CANCEL請求執行特別的處理。與許多其它請求同樣，它們由上述規則處理。特別是無狀態代理將相同的Route頭字段的處理方法應用到了CANCEL請求中，而無狀態代理也將這種方法應用到了任何其它請求中。
第14.7節描述的響應處理不會應用到具備無狀態行爲的代理上。當響應到達無狀態代理時，該代理必須檢查第一個（頂端）Via頭字段值中的sent-by值。若是這個地址與代理相匹配（這個值與該代理插入到前一個請求中的值相等），那麼這個代理必須從響應中將這個頭字段值刪除，並將結果轉發到下一個Via頭字段值中表示的位置。代理不能添加、修改或刪除消息體。除非另行指定，不然代理不能刪除任何其它頭字段值。若是這個地址與代理不匹配，那麼必須丟棄該消息。
14.11. 代理路由處理總結
在沒有本地策略的狀況下，代理對包含Route頭字段的請求所執行的處理能夠概括爲如下幾個步驟：
1. 代理將對Request-URI進行檢查。若是它表示的是一個該代理所擁有的資源，那麼代理將用運行定位服務的結果來代替它。不然，代理不會對Request-URI進行更改。
2. 代理將對頂端Route頭字段值中的URI進行檢查。若是該URI表示這個代理，那麼代理將把它從Route頭字段中刪除（由於已經遍歷了這個路由節點）。
3. 若是沒有Route頭字段值，代理將把這個請求轉發到頂端Route頭字段值或Request-URI中的URI表示的資源。當代理對此URI應用步驟4中所描述的要求時，代理可肯定要使用的地址、端口和傳輸協議。
若是在請求路徑中沒有遇到嚴格路由的元素，那麼Request-URI將總會表示請求的目標。
15. 事務
SIP是一個事務協議：組件間的交互發生在一系列獨立的消息交換中。具體來講，SIP事務由一個單一的請求和對這個請求的任何響應（包括零或多個臨時響應以及一個或多個最終響應）組成。事務中的請求是INVITE（稱爲INVITE 事務）時，只有最終響應不是2xx響應時這個事務才包括ACK。若是最終響應是2xx，那麼不該將ACK視爲事務的一部分。這種區分的根源在於向UAC傳遞INVITE的全部200（OK）響應很是重要。爲了將這些響應傳遞到UAC，UAS要負責重傳它們，而且UAC要負責用ACK對它們進行確認。因爲這個ACK只是由UAC重傳的，所以能夠有效地將其視爲自身的事務。
事務分爲客戶端與服務器端。客戶端稱爲客戶端事務，服務器端稱爲服務器事務。客戶端事務發送請求，服務器事務發送響應。客戶端事務與服務器事務都是嵌入任何元素中的邏輯功能。具體來講，它們存在於用戶代理和有狀態代理服務器中。在這個實例中，UAC執行客戶端事務，其出站代理執行服務器事務。出站代理還會執行一個客戶端事務，該事務會將請求發送到入站代理的服務器事務。這個入站代理也會執行一個客戶端事務，這個事務將請求發送給UAS 的服務器事務中。如圖 1所示。
圖 1事務關係
無狀態代理不包含客戶端事務或服務器事務。事務存在於一端的UA（或有狀態代理）與另外一端的UA（或有狀態代理）之間。就SIP 事務而言，無狀態事務是透明的。客戶端事務從嵌入客戶端的元素（這個元素稱爲「事務用戶」或TU；它能夠是UA，也能夠是有狀態代理）接收請求，並將請求可靠地傳遞給服務器事務。客戶端事務還負責接收響應並將這些響應傳遞給TU，同時將任何重傳響應或不容許的響應（如對ACK的響應）過濾。此外，在INVITE請求的狀況下，客戶端事務負責爲任何接收2xx響應的最終響應生成ACK請求。
與此類似，服務器事務從傳輸層接收請求並將請求交付給TU。服務器事務會過濾來自網絡的任何重傳請求。服務器事務接受TU 的響應並將它們交付給傳輸層，以在網絡上進行傳輸。在INVITE事務中，它爲任何最終響應（除2xx響應以外）接收ACK請求。
2xx響應及其ACK採用特殊的處理方法。這個響應只能由UAS重傳，而且其ACK 由UAC生成。這種端到端的處理方法是必要的，以便呼叫方知道接收呼叫的用戶集。因爲使用了這種特殊的處理方法，2xx 響應由UA核心進行重傳，而不是事務層。與此類似，UA核心也會爲2xx生成ACK。沿路徑的每一個代理僅轉發INVITE的2xx響應以及相應的ACK。
15.1. 客戶端事務
客戶端事務經過對狀態機的維護來提供其功能。
TU經過一個簡單的接口與客戶端事務進行通訊。當TU想發起一個新事務時，這個接口會建立一個客戶端事務，並把將要發送的SIP請求的目的地的IP地址、端口和傳輸協議傳遞給客戶端。客戶端事務開始執行其狀態機。有效的響應會從客戶端事務上傳到TU。
就TU 傳遞請求的方法而言，有兩種客戶端事務狀態機。其中一種用於處理INVITE請求客戶端事務。這種機器稱INVITE客戶端事務。另外一種用於處理除INVITE和ACK之外的全部請求的客戶端事務 。這種機器稱非INVITE客戶端事務。ACK沒有客戶端事務。若是TU但願發送ACK，那麼它能夠直接將ACK 傳送到傳輸層進行傳輸。
INVITE事務因其擴展的持續時間而與其它方法的事務不一樣。一般地，爲了對INVITE進行響應，須要用戶輸入內容。發送響應所需的長時間的延時同意一個三向握手。另外一方面，其它方法的請求有望迅速完成。因爲非INVITE事務依靠雙向握手，TU應對非INVITE請求當即作出響應。
15.1.1. INVITE客戶端事務
15.1.1.1. INVITE 事務概述
INVITE事務由一個三向握手組成。客戶端事務發送INVITE，服務器事務發送響應，客戶端事務還要發送一個ACK。對不可靠的傳輸（如UDP），客戶端事務會在時間間隔T1後重傳請求，每次重傳後該時間翻倍。T1是對往返時間（RTT）的估計，其缺省值爲500ms。這裏描述的幾乎全部的事務計時器均可以用T1測量，並經過更改T1來調整它們的值。可靠傳輸上的請求不會重傳。接收到一個1xx響應後，任何重傳都中止，客戶端會等待進一步的響應。服務器事務會發送額外的1xx響應，這些1xx響應不會經過服務器事務進行可靠的傳送。服務器事務最終會決定發送一個最終響應。對不可靠的傳輸來講，響應週期性地重傳，而對可靠的傳輸來講，響應則只會發送一次。對客戶端事務接收到的每個最終響應，客戶端事務都會發送一個ACK，其目的是結束響應的重傳。
15.1.1.2. 正式描述
圖 2顯示了INVITE客戶端事務的狀態機。當TU用INVITE請求發起一個新的客戶端事務時，事務必須進入起始狀態，即「正在呼叫中」。客戶端事務必須將請求傳送到傳輸層以進行傳輸。若是使用了不可靠的傳輸，那麼客戶端事務必須啓動值爲T1的計時器A。若是使用了可靠的傳輸，那麼客戶端事務則不該啓動計時器A（計時器A對請求的重傳進行控制）。對於任何傳輸，客戶端事務都必須啓動具備64*T1秒值的計時器B（計時器B 對事務的超時進行控制）。
當計時器A觸發時，客戶端事務必須將請求重傳到傳輸層，而且必須將計時器的值重置爲2*T1。在傳輸層上下文中重傳的正式定義是：取出先前發送給傳輸層的消息，再次將其發送到傳輸層。
當計時器A在2*T1秒後觸發時，必須重傳請求（假定客戶端事務仍然處於這種狀態）。這一過程必須繼續，以便每次傳輸後在翻倍的時間間隔內重傳請求。只有在客戶端事務處於「正在呼叫中」狀態時，才能完成重傳。
T1的缺省值爲500ms。T1是客戶端事務與服務器事務間RTT的估計值。元素能夠在不容許鏈接Internet的關閉的私有網絡中使用較小的T1值（雖然不推薦）。若是事先知道（如在高延遲訪問連接上）RTT較大，那麼推薦將T1的值選得大一些。無論T1的值是什麼，都必須使用重傳的指數退避。
若是當計時器B觸發時客戶端事務仍處於「正在呼叫中」狀態，那麼客戶端事務應當通知TU發生了超時。客戶端事務不能生成ACK。64*T1的值與在不可靠傳輸下發送七個請求所需的時間總和相等。
若是客戶端事務處於「正在呼叫中」狀態時接收到一個臨時響應，那麼它將轉換到「進行」狀態。在「進行」狀態中，客戶端事務再也不重傳請求。並且，臨時響應必須傳送到TU。當客戶端事務處於「進行」狀態時，任何臨時響應都必須上傳到TU。
當處於「正在呼叫中」狀態或「進行」狀態時，接收到狀態碼爲300－699的響應會致使客戶端事務轉換到「完成」狀態。客戶端事務必須將接收到的響應上傳到TU，還必須生成一個ACK 請求，即便在傳輸是可靠的狀況下也是如此（第15.1.1 節給出了從響應構造ACK的指導原則），而後將ACK 請求傳送到傳輸層進行傳輸。ACK 發送到的地址、端口和傳輸協議必須與原始請求發送到的地址、端口和傳輸協議相同。客戶端事務應當在進入「完成」狀態時啓動計時器D，對不可靠傳輸它的值至少應爲32秒，而對可靠的傳輸其值應爲零。計時器D反映了當使用不可靠傳輸時服務器事務能夠停留在「完成」狀態的時間總量。這與INVITE服務器事務中的計時器H（其缺省值爲64*T1）相等。可是，客戶端事務不知道服務器事務使用的T1值，所以要使用32s這個絕對最小值，而不是根據計時器D來設定T1值。
在「完成」狀態時，接收到的最終響應的任何重傳都會致使向傳輸層重傳ACK，以進行重傳，可是不能將新接收到的響應上傳到TU。重傳響應定義爲：根據第15.1.3 節的規則與同一客戶端事務相匹配的任何響應。
若是計時器D在客戶端事務處於「完成」狀態時觸發，那麼客戶端事務必須轉換到終止狀態。
圖 2 INVITE客戶端事務
當處於「正在呼叫中」或「進行」狀態時，接收2xx響應一定致使客戶端事務進入「終止」狀態，而且響應必需要上傳到TU。對這個響應的處理取決於TU是代理核心仍是UAC核心。UAC核心將爲這個響應生成ACK，而代理核心則老是將200（OK）轉發到上游。因爲對200（OK）的處理並非發生在事務層，所以代理與UAC會對它有不一樣的處理。
在客戶端事務進入「終止」狀態時它自己必須被銷燬。實際上這對保證準確的操做是必須的。緣由是對INVITE的2xx響應的處理是不一樣的：每一個響應都是由代理轉發的，而且在UAC中的ACK處理也是不一樣的。所以，每一個2xx都須要傳送到代理核心（以即可以轉發）和UAC核心（以便它能夠獲得確認）。在事務層中沒有進行處理操做。在傳輸接收到響應的任什麼時候候，若是傳輸層（使用第15.1.3 節中的規則）沒有找到匹配的客戶端事務，響應將直接傳送到UAC核心。因爲第一個2xx已經銷燬了匹配的客戶端事務，後續的2xx會發現沒有匹配的客戶端事務，因此纔會直接傳送到核心。
15.1.1.3. ACK請求的構造
這一章指定了在客戶端事務中發送的ACK請求的構造。爲2xx生成ACK的UAC核心必須遵循第9 章描述的規則。
由客戶端事務構造的ACK請求必須包含Call-ID、From 和Request-URI的值，這些值與客戶端事務傳送到傳輸層的請求（稱爲「原始請求」）中的那些頭字段的值相等。ACK中的To頭字段必須與正在被確認的響應中的To頭字段相等，但因爲它添加了標記參數，所以它經常與原始請求中的To頭字段不一樣。ACK必須包含一個單一的Via頭字段，它必須與原始請求的頂端Via頭字段值相等。ACK中的Cseq頭字段包含的序列號值必須與原先請求中的相同，可是方法參數必須與「ACK」相等。
若是其響應正在被確認的INVITE請求有Route頭字段，那麼這些頭字段必須在ACK中出現。這是爲了確保能夠經過任何下游無狀態代理正確地路由ACK。
雖然任何請求均可以包含一個消息體，可是ACK中的消息體比較特殊，由於若是沒有理解消息體就沒法拒絕請求。所以，不推薦在非2xx的ACK中放置消息體，可是若是已經放置了消息體，假定INVITE的響應不是415，那麼消息體類型要限制在任何在INVITE中出現的類型。若是INVITE的響應是415，那麼ACK中的消息體能夠是415中Accept頭字段中列出的任何類型。
例如，請考慮如下請求：
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=88sja8x
Max-Forwards: 70
Call-ID: 987asjd97y7atg
CSeq: 986759 INVITE
該請求的非2xx 最終響應的ACK 請求以下所示:
ACK sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
To: Bob <sip:bob@biloxi.com>;tag=99sa0xk
From: Alice <sip:alice@atlanta.com>;tag=88sja8x
Max-Forwards: 70
Call-ID: 987asjd97y7atg
CSeq: 986759 ACK
15.1.2. 非INVITE 客戶端事務
15.1.2.1. 非INVITE事務概述
非INVITE事務不使用ACK。它們是簡單的請求--響應交互。對於不可靠的傳輸來講，請求在一個時間間隔（時間間隔起始值爲T1，在到T2前該時間間隔每次翻倍）內進行重傳。若是接收到一個臨時響應，那麼對不可靠傳輸而言，將繼續重傳（但時間間隔在T2內）。服務器事務只有在接收到重傳請求時，纔會重傳它發送的最後一個響應，這個響應能夠是臨時響應，也能夠是最終響應。這就是即便在臨時響應以後，仍需繼續重傳請求的緣由：它們是爲了確保可靠的傳輸最終響應。
與INVITE事務不一樣，非INVITE事務對2xx響應並不作特殊的處理。結果是，只向UAC傳送了非INVITE的一個2xx響應。
15.1.2.2. 正式描述
圖 3 非INVITE客戶端事務
圖 3顯示了非INVITE客戶端事務的狀態機。它與INVITE狀態機很是類似。
當TU用請求發起新的客戶端事務時，事務會進入「嘗試」狀態。進入這個狀態時，客戶端事務應當將計時器F設置爲在64*T1秒內觸發。這個請求必須傳送到傳輸層進行傳輸。若是使用的是不可靠的傳輸，那麼客戶端事務必須將計時器E設置爲在T1秒以內觸發。若是計時器E在客戶端事務仍處於嘗試狀態就觸發，那麼計時器將會被重置，可是此次重置的值爲MIN（2*T1，T2）。當計時器再一次觸發時，它會被重置爲MIN（4*T1，T2）。這一過程將會繼續，以便在一個以指數遞增的時間間隔（最大值爲T2）內發生重傳。T2的缺省值爲4秒，若是服務器事務未當即響應的話，T2表明非INVITE服務器事務將對請求發出響應所用的時間總和。對於T1和T2的缺省值來講，這將會產生500ms、1s、2s、4s、4s、4s的時間間隔。
若是計時器F在客戶端事務仍處於「嘗試」狀態時觸發，那麼客戶端事務應當向TU報告超時，而後應進入「終止」狀態。若是在「嘗試」狀態下接收到了一個臨時響應，那麼這個響應必須傳送到TU，而後客戶端事務應轉換到「進行」狀態。若是在「嘗試」狀態接收到一個最終響應（狀態碼爲200－699），那麼這個響應必需要傳送到TU，客戶端事務則必須轉換到「完成」狀態。
若是計時器E在客戶端事務處於「進行」狀態時觸發，那麼請求必須傳送到傳輸層進行重傳，計時器E的值也必須重置爲T2秒。若是計時器F在「進行」狀態時觸發， TU必須獲得超時通知，而且客戶端事務必須轉換到終止狀態。若是在「進行」狀態時接收到一個最終響應（狀態碼爲200－699），那麼這個響應必需要傳送到TU，而客戶端事務則必須轉換到「完成」狀態。
一旦客戶端事務進入「完成」狀態，對不可靠傳輸，它必須將計時器K設置在T4秒以內觸發；對可靠傳輸，計時器應設置爲零。「完成」狀態的存在是爲了對可能接收到的任何額外重傳響應起到緩衝做用（這也是客戶端事務只對於不可靠的傳輸才保留的緣由）。T4 表示網絡清除客戶端事務和服務器事務間消息所需的時間總和。T4的缺省值爲5s。當響應使用第15.1.3 節中指定的規則與同一事務匹配時，它即是重傳響應。若是計時器K在這個狀態觸發，那麼客戶端事務則必須轉換到「終止」狀態。
一旦事務處於終止狀態，必須當即銷燬它。
15.1.3. 將響應與客戶端事務匹配
當客戶端的傳輸層接收到響應時，它必須肯定哪個客戶端事務來處理這個響應，以進行第15.1.1節和第15.1.2節所描述的處理。爲此，須要使用頂端Via頭字段中的分支參數。在兩種狀況下響應會與客戶端事務匹配：
1. 響應在頂端Via頭字段中的分支參數值與建立事務的請求的頂端Via頭字段的分支參數值相同；
2. Cseq頭字段中的方法參數與建立事務的請求的方法匹配。因爲CANCEL請求組成了共享分支參數值的不一樣事務，所以須要這個方法。
若是請求經過多播發送，那麼它可能會從不一樣的服務器生成多個響應。這些響應在頂部Via中有相同的分支參數值，但在To標記中它們的分支參數值卻不一樣。接收到的第一個響應將會使用上面的規則，而其它響應將視爲重傳響應。這並不是出現了錯誤；多播SIP只提供根本的「single-hop-discovery-like」服務，這個服務只限於處理單一的響應。
15.1.4. 處理傳輸錯誤
當客戶端事務向傳輸層發送請求時，若是傳輸層發生錯誤，能夠遵循如下步驟。
客戶端事務應當通知TU發生了傳輸錯誤，並直接轉換到「終止」狀態。TU將處理錯誤轉移機制。
15.2. 服務器事務
服務器事務負責將請求傳遞到TU以及對響應進行可靠的傳輸。它經過狀態機來完成這些任務。當收到請求時，而且請求須要事務處理時（實際狀況並不是老是如此），核心建立服務器事務。
與客戶端事務相同，服務器事務的狀態機取決於接收到的請求是不是INVITE 請求。
15.2.1. INVITE 服務器事務
圖 4是INVITE 服務器事務的狀態圖。
圖 4 INVITE服務器事務
當爲請求構造服務器事務時，服務器事務便進入了「進行」狀態。服務器事務必須生成一個100(Trying)響應，除非它知道TU將在200ms內生成一個臨時或最終響應，在這種狀況下，它可能會生成一個100(Trying)響應。爲了不網絡擁塞，須要臨時響應迅速結束重傳請求。除了把在響應的To頭字段中插入標記（當請求的To 頭字段中沒有標記時）這一點從MAY降爲SHOULD NOT之外，100(Trying)響應是根據第5.2.6節的步驟構造的。這個請求必須傳送到TU。
TU將任何數量的臨時響應傳送到服務器事務。只要服務器事務處於「進行」狀態，全部這些響應都要傳送到傳輸層進行傳輸。這些響應不是由事務層可靠發送的（它們不是由事務層重傳的），所以不會致使服務器事務的狀態改變。若是在「進行」狀態中收到了重傳請求，那麼TU 接收到的最新的臨時響應必需要傳送到傳輸層以進行重傳。若是一個請求根據第15.2.3 節的規則與同一服務器事務相匹配，那麼這個請求即是重傳請求。
當處於「進行」狀態時，若是TU將一個2xx響應傳送到服務器事務，那麼服務器事務必須將這個響應傳送到傳輸層進行傳輸。2xx響應不是由服務器事務重傳的，而是由TU重傳的。而後服務器事務必須轉換到「終止」狀態。
當處於「進行」狀態時，若是TU向服務器事務傳送一個狀態碼爲300－699的響應，那麼這個響應必需要傳送到傳輸層以進行傳輸，而且狀態機必須進入「完成」狀態。對於不可靠的傳輸來講，要將計時器G設置爲在T1秒內觸發，而對於可靠的傳輸則無需設置觸發時間。
在RFC 2543中，即便對於可靠的傳輸，響應也老是要重傳的。本規範在這一點上對RFC 2543進行了改動。
當進入「完成」狀態時，對全部的傳輸，計時器H必須設置爲在64*T1秒觸發。計時器H肯定服務器事務什麼時候再也不重傳響應。它的值應與計時器B相同，等於客戶端事務繼續重發請求的時間總和。若是計時器G觸發，那麼響應便會再次發送到傳輸層進行重傳，計時器G設置爲在MIN（2*T1，T2）秒內觸發。從這個時間開始，當計時器G觸發時，響應便會再次傳送到傳輸層進行傳輸，而計時器G的值將會重置爲先前的兩倍，直到值超過T2，此時，應將計時器G的值重置爲T2。這與非INVITE客戶端事務處於「嘗試」狀態時對請求進行重傳的行爲一模一樣。此外，當處於「完成」狀態時，若是接收到重傳請求，那麼服務器應當將響應傳送到傳輸層進行重傳。
若是服務器事務在「完成」狀態時接收到ACK，那麼它必須轉換到「確認」狀態。因爲在這個狀態能夠忽略計時器G，所以，全部的響應都將中止重傳。
若是在「完成」狀態中計時器H觸發，這代表服務器事務從未接收到ACK。在這種狀況下，服務器事務必須轉換到「終止」狀態，而且必須向TU 指明發生了事務錯誤。
「確認」狀態是爲了接收任何到達的附加的ACK消息，該消息是由重傳的最終響應觸發的。當進入這種狀態時，對於不可靠傳輸計時器I設置爲在T4秒內觸發；而對於可靠傳輸則設置爲零。計時器I一旦觸發，服務器必須轉換到「終止」狀態。
一旦事務處於「終止」狀態，必需要當即銷燬它。與客戶端事務類似，這是爲了確保INVITE的2xx響應的可靠性。
15.2.2. 非INVITE 服務器事務
圖 5給出了非INVITE 服務器事務的狀態機。
圖 5 非INVITE服務器事務
這個狀態機在「嘗試」狀態時初始化，初始化時會向狀態機發送一個除INVITE或ACK以外的請求。這個請求將上傳到TU。一旦處於「嘗試」狀態，任何進一步的重傳請求都會被丟棄。若是請求使用第15.2.3節中的規則與同一服務器事務相匹配，那麼這個請求即是重傳請求。當處於「嘗試」狀態時，若是TU將一個臨時響應傳送到了服務器事務，那麼服務器事務必須進入「進行」狀態。這個響應必需要傳送到傳輸層傳輸。在「進行」狀態時從TU接收到的任何進一步的臨時響應都必須傳送到傳輸層進行傳輸。倘若在「進行」狀態接收到重傳請求，那麼最新發送的臨時響應必須傳送到傳輸層重傳。若是在「進行」狀態中TU將最終響應（狀態碼爲200－699）傳送到服務器，那麼事務必須進入「完成」狀態，這個響應則必須傳送到傳輸層進行傳輸。
當服務器事務進入「完成」狀態時，對不可靠傳輸，它必須將計時器J設置爲在64*T1秒內觸發；對可靠傳輸，設置爲零秒觸發。當處於「完成」狀態時，在接收到重傳響應的任什麼時候候，服務器事務都必須將最終響應傳送到傳輸層重傳。在「完成」狀態時，任何由TU傳送到服務器事務的其它最終響應都必須被丟棄。服務器事務將保持這種狀態，直到計時器J觸發，這時服務器事務必須轉換到「終止」狀態。
當服務器事務進入「終止」狀態時，必需要銷燬它。
15.2.3. 將請求與服務器事務匹配
當服務器從網絡接收到請求時，該請求必須與現有的事務相匹配。匹配按如下方式進行：首先要檢查請求頂端Via頭字段中的分支參數。若是有分支參數，而且以magic cookie 「z9Hg4BK」開頭，那麼這個請求即是由符合本規範的客戶端事務生成的。所以，客戶端發送的全部事務中的各個分支參數都應當不一樣。若是知足如下條件，則請求與事務相匹配：
1. 請求中的分支參數與建立事務的請求的頂端Via頭字段中的分支參數相等；
2. 請求的頂端Via頭字段中的sent-by值與建立事務的請求的頂端Via頭字段中的sent-by值相等；
3. 請求的方法與建立事務的方法相同（除ACK之外，它的建立事務的請求方法爲INVITE）。
以上匹配規則適用於INVITE事務和非INVITE事務。
Sent-by值是做爲匹配過程的一部分使用的，由於不一樣客戶端可能會對分支參數進行意外或惡意的複製。
若是頂端Via 字段中沒有分支參數，或者分支參數不包含magic cookie，那麼能夠使用如下步驟。這些步驟用來處理與聽從RFC 2543規範的實現的向後兼容問題。
若是一個INVITE請求的Request-URI、To標記、From標記、Call-ID、Cseq以及頂端Via頭字段與建立事務的INVITE請求的對應內容相匹配，那麼它與這個事務是匹配的。在這種狀況下，INVITE是建立這個事務的原始請求的重傳請求。若是ACK請求的Request-URI、From標記、Call-ID、Cseq 號（不是方法）以及頂端Via頭字段與建立事務的INVITE請求的對應內容相匹配，而且這個ACK的To標記與服務器事務發送的響應的To標記相匹配，那麼這個ACK請求就與這個事務相匹配。匹配是根據爲每一個頭字段定義的匹配規則進行的。在ACK匹配過程當中在To頭字段中包括一個標記有助於區分2xx的ACK與代理上其它響應的ACK，代理有可能將兩種響應一塊兒轉發（在異常狀況下，這是有可能發生的。具體說來，當代理分發一個請求，而後崩潰，響應可能會傳遞到另外一個代理，這個代理可能會終止向上遊轉發多個響應）。能夠認爲，若是一個ACK請求與和前一個ACK匹配的INVITE事務相匹配，那麼它是先前ACK請求的重傳。
對於全部其它請求方法而言，若是一個請求的Request-URI、To標記、From標記、Call-ID、Cseq（包括方法）以及頂端Via頭字段與建立事務的請求的對應內容相匹配的話，那麼該請求便與這個事務相匹配。匹配是根據爲每一個頭字段定義的匹配規則進行的。當一個非INVITE請求與一個現有的事務相匹配時，它是建立這個事務的請求的重傳。
因爲匹配規則包括Request-URI，所以服務器沒法將響應與事務相匹配。當TU將一個響應傳送到服務器事務時，它必須將其傳遞到這個響應指向的特定的服務器事務。
15.2.4. 處理傳輸錯誤
在服務器端的事務實例將相應的響應發到傳輸層後，在傳輸層傳輸失敗的狀況下，可進行以下處理：
首先，能夠選擇將響應發往另外一個做爲備份的實體。
若是上述嘗試都傳輸失敗，事務層應該將失敗通知給TU，並將相應的事務實例的狀態遷移爲「終止」。
16. 傳輸
傳輸層負責經過網絡傳送請求和響應，傳輸分爲面向鏈接傳輸和非面向鏈接傳輸，當傳輸爲面向鏈接時，還要肯定請求或者響應可用的鏈接。
傳輸層能夠管理永久鏈接，這些鏈接使用的傳輸協議有TCP和SCTP，或者基於TCP和SCTP的TLS，包括那些開放的傳輸層的協議，這些鏈接還包括客戶機或者服務器傳輸層的開放鏈接，客戶機和服務器傳輸層可共同使用該鏈接，能夠經過該鏈接的遠端地址、端口、傳輸協議所組成的三元組來檢索該鏈接，若是一個鏈接開放，該索引設成目的地IP地址、端口和傳輸協議的三元組。若是一個鏈接被傳輸層所接受，該索引設成源IP地址、端口和傳輸協議的三元組。因爲源端口一般是暫時的，因此傳輸層所接受的鏈接通常不會從新使用。因此一般兩個對等代理服務器在使用面向鏈接傳輸協議時，會用不用兩個鏈接，用於各自方向發起的事務。
本標準建議，在最後一個消息經過以後，該鏈接仍須要開放一段時間。該時間段至少等於實體將一個事務從實例進行到終止狀態所用時間的最大值。這樣，事務能夠在其發起的鏈接完成（例如請求、響應、INVITE、用於非2xx響應的ACK）。該時間段的值至少爲64*T1。然而若是一個實體使用一個更大的定時器C，這個持續時間將更長。
全部的SIP實體都必須能實現UDP和TCP。SIP實體也能夠使用其餘的協議。
16.1. 客戶端
16.1.1. 發送請求
傳輸層的客戶端負責發送請求並接受響應。傳輸層的用戶將請求、IP地址、端口、傳輸協議以及組播目的地的TTL傳遞到客戶機傳輸層。
若是一個請求在小於200字節或者大於1300字節的路徑MTU中，而該MTU值未知，那麼該請求必須使用RFC 2914中規定的擁塞控制協議，例如TCP協議。若是這與頂端Via中所指定的傳輸協議不一樣，那麼頂端Via的值須要修改。這有效的防止了使用UDP會形成的消息碎片，而且爲大塊的消息提供了擁塞控制。對於UDP來講可以處理最大數據包就是65535字節幷包括IP和UDP字頭。
消息尺寸和MTU之間的200字節的「緩衝區」適應了SIP中響應消息通常比請求大的狀況。例如，能夠在INVITE響應中附加Record-Route頭字段值。有了這個額外的緩衝區，響應能夠比請求大170字節，而在IPV4中沒必要被分塊（假設沒有IPSec時，IP/UDP消耗大約30字節）。當路徑MTU未知時，基於以太網的MTU是1500字節來將MTU設爲1300字節。
若是一個實體因爲消息大小的緣故才須要經過TCP發送某請求，不然該請求能夠經過UDP傳輸，若是創建鏈接時引發下面兩種狀況：ICMP協議不支持，和從新創建TCP鏈接，此時該實體就應該使用UDP從新發送請求。
向組播地址發送請求的客戶機必須在Via頭字段值中附加「maddr」參數指明目的地組播地址，對於IPv4來講應該增長一個值爲1的「ttl」參數。IPv6的組播的內容不在本部分範圍以內。這個規定對SIP組播產生了限制。它的基本功能是「單跳發現（single-hop-discovery-like）」業務，也就是向一組同類的服務器發送請求，可是隻須要其中一個服務器處理該請求便可。註冊時能夠使用該功能。客戶機事務層應該接收第一個請求，其他的由於包含一樣的Via分支標識符而被視爲重發。
發送請求以前，客戶端事務層必須在Via頭字段中插入一個「sent-by」字段。該字段包括一個IP地址或者是主機名和端口。本部分建議使用FQDN（全資格域名）方式。該字段用於如下狀況下發送請求。若是沒有規定端口，根據傳輸協議不一樣而取不一樣的端口缺乏值，UDP取5060而TCP和SCTP取5061.
在進行可先傳輸時，應在收到請求的鏈接上發送響應。所以，客戶端傳輸層必須作準備在同一個鏈接上接收響應。發生錯誤時，服務器能夠創建一個新鏈接發送響應。在這種狀況下，傳輸層也必須在源IP地址上引入一個鏈接，從源IP地址和「sent-by」字段中所指的端口發送請求。它還必須準備在服務器端選擇的地址和端口上引入一個鏈接。
在不可靠單播傳輸時，客戶端傳輸層必須準備在源IP地址上接收響應，源IP地址就是發送請求的地址，端口號爲「sent-by」字段中的值。另外，與可先傳輸同樣，某些特定狀況下，響應也將被傳輸到其餘地方。
在組播的狀況下，客戶端傳輸層必須做爲發送請求的組播羣中的一員在與發送請求相同的組播羣和端口上接收響應。
若是一個原有的鏈接對於某請求的目的IP地址、端口和傳輸協議開放，則本部分建議這個鏈接用於發送請求而另一個鏈接也能夠開放並使用。
若是某請求使用組播發送，它就會被送往一組用戶所提供的地址、端口和TTL。若是某請求使用不可靠單播傳輸方式發送，它應付被送往傳輸用戶所提供的IP地址和端口。
16.1.2. 接收響應
客戶機傳輸層收到響應後須要檢查頂端Via的值。若是「sent-by」參數中的值與客戶端傳輸層插入到請求中的值不同，該響應就必須被丟棄。
若是存在一些客戶端事務，客戶機傳輸層將在原有的事務中查找與該響應所匹配的事務。若是找到匹配事務，就必須將該響應斷定以對應的事務中處理。反之該響應就必須被送到內核服務器作進一步處理，根據內核服務器的不一樣，對這些響應有不一樣的處理。
16.2. 服務器
16.2.1. 接收請求
服務器能夠經過DNS來搜索對方服務器，搜索結果以SIP或者SIPS URI形式給出，服務器應該經過搜索結果中的任何IP地址、端口和傳輸協議來接收請求。另外，必須將一個URI放到REGISTER請求或者重定向響應中的Contact字段，或者放在請求或者響應中的Record-Route頭字段中，URI也能夠用放到網頁或者名片上的形式給出。本部分建議，服務器在公共接口上接受請求是應用不用默認的端口值（TCP和UDP是5060，而TCP上的TLS是5061），私有網絡或者同一個主機上運行多個服務器的狀況除外。由於若是消息太大則必須使用TCP而不能用UDP傳輸，因此任何使用UDP端口和接口的服務器必須可以在TCP上使用一樣的端口和接口。反之，服務器沒必要由於使用了TCP的一個特定端口和接口就要求在UDP狀況下使用同一特定端口和接口。服務器傳輸層經過任何傳輸協議收到請求後，必須檢查Via頭字段頂端的「sent-by」參數的值。若是「sent-by」參數的主機位置包含一個域名或者包含一個不一樣於數據包源地址的IP地址，服務器必須在Via頭字段中添加一個「received」參數。該參數必須包括所收數據包的源地址，這樣，服務器傳輸層就能夠將響應發送到發出請求的源IP地址。
而後，服務器傳輸層將在服務器端事務中尋找與請求相匹配的事務。若是找到了對應的服務器事務，就將請求送到這個事務來處理；若是沒有找到相匹配的事務，就將請求送到內核服務器，並創建一個新的服務器端事務來處理它。若是UAS內核服務器對INVITE請求發出2xx服務器事務即終結，這就意味着若是ACK到達，將沒有相匹配的服務器事務。基於上述原則，ACK就被送往UAS內核進行處理。
16.2.2. 發送響應
服務器傳輸層使用Via字段的頂端值來決定將響應發送目的。具體過程以下：
² 若是「sent-protocol」爲可靠的傳輸協議，如TCP或者SCTP，或者基於TCP或SCTP的TLS且現有的鏈接仍然可用，則必須使用該鏈接傳輸響應到創建該事務的初始請求的源地址。這就要求服務器傳輸層保持服務器端事務和傳輸鏈接的關聯。若是該鏈接不可用，服務器應與「received」參數中的IP地址之間開放一個新鏈接，並使用「sent-by」中的端口值，若是沒有指定端口就使用該傳輸協議的缺省端口值。若是該鏈接失敗，服務器應該根據RFC 3263中的程序肯定所要開放的鏈接的IP地址和端口並向其發送響應消息。
² 不然，若是Via字段包含「maddr」參數，就必須將響應轉發到參數中所列的地址，所用端口爲「sent-by」中的指定端口值，若是沒有指定，端口值爲5060.若是地址爲組播地址，就應該使用「ttl」參數中指標TTL值來發送響應，若是該參數不存在，TTL的值爲1.
² 不可靠的單播傳輸的狀況下，若是Via含有「received」參數，則響應就被送往「received」中指定的地址，所用端口爲「sent-by」中指定端口值，若是沒有指定，端口值就爲5060。若是傳輸失敗，例如獲得ICMP「端口不可達」響應，就應該使用RFC 3263中的Section 5的程序來肯定響應發送的目的。
² 不然，若是沒有接收者標籤，就應該將響應送到「sent-by」中指定的地址
16.3. 數據幀
面向消息傳輸的狀況下（例如UDP），若是消息包含Content-Length頭字段，則消息體則應爲該字段所指示的長度。越長的數據包必須被丟棄。若是傳輸的數據包在消息體結束以前結束，則產生錯誤。若是消息是一個響應，則它必須被丟棄。若是消息爲一個請求，實體就應該產生一個400(Bad Request)響應。若是該消息沒有Content-Length頭字段，那麼消息體長度就認爲是所傳輸的數據包的長度。
面向流傳輸的狀況下（例如TCP），Content-Length頭字段指示消息體的大小，面向流傳輸的狀況下必須使用Content-Length頭字段。
16.4. 錯誤處理
若是傳輸的用戶經過不可靠傳輸協議傳輸消息，併產生ICMP錯誤，則按照ICMP錯誤的類型肯定處理方法。若是爲主機、網絡、端口或者協議不可用的錯誤或者參數錯誤，應由傳輸層通知用戶。源終止和TTL超時的ICMP錯誤都將忽略。
若是傳輸的用戶要求經過可靠傳輸協議傳輸消息且鏈接失敗，那麼傳輸層應該通知用戶。
17. 普通的消息成分
17.1. SIP和SIPS URI
SIP和SIPS URI用於指示一個通訊資源。像全部的URI同樣，SIP或SIPS URI也能夠用於網頁、電子郵件消息和出版物。其中包含了與該通訊資源創建並維持會話所須要的信息。
通訊資源的例子以下：
在線業務的用戶
多方電話的狀況
消息系統的語音信箱
網關業務的PSTN號碼
某組織裏的一個組（例如「銷售組」或者「技術支持」）
SIPS URI所指示的爲安全的資源，即UAC與該URI所屬的域之間使用TLS傳輸。該資源與某個用戶間通訊是安全的，且所使用安全機制由該域的本地策略所決定。若是但願獲得安全的通訊，任何由SIP URI所指標的資源在改變其URI方案以後能夠升級至SIPS URI。
17.1.1. SIP URI的構成
「SIP:」和「SIPS」的方案參見RFC 2396。格式相似於郵件URL，分別規定SIP頭字段和SIP消息體。這就能夠在網頁上或者電子郵件消息裏使用URI規定會話的主題、媒體類型和緊急程度等。SIP URI通用格式爲：
sip:user:password@host:port;uri-parameters?headers
SIPS URI的格式也是同樣的，但方案是SIPS而不是SIP。
以上符號定義以下：
User：指定被尋址的主機資源的標識符。「host」一般用來指示一個域。URI中「userinfo」由user和password以及@符號組成，若是目的主機沒有用戶或者主機自己就是被指定的資源，則userinfo部分爲可選。若是有@符號，那麼user字段就不可爲空，若是被尋址的主機能夠處理電話號碼，例如，IP電話網關，其telephone-subscriber字段就能夠用來做爲user字段，SIP URI中telephone-subscriber的編碼方式參見本規範
Password：password與user相關，SIP和SIPS URI的語法中容許該字段存在。可是不建議使用該字段。由於鑑權信息以明碼文本的形式經過，因此幾乎全部的狀況下都不安全。Password只是user部分的延伸，本規範不對其特殊的定義，能夠把「user:password」部分看做一個字符串。
Host：指定SIP資源。Host部分包含一個FQDN或者是一個數值表示的IPv4或者IPv6地址。建議該字段使用FQDN方式。
Port：指定請求要被髮送的端口。
URI parameter：包括transport，maddr，ttl，user，method以及lr參數。這些參數用於以URI構建一個請求，它們附加在hostport以後，以分號隔開，其格式爲：
Parameter-name=parameter-value
雖然一個URI能夠有若干個參數，可是一個參數名最多隻能出現一次。
Transport：用來肯定發送SIP的傳送機制，見RFC 3263的規定。SIP能夠任何網絡傳送協議。各類協議的參數名的定義參數UDP、TCP和SCTP的相關規範。
Maddr：用於指定用戶所要聯繫的服務器地址，它優先於host字段的地址。Maddr存在時，URI中的port和transport字段都用於maddr所指定的地址。爲了發送請求，須要得到目的地址的地址、端口以及傳輸協議。Maddr字段是鬆散源路由的一個簡單的形式。它容許URI指定一個到達目的地時必須經過的代理服務器。本規範不建議在該路徑上繼續使用maddr參數，而是應該使用文件中講的另外一種路由機制來預先創建一個路徑組，它含有一個描述所要經過的節點的完整URI。
Ttl：UDP組播數據包的生存時間值，只能用於maddr爲組播地址而且傳送協議是UDP的狀況下，例如：肯定對於alice@altanta.com的呼叫，使用ttl值爲15，組播地址爲239.255.255.1，URI形式以下：
sip:alice@altanta.com;maddr=239.255.255.1;ttl=15
這組有效的telephone-subscriber字符串是有效的user字符串的一個子集。URI中的user參數用來區分那些電話號碼和user名不一樣的URI。若是user字符串包含一個格式爲telphone-subscriber的電話號碼，則應該存在「phone」這個值。即便沒有這個參數，若是本地用戶名的規定容許，SIP URI也能夠把@以前的部分看作一個電話號碼。
Mehtod：規定由URI構建SIP請求的方法，由方法參數指定。
Lr：該參數存在的狀況下，用來指示負責該資源的實體實施路由機制。該參數能夠存在於URI代理服務器中的Record-Route頭字段，也能夠存在於預先創建的路由組URI中。一個基於URI發送的請求若是沒有lr參數，由接收實體就被認爲執行的嚴格路由機制並重定消息格式來保存Request-URI中原有信息。既然URI參數機制是可擴展的，SIP實體就必須忽略其不理解的URI參數。
Headers：該字段位於由URI構建的請求消息中。SIP請求的的Headers字段能夠在URI中用「?」來指定。Header的名字和值是由&分開的hname=hvalue對，當hname爲「body」時代表相關的hvalue是SIP請求的消息體。
表 1 SIP URI中各成分的使用及其缺省值
|
|
default |
Req.-URI |
To |
From |
Contact |
R-R/Route |
external |
| User |
-- |
o |
o |
o |
o |
o |
o |
| Password |
-- |
o |
o |
o |
o |
o |
o |
| Host |
-- |
m |
m |
m |
m |
m |
m |
| Port |
(1) |
o |
- |
- |
o |
o |
o |
| User-param |
ip |
o |
o |
o |
o |
o |
o |
| Method |
INVITE |
- |
- |
- |
- |
- |
o |
| Maddr-param |
-- |
o |
- |
- |
o |
o |
o |
| Ttl-param |
-- |
o |
- |
- |
- |
o |
o |
| Transp.-param |
UDP |
o |
- |
- |
o |
o |
o |
| Lr-param |
-- |
o |
- |
- |
- |
o |
o |
| Other-param |
-- |
o |
o |
o |
o |
o |
o |
| headers |
-- |
- |
- |
- |
o |
- |
o |
(1)：缺省的port值與傳送協議有關。Sip：使用UDP、TCP、或者SCTP時爲5060。Sip：使用基於TCP的TLS是5061。
表1總結了在URI出如今不一樣的上下文中時SIP和SIPS URI各個組成部分的用法。External這一列講述了URI位於SIP消息體以外的狀況，例如網頁上或者商業名片上。標註「m」表示強制使用，標註「o」表示可選，標註「-」表示禁止。若是URI有禁止項存在，SIP實體處理到它的時候應該忽略這些項。第二列指出若是一個可選項沒有出現時的缺省值。「--」指出這項或者不可選或者沒有缺省值。
Contanct頭字段中的URI根據字段出現的上下文的不一樣而有不一樣的限制。一組適用於創建和維持對話的消息（INVITE和200響應），另一組適應於註冊和重定向消息（REGISTER，對它的200（OK）響應以及對於任何方法的3xx響應）。
17.1.2. 字符轉義的要求
在SIP URI中，定義一組須要轉義的字符時，就要遵循RFC 2396中的要求使用「「%」HEX HEX」機制進行轉義。RFC 2396規定：任何給定的URI組成部分中所保留的字符集實際是由該組成部分所定義的。通常狀況下，若是一個URI的字符使用轉義的US-ASCⅡ碼所代替後語言被改變，這個字符就應該保留。US-ASCⅡ字符以外的字符，例如空格、控制符還有URI中的分隔符都必須被轉義。URI不能夠包含未轉義的空格和控制符。
對於每一個部分來講，有效的BNF的擴展定義了能夠不用轉義的字符。除此之外的字符都要被轉義。例如「@」不是user成分的字符，所以user爲j@s0n時，至少@符須要編碼爲「j%40s0n」。擴展的hname和hvalue符號代表所示的URI頭字段名和值中保留的字符必須被轉義。
User部分的telephone-subscirber子集的轉義有特殊的要求。如RFC 2806所述，telephone-subscriber未保留的字符集中包含許多不一樣的語法形式的字符，當使用SIP URI時，這些字符須要被轉義，任何telephone-subscriber中出現的字符若是沒有出如今BNF的擴展定義中則必須被轉義。
SIP和SIPS URI中的host部分不容許字符轉義（%字符在擴展中無效）。未來國際化域定案以後這個規定可能會發生改變，如今的具體實現中，不能夠經過將所收到的host中的轉義字符理解爲未轉義的字面的意思來提升魯棒性。可是若是要求知足IDN的要求的話，未來的狀況可能徹底不一樣。
17.1.3. SIP URI舉例
sip:alice@atlanta.com
sip:alice:secretword@atlanta.com;transport=tcp
sips:alice@atlanta.com?subject=project%20x&priority=urgent
sip:+1-212-555-1212:1234@gateway.com;user=phone
sips:1212@gateway.com
sip:alice@192.0.2.4
sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com
sip:alice;day=tuesday@atlanta.com
最後一個例子的user字段值爲「alice;day=tuesday」。轉義規則容許該字段中分號保留未轉義。本協議的目的就是要求該字段不透明，因此這個值如何構成也僅僅在負責該資源的SIP實體中有意義。
17.1.4. URI比較
本規範中定義的某些操做須要肯定兩個SIP或SIPS URI是否等價。本規範規定，註冊服務器須要比較REGISTER請求的Contact URI中的綁定。根據如下規則斷定SIP和SIPS URI是否等價：
² SIP和SIPS URI不相等
² 比較SIP和SIPS URI的userinfo（含密碼的userinfo或者telephone-subscriber格式）時須要區分大小寫，除非特殊要求，比較URI的其他成分都不區分大小寫。
² 比較SIP和SIPS URI時，參數和頭字段的順序與等價性無關。
² 除了「保留」組（參見RFC 2396）之外，全部的字符都等價於它們對應的「「%」HEX HEX」編碼。
² DNS搜索主機名獲得的IP地址與該主機名不一致。
² 兩個URI等價，要求用戶、密碼、主機、端口都必須一致。
省略用戶部分的URI與包含用戶部分的URI不致。省略密碼的URI與包含密碼的URI也不致
省略任何含有缺乏值部分的URI與包含該部分而且指定值等於缺乏值的URI不致。例如，省略掉可選端口的URI與指定端口爲5060的URI不一致，transport-parameter，ttl-parameter，user-parameter，以及Method都是一樣的道理。（規定sip:user@host與sip:user@host:5060不等價與RFC 2543規定徹底不一樣。）從相同的URI中選到的地址等價。sip:user@host:5060端口老是5060而sip:user@host能夠經過[4]的DNS SRV機制解析爲另外的端口。
URI的參數比較規則以下：
兩個URI中出現的參數必須一致。
user、ttl、或method參數只在其中一個URI中出現，即便包含有缺乏省，也必定不能與另外的URI一致。
包含maddr參數的URI與不包含maddr的URI不一致
其他的參數若是隻在其中一個URI中出現時，比較的時候忽略不計。
URI的header成功 定不能忽略。兩個一致的URI中必須同時包含成分一致header。
17.1.5. 由URI構成請求
直接由URI構成時，商業名片、網頁以至協議內部資源（如已註冊的地址）的URI的頭字段或者消息體可能包含一些不合適部分。
構成請求中的必須包括Request-URI中的transport，maddr，ttl，user參數。若是URI包含一個method參數，它的值必須做爲請求的方法。Request-URI中不能夠有method參數。未知的URI參數必須放在消息的Request-URI中。
出如今URI中的頭字段或者消息體都應當包含在消息裏，基於請求中的每一個組成部分明顯標記該請求。
具體實現中，不該明顯標記那些容易受到威脅的頭字段From，Call-ID，CSeq，Via和Record-Route。
具體實現中，爲了在惡意攻擊的狀況下不被做爲不知情的代理利用，不能夠明顯標記那些請求的Route字段的值。
有些頭字段可能會引發位置或能力的錯誤判斷，因此不該該明顯標記它們。包括Accept，Accept-Encoding，Accept-Language，Allow，Contact，Organization，Supported，User-Agent。
具體實現中，應當校驗描述性頭字段的準確性，包括：Content-Disposition，Content-Encoding，Content-Language，Content-Length，Content-Type，Date，Mime-Version和Timestamp。
若是從給定的URI構建的請求不是有效的SIP請求，那麼該URI也是無效的，該請求不該被傳輸，並應尋找出現再次URI的緣由。構建請求無效的緣由有不少，包括頭字段語法錯誤，URI參數組合無效，消息體描述錯誤等。
發送一個由給定的URI構成的請求中所要求的能力可能難以達到。例如URI可能指定一種不可實現的傳送協議或者擴展。這種狀況下應該拒絕發送這個請求而不是修改它來適應它的能力。不能夠發送須要某個它不支持的擴展協議的請求。
例如，這種請求能夠經過現有的Require頭參數來構造，也能夠經過或方法URI參數來構造，該參數帶有未知的值或明確不支持的值。
17.1.6. SIP URI和tel URL的關聯
若是一個tel URL要被轉換成SIP URI時，tel URL中的整個telephone-subscriber部分和一些參數都被放在SIP URI中的userinfo中。例如：
tel:+358-555-1234567; postd=pp22變成
sip:+358-555-1234567;postd=pp22@foo.com;user=phone
而不是sip: +358-555-1234567 @foo.com;postd=pp22;user=phone
一般，以這種方式，等價的「tel」URL轉變成的SIP或SIPS URI可能不等價，SIP URI中的userinfo比較的時候區分大小寫，tel URL中的大小寫不區分的部分和tel URL參數從新排序雖然不影響tel URL的等價性，可是轉變成SIP或SIPS URI就不等價了，例如：
tel:+358-555-1234567;postd=pp22
tel:+358-555-1234567;POSTD=PP22
是等價的，而
sip:+358-555-1234567;postd=pp22@foo.com;user=phone
sip:+358-555-1234567;POSTD=PP22@foo.com;user=phone
卻不等價。
一樣，
tel:+358-555-1234567;postd=pp22;isub=1411
tel:+358-555-1234567;isub=1411;postd=pp22
是等價的，而
sip:+358-555-1234567;postd=pp22;isub=1411@foo.com;user=phone
sip:+358-555-1234567;isub=1411;postd=pp22@foo.com;user=phone
不等價
爲減輕這個問題，將放到userinfo部分的telephone-subscriber中的大小寫不區分的部分統一改成小寫（tel URL全部的成分除未來擴展的參數之外都是大小寫不區分的），telephone-subscriber參數按照名字排序（isdn-subaddress和post-dial這種參數除外，它們老是排在前面）。根據上面的規定
tel:+358-555-1234567;postd=pp22 和
tel:+358-555-1234567;POSTD=PP22
都將成爲
sip:+358-555-1234567;postd=pp22@foo.com;user=phone
而
tel:+358-555-1234567;tsp=a.b;phone-context=5 和
tel:+358-555-1234567;phone-context=5;tsp=a.b
都將成爲
sip:+358-555-1234567;phone-context=5;tsp=a.b@foo.com;user=phone
17.2. 選項標籤
選項標籤是用來指定SIP擴展選項的識別符且爲惟一的。這些標籤用於Require，Proxy-Require，Supported以及Unsupported這些頭字段中，這些選項以「選項參數=符號」的形式做爲參數出如今這些頭字段中。選項標籤在RFC的相關標準中定義。爲了能夠保證廠商互通性，可參考IANA註冊的選項標籤。
17.3. 標籤
「tag」參數用於SIP消息中的To和From頭字段。它一般用來識別一個對話，由Call-ID和對話的雙方各一個的標籤組成。當UA在對話以外發送請求的時候，它只包含一個From標籤，提供「一半」對話ID，對話由收到響應結束，雙方在To標籤裏提供另外一半ID。分叉代理的SIP請求便可以由一個請求創建多個對話。所以，對話雙方都必需要有標識符：沒有接收者確認，發件人不能確認這個對話是由一個請求創建的多個對話的哪個。
UA生成一個標籤插入到請求或者響應中，這個標籤必須是全局惟一的而且至少是32比特的隨機編碼。當UA要將本身加入一個會話中支，它須要在INVITE請求的From頭字段中插入一個標籤，在其響應的To頭字段中插入一個不一樣的標籤。一樣，兩個對於不一樣呼叫的INVITE有不一樣的From標籤，對於兩個不一樣的呼叫的響應也有不一樣的To標籤。
除了要求全局惟一，根據具體實踐不一樣對創建標籤的規則也有不一樣的要求。系統在容許的範圍以內出錯，標籤有助於將聖誕倒換到備用的服務器上。在出錯的服務器上經過備份能夠識別出這個對話的部分請求，UAS能夠選擇標籤來恢復該聖誕以及其餘相關的狀態。
18. 頭字段
本章完整的列舉了頭字段的語法、語義、用法。頭字段與各類方法和代理服務器的關係總結於表 2
表 2 頭字段概覽
| Header field |
where |
proxy |
ACK |
BYE |
CAN |
INV |
OPT |
REG |
| Accept |
R |
|
- |
o |
- |
o |
m* |
o |
| Accept |
2xx |
|
- |
- |
- |
o |
m* |
o |
| Accept |
415 |
|
- |
c |
- |
c |
c |
c |
| Accept-Encoding |
R |
|
- |
o |
- |
o |
o |
o |
| Accept-Encoding |
2xx |
|
- |
- |
- |
o |
m* |
o |
| Accept-Encoding |
415 |
|
- |
c |
- |
c |
c |
c |
| Accept-Language |
R |
|
- |
o |
- |
o |
o |
o |
| Accept-Language |
2xx |
|
- |
- |
- |
o |
m* |
o |
| Accept-Language |
415 |
|
- |
c |
- |
c |
c |
c |
| Alert-Info |
R |
ar |
- |
- |
- |
o |
- |
- |
| Alter-Info |
180 |
ar |
- |
- |
- |
o |
- |
- |
| Allow |
R |
|
- |
o |
- |
o |
o |
o |
| Allow |
2xx |
|
- |
o |
- |
m* |
m* |
o |
| Allow |
r |
|
- |
o |
- |
o |
o |
o |
| Allow |
405 |
|
- |
m |
- |
m |
m |
m |
| Authentication-Info |
2xx |
|
- |
o |
- |
o |
o |
o |
| Authorization |
R |
|
o |
o |
o |
o |
o |
o |
| Call-ID |
c |
r |
m |
m |
m |
m |
m |
m |
| Call-Info |
|
ar |
- |
- |
- |
o |
o |
o |
| Contact |
R |
|
o |
- |
- |
m |
o |
o |
| Contact |
1xx |
|
- |
- |
- |
o |
- |
- |
| Contact |
2xx |
|
- |
- |
- |
m |
o |
o |
| Contact |
3xx |
d |
- |
o |
- |
o |
o |
o |
| Contact |
485 |
|
- |
o |
- |
o |
o |
o |
| Content-Disposition |
|
|
o |
o |
- |
o |
o |
o |
| Content-Encoding |
|
|
o |
o |
- |
o |
o |
o |
| Content-Language |
|
|
o |
o |
- |
o |
o |
o |
| Content-Length |
|
ar |
t |
t |
t |
t |
t |
t |
| Content-Type |
|
|
* |
* |
- |
* |
* |
* |
| Cseq |
c |
r |
m |
m |
m |
m |
m |
m |
| Date |
|
a |
o |
o |
o |
o |
o |
o |
| Error-Info |
300-699 |
a |
- |
o |
o |
o |
o |
o |
| Expires |
|
|
- |
- |
- |
o |
- |
o |
| From |
c |
r |
m |
m |
m |
m |
m |
m |
| In-Reply-To |
R |
|
- |
- |
- |
o |
- |
- |
| Max-Forwards |
R |
amr |
m |
m |
m |
m |
m |
m |
| Min-Expires |
423 |
|
- |
- |
- |
- |
- |
m |
| MIME-Version |
|
|
o |
o |
- |
o |
o |
o |
| Organization |
|
ar |
- |
- |
- |
o |
o |
o |
| Priority |
R |
ar |
- |
- |
- |
o |
- |
- |
| Proxy-Authenticate |
407 |
ar |
- |
m |
- |
m |
m |
m |
| Proxy-Authenticate |
401 |
ar |
- |
o |
o |
o |
o |
o |
| Proxy-Authorization |
R |
dr |
o |
o |
- |
o |
o |
o |
| Proxy-Require |
R |
ar |
- |
o |
- |
o |
o |
o |
| Record-Route |
R |
ar |
o |
o |
o |
o |
o |
o |
| Record-Route |
2xx,18x |
mr |
- |
o |
o |
o |
o |
- |
| Reply-To |
|
|
- |
- |
- |
o |
- |
- |
| Require |
|
ar |
- |
c |
- |
c |
c |
c |
| Retry-After |
404, 413, 480, 486 |
|
- |
o |
o |
o |
o |
o |
| Retry-After |
500,503 600,603 |
|
- |
o |
o |
o |
o |
o |
| Route |
R |
adr |
c |
c |
c |
c |
c |
c |
| Server |
r |
|
- |
o |
o |
o |
o |
o |
| Subject |
R |
|
- |
- |
- |
o |
- |
- |
| Supported |
R |
|
- |
o |
o |
m* |
o |
o |
| Supported |
2xx |
|
- |
o |
o |
m* |
m* |
o |
| Timestamp |
|
|
o |
o |
o |
o |
o |
o |
| To |
c(1) |
r |
m |
m |
m |
m |
m |
m |
| Unsupported |
420 |
|
- |
m |
- |
m |
m |
m |
| User-Agent |
|
|
o |
o |
o |
o |
o |
o |
| Via |
R |
amr |
m |
m |
m |
m |
m |
m |
| Via |
rc |
dr |
m |
m |
m |
m |
m |
m |
| Warning |
r |
|
- |
o |
o |
o |
o |
o |
| WWW-Authenticate |
401 |
ar |
- |
m |
- |
m |
m |
m |
| WWW-Authenticate |
407 |
ar |
- |
o |
- |
o |
o |
o |
「where」列定義能夠使用該頭字段的請求和響應的類型。每一個值含義以下：
R:頭字段只能在請求中出現；
r:頭字段只能在響應中出現；
2xx、4xx，等等：頭字段能夠用於的響應代碼。
c：頭字段是從請求複製到響應的。
若是」where」欄目是空白，表示頭字段能夠在全部的請求和應答中出現。
「proxy」列描述了proxy在頭字段上的操做
a：若是頭字段不存在，proxy能夠增長或者鏈接頭字段
m：proxy能夠修改頭字段值
d：proxy能夠刪除頭字段值
r：proxy必須能讀取這個頭字段，所以這個頭字段不能加密。
接下來6列描述某一個方法中能夠出現的頭字段：
c：條件；對頭字段的要求依賴於消息的上下文
m：頭字段是強制要有的。
m*：頭字段應該被髮送，可是客戶端/服務端能夠接收沒有該字段的消息。
o：頭字段是可選的。
t：頭字段應該被髮送，可是客戶端/服務端能夠接收沒有該字段的消息。若是使用基於流的傳送協議（例如TCP），那麼必須含有該頭字段。
*：若是消息體不爲空，那麼頭字段是必須。
-：不可以使用該字段。
「Optional」意味着這個元素能夠在請求或者應答中包含該頭字段，但UA也能夠忽略它， Require頭字段例外。」mandatory」（強制）要求請求中或者響應中必須含有該頭字段，收到該請求的UAS或者UAC必須可以理解該字段。」Not applicable」（不可以使用）要求請求消息不能夠含有該字段，UAS必須忽略含有這些字段的請求消息；一樣，對於響應，標註了「Not applicable」的頭字段意味着UAS不能夠將該字段放於響應中，而且UAC必須忽略響應中的該字段。
UA應該忽略它所不理解的擴展頭字段參數，當整個消息太大時，某些普通的頭字段能夠使用縮略形式。Contact、From以及To字段都包含一個URI。若是該URI包含逗號、問號或者分號，該URI必須用三角括號括起來。任何URI參數也都包括在這些三角括號內。若是某URI沒有在三解括號內，而且參數使用分號分隔，那麼這些參數就認爲是頭字段參數，而不是URI參數。
18.1. Accept
Accept頭字段參照HTTP語法規定，語義也基本相同。惟一不一樣的是若是沒有Accept頭域，服務器應該默認其值爲application/sdp。空的Accept頭域意味着沒有可接受的媒體類型。
例子：
Accept: application/sdp;level=1,application/x-private,text/html
18.2. Accept-Encoding
Accept-Encoding相似Accept，限制響應中可接受的內容編碼。
Accept-Encoding容許爲空。它等價於Accept-Encoding:identity,也就是說，只有identity時容許沒有編碼。若是沒有Accept-Encoding存在，那麼服務端應該使用缺省值：identity。
例如：
Accept-Encoding:gzip
18.3. Accept-Language
Accept-Language用來在請求中指定響應中首選的語言，用於響應中做爲消息體的緣由描述、對話描述或者狀態響應。若是沒有Accept-Language，那麼服務器應當假設全部的語言客戶端均可以接受。
Accept-Language的語法遵守HTTP。基於「q」參數排序的規定也適用於SIP。
例如：
Accept-Language: da, en-gb; q= 0.8, en;q=0.7
18.4. Alert-Info
當INVITE請求含有Alert-Info時，該字段對UAS定義了另一個可用的鈴音。當在180（Ringing）響應中出現時，該字段對UAC定義了另一個能夠使用的回鈴音。代理服務器插入該字段是能夠提供一種獨特的鈴聲。
Alter-Info能會帶來潛在的安全隱患。
另外，用戶應該也能夠修改鈴聲以使鈴聲可用。這有助於防止因爲不信任的實體使用了該字段而致使通訊中斷。
例如：
Alter-Info: <http://www.example.com/sounds/moo.wav>
18.5. Allow
Allow列出了發起請求UA支持的方法列表。UA能理解的全部方法都必須列於該頭字段中。消息中若無該頭字段，則意味UA未提供任何關於它所支持方法的信息，並不意味着UA不支持任何方法
響應消息中的Allow包含OPTIONS之外其餘的方法，所以能夠減小所需消息數量。
例如：
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE
18.6. Authentication-Info
Authentication-Info爲通訊雙方提供HTTP分類鑑權信息。若是某請求已經基於Authorization頭字段完成了鑑權，那麼UAS能夠在該請求的2xx的響應中包含一個Authentication-Info字段，語法和語義規定見RFC 2617。
例如：
Authentication-Info: nextnonce=」47364c23432d2e131a5fb210812c」
18.7. Authorization
Authorization中包含UA進行認證的鑑權證書。
Authorization和Proxy-Authorization,不遵循多頭字段值的通常規則。雖然多個數值之間沒有逗號分隔，該頭字段名仍能夠出現屢次。而且不能夠按照4.3中的規則將其合併成一個頭字段行
例如：
Authorization:Digest username=」Alice」, realm=」atlanta.com」,
nonce = 」84a4cc6f3082121f32b42a2187831a94」,
response=」7587245234b3434cc3412213e5f113a5432」
18.8. Call-ID
Call-ID用來惟一標識某個客戶端的某個特定的INVITE或全部的註冊請求。一個多媒體會議能夠發起多個不一樣Call-ID的呼叫，例如，某用戶數次邀請某人加入同一個會議。Call-ID區分大小寫並逐字節比較，縮寫形式爲i。
例如：
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com
i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4
18.9. Call-Info
Call-Info若在請求中則提供主叫的附加信息，若在響應中則提供被叫附加信息。」purpose」參數描述了URI的用途。」icon」參數包含了一個呼叫方或者被叫方的圖標。」info」參數則爲主叫或者被叫的通常描述；」card」參數提供一個名片，其他參數能夠經過INNA註冊。
可是，使用Call-Info可能會帶來一些安全隱患。若是某被叫接到一個惡意主叫提供的URI，被叫方可能會顯示顯現一些不恰當或者攻擊性的內容，或者一些危險的、非法的內容。所以，僅當UA可以證實發出的Call-Info字段的實體是真實並可信的，該UA才使用Call-Info的信息。這並不必定要求是對等的UA，代理服務器也能夠在請求中插入該字段。
例如：
Call-Info: http://www.example.com/alice/photo.jpg;purpose=icon,
http://www.example.com/alice/;purpose=info
18.10. Contact
Contact字段值包含一個URI，其含義取決於所在的請求或響應的類型。
Contact還能夠包含了一個顯示的名字、含有URI參數的URI和頭字段參數。
本文檔定義了Contact參數「q」和「expires」。這些參數只用於REGISTER的請求及其響應以及3xx的響應。
當Contact頭字段包含一個顯示名稱時，那麼帶參數的URI應當用」<」和」>」括起來。不然，URI後面的參數都認爲是頭字段參數而不是URI參數。
即便「display-name」爲空，只要」addr-spec」包含逗號、分號或者問號，也必須使用「name-addr」中的格式。display-name和」<」之間的LWS(線性空白)無關緊要。
解析顯示名稱、URI、URI參數以及頭字段參數的規則一樣適用於To和From頭字段。
Contact頭字段的做用相似於HTTP中的Location頭字段。可是HTTP中的Location只容許1個不用引號標註的地址。因爲URI中能夠包含逗號和分號，它們可能被誤認爲頭字段或者參數的分隔符。
Contact的縮寫是m(「moved」)。
例如：
Contact： 「Mr.Watson」 <sip:watson@worcester.bell-telephone.com>;q=0.7;
expires=3600,
「Mr. Watson」 mailto:watson@bell-telephone.com ;q=0.1
m: <sips:bob@192.0.2.4>;expires=60
18.11. Content-Disposition
Content-Disposition描述了消息體，或者消息的多個部分，或者消息體的一個部分應被UAC或者UAS怎樣解釋。該頭字段擴展了MIME Content-Type。
SIP定義了Content-Disposition幾個新的「disposition-types」。「session」值表示消息體部分描述了一個呼叫時或者呼叫前的媒體會話。「render」值表示了消息體應被顯示或者回傳給用戶。注意」render」比」inline」更適合避免MIME消息體做爲一個大的消息的一部分作展現（因爲SIP消息的MIME消息體常常不被展現給用戶）。出於向後兼容的考慮，若是Content-Disposition不存在，服務器應當假設Content-Type爲application/sdp的消息體是所要描述的「session」，其餘消息體的值爲「render」。
「icon」表示消息體部分包含了一個用於表示呼叫者或者被叫者的icon圖標，當UA收到這個消息，就能夠展現一下，或者在對話過程當中一致展現。「alert」指明該消息體部分包含一些信息應該由UA通知用戶接收請求的時候回傳給用戶，一般一個請求發起一個對話。例如，180臨時性響應發出以後，告警該消息體應該做爲一個鈴聲信息回傳給電話機。
任何含有「disposition-type」的MIME消息體只有在該消息被鑑權後才處理
參數handling-param指定了若是UA不理解所收到的某消息體的內容類型或者處理類型，UAS應該如何處理。該參數定義了「optional」和「required」兩個值，若是沒有該參數，默認值爲「required」。關於該參數參見RFC 3204。
例如：
Content-Disposition: session
18.12. Content-Encoding
Content-Encoding是對「media-type」(媒體類型)的一個修正。它的值指定了適用於該實體的編碼以及爲了得到Content-Type指定的媒體類型所須要使用的解碼機制。Content-Encoding主要用於消息體壓縮並且不丟失底層媒體類型標識。若是某個實體能夠使用多個編碼方式，則編碼方式按其使用的順序排列。
全部的Content-Encoding的值都不區分大小寫。其符號值必須在IANA上註冊。
客戶端能夠在請求中進行包體的內容編碼。服務端也能夠在應答中進行內容編碼。服務端必須只能應用客戶端在請求中的Accept-Encoding頭域中列出的編碼類型。
Content-Encoding簡寫是e。
例如：
Content-Encoding:gzip
e: tar
18.13. Content-Language
參見HTTP相減規範，舉例以下：
Content-Language: fr
18.14. Content-Length
Content-Length頭字段用十進制數指定發送的消息體的大小（字節數）。具體實現時，應該使用該字段指示所傳遞消息體的大小而不考慮該實體的媒體類型。本協議規定，使用基於流的傳輸協議時必須使用該字段。
本字段所指標的消息體的大小不包括分隔頭字段和消息體的CRLF符。該字段的有效值爲大於等於零的數。若是消息中無消息體，那麼該字段值必須設爲零。省略Content-Length字段簡化了動態的產生響應的類CGI腳本程序。
Content-Length簡寫是l
例如：
Content－Length：349
l：173
18.15. Content-Type
Content-Type頭字段指定發給對方的消息體的媒體類型。若是消息體不爲空，那麼Content-Type頭字段就必須存在。若是消息體是空的，而且該頭字段存在，那麼就表示了特定類型的媒體的包體長度爲0（好比空的音頻文件）。
Content-Type簡寫是c
例如：
Content-Type: application/sdp
c: text/html;charset=ISO-8859-4
18.16. CSeq
Cseq位於請求消息中，包含一個十進制數字序列和一個請求方法。這個數字序列必須是一個32位的無符號整數。Cseq請求方法區分大小寫的。Cseq用於把某對話中的事務進行排序且提供一種惟一標識某事務的方法，並可以區分某請求是新的請求仍是重發的請求。若是兩個CSeq的數字序列以及方法都相等，那麼兩個Cseq頭域就是等價的。
例如：
Cseq:4711 INVITE
18.17. Date
Date頭字段包含日期和時間。和HTTP/1.1不一樣，SIP只支持最近的RFC 1123格式的日期。SIP限制了在SIP－date中的時區是「GMT」,在RFC 1123中支持任意的時區。RFC1123的日期是區分大小寫的。
Date頭域反映了請求或者響應第一次被髮送的那一刻的時間。沒有後備電池的終端系統能夠利用Date字段得到當前時間。然而，因爲是GMT格式的，因此，它要求客戶端知道和GMT的時差。
例如：
Date：Sate,13 Nov 2010 23:29:00 GMT
18.18. Error-Info
Error-Info頭字段用來提供出錯狀態碼的附加信息。
UAC具有用戶接口功能，包括PC軟客戶端的彈出窗口接口、音頻接口、經過網關鏈接的音頻電話或端點的接口。當服務器產生錯誤信號的時候，它能夠發送一個帶詳細描述的出錯狀態碼，或者可發送一個音頻記錄， Error-Info頭字段能夠同時發送這兩種信號，UAC能夠選擇任何一種方式通知主叫。
UAC能夠把在Error-Info中的一個SIP或者SIPS URI看成重定向消息的Contact頭字段，而且據此產生一個新的INVITE，並創建一個已記錄的會話。非SIP URI能夠回送給用戶。
例如：
SIP/2.0 404 The Number you have dialed is not in service
Error-Info: <sip:not-in-service-recording@atlanta.com>
18.19. Expires
Expires頭字段給定了消息（或者內容）的有效時間。其含義因請求方法不一樣而不一樣。INVITE的有效時間並不影響會話的實際持續時間。會話持續時間的表達方法由會話描述協議SDP規定。
該字段的值是一個十進制整數，單位爲秒，其值介於0到(232-1)之間。
這個頭域的值是一個以秒計數的整數，從0到(2**32)-1，從收到請求開始計數。
例如：
Expires:5
18.20. From
From頭字段用於指示請求的發起者。這可能與對話的發起者並不一樣。被叫發送給主叫的請求在From字段中使用被叫的地址。
「display-name」參數可選，主要用於人機接口。若是用戶須要隱藏其標識，那麼系統應當使用」Anonymous」做爲顯示名字。即便是」displayname」是空的，若是「addr-spec」 包含一個逗號、問號或者分號，那麼就必須使用「name-addr」的格式。相關的格式參見4.3.1節描述。
若是兩個From字段的URI一致而且參數也一致，那麼這兩個頭字段就是等價的。若是擴展參數在一個頭字段中存在，在另一個頭域字段不存在，那麼比較這兩個頭字段時應將這個參數忽略。這意味着名字和三角括號的存在與否並不影響其等價性。
From的簡寫是f
例子：
From: 「A. G. Bell」 <sip:agb@bell-telephone.com> ; tag=a48s
From: sip:+12125551212@server.phone2net.com;tag=887s
f: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8
18.21. In-Reply-To
In-Reply-To頭字段列舉了本次呼叫相關的或者返回的Call-ID。客戶端能夠緩存這些Call-ID，並放在所返回的呼叫的In-Reply-To字段中。這容許自動呼叫分配系統（ACD）將返回的呼叫路由到第一個呼叫發起者。這也容許被叫過濾這些呼叫，僅返回那些被接受的呼叫。這個頭字段並不可替代請求鑑權。
例如：
In-Reply-To: 70710@saturn.bell-tel.com,17320@saturn.bell-tel.com
18.22. Max-Forwards
Max-Forwards頭字段必須在每個SIP請求中使用，來限制中間轉發請求到下一個節點的proxy或者gateway的個數。當某個客戶端沿着某條鏈路發送請求消息的時候，使用該字段能夠有效防止鏈路中出錯或者發生迴環。
Max-Forwards是一個0－255的整數，指示該請求還容許被轉發的次數。每當服務器轉發這個請求一次，這個數字就減一。建議的初始值是70。當不能肯定有無循環路由的時候，必須在頭域中增長本頭域。例如，B2BUA應當增長這個頭域。
例如：
Max-Forwards:6
18.23. Min-Expires
Min-Expires頭字段定義了由服務器控制的軟狀態實體更新間隔的最小值。這也包括註冊服務器存儲的Contact字段。該頭字段的值是0~232-1的十進制整數，單位爲秒。
例如：
Min-Expires:60
18.24. MIME-Version
參見HTTP/1.1。舉例以下：
MIME-Version: 1.0
18.25. Organization
Organization頭字段包含了發出請求或者響應消息的SIP節點所屬的組織名稱。該字段能夠用來讓客戶端軟件過濾呼叫。
例如：
Organization: Boxes by Bob
18.26. Priority
Priority頭字段定義客戶端請求緊急程度。Priority描述了對於接收用戶或其代理，請求消息所具備的優先級。例如，這多是決定呼叫轉發和處理的優先要素。對於斷定優先級來講，若是消息沒有包含Priority字段，那麼處理的時候應當看成」normal」優先級處理。Priority不影響通信資源的優先順序，好比路由上的包轉發的優先級或者訪問PSTN網關的優先級。該頭字段有「non-urgent」、「norma」、「urgent」和「emergency」取值。強烈建議「emergency」只用於影響到生命、身體、或者財產危急時候才使用。
例如：
Subject: A tornado is heading our way!
Priority: emergency。
或者
Subject: Weekend plans
Priority: non-urgent.
18.27. Proxy-Authenticate
Proxy-Authenticate頭字段包含一個鑑權質詢口令。
例如：
Proxy-Authenticate: Digest realm=」atlanta.com」,
domain=」sip:ss1.carrier.com」,qop=」auth」,
nonce=」f84f1cec41e6cbe5aea9c8e88d359」,
opaque=」」,stale=FALSE,algorithm=MD5
18.28. Proxy-Authorization
Proxy-Authorization頭字段用於用戶對要求鑑權的proxy標識本身。Proxy-Authorization頭字段包含一個證書，其中包含UA對於proxy的鑑權信息和所要請求的資源的域。
關於多字段名的通常規定並不適用於Proxy-Authorization和Authorization頭字段。雖然多個數值之間沒有逗號分隔，該頭字段名仍能夠出現屢次，可是不能夠將它們結合成一個單獨的頭字段行。
例如：
Proxy-Authorization: Digest username=」Alice」,realm=」atlanta.com」,
nonce=」c60f3082ee1212b402a21831ae」,
response=」245f23415f11432b3434341c022」
18.29. Proxy-Require
Proxy-Require頭字段用來指定proxy所必須支持的相關的特性。
例子：
Proxy-Require:foo
18.30. Record-Route
Record-Route頭字段是proxy在插入到請求消息中的，用來強制會話中的後續請求通過本proxy的。
例子：
Record-Route: <sip:server10.biloxi.com;lr>,
<sip:bigbox3.site3.atlanta.com;lr>
18.31. Reply-To
Reply-To頭字段包含了邏輯上返回目的地URI，這個可能和From頭字段不一樣。若是用戶須要保持匿名，則該字段必須從請求中省略掉，或者使用一種不顯現任何我的信息的方式。
即便「display-name」爲空，若是「addr-spec」包含逗號、問號或者分號，那麼就須要使用「name-addr」的格式來填寫。
例如：
Replay-To: Bob <sip:bob@biloxi.com>
18.32. Require
Require頭字段用於UAC告訴UAS處理請求時須要支持那些特性。該字段爲可選，但不能夠被忽略。
該字段包含一個option tag的列表。每個option tag定了一個要處理請求，要求UAS必須支持的SIP擴展。一般，這用於定義一個須要支持的擴展頭域的集合。
例如：
Require：100rel
18.33. Retry-After
Retry-After頭字段用於500（Server Internal Error）或者503（Service Unavailable）響應中，能夠對請求發起客戶端指示多久後服務不可用。在404(Not Found)、413(Request Entity Too Large)、480(Temporarily Unavailable)、486(Busy Here)、 600 (Busy),或者603(Decline)響應中代表被叫什麼時候可用。這個字段的值是一個秒爲單位的正整數（十進制），從響應生成開始計時。
本字段中能夠使用一個註釋項標明於回呼時間的附加信息，該註釋項爲可選。「duration」參數指明被叫從空閒的開始保持空閒的時長。該參數可選。
例如：
Retry-After: 18000;duration=3600
Retry-After:120 (I’m in a meeting)
18.34. Route
Route頭字段用於強制一個請求通過一個proxy路由列表。
例如：
Route: <sip:bigbox3.site3.atlanta.com;lr>,
<sip:server10.biloxi.com;lr>
18.35. Server
Server頭字段包含UAS處理請求所使用的軟件信息。
服務器的特定軟件版本可能會使服務器因爲特定軟件安全漏洞致使服務器受到攻擊。實現上應當使得Server頭域是一個能夠配置的選項。
例如：
Server：HomeServer v2
18.36. Subject
Subject頭字段包括呼叫的概述或者呼叫的性質，過濾呼叫時，能夠沒必要解析會話描述。會話描述沒必要與邀請使用同一個對象。
Subject縮寫是s
例如：
Subject: Need more boxes
s: Tech Support
18.37. Supported
Supported頭字段列舉了UAC或者UAS支持的全部擴展。
Supported頭字段包含了一個UAS或者UAC所支持的option tag列表。若是本字段是空的，表示不支持任何擴展。
Supported縮寫是k
例如：
Supported: 100rel
18.38. Timestamp
Timestamp頭字段給出UAC向UAS發出請求的時間。
例如：
Timestamp:54
18.39. To
To頭字段指定請求的邏輯上接收者。「display-name」參數用於人機接口，爲可選。「tag」參數通常用於標識對話。
To頭字段等價性的斷定同From頭字段。
To頭域的縮寫是t。
舉例以下：
To: The Operator <sip:operator@cs.columbia.edu>;tag=287447
t: sip:+12125551212@server.phone2net.com
18.40. Unsupported
Unsupported頭字段列出了不被UAS支持的特性列表。
例如：
Unsupported:foo
18.41. User-Agent
User-Agent頭字段包含了發起請求的UAC信息。該字段的主義參見HTTP/1.1。
若是顯示UA的特定軟件版本信息，一量該軟件存在安全漏洞，該UA就容易受到攻擊，應把User-Agent字段做爲可配置的選項
例如：
User-Agent:Softphone Beta1.5
18.42. Via
Via頭字段指定目前請求消息通過的路徑，同時指定響應也要按該路徑返回。Via頭字段的branch ID參數提供了事務的標識符，proxy用它來檢測環路。
Via頭字段包含了用於發送消息的通信協議、客戶端主機名或者網絡地址，可能還有接收應答響應的端口號。Via頭字段還能夠包含參數「maddr」、「ttl」、「received」和「branch」，具體實現時，branch參數的值必須用magic cookie「z9hG4bK」打頭。
這裏定義的通信協議是UDP、TCP、TLS和SCTP，TLS是基於TCP的TLS。如：
Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7
Via: SIP/2.0/UDP 192.0.2.1:5060 ;received=192.0.2.207;branch=z9hG4bK77asjd
Via縮寫是v
上面例子中，一個擁有兩個地址（192.0.2.1和192.0.2.207）的多源(multi-homed)主機發出消息。發送方可能用錯了網絡接口。Erlang.belltelephone.com發現了不匹配，就在前一跳的Via字段中插入一個包含實際發送該數據包的址的參數。
主機或者網絡地址以及端口號不須要遵循SIP URI的語法。「：」或者「/」的任何一邊的LWS都是容許的。以下所示：
Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16
;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1
雖然要求全部的請求中都包含branch參數，但該字段的BNF仍然規定branch參數是可選的。這樣可加強與RFC 2543定義實體之間的互操做性。
18.43. Warning
Warning頭字段是與響應狀態有關的附加信息。Warning頭字段值放於響應中發送，其中包含一個三位告警碼、主機名以及告警文本信息。
「warn-text」應爲可被用戶理解的天然語言，能夠根據如下幾種狀況選擇：用戶的位置、請求中的Accept-Language字段、響應中的Content-Language字段。默認的語言是i-default。
如下列舉了已定義的「warn-code」和英文的warn-text。這些告警是由會話描述所引入的失敗。告警碼的第一位是3則代表爲SIP告警。300-329代表是由於會話描述中的關鍵詞引發的錯誤；330-339表示錯誤與會話描述要求的基本網絡業務有關；370-379代表錯誤與會話描述要求的QoS有關；390-399是除上述狀況以外的錯誤。
300 Incompatible network protocol:（不兼容的網絡協議），One or more network protocols contained in the session description are not available.（在會話描述中的一個或者多個網絡協議不適用）
301 Incompatible network address formats(不兼容的網絡地址格式)：One or more network address formats contained in the session description are not available. （會話描述中的一個或者多個網絡地址格式不合法）
302 Incompatible transport portocol(不兼容的通信協議)：One or more transport protocols described in the session description are not available. （會話描述中的一個或者多個通信協議不存在）。
303：Incompatible bandwidth units（不兼容的帶寬單位）: One or more bandwidth measurement units contained in the session description were not understood.（會話描述中的一個或者多個帶寬單位不支持）。
304 Media type not available（媒體類型不存在）: One or more media types contained in the session description are not available. （會話描述中的一個或者多個媒體類型不存在）。
305 Incompatible media format（媒體格式不兼容）: One or more media formats contained in the session description are not available.（會話描述中的一個或者多個媒體格式不兼容）。
306 Attribute not understood（媒體屬性不支持）: One or more of the media attributes in the session description are not supported.（會話描述中的一個或者多個媒體屬性不支持）。
307 Session description parameter not understood（會話描述參數不支持）: A parameter other than those listed above was not understood.（列出的會話描述參數不支持）。
330 Multicast not available（多點傳輸不容許）: The site where the user is located does not support multicast.（用戶定位的這個服務器不支持多點傳送）。
331 Unicast not available（Unicast不支持）: The site where the user is located does not support unicast communication (usually due to the presence of a firewall)。（用戶定位的節點不支持unicast通信（一般因爲在防火牆以後））。
370 Insufficient bandwidth(帶寬不足): The bandwidth specified in the session description or defined by the media exceeds that known to be available.（會話描述的帶寬要求或者媒體要求的帶寬超過限制）。
399 Miscellaneous warning（雜項警告）: The warning text can include arbitrary information to be presented to a human user or logged. A system receiving this warning MUST NOT take any automated action.（這個警告信息能夠包含給用戶的任意信息或者作日誌記錄。接收到這個警告的系統禁止作任何自動操做）。
1xx和2xx消息是HTTP/1.1使用的。
附加的「warn-code」是IANA定義的。
例如：
Warning: 307 isi.edu "Session parameter ’foo’ not understood"
Warning: 301 isi.edu "Incompatible network address type ’E.164’"
18.44. WWW-Authenticate
WWW-Authenticate頭字段包含了認證信息。
例如：
WWW-Authenticate:Digest realm=」atlanta.com」,
domain=」sip:boxesbybob.com」,qop=」auth」,
nonce="f84f1cec41e6cbe5aea9c8e88d359",
opaque="", stale=FALSE, algorithm=MD5
19. 響應代碼
SIP的響應代碼在HTTP/1.1的基礎上有所擴展。這裏只涉及到SIP響應代碼，並補充了6xx響應代碼。
19.1. 臨時響應1xx
臨時響應即報告性的響應，用來指明所聯繫的服務器尚未肯定性的響應。若是服務器須要200ms以上的時間才能發出最終響應，則它就須要首先發送一個1xx響應。1xx響應不能進行可靠傳輸。它也不能讓客戶端發送一個ACK請求。臨時響應（1xx）能夠包括一些消息體，其中包含會話描述SDP。
19.1.1. 100 Trying
100 Trying代表下一跳服務器已經收到該請求，可是對此次請求並未進行具體的處理。和其餘臨時響應同樣，該響應使UAC中止重發INVITE請求。與其餘臨時響應不一樣，該響應不能使用有狀態服務器前轉。
19.1.2. 180 Ringing
UA收到INVITE請求以後用該響應通知用戶，該響應也能夠用來初始化一個本地回鈴。
19.1.3. 181 Call is Being Forwarded(呼叫被轉發)
服務器能夠用使用該狀態碼錶示該呼叫正被前轉到另一組終點。
19.1.4. 182 Queued
當被叫方正忙，而且服務器決定將呼叫排隊等候，而不是拒絕呼叫的時候，那麼就應當返回該響應。當被叫方一旦恢復接收呼叫，將返回適當的終結應答。該響應中能夠包括一個表示緣由的短語，好比：」5 calls queued;expected waiting time is 15minutes」。服務器能夠發出多個182（Queued）響應來更新呼叫等待的狀態。
19.1.5. 183（Session Progress）
183（Session Progress）響應用來傳遞呼叫進程的信息，其中包括緣由短語、頭字段、消息體來描述呼叫進程更詳細的信息。
19.2. 成功信息2xx
該響應代表請求成功
19.2.1. 200 OK
該響應表示請求成功。與響應一塊兒返回的信息取決於請求中使用的方法。
19.3. 轉發請求3xx
該響應指標用戶新位置信息，或者指定能夠知足本次呼叫所須要的其餘服務。
19.3.1. 300 Multiple Choices
請求中的地址能夠解析爲幾個選項，每一個選項都有本身特定的位置。用戶或者UA能夠肯定一個首先的通訊端點而且將該請求重定向到該位置。
請求中的消息體可能包含一個資源特徵和位置的列表，用戶或者UA能夠從中選擇一個Accept頭字段中所容許的最合適的資源特徵和位置。該消息不定義MIME類型。
這些選項可做爲Contact字段列出。SIP響應可包含幾個Contact字段或者在一個Contact字段中有多個地址。UA能夠使用Contact字段的中的值自動重定向，也能夠要求用戶對選項進行確認。若是被叫能夠經過多個不一樣的位置到達，且服務器不能代理該請求，則能夠使用該狀態碼。
19.3.2. 301 Moved Permently
當用戶已經不在Request-URI頭字段的地址中，請求發起用戶就應該重發請求至Contact頭字段中的新地址。請求方應該更新本地姓名地址簿和用戶位置並將未來的請求重定向到新地址。
19.3.3. 302 Moved Temporarily
請求發起用戶應向Contact頭字段中的新地址重發請求。新請求中的Request-URI是響應中Contact頭字段裏的值。Contact頭字段中URI的有效期能夠收Expires頭字段或者Contact頭字段中的expires參數來定義。Proxy和UA能夠在有效期內使用URI。若是沒有明肯定義有效期，則該地址僅可有效遞歸一次，而之後的事務就不能夠再使用該URI。
若是用戶向Contact頭字段中的URI發送請求失敗，則應向重定向請求中的URI嘗試發送請求。有效期事後以後該URI就再也不使用，這時能夠有一個新臨時URI。
19.3.4. 305 Use Proxy
請求的資源必須經過Contact頭域中指出的proxy來訪問。Contact頭域指定了一個proxy的URI。接收到這個應答的對象應當經過這個proxy從新發送這個單個請求。305（UseProxy）必須是UAS產生的。
19.3.5. 380 Alternative Service
呼叫不成功，可是能夠嘗試另外的服務。
19.4. Request Failure 4xx
該響應由服務器發出代表請求失敗。客戶機不該（例如增長合適的受權）將原請求不加修改並從新發送。但將原請求發向不一樣的服務器也可能成功。
19.4.1. 400(Bad Request)
該響應表示請求因爲語法錯誤該而不能被理解。響應的緣由短語中應詳細指出語法錯誤。
19.4.2. 401 (Unauthorized)
該響應表示請求消息須要用戶鑑權。該響應由UAS和註冊服務器發起。407 (Proxy Authentication Required)由代理服務器發起。
19.4.3. 402 (Payment Required)
保留未來使用。
19.4.4. 403 (Forbidden)
該響應表示服務器能理解可是拒絕執行請求消息。即便該請求已經鑑權也不能進行中繼。
19.4.5. 404 (Not Found)
該響應表示服務器能夠肯定用戶不在Request-URI頭字段指定的域中。若是Request-URI頭字段所指定的域與請求的接收方所能處理的域不一致時，也應該發送該響應。
19.4.6. 405 (Method Not Allowed)
該響應表示在Request-URI頭字段指定的地址上，請求中的方法可以被理解但並不容許使用。該響應中必須包括一個Allow頭字段來列舉指定地址上所容許的方法。
19.4.7. 406 (Not Acceptable)
該響應表示，根據請求的Accept頭字段，該請求所指定的資源生成響應的消息體中包含的某些內容特性是不被接受的。
19.4.8. 407 (Proxy Authentication Required)
該響應相似於401 (Unauthorized)，不一樣的它指定客戶機必須首先向代理服務器鑑權本身。該狀態碼可用於接入到通訊信道中。
19.4.9. 408 (Request Timeout)
該響應表示服務器不能在適當的時長內產生響應。例如當它不能及時肯定用戶的位置時。客戶端收到該響應後，能夠不加修改便重發原請求。
19.4.10. 410 (Gone)
該響應表示服務器中被請求的資源不可用且服務器不知道轉發地址，而且這種狀況是永久性的。若是服務器不知道這種狀況是否爲永久性的，此時則應該使用404 (Gone)狀態碼。
19.4.11. 413 (Request Entity Too Large)
該響應表示，若是請求的消息體超出服務器可以處理範圍，服務器將拒絕處理該請求。服務器能夠關閉此鏈接以防客戶端不斷髮送同一個請求。
若是這種狀況是暫時的，服務器應在響應中加入一個Retry-After頭字段用來指定多久之後客戶機能夠重發該請求。
19.4.12. 414 (Request-URI Too Long)
該響應表示，若是Request-URI超出服務器可以處理的範圍，服務器將拒絕處理該請求。
19.4.13. 415 (Unsupported Media Type)
該響應表示服務器不支持某請求方法的消息體格式而拒絕處理該請求。根據具體內容的不一樣，服務器必須用響應Accept、Accept-Encoding或 Accept-Language頭字段返回服務器能夠接收的格式列表。
19.4.14. 416 (Unsupported URI Scheme)
該響應表示，因爲服務器不理解URI的方案而不能處理該請求。
19.4.15. 420 (Bad Extension)
該響應表示，服務器不理解Proxy-Require或Require 頭字段中協議的擴展規定。服務器必須在響應中的Unsupported字段中包含一個它不支持的擴展的列表。
19.4.16. 421 (Extension Required)
該響應表示，UAS須要某個特定的擴展才能處理該請求，可是這種擴展沒有列在請求中的Supported頭字段中。該響應必須包含一個Require頭字段列舉所須要的擴展。
除非UAS不能向客戶提供任何其餘所需的業務不然不該該使用該響應。若是Supported字段中沒有所需的擴展，服務器只能用客戶端所支持的擴展規定對該請求進行SIP的基本處理。
19.4.17. 423 (Interval Too Brief)
該響應表示，因爲請求更新資源的間隔時間過短，服務器拒絕該請求。註冊請求的Contact字段中定義的有效期過短，註冊服務器能夠使用該響應拒絕請求。
19.4.18. 480 (Temporarily Unavalilable)
該響應表示，與被叫方成功的聯繫上，可是被叫目前不可用者。在響應的Retry-After字段中能夠指定一個合適的呼叫時間，在緣由短語應該給出一個詳細的緣由指明爲何被叫方不可用。這個值能夠由UA來設置。
若是重定向服務器或者代理服務器知道Request-URI中指定的用戶可是目前並無其有效位置，就能夠返回該狀態碼。
19.4.19. 481 (Call/Transaction Does Not Exist)
該響應表示UAS收到的請求與現有的對話或者事務沒有相對應的。
19.4.20. 482 (Loop Detected)
該響應表示服務器檢測到有環路。
19.4.21. 483 (Too Many Hops)
該響應表示，服務器收到的請求中的Max-Forwards值爲零。
19.4.22. 484 (Address Incomplete)
該響應表示，服務器收到的Request-URI不完整並應在緣由短語中提供附加信息。該狀態碼容許異步撥號（overlapped dialing）。當用戶使用異步撥號的方式時並，客戶端並不知道撥號字串的的長度。所以它發送的字符串比實際的長，並提示用戶輸入更多的數字。直到再也不收到484狀態碼爲止。
19.4.23. 485 (Ambiguous)
該響應表示請求中的Request-URI不明確。該響應中的Contact字段中能夠包含另一個明確的地址，因爲顯示替代的Request-URI可能會破壞用戶或者組織的保密性。 這種狀況下，服務器必須能夠作出404(Not Found) 響應，或者服務器可以禁止列舉可能的URI選項。
例子以下：
sip:lee@example.com:
SIP/2.0 485 Ambiguous
Contact: Carol Lee <sip:carol.lee@example.com>
Contact: Ping Lee <sip:p.lee@example.com>
Contact: Lee M. Foote <sips:lee.foote@example.com>
有些電子信箱以及語音信箱系統能夠提供這種功能。該狀態碼與3xx狀態碼語義不一樣：對於300響應，假設能夠經過所提供的選項到達同一我的或者服務。自動化的選擇或者連續的查找只對3xx有意義，而使用485 (Ambiguous)響應時則須要用戶干涉。
19.4.24. 486 (Busy Here)
該響應表示，已經成功的和被叫終端鏈接，可是被叫目前不能在該終端系統執行呼叫，響應中的Retry-After字段能夠指定一個合適的呼叫時間。該用戶在其餘地方可用。若是客戶機知道沒有別的終端系統能夠接受本次呼叫那麼應該使用600 (Busy)狀態碼。
19.4.25. 487 (Requet Terminated)
該響應表示，請求被BYE或者CANCEL請求終止。CANCEL請求不能夠返回該響應。
19.4.26. 488 (Not Acceptable Here)
該響應與606 響應的含義相同，可是僅指Request-URI中指定的資源，若是在別處，該請求可能成功。
該響應中可能存在包含媒體能力描述的消息體，該消息體格式根據INVITE請求中的 Accept字段(若是不存在就是 application/sdp)規定。
19.4.27. 491 (Request Pending)
該響應表示，UAS收到請求可是在同一個對話中該UAS還有一個等待處理的請求。
19.4.28. 493 (Undecipherable)
該響應表示，UAS收到的請求包含一個加密的MIME消息體而接收方沒有合適的解碼密鑰。該響應能夠只包含一個消息體，該消息體包含一個公共密鑰用來加密發送給UA的MIME消息體。
19.5. 5xx (Server Failure)
該響應表示服務器內部出錯致使失敗。
19.5.1. 500 (Server Internal Error)
該響應表示，服務器遇到意外的狀況使它不能執行該請求。客戶端能夠顯示這種特定的出錯狀況，而且能夠幾秒鐘重發該請求。
若是狀況是暫時的，服務器能夠在Retry-After字段中指定多久以後客戶機能夠重發該請求。
19.5.2. 501 (Not Implemented)
該響應表示服務器不支持實現該請求所須要的功能。若是UAS沒法識別該請求的方法而且不支持該方法，就能夠發送該響應。若是爲代理服務器，它轉發請求時都不考慮請求的方法。
若是服務器識別了請求中的方法可是並不支持該方法應該發送405 (方法不容許)響應
19.5.3. 502 (Bad Gateway)
當服務器做爲網關或者代理服務器時，須要接入到某下行服務器來完成請求，該下行服務器發出該響應表示其爲無效網關。
19.5.4. 503 (Service Unavailable)
該響應表示因爲服務器過載或者正在維護而致使服務器暫時不能處理該請求。服務器能夠在Retry-After中指明什麼時候可重發該請求。若是沒有Retry-After則客戶端必須按照收到的是500 (Server Internal Error)響應處理。
代理服務器或 UAC收到一個該響應以後應該將該原請求轉發到替代的服務器上。若是響應中存在Retry-After字段，則在該字段定義的時間以內該客戶機不能再向原來的服務器發送任何請求。
服務器也能夠沒必要發送該響應，而直接拒絕鏈接或者丟棄原請求。
19.5.5. 504 (Server Time-out)
該響應表示，服務器接入到一個外部服務器來處理請求，可是沒有及時收到該外部服務器的響應。若是在Expires字段中規定的時間以內沒有收到上行服務器發來的響應，就應該使用408 (Request Timeout)響應。
19.5.6. 505 (Version Not Supported)
該響應表示服務器不支持請求中的協議的版本。
19.5.7. 513 (Message Too Large)
該響應表示，因爲消息體的長度超過服務器的處理能力限制，服務器不能處理該請求。
19.6. 6xx (Global Failures)
該響應表示服務器對於某一特定用戶的肯定的信息。
19.6.1. 600 (Busy Everywhere)
該響應表示與被叫終端鏈接成功，可是被叫由於忙而不能接收呼叫。該響應中的Retry-After字段指定過多久以後能夠從新呼叫。若是被叫不但願給出拒絕本次呼叫的緣由則應該使用603 (Decline)。該響應只用於客戶端知道沒有別的終端能夠接收該請求的狀況，不然應該返回486響應。
19.6.2. 603 (Decline)
該響應表示，與被叫已經成功鏈接，被叫用戶明確表示不能參與此呼叫。該響應中的Retry-After字段能夠指定過多久以後能夠從新呼叫。只有客戶端知道沒有別的終端能夠接收該請求才能夠使用該響應。
19.6.3. 604 (Does Not Exist Anywhere)
該響應通知服務器Request-URI中的用戶根本不存在。
19.6.4. 606 (Not Acceptable)
該響應表示與用戶代理已經成功鏈接，可是會話描述中如請求的媒體、帶寬或者地址形式等都不可接受。
該響應能夠包含一個Warning頭字段來詳細說明不支持該會話描述的緣由。
該響應中能夠有一個包含媒體能力描述的消息體，它的格式依據INVITE請求中的Accept頭字段，若是沒有該字段，則依據application/sdp。同OPTIONS請求消息的200 (OK)響應的消息體。
通訊中不但願有頻繁的協商，但若是一個新用戶被邀請參加原有的一個會議根據邀請發起者是否發送606響應來決定是否須要協商。
該響應只用於客戶機知道沒有別的終端能夠響應該請求。
20. IMS對SIP消息的擴展要求
20.1. 綜述
本章給出IMS網絡對SIP/SDP的一些基本擴展。在IMS網絡中採用SIP協議的IMS實體，如CSCF、MGCF、AS等都應該支持本章所列的擴展。
20.2. 頭字段擴展
20.2.1. Path頭字段
20.2.1.1. 概述
在IMS網絡中，新擴展了SIP協議的Path頭字段。
Path頭字段用來記錄REGISTER請求從用戶UE到S-CSCF（註冊服務器）之間的路由。經過該頭字段，用戶歸屬網絡的S-CSCF能夠知道用戶UE當前所接入的P-CSCF的地址，繼而將發往該用戶的請求（包括初始會話請求）經過該P-CSCF發送給用戶的UE。
20.2.1.2. 基本操做
Path頭字段的用法與Record-Route相似，可是隻能用在REGISTER及其200響應消息中。
如P-CSCF指望本身保留在後續發往UE的請求消息路由中，則將自已的URI插入到REGISTER請求的Path頭字段中，並置於頂端。
若是註冊服務器接受了註冊請求，則按照原順序將Path頭字段存儲起來，而後將Path頭字段的值複製到REGISTER請求的2xx響應中，當S-CSCF接收到發往用戶的請求時，就添加一個Route頭字段，其內容就是Path頭字段的內容。
20.2.1.3. Path的語法
Path = 「Path」 HCOLON path-value *(COMMA path-value)
Path-value = name-addr *(SEMI rr-param)
Path擴展的選項標籤（option-tag）是：path。
有關Path頭字段擴展的詳細內容見IETF RFC 3327.
20.2.2. Service-Route頭字段
20.2.2.1. 概述
與Path頭字段相對應，IMS網絡擴展了Service-Route頭字段。Service-Route頭字段用來記錄從用戶UE接入的P-CSCF到用戶歸屬的S-CSCF之間的路由。經過該頭字段，用戶UE能夠設置從接入的P-CSCF到歸屬網絡的S-CSCF的路由，將該用戶發起的請求（包括初始會話請求）直接發送給S-CSCF，而不須要再經過I-CSCF來轉接。
20.2.2.2. 基本操做
Service-Route頭字段只用在REGISTER請求的200響應中。
一般狀況下，S-CSCF能夠在REGISTER請求的200響應中插入Service-Route頭字段，並將該頭字段設爲本身的URI。
Path和Service-Route的關係相似於Record-Router和Route的關係，只不過前者用於註冊過程當中，然後才用於會話創建過程當中。
20.2.2.3. Service-Route的語法
Service-Route = 「Service-Route」 HCOLON sr-value *(COMMA sr-value)
Sr-value = name-addr *(SEMI rr-param)
有關Service-Route頭字段擴展的詳細內容見IEFT RFC 3608.
20.2.3. Orig參數
20.2.3.1. 概述
「Orig」參數是一個uri的參數（uri-parameter），用於向S-CSCF指示這是一個始發業務而不是一個終結業務，或向I-CSCF指示應該執行始發程序。該參數見3GPP TS 24.229規定。
20.2.3.2. 基本操做
在特定的業務中，AS在S-CSCF和I-CSCF地址的後面添加orig參數，當S-CSCF發現其地址後有orig參數，則觸發相關始發業務；當I-CSCF發現其址後有orig參數，則執行相關的始發程序。
20.2.3.3. Orig參數的語法
Orig參數的語法格式以下所示：
Uri-parameter=transport-parm / user-param /method-param /ttl-param / maddr-param /lr-param /orig / other-param
orig=」orig」
20.2.4. P-Associated-URI頭字段
20.2.4.1. 概述
P-Associated-URI頭字段使得S-CSCF（註冊服務器）能夠返回與註冊的地址記錄（AOR）相關聯的一組URI地址，從而使得用戶在註冊一個URI地址時，能夠隱性註冊他本身的其餘相關聯的URI地址。
20.2.4.2. 基本操做
P-Associated-URI頭字段只用在REGISTER的200響應中，由歸屬網絡的S-CSCF在REGISTER的200響應中插入。
P-CSCF須要保存P-Associated-URI中含有顯示名字的公有用戶標識，而且將這些標識與已註冊的公有用戶標識進行關聯，例如已註冊的用戶標識和相關聯的隱性註冊的身份。
若是P-Associated-URI中包含顯示名字，P-CSCF須要保存含有顯示名字的缺省的公有用戶標識。P-Associated-URI中包含該用戶全部的公有用戶標識，可是並不是都是已註冊的標識。第一個URI是已經註冊的公有用戶標識，P-CSCF應該將P-Associated-URI中的第一個URI作爲用戶缺省的公有用戶標識。
20.2.4.3. P-Associated-URI語法
P-Associated-URI = "P-Associated-URI" HCOLON (p-aso-uri-spec)*(COMMA p-aso-uri-spec)
p-aso-uri-spec = name-addr *(SEMI ai-param)
ai-param = generic-param
有關P-Associated-URI頭字段擴展的詳細內容見IETF RFC 3455。
20.2.5. P-Called-Party-ID
20.2.5.1. 概述
當被叫用戶的S-CSCF收到初始請求以後，會修改請求中的Request-URI爲被叫用戶註冊的Contact地址，爲了避免丟失原來的Request-URI信息，即被叫用戶的公有用戶標識，將該信息保存在P-Called-Party-ID頭字段中。
20.2.5.2. 基本操做
被叫用戶歸屬網絡的S-CSCF在將初始請求（包括INVITE、SUBSCRIBE、OPTION、MESSAGE、REFER請求）轉發給被叫用戶的P-CSCF時，會用被叫用戶註冊的Contact地址覆蓋請求消息中的Request-URI。爲了使被叫用戶知道該請求是發往哪一個公有用戶標識，S-CSCF應該在初始請求中增長P-Called-Party-ID頭字段，用該頭字段攜帶原來請求中的Request-URI，即被叫用戶的公有用戶標識。
被叫用戶的P-CSCF在收到UE發送來的對上述請求的1XX或2XX響應時，應該刪除P-Preferred-Identity，而根據P-Called-Party-ID生成P-Asserted-Identity。
20.2.5.3. 5.6.3 P-Called-Party-ID的語法
P-Called-Party-ID = "P-Called-Party-ID" HCOLON called-pty-id-spec
called-pty-id-spec = name-addr *(SEMI cpid-param)
cpid-param = generic-param
有關P-Called-Party-ID頭字段擴展的詳細內容見IETF RFC 3455。
20.2.6. P-Visited-Network-ID
20.2.6.1. 概述
P-Visited-Network-ID頭字段用來向用戶的歸屬網絡指示用戶當前漫遊的網絡的標誌，便於歸屬網絡查找與漫遊網絡的漫遊協議。
P-Visited-Network-ID頭字段可由拜訪網絡的P-CSCF在INVITE、REGISTER、SUBSCRIBE、OPTION、MESSAGE、REFER請求中提供。
20.2.6.2. 基本操做
P-CSCF在REGISTER請求消息中必須攜帶P-Visited-Network-ID頭字段，其餘請求消息不做要求。S-CSCF在將該頭字段路由出歸屬網絡時，應刪除該頭字段。若是S-CSCF的下一跳仍是在歸屬網絡中時，也建議在請求中刪除該頭字段。
20.2.6.3. P-Visited-Network-ID的語法
P-Visited-Network-ID = "P-Visited-Network-ID" HCOLON vnetwork-spec *(COMMA vnetwork-spec)
vnetwork-spec = (token / quoted-string) *(SEMI vnetwork-param)
vnetwork-param = generic-param
有關P-Visited-Network-ID頭字段擴展的詳細內容見IETF RFC 3455。
20.2.7. P-Access-Network-Info
20.2.7.1. 概述
P-Access-Network-Info頭字段用來向歸屬網絡指示用戶接入IMS網絡的接入方式和用戶位置信息。
20.2.7.2. 基本操做
P-Access-Network-Info頭字段由UE在其發送的每個請求（包括ACK和CANCEL）或響應中插入，可是該請求應具備完整性保護時才能夠攜帶該字段。
CSCF不能插入或修改P-Access-Network-Info頭字段，除非UE不能插入該字段。
S-CSCF應在將消息轉發出去時刪除P-Access-Network-Info頭字段，除非下一跳是與S-CSCF同在一個信任域內的AS。
20.2.7.3. P-Access-Network-Info的語法
P-Access-Network-Info = 「P-Access-Network-Info」 HCOLON access-net-spec *(COMMA access-net-spec)
access-net-spec = access-type [SEMI np] *(SEMI access-info)
access-type = "IEEE-802.11" / "IEEE-802.11a" / "IEEE-802.11b" / "IEEE-802.11g" / "3GPP-GERAN" / "3GPP-UTRAN-FDD" / "3GPP-UTRAN-TDD" / "ADSL" / "ADSL2" / "ADSL2+" / "RADSL" / "SDSL" / "HDSL" / "HDSL2" / "G.SHDSL" / "VDSL" / "IDSL" / "3GPP2-1X" / "3GPP2-1X-HRPD" / "DOCSIS" / token
np = "network-provided"
access-info = cgi-3gpp / utran-cell-id-3gpp / dsl-location / i-wlan-node-id / ci-3gpp2 / extension-access-info
extension-access-info = gen-value
cgi-3gpp = "cgi-3gpp" EQUAL (token / quoted-string)
utran-cell-id-3gpp = "utran-cell-id-3gpp" EQUAL (token / quoted-string)
i-wlan-node-id = "i-wlan-node-id" EQUAL (token / quoted-string)
dsl-location = "dsl-location" EQUAL (token / quoted-string)
ci-3gpp2 = "ci-3gpp2" EQUAL (token / quoted-string)
有關P-Access-Network-Info頭字段擴展的詳細內容和具體參數的取值見IETF RFC 3455和3GPP TS 24229。
20.2.8. P-Charging-Function-Address
20.2.8.1. 概述
P-Charging-Function-address用來指示本網絡內的在線計費功能和離線計費功能的地址。IMS中使用的計費功能地址包括計費數據功能（CDF）地址和在線計費功能 （OCF）地址，CDF用於離線計費，OCF用於在線計費。
計費功能地址由用戶的歸屬網絡分配，用於其餘實體向該地址發送計費信息。
P-Charging-Function-Addresses 頭字段中的參數，CDF 中使用"ccf"，OCF中使用"ecf"。
20.2.8.2. 5.9.2 基本操做
在一個P-Charging-Function-address頭字段中可能存在多個CDF地址和OCF地址。每一個ccf 或 ecf參數至少含有一個地址。第一個地址是首選的，對於每一個網絡來講，第二個地址都是用於備份的。
CDF的地址和OCF的地址由歸屬網絡的S-CSCF從HSS中獲取並傳遞到其餘網元，並僅在歸屬網絡內傳遞，由歸屬網絡的邊界節點負責刪除。
S-CSCF應在收到的初始請求或響應中添加P-Charging-Function-address頭字段，發送給用戶iFC中包含的全部位於歸屬網絡的AS，或者用戶歸屬網絡內的P-CSCF或I-CSCF；在向其餘網絡轉發請求以前刪除該字段。
20.2.8.3. 5.9.3 P-Charging-Function-Address的語法
P-Charging-Addr = "P-Charging-Function-Addresses" HCOLON charge-addr-params * (SEMI charge-addr-params)
charge-addr-params = ccf / ecf / generic-param
ccf = "ccf" EQUAL
gen-value ecf = "ecf" EQUAL gen-value
有關P-Charging-Function-Address頭字段擴展的詳細內容見IETFRFC 3455。
20.2.9. P-Charging-Vector
20.2.9.1. 概述
P-Charging-Vector頭字段用於在IMS網絡實體之間傳送IMS計費標識（ICID）和相關的計費信息，包括IMS計費標識icid、始髮網絡運營商標識、終結網絡運營商標識以及接入網計費信息參數等信息。
20.2.9.2. 5.10.2 基本操做
發起方的P-CSCF應在從UE收到的初始請求中添加P-Charging-Vector頭字段。
接收方的P-CSCF應在從UE接收到的第一個響應中添加P-Charging-Vector頭字段。 P-Charging-Vector頭字段攜帶如下兩個信息：
² IMS計費標識（ICID）：IMS計費標識是IMS網元（包括AS）之間共享的一個會話級的標識，IMS實體之間經過ICID來關聯相關的CDR。ICID也用在獨立事務的請求消息中（如SUBSCRIBE、NOTIFY、MESSAGE）。P-CSCF在請求或響應中添加P-charging-Vector 頭字段，並在該頭字段中給出ICID參數。在響應中添加的ICID的值應該與同一事務的請求中的ICID的值相同。信令沿途的的IMS網元都應該將ICID保存到本地。
² 運營商間標識（IOI）：運營商間標識是在發送網絡、接收網絡和內容提供商之間共享的一個全球惟一的標識。發送網絡在請求消息的P-Charging-Vector頭字段中插入「orig-ioi」參數，用來指示請求始發的運營商網絡；接收網絡在響應消息中插入的「term-ioi」參數，則用來指示產生該響應消息的運營商網絡。有三種類型的IOI參數：
- 1類IOI：在P-CSCF（一般是拜訪網絡）和歸屬網絡的S-CSCF之間傳遞，1類始發和終結的IOI參數經過REGISTER請求和響應消息進行交換；
- 2類IOI：在始髮網絡的S-CSCF和終結網絡的S-CSCF之間傳遞，或在始髮網絡的S-CSCF和MGCF（終結網絡爲PSTN/PLMN/軟交換）之間傳遞，或在MGCF（始髮網絡爲PSTN/PLMN/軟交換）和終結網絡的S-CSCF之間傳遞。2類始發和終結的IOI參數經過與會話有關或無關的請求和響應消息進行交換；
- 3類IOI：在歸屬運營商的S-CSCF/I-CSCF和任意的AS之間傳遞， 3類始發和終結的IOI參數經過與會話有關或無關的請求和響應消息進行交換。
P-CSCF、I-CSCF、S-CSCF或AS在收到IOI參數後，都須要將該參數存到本地，在後續的請求或響應消息中都應該添加適當類型的「orig-ioi」和「term-ioi」參數。
20.2.9.3. P-Charging-Vector的語法
P-Charging-Vector = "P-Charging-Vector" HCOLON icid-value *(SEMI charge-params)
charge-params = icid-gen-addr / orig-ioi / term-ioi / access-network-charging-info / generic-param
icid-value = "icid-value" EQUAL gen-value
icid-gen-addr = "icid-generated-at"
EQUAL host orig-ioi = "orig-ioi" EQUAL gen-value
term-ioi = "term-ioi" EQUAL gen-value
access-network-charging-info = (gprs-charging-info / i-wlan-charging-info / xdsl-charging-info / packetcable-charging-info / generic-param) gprs-charging-info = ggsn SEMI auth-token [SEMI pdp-info-hierarchy] *(SEMI extension-param)
ggsn = "ggsn" EQUAL gen-value
pdp-info-hierarchy = "pdp-info" EQUAL LDQUOT pdp-info *(COMMA pdp-info) RDQUOT pdp-info = pdp-item SEMI pdp-sig SEMI gcid [SEMI flow-id] pdp-item = "pdp-item" EQUAL DIGIT
pdp-sig = "pdp-sig" EQUAL ("yes" / "no") gcid = "gcid" EQUAL 1*HEXDIG
auth-token = "auth-token" EQUAL 1*HEXDIG
flow-id = "flow-id" EQUAL "(" "{" 1*DIGIT COMMA 1*DIGIT "}" *(COMMA "{" 1*DIGIT COMMA 1*DIGIT "}")")"
extension-param = token [EQUAL token] i-wlan-charging-info = "pdg"
xdsl-charging-info = bras SEMI auth-token [SEMI xDSL-bearer-info] *(SEMI extension-param) bras = "bras" EQUAL gen-value
xDSL-bearer-info = "dsl-bearer-info" EQUAL LDQUOT dsl-bearer-info *(COMMA dsl-bearer-info) RDQUOT
dsl-bearer-info = dsl-bearer-item SEMI dsl-bearer-sig SEMI dslcid [SEMI flow-id] dsl-bearer-item = "dsl-bearer-item" EQUAL DIGIT
dsl-bearer-sig = "dsl-bearer-sig" EQUAL ("yes" / "no") dslcid = "dslcid" EQUAL 1*HEXDIG
packetcable-charging-info = packetcable [SEMI bcid] packetcable = "packetcable-multimedia" bcid = "bcid" EQUAL 1*48(HEXDIG)
其中，access-network-charging-info見3GPP TS 24.229對IETF RFC 3455的擴展。 有關P-Charging-Vector頭字段擴展的詳細內容見IETF RFC 3455.
20.3. 鑑權參數
20.3.1. 概述
IMS對SIP協議的WWW-Authenticate頭字段定義了一個新的「auth-param」參數值。該參數主要用在401（REGISTER）響應中，用於攜帶IK（完整性密鑰）和CK（加密密鑰）向UE發起質詢。
同時，也對SIP協議的Authorization頭字段定義了一個新的「auth-param」參數值。該參數主要用在REGISTER請求中，攜帶「integrity-protected」參數，用於P-CSCF檢查UE發送的註冊請求是否被修改過。
這個參數見3GPP TS 24.229的規定。
20.3.2. 基本操做
20.3.2.1. WWW-Authenticate擴展的auth-param參數
S-CSCF在執行認證過程當中，若是採用IMS-AKA認證方式，則須要從HSS下載S-CSCF所需的全部與安全相關的參數，即所謂的認證向量（AV）。
認證向量包括如下參數：
² 隨機質詢（RAND）；
² 指望的結果（XRES）；
² 網絡鑑權令牌（AUTN）；
² 完整性密鑰（IK）；
² 加密密鑰（CK）。
在註冊過程當中，用戶的UE首先發出初始REGISTER請求。因爲初始REGISTER未帶任何認證信息，歸屬網絡的S-CSCF應返回401響應，並在響應的WWW-Authenticate頭字段中給出從HSS下載的RAND、AUTN、IK和CK參數，其中IK和CK參數爲新擴展的參數。
P-CSCF在收到401響應後，應該保存IK和CK參數，並將這兩個參數從401響應中刪除，以後，再將401響應轉發給用戶的UE。
用戶的UE經過AUTN對歸屬網絡進行鑑權，判斷該401響應是不是本身的歸屬網絡所發送的。若是UE確認該401響應是本身歸屬網絡的S-CSCF發送的，則UE會經過401響應中提供的RAND和共享密鑰計算出質詢響應RES，同時也會計算出IK。UE會將RES放在第二個REGISTER請求的Authorization頭字段中，經過P-CSCF發送給S-CSCF。
S-CSCF應該將接收到的RES與AV中的XRES相比較，若是這兩個參數徹底相同，則S-CSCF就成功的完成了對用戶的認證。
UE計算出來的IK、P-CSCF從S-CSCF得到的IK將做爲它們之間創建安全關聯的共享密鑰。
20.3.2.2. Authorization擴展的auth-param參數
「integrity-protected」參數由P-CSCF在REGISTER請求的Authorization頭字段中添加。若是REGISTER消息是從與UE創建的安全關聯上收到的，同時包含鑑權響應參數，則「integrity-protected」應設成「yes」，不然設爲「no」。S-CSCF會根據此信息決定是否須要向收到的REGISTER請求發起質詢。 5.11.3 相關擴展參數的語法
20.3.2.3. 對WWW-Authenticate頭字段的auth-param參數的擴展
auth-param = 1#( integrity-key / cipher-key )
integrity-key = "ik" EQUAL ik-value
cipher-key = "ck" EQUAL
ck-value ik-value = LDQUOT *(HEXDIG) RDQUOT
ck-value = LDQUOT *(HEXDIG) RDQUOT
20.3.2.4. 對Authorization頭字段的auth-param參數的擴展
auth-param = "integrity-protected" EQUAL ("yes" / "no" / "tls-yes")
20.4. 安全機制的協商
20.4.1. 概述
爲了保證UE和P-CSCF之間傳遞的消息的安全性，UE和P-CSCF之間須要協商並採用一個共同的安全機制。目前，UE和P-CSCF之間至少須要支持IPSec安全機制。他們之間經過新擴展的Security-Client、Security-Server和Security-Verify三個頭字段進行協商所採用的安全機制，以及告訴對方本身受保護的客戶端和服務器端口。
20.4.2. 5.12.2 基本操做
Security-Client一般在初始REGISTER請求中用於指示UE所支持的安全機制、加密算法以及本身的受保護的客戶端和服務器端口等信息。
Security-Server在由P-CSCF到REGISTER的401響應中，用來指示P-CSCF所支持的安全機制、加密算法以及本身的受保護的客戶端和服務器端口等信息。
UE經過Security-Verify對P-CSCF的相關安全信息進行確認。 經過這三個頭字段的三次握手，UE和P-CSCF之間就能夠協商好所採用的安全機制和彼此的受保護的服務器端口和客戶端端口。
爲了確保全部請求和響應都是經過IPSec安全關聯發出，P-CSCF須要在發往UE的每個初始請求或響應的Record-Route頭字段中，將其受保護的服務器端口設爲其地址的一部分。因爲受保護的端口號信息僅是在UE和P-CSCF之間有意義，因此，P-CSCF在將請求或響應消息轉發給S-CSCF或其餘實體以前，在指示本身地址的Via、Record-Route頭字段中不用添加受保護的端口信息。
而對於UE，則須要：
² 在每一個請求消息的Contact和Via（不包括初始REGISTER請求的Via）頭字段中，將受保護的服務器端口設置爲其地址的一部分；
² 在它發出的每一個初始請求的Route頭字段中，將P-CSCF受保護的服務器端口做爲P-CSCF地址的一部分。
Security-Client、Security-Server和Security-Verify頭字段的具體用法見3GPP TS 33.203附錄H的相關要求。
20.4.3. Security-Client、Security-Server和Security-Verify頭字段的語法
security-client = "Security-Client" HCOLON sec-mechanism *(COMMA sec-mechanism) security-server = "Security-Server" HCOLON sec-mechanism *(COMMA sec-mechanism) security-verify = "Security-Verify" HCOLON sec-mechanism *(COMMA sec-mechanism) sec-mechanism = mechanism-name *(SEMI mech-parameters)
mechanism-name = "ipsec- 3gpp" / "tls" mech-parameters = ( preference / algorithm / protocol / mode / encrypt-algorithm / spi-c / spi-s / port-c / port-s )
preference = "q" EQUAL qvalue qvalue = ( "0" [ "." 0*3DIGIT ] ) / ( "1" [ "." 0*3("0") ] ) algorithm = "alg" EQUAL ( "hmac-md5-96" / "hmac-sha-1-96" )
protocol = "prot" EQUAL ( "ah" / "esp" )
mode = "mod" EQUAL ( "trans" / "tun"/ "UDP-enc-tun" )
encrypt-algorithm = "ealg" EQUAL ( "des-ede3-cbc" /"aes-cbc" / "null" )
spi-c = "spi-c" EQUAL
spivalue spi-s = "spi-s" EQUAL spivalue
spivalue = 10DIGIT; 0 to 4294967295
port-c = "port-c" EQUAL port
port-s = "port-s" EQUAL port
port = 1*DIGIT
20.5. 前提條件
20.5.1. 概述
爲了不在資源預留好以前就向被叫用戶振鈴，在IMS網絡對SIP和SDP協議進行了擴展，引入了前提條件的概念。前提條件與會話中的媒體流的資源預留狀況相關聯，只有知足了前提條件，即預留了指望的資源以後，才向被叫用戶振鈴。
前提條件主要擴展了SDP的三種屬性：當前狀態（curr）、指望狀態（des）和確認狀態（conf），分別表示指定的媒體流當前資源預留的狀況、指望的資源預留狀態和用於請求對端發送資源預留確認的條件。
爲了保證通訊實體對前提條件的正確處理，同時，也引入了一個新擴展的SIP選項標籤（option-tag）「precondition」。
20.5.2. 5.13.2 基本操做
在IMS中，前提條件是與會話相關的網元應支持的能力，可是在一次會話中是否採用，取決於具體的應用場景。
若是主叫用戶是經過無線方式接入到IMS網絡，則主叫用戶接入側應該採用前提條件。本部分規定，若是主叫用戶支持前提條件，因爲並未明確被叫用戶是否支持前提條件，所以「precondition」的擴展選項標籤應經過Support頭字段來攜帶，而不能經過Required頭字段來攜帶。
若是主叫用戶是經過無線方式接入到IMS網絡，採用前提條件的處理方式以下：
若是主叫側資源沒有準備好，將在SDP中將媒體置成「Inactive」。若是被叫用戶回送的響應消息中代表被叫側確實不支持前提條件，則主叫側應該將資源預留好，以後經過re-INVITE/UPDATE方式從新與被叫創建會話。
若是主叫側資源已經準備好，則經過Support來攜帶「precondition」，並在SDP中攜帶本身所支持的媒體格式，被叫側能夠根據本身的狀況進行媒體協商或者資源預留。
若是主叫用戶是經過固定方式接入到IMS網絡的，則能夠不採用前提條件。若是採用前提條件，應與無線接入的處理方式一致。
被叫用戶在會話的創建過程當中能夠採用前提條件。可是，若是主叫用戶不支持前提條件，則被叫側不能採用前提條件。在被叫側不採用前提條件時，UE應在向用戶振鈴以前，先預留好本地接入的資源。
UE在使用前提條件時，應遵守IETF RFC 3312中的有關處理程序。資源預留採用分段預留方式，而不採用端到端的方式，即status-type只採用「local」或「remote」，不採用「e2e」。
有關前提條件具體的擴展內容見IETF RFC3312和IETF RFC4032。
20.5.3. 5.13.3 前提條件的相關參數的語法
current-status = "a=curr:" precondition-type SP status-type SP direction-tag
desired-status = "a=des:" precondition-type SP strength-tag SP status-type SP direction-tag
confirm-status = "a=conf:" precondition-type SP status-type SP direction-tag
precondition-type = "qos" | token
strength-tag = ("mandatory" | "optional" | "none" | "failure" | "unknown")
status-type = ("e2e" | "local" | "remote")
direction-tag = ("none" | "send" | "recv" | "sendrecv")
注：目前只規定了qos一種前提類型，這個類型主要依賴於無線鏈路上預留的帶寬以及網絡中路由器對傳輸大量語音和數據的分組數據的處理優先級。
20.6. SIP信令壓縮
20.6.1. 概述
爲了節省空中接口的資源，須要對SIP協議進行壓縮。SIP協議的壓縮對IMS網絡來講是一個很是重要的應用。
當UE經過無線方式接入到P-CSCF時，即P-Access-Network-Info頭字段包含下列任意取值時， P-CSCF和UE之間的SIP消息應該進行壓縮：
² 3GPP-GERAN；
² 3GPP-UTRAN-FDD；
² 3GPP-UTRAN-TDD；
² 3GPP2-1X；
² 3GPP2-1X-HRPD。
對於這類UE和P-CSCF來講，應支持SIP壓縮，但不必定啓用SIP壓縮。UE和P-CSCF能夠經過協商說明是否願意使用SIP壓縮。P-CSCF和經過無線方式接入的UE應符合IETF RFC3486定義的壓縮協商機制以及IETF RFC3320中規定的信令壓縮規範。
用於指示是否支持信令壓縮的SIP機制見IETF RFC3486的規定，具體的方式是在Via頭字段和SIP URI中分別擴展了一個comp參數，且目前爲該參數只定義了一個值：comp=SigComp，用來指示是否願意使用信令壓縮。
信令壓縮的具體規範見IETF RFC348六、IETF RFC3320、IETF RFC4896的規定。
20.6.2. 5.14.2 基本操做
若是UE在REGISTER請求的Contact頭字段中添加「comp=SigComp」參數，則表示UE在後續的以本身爲目的的初始請求中願意採用壓縮形式。
UE做爲請求發起方，若是UE在初始請求的Contact頭字段中添加「comp=SigComp」參數，則表示UE接受該對話的全部後續請求願意採用壓縮形式。
UE做爲請求接收方，若是UE在初始請求的第一個響應中的Contact頭字段中添加「comp=SigComp」參數，則表示UE接受該對話的全部後續請求願意採用壓縮形式。
若是UE在任何請求消息的Via頭字段中添加「comp=SigComp」參數，則表示UE願意接受對這個請求的全部響應採用壓縮形式。
若是P-CSCF在發往UE的消息中對應於本身的Record-Route中添加「comp=SigComp」參數，則表示P-CSCF願意接受該對話的後續請求採用壓縮形式。
若是P-CSCF在任何請求的Via頭字段中添加「comp=SigComp」參數，則表示P-CSCF願意接受該請求的全部響應採用壓縮形式。
20.6.3. 5.14.3 相關語法
與SIP信令壓縮相關的擴展參數的語法以下：
² 對於URI來講，SIP壓縮擴展的是「uri-parameter」：
compression-param = "comp=" ("sigcomp" / other-compression)
other-compression = token
² 對於Via頭字段來講，SIP壓縮擴展的是「via-extension」參數：
via-compression = "comp" EQUAL ("sigcomp" / other-compression)
other-compression = token
20.7. IMS網絡中的SIP定時器
信令消息在空中接口的處理會帶來傳輸的時延，所以YD/T 1522.1中規定的一些SIP定時器在某些狀況下可能須要修改。表6給出在IMS網絡中的一些SIP定時器的建議值。
表6的第一列給出了YD/T 1522.1定義的定時器；第二列給出了該這些定時器的默認值，適用於IMS網絡中CSCF、MGCF等網元設備之間的通訊，不適用於空中接口。
當UE經過無線方式接入到P-CSCF時，即P-Access-Network-Info頭字段包含5.14.1節所提到的任意取值時，P-CSCF採用第三列的取值。其餘狀況下，P-CSCF仍是採用SIP定時器默認的取值，即第一列的取值。
SIP定時器
| SIP定時器 |
IMS網元默認設置 |
與無線接入的UE相連的P-CSCF |
含義 |
| T1 |
500ms（缺省） |
2s |
往返時間（RTT）的估值 |
| T1 |
4s |
16s |
非INVITE請求和INVITE響應的最大重傳間隔 |
| T4 |
5s |
17s |
消息在網絡中的最大時長 |
| Timer A |
Initially T1 |
Initially T1 |
INVITE重傳間隔（UDP） |
| Timer B |
64*T1 |
64*T1 |
INVITE事務超時定時器 |
| Timer C |
> 3min |
> 3min |
Proxy中的INVITE事務超時定時器 |
| Timer D |
> 32s(UDP) |
> 128s |
等待響應重傳的時間 |
| 0s(TCP/SCTP) |
0s(TCP/SCTP) |
||
| Timer E |
初始的T1 |
初始的T1 |
非INVITE請求的重傳間隔（UDP） |
| Timer F |
64*T1 |
64*T1 |
非INVITE事務超時定時器 |
| Timer G |
初始的T1 |
初始的T1 |
INVITE的響應的重傳間隔 |
| Timer H |
64*T1 |
64*T1 |
等待ACK的時間 |
| Timer I |
T4(UDP) |
T4(UDP) |
等待ACK重傳的時間 |
| 0s(TCP/SCTP) |
0s(TCP/SCTP) |
||
| Timer J |
64*T1 for UDP |
64*T1(UDP) |
等待非INVITE請求重傳的時間 |
| 0s(TCP/SCTP) |
0s(TCP/SCTP) |
||
| Time K |
T4(UDP) |
T4(UDP) |
等待響應重傳的時間 |
| 0s(TCP/SCTP) |
0s(TCP/SCTP) |
20.8. SIP協議的應用
IMS域網元實體在SIP消息流程中的具體行爲詳情見《IMS核心業務流程.doc》
20.8.1. P-CSCF處理過程
20.8.1.1. 概述
P-CSCF應支持Path和Service-Route頭字段。Path頭字段僅僅用於REGISTER請求和它的200OK響應中。Service-Route頭字段用於註冊請求的200OK響應消息中。
P-CSCF在向UE發送任何請求或者響應前，P-CSCF應去除消息中存在的P-Charging-Function-Addresses和P-Charging-Vector頭字段。
一旦 P-CSCF接收到UE發出的任何響應或者請求，P-CSCF 將：
² 去除存在的P-Charging-Function-Addresses和P-Charging-Vector頭字段並忽略該頭字段中的數據。
² 在傳遞該消息時，能夠插入先前保存的數據到P-Charging-Function-Addresses和P-Charging-Vector頭字段中。
若是P-CSCF部署在拜訪網絡時，它忽略S-CSCF和I-CSCF發送來的消息的P-Charging-Function-Addresses。
當請求或響應消息中的P-Access-Network-Info頭字段帶有「network-provided」參數，P-CSCF應移除P-Access-Network-Info頭字段
當P-CSCF 接收到來自S-CSCF 的任何請求和響應，P-CSCF 將去除消息體中P-Media-Authorization 頭。
注3： 若是基於本地策略業務應用時，P-CSCF將插入P-Media-Authorization頭，見5.2.7.2 和5.2.7.3。
注4： P-CSCF將對發往UE的註冊和認證之外的SIP消息，進行安全性保護。P-CSCF將丟棄沒有完整性保護的sip消息（註冊和認證消息除外）。註冊和認證處理中完整性保護和檢查在5.2.2中進行了定義。
除了 305（Use Proxy）響應，P-CSCF 不會重複回覆3xx 響應。
20.8.1.2. 註冊
P-CSCF應使用SIP默認端口接收初始註冊請求。P-CSCF僅使用相同的端口接收後安全保護的註冊消息及後續的SIP消息，無需使用協商端口交換受保護的消息。
當P-CSCF 接收到一個UE發起的註冊請求：
1) 在消息體中增長一上Path頭字段，並將P-CSCF的SIP URI設置到Path頭字段中，使之後全部發送給用戶的消息都通過P-CSCF傳送
2) 增長Require頭字段，包括「path」選項標籤；
3) 增長P-Visited-NetWork-ID頭字段，內容是本身的網絡標識，歸屬網絡經過該標識可獲目前正服務於用戶的拜訪網絡
4) 插入P-Charging-Vector頭，包括icid、orig-ioi等參數，參看3GPP TS 32.260 中的描述；
5) 當註冊請求受到認證過程當中的完整性保護且包括認證挑戰響應，或者該請求在成功認證後安全關聯建立且沒有認證挑戰響應時，在Authorization頭中，插入"integrity-protected"參數值設置爲"yes"，其餘狀況該參數設置爲「No」。
5) 當註冊請求沒有完整性保護時，將檢查Security-Client是否存在。若是存在，則去除並保存，若是不存在，P-CSCF則回覆4xx響應。
6) 當註冊請求帶有完整性保護，則P-CSCF應：
a) 檢查受保護請求的安全關聯。若是安全關聯是一個臨時的，因而請求消息中指望帶上Security-Verify和Security-Client頭字段。若是沒有，P-CSCF將返回4xx響應。若是有，P-CSCF將對比請求消息中Security-Verify和P-CSCF發送給UE的認證消息中Security-Server內容，以及請求中Security-Client和被挑戰註冊請求中Security-Client內容。若是不匹配，可能存在中間攻擊。該請求應該被拒絕，經過發送4xx響應。若是匹配，P-CSCF將去除Security-Verify 和Security-Client頭。
b) 若是註冊請求中安全關聯已經創建，則：
- 消息體中若是有Security-Verify頭，則P-CSCF將去除之；
- Security-Client頭中包含新的參數值，若是缺乏該頭或者必須的參數，P-CSCF將返回4xx響應。
- P-CSCF將傳遞消息給S-CSCF前，將保存並去除Security-Client頭中內容；
c) P-CSCF將檢查具備完整性保護的註冊消息中Authorization頭中的私有用戶標識是否與先前被挑戰或被認證的私有用戶標識一致。若是不一樣，P-CSCF回覆403(Forbidden)響應。
7) 插入P-Visited-Network-ID頭，設置爲先前提供的，用於標識拜訪網絡的值。
8) 決定歸屬網絡的I-CSCF，並將請求消息發往該I-CSCF。
若是被選擇的I-CSCF：
- 不響應註冊請求，僅做爲中繼，或者
- 對於註冊請求，發送3xx（重定向）響應和480（臨時無效）響應，
則P-CSCF將選擇一個新的I-CSCF，併發送初始的註冊請求。
注1： I-CSCF的列表能夠是RFC 3263中描述得到，或者在P-CSCF中設定的。
若是P-CSCF傳遞註冊請求到I-CSCF失敗，P-CSCF將發送408（請求超時）響應或者504（服務器超時）響應，參看RFC3261處理過程。
當 P-CSCF 接收到註冊請求的401（未鑑權）響應時：
1) 刪除與UE之間，臨時創建的安全關聯；
2) 移除401響應消息中的CK IK參數，並與對應的私有用戶標識和臨時安全關聯進行綁定。當移除CK、IK後，P-CSCF將傳遞401響應給UE。
3) 插入Security-Server頭，頭中包括P-CSCF靜態安全列表和3GPP TS 33.203 附錄H中描述的安全關聯參數。在RFC 3329中，P-CSCF將支持"ipsec-3gpp"安全機制。在Ipsec層算法上，P-CSCF 將支持HMAC-MD5-96 (RFC 2403 [20C]) 和HMAC-SHA-1-96(RFC 2404) ；
4) 利用UE和P-CSCF之間私有用戶標識的臨時SIP層生命期，創建一個臨時安全關聯。進一步描述參看3GPP TS 33.203 [19] 和 RFC 3329 [48]。P-CSCF將設置臨時SIP層生命期爲臨時安全關聯等待註冊鑑權時間。
用註冊請求受保護的安全關聯向UE發送401響應，或者用註冊請求沒有受保護的安全關聯發送響應。
注2： S-CSCF發送到UE的401挑戰響應，做爲註冊的響應，P-CSCF插入Security-Server頭。
P-CSCF在註冊過程當中，和UE之間協商和設置兩套安全關聯設置，S-CSCF將對UE進行認證。進一步的描述參看3GPP TS 33.203 [19]。
當 P-CSCF 接收到註冊請求的200OK 響應時，P-CSCF 將檢查Expires 頭或者contact 頭中expires 中的值。若是值不等於0，P-CSCF 將：
1) 按照順序保存Service-Route頭列表，P-CSCF將爲各個公有用戶標識保存註冊有效期。P-CSCF將用列表做爲可用路由信息。若是註冊是刷新註冊，P-CSCF將取代已存在的Service-Route列表。
2) 關聯Service-Route頭列表和已註冊的公有用戶標識（難道不一樣pui會不一樣的Service-Route？）；
3) 存儲P-Associated-URI頭中，與註冊的公有用戶標識相關聯的公有用戶標識。
4) 存儲P-Associated-URI頭列表中第一公有用戶標識做爲默認公有用戶標識，以便後續使用。
注3： 當多個公有用戶標識註冊時，P-CSCF可能存儲多個默認公有用戶標識。
5) 存儲P-Charging-Function-Addresses中的值；
6) 若是安全關聯有效，設置安全關聯的SIP層生命期，採用先前存在的安全關聯生命期和完成的註冊生命期加上30s，二者間的最大值。
7) 若是存在的是臨時安全關聯，則改變其爲新的安全關聯設置，好比採用先前存在的安全關聯生命期和完成的註冊生命期加上30s，二者間的最大值來設置SIP層生命期。
8) 採用請求消息採用的安全關聯的保護措施，進行200OK響應的保護。
當 P-CSCF 從UE 接收到基於新的安全關聯的SIP 消息（包括註冊請求），而P-CSCF 側尚未使用新的安全關聯，則：
1) 減小安全關聯老的設置的SIP層生命期爲64*T1（若是當前值大於64*T1）；
2) 對後續給UE的消息採用新創建的安全設置（如將新創建的安全關聯投入使用）。
注４： 在上述狀況下，P-CSCF將基於新創建的安全關聯發送請求到UE。在UDP層，發送給UE的響應採用新創建的安全關聯；在TCP層，發送給UE的響應採用與請求一致的安全關聯。
注5： 當從UE接收到SIP消息（包括註冊請求）採用一套不一樣於P-CSCF新創建的安全關聯設置，P-CSCF將不會對安全關聯設置採起任何行爲。
當老的安全關聯的 SIP 層生命期到期，如SIP 層生命期小於64*T1，而且新創建安全關聯還未創建使用，對後續發往UE 的消息，P-CSCF 將用新創建的安全關聯（見注３）。
當 P-CSCF 發送註冊請求的200OK 響應中，包括re-authentication，P-CSCF 將：
1) 保持用於重認證的註冊請求的安全關聯設置；
2)保存在認證過程當中新創建的安全關聯；
3) 若是存在其餘安全關聯設置，刪除之；
4) 對於後續發送給UE的請求，繼續使用用於重認證的註冊請求的安全關聯設置。
當發送決定初始認證的註冊請求的 200OK 響應時，如初始註冊請求未受保護，P-CSCF 將：
1) 保存在認證過程當中建立的安全關聯設置；
2) 若是存在其餘安全關聯設置，刪除之；
3) 在後續發給UE的消息，採用新創建的安全關聯設置。
注6 ： P-CSCF保持着兩套路由頭列表。第一套路由頭列表是註冊時建立的，僅用於UE發起的初始請求。這個列表對每一個公有用戶標識的註冊有效。第二套路由列表是在從初始Invite消息和關聯響應的Record Route頭中構建的，用於對話的過程當中。一旦對話終止，則丟棄第二套路由列表。
當 SIP 層生命期超時，P-CSCF 將從Ipsec 數據庫中刪除安全關聯。
20.8.1.3. 訂閱註冊用戶狀態事件包
一旦接收到用戶註冊請求的 200OK 響應，P-CSCF 將向S-CSCF 訂閱註冊事件包，RFC3680中有描述。
1) 產生一個訂閱請求，包括下面元素：
- Request-URI設置爲P-CSCF但願訂閱的源，好比默認公有用戶標識的SIP URI；
- From頭，設置爲P-CSCF的SIP URI；
- To頭，設置爲包含默認公有用戶標識的SIP URI；
- Event頭，設置爲「reg」；
- Expires頭，設置爲註冊請求200OK響應中Expires頭的值大；
- P-Asserted-Identity頭，設置P-CSCF的SIP URI，該P-CSCF是在用戶註冊Path頭中插入的那個P-CSCF。
- P-Charging-Vector頭，包括TS 32.260描述的icid參數；
2) 決定歸屬網絡的I-CSCF（如用DNS服務）；發送訂閱請求去 I-CSCF 前的處理過程見RFC3261。
一旦接收到訂閱請求的 2xx 響應，P-CSCF 將存儲已創建的對話的信息，和Expires 頭中的超期時間值。
若是要求連續訂閱，則在先前註冊的公有用戶標識超期前600s，或者當初始訂閱超期時間大於1200s 時，在超期前600s 時，或者當初始訂閱超期時間小於1200s 時，在超過一半時間時，P-CSCF 將用註冊事件包自動刷新訂閱。
20.8.1.4. 多公有用戶標識的註冊
一旦接收到訂閱請求的 2xx 響應，P-CSCF 將維持產生的對話（對話是經過Call-ID, To 和From 標識的）
在訂閱註冊事件包過程當中產生了對話，一旦接收到一個關於該對話的NOTIFY 請求，P-CSCF將執行以下操做：
1) 對於每一個公有用戶標識，各自的<registration>中的狀態屬性設置爲"active"時；
- 隸屬於<registration>下的<contact>中狀態屬性設置爲"active"；
- 隸屬於<registration>下的<contact>下<uri>中，設置爲UE的contact地址；- <contact>中event屬性設置爲"registered" or "created"；
P-CSCF將：
- 綁定註冊的公有用戶標識與各個用戶的contact信息。
- 增長公有用戶標識到用戶已註冊的公有用戶標識列表中；
2) 對於每一個公有用戶標識，各自的<registration>中的狀態屬性設置爲"active"時；
- 隸屬於<registration>下的<contact>中狀態屬性設置爲"terminated"；
- 隸屬於<registration>下的<contact>下<uri>中，設置爲UE的contact地址；
- <contact>中event屬性設置爲"deactivated", "expired", "probation", "unregistered", 或者"rejected"；
P-CSCF將認爲指示的共有用戶標識將爲用戶而註銷，並釋放各自用戶該公有標識的存儲信息。
3) 對於每一個公有用戶標識，各自的<registration>中的狀態屬性設置爲"terminated"時；
- 隸屬於<registration>下的<contact>下<uri>中，設置爲UE的contact地址；
- contact>中event屬性設置爲"deactivated", "expired", "probation", "unregistered", 或者"rejected"；
P-CSCF將認爲指示的公有用戶標識將爲UE而註銷，並釋放各自用戶這些公有標識的全部存儲信息，並從用戶已經註冊的公有用戶標識列表中移除這個公有用戶標識。
若是用 PVI 註冊的全部PUI 都被註銷了，P-CSCF 將接收到來自S—CSCF 的NOTIFY 請求，
該請求能夠如5.4.2.1.2 所述，訂閱狀態設置爲"terminated"。若是該請求的訂閱狀態沒有設置爲"terminated"，P-CSCF 可能不訂閱註冊事件包，或者讓訂閱超時。
注1： 一旦收到一個NOTIFY請求，且請求消息中Subscription-State頭設置爲"terminated"，P-CSCF認爲訂閱註冊事件包終止（好比P-CSCF已經發送了一個訂閱請求，請求中Expires頭爲0）。
注2： 當用戶註冊一個公有用戶標識時，S-CSCF可能隱式註冊多個公有用戶標識。下面段落提供了一套機制通知P-CSCF關於隱式註冊的多個公有用戶標識。
20.8.1.5. 註銷
20.8.1.5.1. 用戶發起的註銷
當 P-CSCF接收到註冊請求的200OK響應時，P-CSCF將檢查消息體Expries頭和/或Contact頭中expires字段中的值。若是值爲0，P-CSCF 將：
1) 去除To頭中的擁有用戶標識，而且從已註冊的公有用戶標識列標重去除全部關聯的公有用戶標識和存儲的信息。
2) 檢查是否UE已經留下其它已註冊的公有用戶標識。當全部UE已註冊的公有用戶標識都被註銷了，P-CSCF將刪除與UE間的安全關聯，在服務器事務（見RFC3261）執行註銷終止後。
注 1 ： 一旦接收到NOTIFY請求，請求中<registration>中狀態屬性設置爲"terminated"（如全部公有用戶標識都被註銷）和Subscription-State頭設置爲"terminated"，P-CSCF認爲訂閱註冊註冊事件包終止（就如P-CSCF發送一個訂閱請求，請求中Expries頭設置爲0）。
注 2 ： 目前沒有區分註冊請求和註銷請求的需求，P-CSCF由於管理緣由，能夠區分註冊和註銷請求，可是在SIP層處理註冊和註銷是沒有差異的。
注 3 ： 當註冊請求僅對應於一個已註冊公有用戶標識，但隱式註冊關係到其它幾個公有用戶標識，當P-CSCF發送該請求的200OK響應，P-CSCF將去除和UE間的安全關聯。
全部後續SIP信令沒法到達UE。
20.8.1.5.2. 網絡發起的註銷
一旦接收到關於訂閱註冊事件包產生的對話的 NOTIFY 消息，見5.2.3 中描述，消息體中保護一個或者多個<registration>元素，都是UE 已經註冊的。
- state屬性設置爲"terminated"；
- state屬性設置爲"active"，且<contact>中state狀態設置爲"terminated"，關聯的事件屬性設置爲"rejected" 或"deactivated"；
P-CSCF 將去除這些公有用戶標識的的全部存儲信息，去除該用戶已經註冊的公有用戶標識列表。
一旦接收到 NOTIFY請求，請求中<registration>state 屬性爲"terminated"（也就是全部公有用戶標識都註銷），且Subscription-State頭設置爲"terminated"或者當全部公有用戶標識都註銷，P-CSCF將下降與UE 間的安全關聯。
注 1 ： P-CSCF和UE間的安全關聯下降等級，容許包含註銷事件得NOTIFY請求到達UE。
注 2 ： 當P-CSCF接收到NOTIFY請求，請求中Subscription-State頭爲"terminated"，P-CSCF認爲訂閱事件包終止（也就是像P-CSCF向S-CSCF發送一個訂閱請求，請求中Expires設置爲0）。
20.8.1.6. 除REGISTER方法以外的全部對話和通常事務的通常處理
20.8.1.6.1. 介紹
本節流程對除了REGISTER 方法之外的全部請求和響應適用
20.8.1.6.2. MO或MT的肯定
當接收了一個初始請求或者目標刷新或者單獨事務，P-CSCF：
――若是請求利用了終呼的信息，將按照20.8.1.6.4節描述的來執行終呼流程。在註冊時終呼信息被增長到Path 消息頭（即P-CSCF 入口），例如，消息從特定的端口得到或者最頂端Route 頭包含了特殊的用戶部分或者參數。
――若是以上信息沒有被請求使用，則執行起呼流程，見20.8.1.6.3節所述。
20.8.1.6.3. UE發起的請求
當 P-CSCF 收到對話或者單獨事務的初始請求，而且請求中P-Preferred-Identity頭字段匹配已經註冊的公有用戶標識，P-CSCF肯定該公有用戶標識爲請求發起者。
當 P-CSCF 收到對話或者單獨事務的初始請求，而且請求中P-Preferred-Identity頭字段不匹配任何一個已經註冊的公有用戶標識，或者請求沒有包含P-Preferred-Identity頭字段，P-CSCF將缺省的公有用戶標識肯定爲請求發起者。若是有一個以上的缺省公有用戶標識，P-CSCF從中隨機抽取一個。
注1：From頭不構成任何肯定流程的部分。
當 P-CSCF從UE收到的對話或者單獨事務的初始請求，而且關於請求的發起者的Service-Route列表存在，P-CSCF 將：
1) 驗證收到的在Service-Route頭（在最後一次成功註冊或者重註冊期間）中的URI列表是否和接收的請求中的預加載的Route 頭是否匹配。不是整個字符串而是一個一個URI進行驗證。若是驗證失敗，P-CSCF 要麼：
a) 返回400（Bad Request）響應，響應可能存在包含有警告代碼399 的Warning 頭；
P-CSCF 不會前轉該請求，而且不將繼續Step 2 之後的操做；或者b)使用註冊或者重註冊回的最後200OK 響應消息所帶的Service-Route 頭替換預加載Route 頭；
2) 增長本身的地址到 Via頭。按照RFC3261流程，P-CSCF的Via頭以包含P-CSCF端口號的格式，以及：
a) P-CSCF的能夠解析爲IP地址的FQDN，或者
b) P-CSCF的IP地址；
3) 當增長本身的SIP URI到Record-Route頭頂部，按照包含P-CSCF端口號（等待被叫的後續請求）的格式，以及：
a) P-CSCF 的能夠解析爲IP 地址的FQDN，或者
b) P-CSCF 的IP 地址；
4) 若是存在P-Preferred-Identity頭，則要移除，並插入P-Asserted-Identity消息頭，表明請求發起者的值；
5) 按照規範3GPP TS 32.260增長帶有icid參數的P-Charging-Vector。
6) 若是是INVITE 請求，還要保存請求中Contact, CSeq, 以及Record-Route 頭的值，以便必要的時候P-CSCF 可以釋放會話；(完成以上步驟後)，按照RFC3261，基於最頂端 Route 頭，前轉該請求。當 P-CSCF 收到以上請求的1XX 或者2xx 響應，P-CSCF 將：
1) 保存P-Charging-Function-Addresses 消息頭的值；
2) 保存Record-Route 的列表；
3) 保存Dialog ID，而且與會話的私有用戶標識和公有用戶標識關聯；
4) 從新填寫本身的Record Route 爲與主叫協商的被保護服務器的端口號，依照RFC3485附加壓縮參數；而且
注 2：對於每一對安全關聯，P-CSCF 關聯兩個端口，一個是保護服務器端口，一個是保護客戶端端口。如何選擇保護端口，參照3GPP TS 33.203。
5) 若是該響應與INVITE 請求相對應，保存Contact, From, To 和Record-Route 頭，以便必要時可以釋放會話。
在按照 RFC3261[26]進行前轉響應到UE 以前，須要進行以上操做。
當 P-CSCF 收到UE 發送的對話的目標刷新請求，P-CSCF 將：
1) 驗證請求的發起者是否關聯了一個對話：
a) 若是請求沒有與請求發起者有關的現存的會話，P-CSCF 將向發起者發送403（Forbidden）響應。響應可能保護帶有warn-code 399 的Warning 頭。P-CSCF 不將前轉該請求。不須要其餘的操做；或者
b) 若是請求有與請求發起者有關的現存的會話，P-CSCF 繼續下面的步驟；
2) 驗證請求中的Record-Route 頭列表和本地保存的同一個對話的列表是否匹配。驗證是按一個一個URI 進行比較，而不是整個字符串匹配。若是匹配失敗，P-CSCF 將：
a) 返回400（Bad Request）響應。響應可能包含帶有warn-code 399 的Warning 頭；P-CSCF也不前轉該請求，同時也不進行Step 3 之後的步驟；或者
b) 使用本地保存的同一個對話的Recodr-Route 中的列表替換Route 頭的值。
3) 增長本身的地址到Via 頭。按照RFC3261[26]流程，P-CSCF 的Via 頭以包含P-CSCF端口號的格式，以及：
a) P-CSCF 的能夠解析爲IP 地址的FQDN，或者
b) P-CSCF 的IP 地址；
4）當增長本身的SIP URI 到Record-Route 頭頂部，按照包含P-CSCF 端口號（等待被叫的後續請求）的格式，以及：
a) P-CSCF 的能夠解析爲IP 地址的FQDN，或者
b) P-CSCF 的IP 地址；
5) 對於INVITE 對話（例如，由INVITE 請求發起的對話），用請求中的Contact 和CSeq頭替換本地保存的，以便P-CSCF 必要時可以釋放會話；
注3：只有收到1xx或者2xx響應，保存的contact和CSeq纔有效。對於其餘情形，之前的仍然有效。
按照 RFC 3261[26]流程，基於最頂端Route 進行前轉請求以前，須要進行以上步驟。
當 P-CSCF 收到以上請求（刷新）的1xx 或者2xx 響應後，P-CSCF 將：
1) 和收到初始請求的響應同樣，須要從新填寫本身的Record Route 爲與主叫協商的被保護服務器的端口號，依照RFC3486[55]附加壓縮參數；而且
2) 使用響應中攜帶的Contact 頭值取代保存的Contact 頭，以便P-CSCF 在必要的時候釋放會話。
在按照 RFC 3261[26]流程進行前轉響應到UE 以前，進行以上操做。
當 P-CSCF 收到來自單獨事務的UE 的請求，而且對於請求發起者的Service-Route 頭列表存在，P-CSCF 將：
1) 驗證收到的在Service-Route 頭（在最後一次成功註冊或者重註冊期間）中的URI
列表是否和接收的請求中的預加載的Route 頭是否匹配。不是整個字符串而是一個一個URI進行驗證。若是驗證失敗，P-CSCF 要麼：
a) 返回400（Bad Request）響應，響應可能存在包含有警告代碼399 的Warning 頭；P-CSCF 不會前轉該請求，而且不將繼續Step 2 之後的操做；或者
b)使用註冊或者重註冊回的最後200OK 響應消息所帶的Service-Route 頭替換預加載Route 頭；
2) 若是存在P-Preferred-Identity 頭，則要移除，並插入P-Asserted-Identity 頭，表明請求發起者的值；而且
3) 增長帶有icid 參數P-Charging-Vector 頭，見 3GPP TS 32.260[17];(完成以上步驟後)，按照RFC3261，基於最頂端Route 頭，前轉該請求。
當收到以上請求(單獨事務)的響應，P-CSCF 將：
1)保存P-Charging-Function-Addresses 頭的值；
完成以上步驟後，按照 RFC3261[26]前轉該響應到UE。
當P-CSCF 收到來自UE 的後續請求，但不是目標刷新請求（包括關聯一個已經存在的對話，可是該方法未知），P-CSCF 將：
1) 驗證請求的發起者是否關聯了一個對話：
a) 若是請求沒有與請求發起者有關的現存的會話，P-CSCF 將向發起者發送403（Forbidden）響應。響應可能包含帶有warn-code 399 的Warning 頭。P-CSCF 不將前轉該請求。不須要其餘的操做；或者
b) 若是請求有與請求發起者有關的現存的會話，P-CSCF 繼續下面的步驟；
2) 驗證請求中的Record-Route 頭列表和本地保存的同一個對話的列表是否匹配。驗證
是按一個一個URI 進行比較，而不是整個字符串匹配。若是匹配失敗，P-CSCF 將：
a) 返回400（Bad Request）響應。響應可能包含帶有warn-code 399 的Warning 頭；P-CSCF也不前轉該請求，同時也不進行Step 3 之後的步驟；或者
b) 使用本地保存的同一個對話的Recodr-Route 中的列表替換Route 頭的值。
3) 對於非INVITE 對話，增長一個帶有icid 參數的P-Charging-Vector 頭，見3GPP TS 32.260; 而且
4）對於INVITE 對話，使用收到的請求中的Cseq 替換保存的Cseq 頭，以便P-CSCF必要時可以釋放會話。
按照 RFC 3261流程，基於最頂端 Route 進行前轉請求以前，須要進行以上步驟。
當 P-CSCF 收到UE 的未知方法的請求（未與存在對話關聯），而且存在該請求發起者的Service-Route 頭，P-CSCF 將：
1) 驗證Service-Route 頭（最後一次成功註冊或者從新註冊得到）中包含的URI 列表是否爲請求中預加載Route 頭的子集。驗證是一個一個URI 進行，而不是整個字符串。若是驗證失敗，P-CSCF 將：
a) 返回400（Bad Request）響應。響應可能包含帶有warn-code 399 的Warning 頭；P-CSCF不前轉該請求，而且不進行Step 2 之後的步驟；或者
b) 使用最後一次註冊的200OK 響應中的Route 頭的值代替請求中Route 頭；而且
2) 若是存在P-Preferred-Identity 頭，移除該頭，插入P-Asserted-Identity 頭，表明當前請求的發起者。
在按照 RFC 3261流程，基於Route 頭進行前轉請求以前，進行以上操做。
20.8.1.6.4. 請求在UE終止
- 1. H323協議和sip協議
- 2. SIP協議
- 3. SIP協議（二）
- 4. Sip協議
- 5. sip 協議解析
- 6. SIP協議解析
- 7. SIP協議轉載
- 8. SIP協議簡介
- 9. FreeSwitch(七)：SIP協議
- 10. sip協議詳解
- 更多相關文章...
- • Swift 協議 - Swift 教程
- • SOAP HTTP 協議 - SOAP 教程
- • Docker 清理命令
- • 適用於PHP初學者的學習線路和建議
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. js中 charCodeAt
- 2. Android中通過ViewHelper.setTranslationY實現View移動控制（NineOldAndroids開源項目）
- 3. 【Android】日常記錄：BottomNavigationView自定義樣式，修改點擊後圖片
- 4. maya 文件檢查 ui和數據分離 （一）
- 5. eclipse 修改項目的jdk版本
- 6. Android InputMethod設置
- 7. Simulink中Bus Selector出現很多? ? ?
- 8. 【Openfire筆記】啓動Mac版Openfire時提示「系統偏好設置錯誤」
- 9. AutoPLP在偏好標籤中的生產與應用
- 10. 數據庫關閉的四種方式
- 1. H323協議和sip協議
- 2. SIP協議
- 3. SIP協議（二）
- 4. Sip協議
- 5. sip 協議解析
- 6. SIP協議解析
- 7. SIP協議轉載
- 8. SIP協議簡介
- 9. FreeSwitch(七)：SIP協議
- 10. sip協議詳解