會議建立

服務提供商最重要的事情就是確保會議可以順利的建立。在會議建立的信令 溝通中，相關資訊放置在封包中的各欄位，透過這些資訊來建立這次的會議。封 包中主要分為Start Line、Message Header、Message Body。在2.3.1中會介紹Start line 和Message，在2.3.2則介紹Message Body，Message Body的部分是另外的協定SDP。

2.3.1. Start Line和Message Header

當一個會議要建立時，必頇經過一系列的信令溝通後才能順利完成。如圖2-6 所示，當John撥號給Alice時UA會先發出1. INVITE(通常包含了SDP的訊息)的請求 訊息給Alice，當Alice的UA收到此請求時會先回傳2. 180 Ringing的暫時訊息給John 表示已經收到請求訊息，避免John重複傳送請求訊息。當Alice接起電話時UA會傳 送3. 200 OK的訊息(通常在此會帶有SDP訊息)給John，此時John的UA收到後會傳送 4. ACK給Alice(1.INVITE 2.200OK 4.ACK即是SIP中的三向握手)。5.多媒體串流 會依照SDP中帶的訊息在Alice和John建立通道傳送影像、聲音或DTMF。當Alice 想結束對話掛上電話時，UA就會傳送6. BYE給John，當John收到BYE的訊息時回 應7. 200 OK給Alice。

圖 2-6 會議建立 1 INVITE

2 180 Ringing 3 200 OK 4 ACK

5 Media Session 6 BYE

7 200 OK

在表2-1中，可以看到SIP封包實際的欄位訊息，在封包的開頭會有Start Line，

主要紀錄這次請求或是狀態回覆碼。其次Message Header部分紀錄了此封包來源和 前往的目的端等資訊。Message Body則是記錄了多媒體資訊的相關參數。

表 2-1 SIP 封包

如表2-2、表2-3中所表示，SIP在作會議建立時會使用SIP請求方法，最常使用 是INVITE、ACK、BYE、INFO。而在回應訊息方面SIP也有個別定義回應代碼，

每種代碼依照開頭有不同類別的訊息。此欄位即是SIP封包中的Start Line部分。

• (v): 0

• (o): IN IP4 192.168.2.138

• (s): CounterPath X-Lite 4.0

• (c): IN IP4 192.168.2.138

• (t): 0 0

• (m): audio 58560 RTP/AVP 8 101

• (a): sendrecv

• (a): rtpmap:101 telephone-event/8000

• (a): fmtp:101 0-15

• (m): video 21382 RTP/AVP 115 34

• (a): sendrecv

• (a): rtpmap:115 H263-1998/90000

• (a): fmtp:115 QCIF=1;CIF=1;I=1;J=1;T=1

• (a): rtpmap:34 H263/90000

• (a): fmtp:34 QCIF=1;CIF=1

Message Body

• INVITE sip:[email protected] SIP/2.0

• Via: SIP/2.0/UDP 192.168.2.138:7340;

•

Branch=z9hG4bK-d8754z-953c536658c39074-1---d8754z-• Contact: <sip:[email protected]:7340>

• To: <sip:[email protected] >

• From: "Alice"<sip:[email protected]>;tag=b3afab63

• Call-ID: [email protected]

• CSeq: 1 INVITE

• Content-Type: application/sdp

• User-Agent: X-Lite Beta release 4.0 Beta 2 stamp 56233

• Content-Lenght: 444

Start Line

Message Header

12

請求方法 說明

INVITE 發起會議的邀請(通常會帶有 SDP)

ACK 收到回應 INVITE 訊息後的答應

BYE 用來結束目前的會議

CANCEL 用來取消尚未建立的會議

REGISTER 透過 UA 把使用者帳號和網路相關資

訊傳送給伺服器

OPTION 用來查詢媒體能力和訊息

INFO 在會議中傳送信號，而不會改變會議

狀態

表 2-2 請求方法

狀態碼 說明

1xx(Provisional) 收到請求，正在處理請求中。暫時性的回應訊息讓傳

送端知道發出的要求已經被收到不要再重覆傳送請 求。

2xx(Success) 成功接受請求。表示確認無誤並接受此請求

3xx(Redirection) 沒辦法滿足請求，需要重導到適當位址

4xx(Client Error) 客戶端傳送來的請求內容有錯，或無法滿伺服器需要

的資訊。

5xx(Server Error) 伺服器的錯誤，無法接受客戶端的請求

6xx(Global Failure) 整體環境的錯誤或是請求不被接受

表 2-3 狀態碼

如表 2-4 所表示，在發送請求訊息時 Message Header 中會代有許多欄位。一 個正確的 SIP 請求至少要包含六個標頭: To, From, CSeq, Call-ID, Max-Forwards,

和 Via。這六種標頭是建立 SIP 請求的基本，他們最重要的功用就是提供路由服 務，包含了位址訊息，路由回應和該次通話的認證碼給伺服器和 UA。

標頭 說明

To 受話端的 SIP URI 通常顯示名字

From 發話端的 SIP URI，伺服器可用來做來電警衛等服務 CSeq 作識別各請求的用途，透過 CSeq 可以知曉回應的是哪

次的呼叫。

Call-ID 是個唯一值用來識別發話端，在一次通話中必頇使用

一致的值作為認證，並且在每次註冊時亦是用同組字 串做認證。

Max-Forwards 最大轉送次數，每經過一次轉送依序減一。到達目標 前到 0 會回送 483(Too Many Hops)回應。

Via 紀錄經過的代理伺服器

表 2-4 SIP 標頭

14

2.3.2. 會談描述協議

SDP[9]全名為 Session Description Protocol ，IEFT1998 年發布 RFC 2327。

SDP 協助可預期的參與者發布和溝通會議建立的資訊。SDP 只是一個單純的格式 來做會議的描述，並不是傳輸協定，而和 SIP 一樣使用其他合適的協定(Session Initiation Protocol、Real- Time Streaming Protocol、Hypertext Transport Protocol 等) 來完成工作。SDP 是以多功能來設計的，所以可以在不同網路環境和不同應用成 是使用。 在 SIP 中，當我們要建立一個多媒體通話時，通話的參與者需要交換彼 此的多媒體資訊，例如媒體的傳輸位置、傳輸埠，語音和影像要使用何種編碼傳 送等。在 SIP 中要建立一個會議時會因為本身無法攜帶多媒體資訊，因此需要 SDP 攜帶堆媒體資訊。通常我們會在發送 INVITE 時就把 Caller 的多媒體資訊放入 SDP 一起傳給 Callee，而 Callee 在接受此通話後，會在 200 OK 回應中攜帶 Callee 可 接受的多媒體資訊。SDP 就是表 1 中的 Message Body 的區塊，區塊中的欄位如同 表 2-5 的欄位解說。

欄位 說明

v SDP 的版本，目前只用 0

o 紀錄請求端的訊息 (IP 版本 、IP )

s 主叫端用來描述會議名稱

c 發送端的連線資訊 (網路型態 、IP)

b 使用的頻寬情形

a 可使用的媒體編碼和資訊

t 會議可進行的時間

m 影像或聲音的連線資訊(Port、使用的協定、可用

的編碼)

表 2-5 SDP 欄位解說