sip事務的概念：乙個sip請求以及由它觸發的一系列應答（包括臨時應答和乙個最終應答）。
sip請求有6種（核心規範定義的，也有擴充套件），也叫6個方法(method欄位標識)：invite, ack, options, bye, cancel, register
sip 請求的格式包括請求行(如invite sip:192.168.101.30 sip/2.0)，sip應答的格式包括狀態行(如sip/2.0 100 trying)；sip應答的狀態碼從100到699，其中100~199是臨時(provisional)應答。
invite請求是三次握手機制，其他請求都採用兩次握手機制。
cancel 請求用於取消懸而未決的事務，我的理解是一方發出invite，但是另一方始終沒有做出應答，發出200ok訊息（超過了預設的振鈴時長），那麼uac會 自動發出乙個cancel請求，uas返回200ok，並且同時發出487狀態碼的應答，uac再對收到的487訊息發出ack確認，即最開始的 invite和487以及ack構成三次握手。
options請求用於詢問伺服器的效能情況，包括這個伺服器所支援的方法（可能會有擴充套件方法）和會話描述協議。
**伺服器的三種型別：保留呼叫狀態**、保留狀態**、不保留狀態**。這三種型別的**在處理能力和所占用資源上有差別，在**分發中我們採用網路核心無狀態，而在流量較小的網路邊界採用智慧型性高的保留（呼叫）狀態伺服器處理路由。
sip訊息編碼採用文字方式（即使用字串），相對的是二進位制的編碼方式，前者易於除錯和擴充套件，後者則有利於節省頻寬。
sip標題頭
：call-id
字 段用於標識乙個特定邀請以及與這個邀請相關的所有後續事務（即標識乙個會話），比如一方發起邀**入乙個西洋棋的會話，那麼invite請求以及應答， bye請求以及應答都共享乙個call-id，因為這兩個事務都屬於乙個特定邀請。而兩個使用者之間可以同時存在多個邀請（比如在下象棋的同時發起聊天的邀 請），那麼乙個邀請中的後續事務將通過這個邀請特有的call-id來區分，如一方發出bye訊息來結束聊天，但是下棋仍然進行中，那麼另一方將根據 bye訊息的call-id來確定要結束的究竟是哪乙個會話。
cseq
欄位是用來給同乙個會話中的 事務進行排序的。可以理解為，會話由call-id來標識，會話中的事務則由cseq標識。除了ack請求和cancel請求，invite之後的請求中 cseq欄位的數字是最初請求(invite)的cseq遞增的結果。而ack和cancel請求則擁有與它所確認（取消）的請求相同的cseq數字部 分，只是方法名不同。
(sip標題頭續)
contact
欄位是被呼叫方傳送200ok訊息時帶上的，包含了被叫方的真實ip，這樣sip伺服器在路由第乙個invite請求之後就可以被解除安裝掉（越過），不再需要存在於信令路徑中。
recode-route
和route
字 段是用來使sip伺服器保留在每次請求中，不被繞過。record-route欄位由信令路徑上的伺服器新增（每經過乙個信令路徑上必須存在的**，就添 加乙個record-route標題頭），maddr引數包含該**的ip位址。被叫方發出的200ok應答包含record-route和 contact欄位（record-route可能有多個），呼叫方收到200ok後根據這兩個字段建立用於後續請求的route標題頭（可能有多個）， 其包含的是信令路徑上的下一跳的下一跳的（hehe，有點彆扭，不過意思是對的）真實ip。
to 字段 總是包含被呼叫方的位址（通過sip**時是公用位址，點對點時是真實ip），要注意的是區別該標題頭和sip訊息請求行中的request-uri。 to在信令路徑中不會被**改變，然而request-uri包含的是信令路徑中下一跳的位址，因此在路途中被每個**改變。
via
字 段儲存所有處理請求的**位址（包括使用者**和sip**），它可以用來檢測路由迴圈，也用於使應答訊息經過請求訊息來時相同的路徑（方向相反）。因此， 在請求訊息傳送時，via標題頭的數量是隨著跳數逐漸增加的，而應答訊息返回時，via標題頭的數量則逐漸遞減（每經過一跳則剝離乙個有它自己位址的 via標題頭）。
(sip標題頭完)
sip訊息可能含有訊息體（乙個或多個），通常是會話描述符，也可以是**或其他附件。一般情況下，訊息體只對ua有意義，因此可被端到端加密。有時候，sip**處於控制的原因也需要檢查被交換**的資訊。
nvite事務：
sip使用udp傳輸協議來傳送invite訊息時，要使用逐 跳重傳機制保證invite的最終傳送，即使用者**ua和sip**proxy都要保證invite到達下一跳，下一跳收到時會返回乙個臨時應答 （proxy返回100trying，ua返回100trying和180ringing），**在限定時間內收不到應答即會重傳invite。
臨時應答（100~199）用於阻止逐跳invite重傳，沒有端到端的可靠傳輸，也就是說當被叫方返回180應答時，如果在路徑中途丟失，也不會重傳。
最終應答（200~699）能被保證到達它們想要去的目的地。
成 功應答（200~299）被可靠地傳送到呼叫方ua，但不是使用逐跳重傳機制。只有呼叫方ua能為最終成功應答傳送乙個ack（直接傳送到被叫方ua）， 如果成功應答在路徑中途丟失或者ua發出的ack丟失，那麼被叫方會在限定時間內收不到ack時重新傳送最終應答，直到收到ack的確認。
非成功最終應答（300~699）使用和invite一樣的逐跳機制。被叫方使用者**將持續重傳非成功應答（給前一跳），直到收到ack為止（proxy也可以為非成功應答傳送ack）。
cancel事務：
cancel事務與invite事務都是逐跳事務，但是處理方法不同，路徑上的每乙個**收到cancel請求時，都會傳送乙個最終應答來響應（而不是發出臨時應答），並且向下一跳傳送乙個cancel請求。
《sip揭秘》格式詳解
sip事務的概念 乙個sip請求以及由它觸發的一系列應答 包括臨時應答和乙個最終應答 sip請求有6種 核心規範定義的，也有擴充套件 也叫6個方法 method欄位標識 invite,ack,options,bye,cancel,register sip 請求的格式包括請求行 如invite sip...
SIP訊息格式
sip 訊息格式 首行 start line 請求行 響應 狀態行 請求行 1.方法 invite,cancel,ack,bye 用於會話的建立 修改和終止 register 用於對使用者的聯絡資訊進行註冊 options 用於對伺服器及其能力進行查詢 2.請求 url 用來標識所請求資源的 sip...
《sip揭秘》讀書筆記1
sip事務的概念 乙個sip請求以及由它觸發的一系列應答 包括臨時應答和乙個最終應答 sip請求有6種 核心規範定義的，也有擴充套件 也叫6個方法 method欄位標識 invite,ack,options,bye,cancel,register sip請求的格式包括請求行 如invite sip ...