在對話中，有其他的相關會被髮送。一個對話是一個持續一定時間的兩個用戶之間的端到端的SIP關係。對話過程要求兩個用戶代理之間的信息是有序的而且請求被正確路由傳輸的。在這個規範中，只有INVITE請求可以用來建立會話。當一個UAC在一個對話中發出請求的時候，它不僅遵循第8節描述的一般UAC規則而且也遵循對話中的請求規則。第12節講述了對話並且討論了對話的創建和維持，以及在對話中創建一個請求。
SIP中最重要的方法就是INVITE方法，它用來在不同的參與者中創建會話使用。一個會話由一組參與者，他們之間用於交流的媒體流組成。第13節講述了這些會話的創建初始化過程，以及創建一個或一組對話。第14節講述了在對話中使用INVITE請求來改變會話的屬性。最後，第15節，講述瞭如何終止會話。
第8、10、11、12、13、14、15節講述了完整的UA核心（第9節描述了取消，在UA核心和代理核心中使用）。第16節講數了代理服務器，代理服務器用於在兩個UA之間做消息路由使用。
6、協議的定義
以下講述的名次對SIP有着額外的意義：
Address-of-Record: 記錄地址。一個address-of-record(AOR)是一個SIP或者SIPS URI它指向了一個具有定位服務的主機，這個主機可以把URI映射成爲用戶真正物理位置的URI。通常情況下，定位服務器是通過登記服務來建立的。一個AOR經常被認爲是一個用戶的”公共地址”
Back-to-Back UserAgent:背對背的用戶代理（B2BUA）是一個邏輯實體，它就像用戶代理服務器（UAS）一樣接收和處理請求。爲了決定該如何應答一個請求，B2BUA就像UAC一樣工作，並且發出請求。但是它不像代理服務器（proxy），它維持對話狀態，並且參與已經建立的對話中的每一個請求。由於它是直接的UAC和UAS的串連，所以，不需要對他有額外的定義。
Call：呼叫，一個呼叫是一個非正式的術語，它是指在端點之間一個一些通訊行爲，通常用於建立多媒體對話。
Call Leg: 對話的別名；在本規範中沒有使用。
Call Stateful: 如果一個代理服務器（proxy）保存一個對話的狀態（從最開始的INVITE到對話終結的BYE），那麼這個代理服務器就是請求有狀態的。一個請求有狀態（call stateful）的代理服務器也一定是事務有狀態的，但是事務有狀態的不一定是請求有狀態的。
Client：客戶端。一個客戶端是一個任意的網絡元素，它發出SIP請求和接收SIP應答。客戶端可能會也可能不會和人交互。用戶代理客戶端（UAC）和代理服務器都是客戶端。
Conference: 一個包含多個參與方的多媒體會話（見後）。
Core：核心。核心定義了SIP實體的特定類別。比如定義了一個有狀態和無狀態的代理服務器，一個用戶代理或者註冊服務器（registrar）。所有的核心，除了無狀態代理服務器，都是事務用戶。
Dialog:對話，一個對話是持續一段時間的兩個UA之間的端到端的SIP關係。一個對話由SIP消息建立，就像用2xx響應INVITE請求。我們用Call identifier，local tag（本地tag），remote tag（對方tag）來標誌一個對話，一個對話在RFC 2543中被正式叫做CALL LEG.
Downstream: 它是事務中的消息傳遞方向。它特指從UAC到UAS的請求流的方向，
Final Response：終結響應。一個響應終端SIP事務的應答，和事務中間的臨時響應相反。所有的2xx，3xx，4xx，5xx，6xx響應都是終結響應。
Header：頭。頭域是在SIP消息頭部用來描述這個SIP消息信息的部分。它由一堆頭域字段組成。
Header Field:頭域字段。頭域字段是在SIP消息頭域的字段。一個頭域字段可以由多個頭域字段行組成。一個頭域字段由一個頭域名和（零個或多個）頭域值組成。多個頭域值用’,’分割。某些頭域字段只能有單個值，比如結果域（result）就只能有一個值。
Header Field Value:頭域值。一個頭域值是一個單個的值，一個頭域字段可以有0個或者多個頭域值。
Home Domain：宿主機。一個提供SIP服務的主機。一般指的是在登記服務中指明的記錄地址中的URI的主機。
Informational Response:提示應答。和臨時應答一樣。
Initiator, Calling Party, Caller: 用INVITE初始一個會話（和對話）的那方。一個caller從發出INVITE請求建立對話開始，到對話終止都一直是這個角色。
Invitation: 一個INVITE請求。
Invitee,Invited User,Called Party, Callee:被叫方。收到INVITE請求並且建立會話的那方。一個被叫方從收到INVITE請求起，到終止INVITE建立的對話結束，都稱作被叫方。
Location Service: 定位服務。定位服務是用來給SIP轉發或者代理服務器確定被叫方可能的位置使用的。它包含一張綁定了address-of-record的表，被叫方可能有0到多個記錄。綁定的記錄可以通過多種渠道添加和刪除；本規範定義了REGISTER方法來更新綁定表。
Loop：環路。當請求抵達一個代理服務器，代理服務器轉發這個請求，當這個請求再次來到同一個代理服務器，就稱之爲環路。當第二次抵達的時候，Request－URI中包含了上次抵達的資料，並且由於並沒有什麼東西可以改變轉發的策略，這樣就導致這個請求還會再次被轉發回來。環路請求是錯誤的，所以，處理程序需要檢測和防止協議中出現的環路請求。
Loose Routing:丟失路由。代理服務器在下述情況下會丟失路由。
A proxy is said to be loose routing if it follows the procedures defined in this specification for processing of the Route header field. These procedures separate the destination of the request (present in the Request-URI) from the set of proxies that need to be visited along the way (present in the Route header field). A proxy compliant to these mechanisms is also known as a loose router.
Message:消息。SIP元素之間傳送的協議數據就是消息。SIP消息既可以是請求也可以是應答。
Method:方法。方法是在服務器請求處理的主要功能。方法是請求消息自身攜帶的。典型的方法就是INVITE和BYE。
Outbound Proxy:對外代理服務器。一個代理服務器接收到客戶的請求，即使它不是由Request_URI所決定的服務器。通常一個UA會手工配置一個對外的代理服務器，或者可以通過一個自動配置的協議自動配置一個。
Parallel Search: 並行搜索。並行搜索情況下，代理服務器會向多個用戶可能存在的地方發起請求，並且等待應答。同串行搜索不同的地方是，並行搜索不會等待上一個請求應答回來之後再發起下一個搜索，而是一個接一個的發起搜索請求。
Provisional Response: 臨時應答。服務器用來標誌自己正在處理的應答，但是本應答並不結束一個SIP事務。1xx應答就是臨時的，其他應答標誌着事務的結束。
Proxy,Proxy Server:代理、代理服務器。一箇中間的實體。它本身即作爲客戶端也作爲服務端，爲其他客戶端提供請求的轉發服務。一個代理服務器首先提供的是路由服務，也就是說保證請求被髮到更加”靠近”目標用戶的地方。代理服務器對某些強制政策有用（比如，確認一個用戶是否允許建立一個呼叫等）。一個代理服務器翻譯，並且，如果有需要的話，再轉發前會重寫請求消息。
Recursion：迴路、遞歸。一個客戶端，在響應請求的時候產生新的到Contract包頭域的URI請求的時候，會在3xx響應中陷入遞歸。A client recurses on a 3xx response when it generates a new request to one or more of the URIs in the Contact header field in the response.
Redirect Server:重定向服務器。一個重定向服務器是一個產生3xx應答的UAS服務器，指示客戶端連接別的URI。
Registrar: 登記員。一個登記員（登記服務器）是一個接收REGISTER請求得服務器。他把請求得信息放到定位服務器中，這樣可以讓定位服務器很方便得查找位置信息。
Regular Transaction:常規事務。凡不包含INVITE,ACK,或者CANCEL方法得事務就是常規事務。
Request: 請求。 一個由客戶端發到服務端得SIP信息，用於執行特定得功能。
Response：應答。一個由服務端發到客戶端得SIP信息。用來標誌從客戶端發往服務端得請求處理得情況得。
Ringback: 回鈴音。回鈴音是一個信號音。是給呼叫方得一個信號表示被叫方正在振鈴（Ringing）。
Route Set: 路由集。路由集合是一個順序得SIP或者SIPS URI。這些URI描述了傳遞一個請求所必須經歷得代理列表。一個路由集可以是自適應得，因爲包頭中包含了Record-Route(記錄路由)，也可以是依賴配置得到得。
Server：服務器。一個server是一個網絡元素接收請求並且處理請求並且發送迴應給請求方。典型得服務器就是代理服務器（proxies），用戶代理服務器（user agent servers），重定向服務器，登記服務器。
Sequential Search：順序查找。在順序查找中，代理服務器順序嘗試聯繫地址，在處理下一個之前必須等待上一個請求已經有一個結束應答。一個2xx或者6xx系列得最終應答總是結束一個順序查找。
Session：會話。根據SDP得描述：”一個多媒體會話是一個由多媒體發送方和接受方組成得集合，並且包括在發送方和接受方之間得數據流。一個多媒體會議是一個典型得多媒體會話。”(RFC 2327[1])(一個session在SDP訂一下可以是一個或者多個RTP sessino)。在定義中，一個被叫方可以被多次邀請，被不同得呼叫方邀請，到同一個會話。在SDP中，一個會話可以被SDP用戶名，session id,網絡類型，地址類型，地址元素得一個集合串所規定。
SIP 事務：一個SIP事務是在客戶端和服務端得事件，包括了從第一個由客戶端發送到服務端得請求，到最後一個（非1xx）服務端向客戶端發出得終結應答。如果請求是一個INVITE請求，並且終結應答是一個非2xx得應答，那麼事務還包括一個ACK給服務器做應答。給INVITE請求的2xx應答的ACK迴應，是一個獨立的事務。
Spiral：回溯。一個回溯是指一個SIP請求，路由給一個proxy，並且轉發，但是又被路由回這個proxy，但是不同於迴路（遞歸）的是，這次路由回來的請求包的包頭中，包含了不同於原請求的請求包部分，使得本次proxy決定的路由轉發與上次不同。通常，這是說，請求的Request-URI不同於上次的Request_URI。一個回溯不是一個錯誤，不同於迴路（環路loop）。通常導致這樣的現象是呼叫轉發（call forwarding）。一個用戶呼叫[email protected]。example.com代理服務器轉發請求到Joe的PC,並且Joe的pc呼叫轉移到[email protected]。這個請求被轉發回example.com代理服務器。可是這個並不是一個環路（loop）。因爲請求的目的地址變成了另一個用戶，這就是回溯，是一個合法的情況。
Stateful Proxy:有狀態的代理服務器。在邏輯上，有狀態的代理服務器就是處理一個請求的過程中，維持的一個本規範所定義的客戶端和服務端的事務狀態機。也是一個事務又狀態代理服務器(transaction stateful proxy)。具體的stateful proxy在第16節定義。一個（事務）有狀態代理服務器和一個call stateful proxy不是一回事。
Stateless Proxy：無狀態的代理服務器。在邏輯上，無狀態代理服務器在處理請求中，並不維持客戶和服務端的事務狀態機。一個無狀態的代理服務器直接轉發每一個接收到的請求和每一個接收到的響應。
Strict Routing:嚴格路由。路由處理規則如果複覈RFC2543協議（and many prior work in progress versions of this RFC） 就是一個嚴格路由。在這個規則下，如果在包頭中包含Route域，那麼代理服務器就會刪除Request_URI域內容。本文檔並不要求一定要有嚴格路由，本文檔只要求鬆散路由就可以了。支持嚴格路由的代理服務器也叫嚴格路由器。
Target Refresh Request: 目標刷新請求。一個Target Refresh Request是一個在對話中發出的請求，用來更改對話目標的請求。
Transaction User(TU):事務用戶。在transaction 層之上的協議層。TU包括了UAC 核心，UAS core,和proxy core。
Upstream:上行流。一個在事務中的消息流向方向。它是指由用戶代理服務器（UAS）發出應答到用戶代理客戶端（UAC）的消息流向方向。
URL-encoded:一串根據RFC2396－2.4節編碼的字符。
User Agent Client(UAC):用戶代理客戶端。用戶代理客戶端是一個邏輯的概念，他創建一個新請求，並且用客戶事務狀態機發送這個請求。UAC角色只在事務中存在。換句話說，UAC就是一小段代碼初始化一個請求，並且在事務中遵循UAC的規則。如果它接下來收到一個請求，那麼在那個事務中，它就是作爲UAS來處理請求。
UAC Core:UAC核心。在transaction和transport層之上得UAC實現的功能集合。
User Agent Server(UAS): 用戶代理服務器.UAS是一個邏輯的實體，對SIP請求做響應的。應答接受、拒絕、或者轉發對應的請求。UAS角色在事務中存在。換句話說，是響應請求的一小段軟件，在事務中作爲UAS存在。如果他發出請求，那麼他就在事務中作爲UAC存在。
UAS Core：UAS核心。在transaction和transport層智商的UAS實現的功能集合。
User Agent（UA）。一個邏輯實體的概念，包含UAC和UAS。
UAC和UAS，就像代理服務器和轉發服務器，是在事務by事務的原理（串行事務處理）上定義的。例如，當發出一個初始化INVITE請求的時候，UA作爲UAC初始化一個呼叫動作，當從被叫方接收到一個BYE請求的時候，UA作爲UAS響應。類似的，同樣的代碼可以對一個請求做爲proxy服務器處理，對另一個請求作爲重定向服務器。
proxy，location，registrar服務器都是邏輯實體，在它們的實現中，可能是作爲單個應用實現的。
7、SIP消息：
SIP協議是一個基於文本的協議，使用UTF-8字符集（RFC2279[7]）。
一個SIP消息既可以是一個從客戶端到服務器端的請求，也可以是一個從服務器端到客戶端的一個應答。
即使在字符集上和語法細節上有所不同，請求（7.1）還是應答（7.2）消息都基於RFC2822格式的。（SIP允許包頭域不是標準的RFC2822包頭域）。這兩種消息類型都由一個起始行，一個或者多個包頭域，一個可選的消息中文組成。
一般消息＝ 起始行
*消息包頭
CRLF
[消息正文]
起始行＝ 請求行/狀態行
起始行、每一個包頭行，空行、都必須由回車換行組成（CRLF）。即使消息中文沒有，也必須有一個空行跟隨。
除了在字符集上的區別以外，很多SIP的消息和包頭域的格式都同HTTP/1.1一樣。我們在這裏就不重複它的語法和語義了，我們用[HX.Y]來標誌HTTP/1.1規範（RFC2616[8]）的X.Y節的描述。
SIP並非一個HTTP的超集或者擴展。
7．1 請求
SIP請求是根據起始行中的Request-Line來區分的。一個Request_line包含方法名字，Request－URI，用單個空格（SP）間隔開的協議版本。
Request-Line由CRLF結束。除了用作行結束標誌以外，不允許CR或者LF出現在其他地方。在其他域中，不允許出現線形的空白（liner whitespace LWS）
Request-Line = Method SP Request-URI SP SIP-VERSION CRLF
Method: 這個規範規定了6中方法：REGISTER用於登記聯繫信息，INVITE，ACK,CANCEL用於建立會話，BYE用於結束會話，OPTIONS用於查詢服務器負載。SIP擴展、標準RFC追加可能包含擴展的方法。
Request-URI: Request-URI是一個SIP或者SIPS URI，他們在19.1節由描述。也可以是一個通用的URI(RFC 2396[5])。它標誌了這個請求所用到的用戶或者服務的地址。Request-URI禁止包含空白字符或者控制字符，並且禁止用”<>”括上。
SIP 元素可以支持除了SIP或者SIPS之外所規定的Request-URIs。比如”tel” URI模式（RFC 2806[9]）。SIP元素可以用他們自己的機制來轉換non-SIP URIs到SIP URI，SIPS URI或者其他什麼格式的URI。
SIP-Version：請求和應答消息都包含當前使用的SIP版本，這個遵循[H3.1](類似HTTP用SIP替代，用SIP/2.0替代HTTP/1.1)中關於版本的規定，版本依賴，升級版本號。一個應用，發出的SIP消息一定包含了SIP-Version “SIP/2.0”。這個SIP版本串是大小寫不銘感的，但是在實現中必須發送大寫。
不像HTTP/1.1,SIP把版本號當作一個文本串處理。在實現上，這個應該不會有區別。
7．2應答
SIP應答和SIP請求的區別在於在START-LINE中是否包含一個STATUS-LINE。一個status-line在由數字表達的status－code之前，是一個協議的版本串，每一個元素之間用一個單個SP（空格）分開。
除了最後用作結束標誌以外，CR/LF不允許出現在其他地方。
status-line = SIP-VERSION SP STATUS-CODE SP Reasong-Phrase CRLF
Status-Code 是一個3位的數字result code，用來標誌處理請求的一個結果。Reason-Phrase是一個簡短的Status-Code的說明。Status-Code是爲了能自動處理使用的，但是Reason-Phrase是用來給用戶看得。一個客戶端並不要求一定要顯示或者解釋這個Reason-Phrase。本文檔建議輸出這個reason-phrase,實現中可以選擇其他文本，比如用請求包頭中指定的合適語言來顯示。
status－code的第一個數字表示了應答的類型。接下來兩個數字並不作分類使用。基於這個原因，任何status code在100到199的可以統稱位”1xx應答”，類似的，在200到299的可以統稱位”2xx應答”，依此類推。SIP/2.0允許6類應答：
1xx：臨時應答－請求已經接收，正在處理這個請求。
2xx：成功處理－請求已經成功接收，並且正確處理了這個請求。
3xx：重定向－還需要附加的操作才能完成這個請求，本請求轉發到其他的服務器上處理。
4xx：客戶端錯誤－－請求包含錯誤的格式或者不能在這個服務器上完成。
5xx：服務器錯誤－服務器不能正確的處理這個顯然合法的請求。
6xx：全局錯誤－請求不能被任何服務器處理。
21節定義了詳細的代碼說明。
7.3 頭域
SIP頭域和HTTP頭域在語法和語義上都比較類似。特別的，SIP頭域遵循[H4.2]關於消息頭的語法的定義，並且遵循多行的擴展頭域的規則。(後者 is specified in HTTP with implicit whitespace and folding)。這個規範遵循RFC2234[10]，並且把清晰的空白和封裝作爲內在的語法規則。
[H4.2]也定義了具有相同域名的多個頭域，他們的值是用逗號分開的列表，可以合併到一個頭域中。這個也適用於SIP，但是細節上略有不同，因爲語法不同。實際上，任何SIP的包頭語法都是基於如下範式的：
header ＝ “ header-name” HCOLON header-value *(COMMA header-value)
這個允許合併在具有同一個域名的多個頭域，到一個用逗號分割的單個頭域中。Contact頭域除了當域值是”*”之外，都允許用逗號分割的列表。
7.3.1 頭域格式。
頭域遵循在RFC2822的2.2節定義的通用頭域格式。每一個頭域都由一個域名加上冒號（”:”）和域值組成。
field-name:field-value
消息頭的正則語法在25節中有介紹介紹。
在消息頭中，允許在冒號的左右有任意個數的空白；但是，在實現中，建議避免域名和冒號中間有空格，並且建議在冒號和值之間使用單個空格（SP）。
Subject: lunch
Subject : lunch
Subject :lunch
Subject: lunch
所以，上面的都是合法的，也是相等的，但是最後一種是我們所推薦的。
頭域可以擴展成爲多行的，只要在每一個附加行前邊用至少一個SP或者水平TAB(HT)打頭就可以了。這種多行的頭域在行結尾並且在下一行之前的空白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等等）放在消息頭的最前邊，這樣可以提高處理的速度。相同域名的域之間的順序非常重要。只有當單個頭域的域值是可以用逗號分割的列表的時候，纔可以表達成爲同一個域名的多個頭域（這就是說，如果遵循7.3定義的語法）。也就是意味着必須可以將同一個域名的多個頭域在不改變消息語義的前提下，改換表達成爲一對”域名: 域值”；這個轉換是通過順序增加每一個域的域值，域值之間用逗號分割。這個規則有幾個例外，就是WWW-Authenticate,Authorization,Proxy-Authenticate,和Proxy-Authorization頭域。多個頭域行可以在消息頭中出現，但是由於他們的語法並不遵循7.3中定義的通用格式，所以，他們並不能合併成爲單個頭域行。
在實現上，必須能夠既能夠處理多個頭域行的情況，也必須能夠處理用逗號分割的合併的單個頭域行的情況。
下邊的幾組頭域是相等的：
Route: <sip:[email protected]>
Subject: Lunch
Route: <sip:[email protected]>
Route: <sip:[email protected]>
Route: <sip:[email protected]>, <sip:[email protected]>
Route: <sip:[email protected]>
Subject: Lunch
Subject: Lunch
Route: <sip:[email protected]>, <sip:[email protected]>
<sip:[email protected]>
下邊各組是合法的，但是並不相等。
Route: <sip:[email protected]>
Route: <sip:[email protected]>
Route: <sip:[email protected]>
Route: <sip:[email protected]>
Route: <sip:[email protected]>
Route: <sip:[email protected]>
Route: <sip:[email protected]>,<sip:[email protected]>,<sip:[email protected]>
每一個頭域值的格式是依賴於它的頭域名的。他可以是任意順序的TEXT-UTF8字符，也可以是一個空格，標記，分隔符，引號括起來的字串的組合。很多頭域都回附帶一個通用的域值格式。這個域值格式是由分號分開的參數名和參數值的組合：
field-name: field-value *(;parameter-name=parameter-value)
雖然在域值裏邊可以有任意數量的parameter-name/parameter-value對，但是不能允許有相同的parameter-name存在（唯一性）。除了特別指出的頭域之外，頭域中的域名、域值、parameter name parameter-value都是大小寫不敏感的。標記詞始終是大小寫不銘感的。除非有特別的指定，引號串的字符串是大小寫敏感的。例如：
Contact: <sip:[email protected]>;expires=3600
和
CONTACT: <sip:[email protected]>; ExPiReS=3600
相同。
Content-Disposition: session;handling=optional
和
content-disposition: Session;HANDLING=OPTIONAL
相同。
下邊的兩個頭域不相同：
Warning: 370 devnull “Choose a bigger pipe”
Warning: 370 devnull “CHOOSE A BIGGER PIPE”
SIP中最重要的方法就是INVITE方法，它用來在不同的參與者中創建會話使用。一個會話由一組參與者，他們之間用於交流的媒體流組成。第13節講述了這些會話的創建初始化過程，以及創建一個或一組對話。第14節講述了在對話中使用INVITE請求來改變會話的屬性。最後，第15節，講述瞭如何終止會話。
第8、10、11、12、13、14、15節講述了完整的UA核心（第9節描述了取消，在UA核心和代理核心中使用）。第16節講數了代理服務器，代理服務器用於在兩個UA之間做消息路由使用。
6、協議的定義
以下講述的名次對SIP有着額外的意義：
Address-of-Record: 記錄地址。一個address-of-record(AOR)是一個SIP或者SIPS URI它指向了一個具有定位服務的主機，這個主機可以把URI映射成爲用戶真正物理位置的URI。通常情況下，定位服務器是通過登記服務來建立的。一個AOR經常被認爲是一個用戶的”公共地址”
Back-to-Back UserAgent:背對背的用戶代理（B2BUA）是一個邏輯實體，它就像用戶代理服務器（UAS）一樣接收和處理請求。爲了決定該如何應答一個請求，B2BUA就像UAC一樣工作，並且發出請求。但是它不像代理服務器（proxy），它維持對話狀態，並且參與已經建立的對話中的每一個請求。由於它是直接的UAC和UAS的串連，所以，不需要對他有額外的定義。
Call：呼叫，一個呼叫是一個非正式的術語，它是指在端點之間一個一些通訊行爲，通常用於建立多媒體對話。
Call Leg: 對話的別名；在本規範中沒有使用。
Call Stateful: 如果一個代理服務器（proxy）保存一個對話的狀態（從最開始的INVITE到對話終結的BYE），那麼這個代理服務器就是請求有狀態的。一個請求有狀態（call stateful）的代理服務器也一定是事務有狀態的，但是事務有狀態的不一定是請求有狀態的。
Client：客戶端。一個客戶端是一個任意的網絡元素，它發出SIP請求和接收SIP應答。客戶端可能會也可能不會和人交互。用戶代理客戶端（UAC）和代理服務器都是客戶端。
Conference: 一個包含多個參與方的多媒體會話（見後）。
Core：核心。核心定義了SIP實體的特定類別。比如定義了一個有狀態和無狀態的代理服務器，一個用戶代理或者註冊服務器（registrar）。所有的核心，除了無狀態代理服務器，都是事務用戶。
Dialog:對話，一個對話是持續一段時間的兩個UA之間的端到端的SIP關係。一個對話由SIP消息建立，就像用2xx響應INVITE請求。我們用Call identifier，local tag（本地tag），remote tag（對方tag）來標誌一個對話，一個對話在RFC 2543中被正式叫做CALL LEG.
Downstream: 它是事務中的消息傳遞方向。它特指從UAC到UAS的請求流的方向，
Final Response：終結響應。一個響應終端SIP事務的應答，和事務中間的臨時響應相反。所有的2xx，3xx，4xx，5xx，6xx響應都是終結響應。
Header：頭。頭域是在SIP消息頭部用來描述這個SIP消息信息的部分。它由一堆頭域字段組成。
Header Field:頭域字段。頭域字段是在SIP消息頭域的字段。一個頭域字段可以由多個頭域字段行組成。一個頭域字段由一個頭域名和（零個或多個）頭域值組成。多個頭域值用’,’分割。某些頭域字段只能有單個值，比如結果域（result）就只能有一個值。
Header Field Value:頭域值。一個頭域值是一個單個的值，一個頭域字段可以有0個或者多個頭域值。
Home Domain：宿主機。一個提供SIP服務的主機。一般指的是在登記服務中指明的記錄地址中的URI的主機。
Informational Response:提示應答。和臨時應答一樣。
Initiator, Calling Party, Caller: 用INVITE初始一個會話（和對話）的那方。一個caller從發出INVITE請求建立對話開始，到對話終止都一直是這個角色。
Invitation: 一個INVITE請求。
Invitee,Invited User,Called Party, Callee:被叫方。收到INVITE請求並且建立會話的那方。一個被叫方從收到INVITE請求起，到終止INVITE建立的對話結束，都稱作被叫方。
Location Service: 定位服務。定位服務是用來給SIP轉發或者代理服務器確定被叫方可能的位置使用的。它包含一張綁定了address-of-record的表，被叫方可能有0到多個記錄。綁定的記錄可以通過多種渠道添加和刪除；本規範定義了REGISTER方法來更新綁定表。
Loop：環路。當請求抵達一個代理服務器，代理服務器轉發這個請求，當這個請求再次來到同一個代理服務器，就稱之爲環路。當第二次抵達的時候，Request－URI中包含了上次抵達的資料，並且由於並沒有什麼東西可以改變轉發的策略，這樣就導致這個請求還會再次被轉發回來。環路請求是錯誤的，所以，處理程序需要檢測和防止協議中出現的環路請求。
Loose Routing:丟失路由。代理服務器在下述情況下會丟失路由。
A proxy is said to be loose routing if it follows the procedures defined in this specification for processing of the Route header field. These procedures separate the destination of the request (present in the Request-URI) from the set of proxies that need to be visited along the way (present in the Route header field). A proxy compliant to these mechanisms is also known as a loose router.
Message:消息。SIP元素之間傳送的協議數據就是消息。SIP消息既可以是請求也可以是應答。
Method:方法。方法是在服務器請求處理的主要功能。方法是請求消息自身攜帶的。典型的方法就是INVITE和BYE。
Outbound Proxy:對外代理服務器。一個代理服務器接收到客戶的請求，即使它不是由Request_URI所決定的服務器。通常一個UA會手工配置一個對外的代理服務器，或者可以通過一個自動配置的協議自動配置一個。
Parallel Search: 並行搜索。並行搜索情況下，代理服務器會向多個用戶可能存在的地方發起請求，並且等待應答。同串行搜索不同的地方是，並行搜索不會等待上一個請求應答回來之後再發起下一個搜索，而是一個接一個的發起搜索請求。
Provisional Response: 臨時應答。服務器用來標誌自己正在處理的應答，但是本應答並不結束一個SIP事務。1xx應答就是臨時的，其他應答標誌着事務的結束。
Proxy,Proxy Server:代理、代理服務器。一箇中間的實體。它本身即作爲客戶端也作爲服務端，爲其他客戶端提供請求的轉發服務。一個代理服務器首先提供的是路由服務，也就是說保證請求被髮到更加”靠近”目標用戶的地方。代理服務器對某些強制政策有用（比如，確認一個用戶是否允許建立一個呼叫等）。一個代理服務器翻譯，並且，如果有需要的話，再轉發前會重寫請求消息。
Recursion：迴路、遞歸。一個客戶端，在響應請求的時候產生新的到Contract包頭域的URI請求的時候，會在3xx響應中陷入遞歸。A client recurses on a 3xx response when it generates a new request to one or more of the URIs in the Contact header field in the response.
Redirect Server:重定向服務器。一個重定向服務器是一個產生3xx應答的UAS服務器，指示客戶端連接別的URI。
Registrar: 登記員。一個登記員（登記服務器）是一個接收REGISTER請求得服務器。他把請求得信息放到定位服務器中，這樣可以讓定位服務器很方便得查找位置信息。
Regular Transaction:常規事務。凡不包含INVITE,ACK,或者CANCEL方法得事務就是常規事務。
Request: 請求。 一個由客戶端發到服務端得SIP信息，用於執行特定得功能。
Response：應答。一個由服務端發到客戶端得SIP信息。用來標誌從客戶端發往服務端得請求處理得情況得。
Ringback: 回鈴音。回鈴音是一個信號音。是給呼叫方得一個信號表示被叫方正在振鈴（Ringing）。
Route Set: 路由集。路由集合是一個順序得SIP或者SIPS URI。這些URI描述了傳遞一個請求所必須經歷得代理列表。一個路由集可以是自適應得，因爲包頭中包含了Record-Route(記錄路由)，也可以是依賴配置得到得。
Server：服務器。一個server是一個網絡元素接收請求並且處理請求並且發送迴應給請求方。典型得服務器就是代理服務器（proxies），用戶代理服務器（user agent servers），重定向服務器，登記服務器。
Sequential Search：順序查找。在順序查找中，代理服務器順序嘗試聯繫地址，在處理下一個之前必須等待上一個請求已經有一個結束應答。一個2xx或者6xx系列得最終應答總是結束一個順序查找。
Session：會話。根據SDP得描述：”一個多媒體會話是一個由多媒體發送方和接受方組成得集合，並且包括在發送方和接受方之間得數據流。一個多媒體會議是一個典型得多媒體會話。”(RFC 2327[1])(一個session在SDP訂一下可以是一個或者多個RTP sessino)。在定義中，一個被叫方可以被多次邀請，被不同得呼叫方邀請，到同一個會話。在SDP中，一個會話可以被SDP用戶名，session id,網絡類型，地址類型，地址元素得一個集合串所規定。
SIP 事務：一個SIP事務是在客戶端和服務端得事件，包括了從第一個由客戶端發送到服務端得請求，到最後一個（非1xx）服務端向客戶端發出得終結應答。如果請求是一個INVITE請求，並且終結應答是一個非2xx得應答，那麼事務還包括一個ACK給服務器做應答。給INVITE請求的2xx應答的ACK迴應，是一個獨立的事務。
Spiral：回溯。一個回溯是指一個SIP請求，路由給一個proxy，並且轉發，但是又被路由回這個proxy，但是不同於迴路（遞歸）的是，這次路由回來的請求包的包頭中，包含了不同於原請求的請求包部分，使得本次proxy決定的路由轉發與上次不同。通常，這是說，請求的Request-URI不同於上次的Request_URI。一個回溯不是一個錯誤，不同於迴路（環路loop）。通常導致這樣的現象是呼叫轉發（call forwarding）。一個用戶呼叫[email protected]。example.com代理服務器轉發請求到Joe的PC,並且Joe的pc呼叫轉移到[email protected]。這個請求被轉發回example.com代理服務器。可是這個並不是一個環路（loop）。因爲請求的目的地址變成了另一個用戶，這就是回溯，是一個合法的情況。
Stateful Proxy:有狀態的代理服務器。在邏輯上，有狀態的代理服務器就是處理一個請求的過程中，維持的一個本規範所定義的客戶端和服務端的事務狀態機。也是一個事務又狀態代理服務器(transaction stateful proxy)。具體的stateful proxy在第16節定義。一個（事務）有狀態代理服務器和一個call stateful proxy不是一回事。
Stateless Proxy：無狀態的代理服務器。在邏輯上，無狀態代理服務器在處理請求中，並不維持客戶和服務端的事務狀態機。一個無狀態的代理服務器直接轉發每一個接收到的請求和每一個接收到的響應。
Strict Routing:嚴格路由。路由處理規則如果複覈RFC2543協議（and many prior work in progress versions of this RFC） 就是一個嚴格路由。在這個規則下，如果在包頭中包含Route域，那麼代理服務器就會刪除Request_URI域內容。本文檔並不要求一定要有嚴格路由，本文檔只要求鬆散路由就可以了。支持嚴格路由的代理服務器也叫嚴格路由器。
Target Refresh Request: 目標刷新請求。一個Target Refresh Request是一個在對話中發出的請求，用來更改對話目標的請求。
Transaction User(TU):事務用戶。在transaction 層之上的協議層。TU包括了UAC 核心，UAS core,和proxy core。
Upstream:上行流。一個在事務中的消息流向方向。它是指由用戶代理服務器（UAS）發出應答到用戶代理客戶端（UAC）的消息流向方向。
URL-encoded:一串根據RFC2396－2.4節編碼的字符。
User Agent Client(UAC):用戶代理客戶端。用戶代理客戶端是一個邏輯的概念，他創建一個新請求，並且用客戶事務狀態機發送這個請求。UAC角色只在事務中存在。換句話說，UAC就是一小段代碼初始化一個請求，並且在事務中遵循UAC的規則。如果它接下來收到一個請求，那麼在那個事務中，它就是作爲UAS來處理請求。
UAC Core:UAC核心。在transaction和transport層之上得UAC實現的功能集合。
User Agent Server(UAS): 用戶代理服務器.UAS是一個邏輯的實體，對SIP請求做響應的。應答接受、拒絕、或者轉發對應的請求。UAS角色在事務中存在。換句話說，是響應請求的一小段軟件，在事務中作爲UAS存在。如果他發出請求，那麼他就在事務中作爲UAC存在。
UAS Core：UAS核心。在transaction和transport層智商的UAS實現的功能集合。
User Agent（UA）。一個邏輯實體的概念，包含UAC和UAS。
UAC和UAS，就像代理服務器和轉發服務器，是在事務by事務的原理（串行事務處理）上定義的。例如，當發出一個初始化INVITE請求的時候，UA作爲UAC初始化一個呼叫動作，當從被叫方接收到一個BYE請求的時候，UA作爲UAS響應。類似的，同樣的代碼可以對一個請求做爲proxy服務器處理，對另一個請求作爲重定向服務器。
proxy，location，registrar服務器都是邏輯實體，在它們的實現中，可能是作爲單個應用實現的。
7、SIP消息：
SIP協議是一個基於文本的協議，使用UTF-8字符集（RFC2279[7]）。
一個SIP消息既可以是一個從客戶端到服務器端的請求，也可以是一個從服務器端到客戶端的一個應答。
即使在字符集上和語法細節上有所不同，請求（7.1）還是應答（7.2）消息都基於RFC2822格式的。（SIP允許包頭域不是標準的RFC2822包頭域）。這兩種消息類型都由一個起始行，一個或者多個包頭域，一個可選的消息中文組成。
一般消息＝ 起始行
*消息包頭
CRLF
[消息正文]
起始行＝ 請求行/狀態行
起始行、每一個包頭行，空行、都必須由回車換行組成（CRLF）。即使消息中文沒有，也必須有一個空行跟隨。
除了在字符集上的區別以外，很多SIP的消息和包頭域的格式都同HTTP/1.1一樣。我們在這裏就不重複它的語法和語義了，我們用[HX.Y]來標誌HTTP/1.1規範（RFC2616[8]）的X.Y節的描述。
SIP並非一個HTTP的超集或者擴展。
7．1 請求
SIP請求是根據起始行中的Request-Line來區分的。一個Request_line包含方法名字，Request－URI，用單個空格（SP）間隔開的協議版本。
Request-Line由CRLF結束。除了用作行結束標誌以外，不允許CR或者LF出現在其他地方。在其他域中，不允許出現線形的空白（liner whitespace LWS）
Request-Line = Method SP Request-URI SP SIP-VERSION CRLF
Method: 這個規範規定了6中方法：REGISTER用於登記聯繫信息，INVITE，ACK,CANCEL用於建立會話，BYE用於結束會話，OPTIONS用於查詢服務器負載。SIP擴展、標準RFC追加可能包含擴展的方法。
Request-URI: Request-URI是一個SIP或者SIPS URI，他們在19.1節由描述。也可以是一個通用的URI(RFC 2396[5])。它標誌了這個請求所用到的用戶或者服務的地址。Request-URI禁止包含空白字符或者控制字符，並且禁止用”<>”括上。
SIP 元素可以支持除了SIP或者SIPS之外所規定的Request-URIs。比如”tel” URI模式（RFC 2806[9]）。SIP元素可以用他們自己的機制來轉換non-SIP URIs到SIP URI，SIPS URI或者其他什麼格式的URI。
SIP-Version：請求和應答消息都包含當前使用的SIP版本，這個遵循[H3.1](類似HTTP用SIP替代，用SIP/2.0替代HTTP/1.1)中關於版本的規定，版本依賴，升級版本號。一個應用，發出的SIP消息一定包含了SIP-Version “SIP/2.0”。這個SIP版本串是大小寫不銘感的，但是在實現中必須發送大寫。
不像HTTP/1.1,SIP把版本號當作一個文本串處理。在實現上，這個應該不會有區別。
7．2應答
SIP應答和SIP請求的區別在於在START-LINE中是否包含一個STATUS-LINE。一個status-line在由數字表達的status－code之前，是一個協議的版本串，每一個元素之間用一個單個SP（空格）分開。
除了最後用作結束標誌以外，CR/LF不允許出現在其他地方。
status-line = SIP-VERSION SP STATUS-CODE SP Reasong-Phrase CRLF
Status-Code 是一個3位的數字result code，用來標誌處理請求的一個結果。Reason-Phrase是一個簡短的Status-Code的說明。Status-Code是爲了能自動處理使用的，但是Reason-Phrase是用來給用戶看得。一個客戶端並不要求一定要顯示或者解釋這個Reason-Phrase。本文檔建議輸出這個reason-phrase,實現中可以選擇其他文本，比如用請求包頭中指定的合適語言來顯示。
status－code的第一個數字表示了應答的類型。接下來兩個數字並不作分類使用。基於這個原因，任何status code在100到199的可以統稱位”1xx應答”，類似的，在200到299的可以統稱位”2xx應答”，依此類推。SIP/2.0允許6類應答：
1xx：臨時應答－請求已經接收，正在處理這個請求。
2xx：成功處理－請求已經成功接收，並且正確處理了這個請求。
3xx：重定向－還需要附加的操作才能完成這個請求，本請求轉發到其他的服務器上處理。
4xx：客戶端錯誤－－請求包含錯誤的格式或者不能在這個服務器上完成。
5xx：服務器錯誤－服務器不能正確的處理這個顯然合法的請求。
6xx：全局錯誤－請求不能被任何服務器處理。
21節定義了詳細的代碼說明。
7.3 頭域
SIP頭域和HTTP頭域在語法和語義上都比較類似。特別的，SIP頭域遵循[H4.2]關於消息頭的語法的定義，並且遵循多行的擴展頭域的規則。(後者 is specified in HTTP with implicit whitespace and folding)。這個規範遵循RFC2234[10]，並且把清晰的空白和封裝作爲內在的語法規則。
[H4.2]也定義了具有相同域名的多個頭域，他們的值是用逗號分開的列表，可以合併到一個頭域中。這個也適用於SIP，但是細節上略有不同，因爲語法不同。實際上，任何SIP的包頭語法都是基於如下範式的：
header ＝ “ header-name” HCOLON header-value *(COMMA header-value)
這個允許合併在具有同一個域名的多個頭域，到一個用逗號分割的單個頭域中。Contact頭域除了當域值是”*”之外，都允許用逗號分割的列表。
7.3.1 頭域格式。
頭域遵循在RFC2822的2.2節定義的通用頭域格式。每一個頭域都由一個域名加上冒號（”:”）和域值組成。
field-name:field-value
消息頭的正則語法在25節中有介紹介紹。
在消息頭中，允許在冒號的左右有任意個數的空白；但是，在實現中，建議避免域名和冒號中間有空格，並且建議在冒號和值之間使用單個空格（SP）。
Subject: lunch
Subject : lunch
Subject :lunch
Subject: lunch
所以，上面的都是合法的，也是相等的，但是最後一種是我們所推薦的。
頭域可以擴展成爲多行的，只要在每一個附加行前邊用至少一個SP或者水平TAB(HT)打頭就可以了。這種多行的頭域在行結尾並且在下一行之前的空白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等等）放在消息頭的最前邊，這樣可以提高處理的速度。相同域名的域之間的順序非常重要。只有當單個頭域的域值是可以用逗號分割的列表的時候，纔可以表達成爲同一個域名的多個頭域（這就是說，如果遵循7.3定義的語法）。也就是意味着必須可以將同一個域名的多個頭域在不改變消息語義的前提下，改換表達成爲一對”域名: 域值”；這個轉換是通過順序增加每一個域的域值，域值之間用逗號分割。這個規則有幾個例外，就是WWW-Authenticate,Authorization,Proxy-Authenticate,和Proxy-Authorization頭域。多個頭域行可以在消息頭中出現，但是由於他們的語法並不遵循7.3中定義的通用格式，所以，他們並不能合併成爲單個頭域行。
在實現上，必須能夠既能夠處理多個頭域行的情況，也必須能夠處理用逗號分割的合併的單個頭域行的情況。
下邊的幾組頭域是相等的：
Route: <sip:[email protected]>
Subject: Lunch
Route: <sip:[email protected]>
Route: <sip:[email protected]>
Route: <sip:[email protected]>, <sip:[email protected]>
Route: <sip:[email protected]>
Subject: Lunch
Subject: Lunch
Route: <sip:[email protected]>, <sip:[email protected]>
<sip:[email protected]>
下邊各組是合法的，但是並不相等。
Route: <sip:[email protected]>
Route: <sip:[email protected]>
Route: <sip:[email protected]>
Route: <sip:[email protected]>
Route: <sip:[email protected]>
Route: <sip:[email protected]>
Route: <sip:[email protected]>,<sip:[email protected]>,<sip:[email protected]>
每一個頭域值的格式是依賴於它的頭域名的。他可以是任意順序的TEXT-UTF8字符，也可以是一個空格，標記，分隔符，引號括起來的字串的組合。很多頭域都回附帶一個通用的域值格式。這個域值格式是由分號分開的參數名和參數值的組合：
field-name: field-value *(;parameter-name=parameter-value)
雖然在域值裏邊可以有任意數量的parameter-name/parameter-value對，但是不能允許有相同的parameter-name存在（唯一性）。除了特別指出的頭域之外，頭域中的域名、域值、parameter name parameter-value都是大小寫不敏感的。標記詞始終是大小寫不銘感的。除非有特別的指定，引號串的字符串是大小寫敏感的。例如：
Contact: <sip:[email protected]>;expires=3600
和
CONTACT: <sip:[email protected]>; ExPiReS=3600
相同。
Content-Disposition: session;handling=optional
和
content-disposition: Session;HANDLING=OPTIONAL
相同。
下邊的兩個頭域不相同：
Warning: 370 devnull “Choose a bigger pipe”
Warning: 370 devnull “CHOOSE A BIGGER PIPE”