[SIP00]SIP 概念總結

寫著寫著就懂了發表於2014-05-03

SIP
---------------------------
  Session Initiation Protocol
---------------------------
  create, manage and terminate sessions in an IP based network.

SIP 可以幹什麼？ 

      
    sip 只用於建立,修改和結束的sessions，**4個主要目的**：
1. 建立使用者的location資訊：把使用者名稱和地址繫結起來：register
2. 提供一個共同準則的Session，讓所有同意這些準則的使用者聚在一起
3. 管理call management,加入，刪除，改變參與者的狀態
4. 可以改變進行中的session:cancel

SIP 由哪些組成？


    1 UA 通常會把UAC,UAS整合在一起
        - User Agent Client (UAC) : It generates requests and send those to servers.
        - User Agent Server (UAS) : It gets requests, processes those requests and generate responses.
    2 Client
       使用裝置的終端：IP phone,PC:是發給UAC的前做的工作
    3 Servers
     - Proxy Server: 最常見的一種server:最初的requests裡面的訊息不能準備的定位到接收者的位置, 所以發給了Proxy Servers去找到準備位置
     - Redirect Server：重定向server:當前的router 找不到目的地時：返回給client要重新router找：比如：你的上海註冊的電話，跑到廣州去了，然後朋友打電話給你就要重定向操作
     - Registrar：所有的使用者都會註冊到Registrar上，[遵守統一的Url方法](http://wiki.mbalib.com/wiki/%E7%BB%9F%E4%B8%80%E8%B5%84%E6%BA%90%E5%AE%9A%E4%BD%8D%E7%AC%A6)在Internet上所有資源都有一個獨一無二的URL地址。（雖然不註冊也可以發signalling，但通常都是要註冊的）
- Location Server: 真正存放Registrar的地址的地方

SIP有哪些常用的方法(Method)

INVITE:發出邀請:與ACK配合建立session
         1. Invite 裡面包含了SDP(會話描述）
         2. 如果已在session中，也可以用re-invite來調整會話（先ALice和Bob在語音會話，然後聊著聊著就又加入了視訊會話）
     ACK:Acknowledgement 確認
     與invite形成一個三次握手：Invite ->最終應答(200ok)->ACK

[Question]為什麼要三次握手?
  Note :Invite是Method裡面唯一一個三次握手（其它都是用請求->應答模式)
     1. Invite建立session的時間很長，要用User來最終確定建立會話
     2. 使派生代理成為可能，Client會從不同的伺服器得到應答，向每個傳送應答的伺服器發Ack請求來保證在UDP等不可靠協議的SIP操作。（如果其中一個成功了，讓其它的會話也能清理乾淨）
     3. Alice 發Invite給Bob---> Bob沒有收到--->Alice 再發Invite--->Bob收到返回200ok--->這時200ok在網路中又丟失了（悲劇）--->Alice沒有收到200ok，會認為沒有Invite成功，又發Invite---->直到成功收到200ok--->會話還沒有建立（再發個ACK確認）這個例子的點在於：如果Alice 發了Invite沒有收到200ok後就直接關掉了，Bob在這裡發出200ok後，發現Alice沒有再發Invite了，Bob就認為會話建立成功了，天哪，只是Alice不線了，如果再加上一個ACK就可以避免這種情況了
  Cancel 取消一個沒有最終應答的請求。
    1. 發生一個transcation裡面，請求取消已最終應答的Invite是無效的，比如：Alice 對Bob 發出Invite，Bob一直振鈴（1XX,臨時應答）沒有接，然後Alice就發Cancel取消Invite。
        *Attaction*服務對Cancel處理完後還是會發200ok的讓Invite的三次握手還是正常進行
    2.Cancel在派生代理裡面的應用：Alice 給Bob發Invit-->Registar發現有3個地址可用：Bob@home,Bob@office,Bob@outside-->派生代理會向三個派發-->其中Bod@home返回200ok-->200ok沿路返回派生代理時，派生代理會給餘下2個請求發cancel讓他們停止（Invite事務）振鈴
Bye 請求放棄session
  1. 會話只有2方時，其中一方放棄就會terminate session
  2. 會話多方時，只是自己退出會話，其它不受影響。（實現中，其它人離開通常不做Bye處理）
Register 註冊
  1. 使用者發出Register告訴伺服器使用者當前的位置（可多個）所以常和位置定位服務繫結在一起
  2. 上面說的是最簡單的註冊方式，基本上沒有人用，因為網路總是不安全的，還要加入各種安全認[著名而有意思的RSA](http://zh.wikipedia.org/wiki/%E5%85%AC%E5%BC%80%E5%AF%86%E9%92%A5%E5%8A%A0%E5%AF%86)
  3. UAC 發給UAS Register--->UAS 返回401Unauthorized(表明UAC要認證），返回時會加 proxy-Authenticate，noce(這個就是用RSA生成的鑰匙）--->UAC得到這個訊息後再加上Username,Url等發給專門註冊的UAS，然後這個UAS會去根據這個鑰匙再複雜地認證是不是真的-->然後就註冊成功{ok,200,Opt}.bababa.....實際應用很複雜的，不要想幫簡單了。
 OPTIONS: 請求伺服器的效能，檢視對方支援什麼？                
    例如：請求後知道伺服器支援SDP,支援哪一種壓縮方式，那麼客戶端就可以傳送相應的壓縮SDP,從而節省頻寬。

SIP Session


 

1xx = 通知性應答 2xx = 成功應答
100 正在嘗試
100 正在嘗試
180 正在撥打
181 正被轉接
182 正在排隊
183 通話進展 		200 OK
202 被接受：用於轉介
3xx = 轉接應答 4xx = 呼叫失敗
300 多項選擇
301 被永久遷移
302 被暫時遷移
305 使用代理伺服器
380 替代服務 		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 = 伺服器失敗 6xx = 全域性失敗

500 伺服器內部錯誤
501 無法實施：SIP呼叫方法在此處無法實施
502 不當閘道器
503 服務不可使用
504 伺服器超時
505 不支援該版本：伺服器不支援SIP協議的這個版本
513 訊息過長 		600 各處均忙
603 拒絕
604 無處存在
606 不可使用

以下只是一個典型的SIP case(實際複雜多了）


  
  SIP 請求訊息格式
    

INVITE sip:user2@server2.com SIP/2.0
    Via: SIP/2.0/UDP pc33.server1.com;branch=z9hG4bK776asdhds Max-Forwards: 70
    To: user2 <sip:user2@server2.com>
    From: user1 <sip:user1@server1.com>;tag=1928301774
    Call-ID: a84b4c76e66710@pc33.server1.com
    CSeq: 314159 INVITE
    Contact: <sip:user1@pc33.server1.com>
    Content-Type: application/sdp
    Content-Length: 142
    ---- User1 Message Body Not Shown ----

上面是一個INVITE 的Request最基本訊息（會話描述的協議沒有寫出來哦,少年是不是感覺和http一個樣子）：
一個SIP請求由**一個請求行(Request_line），幾個標題頭(Headers）,一個空行(Empty line),一個訊息體(Message body)**,訊息體是可選的，一些請求可以不帶。
*Request_line*:
    方法（INVITE) 請求URL(sip:user2@server2.com) 版本號(SIP/2.0)
SIP 應答訊息格式
   

SIP/2.0 200 OK
    Via: SIP/2.0/UDP site4.server2.com;branch=z9hG4bKnashds8;received=192.0.2.3
    Via: SIP/2.0/UDP site3.server1.com;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
    Via: SIP/2.0/UDP pc33.server1.com;branch=z9hG4bK776asdhds;received=192.0.2.1
    To: user2 <sip:user2@server2.com>;tag=a6c85cf
    From: user1 <sip:user1@server1.com>;tag=1928301774
    Call-ID: a84b4c76e66710@pc33.server1.com
    CSeq: 314159 INVITE
    Contact: <sip:user2@192.0.2.4>
    Content-Type: application/sdp
    Content-Length: 131
    ---- User2 Message Body Not Shown ----

一個應答訊息由**一個狀態行(Status line),幾個標題頭(Headers),一個空行(Empty line),一個訊息體(Message body)**，訊息體是可選的，一些應答可以不帶。
Status line
        協議版本(SIP/2.0) 狀態碼(200) 一些原語(OK)
原語只給人閱讀用，於機器沒一點用。
Note
我們只要保證可靠的最終應答(如：200），臨時的可以不在乎，因為我們只關心session是否被建立，失敗是由於什麼原因,而不關心會話是怎麼建立的
SIP各標題頭的作用
1. From:user1 <sip:user1@server1.com>;tag=1928301774
    人名+他的SIP Url+tag=
2. CallID:a84b4c76e66710@pc33.server1.com
    不同的事務有不同的callid,Bob和Alice在進行棋盤會話Call_id1,這裡2人想語音會話，發Invite裡Callid2，這callid1=/=callid2用於標識不同的transcation!
3. Content: <sip:user2@192.0.2.4>
    根據這個可以直接找到使用者的URL,這個特性非常重要，因為他會話建立後，再建立下一個同樣的會話就可以不經過第一次那麼麻煩的尋求了，這理論是很美好的，但現實中，為了計費，絕對不可能讓content給client給存起來(這樣以後client就可以直接聯絡，不經對伺服器），所以這個東西一定存在server上，client如果需求，就會發請求，由server來處理，但也不用像第一次複雜（因為Server是知道Bob在哪的）
4. CSeq: 314159 INVITE
    - 一個整數字段 方法名，整數部用於同一session(CallID決定)中不同的請求排序，它會與將請求和應答想匹配：比如：Alice 發1 Invite 沒返回--->再發 2 Invite--->沒返回--->再發3 Invite--->這時返回了2 Invite就知道是第2個請求得到了響應（這個數是一直遞增1的）。
    - Ack的CSeq:這個是與Invite裡面的一樣的，這使代理為非成功最終應答產生Ack時不用再建立新的CSeq,保證唯一性，只用client代理建立哦。
    - Cancel的CSeq:這個也是與Invite裡面的一樣的，這也是為什麼CSeq裡面要加Method的原因，如果不加，client就不知道這個是cancel還是invite的應答了。

相關文章