+----------------------------------------------------------------------------------------------------------------------------------------------------------------+
+ SIP協議 RFC3261 + RFC2327 SDP 我們主要有三類的會話描述：會話描述、時間描述、媒體描述，具體你可以參看RFC 2327
+----------------------------------------------------------------------------------------------------------------------------------------------------------------+
ICT: 客戶端邀請事務，由客戶端發起的
0d0a == 回車換行CRLF
每行後面都有這個，最後的消息頭有 2個
狀態碼
1：臨時 2：成功 3：重定向(多個contact) 4：客戶端錯誤 5：服務器錯誤 6：全局錯誤
SIP消息
SUBSCRIBE 方法用於請求隨後一個事件或一組事件的異步通知。
NOTIFY 方法用於通知SIP節點先前由SUBSCRIBE 請求的事件已經發生。該方法也可以提供與該事件有關的更進步的詳細信息。
INFO 消息的目的是沿着SIP信令通路攜帶應用層消息。
並不是用來改變SIP呼叫的狀態，或會議SIP的初始化狀態參數。它僅是用於發送通常與會議有關的應用層的可選信息。
傳送SIP 會議中生成的 DTMF 數字
在會議的參加者之間傳送影像或其它的非流信息
re-INVITE 能夠用於在一個會一種改變會議的特性。這通常是與會議相關的媒體流量的屬性或者更新SIP會議地計時器。
增加/刪除媒體流
改變地址，端口
永不分支，因爲確定的UA
REFER 呼叫轉移
OPTIONS 請求可以作爲建立會話的一部分，用來查詢對方的能力使用
MESSAGE 即時消息IM
拆除當前對話，從而保護服務器自身資源，達到keep-alive的目的。
SIP概念：http://www.cnblogs.com/gordon-gao/articles/2516443.html
call : 會議中每個UA是同一個call-ID = 隨機數字@IP或者主機名
事務：
transaction存在於相鄰SIP實體：UAC，UAS
一個事務包含一個請求消息，0或多個臨時響應消息，1或者多個最終響應消息
請求經過每個有事務狀態的proxy時，proxy會生成一個服務器端事務和一個客戶端事務，
並把自己的URI添加到VIA的棧頂，並生成一個全局的branch，所以事務以此來區分。
INVITE事務：UAC一定要回ACK，用3次握手來保證。其他事務：INFO，OPTIONS
對話：
端到端的信令關係。UA之間的，不會與代理間有對話。
dialog起始於對INVITE（REFER）的一個非失敗的響應，如200OK，終止於任意一方發出的BYE
一個呼叫可能包含多個對話（會議）；用call-ID, from, to來標識
早對話：1XX 到 2XX 之間，可能會有UPDATE請求
會話：
存在時間，同對話
VIA：
最下面的VIA是初始化請求的UA插入的；上面的是經過的每個代理插入的
cseq :
標識事務並對事務排序
初始化時隨機，後續按各自方向+1
可標識是新的請求，還是重發的請求
contact
UA希望接受請求的地址，後續請求可以用這個來聯繫當前UA
如果代理沒有插入record-route, 則後續請求可以忽略它，直接用contact來請求
SIP註冊
爲增強安全性，運營商在給你分賬號的時候會給你一個用戶名和密碼，這個呢，是用來鑑權用的，
當你給軟交換髮註冊報文後，服務器會先回應401，請證明，並會帶上加密的方法（一般md5）、隨機數，
你就帶上你的用戶名以及用隨機數加密密碼後的字符串再發一個註冊包，
這樣服務器也會用同樣的算法加密後比較字符串，一樣的就回應200 OK，不一樣就回應403。
如果你每次發的報文call-id是一樣的，cseq也是一樣的，那麼服務器會認爲重複發包，不理會。如果是鑑權的第二個註冊包，那麼cseq會+1。
當發起第一個註冊包時，會起一個定時器，一般是0.5，但是這個值可以根據實際的網絡條件調整，如果在0.5s內沒有收到服務器的響應，
就重發一遍，協議規定的是0.5、1、2、4、4、4、4、4、4、4s來重發，大概是32s的時間內，前面也說了要是你網絡延遲實在厲害，這個值是可以調整的，只要是按照T1、2T1，4T1、8T1，8T1，8T1，8T1，8T1，8T1，8T1就可以了。
解決了 需要在返回401後 把驗證信息保存下來 然後再當心跳發送
RFC3261中定義了兩個基準定時器T1＝500ms和T2＝4s。
客戶端：
T1:500ms, 超時重傳INVITE
TB: 64T1, 超時終結事務 （超時還未收到ACK，狀態轉爲確認，但應當用BYE來終止）
服務端：
Th：64T1，超時終結事務
T2:8T1=4s，重傳，T1超時後，加到T2後以T2重傳
非INVITE：
Tf: 64T1=32s，超時終結事務,F（TCP）and E (UDP)
8. 對話
對話ID = call-id + 本地標籤 + 遠端標籤
對話的創建時機：發送2XX或1XX等非失敗響應時，進入初始對話狀態
UAS： 響應中包含
請求中的Record-Route, 保持順序
Contact : 後續對話的地址, SIPS ore SIP要與其他消息保持一致
路由集：
遠端目的： 請求中contact URI
遠端序列號： 請求中的Cseq
本地序列號： 空
呼叫標識符： 請求中的call-id
本地標籤/URI： 請求To tag/URI
遠端標籤/URI： 請求From tag/URI
對話中的請求 發往第一個Route 或者 requestURI
Request-URI : 遠端目的 or 。。。
Route: 路由集，lr 等參數確定（不含lr，表示本代理服務器不理解此路由機制，）
目標刷新請求消息 只修改遠端URI？ INVITE 由 reINVITE 來刷新
收到含To tag的請求
收到的序列號問題：遠端序列號爲空，大於請求序列號
9. 會話發起過程
發送INVITE，收到2XX後，發送ACK；
請求可能被分叉，所以可能收到多個2XX，每個都是屬於同個呼叫的一個對話，通過TO中的TAG區別，對每個都要回ACK
UAC：
Supported: 支持的擴展功能
INVITE sdp 請求， 2XX sdp 響應
2XX , ACK
UAS： 發送2XX, 未收到ACK時，間隔T1後重發，間隔時間加倍，直到T2，仍未收到，發送BYE
10. 會話更改過程
通過在已經建立的Dialog中發送reINVITE來修改媒體流，媒體接受地址等
UAC：reINVITE中攜帶新的SDP，過程不能重疊
UAS：更改是否有效，是就修改，發送2XX，等ACK，等不到發送BYE；否就發送488.
11. 會話結束過程
通過BYE，或者拒絕
UAC：發送BYE
UAS：收到BYE，檢查相應的對話，不存在，發送481；存在，發送2XX；正在處理，發送487
12. 代理服務器
將請求和應答分別路由到UAS，UAC的SIP實體。也可作應答：錯誤響應，鑑權，此時相當於UAS
無狀態：轉發後即丟失信息
有狀態：事物狀態，可能分叉請求，即把一個請求分到多個服務器。
採用TCP傳輸（有狀態傳輸）時可以不用記錄事物狀態？兩種類型可以隨時轉換
13. SIP事務
非2XX響應，其事務包括ACK消息；2XX，不包括ACK
非INVITE事務： 不使用ACK
響應與客戶端事務匹配: 即判斷是否爲重傳的
1. via branch 一致
2. Cseq的方法 一致 （cancel請求與原請求屬於不同事務，但branch一致）
多播請求下，只處理第一個響應。（To tag不同）
服務器端事務
100響應，避免重傳產生的網絡擁塞
請求與服務端事務的匹配
1. via branch "z9hG4bk..."
2. via sendby ,防止不同客戶端產生的branch相同
3. via method
14. 傳輸
面向連接的傳輸 : TCP（處理大塊消息？） SCTP TLS。 兩個對等的代理服務器使用面向連接傳輸協議時，會使用2個連接用於各自方向上的連接？？？
客戶端傳輸層：
UDP 改 TCP，用於 處理大消息 或者 使用擁塞控制協議（MTU最大傳輸單元）
組播時，via 中添加 maddr == 目的地組播地址, ttl = 1
add via: sendby ==
UDP default port == 5060 TLS == 5061
接受響應 檢查sendby
服務器傳輸成
sendby 中的地址同包的來源不同，添加via received == 所收數據包的源地址 ？？？
響應處理：IP: received or sendby中的地址 port : sendby中的端口
數據幀 content-length
面向消息的傳輸 UDP 。。。超長，丟棄；短了，錯誤
面向流 的傳輸 TCP 消息體的大小
15. 普通的消息成分
SIP:user:passwd@host:port;uri-param?heads (可能沒用戶部分)
參數：transport, maddr, ttl(UDP組播數據包的生存時間), lr
轉義 ： a == %61 (% HEX)
URI比較
18. HTTP鑑權的使用
質詢鑑權，分類digest鑑權機制，用401、407來要求UAC鑑權
UAC：
收到401後，重新發請求，Cseq 加 1
有證書，在Authorization中提供證書；無，用anonymous重試
407: proxy-authorization
UAS：
401中www-authenticate攜帶質詢參數：realm,
407中的proxy-autherticate
SIP 協議消息應答代碼解釋詳錄
1xx = 通知性應答
100 正在嘗試
180 正在撥打
181 正被轉接
182 正在排隊
183 通話進展
2xx = 成功應答
200 OK
202 被接受：用於轉介
3xx = 轉接應答
300 多項選擇
301 被永久遷移
302 被暫時遷移
305 使用代理服務器
380 替代服務
4xx = 呼叫失敗
400 呼叫不當
401 未經授權：只供註冊機構使用，代理服務器應使用代理服務器授權407
402 要求付費（預訂爲將來使用)
403 被禁止的
404 未發現：未發現用戶
405 不允許的方法
406 不可接受
407 需要代理服務器授權
408 呼叫超時：在預定時間內無法找到用戶
410 已消失：用戶曾經存在，但已從此處消失
413 呼叫實體過大
414 呼叫URI過長
415 不支持的媒體類型
416 不支持的URI方案
420 不當擴展：使用了不當SIP協議擴展，服務器無法理解該擴展
421 需要擴展
423 時間間隔過短
480 暫時不可使用
481 通話/事務不存在
482 檢測到循環
483 跳數過多
484 地址不全
485 模糊不清
486 此處太忙
487 呼叫被終止
488 此處不可接受
491 呼叫待批
493 無法解讀：無法解讀 S/MIME文體部分
5xx = 服務器失敗
500 服務器內部錯誤
501 無法實施：SIP呼叫方法在此處無法實施
502 不當網關
503 服務不可使用
504 服務器超時
505 不支持該版本：服務器不支持SIP協議的這個版本
513 消息過長
6xx = 全局失敗
600 各處均忙
603 拒絕
604 無處存在
606 不可使用
<--- SIP read from UDP:10.50.144.100:8578 --->
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 10.50.144.100:8578;rport;branch=z9hG4bK1433206046
From: <sip:[email protected]>;tag=1898566852
To: <sip:[email protected]>
Call-ID: 1125968959
CSeq: 21 INVITE
Contact: <sip:[email protected]:8578>
Authorization: Digest username="90001", realm="asterisk", nonce="628e2fa5", uri="sip:[email protected]", response="58cf8d7ee6328ec232c9788b10816ca0", algorithm=MD5
Content-Type: application/sdp // 用於媒體協商
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO // Allow: 支持的請求方法
Max-Forwards: 70
User-Agent: Linphone/3.4.0 (eXosip2/unknown)
Subject: Phone call
Content-Length: 376
v=0
o=90001 3239 3239 IN IP4 10.50.144.100 //origin 所有者/創建者 和會話標識
s=Talk //subject 會話的主題
c=IN IP4 10.50.144.100 //connect 連接信息 多播地址
b=AS:256
t=0 0 //time 會話時間，SIP用外部信令的方式建立媒體流，所以爲0
m=audio 7076 RTP/AVP 111 110 100 104 3 0 8 101 //media 每個媒體流，可以有0個或者多個 通常，0 端口號指示不期望該媒體流，下面的格式按照優先級排列
a=rtpmap:111 speex/16000 // 指示從RTP 載荷類型到編碼的映射
a=fmtp:111 vbr=on // 提供媒體格式的其他參數
a=rtpmap:110 speex/8000
a=fmtp:110 vbr=on
a=rtpmap:100 iLBC/8000
a=fmtp:100 mode=30
a=rtpmap:104 AMR/8000
a=fmtp:104 octet-align=1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
<------------->
<--- SIP read from UDP:10.50.146.30:39842 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.50.146.14:5060;branch=z9hG4bK216c45cc;rport=5060
Contact: <sip:[email protected]:39842;rinstance=cbe06931a28eb1a2>
To: <sip:[email protected]:39842;rinstance=cbe06931a28eb1a2>;tag=a31f2211
From: "90001"<sip:[email protected]>;tag=as12dbc590
Call-ID: [email protected]:5060
CSeq: 102 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
User-Agent: eyeBeam release 1102q stamp 51814
Content-Length: 184
v=0
o=- 3 2 IN IP4 10.50.146.30
s=CounterPath eyeBeam 1.5
c=IN IP4 10.50.146.30
t=0 0
m=audio 48000 RTP/AVP 0 101
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=sendrecv // 媒體流的方向，收發是默認的，inactive只通信
<------------->
