Session Initiation Protocol (SIP)簡介

說明Session Initiation Protocol是什麼。


Session Initiation Protocol是由Internet Engineering Task Force(IETF)組織中的Multiparty Multimedia  Session Control (MMUSIC)工作小組所制定。中文翻譯看過兩種:「會議初始通信協定」、「議程初始協定」。為了忠於原味,本文中還是以「SIP」簡稱之。

簡介的主題如下:

  1. SIP應用的範圍
  2. SIP元件說明
  3. SIP方法(Methods)
  4. SIP回覆代碼類型
  5. SIP Session Setup循序圖
  6. 參考資料

SIP應用的範圍:(BACK)

  • 多方多媒體通訊(Multiparty Multimedia Communication)系統
  • 網際網路電信(Internet Telephony)
  • 網路電話(IP Phone)
  • 網路用戶交換機(IP-PBX)
  • 網路電信交換機(Softswitch)
  • 第三代行動通訊(3G)的控制信號通訊協定

SIP元件說明:(BACK)

  • User Agents: User Agents是SIP網路環境中的終端設備,它可以是SIP電話機或者在個人電腦端的SIP客戶端軟體,它包函User Agent Client (UAC)以及User Agent Server (UAS),UAC負責產生(建立)請求(Request),而UAS負責產生依照請求產生應答(Response)。每個SIP User Agent都包含UAC以及UAS的功能),這個模式與傳統的client/server架構不同,例如:網站與瀏覽器,在瀏覽器在瀏覽網站的期間,網站伺服器一直是Server端,瀏覽器端一直是Client端。
  • SIP Proxy: SIP Proxy負責將User Agent或者其他的SIP Proxy發出的請求代為傳遞到另外一個SIP元件。當User Agent發出請求的時候,請求並不是直接傳送到目的端的User Agent,而是經由一層層的SIP Proxy後才將請求訊息傳送到目的端的User Agent,,每個SIP Proxy都會決定出下一個路由且對請求訊息做適當的加工處裡以利訊息的傳遞。目的端的User Agent回覆結果的時候也是一樣會經由相反的路由將結果回覆給請求端的User Agent。
  • Redirect Server: 當User Agent或者Proxy所發出的請求傳送到Redirect Server時,Redirect Server回覆Redirect訊息(3xx),讓User Agent或者Proxy知道需要將訊息重新導向至另一個SIP元件。
  • Registrar Server: Registrar Server提供User Agent進行註冊的介面,用以進行管理以及特定的服務,並且更新Location Server上的User Agent資訊或者更新其他的資料庫。
  • Location Server: Location Server負責儲存User Agent的資訊,例如:URL、IP位址、身分、特性等等。

SIP方法(Methods):(BACK)

方法 說明 RFC
INVITE 邀請建立Session。 RFC3261
ACK 回覆確認邀請(INVITE)的回覆已收到。 RFC3261
BYE 結束一個以連接的Session。 RFC3261
CANCEL 取消一個已發出邀請但尚未連結的Session。 RFC3261
REGISTER 註冊使用者資訊。 RFC3261
OPTIONS 查詢Server的功能與選項。 RFC3261
INFO 用來傳送midcall訊號(mid-session資訊)並不改變Session的狀態。 RFC2976

SIP回覆代碼類型:(BACK)

代碼類型 說明
1xx 訊息通知,請求處裡中尚為完成。(例如:Trying)
2xx 請求處裡成功。
3xx 重新導向,將請求訊息重新導向至另一個SIP元件。
4xx 客戶端錯誤,錯誤的原因在於請求端。可以矯正後重試。
5xx 伺服器端錯誤,錯誤的原因在於目的端。可以重試其他的location。
6xx 錯誤(Global Error),請求失敗且無法重試。

SIP Session Setup循序圖(rfc3261中所提供的例子):(BACK)

在循序圖中Alice’s softphone要透過SIP提出邀請Bob’s SIP Phone,Alice’s softphone位於atlanta.com這個網域,而Bob’s SIP Pohone位於biloxi.com這個網域,所以當Alice’s softphone將INVITE訊息發送出來的時候,第一步會將訊息送給所屬網域的SIP Proxy。SIP Proxy依照訊息中的內容發現目的端的User Agent位於biloxi.com這個網域,所以將訊息轉送至biloxi.com這個網域的SIP Proxy,且同時通知Alice’s softphone這個User Agen:100 Trying的回覆訊息。biloxi.com所屬的SIP Proxy經過查詢後找出Bob’s SIP Phone現在的IP位址並將INVITE訊息傳送給Bob’s SIP Phone,並且回覆atlanta.com SIP Proxy:100 Trying的回覆訊息。在Bob’s SIP Phone收到INVITE訊息並進行Ringing的動作時,回覆180 Ringing的訊息將透過biloxi.com SIP Proxy與atlanta.com SIP Proxy傳回Alice。在Bob確認接起電話後,Bob’s SIP Phone將200 OK的訊息經由biloxi.com SIP Proxy與atlanta.com SIP Proxy傳回Alice’s softphone。Alice’s softphone在收到200 OK的訊息後直接(請注意!未經過SIP Proxy喔)將ACK訊息回覆給Bob’s SIP Phone並且啟動Media Session進行通話。在結束通話後,Bob’s SIP Phone發出BYE訊息並且接收到由Alice’s softphone回傳的200 OK回覆訊息後結束通話與SIP控制訊號。

Alice’s softphone所發出的INVITE訊息如下:

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)

  • 第一行表示將INVITE(邀請)bob@biloxi.com。
  • 第二行Via表示Alice現在所在的IP位址(以domain name表示)也就是說Bob回覆訊息時將會回覆到此位址。
  • 第三行Max-Forwards內容表示訊息最大被轉送(Forward)的次數。
  • 第四行To內容表示目的端的名字是Bob與所屬的URI。顯示名字的規範請參照RFC2822。
  • 第五行From內容表示發送耑的名字是Alice與所屬的URI。
  • 第六行Call-ID內容是一個唯一的鍵值用來表示此Call。
  • 第七行CSeq內容包含一個序號以及方法(Method)名稱。
  • 第八行Content內容為發送端的URI,用來讓其他元件知道如何直接連絡發出訊息的User Agent。
  • 第九行Content-Type內容為訊息內容的說明。
  • 第十行Content-Length內容為訊息的總長度。

Bob’s SIP Phone回覆的200 OK訊息如下:

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。
  • Via、To、From、Call-ID、CSeq這些欄位內容複製傳送過來的Request。而有三個Via欄位的來源為: Alice’s SIP Phone、atlanta.com SIP Proxy以及biloxi.com SIP Proxy所增加上去的。
  • 第九行Contact表示Bob所使用的SIP Phone目前所在的URI。可用於直接連線使用。
  • Content-Type與Contetn-Length表示訊息內容的說明以及長度。

參考資料:(BACK)

 

在〈Session Initiation Protocol (SIP)簡介〉中有 10 則留言

  1. 您好..請問您有在研究SIP嗎?
    因為我的碩士論文是做這方面的研究..可否與您交換交換心得呢?
    看了您這篇文章..感覺跟wiley的Internet Communications Using SIP那一本書中講SIP簡介的那一段有點像耶
    我剛接觸SIP不久…如蒙不棄..可否互相討論討論呢??

  2. 因為工作的需要,在三個月前上過SIP Application Server的課程,因為講師要求上課前需要有SIP的觀念,這篇文章是在上課前臨時惡補作的筆記(沒錯,有參考Internet Communications Using SIP的內容以及網路上的資料),但是因為上完課以後沒有在實際應用過,所以可能記的不是很清楚!
    後來因為上課的學員有人完全沒有SIP的觀念,所以講師花了一天的時間說明SIP,講師是英國人,是位非常專業的講師!
    如果我幫的上忙的話,歡迎討論!:)

  3. 您好,請問您有架設過SIP的Registrar Server嗎?我最近在做這方面的專題,一直苦於沒有相關的人可以討論呢^__^

  4. 你好,我最近也是在做這方面的專題,但是遇到SIP架構上的問題(registrar 後proxy要怎麼找到使用者),不知是否方便的話可以一起討論.
    PS.SER也是不錯的選擇,忘記他是包含那種server了..

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *

這個網站採用 Akismet 服務減少垃圾留言。進一步了解 Akismet 如何處理網站訪客的留言資料

Secured By miniOrange