【1】SIP消息格式
SIP消息分為請求和響應兩類。
請求消息是UAC（客戶端）發往UAS（服務器端），響應消息是UAS發往UAC。
不論請求消息或者響應消息，它都是由一個起始行、若干個頭字段和一個消息體組成。
消息格式：
起始行
消息頭部（若干個頭字段）
空行
消息體（SDP）
如下實例（由wireshark抓包所得的sip包）：
（1）起始行
如上實例，起始行如下：
說明：
起始行對於請求是請求行，對於響應是狀態行。
Method：方法表示請求的類型，核心的類型有6種，INVITE，ACK，BYE，CANCEL，REGISTER和OPTIONS
Request-URI：請求的URI表示此請求將要被發送的目標地址
SIP-Version：一般為SIP/2.0
如下圖為響應消息，起始行為狀態行（狀態行由協議版本、狀態碼和狀態原因短語組成）：
（2）消息頭
如上實例，消息頭展開如下：
說明：
[1] Via
via頭字段指定目前請求消息經過的路徑（專業可理解為路由），同時指定響應也要按該路徑返回。
該字段值中的branch ID參數是一個事務標識符，代理服務器用它來檢測環路。
[2] Max-forwards
在RFC3261中規定，Max-Forwards（最大轉發次數）頭字段必須和任何方法一起規定向下游轉發消息的代理服務器和網關的個數。
當某客戶端沿着某條鏈路發送請求消息的時候，使用該字段可以有效地防止鏈路中出錯或者發生回環。
Max-forwards頭字段的值是一個0-255的整數，指示了該請求還允許被轉發的次數。轉發該請求時，每經過一個服務器該值就減一。
一般默認為70。例如：
Max-Forwards: 70
[3] Contact
Contact字段的值含有一個URI，UA可根據這個地址，直接找到另一個UA，從而避開SIP服務器。
關於rinstance參數，因為有的SIP終端支持多路通話，所以利用rinstance可以區別到底屬於哪路通話。
[4] To
To頭部字段指明請求消息的邏輯接收者或者是用戶或資源的注冊帳號，該地址是作為請求消息的目標地址。
特別強調，將一個請求的To頭字段和Request-URI區分開來非常重要：
在整個會話過程中，To頭字段含有同樣的內容，它是打算用於遠端用戶代理的，它不能被代理改變。
而Request-URI含有在信令路徑中下一跳的地址，並因此在路途中被每個代理改變。
[5] From
From頭域包含了請求發起者的邏輯標志，可能是用戶的address-of-record。
就像To頭域一樣，From頭域也包含一個URI並且可以包含一個顯示的姓名。
SIP可以用這個頭域來實現對請求的檢查和選擇一個規則進行對請求的處理（比如，自動的呼叫拒絕，凡是某人發過來的東西，一律無視等等）。
同樣的，因為From頭域包含的是邏輯名字，所以From URI也可以不包含IP地址或者UA對應的主機名字。
這個域也包含了一個TAG參數，這個TAG參數是一個隨機字串（1928301774），是軟電話（softphone）在URI上增加的一個隨機串。用來做標志用途的。
[6] Call-ID
Call-ID頭字段唯一的標識某個客戶端的某個特定的會話或所有的注冊請求。
一個多媒體會議可以發起幾個Call-ID不同的呼叫，例如，一個發 起者A可以邀請用戶B參與一個會議，隨后又邀請用戶C參與同一個會議，那么，A與B有一個Call-ID，A與C有另一個Call-ID。
那么，A發送 BYE請求時，就是通過不同的Call-ID來選擇結束那個會話。
Call-ID區分大小寫並逐字節比較。
[7] CSeq
命令序列頭字段Cseq位於請求消息中，包含兩個字段：一個無符號整數字段和一個方法名。
該頭字段用於把某對話中的事務進行排序且提供了一種唯一標 識某事務的方法（即INVITE、ACK等method），並能夠區分某請求是新的請求還是重發的請求。
如果兩個Cseq的數字序列以及方法都相等那么這 兩個Cseq就是等價的。
例如：Cseq: 8019084 INVITE
200 OK中的Cseq：完整地復制對應請求中的Cseq，不做任何修改；
ACK中的Cseq：和對應的最終響應有相同的整數序列，只是方法名變為ACK；
CANCEL中的Cseq：和對應的請求（一般是INVITE）由相同的整數序列，只是方法名變為CANCEL；
[8] Allow
Allow列出了發起請求UA支持的方法列表。UA能理解的所有方法都必須列於該頭字段中。
消息中若無該頭字段，則意味UA未提供任何關於它所支持方法的信息，並不意味着UA不支持任何方法。
響應消息中的Allow包含OPTIONS以外其他的方法，因此可以減少所需消息數量。
例如：
Allow: OPTIONS, SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, MESSAGE
[9] Content-Type
Content-Type頭字段指定發給對方的消息體的媒體類型。
如果消息體不為空，那么Content-Type頭字段就必須存在。
如果消息體是空的，並且該頭字段存在，那么就表示了特定類型的媒體的包體長度為0（比如空的音頻文件）。
[10] Supported
Supported頭字段列舉了UAC或者UAS支持的所有擴展。
Supported頭字段包含了一個UAS或者UAC所支持的option tag列表。如果本字段是空的，表示不支持任何擴展。
[11] User-Agent
User-Agent頭字段包含了發起請求的UAC信息。
如果顯示UA的特定軟件版本信息，假如該軟件存在安全漏洞，該UA就容易受到攻擊，應把User-Agent字段作為可配置的選項。
[12] Content-Length
Content-Length頭字段指定發給對方的消息內容長度。
[13] Proxy-Authorization
Proxy-Authorization頭字段用於用戶對要求鑒權的proxy標識自己。
Proxy-Authorization頭字段包含一個證書，其中包含UA對於proxy的鑒權信息和所要請求的資源的域。
關於多字段名的一般規定並不適用於Proxy-Authorization和Authorization頭字段。
雖然多個數值之間沒有逗號分隔，該頭字段名仍可以出現多次，但是不可以將它們結合成一個單獨的頭字段行。
帶有鑒權消息的實例如下：
（3）消息體
如上實例，消息頭如下：
說明：關於消息體內容，我們重點關注一下媒體描述Media Description中的編碼類型。如上例，G.711
Good Good Study, Day Day Up.
順序 選擇 循環 總結