SIP協議詳解(中文)-1

1、SIP協議介紹
Internet的許多應用都需要建立和管理一個會話，會話在這裡的含義是在參與者之間的資料的交換。由於考慮到參與者的實際情況，這些應用的實現往往是很複雜的：參與者可能是在代理間移動，他們可能可以有多個名字，他們中間的通訊可能是基於不同的媒介（比如文本，多媒體，視頻，音頻等）－有時候是多種媒介一起互動。人們創造了無數種通訊協議應用於即時的多媒體會話資料比如聲音，影像，或者文本。本SIP（工作階段初始通訊協定）和這些協議一樣，同樣允許使用Internet端點（使用者代理程式）來尋找參與者並且允許建立一個可共用的會話描述。為了能夠定位精確的會話參與者，並且也為了其他的目的，SIP允許建立基礎的network
hosts（叫做Proxy 伺服器），並且允許終端使用者註冊上去，發出會話邀請，或者發出其他請求。SIP是一個輕形的，多用途的工具，可以用來建立，修改和終止會話，它獨立運作於通訊協議之下，並且不依賴建立的會話類型。

2、SIP協議功能概況
SIP是一個應用程式層的控制協議，可以用來建立、修改、和終止多媒體會話（或者會議）例如Internet 電話。SIP也可以邀請參與者參加已經存在的會話，比如多方會議。媒體可以在一個已經存在的會話中方便的增加（或者刪除）。SIP顯示的支援名字映射和重新導向服務，這個用於支援個人移動業務－使用者可以使用一個唯一的外部標誌而不用關係他們的實際網路地點。SIP在建立和維持終止多媒體會話協議上，支援5個方面：
使用者定位： 檢查終端使用者的位置，用於通訊。
使用者有效性：檢查使用者參與會話的意願程度。
使用者能力：檢查媒體和媒體的參數。
建立會話：”ringing”,建立會話參數在來電者和被叫方。
會話管理：包括髮送和終止會話，修改會話參數，啟用服務等等。
   SIP不是一個垂直整合的通訊系統。SIP可能叫做是一個組件更合適，它可以用作其他IETF協議的一個部分，用來構造完整的多媒體架構。比如，這些架構將會包含即時資料傳輸協議（RTP）（RFC 1889）用來傳輸即時的資料並且提供QoS反饋，即時資料流通訊協定（RSTP）(RFC 2326)用於控制流程媒體的的傳輸，媒體網關控制協議（MEGACO）(RFC 3015)用來控制到公用電話交換網（PSTN）的網關，還有會話描述協議（SDP）（RFC 2327）用於描述多媒體會話。因此，SIP應該和其他的協議一起工作，才能提供完整的對終端使用者的服務。雖然基本的SIP協議的功能組件並不依賴於這些協議。

SIP本身並不提供服務。但是，SIP提供了一個基礎，可以用來實現不同的服務。比如，SIP可以定位使用者和傳輸一個封裝好的對象到對方的當前位置。並且如果我們利用這點來通過SDP傳輸會話的描述，立刻，對方的使用者代理程式可以得到這個會話的參數。如果我們用這個像傳輸會話描述（SESSION DESCRIPTION SD）一樣來電者的照片，一個”呼叫ID”服務很容易就建立了。這個簡單的例子說明了，SIP作為一個基礎，可以在其上提供很多不同的服務。

SIP並不提供會議控制服務（比如議席控制或者投票系統），並且並沒有建議會議應該則那樣管理。可以通過在SIP上建立其他的會議控制協議來發起一個會議。由於SIP可以管理參與會議的各方的會話，所以會議可以跨異構的網路，SIP 並不能，也不打算提供任何形式的網路資源預留管理。

安全對於提供的服務來說特別重要。要達到理想的安全程度，SIP提供了一套安全服務，包括防止拒絕服務，認證服務（使用者到使用者，代理到使用者），完整性保證，加密和隱私服務。

SIP可以基於IPV4也可以基於IPV6

3、術語
在這個文檔中，關鍵詞”必須”,”不允許”,”要求”,”可以”,”不可以”,”應該”,”不應該”,”建議”,”不建議”,”可能”,”可選” 是根據BCP14,RFC 2119[2]的規範描述SIP實現需要的不同層次

4、實施概覽
這節通過簡單的樣本介紹了SIP的基本實現。本節是通過自然的而非正則的樣本來介紹的。

   第一個例子說明了SIP的準系統：定位一個斷點，發出通訊請求，通過協商會話參數建立會話，拆卸剛才建立的會話。
   圖一表示一個典型的Alice和Bob兩個使用者間的SIP訊息交易交換例子.（每一個訊息採用字母”F”和一個用來指向本文的一個數字做標記）在這個例子裡，Alice在她的PC上使用一個SIP的應用程式（比如說一個軟的電話），呼叫Bob在Internet上的一個SIP電話。這個例子也掩飾了兩個SIP代理之間，怎樣為Alice和Bob建立會話串連。This typical arrangement is often referred to as the "SIP trapezoid" as shown by the
geometric shape of the dotted lines in Figure 1.

Alice 通過Bob的SIP標誌 “呼叫” Bob，這個SIP標誌是統一分配的資源（Uniform Resource Identifier URI）稱作SIP URI。SIP URI在19.1節中定義。它很像一個email地址，典型的SIP URI包括一個使用者名稱和一個主機名稱。在這個範例中，SIP URI是sip:bob@biloxi.com,biloxi.com是Bob的SIP服務提供者。Alice有一個SIP URI: sip:alice@atlanta.com。 Alice可以輸入Bob的URI，也可以直接在地址本的一個超級連結上點擊一下Bob的URI。SIP也提供保密URI，稱作SIPS
URI。例如：sips: bob@biloxi.com。 一個基於SIPS URI的通話保證這個通話是安全的，並且對呼叫者和被叫的所有的SIP訊息是加密傳輸的（叫做TLS）。在TLS中，請求是通過加密方式傳輸給被叫方，但是這個加密機制是基於被叫方宿主伺服器的實現的。

SIP是基於一個類似HTTP協議的請求應答的通訊模式。每一個通訊都包含對某個功能的請求，並且起碼需要一個應答。在這個應答中，Alice的軟電話發送一個含有Bbo的SIP URI抵制的INVITE通訊請求。INVITE是一個SIP請求的例子，表示請求方（Alice）希望服務方（Bob）應答。INVTE請求包含一系列的包頭域（Header fields）。包頭中包含很多屬性並且包含了傳輸訊息的附加資訊。在INVITE中有如下的欄位：呼叫的唯一標誌，目的抵制，Alice的地址，Alice和Bob建立會話的類型。INVITE請求（圖1中的F1）可能看起來像這樣的：

INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(Alice’s SDP not shown)

atlanta.com . . . biloxi.com
.    proxy                 proxy        .
.                                         .
Alice’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . Bob’s
softphone                                             SIP Phone
|                    |                    |                    |
| INVITE F1            |                    |                    |
|--------------->            | INVITE F2            |                    |
| 100 Trying F3        |--------------->            | INVITE F4            |
|<---------------            | 100 Trying F5        |--------------->            |
|                    |<--------------            | 180 Ringing F6        |
|                    | 180 Ringing F7        |<---------------            |
| 180 Ringing F8        |<---------------            | 200 OK F9            |
|<---------------            | 200 OK F10        |<---------------            |
| 200 OK F11        |<---------------            |                    |
|<---------------            |                    |                    |
|                            ACK F12                        |
|                    ------------------------------------------------->        |
|                        Media Session                        |
|<================================================>    |
|                            BYE F13                        |
|                    <-------------------------------------------------        |
|                        200 OK F14                            |
|                    ------------------------------------------------->        |
|                                                            |
圖一：SIP矩形表達的SIP會話建立例子。

在簡訊的第一行，包含了請求的類型（INVITE）。在這行之後的是這個請求的頭域。這個例子中包含了最少需要的頭域集合。簡單介紹一下：

VIA域包含了Alice接收發送請求的伺服器位址（pc33.atlanta.com）。同樣這個包含了一個分支參數來標誌Alice和這個伺服器的會話事務。

TO域包含了顯示姓名（Bob）和一個SIP或者SIPS URI（sip：bob@biloxi.com）請求將首先傳輸到這個URI中。顯示姓名（Display names）在RFC 2822中描述。
From域也同樣包含一個顯示姓名（Alice）和一個SIP或者SIPS URI（sip:alice@atlanta.com）這個URI用來標誌請求的原始發起者。
這個域也包含了一個TAG參數，這個TAG參數是一個隨機字串（1928301774），是軟電話（softphone）在URI上增加的一個隨機串。用來做標誌用途的。
Call_ID包含一個全域的唯一標誌，用來唯一標誌這個呼叫，通過隨機字串和softphone的自己名字或者IP抵制混和產生的。通過TO TAG, FROM TAG和CALL-ID完整定義了Alice和Bob之間的端到端的SIP關係，並且表示這個是一個對話性質的關係。
CSEQ或者Command Sequence包含了一個整數和一個請求名字。這個Cseq數字是順序遞增的。每當對話中發起一個新的請求都會引起這個數位順序遞增。
Contact域包含一個SIP或者SIPS URI用來表示訪問Alice的直接方式，通常由使用者名稱和一個主機的全名（Fully Qualified Domain Name FQDN）組成。當FQDN作為首選的時候，許多終端使用者由於不會由名字登記（而導致不能訪問Alice的主機），所以IP地址是可選的。
VIA域告訴大家本請求發送到哪裡並且應答到哪裡，Contract域告訴大家將來的請求將發送到哪裡（奇怪…不是Alice發起的麼，將來的請求應該是Bob才對啊）。
Max-Forwards:最大轉寄數量限制了通訊中轉寄的數量。它是由一個整數組成，每轉寄一次，整數減一。
Content－type包含了訊息本文的描述（訊息本文在本範例中沒有列出）
Content-length:包含訊息本文的長度（位元組數）
完整的SIP包頭域的定義在20節。會話的細節，比如媒體的類型，codec，或者採樣速率，沒有通過SIP來描述。這個可以通過SIP的訊息本文來描述，可以通過其他定義的協議在本文中進行描述。有一種是會話描述協議（Session Descripotion Protocol SDP）（RFC2327[1]）。這個SDP訊息（沒有在例子中列出）通過SIP的訊息中傳送，就像通過附件發送EMAIL一樣，或者說通過HTTP傳輸的網頁一樣。

由於softphone並不知道bob或者bob的sip伺服器biloxi.com在哪裡，所以softphone發送INVITE請求到Alice的sip伺服器,atlanta.com。這個atlanta.com SIP伺服器應該已經在Alice的softphone中配置了，或者可以通過DHCP獲得。atlanta.com SIP伺服器是一台Proxy 伺服器。Proxy 伺服器接收SIP請求並且根據請求轉寄。在這個例子中，Proxy 伺服器接收到INVITE請求，並且回送一個100（Trying）應答給Alice的softphone。100（Trying）應答表示INVITE請求已經收到，並且Proxy 伺服器正在轉寄INVITE請求。SIP的應答是通過一個三位元的數字表示的。SIP應答同樣包含TO、FROM、Call-ID，CSEQ和在VIA中的分支參數，這個參數使得Alice的softphone可以把請求和應答關聯起來。atlanta.comProxy 伺服器收到INVITE請求之後，就去找biloxi.com可能通過DNS服務來找提供這個biloxi.com的SIP伺服器。這在[4]中有描述。最後，轉寄INVITE請求到biloxi.com或者能到達biloxi.com的Proxy 伺服器。在轉寄請求之前，atlanta.comProxy 伺服器會在via頭上增加一個一段包含自己抵制的值（INVITE已經包含了Alice的的地址VIA域）。biloxi.comProxy 伺服器收到這個INVITE請求並且返回一個100（Trying）應答給atlanta.comProxy 伺服器標誌這它已經收到這個請求並且正在處理這個請求。這個Proxy 伺服器通過查詢資料庫，通常叫做地址服務，這個服務中包含了bob的當前ip地址。（我們在下一節可以看到這個資料庫是怎麼回事）biloxi.com代理服務增加另一段包含自己地址的VIA頭域並且發送它到bob的sip
電話。

Bob的SIP電話接收到INVITE請求並且提醒bob有一個從Alice的呼入，這樣bob可以決定是否響應這個呼入。這個意思就是：bob的電話響了。bob的sip電話發送一個180（Ringing）回應，這個回應將通過兩個Proxy 伺服器原路返回給Alice。每一個Proxy 伺服器通過via頭域決定該把這個應答發送給哪裡，並且在發送之前把自己的地址從頭上拿走。雖然DNS和定位服務在路由最初的INVITE請求，180（ringing）響應可以簡單返回給發起者而不需要尋找發起者在哪裡，並且不需要在Proxy 伺服器保留狀態，同時，每一個轉寄INVITE的代理也可以得到INVITE的每一個應答，這樣的特性也非常有用。

當Alice的softphone收到180（Ringing）應答的時候，它提示Alice,可能是通過一個回鈴音，或者螢幕上的一個訊息提示。

在這個例子中，Bob決定響應這個呼叫。當他拿起電話，他的SIP電話發送200（OK）回應給寄件者，表示這個電話已經接起來了。這個200（OK）包含了一個訊息體，這個訊息體包含SDP媒體描述，這個媒體描述包含Bob希望和Alice建立何種媒體串連。同樣，SDP訊息也是兩段交換：Alice發送一個給Bob，Bob發送一個回給Alice。這個兩段的交換提供基本的相容性協商，並且基於簡單的SDP提出/應答交換模型。如果Bob不想響應這個呼叫或者正在響應別的呼叫，一個錯誤的響應會代替正常的200（OK）回送出去，這樣，就不會有串連建立。SIP完整的傳回碼在21節有介紹。Bob發出的200（OK）（圖一的F9訊息）可能長得像這樣的：

SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.com
;branch=z9hG4bKnashds8;received=192.0.2.3
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com
;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com
;branch=z9hG4bK776asdhds ;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
(Bob’s SDP not shown)

應答的第一行包含了應答代碼（200）和原因（ok）。剩下的行包含了包頭域。VIA,TO,FROM,CALL-ID,Cseq包頭域是從INVITE請求包中直接拷貝過來的。（有三個VIA域值－一個是Alice SIP電話增加的，一個是atlanta.com代理加的，一個是biloxi.com代理加的）。Bob的SIP電話增加了一個TAG參數。這個TAG參數會被參與對話的各方所使用，並且在以後的對話中被使用。Contract域包含了一個能直接聯絡到Bob的URI。Content－type和Content_Length域包含了訊息體（沒有在例子中體現），這個訊息體裡邊是Bob的SDP媒體資訊。

除了DNS和位置服務之外，Proxy 伺服器可以自主決定路由，也就是說自己決定應該向哪裡轉寄請求。比如，如果Bob的SIP電話返回一個486（電話正忙）訊號，biloxi.com這個Proxy 伺服器可以轉寄這個INVITE請求到Bob的語音郵箱伺服器。一個Proxy 伺服器可以同時向N個地方發送INVITE請求。這種並發尋找就是傳說中的分流（forking）。

在這個例子中，200（OK）應答通過兩個代理並且發送到Alice的softphone上，Alice的softphone收到這個應答，停止響鈴，並且標誌電話Bob已經接聽。最後，Alice的電話發送一個確認訊息，ACK，到Bob的SIP電話來確認接收到了這個最後的200（o’k）應答。在這個例子中，ACK訊號是直接由Alice的softphone發送到Bob的SIP phone上，跨過了兩個Proxy 伺服器。這是因為兩個端點（Alice和Bob）通過INVITE/200(OK)的請求應答包中的Contact包頭域都知道互相之間的地址了，這個地址是最開始發起INVITE請求的時候所不知道的。所以，不需要兩個Proxy 伺服器再尋找對方的地址了，所以Proxy 伺服器不參與接下來的通話流了。這就完成了一個完整的使用INVITE/200/ACK
三方握手來建立SIP會話的過程。會話建立過程中的細節描述再13節由描述。

現在，Alice和Bob的媒體會話開始了，他們通過發送剛才建立會話所交換的SDP包中約定的互相明白的媒體包來進行會話。一般情況下，端到端的媒體包和SIP訊號控制包通過不同的通訊路徑來發送。

在會話中，Alice或者Bob都可以改變他們自己的媒體會話屬性。這個可以通過發送一個包含新媒體屬性描述的re-INVITE請求來完成。這個re-INVITE是捆綁在一個現有的會話的，這樣參與會話的對方可以明白這是要改變現有的會話屬性而不是建立立一個會話。對方收到這個re-INVITE請求後，會發送一個200（OK）應答表示接受這個改變。請求方通過一個ACK來表示接受了對方的這個200(OK)應答。如果對方不同意這個媒體屬性變化，他會發送一個錯誤的應答比如488（暫時不能進行），這個也會收到發起者的一個ACK響應。不管怎樣，就是是re-INVITE的失敗也不會影響到現有的會話－原有的會話還可以用上次的媒體會話屬性繼續。可以在14節找到會話屬性更改的細節說明。

在通話結束的時候，Bob首先斷開（掛機hangs up），並且發送一個BYE的訊息。這個BYE的訊息將直接送到Alice的softphone，同樣是跳過代理的。Alice通過發送200（OK）應答來確認收到了這個BYE訊息，這個訊息終止了會話並且應答了BYE的請求。ACK在這裡不需要發送－一個ACK訊號只在響應一個INVITE的響應的時候被發送。我們稍晚一點會討論這個INVITE的特別處理，但是基於SIP的可靠性的機制，一個通話的時間可以認為包含電話響鈴和掛機的時間（but relate to the reliability
mechanisms in SIP, the length of time it can take for a ringing phone to be answered, and forking.）基於這樣的原因，SIP請求的處理通常根據是否INVITE請求進行分類，INVITE類和非INVITE類請求分開處理。結束會話的細節可以在15節查到。

24.2節描述了圖1中使用的全部訊息詳細解釋。在某些情況下，所有會話中的包都繼續通過代理轉寄會很有用。比如，如果biloxi.comProxy 伺服器希望在INVITE之後繼續保持SIP訊息流程，他會在INVITE中增加一個頭域（Record-Route）包含一個URI指向這個Proxy 伺服器的hostname或者IP地址。這個訊息會被Bob的SIP電話和Alice的softphone所接到（因為Record-Route頭域將在200(OK)應答中被送回），並且在會話中一直儲存。那麼biloxi.comProxy 伺服器就可以繼續接收和轉寄ACK,BYE,給BYE的200（OK）應答。每一個代理都可以單獨決定是否接收INVITE以後的後續訊息，並且這些後續訊息都可以被發送到那些決定接收後續訊息的Proxy 伺服器。這種情況通常發生在提供mid-call業務的Proxy 伺服器上。

登記服務是另一個常用的SIP操作。登記服務是biloxi.comProxy 伺服器知道Bob當前地址的一個方法。在初始化的時候，或者每隔一段時間，Bob的SVoIP發送REGISTER訊息給biloxi.com的一個註冊伺服器。REGISTER訊息包含了Bob當前登陸伺服器的SIP或者SIPS的URI（sip:bob@biloxi.com）（轉換成為Contact域中的SIP或者SIPS URI）。登記伺服器登記這個映射，這個叫做綁定（binding），寫到一個資料庫裡邊，叫做定位服務（location service），這個資料庫可以被biloxi.com的Proxy 伺服器使用。通常登記伺服器和Proxy 伺服器是做在一起的。一個很重要的概念就是SIP伺服器的差別在邏輯上，並非在物理上的差別。

Bob並沒有限定非得在一個單個裝置上發起註冊。比如，他家裡的SIP電話和公司的SIP電話都可以註冊。這些訊息在定位服務（location service）中儲存，並且允許Proxy 伺服器通過不同的手段尋找Bob。同樣的，不同的使用者也可以在同一個裝置上同時註冊。

定位服務（location service）是一個邏輯概念。他是讓代理服務通過輸入一個URI來查詢到底應該向哪裡轉寄請求。可以簡單通過使用者註冊來建立這個定位服務所需要的資料，也可以通過其他方法。可以通過其他任意的地址映射方式來實現定位服務。

最後在SIP中需要注意的是，註冊服務只是用來提供路由收到的SIP請求的，它並不做請求的身份認證的判定。在SIP中授權和認證可以通過建立在基於請求/應答的模式上的上下文相關的請求來實現，也可以使用更底層的方式來實現（具體在26節有描述）。

完整的註冊SIP訊息描述例子在24.1節。

其他SIP的操作，比如檢查SIP伺服器的負載，或者使用用戶端使用可選項（OPTIONS），或者用CANCEL取消一個未決的請求，在後續的章節中會介紹。

5、協議的結構
SIP是一個分層的協議，意思是說SIP協議由一組相當無關的處理層次組成，這些層次之間只有鬆散的關係。協議分成不同層次來描述是為了能夠更清晰的表達，在同一個小節裡有功能的公用要素的交叉描述。本協議並沒有規定一個具體的實現。當我們說一個要素”包含”某一個層，我們的意思是這個要素複核這個層定義的規則。

不是SIP每一個要素都一定包含每一個層。此外，SIP定義的要素是邏輯上的要素，不是物理要素。一個物理的實現可以實現不同的邏輯要素，或許甚至是基於串列交易處理原理。SIP最底層的是它的文法和編碼層。編碼方式是採用擴充的Backus-Naur Form grammar(BNF範式)。完整的BNF描述在25節；第7節有簡要的SIP訊息結構描述。

第二層是傳輸層。它定義了一個用戶端如何發送請求和接收應答，以及一個伺服器如何接收請求和發送應答。所有的SIP要素都包含一個通訊層。第18節有通訊層的描述。

第三層是事務層。事務是SIP的基本組成部分。一個事務是客戶發送的一個請求事務（通過通訊層）發送到一個伺服器事務，連同伺服器事務的所有的該請求的應答發送回用戶端事務。事務層處理應用服務層的重發，匹配請求的應答，以及應用服務層的逾時。任何一個使用者代理程式用戶端（user agent client UAC）完成的事情都是由一組事務構成的。有關事務的討論在第17節有描述。使用者代理程式包含一個事務層，來實現有狀態的Proxy 伺服器。無狀態的Proxy 伺服器並不包含事務層。事務層包含一個客戶元素（可以認為是一個客戶事務）和一個伺服器元素（可以認為是一個伺服器事務），他們都可以用一個有限狀態機器來處理特定的請求。

在事務層之上是事務使用者（TU）。每一個SIP實體，除了無狀態代理，都是一個事務使用者。當一個TU發出一個請求，它首先建立一個客戶事務執行個體（client transaction instance）並且和請求一起發送，這包括了目標IP地址、連接埠號碼、以及發送請求的裝置。TU可以建立客戶事務，也可以取消客戶事務。當客戶取消一個事務，它請求伺服器終止正在處理的事務，並且復原狀態到該事務開始前的狀態，並且產生指定的該事務的錯誤報表。這是由CANCEL請求完成的，這個請求有自己的事務，並且包含一個被取消的事務（第9節）。

SIP要素，包含，使用者代理程式用戶端和伺服器，無狀態和有狀態Proxy 伺服器和註冊伺服器，包含一個可以互相區別的核心（Cores）。Cores，除了無狀態Proxy 伺服器，都是事務使用者。UAC(使用者代理程式用戶端)和UAS(使用者代理程式服務端)的cores的行為依賴於實現，對所有的實現來說，有幾個公用的原則（第8節）。對UAC來說，這些規則約束請求的建立；對UAS來說，這些規則約束請求的處理和應答。由於註冊服務在SIP中是一個重要的角色，所以UAS處理REGISTER請求有一個特別的名字：登記員（registrar，登記伺服器）。第10節描述了UAC和UAS的對REGISTER實現的core（核心）行為。第11節描述了OPTIONS的UAC和UAS的core實現，這個OPTIONS用來檢測UA的處理能力的（UA-user
agent）。