1

Session Initiation Protocol (SIP)

•SIP 的設計是要擁有最大的彈性, 所以並沒有非常詳細的定義各個 entity 一定要處理, 或要如何處理. •因此 interoperation 是非常重要的.

2

2

Goal – We want to know

SIP ArchitectureSIP Messages SyntaxBasic Call ExampleSession Description Protocol (SDP)SIP Extensions Interworking with PSTN and H.323

•Question:•1. SIP message 的設計上有許多的 redundancy, 如 response 會複製request 中的 header, 即使沒有用處. We need get To: and From: once. It is not necessary to send it many times. Why?•2. If SIP agent finds the copied data is not consistent as the original one (ex: To☺, is it necessary to reply an error?•3. To: tag, From: tag, Call ID form a dialog ID. Why not to use a unique value for dialog ID.

3

SIP Architecture

• Introduction to SIP

• SIP Network Entities

• Simple Example

4

4

Introduction

A powerful alternative to H.323More flexible, simplerEasier to implement

Advanced features

Better suited to the support of intelligent user devicesA part of IETF multimedia data and control architectureSDP (Session Description Protocol), RTSP (Real-Time Streaming Protocol), SAP (Session Announcement Protocol)

•SIP 只是單純的 call setup 的方式, 所以必須結合其他的 protocols, 如•SDP (Session Description Protocol) 用來描述 session media 的持性，例如所使用的 codec 。•RTSP (Real-Time Streaming Protocol) 是一個 application-layer 的proposed standard, RFC 2205, 用於傳送 multimedia streaming. 它像是一個 framework, 依狀況選用 TCP, UDP 或其他簡化的 transport, 利用 RTP 傳送 streaming data 與 control signals.•SAP (Session Announcement Protocol) 是 RFC 2974, 第二版的multicast session directory announcement protocol. 對於multimedia conference, 需要有 directory 儲存 session setup 的相關訊息 (ex: pre-arranged conference). 這些 directory 採用 distributed 的方式, 所以彼此間需要定期做 announcement, 交換訊息.

5

5

The Popularity of SIP

Originally Developed in the MMUSIC (Multiparty Multimedia Session Control)

A separate SIP working groupRFC 2543 → The latest version: RFC 3261

SIP + MGCP/MEGACOThe VoIP signaling in the future

“bake-off” or SIPit (SIP Interoperability Tests)Various vendors come together and test their products against each other

To ensure that they have implemented the specification correctly To ensure compatibility with other implementations

•SIP 是由 IETF 於 1993 年 3 月制定的通訊協定, 做為 Internet conferencing, telephony 的信令控制協定, 用來建立, 更改, 與終結通訊服務的議程. 是屬於 Application 的 protocol.

•最早是 IETF (Internet Engineering Task Force) 的 MMUSIC (Multiparty Multimedia Session Control) 這個Working group 在制定SIP, 但當 SIP 逐漸受到重視, 便成立 SIP working group.•早期 SIP 定義於1999年 RFC 2543，新一版的定義在 RFC 3261 中(2002 May), proposed standard。

•不同於 H.323 的完整架構， SIP 的特色就是簡單而且富有彈性。它是Text-based encoding的方式，和 HTTP 類似的 request-response transcation model。因此很容易去 implement、或是開發新的功能。因此許多人認為 MGCP/MEGACO （詳見第六章）加上 SIP, 將成為未來 VoIP 的signaling protocol 的主流. 例如 3GPP 便指定使用 SIP 等做為 All IP Network 的通訊協定.•許多的廠商到目前為止, 已經進行多次 SIP 產品相容的測試. 被稱為 SIPit(SIP Interoperability Tests). 開始的 7 次還被稱為 bake-off (烘焙比賽). •課本的 Fig 5-1 說明舉辦的次數與參加的廠商數目. 雖然最近幾次出席的廠商數目下降, 但事實上產品的數目卻大幅上升, 可見 SIP 受歡迎的程度. •最近一次的 SIPit-14 在 Feb 2004.

6

6

SIP Basic (1/2)

SIP is a peer-to-peer protocolEnd-devices initiate sessions

SIP is an application layer signaling protocolCreate, modify and terminate sessionsApplications can be voice, video, gaming, instant messaging, presence, call control, etc.

SIP uses existing IETF protocols to provide:Message formatting (HTTP 1.1)Name resolution and mobility (DHCP and DNS)Media (RTP)Media negotiation (Session Description Protocol—SDP)Application encoding (MIME)

•注意: SIP 本身並不提供 service, SIP 是提供 primitives (原始的架構), 來實現多樣的 service.

7

7

SIP Basic (2/2)

SIP is ASCII text-basedEases implementation and debugging

Uses URI style addresses and syntaxFlexible transport

can use UDP, TCP, TLS, or SCTPUses SDP for describing media sessions

Audio, video, realtime text ... Simple extensible protocol

Methods—Define transactionHeaders—Describe transactionBody—SDP and other MIME content

8

8

SIP Architecture

A signaling protocolThe setup, modification, and tear-down of multimedia sessions

SIP + SDPDescribe the session characteristics

Separate signaling and (RTP) media streams

SIP Signaling

IP Network

RTP Media Stream

SIP User SIP User

•SIP 是一個處理信令的通訊協定(signaling protocol)，主要是處理 sessions 的建立、變更、以及結束。

•SIP 的contents 搭配了 SDP 來描述 session 的持性，例如：通話的雙方會利用 SDP 來決定要使用的 codec 。•而 SIP 只負責 signaling 的部分，media 的部分就交由 RTP 來負責搭載。這個 signaling 與 media 分開的特色與 H.323 類似。•上圖說明 media 與 signaling 是走不同的路徑. 所謂的 SIP user 可以是PC+ handset 或直接與網路相連的 SIP phone.

9

9

SIP Network Entities

Client-Server ModelClients

User agent clients (UAC)Application programs sending SIP requests

ServersResponds to clients’ requestsFour types of servers

•SIP 使用 client-server 的架構, 因此 SIP 的網路實體可分為 client, server, 與同時兼具 client/server 兩種角色的 proxy 三大類:

•SIP 的客戶端(client)稱之為 User Agent Client (UAC)，凡是送出SIP request 的就稱之為 SIP Client 。有可能是一台電腦或是一個SIP Phone。•SIP Server 就是回應 Client 的 request 而發出 response 的元件。

•Servers 依據功能可分為四大類, 以下會分別說明.•其中一類為 Server agent server (UAS) 即電話的另一端, 回覆訊息給 UAC.

•User Agent = UAC + UAS. User agent 同時擔任 client 以及 server 的角色。

10

10

Types of Servers (1/3)

Proxy serversHandle requests or forward requests to other serversCan be used for call forwarding, time-of-day routing, or follow-me services

SIPProxyCaller@work.com Collins@home.net

1.Request Collins@work.com

2.Request Collins@home.net

4.Response 3.Response

• Server 依據執行的功能分為四大類:• Proxy server 是一個 optional SIP component.

• Proxy server 的角色和 web service 中的 proxy 很像，主要就是負責處理及轉送 (routing) request 與 response 到正確的地方。Proxy 同時擔任client 以及 server 的角色, 但 Proxy server 不會 initiate SIP messages

• Proxy sever 可以提供像是 time-of-day routing（依據使用者一天的行動模式依時間設定不同的轉接）, follow-me service （電話轉接）的服務.

• 上圖中的 Collins (柯林斯:一種雞尾酒的名字) 可能會在 2 個 SIP devices (分別在公司與家中) 使用 SIP phone. Collins 有一個代表他這個使用者的名稱 Collins@work.com, 其中 work.com 是公司的 domain name. 家中 SIP devices 的網路位址為 Collins@home.net.

• Collins 的朋友 Caller (我們用 Caller@work.com 代表他) 想要打電話給Collins. Caller 送出 Invite 的訊息給 proxy, proxy 查詢資料庫發現目前Collins 是在家中, 因此將 request 轉送到 Collins 家中的電腦. 相同的, 所回覆的 response 也會經由 proxy 傳回給 caller.

• Note: 真正傳送語音的 trunk 是不會經過 proxy 的.• Proxy 的使用可能是 Caller 移動到不同的 ISP 的控制下, 必須透過此

ISP 的 proxy 幫忙轉送訊息.

11

11

Types of Servers (2/3)

Redirect serversMap the destination address to zero or more new addresses

Redirect Server

1.Request Collins@work.com

Caller@work.com

Collins@home.net

2.Moved temporarily Contact: Collins@home.net

3.ACK

4.Request

Collins@home.net

5.Response

•Redirect server 是一個 optional SIP component.

•Redirect server 主要的功能就是對應使用者名稱到現在所在的網路位址, 可以對應到 1 或多個網路位址。當使用者離開原本的網路位址，到別的地方時，redirect server 會透過一個 302 response 告知 UAC callee的新位置。•上圖中 Caller 想要打電話給 Collins, 但不知 Collins 目前真正的所在. 因此Caller 送出的訊息給 redirect server, 其中包括代表 Collins 個人的位址“Collins@work.com”. Redirect server 查詢資料庫後, 將 Collins 家中的 SIP phone 位址 ”Collins@home.net”傳回, Caller 並回覆一個 Acknowledge. 之後 Caller 將 Invite request 送到 Collins 家中的電腦. 相同的, Collins 會回覆一個 response. •Note: 利用 redirect server 也可以提供像是 call-forwarding, follow-me service 的服務. •Redirect server 與 proxy 不同之處在於 redirect server 本身並不幫忙轉送request, 只傳回正確的位址給 UA. 真正傳送語音的 trunk 也是不會經過redirect server.

12

12

Types of Servers (3/3)

A user agent server (UAS)Accepts SIP requests and contacts the userThe user responds an SIP responseUsually, a SIP device = UAC+UAS

A registrarAccepts SIP REGISTER requests

Indicating that the user is at a particular addressPersonal mobility

Typically combined with a proxy or redirect server

•Server agent server (UAS) 即電話的另一端, 接收與處理 UAC 發出的 request, 並回覆訊息給 UAC.

•通常UAS 也是一個 UCS，例如：SIP Phone 是一個 User agent, 可以接電話與打電話。因此 SIP 可用於建立 peer-to-peer 的連結.

•Registrar 是一個 optional SIP component.

•當 SIP 使用者來到一個新的網路, 必須使用新的網路位址, 這時就要向Registrar 做註冊的動作.

•例如 Collins 進入公司, 就可使用公司 PC 對 registrar 註冊, 此後所有的電話便會轉送到公司.

•當使用者移動到別的地方時，可以透過 SIP REGISTER request 告知registrar 我的新位置，達到 user mobility 的功能。Registrar 本身並不幫忙轉送 request, 只傳回正確的位址給 UA. •通常 registrar 會搭配 proxy, redirect server 做在一起.而 UAS 會搭配 UAC 做在一起. 所以網路上的只會看到 user agent 與 proxy server.

13

13

SIP Call Establishment

It is simple, which contains a number of interim responses.

a

b

c

d

e

f

g

INVITERinging

OK

ACK

Conversation

BYE

OK

SIP device A

SIP device B

•以上是一個簡單的 SIP 建立通話的流程。透過 INVITE, OK, ACK 這樣 3-way handshake 方式來達成連線的建立。•其中 Ringing response 是一種臨時的回應 (provisional response). 所謂provisional response 是臨時的回覆, 提供額外的資訊給 caller，在此處就是告知對方 B 的 SIP device 已經開始振鈴。但整個邀請 (INVITE)的過程仍未完成, 所以稱為 provisonal.•當使用者拿起話筒接聽電話時, 完成整個 INVITE 的要求完成, B 會送回200 OK. 這個 OK response 為最終的回應 (final response).•A 必須要送一個 ACK request 給 callee B 來表示 final response 正確的傳到 caller。•Step e 表之後開始通話.•通話完畢後, 有一方掛斷電話 (此圖中 A 先掛電話 ), 會送出 BYE 訊息給 B. B 也同意其要求, 送回 OK.

14

14

Call Completion to Busy Subscriber Service

a

b

c

d

e

f

gConversation

BYE

OK

ACK

OK

Ringing

INVITE

Busy (Try at 4pm)

INVITE

ACK

j

i

h

SIP device A

SIP device B

•這是一個利用 SIP 的機制, 提供一個類似傳統電話網路的 Call Completion to Busy Subscriber Service 特殊服務的範例. 這樣的服務可以避免 A 不斷的嘗試打給 B. •Steps a,b,c: A 想打電話給 B, 但是 device B 送回 Busy, 並在訊息中通知 A 使用者不在, 請在 4pm 之後再試.•Device A 在 4:00 pm 呼叫使用者 A, 問他是否要再打電話給使用者 B.•Steps d,e: Device A 呼叫 device B, 而且接受其要求開始振鈴. •Steps f, g: 使用者 B 接起電話, 送回 OK, 且 Device A 送回 ACK.•Step h: 開始通話.•Steps i, j :通話完畢後, 有一方掛斷電話 (此圖中 A 先掛電話 ), 會送出 BYE 訊息給 B. B 也同意其要求, 送回 OK.

15

15

SIP Advantages

Attempt to keep the signaling as simple as possibleOffer a great deal of flexibility

Does not care what type of media is to be exchanged during a session or the type of transport to be used for the media

Various pieces of information can be included within the messages

Including non-standard informationEnable the users to make intelligent decisions

The control of the intelligent features is placed in the hands of the customer, not the network operator.

E.g., SUBJECT header

•從上述的建立電話的例子中, 可看到 SIP 的簡單的特性, 這個特性使得與其他傳統信令系統相比, 有下面的優點:

•比較有彈性, SIP 可在 TCP, TLS, UDP 或其他 transport layer 上傳送, 基本上 SIP 只是 application layer 的 service, 沒有規定底層使用的 transport layer.

•SIP 訊息可以包括許多 optional 欄位, 欄位中可以填入使用者自定的資料. 這樣的方式, 可以讓兩端的使用者分享一些 (不是協定制定的) 資訊.

•例如 SIP 並不考慮傳送語音所使用的 media format, 也不考慮傳送media 所使用的通訊協定. 因此當有新的服務時, SIP 會比較容易嵌入使用.•例如 SIP INVITE 訊息中有一個 SUBJECT 的欄位. Callee會依據這個欄位內含的主旨, 決定是否接通電話. •所以 SIP 提供的攜帶資訊的機制, 使得通話的使用者可以依據資訊控制系統的運作, 不再像傳統電信系統是控制在業者的手中.

16

Overview of SIP Messaging Syntax

• SIP Message Syntax

• SIP Request Messages

• Simple Example

17

17

SIP Messaging Syntax (1/2)

Text-basedSimilar to HTTP (Hypertext Transfer Protocol)Disadvantage – more bandwidth consumption

SIP messagesmessage = start-line

*message-header CRLF[message-body]

start-line = request-line | status-lineRequest-line specifies the type of requestResponse line (status-line) indicates the success or failure of a given request.

•SIP 的 message 結構是以文字為主(text-based)，而且類似於 HTTP。相對於 binary-based 而言，SIP的 parsing 較簡單，但是比較浪費頻寛。

•SIP 的 message 內容中，第一行 start-line 是來表示 SIP Request 或是SIP Response 的命令列.

•| 表示二選一. 換言之, SIP 訊息有兩大類: request 與 response.•若是 start-line=request-line 表示是一個 request. 若是 start-line=status-line 表示是一個 response 的代碼.Ex: request-line = INVITE.

•之後是一行一行的 message header, 各 header 間以換行命令 CRLF 隔開，之後才是 message-body.

•* 表示 message-header 是有許多個.•[] 表示 message-body 是可有可無的.

•CRLF (carriage-return line-feed sequence)

18

18

SIP Messaging Syntax (2/2)

Message headersAdditional information of the request or responseE.g.,

From: /To: headers for the originator and recipientRetry-after headerSubject header

Message bodyDescribe the type of sessionThe most common structure for the message body is SDP (Session Description Protocol).Could include an ISDN User Part messageExamined only at the two ends

•Message header 提供 request/response 更多的資訊. •Ex: 訊息的來源與接收者的名稱. Retry-after header 可以存放下午四點再來嘗試的資訊.Subject 代表主旨.•Header 每個電話經過 entities 都會 lookup.

•Message body 是用於描述要被建立的 session 的型態, 包括描述所要傳輸的 media. 但由於 SIP 並未定義其格式, 所以必須用其他協定. 事實上message body 可以包含多個部份, 可以各自有不同的格式.

•通常會使用 SDP. Ex: 以 SDP 表示將使用 G.711 A-law.•Ex: 當 SIP 和 PSTN 以 SS7 互動時, capability 資訊會包含 ISUP (ISDN User Part) 的訊息, 也會被包裹於 SDP 中.•可以是 MIME content. Ex: 回應給 INVITE 的 response 可以是HTML document, 或是 image.•message-body 的內容只有參與通話的 endpoints 才會拆開看。

19

19

SIP Requests

Method SP Request-URI SP SIP-version CRLFEx: INVITE sip:yoyo@s1.yy.com SIP/2.0Request-URI

The address of the destination

MethodsRFC 2543: INVITE, ACK, OPTIONS, BYE, CANCLE, REGISTERRFC 3261: SUPPORT, RFC 2976: INFO, RFC 3262: PRACK, RFC 3265: SUSCRIBE & NOTIFY, RFC 3311: UPDATE, RFC 3428: MESSAGE, RFC 3515:REFER

•Request 是 SIP 第一大類訊息, 其格式為 Method(空格 SP)Request-URI(空格 SP)SIP-version(換行CRLF)

•Method 代表 sender 在此 session 想要提出的要求 (ex: INVITE: 想建立電話)•Request-URI 表示此 Request 要送達的目的地, 那一台電腦的那一個SIP使用者.•SIP-version 目前是 2.0 版.

•在 RFC 3261 定義了 6 種 methods: INVITE, ACK, OPTIONS, BYE, CANCLE, REGISTER.•另外, 又新加入 RFC 2976 定義的 INFO, RFC 3311 定義的 UPDATE, RFC 3315 定義的 REFER.

•INFO 是在講電話的過程中, 做 application-layer information 的交換•UPDATE 加上 SDP 可用於讓 session 改變所使用的 media.•REFER 是讓電話轉接給第三者.•PRACK 代表 provisional acknowledgement, 暫時回應來自 receiver 的 provisional response, 希望能提供更高的可靠性.•SUBSCRIBE/NOTIFY 當發生 event 時 (ex: presence, monitoring of calls), 可以讓兩方以描述事件-通知這樣的訊息互動. •MESSAGE 提供 page mode 的 instant messaging service.

20

20

SIP Methods (1/2)

INVITEInitiate a sessionInformation of the calling and called partiesThe type of mediaSimilar to IAM (initial address message) of ISUP

ACK Only when receiving the final response

BYETerminate a sessionCan be issued by either the calling or called party

•INVITE 用於開起一個 session, 要請對方加入這個 session. 可以是簡單的雙方通話或 conference call.

•對於一個 INVITE 的 SIP 訊息, 會包含雙方的資訊, 傳送 media 的型式. •類似 ISUP 中的 IAM (Initial address message).

•ACK 用於通知對方的INVITE, 已收到對方最後確認的 response 訊息 (ex: 200 OK, 除 1xx 之外 response).

•如果用 INVITE 呼叫對方, 對方開始振鈴並送回 (altering), 則 caller 是收到 altering, 但因為不是最終的結果, 所以不會送回 ACK.•相反的, 如果用 INVITE 呼叫對方, 但對方忙線中送回 (busy), 則caller 會送回 ACK. •其他的method就不會回 ACK.

•BYE 用於通知對方要結束這個 session. 不論是那一方, 只要使用者掛斷電話, 就要送給對方 BYE.

21

21

SIP Methods (2/2)

OPTIONSQuery a server as to its capabilities

A particular type of media

CANCELTerminate a pending requestE.g., an INVITE did not receive a final response

REGISTERLog in and register the address with a SIP server“all SIP servers” – multicast address (224.0.1.175)Can register with multiple serversCan have several registrations with one server

•OPTIONS (選項)用於詢問 called party 關於它的 capabilities. •例如, 詢問被叫端所能支援的 media type (ex: response 會說明支援那些 method, content types, extensions, codec).

•CANCEL 用於要求對方結束這個 session. •例如, 如果用 INVITE 呼叫對方, 但對方一直都沒有送回 response, 則 caller 會使用 parallel search 給多個目的地 (因為一個使用者可能同時註冊了許多位址). 如果其中之一送用 final response, 則 caller 會送給其他目的地 CANCEL.

•REGISTER 是 user-agent client 向 SIP server 註冊的動作, 讓註冊員(registrar) 知道自己的 address.

•User-agent 可以向一個 local SIP server 註冊, 也可以用224.0.1.175 這個 multicast address 向所有 SIP severs 註冊.•One number service 是向多個 SIP server 註冊的範例.

22

22

“One number” ServiceRegistrar/Proxy CallerUser at Address 1User at Address 2

OK

Register (address 1)

Register (address 2)

OK

INVITE

Trying

INVITE

INVITE

OK

CANCEL

OK (for INVITE)

OK (for CANCEL)ACK

ACK

Conversation

•這個 One number service（又稱為 follow me service）的 message flow，主要是讓使用者無論移動到公司還是家裡都不會漏接電話的一種服務。

•當使用者在兩個地方(Address1/address2) 都註冊之後，有人打給該使用者時，proxy（此時又稱為 forking proxy）會同時把 INVITE 轉送到兩個地方。當其中一個地方有人接聽時, 送回 200 OK, proxy 就會使用 CANCEL 取消另一個地方的連線。這樣可以讓使用者到那都不會漏接電話。

•像 sip:collins@work.com 這樣一個 address, 代表 Collins 這個使用者, 透過 work.com 這樣的 domain name, 找到其 registrar, 就可知到目前 collins可能在那些地方, 全部都會嘗試去呼叫他.•Question: 如果 Collins 不在家, 但家人接起電話, 反而另一支 Collins 所在的電話(訊號處理較久 or 接得比較晚)就可能被 cancel.

23

23

SIP Responses

SIP-Version SP Status-Code SP Reason-Phrase CRLFRequest: INVITE sip:yoyo@s1.yy.com SIP/2.0Response: SIP/2.0 200 okStatus-Code

A three-digit number

Reason-PhraseA textual description of the outcomeCould be presented to the user

•Response 是 SIP 第二大類訊息, 其格式為 SIP-version(空格)Status-Code(空格)Reason-Phrase(換行CRLF)

•Status Code 代表回應 response (Ex: INVITE sip:yoyo@s1.yy.com SIP/2.0)所回傳的答案, 它是一個三位數字組成的碼, (ex: 200: 同意), 給 sender 的機器解讀.•Reason Phrase 表示會有此 status code 的原因 (ex: OK), 這是那一台電腦的那一個 SIP 使用者看的資料.•SIP-version 目前是 2.0 版.

24

24

Status Code

Provisional response1XX Informational (ex: 181 Ringing)

Final response2XX Success (ex: 200 OK)3XX Redirection (ex: 302 Moved temporarily)4XX Client Error (ex: 401 Unauthorized)5XX Server Error (ex: 505 SIP version not supported)6XX Global Failure (ex: 604 Does not exist anywhere)

All responses, except for 1XX, are considered final and Should be ACKed.

•Status code 分為 6 類, 分別以三位數的第一個數字代表:•1XX (Provisional information) 臨時的一個回應, 提供某些訊息, 表示request 已經收到了, 繼續處理中. Ex: 181 Ringing 表示已經振鈴.•2XX (Success) 表示 request 已經收到了, 處理完畢, 成功的回應. 在原 SIP 中只有 200 OK 一項. Ex: 對於 INVITE, 回應 200 OK 代表使用者已接起電話. 後來在 REFER method 定義裡, 又多了 202 accepted 這一項.•3XX (Redirection) 表示 request 要轉到其他適當的 agent 做進一步的處理. Ex: 302 表使用者目前不在, 所以請 sender 轉送到 response 中所攜帶的address. •4XX (Client Error): 因 request 內容中包括不好的 syntax, 或 request 無法滿足 server 的要求. Ex: 401 Unauthorized 表示 sender 未經授權, 沒有資格提供要求.•5XX (Server Error): 有效的 request, 但因 server 本身的能力造成的失敗. Ex: 505 SIP version not supported 是 SIP 版本不合的問題.•6XX (Global Failure): 如果這個 request, 任何的 server 都無法滿足其需求而造成的失敗. Ex: 604 Does not exist anywhere 是根本沒有這個使用者.•2XX - 6XX 都是最終的回應. 換句話說, 如果送出 response 的 sender, 收到 1XX 以外的 response, 都要送回 ACK.

25

25

SIP Addressing

SIP URIs (Uniform Resource Identifier) user@hostAlso called as URLs (Uniform Resource Locators)

Two types of SIP URIs:Address of Record (AOR) (identifies a user)

sip:collins@work.comContact (identifies a device and is usually a Fully Qualified Domain Name, FQDN)

sip:line2@127.24.45.4 or sip:collins@station1.work.com

Other example:sip:3344556789@telcom.netsip:3344556789@telcom.net;user=phonesips:bob@biloxi.com

•Uniform Resource Indicators (URIs) 或 Uniform Resource Locators (URLs). 使用 URI 是 SIP 一項很重要的, 很有利的特徵. •SIP 的要求與回應都要送到特定機器(host)上特定的使用者(user), 因此其位址是以 URI 來表示. 其格式為 user@host.

•類似 email address, 事實上也建議使用 email address. 但不同的是 email 使用mailto:collins@home.net, 而 SIP 使用 sip:collins@home.net.

•依據電話主叫端要呼叫的是使用者 (i.e., 不知道使用者所在的電腦), 還是呼叫使用者所在的設備, SIP URIs分成兩類:

•Address of Record (AOR) 定義一個使用者•Ex: sip:collins@work.com, 使用 work.com 是 domain name, 而非特定設備. 許要有 DNS 來找到這個 domain. 比較常用.

•Contact 定義一個機器設備. 使用 Fully Qualified Domain Name (FQDN) 來指定機器.•Ex: sip:collins@station1.work.com 就指向一台機器 station1.

•其他的範例:•對於 PSTN 的用戶, 可以使用其電話號碼, 做為 SIP address, 如sip:3344556789@telcom.net, 就會轉到特定 gateway telcom.net 處理.•SIP URI 後面可以加入參數, 給予更多的說明, 如 sip:3344556789@telcom.net;user=phone, 其中 “user=phone”表明 user=3344556789是 PSTN 的電話, 而不是 user name.

•事實上有多種 URI 方式:•像 sip:alice@example.com 這樣的 SIP URI, 最常被使用, 在 RFC 2543 就已有定義. •像 sips:bob@biloxi.com is a Secure SIP URI 這樣的 SIP URI, 定義於 RFC 3261, 是為了security, 特別使用 TLS (transport layer security) over TCP 來傳送. Registrar, Proxy, Redirect 都必需支援 TLS.

•Note: 如果要提供 hop-by-hop security, 則需使用 IPSec.•像 Tel:54065;phone-context=dialplan.biloxi.comtel這樣的 SIP URI, 為了 telephone numbers 而定義. •像 Tel:+18005551212;phone-context=e164.arpa 指出一個完整的 e164 號碼. 也可以用“ENUM”的服務.

26

26

Message Headers

Provide further information about the messageEx: Subject: vacationEx: Content-Type:application/sdp

Table 5-2, Table 5-3Four main categories

General, Request, Response, and Entity headers

•在 start-line 之後, SIP 訊息會跟著許多 message headers, 提供更多資訊. 每個 header 都是以換行 (CRLF) 隔開. 很像是 Q.931 information element 的角色.•message header 是不分大小寫的.

•Ex: 在 INVITE 中的 Subject 帶著主旨 vacation, Content-Type 說明message body 的格式為 SDP.

•依其傳送的內容, 標頭分成四大類: message header: general, request, response, entity header.•Table 5-2 列出 request 與 header 間的關係, i.e., 是否在此 request 會採用此 header. Table 5-3 則列出 response 與 header 間的關係.

27

27

General Headers

Used in both requests and responsesTo, From, CSeq, Call-ID, and Via are mandatory for all SIP messages.Basic information

To: header in a REGISTER indicates the address-of-record of the user.

Ex: To: Collins@work.com

To: header in an INVITE indicates the called party.Ex: To: Boss<sip:Manager@work.com>Ex: To: Boss<sip:Manager@station2.work.com>

From: header indicates the originator.Ex: From: Daniel<sip:Collins@work.com>;tag=4455

•其中有所謂的通用標頭 (general header)，是 request/response 中均會夾帶的標頭。攜帶最基本, 一般的資訊.

•To, From, CSeq, Call-ID, and Via 在所有 SIP 訊息中都是mandatory.•Max-Forwards 在 SIP request 中也是 mandatory.

•比方說 To (callee的URI)、From (Caller的URI)、Call-ID (一個能唯一辨認出這個session的名稱)、Contact (真正可以通話的 SIP URI)。

•Ex: 在 REGISTER 中的 To:header 代表在 Registrar 中儲存 user 資料的位址 (address of record).•Ex: 在 INVITE 中的 To:header 表示被叫方.•Ex: 在 SIP 訊息中的From:header 代表主動打電話的一方.

28

28

To: Header

The To header field first and foremost specifies The desired "logical" recipient of the requestThe address-of-record of the user or resource that is the target of this request.

The original recipient may or may not be the UAS processing the request, due to call forwarding or other proxy operations.Request-URI identifies the UAS that is to process the request.

•To: header 最初是 (From: 欄位註明的使用者) 用來指定 (1) 發話端希望接收這個 request 的 “logical” & “original”接受者, (2) 發話端希望在目的地處理這個 request 的 address-of-record 或是 resource. •Request URI 才是真正指出處理此 request 的 UA.•但是 To: header 上面的位址不見得是最後處理 request 的機器或資源. 可能是因為 call forwarding, 或是 proxy 特殊的服務.

•Ex: To: Boss<sip:Manager@work.com> 這只是個代表 Boss 的 address-of-record 的 URI, proxy 最終將電話轉送到另一台Manager@station2.work.com 處理.

•最終處理 request 的 UAS, 若發現 To: header 與自己的 URI 並不相同, 則可以自行決定是否要接受這個 request. (可以是 software 自行決定, 或顯示於螢幕讓人來決定). 然而 SIP 建議在這樣的情況下, 或 UAS 不瞭解 To: 上的 URI, 仍要接受此 request. 否則 UAS 可送回 403 (Forbidden) 拒絕這個 request.

29

29

Request-URI

Request-URI identifies the UAS that is to process the request. The initial Request-URI of the message SHOULD be set to the same value of the URI in the To field.

One notable exception is the REGISTER

A UA uses the REGISTER method to bind its address-of-record to a specific contact address.

•To: header 和 Request-URI 比較: •Request-URI 指出處理此 request 的 UA.

• Request-URI 必須是一個 SIP URI 或 SIPS URI 或 a general URI (RFC 2396) 或 "tel" URI (RFC 2806) •如果處理 request 的 UAS 不瞭解 Request-URI, UAS 應該要送回 416 (Unsupported URI Scheme) 拒絕這個 request.•如果 Request-URI 沒有辦法很明確指出處理此 request 的 UAS, proxy 應該要送回 404 (Not Found) 拒絕這個 request.

•UA 使用 REGISTER 將自己的 address-of-record 和目前所在的 contact 位址連結(bind) 在一起.•最初 UA 送出的 SIP 訊息的 Request-URI 應該 (SHOULD) 和 To: header 的URI 相同. 這是方便設定或為了保密等的原因 (Request-URI 會在傳送時修改)•唯一的例外是 REGISTER, Request-URI 指的是 registrar, 而 To: 指的是 user 的 address of record.•To: 和 From: 基本上只有 caller 和 callee會看, 但是 specification 並沒有指出中間 proxy 是否要或不要看, 以維持最大的彈性.

30

30

Contact: Header

Provides a URI for use in future communication regarding a particular sessionEx1: In a SIP INVITE, the Contact header might be different from the From header.

An third-party administrator initiates a multiparty session.

Ex 2: Used in response, it is useful for directing further requests directly to the called user.Ex 3: It is used to indicate a more appropriate address if an INVITE issued to a given URI failed to reach the user.

•Contact 只用於 INVITE transaction.•Contact 是一個很有用的 header, 可以用在底下的狀況:•在 INVITE 中的 Contact: header, 不同於 From: header, 例如 From: 上是一個 Address of record, 而非特定機器的位址; 而且啟始一個 session 的機器, 不見得真正參與 session 通話, 所以 Contact 所帶著的才是真正要通話的呼叫端的 SIP URI。對於 multiparty session, 也是通常由管理者起動, 卻不參與 conference call.•對於第一個request, 可以要經過許多 proxy 轉送, 最後到達接收端, 接收端也會以原路徑傳回 response. 但在接下來的 request 或其他訊息, 就不用經過 proxy, 因此可以用 response 中的 Contact: header, 找到接收端的真正的網路位址, 接下來的 request (如 ACK) 也可直接送給真正的 callee.•Contact: header 也可以用在當 INVITE 的 INVITE URI 失敗(不正確)時, 可以找出究竟是要傳送給誰. 此時 receiver 回應的 302 moved temporarily 中就會帶 Contact:, 內含真正可以通話的 SIP URI.•Contact 與 From 不同的情況在投影片均有列舉。

31

31

Request / Response Headers

Request HeadersApply only to SIP requestsAddition information about the request or the clientEx: Subject: vacationEx: Priority: (emergency, urgent, normal, or non-urgent)

Response HeadersFurther information about the response that cannot be included in the status lineEx: UnsupportedEx: Retry-After

•Request Header 這一類的 header 只放於 SIP request 訊息中, 以提供更多的資訊.

•例如 Subject: header 以文字敘述此 session 的主旨.•例如 Priority: header 說明此 request session 的中要性. 可分為emergency, urgent, normal, non-urgent.

•Response Header 這一類的 header 只放於 SIP response 訊息中, 在status code 之外, 提供更多的資訊.

•例如 Unsupported: header 指出 server 沒有支援的功能.•例如 Retry-After: header 說明使用者目前不在, 多久之後可再嘗試.

32

32

Entity Headers

Indicate the type and format of information included in the message bodyContent-Length: the length of the message bodyContent-Type: media type of the message body

Ex: Content-Type:application/sdp Content-Encoding: for message compressionContent Disposition: how a message part should be interpreted

session, icon, alert, render

•Entity Header 這一類的 header 用於指出 SIP message body 中, 所採用的型態與格式.

•例如 Context-Length: header 說明 message body 的長度. (單為byte)•例如 Context-Type: header 說明 message body 採用的格式協定, 通常為 SDP.•例如 Context-Encoding: header 說明 message body 採用的加解密的資訊.•例如 Context-Disposition: header 說明 message body 中有一些特別的部份, 需要進一部說明.

•若值為 session, 表示 message body 中帶有與 session 相關的資料, 用以描寫 session 的特性.•若值為 icon, 表示 message body 中帶有 sender 個人的畫像, 可顯示給對方看.•若值為 render, 表示 message body 中帶有 sender 想要告訴其他參與的”使用者”的資料.•若值為 alert, 表示 message body 中帶有個人化的 ring tone (以 audio clip 方式包裝), 以呼叫使用者.

33

Examples

• Registration

• Invitation

• Termination of a Call

34

34

RegistrationRegistrarCollins@station1.work.com

REGISTER sip:registrar.work.com SIP/2.0Via: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123Max-Forwards: 70From: sip:Collins@work.com; tag = 123456To: sip:Collins@work.comCall-ID: 123456@station1.work.comCSeq: 1 REGISTERContact: sip:Collins@station1.work.comExpires: 7200Content-Length: 0

SIP/2.0 200 OKVia: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123From: sip:Collins@work.com; tag = 123456To: sip:Collins@work.comCall-ID: 123456@station1.work.comCSeq: 1 REGISTERContact: sip:Collins@station1.work.comExpires: 3600Content-Length: 0

a

b

•Registration 是讓 server 得到目前使用者所在的位址. 此例中, Daniel Collins 這個人 log in 到 station1.work.com 這台機器, 為了讓別人可以打電話到這裡來. 因此 Collins 向 Registrar 做一個註冊的動作. •Request-URI 指出目的地的位址, 若中間有經過 proxy, 也會看 Request-URI 決定 callee的位址. 至於 To: header, 在Registration 中代表的是 registrar 看的 address of record. 在 INVITE 中, 通常 To: header 是給 caller 和 callee看. 但是沒有說proxy 不會去看 To: header.•REGISTER中有一些特殊的 header:•Via: header 說明這個 request 從第一台機器送出, 到目前為止路徑上所有經過的節點.

•特別是在 Via 中指定傳輸時所使用的協定: UDP. 內定 SIP 是走 UDP. 但也可以是 TCP, SCTP, TLS.•Via 後的位址是用於表示若有 response 時, 要送到自己的那一個位址, 也可以加上 port number.•在會經過許多 proxy 的狀況中, response 可利用 via 經由原路折返, 找到 originator.•Via 中會有 branch parameter, 用於 proxy.

•From: header 代表啟動註冊的一方. (可以是 manager, 不見得是真正接電話的使用者).•From 中包含 tag parameter, 這是一個由 sender 所產生的亂數, 做為 sender 的 ID.

•To: header 表示在 Registrar 中, 代表 Collins 的使用者記錄的位址 (Address of record). •Note: request 中的 To: 後面沒有 tag, 如果雙方會建立 dialog, response 中的 To: 後面會帶著 receiver 產生的 tag, 做為 receiver 的 ID.•Dialog 是一個 two user agents 間 peer-to-peer 的關係. 處理 dialog 的機制會維護兩端間訊息的順序與傳送的路徑.

•Call-ID 是由 sender 指定, 打電話來這台電腦的 SIP 電話號碼 (ex: 123456@station1.work.com), 所以若 user 在此機器上, 同時對不同的 Registrar 註冊, 都要使用此相同的 Call-ID. 為避免重覆, 建議使用 local-id@host 的格式. 通常前面是一個 random number, 後面是機器的 URI.•CSeq (Command Sequence) 是一種指出 transaction (交易) 與其 order (順序) 的方式. 包括一個 32-bit unsigned 號碼與啟動這個 transaction 的 request method.

•Transaction 定義為 “從 Request 到收到一個不是 1xx 的 response, 間所有的訊息往來”.•在同一個 dialog 內, 在同一個 transaction 中的所有 request / final response 都使用相同的 CSeq，下一個transaction (for new request) 時，CSeq就要再加1，以用於區分不同的 request/response。但 ACK 與 Cancel 是例外, 要與之前的 request 有相同 CSeq號碼. 雖然 ACK/Cancel 已經是另一個 transaction. CSeq的初始值通常為前 31 bits of 32-bits clock, 以避免 overflow (warp around).

•Contact 用來說明若打給 “Call-ID”的電話, 都要接到 Contact 後所附的位址, 這才是真正的電話參與者.•Expires 為 32-bit unsigned的數字. 這裡為 7200 (單位為 sec) 表示 Collins 認為這次註冊的有效期限為 2 hours. Registrar 會回應一個比較小的數字 (3600 sec), 代表真正的有效期限.

•最大的數字可到 136 年.•如果 request 中的 Expire 數字太小, Registrar 可能會回應一個 status code 423 Interval too brief, 並告訴 client 自己能接受的最小的 registration interval.

•Content-Length 是用來指出 payload 的大小是多少。如果 SIP message 沒有帶 SDP 或其它的 content，就設成 0。•如果 Collins 離開到別處, 在另一個位址進行註冊前, Collins 可以先取消第一次的註冊 (也可以不要取消, 同時存在多個 record)

•若要取消特定某一 Call-ID, 其方式是送出與註冊時一模一樣的 REGISTER request, 但在 Expires 中填入 0, CS seq要加 1. •若要取消所有在 Registrar 的註冊, 則送出一個新的 REGISTER request, 但在 Expires 中填入 0, Contact 填入wildcard character *.

35

Invitation

A two-party callSubject:

optional

Content-Type:application/sdp

Transaction: Command Sequence

A dialog IDTo identify a peer-to-peer relationship between two user agentsTag in FromTag in ToCall-ID

Boss<sip:Manager@station2.work.com>Daniel<sip:Collins@work.com>

INVITE sip:manager@station2.work.com SIP/2.0Via: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123Max-Forwards: 70From: Daniel<sip:Collins@work.com>; tag=44551Contact: sip:Collins@station1.work.comTo: Boss<sip:Manager@station2.work.com>Call-ID: 123456@station1.work.comCSeq: 1 INVITESubject: VacationContent-Length: xxxContent-Type: application/sdpContent-Disposition: session(message body)

a

bSIP/2.0 180 RingingVia:SIP/2.0/UDP station1.work.com;branch= z9hG4bK123From: Daniel<sip:Collins@work.com>; tag=44551To: Boss<sip:Manager@station2.work.com>; tag=11222Contact: sip:manager@station2.work.comCall-ID: 123456@station1.work.comCSeq: 1 INVITEContent-Length: 0

cSIP/2.0 200 OKVia: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123From: Daniel<sip:Collins@work.com>; tag=44551To: Boss<sip:Manager@station2.work.com>; tag=11222Contact: sip:manager@station2.work.comCall-ID: 123456@station1.work.comCSeq: 1 INVITESubject: VacationContent-Length: xxxContent-Type: application/sdpContent-Disposition: session(message body)

dACK sip:manager@station2.work.com SIP/2.0Via:SIP/2.0/UDP station1.work.com;branch= z9hG4bK123Max-Forwards: 70From: Daniel<sip:Collins@work.com>; tag=44551To: Boss<sip:Manager@station2.work.com>; tag=11222Call-ID: 123456@station1.work.comCSeq: 1 ACKContent-Length: 0

Conversation

•Collins (自稱為 Daniel) 要建立一通 two-party 的電話, 打給 Manager (Boss). 兩人都在同一個 LAN 中. •觀察 INVITE sip:manager@station2.work.com SIP/2.0.由於此例中, 電話沒有經過任何的 proxy, INVITE 直接送到 station2.work.com, 所以和 To: header 有相同的 URI. 但通常很少有 caller 可以確切知道 callee所在的機器位址.

•Max-Forwards: 70 (預設值) 表示最多可經 70 proxy 轉送. 每經一個 proxy 此值就會被減 1. •From: header 除了指出 URI 外, 還帶有 display name. 表示當以振鈴呼叫使用者時, 螢幕會出現Daniel 來電, 呼叫 Boss, 而不是彼此的 URI.•Subject: 指出此電話的主旨.•Contact: 指出 Daniel 真正的位址在 Collins@stations1.work.com.•Context-Type: 指出 message body 是以 SDP 格式封裝. Context-Disposition 指出 message body 是session 的相關資訊. Context-length 指出 message body 的長度. message body 放置的是 caller 希望的 media 格式.

•觀察 SIP/2.0 180 Ringing.表示已處理到以振鈴呼叫使用者, 先送回一個暫時性的回覆. response 中大部份的內容都是從 request 中複製過來, 除了 Content-length=0 表示沒有 message body, 當然也不會有 Context-type: header.

•To: header 後面由 callee加入了 tag 參數 (只有此 address 的擁有者才能給予 tag). 事實上, From 的tag, To 的 tag, 與 Call-ID 組成一個 dialog ID, 表示這兩個使用者間 peer-to-peer 的 dialog (會談)關係. 之後所有的訊息上的 From, To 都要帶著 tag, 直到 dialog 結束. •Note: session 並未建立, 但是送回 180 ring 就表示 dialog 已經開始了. 此時 dialog 的狀態稱為 early. 若送回 200 OK, dialog 的狀態則變為 confirmed.

•當使用者 Boss 接起電筒, 表示 Invite 成功, 因此送回 SIP/2.0 200 OK. response 中大部份的內容都是從 request 中複製過來, 除了 message body 放置的是 called 希望的 media 格式. 結束 INVITE 開啟的 transaction (交易).

•主叫端送回 ACK, 表示有收到 response. 注意 CSeq: header 改成 1 ACK, 用以表示這是一個新的 request.•之後就可以開始交談了.

36

36

Termination of a Call

Boss<sip:Manager@station2.work.com>Daniel<sip:Collins@work.com>

BYE sip:manager@work.com SIP/2.0Via: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123Max-Forwards: 70From: Daniel<sip:Collins@work.com>; tag=44551To: Boss<sip:Manager@station2.work.com>; tag=11222Call-ID: 123456@station1.work.comCSeq: 2 BYEContent-Length: 0

a

bSIP/2.0 200 OKVia: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123From: Daniel<sip:Collins@work.com>; tag=44551To: Boss<sip:Manager@station2.work.com>; tag=11222Call-ID: 123456@station1.work.comCSeq: 2 BYEContent-Length: 0

•任何一方都可送出 BYE 這個 request 結束 session. 接收端要立即終止傳送 media 給對方.•BYE 中的 header 與 INVITE 的一樣, 只有 CSeq反應出這是一個 BYE 的request.•接收端送回 200 OK.

37

Redirect and Proxy Servers

• Redirect Servers

• Proxy Servers

•以下的範例說明要經過 proxy 處理的狀況.

38

Redirect Servers

An alternative address

302 Moved temporarily

Another INVITESame Call-IDCSeq ++

INVITE sip:manager@pc1.home.net SIP/2.0Via: SIP/2.0/UDP station1.work.com; branch=z9hG4bK124Max-Forwards: 70From: Daniel<sip:Collins@work.com>; tag=44551Contact: sip:Collins@station1.work.comTo: Boss<sip:Manager@work.com>Call-ID: 123456@station1.work.comCSeq: 2 INVITESubject: VacationContent-Length: xxxContent-Type: application/sdpContent-Disposition: session(message body)

c

d

ACK sip:manager@work.com SIP/2.0Via: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123Max-Forwards: 70From: Daniel<sip:Collins@work.com>; tag=44551To: Boss<sip:Manager@work.com>Call-ID: 123456@station1.work.comCSeq: 1 ACK

Boss<sip:Manager@pc1.home.net>Daniel<sip:Collins@work.com>

INVITE sip:manager@work.com SIP/2.0Via: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123Max-Forwards: 70From: Daniel<sip:Collins@work.com>; tag=44551Contact: sip:Collins@station1.work.comTo: Boss<sip:Manager@work.com>Call-ID: 123456@station1.work.comCSeq: 1 INVITESubject: VacationContent-Length: xxxContent-Type: application/sdpContent-Disposition: session(message body)

a

bSIP/2.0 302 Moved TemporarilyVia:SIP/2.0/UDP station1.work.com;branch=z9hG4bK123From: Daniel<sip:Collins@work.com>; tag=44551To: Boss<sip:Manager@work.com>; tag=11222Call-ID: 123456@station1.work.comCSeq: 1 INVITEContact: sip:Manager@pc1.home.net

Redirect Server

•Redirect server 主要的功能就是對應使用者名稱到現在所在的網路位址, 可以對應到 1 或多個網路位址。當 UAC 詢問 callee的網路位址，redirect server 會透過一個 302 response 告知 UAC callee的新位置。但如果redirect server 無法處理這個 URI, 就會送回 4xx, 5xx, 6xx 的 Error. •如果 redirect server 收到 CANCEL 訊息, 便會回傳 200 OK.•Daniel 要建立一通 two-party 的電話, 打給 Boss. 此時 Boss 離開辦公室, 以 Manager@pc1.home.net 的位址註冊. 由於不知道對方真正的位置, 所以Daniel 將 INVITE 送到 redirect server. •觀察 INVITE sip:manager@work.com SIP/2.0.和 Fig 5-9 的 INVITE 不同. 這是因為不知道對方真正的位置, 所以 Request-URI 與 To: header 中並沒有指出 Boss 的真正的所在地, 而用 Address of record 來表示.•redirect server 會送回一個 302 response, 用 Contact: header 告知 UAC callee的新位置。•Step c 中 Daniel 送回 ACK, 結束這次 transaction.•Step c 中 Daniel 送出 INVITE 到 manager@pc1.home.net, 值得注意的是CSeq已經加 1, Call-ID 沒有改變 (因為是同一通電話).

39

39

Proxy Servers

Sits between a user-agent client and the far-end user-agent serverNumerous proxies can reside in a chain between the caller and callee.The proxy may change the Request-URI.Via: header

The path taken by a requestLoop detected, 482 (status code)For a response

The 1st Via: header, Checked, RemovedBranch: used to distinguish between multiple responses to the same request/ to detect loop

p4p3p2p1callerINVITE

482

ACK

•Proxy server 的角色和 web service 中的 proxy 很像，主要就是負責處理及轉送 request 與 response 到正確的地方。最常見的狀況, 就是在 caller 與 callee間, 會經過一個 caller 的 proxy, 與一個 callee的 proxy.•如果 proxy 知道 callee真正的位置, 就會修改 Request-URI, (它將是最後一個 proxy), 且將 INVITE 轉送給 callee.•從 caller 送到 callee這 path 間所有 machines 都會把自己加入 Via (加在最上方).•Via 中會指出所使用的 transport protocol.•Via 的其中一個用途在於發現 loop. 對於同一個一模一樣的 request, 若proxy 發現自己已經在 via 中, 表示出現 a loop. 這時會送回 482 loop detected. 如圖, proxy 2 發現有 loop, 就由 via 原路徑送回 482. 最後 caller 再送回 ACK (by SIP-URI), proxy 清除自己的 state 記錄.•Callee送回 Response 時, 會依據 Via 的順序, 送給下一個 proxy, 並把自己移除.•Via 後的 Branch 請見下一頁.

40

40

Forking Proxy

Forking Proxy: Issue a single request to multiple destinations

A user is registered at several locations“fork” requests

Branch: used to distinguish between multiple responses to the same request

Ex: on Via: header ;branch=z9hG4bK123

In order to handle such forking, a proxy must be stateful.

•在RFC 2543, 一個 SIP request 可能會被 forking proxy 做 multicast 給許多目的地 (有點像 branch, 也很像是 fork 許多 request). 為了區別來自這些目的地的 response, 所以用不同的 branch 號碼表示. branch 是 optional, 在一個 transaction 中也不是只有一個獨一無二的 branch 號碼.

•forking proxy 這樣會 fork request 給許多目的地的 proxy 稱為forking proxy, 必需是 stateful才有意義, 可對來自各目的地回收的response 做進一步的處理. •這些被 branched request, 必須給予不同的 branch number (ex: step c 的 z9hG4bK123 與 step d 的 z9hG4bK456), 以資分辨.

•在 RFC 3261, branch ID 用做 transaction ID, 用於檢查是否有 loop. branch 的開頭為 z9hG4bK, 這數字被稱為 magic cookie, 表示這個 branch 是用於 RFC 3261 的定義. (因為 z9hG4bK 從未用於 RFC 2543)•每一個 client, 對每一個 transaction, 都要創造出獨一無二的 branch. 唯一的例外是對於不是 2xx response 而產生的 ACK, CANCEL, 要用與 original request 相同的 branch. (和 CSeq有點像)

41

41

Proxy State

Transaction statelessProxy server forwards all methods and responses without interaction

Transaction statefulMaintains state for the transaction until the final response is receivedTransaction Control Block (TCB)

•Proxy 分成兩類: stateless 與 stateful.•一個 stateless proxy, 處理訊息後就忘記了, 所以當發生 loop 時, 它就像上一次一樣被轉送到下一站.•一個 stateful proxy, 處理訊息後, 仍會記得原來的 incoming request, 與自己轉送到下一站的 outgoing request. 所以 proxy 就可以用比較聰明的方式處理 loop.

•當 Proxy server 收到一個新的 method, 就會開啟一個Transaction Control Block (TCB), 維護 transaction 所有資料, 直到收到 final response.•通常一個 stateful的 proxy server, 會產生 CANCEL method 或 acknowledgement (ex: 100 Trying 是給前一站, 表示正在運作. 另外在 INVITE 的過程中, 不知 callee在那一個地方, 所以 proxy 會 fork INVITE response 給許多目的地, 但只有一個會建立連線, 其他的都必須由此 proxy 送出 CANCEL 停止transaction).

42

42

Record-Route: and Route:

Record-Route:Use Contact: → the messages may not pass through the same proxyA stateful proxy might require that it remains in the signaling pathInsert its address into the Record-Route: headerThe response includes the Record-Route: headerThe information contained in the Record-Route: header is used in the subsequent requests related to the same call.

The Route: header = the Record-Route: header in reverse order

•對於一個 stateful proxy, 會希望永遠在 signaling path 上, 如此才有辦法處理一些特殊的服務.•利用 request 中的 via, (第一筆) response 可以經由原路回到 originator. 但事實上, 由於 Contact: header 的存在, 兩端點在接下來的訊息中, 便可直接送到對方, 而不用經過 proxy. 但是如果 (stateful) proxy 希望仍能在路徑上, 以便做一些特殊的服務, 就要用 Record-Route: header 把自己記下來.

•路過的每一個 Proxy 會把自己記錄成 Record-Route:, 並列在之前所有Record-Route: headers 的前面.•Record-Route: 會複製於 (steps d, e) Response 中, 送給 originator. 接下來所有的 requests 都要照這個順序傳送.•接下來 Originator 會把 Record-Route: 的 list of proxy 以相反的順序複製於下一筆 request (step f) 的 Route: header. 這時送出的路徑就會強迫經過在 Route: list 上的第一個 proxy (而不是送到 Request URI).•每經過一個 proxy, 就會移去 Route: list 上, 自己的位址. 當 list 是空的, 最後的目的地即為 Request-URI.•以上的過程稱為 loose routing (lr). 在 Record-routing: 中會加入 lr參數表示是 loose routing. 改版的原因可能是因為不希望 proxy 會更動到太多 message 的內容, 特別是 Request-URI 這樣重要的部份.

•舊版 (RFC 2543) 的 SIP 的 record-route 被稱為 strict routing. 不同處在於當時的做法是要把真正的目的地會列在 Route: 的最後一個, 而把第一個 Record 的 proxy (i.e., 下一站的 proxy 的位址) 放在 Request-URI. 因此每一個 proxy 都會更動 SIP 訊息的 Request-URI.•只支援 strict routing 的 proxy 可能不瞭解新的 loose routing 的作法, 所以會更動 SIP 訊息的 Request-URI.

43

43

Strict Routing and Loose Routing

INVITE: U1->P1->P2->P3->P4->U2

BYE: U2->P4->P3->P2->P1->U1

INVITE sip:callee@u2.domain.comSIP/2.0

Contact: sip:caller@u1.example.com

Record-Route: <sip:p4.domain.com;lr>

Record-Route: <sip:p3.middle.com>

Record-Route: <sip:p2.example.com;lr>

Record-Route: <sip:p1.example.com;lr>

BYE sip:caller@u1.example.comSIP/2.0

Route: <sip:p4.domain.com;lr>

Route: <sip:p3.middle.com>

Route: <sip:p2.example.com;lr>

Route: <sip:p1.example.com;lr>

BYE sip:p3.middle.com SIP/2.0

Route: <sip:p2.example.com;lr>

Route: <sip:p1.example.com;lr>

Route: <sip:caller@u1.example.com>

BYE sip:p2.example.com;lrSIP/2.0

Route: <sip:p1.example.com;lr>

Route: <sip:caller@u1.example.com>

BYE sip:sip:caller@u1.example.com>

Route: <sip:p1.example.com;lr>

BYE sip:sip:caller@u1.example.com>

•U1 送出 INVITE 給 U2, 其中 P3 是 strict router, 其他 proxy 是採用 loose routing.•在 U2 送回 BYE 給 U1 的過程中, 遇到 P3 時, 要將 Request-URI 改成 P3 的 URI, 並把 U1 的 URI 加入最後一行 Route.•P4 發現自己是第一個Route: 中的proxy, 因此移去最上面的自己, 而且P4 準備將BYE 送到P3. 但由於SIP 中沒有lr, 所以將BYE 的Request-URI 改成P3, 並把caller 放到Route: 的最後面.

•P3 是strict router, 他接著把BYE 轉到P2. 這個原因可能是因為P3 是舊的機器, 只支援strict routing (RFC 2543), 因此P3 仍會把Request-URI 改成P2.

•P2 看到BYE 的Request-URI 是自己寫入Record-Route: 的值, 因此改寫Request-URI 變回caller. 且把caller 從Route: 中移除.

44

44

Boss<sip:Manager@pc1.home.net> Daniel<sip:Collins@station1.work.com>

INVITE sip:Collins@work.com SIP/2.0Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890Max-Forwards: 70From: Boss<sip:Manager@home.net>; tag=ab12Contact: Boss<sip:manager@pc1.home.net>To: Daniel<sip:Collins@work.com>Call-ID: 123456@pc1.home.netCSeq: 1 INVITE

a

b

SIP/2.0 100 TryingVia: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890From: Boss<sip:Manager@home.net>; tag=ab12To: Daniel<sip:Collins@work.com>Call-ID: 123456@pc1.home.netCSeq: 1 INVITE

c

sip:Server.work.com

INVITE sip:Collins@station1.work.com SIP/2.0Via: SIP/2.0/UDP server.work.com; branch=z9hG4bKxyz1Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890Max-Forwards: 69Record-route: <sip:server.work.com;lr>From: Boss<sip:Manager@home.net>; tag=ab12Contact: Boss<sip:manager@pc1.work.com>To: Daniel<sip:Collins@work.com>Call-ID: 123456@pc1.home.netCSeq: 1 INVITE

SIP/2.0 200 OKVia: SIP/2.0/UDP server.work.com; branch=z9hG4bKxyz1Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890Record-route: <sip:server.work.com;lr>From: Boss<sip:Manager@home.net>; tag=ab12To: Daniel<sip:Collins@work.com>; tag=xyz45Call-ID: 123456@pc1.home.netCSeq: 1 INVITEContact: sip:Collins@station1.work.com

SIP/2.0 200 OK...

e

d

Through a Proxy (1/2)

•假設 Daniel 在家而 Boss 在公司. Boss 要打電話給 Daniel. •Proxy 收到 INVITE, 如果 proxy 本身也是 registrar, 知道 Daniel 的位置, 就會修改 Request-URI, 且將 INVITE 轉送到正確位置. 因此在 Step b 中, INVITE 後的位址被改成 Collins@station1.wor.com, Max-Forward: 減一, 加入 proxy 位址的 Via (在之前 proxy/client 的 Via 之上)•如果 proxy 並不是 registrar, 則 proxy 會將 URI 送到 location function, 決定下一站的位址. 此時 proxy 不會改變 INVITE 後的 URI, 只有最後一個知道Daniel 位置的 proxy, 才會修改它. 這 path 間所有 proxy 都會加入 Via.

•如果對於同一個一模一樣的 request, proxy 發現自己已經在 via 中, 表示出現 a loop. 這時會送回 482 loop detected. •如果, proxy 發現自己已經在 via 中, 但 request 已被修改過, 可能會遇到不同的處理方式, 這時 proxy 仍需轉送此封包.

•Step c: proxy 送回 100 Trying的 response, •Step d: Daniel 送回 200 OK. 在這個 message 中, 一開始會包括 path 上所有的 via. 當 proxy 收到 response, 第一個 via 應該是自己. 如果不是則丟棄此封包. 如果是則把自己的 via 移除, 將下一個 via 視為 next hop, 將封包轉送給它. 如果沒有 next hop, 表示自己是這個封包的目的地.

•Record-route 請參考 proxy state.•Note: Subject: 與 message-body 在流程中被省略.

45

45

Boss<sip:Manager@pc1.home.net> Daniel<sip:Collins@station1.work.com>

ACK sip:Collins@station1.work.com SIP/2.0Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7891Max-Forwards: 70Route: <sip:server.work.com;lr>From: Boss<sip:Manager@home.net>; tag=ab12To: Daniel<sip:Collins@work.com>; tag=xyz45Call-ID: 123456@pc1.home.netCSeq: 1 ACK

e

f

sip:Server.work.com

ACK sip:Collins@station1.work.com SIP/2.0Via: SIP/2.0/UDP server.work.com; branch=z9hG4bKxyz2Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7891Max-Forwards: 69From: Boss<sip:Manager@home.net>; tag=ab12To: Daniel<sip:Collins@work.com>; tag=xyz45Call-ID: 123456@pc1.home.netCSeq: 1 ACK

SIP/2.0 200 OKVia: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890Record-route: <sip:server.work.com;lr>From: Boss<sip:Manager@home.net>; tag=ab12To: Daniel<sip:Collins@work.com>; tag=xyz45Call-ID: 123456@pc1.home.netCSeq: 1 INVITEContact: sip:Collins@station1.work.com

g

Through a Proxy (2/2)

46

46

Boss<sip:Manager@pc1.home.net> pc1

INVITE sip:Collins@work.com SIP/2.0Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK789Max-Forwards: 70From: Boss<sip:Manager@home.net>; tag=ab12Contact: Boss<sip:manager@pc1.home.net>To: Daniel<sip:Collins@work.com>Call-ID: 123456@pc1.home.netCSeq: 1 INVITE

a

bSIP/2.0 100 TryingVia: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK789From: Boss<sip:Manager@home.net>; tag=ab12To: Daniel<sip:Collins@work.com>Call-ID: 123456@pc1.home.netCSeq: 1 INVITE

c

sip:Server.work.com

INVITE sip:Collins@pc1.work.com SIP/2.0Via: SIP/2.0/UDP server.work.com; branch=z9hG4bK123Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK789Max-Forwards: 69Record-coute: <sip:server.work.com;lr>From: Boss<sip:Manager@home.net>; tag=ab12Contact: Boss<sip:manager@pc1.work.com>To: Daniel<sip:Collins@work.com>Call-ID: 123456@pc1.home.netCSeq: 1 INVITE

dINVITE sip:Collins@pc2.work.com SIP/2.0Via: SIP/2.0/UDP server.work.com; branch=z9hG4bK456Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK789Max-Forwards: 69Record-coute: <sip:server.work.com;lr>From: Boss<sip:Manager@home.net>; tag=ab12Contact: Boss<sip:manager@pc1.work.com>To: Daniel<sip:Collins@work.com>Call-ID: 123456@pc1.home.netCSeq: 1 INVITE

pc2

Multiple Locations (1/2)

•在這個例子中, Boss 要打電話給 Daniel. 然而 Daniel 在兩個電腦 pc1, pc2 都向 server 有註冊. 因此 proxy 會將 INVITE 複製成兩份, 分別在 step c, d 送給 pc1, pc2. 這兩個訊息不同處在於必須給予不同的 branch number (ex: step c 的 z9hG4bK123 與 step d 的 z9hG4bK456), 以資分辨.

47

47

Boss<sip:Manager@pc1.home.net> pc1

e

fg

sip:Server.work.com

CANCEL sip:Collins@pc1.work.com SIP/2.0Via: SIP/2.0/UDP server.work.com; branch=z9hG4bK456Max-Forwards: 69Record-coute: <sip:server.work.com;lr>From: Boss<sip:Manager@home.net>; tag=ab12Contact: Boss<sip:manager@pc1.work.com>To: Daniel<sip:Collins@work.com>Call-ID: 123456@pc1.home.netCSeq: 1 CANCEL

SIP/2.0 200 OKVia: SIP/2.0/UDP server.work.com; branch=z9hG4bK456Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK789Record-coute: <sip:server.work.com;lr>From: Boss<sip:Manager@home.net>; tag=ab12To: Daniel<sip:Collins@work.com>; tag=xyz45Call-ID: 123456@pc1.home.netCSeq: 1 INVITEContact: sip:Collins@pc2.work.com

pc2

SIP/2.0 200 OKVia: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK789Record-coute: <sip:server.work.com;lr>From: Boss<sip:Manager@home.net>; tag=ab12To: Daniel<sip:Collins@work.com>; tag=xyz45Call-ID: 123456@pc1.home.netCSeq: 1 INVITEContact: sip:Collins@pc2.work.com

Multiple Locations (2/2)

•先送回 Response 的 pc2, proxy 會將其轉送回 Boss.•對於 pc1, proxy 會送 CANCEL 訊息給 pc1. Note: CANCEL 一定是 hop by hop 傳送, 不經過 proxy, 所以 Via: 只會有 originator 自己.•pc1 會送回 487 request cancelled 給 proxy.•Note: Subject: 在流程中被省略.

48

Session Description Protocol (SDP)

• Introduction to SIP

• SIP Network Entities

• Simple Example

49

49

The Session Description Protocol

The Most Common Message BodyBe session information describing the media to be exchanged between the partiesSDP, RFC 2327 (initial publication)

SDP simply provides a format for describing session information to potential session participants.RFC 3264 (An Offer/Answer Model with SDP)

SIP uses SDP in an answer/offer mode.An agreement between the two parties as to the types of media they are willing to share

•VoIP 的 SIP 的 message-body 大部份是使用 SDP。•SDP 提供描述 session 特性的格式, 電話兩方協調的方式. 最初的版本為RFC 2327.•然而 SDP 並沒有提及如何將這些 session 的描述在電話雙方間傳送, 因此必須與其他協定 (ex: SIP) 相結合.

•Note: 一個 SIP 中只能有一個 SDP 訊息. •RFC 3264, 標題為 An Offer/Answer Model with SDP, 則是描寫 SIP 與SDP 間如何相互運作.•SDP 的做法是用 answer/offer 的方式，是讓兩方達成一個協定的方式。像是在決定 codec 的時候，兩邊會在 SDP 中告訴對方自己可以使用的 codec 有什麼，再選擇出一個兩邊都可以使用的 codec。

•要送出 media 的一端, 提出 offer. 另外一端以 answer 回應.

50

50

The Structure of SDP

Text-based ProtocolThe Structure of SDP

Session Level InformationName of the sessionOriginator of the sessionTime that the session is to be active

Media Level InformationMedia typePort numberTransport protocolMedia format

Originator and Session IDProtocol Version

Session NameSession Time

Media Name and TransportConnection Information

Media Name and TransportConnection Information

Session Description

Session Level Information

Media Description 1

Media Description 2

•SDP 也是一個純文字的協定, 使用 ISO 10646 character set. 雖然SDP的名稱欄位 (session name) 都要使用ASCII, 但 SDP 內容是可以用任何的語言撰寫.

•為了節省頻寬, 也使用許多的縮寫, 如用 v 代表 version.•這裡介紹的是專為 offer/answer model 設計的 SDP 訊息, 只能處理一個 session.

•RFC 2327 SDP 協定中是允許有 multiple session description.•一個 SDP 訊息 (Session description) 分成 session level information 與 media level information.•Session level information 描述 session 本身的相關資料, 如 protocol version, session 的起始者 (originator), session ID, session name, session 開始啟動的時間 (session time).•其他的部份為 media-level information. 由於一個 session 內可能會建立 0 或許多 media stream, 所以每個session stream 都會有一個相對應的 media description. 每一筆 media description 包括 media name, media type, media format, transport protocol, port number 等field資訊.

•如果一開始 offer 中沒有 media description, 表示在之後的 modified offer 才要建立 media stream.•media type 指 audio, video 等項目.•port number 指自己接收或傳送所使用的 port.•transport protocol 指 RTP/AVP. AVP: audio/video profile.•media format 指 G.711, G.726 等 RTP payload type.

51

51

SDP Syntax

A number of lines of textIn each line

field=valueEx: v=0field=<value of subfield1> <value of subfield2> <value of subfield3> ...Ex: m=audio 45678 RTP/AVP 0field is exactly one character (case-significant)

Session-level fields Begin with version description field (v=)

Media-level fieldsBegin with media description field (m=)

•SDP 由許多行的文字說明所組成. •每一行就是一項欄位的文字說明 (description field). 格式為 field=value. field 表示一項特徵, value 表示 endpoint 對這項特徵給的設定值. •為節省頻寬, 也為比較容易解析, 文字說明要注意以下事項. field 都是以第一個英文字母來表示; 等號兩端不可以有空白; value 若是許多項目 (subfield) 的組合, 中間以一個 space 來表示.

•m 為 media 的縮寫. v 為 version 的縮寫.•Ex: m=audio 45678 RTP/AVP 0 是在描述 media type, port number, protocol, media format.•這些 field 可能包含許多小項目, 稱為 subfield. 換句話說, value 是包含許多描述 subfield 設定值的組合. Subfield 必須按照一定的順序排列.

•Session-level information 放在前面, 以 v=... 為開始, 之後跟著許多session-level fields 所組成; 再來是 media-level information. media-level information 可以有許多 media streams 的描述. 每一筆 media description 都是以 m=... 為開始, 跟著許多相關的 session-level fields 所組成.

52

52

Mandatory Fields (1/3)

v, o, s, t, m are mandatory fields.v=(protocol version) (ex: “v=0”)s=(session name) (ex: “s= ”)

A text string for multicast conference

t=(time of the session) (ex: “t=0 0”)The start time and stop time for pre-arranged multicast conference

•v, o, s, t, m 這五項些是 session-level information 中必要的 fields:•v 是 protocol 的版本.•s 是 session 的名稱, 是一個文字字串, 用於 multicast conference. 但對於 SIP 這樣只建立起兩人會談, 名稱就沒有意義, 這時 session name 就設成一個 space (=0x20), 像”s= “或 dash ”s=-“.•t 用於 pre-arranged multicast conference, 先設定好一個固定的session 的起始與結束的時間. 但對於 SIP 這樣在任何時間都可以開始或結束會談, SIP 本身就會處理 session 的起始與結束, time 就沒有意義, 這時 time 就設成 ”t=0 0 “.

53

53

Mandatory Fields (2/3)

o=(session origin or creator)Ex: o=collins 123456 001 IN IP4 s1.yy.comUsername (ex: collins): the originator’s login id or “-”Session ID (ex: 123456)

Make use of NTP timestamp as a unique ID

Version (ex: 001)Network type (ex: IN)

IN refers to Internet

Address type (ex: IP4)IP4, IP6

address (ex: s1.yy.com)A fully-qualified domain name or the IP address

•o 是 session 的起始者, 說明起始者的一些資訊. 包括 6 個 subfields.•Username 代表起始者的名稱, 是 login 到系統所使用的 ID, 如果不需 login, 就用 “-”表示.•Session ID 是這個 session 的代表號, 必需是一個獨一無二的號碼, 因此 SDP 建議使用 NTP (Network Time Protocol) timestamp 做為unique ID. •Version 是這個 session 的版本, 與每次修改的前面版本 (ex: 使用不同的 media type) 做為區隔. 但仍是同一 session, 所以會有相同的sender, Session ID 等 subfields.•Network type 是以一個文字字串說明所使用網路的特性. 如 IN 等於Internet.•Address type 說明所使用網路位址架構, 如 IP4 是 IPv4 addressing, IP6 是 IPv6 addressing.•Address 是要傳送 media 的機器的 network address, 如 s1.yy.com 這台機器)

54

54

Mandatory Fields (3/3)

m=(media) Ex: m=audio 45678 RTP/AVP 15 3 0Media type (ex: audio)

Audio, video, application, data, control

The transport port (ex: 45678)The transport protocol (ex: RTP/AVP)The media format, an RTP payload format (ex: 15 3 0)

List the various types of media format that can be supported

•只有 m (media) 是 media-level information 中必要的 fields:•m 代表 media 的特性, 包括使用的 media type, transport port, transport protocol, media format.•Media type 可以是 audio (一般的語音), video, application, data, control.•Transport port 是media stream 目的地的 port 號碼. port 是依據connection 的型態與傳送的協定來決定. 在 VoIP 通常使用 UDP 傳送 RTP, 所以 port 為 1024 到 65535 間的號碼.•Transport protocol 表示包裝 media 的協定. 如 RTP/AVP 代表只用於語音的 RTP. •Media format 是列出所有可以處理的 media format, 越喜歡的列在前面. 若是 transport protocol 是 RTP, 則 media format 就是許多的RTP payload type. 此例中最希望收到 G.728=15, 再來是 GSM=3, G.711/u-law=0.

55

55

Optional Fields (1/4)

Some optional fields can be applied at both session and media levels.The value applied at the media level overrides that at the session level for that media instance.c=(connection data) (ex: c=IN IP4 s1.yy.com)

The network and address at which media data will be receivedNetwork type (ex: IN)Address type (ex: IP4)Connection address (ex: s1.yy.com)At session or media level

•Note: 有時 session-level 與 media-level information 會設定許多相同的fields. 此時, 針對這個 media stream, 會以 media description 中的設定為主. 其它 media stream 則採用 session-level information 中的設定. •以下介紹各個 optional fields:

•c 代表這條 connection 目的地的相關資料,包括接收此 media 的網路特性與位址

•Network type 說明所使用網路的特性. 如 IN 等於 Internet.•Address type (ex: 架在 IPv4 的網路上)•Connection address (所要傳送 media 的 network address, 例如送到 s1.yy.com 這台機器

•雖然也可以寫像 140.138.137.224 這樣的 IP address, 但建議使用 full qualified domain name, 會比較有彈性.

•c 可放在 session-level 或 media-level information 其中之一.

56

56

Optional Fields (2/4)

a=(attributes) (ex: a=sendonly)Describe additional attributesProperty attribute

Ex: a=sendonly / a=recvonly

Value attributeUsed in a shared whiteboard sessionEx: a=orient:portrait / a=orient:landscapertpmap provides additional information for dynamic payload type.Ex: m=video 54678 RTP/AVP 98

a=rtpmap:98 L16/16000/2Dynamic RTP payload type=9816-bit linear encoded stereo (2 channels) audio sampled at 16kHz

•a 用來補充描述這個 session-level 或 media-level 的特性. (ex: 說明 send only)•一個 SDP 訊息中可以有許多 attributes, 可放在 session-level 和 media-level information.•Attributes 有兩種格式:•1. property attribute: 用以表示其性質

•Ex: a=sendonly表示 send only. 送出這個 SDP 的 sender 只願意送出 media stream, 不願意接收 media stream. 對於 RTP 的使用者, 雖然 sender 不接受 RTP 封包, 但仍會接受 RTCP 封包.•Ex: a=reconly則是 receive only.

•2. value attribute: 用以表示其數值•Ex: 若用於一個共用的 whiteboard session, 則可用 attribute 設定圖案是 portrait (直立) 或 landscape (橫擺).•當 media stream 並使用 dynamic RTP payload type, 則必須提供更多的資訊給對方, 此時可以用 rtpmap這個格式: a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding parameters>]

•encodling name 必須是一個註冊的名稱.•Ex: m=video 54678 RTP/AVP 98

a=rtpmap:98 L16/16000/2•表示想使用 dynamic RTP/AVP payload type=98, 其特性為 16-bit linear encoded stereo (2 channels) audio sampled at 16kHz. •雖然 rtpmap是為 dynamic RTP payload type 所設計的, 但 SDP 建議即使使用 static RTP payload type, 最好也加入 rtpmap.

57

57

Optional Fields (2/4)

i=(session information)A text descriptionAt both session and media levelsIt would be somewhat superfluous, since SIP already supports the Subject header.

u=(URI of description)Where further session information can be obtainedOnly at session level

e=(e-mail address)Who is responsible for the sessionOnly at the session level

•以下這些是 optional fields:•i 代表這個 session 的資訊, 以純文字描述 topic(主題), 以獲得更多 session 的相關資訊.

•information 可放在 session-level 和 media-level information.•如果與 SIP 合用, 既然 SIP 中已有 Subject header, 這個information 欄位就顯得多餘了.

•u 代表 URI, 表示在這個Web site, 可以獲得更多 session 的相關資訊. 通常是 pre-arranged conference 才會用到. 因為 SIP 都是有需求時才建立連線, 這個欄位通常不會使用.

•放在 session-level, 且一個 session, 只能有一個 URI. •e 代表負責這個 session 的管理者的 email address.

•放在 session-level.•若有許多負責人, 就可以有多個 email 欄位, 可以讓大家以 email 來溝通.

58

58

Optional Fields (3/4)

p=(phone number)Only at the session level

b=(bandwidth information)In kilobits per secondAt session or media level

r=(repeat times)For regularly scheduled session a session is to be repeatedHow often and how many times

•以下這些是 optional fields:•p 代表負責這個 session 的管理者的電話號碼.

•放在 session-level.•若有許多負責人, 就可以有多個電話號碼, 可以讓大家溝通. •這個欄位通常不會使用.

•b 代表這個 session 的資訊所需要的頻寬, 其單位為每秒多少 kilobits.•b 可放在 session-level (for 整個 conference) 和 media-level (for 這個 media stream).

•對於一個定期會召開的 regularly scheduled session, r 代表這個 session 的會多久或召開多少次.

•對於 SIP, 這個 r 欄位就顯得多餘.

59

59

Optional Fields (4/4)

z=(timezone adjustments)For regularly scheduled sessionStandard time and daylight savings time

k=(encryption key)An encryption key or a mechanism to obtain it for the purposes of encrypting and decrypting the mediaAt session or media level

•以下這些是 optional fields:•對於一個定期會召開的 regularly scheduled session, z 代表這個時區調整的資訊.

•由於有些地方, 有時候會使用日光節約時間 (daylight savings time), z 欄位就可在此狀況下提供時間的訊息.•對於 SIP, 這個z 欄位就顯得多餘.

•k 是對 media stream 做加解密所採用的秘密鑰匙.•k 可放在 session-level 和 media-level information.

60

60

Ordering of Fields

Session LevelProtocol version (v)Origin (o)Session name (s)Session information (i)URI (u)E-mail address (e)Phone number (p)Connection info (c)Bandwidth info (b)Time description (t)Repeat info (r)Time zone adjustments (z)Encryption key (k)Attributes (a)

Media levelMedia description (m)Media info (i)Connection info (c)

Optional if specified at the session level

Bandwidth info (b)Encryption key (k)Attributes (a)

•所有的欄位要按照固定的順序排列. 這裡說明他們的順序.

61

Usage of SDP with SIP

• Simple Example

• Negotiation of Media

•SIP 提供的是

62

62

Usage of SDP with SIP

SIP and SDP make a wonderful partnership for the transmission of session information.SIP provides the messaging mechanism for the establishment of multimedia sessions.SDP provides a structured language for describing the sessions.The entity headers identifies the message body.

Ex: Content-Type:application/sdp

•SIP 提供建立 multimedia session 所需要的訊息.•SDP 提供描述 session capabilities 的結構化語言.•Question: 如何知道 SIP 中會包含 SDP 的描述? Answer: 利用 Entity header 可以指出 SIP message body 中, 所採用的型態與格式. 例如Context-Length, Context-Type, Context-Encoding, Context-Disposition.•因此結合 SIP 與 SDP 可呈現完美的組合.

63

63

Offer/Answer Model

Offer a selection of media formatsAnswer which the receiver is willing to accept

Supported media type: returned with a transport portUnsupported media type: also be returned with a port number of zero

(1) Offer

(2) Answer

Sender Receiver

•SDP 採用 offer/answer 的模式.•Sender 送出 offer, 代表它所能提出的 media format 選項.•Receiver 複製 sender 的訊息, 但標示出那些是它可以支援 (accept), 那些是不可使用 (reject) 的 format. 回傳這個 answer 給 sender.•SIP 有兩種方式來傳送 offer/answer:

•offer in INVITE, answer in 2XX (範例中所使用的方式)•offer in 2XX, answer in ACK. 這僅能在 INVITE 中沒有 offer 的情況下使用.

64

64

Daniel<sip:Collins@station1.work.com> Boss<sip:Manager@station2.work.com>

INVITE sip:Manager@station2.work.com SIP/2.0From: Daniel<sip:Collins@station1.work.com>; tag = abcd1234To: Boss<sip:Manager@station2.work.com>CSeq: 1 INVITEContent-Length: 213Content-Type: application/sdpContent-Disposition: session

v=0o=collins 123456 001 IN IP4 station1.work.coms=c=IN IP4 station1.work.comt=0 0m=audio 4444 RTP/AVP 2a=rtpmap 2 G726-32/8000m=audio 4666 RTP/AVP 4a=rtpmap 4 G723/8000m=audio 4888 RTP/AVP 15a=rtpmap 15 G728/8000

a

bSIP/2.0 200 OK …

SDP Inclusion in SIP Messages (1/2)

•在這個範例中, Collins 的電腦可同時用 G.726, G.723.2, G.728 連線. 然而Boss 的電腦只支援 G.728. 兩方進行溝通.•INVITE 的 message body 中, 會列出支援的 media format. 每一種 media format 的資訊包括

•Media information: m=audio (media type) 4444 (transport port number) RTP/AVP (支援語音的 RTP) 2 (使用 RTP payload type=2)•Attribute 進一步說明 media type 的資訊: a=rtpmap: 2 (使用 RTP payload type=2) G726-32/8000 (media name, bit rate)

•Note: Collins 為這三種不同的 media type, 各設定一個 port number, 例如用 4444 port 接收 G.726 的 media stream, 用 4666 port 接收 G.723 的media stream,代表 Collins 可以同時接收三種不同 media stream.•Note: Via: 等 headers, 180 Ring 等訊息在流程中被省略.

65

65

SIP/2.0 200 OKFrom: Daniel<sip:Collins@station1.work.com>; tag = abcd1234To: Boss<sip:Manager@station2.work.com>; tag = xyz789CSeq: 1 INVITEContent-Length: 163Content-Type: application/sdpContent-Disposition: session

v=0o=collins 45678 001 IN IP4 station2.work.coms=c=IN IP4 station2.work.comt=0 0m=audio 0 RTP/AVP 2m=audio 0 RTP/AVP 4m=audio 6666 RTP/AVP 15a=rtpmap 15 G728/8000

b

c

d

ACK sip:manager@station2.work.com SIP/2.0From: Daniel<sip:Collins@station1.work.com>; tag = abcd1234To: Boss<sip:Manager@station2.work.com>; tag = xyz789CSeq: 1 ACKContent-Length: 0

Conversation

Daniel<sip:Collins@station1.work.com> Boss<sip:Manager@station2.work.com>

SDP Inclusion in SIP Messages (2/2)

port=4888port=6666

•Step b: 回應的 200 OK 的 message body 與 INVITE 的 message body 幾乎一樣.

•不同意使用的 G.726, G.723.1 的 media type 描述中, port number 設為 0 表示 reject. 也不需用 attribute 再進行陳述.•同意使用的 G.728 的 media type 描述中, 6666 是 Boss 所開啟的port number, 用來接收 G.728 的 media stream. 後面的 attribute 再次說明其特性.

•Step c: ACK, 不需再傳送 SDP, content-length=0.•Step d: 用 RTP 包裝 G.728 語音, 開始通話.

66

66

Alternative Ways

Offerm=audio 4444 RTP/AVP 2 4 15a=rtpmap 2 G726-32/8000a=rtpmap 4 G723/8000a=rtpmap 15 G728/8000

Answerm=audio 6666 RTP/AVP 15a=rtpmap 15 G728/8000

•如果 Collins 的電腦可支援三種不同的 media type, 但只希望只其中之一, 則只要設定一個 port number, 例如用 4444 port 來接收. 此時這三種不同的media type, 就可寫在同一 m field 中: m=audio 4444 RTP/AVP 2 4 15. 在分別用 3 行 attributes 來描述各個的 media type.•對於 Boss 則只要回傳所選用的 G.728, 不可提到其他兩種.

67

67

Negotiation of Media (1/3)

Re-INVITE is issued when the server replies with more than one codec.

With the same dialog identifier (To and From tag), Call-ID and Request-URISession version in o field is increased by 1.

A mismatch488 (Not acceptable here) or 606 (Not acceptable)A Warning header with warning code

304 (media type not available) 305 (incompatible media format)

•如果兩方能支援的 media type 的交集不只一種, 這時就要進行協商. 做法是sender 決定最後使用的那一個 media type, 再傳送一次 INVITE, 此時就不再有爭議.•第二次的 INVITE (與之後所有的 messages) 會使用之前第一次 INVITE 已經建立起來的 dialog (in confirmed state). 所以要有相同的 dialog identifier, Call-ID 與 Request-URI.

•Dialog identifier = From tag + To tag + Call ID.•萬一 offer 中所有的 media types 在 receiver 端都沒有支援, 此時 receiver 便會回應錯誤的 response: 488 (Not acceptable here) 或 606 (Not acceptable). 而且 response 會包含Warning: header, 以 3 碼的 warning code 的值表示問題所在.

•Warning code=304 表 media type not available. 在這個 session 描述中有一個或多個 media types (指 audio/video/app)並未支援.•Warning code =305 表 incompatible media format.在這個 session 描述中有一個或多個 media format (指 G.711 等 codec) 並未支援.

•在這種情況下, caller 會提出新的 INVITE.

68

68

INVITE sip:manager@station2.work.com SIP/2.0CSeq: 1 INVITEContent-Length: 183Content-Type: application/sdpContent-Disposition: session

v=0o=collins 123456 001 IN IP4 station1.work.coms=c=IN IP4 station1.work.comt=0 0m=audio 4444 RTP/AVP 2 4 15a=rtpmap 2 G726-32/8000a=rtpmap 4 G723/8000a=rtpmap 15 G728/8000a=inactive

Daniel<sip:Collins@station1.work.com> Boss<sip:Manager@station2.work.com>

b

a

SIP/2.0 200 OKCSeq: 1 INVITEContent-Length: 157Content-Type: application/sdpContent-Disposition: sessionv=0o=collins 45678 001 IN IP4 station2.work.coms=c=IN IP4 station2.work.comt=0 0m=audio 6666 RTP/AVP 4 15a=rtpmap 4 G723/8000 a=rtpmap 15 G728/8000a=inactive

Negotiation of Media (2/3)

•在這個範例中, Collins 的電腦可支援 G.726, G.723.2, G.728, 然而 Boss 的電腦支援 G.723 與 G.728. •Step a: Collins 提出 offer, 他可支援 G.726, G.723.2, G.728, 但只想開啟一條 media stream, 使用 port=4444.•Step b: Boss 的 answer 指出他可支援 G.726, G.728, 使用 port=6666.

69

69

Daniel<sip:Collins@station1.work.com> Boss<sip:Manager@station2.work.com>

d

c

INVITE sip:manager@station2.work.com SIP/2.0CSeq: 2 INVITEContent-Length: 126Content-Type: application/sdpContent-Disposition: session

v=0o=collins 123456 002 IN IP4 station1.work.coms=c=IN IP4 station1.work.comt=0 0m=audio 4444 RTP/AVP 15a=rtpmap 15 G728/8000

ACK sip:manager@station2.work.com SIP/2.0From: Daniel<sip:Collins@station1.work.com>; tag = abcd1234To: Boss<sip:Manager@station2.work.com>; tag = xyz789CSeq: 1 ACKContent-Length: 0

Negotiation of Media (3/3)

•Step c: Collins 送回 ACK 表示收到 response 200 OK.•雖然 ACK 也可以放置 message body, 但我們不可以用 ACK 來修改media type.

•Step d: Collins 從兩中 media types 決定最後使用 G.728, 再送出一次INVITE.

•CSeq已經加 1.•o field 中的 session version 加 1, 而其他 subfield (如 sender, session number=123456) 都相同, 表示是同一個 session 的更新版本.

•之後的流程就與一般程序相同.

70

70

Determine the capabilities of a potential called partyAccept Header

Indicate the type of information that the sender hopes to receive

Allow HeaderIndicate the SIP methods that it can handle

Supported HeaderIndicate the SIP extensions that it can be supported

OPTIONS Method

•OPTIONS 用於詢問 called party 關於它的 capabilities. •例如, 詢問被叫端所能支援的 media type, 能處理那些 methods, 是否能接受新的 SIP extension, encoding 方式 (ex: gzip), encoding language (ex: en), content-type (ex: application/sdp),

71

71

Daniel<sip:Collins@station1.work.com> Boss<sip:Manager@station2.work.com>

b

aOPTIONS sip:manager@station2.work.com SIP/2.0Via: SIP/2.0/UDP Station1.work.com; branch=z9hG4bK7890123From: Daniel<sip:Collins@work.com>; tag=lmnop123To: Boss<sip:Manager@station2.work.com>Call-ID: 123456@station1.work.comContact: Daniel<sip:Collins@station1.work.com>CSeq: 1 OPTIONSAccept: application/sdpContent-Length: 0

SIP/2.0 200 OKVia: SIP/2.0/UDP Station1.work.com; branch=z9hG4bK7890123From: Daniel<sip:Collins@work.com>; tag=lmnop123To: Boss<sip:Manager@station2.work.com>; tag=xyz5678Call-ID: 123456@station1.work.comCSeq: 1 OPTIONSAllow: INVITE, ACK, CANCEL, OPTIONS, BYESupported: newfield Content-Length: 146Content-Type: application/sdp

v=0o=manager 45678 001 IN IP4 station2.work.coms=c=IN IP4 station2.work.comt=0 0m=audio 0 RTP/AVP 4 15a=rtpmap 4 G723/8000 a=rtpmap 15 G728/8000

Usage of the OPTIONS Method

•Collins 詢問 Boss 那一些是他能接受的 media type. 他送出 OPTIONS 訊息.•Accept: header 指出 sender 希望 Boss 回覆時能使用 SDP 的格式說明Boss 端的 capabilities. 如果在 OPTIONS 中沒有 Accept: header, 則內定為“application/sdp”.•Boss 送回 200 OK. 內含之 SDP 說明 Boss 的機器的能力.

•Allow: header 指出 Boss 的機器能夠處理那一些 SIP methods, 這裡少寫了 REGISTER, spec 也沒有.•Supported: header 為 “newfile”表示任何新的 SIP extension 都可以支援. 如果兩端都支援相同的 extensions, 就可提供新的服務.•Content-type: 指出 message body 說明能支援的 codec.•Response 另外也可以有 Accept:, Accept-Encoding:, Accept-Language:,

72

SIP Extensions and Enhancements

• SIP INFO Method

• SIP Event Notification

• SIP for Instant Messaging

• SIP REFER Method

• Reliability of Provisional Responses

• SIP UPDATE Method

• Integration of SIP Signaling and Resource Management

73

73

SIP Extensions and Enhancements

RFC 2543, March 1999SIP has attracted enormous interest.Traditional telecommunications companies, cable TV providers and ISP

A large number of extensions to SIP have been proposed.

SIP will be enhanced considerably before it becomes an Internet standard.

RFC 3261183 Session ProgressSupported header

•從 1999 開始的 SIP RFC 2543, 就引起眾多的興趣. 包括傳統電信業, Cable TV 業者, 與 ISP 都承認 SIP 有很大的潛能. •因此, 即使 RFC 3261 仍只是 proposed standard, 許多的 extension 就不斷的產生出來, 甚至也成為 proposed standard. •這一切由 IETF 的 SIP working group 統籌負責.

74

74

183 Session Progress

It has been included within the RFC 3261.To open one-way audio path from called end to calling end

From the called party to calling partyEnable in-band call progress information to be transmitted

Tones or announcements

Interworking with SS7 networkACM (Address Complete Message)Ring back tone in 183 Session Progress

•183 Session Progress response code 是 RFC 3261 新增的項目.•183 Session Progress response code 通是用於開啟一個由 callee到caller 的單向音訊路徑, 用於通知 caller 一些 in-band call 正在進行的資訊。常用於通話建立時的資訊傳輸，例如：Tones 以及 announcement.•通常是用於與 SS7 網路溝通，比方說是 caller 送給 callee IAM (帶著電話號碼), callee送回 ACM message (送回 ring-back tone（嘟嘟聲)）告知caller, 建立電話的程序正在進行中。但在 SIP 並無與 ACM 相對的message, 故造出 183 來放入一些 SS7 中獨有的資訊.

75

75

The Supported Header

The Require Header (client → server)A client indicates that a server must support certain extension with Require header420 bad extension with Unsupported header

The Supported headerWay 1:

Options (client → server) Response with Supported (server → client)

Way 2:Request with Supported (client → server) 421 extension required with Require (server →client)

•Supported header 是 RFC 3261 新增的項目.•在 RFC 2543 中，僅定義了 “Require”這個 header，主要功能是讓 client 具體指定它希望完成某一項需求時, servers (包括 proxy) 必需擁有的 extensions 的能力。然而, Require: head 並不能用於讓 server 主動指出自己所具有的能力。因而在 RFC 3261 中，又多定義了一個 “Supported”這個 header field，讓 server 可以一次告訴 client 自己全部支援的extension。•當 client 想要知道某個 server 是否支援某項 extension 時，就可以在 request 裡加上“Required” 這個標頭。Require 後面接著 option tags 的 list. 每個 option tag 代表一個extension, 定義於獨立的 RFC 中 (but 現在不知道在那裡).

•如果該 server 看不懂或不支援的話，則會回傳 420 Bad Extension ,並且把不支援的項目列在 “Unsupported” header 之內。•這是一種很笨的做法.

•Supported header 的用法:•當 client 想要知道某個 server 是否支援某些 extension 時, 就可送出 OPTIONS request 給 server. Sever 會回覆包含 Supported header 的欄位, 說明自己所具有那些 extensions。•如果一個 client 有支援某些 extensions 時，也可以在 request 裡加上 “Supported”的 header field，指出自己所具有的能力。

•若是 sever 受到 client 的 request, 但 server 所需要的 extension 卻沒有列在 Supported header 中, 此時就會回應 421 extension required, 用Require header 告知 client 必須要支援這些 extension。

•如果 Supported 後面是空的, 就表示未支援任何 extensions.

76

76

SIP INFO Method

Specified in RFC 2976For transferring information during an ongoing sessionApplication-layer information could be transferred in the middle of a call.A powerful, flexible tool to support new services

The transfer of DTMF digitsThe transfer of account balance information

Pre-paid service

The transfer of mid-call signaling information generated in another network and passed to the IP network via a gateway

•SIP INFO method 是 RFC 2976 “The Session Initiation Protocol (SIP) INFO Method” 新增的項目. 在 session 正進行時 (如正在講電話的過程中), 可以傳送特別的 application-layer 資訊。

•INFO 訂定得很有彈性, 並沒有指定格式, 可將資訊放在 message body 中送給對方.•若將來有新的服務, 就可以用 INFO 來傳.

•應用上就像是 Dual-Tone Multi-frequency (DTMF) digits 的傳送（就是按鍵資料的傳送）或者是預付卡通知「預付額快要用完」等情況.

77

77

SIP Event Notification

RFC 3265 has addressed the issue of event notification.SUBSCRIBE and NOTIFYEvent header

Subscriber Notifier

SUBSCRIBE

200 OK

NOTIFY

200 OK

NOTIFY

200 OK

a

b

c

d

e

f

Current stateinformation

Updated stateinformation

•SIP Event method 是 RFC 3265 “Session Initiation Protocol (SIP)-Specific Event Notification”新增的項目. 在 RFC 3265 中描述一個 general 的通知機制 (而非針對特定事件), 使得發生 event 時 (ex: instant message, presence, monitoring of calls), 可以讓兩方以描述事件-通知這樣的訊息互動. •Ex 1: 如果使用者想知道在 Instant Messaging buddy list 中的成員的上線狀況, 就可用 SUBSCRIBER 送出詢問的要求給 Instant Messaging server. 其中可以用 Event: header 指出使用者想要知道狀況的 buddy 名單. 之後Server 將使用 NOTIFY 回覆資訊給使用者.•Ex 2: (如上圖) 如果使用者想知道股票價格等資訊, 會送出 SUBSCRIBER 給 server. 在 message body 中可能會有股票號碼的清單, 而 Event: header 中可能會帶著讓 server 瞭解 message body 格式的資訊.

•Server 在做完 authentication 檢查後, 會送回 200 OK.•接下來 server 將相關資料以 NOTIFY 傳回給使用者.•如果狀況改變, 股票價格改變, (或在 Ex1 中, 又有新的 buddy 上線), server 又會再送出 NOTIFY, 提供新的資訊.•使用者會對每一個 NOTIFY 回應一個 200 OK.

•SIP 提供的只是一個通知的機制, 因此各種應用要如何架在 Event Notification 上, 必須自己制定詳細的運作方式與規格. 包括 Event: header 的內容, message body 的格式, 都需要進一步的設計.

78

78

SIP for Instant Messaging (1/3)

The IETF working group – SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE)RFC 3428 “Session Initiation Protocol (SIP) Extension for Instant Messaging”A new SIP method – MESSAGE

This request carries the actual message in a message body.A MESSAGE request does not establish a SIP dialog.

•IETF 成立 SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) 這一個 working group, 專門處理 instant messaging 等議題. 提出 RFC 3428 “Session Initiation Protocol (SIP) Extension for Instant Messaging ”•Instant messaging 是讓一群人以接近 real-time 的方式交換訊息. 雖然也可傳送檔案, 圖片, 但大多是很短的訊息. 通常不會把交換的訊息儲存起來, 但也有例外的時候. 這一群人建立起一個 session, 但傳送的 message 間卻是獨立的.•一開始使用 INVITE 來建立起他們間的 session.接著使用 SIP 新增的MESSAGE method 來傳送資料.最後以 BYE 結束這個 session.•MESSAGE 中, message body 用於傳送資料. 其格式可以是 text/plain, 也可以是 message/cpim. cpim是 common presence and instant message 的縮寫.•傳送 MESSAGE 並沒有建立任何 SIP dialog. 所以 To: From: header 並不需要 tag.

79

79

Daniel<sip:Collins@station1.work.com>Boss<sip:Manager@pc1.home.com> sip:Server.work.com

MESSAGE sip:Collins@work.com SIP/2.0Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890Max-Forwards: 70From: Boss<sip:Manager@home.net> To: Daniel<sip:Collins@work.com>Call-ID: 123456@pc1.home.netCSeq: 1 MESSAGEContent-Type: text/plainContent-Length: 19Content-Disposition: render

Hello. How are you?

MESSAGE sip:Collins@work.com SIP/2.0Via: SIP/2.0/UDP server.work.com; branch=z9hG4bKxyz1Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890Max-Forwards: 69From: Boss<sip:Manager@home.net> To: Daniel<sip:Collins@work.com>Call-ID: 123456@pc1.home.netCSeq: 1 MESSAGEContent-Type: text/plainContent-Length: 19Content-Disposition: render

Hello. How are you?

SIP/2.0 200 OKVia: SIP/2.0/UDP server.work.com; branch=z9hG4bKxyz1Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890From: Boss<sip:Manager@home.net> To: Daniel<sip:Collins@work.com>Call-ID: 123456@pc1.home.netCSeq: 1 MESSAGEContent-Length: 0

SIP/2.0 200 OKVia: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890From: Boss<sip:Manager@home.net> To: Daniel<sip:Collins@work.com>Call-ID: 123456@pc1.home.netCSeq: 1 MESSAGEContent-Length: 0

ab

cd

SIP for Instant Messaging (2/3)

•Boss 透過 proxy 送出 MESSAGE 給 Daniel.•Daniel 回覆 200 OK.

80

80

Daniel<sip:Collins@station1.work.com>Boss<sip:Manager@pc1.home.com> sip:Server.work.com

MESSAGE sip:Manager@home.net SIP/2.0Via: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123Max-Forwards: 70From: Daniel<sip:Collins@work.com> To: Boss<sip:Manager@home.net> Call-ID: 456789@station1.work.comCSeq: 1101 MESSAGEContent-Type: text/plainContent-Length: 22Content-Disposition: render

I’m fine. How are you?

MESSAGE sip:Manager@home.net SIP/2.0Via: SIP/2.0/UDP server.work.com; branch=z9hG4bKabcd

Via: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123

Max-Forwards: 69From: Daniel<sip:Collins@work.com> To: Boss<sip:Manager@home.net> Call-ID: 456789@station1.work.comCSeq: 1101 MESSAGEContent-Type: text/plainContent-Length: 22Content-Disposition: render

I’m fine. How are you?

SIP/2.0 200 OKVia: SIP/2.0/UDP server.work.com; branch=z9hG4bKabcd

Via: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123

From: Daniel<sip:Collins@work.com> To: Boss<sip:Manager@home.net>Call-ID: 456789@station1.work.com CSeq: 1101 MESSAGEContent-Length: 0

SIP/2.0 200 OKVia: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123From: Daniel<sip:Collins@work.com> To: Boss<sip:Manager@home.net>Call-ID: 456789@station1.work.com CSeq: 1101 MESSAGEContent-Length: 0

ef

gh

SIP for Instant Messaging (3/3)

•Daniel 想要對 instant message 回應, 送出自己的 MESSAGE. 也是經由proxy 送到對方.

•從 protocol 的角度看, 以上這兩個 MESSAGE 是無關的.•所以兩次 MESSAGE 可以透過不同的 proxy 來傳送.•在 MESSAGE 中, 不可以有 Contact: header. why? 不建立 dialog.•在 MESSAGE 中, 也不會有 Record-Route: 與 Route: (這是用於SIP dialog, 記錄下一次傳送訊息時所走的路徑). 這是因為MESSAGE 並沒有建立任何 SIP dialog.

•Boss 回應 200 OK.

81

81

SIP REFER Method

RFC 3515 “The Session Initiation Protocol (SIP) Refer Method”To enable the sender of the request to instruct the receiver to contact a third party

With the contact details for the third party included within the REFER requestFor Call Transfer applications

The Refer-to: and Refer-by: HeadersThe dialog between Mary and Joe remains established.

Joe could return to the dialog after consultation with Susan.

•RFC 3515 - The Session Initiation Protocol (SIP) Refer Method•REFER 是讓送出 REFER 的 sender, 命令 receiver 與第三者連絡. 最常見的應用是用在 Call Transfer (話中轉接). 詳細的資料就放在 REFER的message-body.•以下是 Call Transfer 的範例.•有一個 Refer-by: header 會放在 REFER 中, 也可以放在之後邀請第三者的INVITE 中 (optional), 可以表示是依誰的要求進行電話的轉接. 例如可以寫Joe 是依據 Mary 的建議才改與 Susan 談話, 也許 Susan 看了後會比較願意送回 200 OK.•Mary 與 Joe 間的 dialog 仍然維持著, 所以在與 Susan 通話後, 又可以回來繼續與 Mary 談話. 但如果 Mary 或 Joe 任一方想結束 dialog 也是可以的, 只要兩端依據正常的 BYE request 流程, 就可結束兩者間的通訊.

82

82

sip:Mary@station1.work.com sip:Joe@station2.work.com sip:Susan@station3.work.com

REFER sip:Joe@station2.work.com SIP/2.0Via: SIP/2.0/UDP station1.work.com; branch=z9hG4bK789

Max-Forwards: 70From: Mary<sip:Mary@work.com>; tag=123456 To: Joe<sip:Joe@work.com>; tag=67890Contact: Mary<Mary@station1.work.com>Refer-To: Susan<sip:Susan@station3.work.com>Call-ID: 123456@station1.work.comCSeq: 123 REFERContent-Length: 0

SIP/2.0 202 AcceptedVia: SIP/2.0/UDP station1.work.com; branch=z9hG4bK789

From: Mary<sip:Mary@work.com>; tag=123456 To: Joe<sip:Joe@work.com>; tag=67890Contact: Joe<Joe@station2.work.com>Call-ID: 123456@station1.work.comCSeq: 123 REFERContent-Length: 0

INVITE sip:Susan@station3.work.com SIP/2.0Via: SIP/2.0/UDP station2.work.com; branch=z9hG4bKxyz1

Max-Forwards: 70From: Joe<sip:Joe@work.com>; tag=abcxyz To: Susan<sip:Susan@station3.work.com>Contact: Joe<Joe@station2.work.com>Call-ID: 67890@station2.work.comCSeq: 567 INVITEContent-Type: application/sdpContent-Length: xxContent-Disposition: session{message body}

a

bc

Call Transfer (1/2)

•Mary 與 Joe 正在通電話, 按照一般狀況, Joe 想轉和 Susan 談話, 口頭詢問 Mary 的意見, Mary 也表示同意, 因此 ”Mary”開始進行此 Call Transfer 的動作. 因此感覺上, Mary 是主動的.•或者是 Mary 希望 Joe 在 session 中與 Susan 諮商後在回來繼續通話, 所以是 Mary 將電話轉給 Susan. 所以稱為 Call Transfer.•Step a: Mary 決定將電話轉給 Susan, 送出 REFER 給 Joe. 其中的 Refer-To: header 帶著 Susan 的位址. •Step b: Joe 送回 202 Accept 給 Mary, 表示同意接受此要求. 但到最後轉接成功後, Jeo還要送 NOTIFY (Step f) 給 Mary, 表示真正的成功.•Step c: Joe 送出 INVITE 給 Susan.

83

83

sip:Mary@station1.work.comsip:Joe@station2.work.com

sip:Susan@station3.work.com

e

fg

SIP/2.0 200 OKVia: SIP/2.0/UDP station2.work.com; branch=z9hG4bKxyz1

From: Joe<sip:Joe@work.com>; tag=abcxyz To: Susan<sip:Susan@station3.work.com>; tag=123xyzCall-ID: 67890@station2.work.comCSeq: 567 INVITEContent-Type: application/sdpContent-Length: xxContent-Disposition: session{message body}ACK sip:Susan@station3.work.com SIP/2.0Via: SIP/2.0/UDP station2.work.com; branch=z9hG4bKxyz1

Max-Forwards: 70From: Joe<sip:Joe@work.com>; tag=abcxyz To: Susan<sip:Susan@station3.work.com>; tag=123xyzCall-ID: 67890@station2.work.comCSeq: 567 ACKContent-Length: 0

NOTIFY sip:Mary@station1.work.com SIP/2.0Via: SIP/2.0/UDP station2.work.com; branch=z9hG4bK123

Max-Forwards: 70To: Joe<sip:Joe@work.com>; tag=67890From: Mary<sip:Mary@work.com>; tag=123456 Contact: Joe<Joe@station2.work.com>Call-ID: 123456@station1.work.comCSeq: 124 NOTIFYContent-Type: message/sipfrag;version=2.0Content-Length: 15

SIP/2.0 200 OK

SIP/2.0 200 OKVia: SIP/2.0/UDP station2.work.com; branch=z9hG4bK123

To: Joe<sip:Joe@work.com>; tag=67890From: Mary<sip:Mary@work.com>; tag=123456 Call-ID: 123456@station1.work.comCSeq: 124 NOTIFYContent-Length: 0

h

Call Transfer (2/2)

•Step e, f: 當 Susan 同意 Joe 的 INVITE 後, 送回 200 OK. Joe 送回 ACK.•Step g: Joe 以 NOTIFY 通知 Mary 成功, 此訊息的 message body 會包括一部份 Susan 的 200 OK 的 message body,

•以 Content-type: message/sipfrag: verison 2.0 顯示 SIP 訊息(NOTIFY) 中還包含 SIP 訊息 (200 OK), i.e., 像是 tunnel 的方式.

•Step h: Mary 送回 200 OK 給 Joe.•之後 Mary 或 Joe 可以送出 BYE, 結束兩者間的 dialog, 而 Joe 與 Susan 可以繼續這個 session 的通訊.

84

84

Reliability of Provisional Responses (1/2)

Provisional Responses100 (trying), 180 (ringing), 183 (session in progress)Are not answered with an ACK

If the messages is sent over UDPUnreliable

Lost provisional response may cause problems when interoperating with other network

180 (ring), 183 (session progress) → Q931 alerting or ISUP ACM (Address Complete Message)These external networks need these information to drive a state machine.

•100 Trying, 180 Ringing, 183 Session in Progress 這些 response 都是屬於 provisional response，有沒有收到其實不會影響 SIP entities 運作，因此是不需要用 ACK 來確認是否正確到達 caller。但是有些時候，特別是在和其它網路互聯時，這些 provisional response 的遺失就會顯得很重要。像是 180, 183 對應到 Q.931 alerting, ISUP ACM，對這些異質網路而言, 卻都是必須的訊息. 當這些資訊遺失時，其它異質網路的狀態機 (state machine) 有可能因此而無法正常運作。

•所以 SIP 在 extension 中提供了 provisional response 的可靠傳輸，是利用 RSeq, Rack, 以及 PRACK 來達成。

85

85

Reliability of Provisional Responses (2/2)

E.g., a call to an unassigned numberACM to create a one-way path to relay an announcement such as “The number you have called has been changed”If the provisional response is lost, the caller might left in the dark and not understand why the call did not connect.

RFC 3262 “Reliability of Provisional Responses in SIP”

Response sequence (RSeq): a request header Response ACK (RAck): a response headerOption tag=100rel with supported:/unsupported:Provisional Response ACK (PRACK) method

•ISUP 的 ACM 訊息是用於從 callee到 caller 這樣單向的傳輸路徑.•如果 Caller 輸入一個未設定好的電話號碼, ACM 就可傳回錯誤的訊息, 如”你撥的電話號碼已經更改, 請轉撥 *****”. 萬一相對於 ACM 的 provisional response 遺失了, 則 caller 可能就停在那裡不知所措, 也不瞭解為何電話接不通.•RFC 3262 “Reliability of Provisional Responses in SIP”訂定兩個 headers 和一個 option tag, 和 PRACK method, 希望能達到 end-to-end 之間provisional response 的可靠傳輸.

•response sequence (RSeq): 這個 request header 用於 server 傳回的 provisional response, 代表這個 provisional response 的序號. 對於同一個 transaction, 每一個 RSeq都必須不同 (i.e., RSeq的scope 是一個 transaction). 但不同的 transaction, RSeq可以是相同的.•response ACK (RAck): 這個 response header 放於 caller 傳回的PRACK 中, RAck設成 RSeq, 代表這個 PRACK 是回應擁有序號為RSeq 的 response. •Supported: header 增加一個 option tag, 值為 100rel, 表示支援 “所有 provisional responses 會可靠的送達”.•若 option tag=100rel 是放在 Unsupported: header, 則代表 server 不瞭解這個 option tag, 換句話說, 不支援 RSeq, RAck等 extension. 100rel代表 100% reliability.•Provisional Response ACK (PRACK) method 是讓 caller 收到provisional response 後, 傳給 callee, 告知確實有收到.

•這個方式是針對 end-to-end 之間 provisional response 的可靠傳輸, 所以對於 hop-by-hop 的 100 trying 就不適用.

86

86

INVITE sip:ServerB@network.com SIP/2.0Via: SIP/2.0/UDP ClientA.network.com; branch=z9hG4bK7890123Supported: 100relRequire: 100relFrom: sip:ClientA@network.com; tag=lmnop123To: sip:ServerB@network.comCall-ID: 123456@ClientA.network.comCSeq: 1 INVITE

??SIP/2.0 180 RingingVia: SIP/2.0/UDP ClientA.network.com; branch=z9hG4bK7890123Require: 100relRSeq: 567890From: sip:ClientA@network.com; tag=lmnop123To: sip:ServerB@network.com; tag = xyz123Call-ID: 123456@ClientA.network.comCSeq: 1 INVITE

ResponseLost

b

a

c

ResponseRetransmit

ClientA@network.com ServerB@network.com

SIP/2.0 180 RingingVia: SIP/2.0/UDP ClientA.network.com; branch=z9hG4bK7890123Require: 100rel

Provisional Response ACK (1/2)

Start timer T1

default=0.5 sec

•在範例中, Client A 打電話給 Server B, Sever B 的 provisional response 遺失了, 但因有支援可靠的回應, 所以利用重傳得到確認.•Step a: Client A 送出 INVITE.

•Client A 有支援 PRACK, 可從送出的 INVITE 中 Supported: 100rel 看出.•Client A 也希望對方也支援, 所以有 Required: 100rel.

•Step b: Sever B 回應的 180 Ringing, 同時啟動 timer T1=0.5sec. 不幸的180 Ringing 遺失了.

•在回應中必須包含 RSeq, 代表這個 provisional response 的序號. 另外 Require: 中一定要有 100rel 此 optional tag, 表示要求 caller 要回覆 PRACK. •RSeq設成一個 random number 567890. 這個隨機亂數是一個 32 bits, 介於 1 到 4,294,967,295 的值.•啟動之 timer T1, 預設值為 0.5 sec.

•Step c: Timeout 後, Sever B 未收到 PRACK, 因此重傳 180 Ringing.•重傳的回應中仍包含 RSeq, 但針對同一個 response, 每重傳一次, RSeq就加 1. 所以目前為 RSeq=567891. •最多可重傳 64 次.•若連傳 64 次後仍未收到 PRACK, sever 會當作網路有損壞放棄.

87

87

SIP/2.0 180 RingingVia: SIP/2.0/UDP ClientA.network.com; branch=z9hG4bK7890123Require: 100relRSeq: 567891From: sip:ClientA@network.com; tag=lmnop123To: sip:ServerB@network.com; tag = xyz123Call-ID: 123456@ClientA.network.comCSeq: 1 INVITE

d

c

e

ClientA@network.com ServerB@network.com

SIP/2.0 200 OKVia: SIP/2.0/UDP ClientA.network.com; branch=z9hG4bK7890123From: sip:ClientA@network.com; tag=lmnop123To: sip:ServerB@network.com; tag=xyz123Call-ID: 123456@ClientA.network.comCSeq: 2 PRACK

PRACK sip:ServerB@network.com SIP/2.0Via: SIP/2.0/UDP ClientA.network.com; branch=z9hG4bK7890123RAck: 567891 1 INVITEFrom: sip:ClientA@network.com; tag=lmnop123To: sip:ServerB@network.com; tag=xyz123Call-ID: 123456@ClientA.network.comCSeq: 2 PRACK

Provisional Response ACK (2/2)

•Step d: 當 Client A 收到 180 Ringing, 回傳 PRACK 給 callee.•RAck: 帶著 3 個 subfields. 第一個是與 RSeq相同的值, 表示這是回應 RSeq這一個 response. 第二個是 CSeq代表是那一次的 dialog, 第三是表示這是為 INVITE method 而傳送的.•雖然沒有收到所謂 final response, 但 CSeq為 2 PRACK, 表示一個新的 transaction 的開始.

•Step e: 當 sever B 收到 PRACK, 回覆 200 OK (for PRACK). 注意這個200 OK, 並不是針對 INVITE.•可以看出增加了 PRACK, 增加了 reliable, 但並不會因此對 call setup 造成delay (PRACK 是在 200 OK 內傳送). 因此使用 UDP 等 unreliable transport protocol 加上 PRACK 來 SIP 訊息, 還是比用 TCP 傳送來得快一點. 但代價是 Application 比較不好寫.

88

88

The SIP UPDATE Method

RFC 3311 “The Session Initiation Protocol (SIP) UPDATE Method ”To enable the modification of session information before a final response to an INVITE is received

E.g., to change the codec

One important usage is when reserving network resources as part of a SIP session establishment

•在一個(已經收到 200 OK) session 中, 如果想要更改所使用的 codec, 可以再傳送一次 INVITE. 在第二次的 INVITE 中, 指出所想使用的方式. 這樣是在已經建立起的 (confirmed state) dialog 上, 送出第二次的 INVITE, 則dialog 會變成 early state.

•Note: 在建立 dialog 初期稱為 early state. 若 caller 收到 2xx response, 便進入 confirmed state, 直到結束.

•但是此方法對於一個仍在 early state 的 dialog, 就不適用. 舉例來說, 若session 進行到 callee送回 183 session progress 的回應, 其中 message body 可能包含 ring tone 或 music, 此時仍是 early state. 但如果之後 caller 想改變 media 的參數, 或讓 media 延遲進行, 就會有問題. 因為這樣可能原先的 ring tone 就會中斷.•因此在 RFC3311 中提出 UPDATE method.

•在 caller 送出 INVITE, 收到 final response 前, 可以使用 UPDATE 對 session 內容做修正.•當 dialog 建立起來, 不論是 early 或 confirmed state, 不論是 caller 或 callee, 都可以使用內含 SDP offer 的 UPDATE, 對 session 內容做修正. 對 UPDATE 送回的 response (2XX), 必須包含 answer.•可做為 network resource management 的手段, 依據現有的頻寬, 要求改變 media 格式時使用.

•利用 INVITE 中的 Allow: header, 可以指出是否支援 UPDATE.

89

89

Integration of SIP Signaling and Resource Management (1/2)

Ensuring that sufficient resources are available to handle a media stream is a very important.The signaling might take a different path from the media.Assume resource-reservation mechanisms are available (Chapter 8)

End-to-end statusEnd-to-end network resources are reserved as part of session establishment.

Segmented statusA certain amount of network resources are reserved in advance for a certain type of usage.Policing functions at the edge of the network

•若要提供 carrier-grade 的服務, 確保有足夠的 resource 可以滿足 media streams 的要求是非常重要的工作.•由於 signaling 與 voice 可能會經由不同的路徑傳送, 所以我們無法用signaling 傳送的情況來推斷語音傳送的路徑是否順暢.•如何能確保網路可滿足語音傳送的需求? 在第 8 章有提到下列兩種方式:

•End-to-end status: 在建立每一個 session 的過程中, 雙方分別保留下自己到對方方向的 end-to-end 所需的網路資源. (監控整體的頻寬, 不分類). 做法是告訴對方需要配合的事項, 若雙方同意且保留資源, 兩方開始各自完成單向保留資源的程序. 資源保留完成後, 才開始振鈴, 建立通訊.

•適用於在網路上的每一個節點都提供像 RSVP 這樣的資源保留機制.

•Segmented Status: UAs各自管理自己的網路資源.•課本稱為 an aggregate (聚集) basis.做法是將網路上的資源分類, 分配一定比率的頻寬給不同的應用 (ex: voice, data, management traffic). UA 就以隨時監控網路上 (以 link 為監視的單位) 的資源, 知道還有保留多少資源. •在建立 session 的過程一開始, 在要求對方之前, 先檢討自己剩餘的資源是否足夠, 保留下自己一方(接收與傳送)所需的資源後, 才會送出 INVITE 這樣的 request.•適用於 UAs在不同的網路上, 各自管理自己的網路資源.

•在設計 SIP 相關的資源保留管理時, 同一個 session 若有多條 media streams, 可以同時採用上述兩種方式. 但同一條 media stream, 只能用一種.

90

90

Integration of SIP Signaling and Resource Management (2/2)

Way I: A rejected Internet draftWay II: RFC 3312 “Integration of Resource Management and Session Initiation Protocol (SIP)”

By using and UPDATE method and the provisional responses By involving extensions to SDPBy SIP extensions 580 precondition failure

•第一種方法, 是 1999 年提出的 Internet draft, 使用一新的 SIP header.•送出的第一個 INVITE 中, caller 使用 header 指出希望 callee要保留那些資源. 若已經成功保留下所需的資源之後, 會送出的第二個 INVITE 中, 此時才會振鈴呼叫使用者, 開始建立電話.•在 SIP 標準中, 若遇到無法瞭解的 header, 可以略過不計. 但若 callee不認識新的header, 將直接建立電話, 而不知道資源可能是不足的. 因此與 SIP 標準不相容, 這個 extension 被 rejected.

•第二種方法, 新的 rfc3312: “Integration of Resource Management and SIP”被提出, 使用可靠的 provisional response, UPDATE 與改進後的 SDP, 將 QoS的需求寫在 SDP 中 (而非 SIP 中).

•由 SDP 提出是那些 stream, 那些方向, 需要甚麼樣的 QoS需求. 例如 audio 會比video 有更強烈的 QoS需求, 所以必須分別管理其使用的資源.•使用 UPDATE 與 183 session progress 傳送 SDP, 來通知對方自己已做好頻寬的保留. 為確保訊息正確到達對方, 採用 PRACK/200 OK 做確認的動作. •若無足夠的資源, 會送回 SIP extension 的 580 precondition failure. (和 BYE 或CANCEL) 結束 session. 但這是最後的手段, 通常會再挑選低頻寬需求的 codec, 做再次的嘗試.•RFC 定義 precondition 這樣的 option tag, 當提出 offer 的一端希望對方一定要做資源的保留, 就要在 SIP 中 Require header 註明 precondition. RFC 建議最好Supported header 能有 precondition. 由於也要用到 PRACK, UPDATE, 所以也要有 100rel.

•除了一開始建立 session 所要做的資源保留, 也可以是在 session 進行的過程中, 改變QoS或某些資源的使用時, 採用 RFC 3312 的作法. Ex1: 有一端要改變接收 media 的 IP address, 這時就會送出 re-INVITE, 其中 SDP 會寫出新的資源要求. 之後的過程都相同. Ex2: 原本提供兩種 codec, 改成只有一種, 也可用這樣的方式改變.

91

91

End-to-end Resource Reservation

INVITESession Description(with pre-condition attributes)

SIP/2.0 183 Session ProgressSession Description(with pre-condition attributes)

a

b

cPRACK

SIP/2.0 200(OK) (for PRACK)

Resource Reservation

UPDATESession Description(with updated pre-condition attributes)

SIP/2.0 200 (OK) (for UPDATE)Session Description(with updated pre-condition attributes)

SIP/2.0 180 (Ringing) (response to initial INVITE)

PRACK (for 180 response)

SIP/2.0 200(OK) (for PRACK)

SIP/2.0 200(OK) (for INVITE)

ACK

d

e

f

g

h

i

j

k

l

UserA@network.com UserB@network.com

Reserving network resources in advance of altering the called user

•在範例中, User A 打電話給 User B. 這個網路上使用 RSVP.•Step a: User A 送出 INVITE, 其中包括 session description. 說明 User A 可以提供的項目(offer media), 還有彼此間使用的 media streams, 希望對方同意的保留的頻寬等條件(preconditions), ex: 採用 end-to-end 的方式. User A 要求 User B 在尚未完成資源保留前, 不可以送出振鈴.•Step b: User B 送回 183 Session Progress. 給予 answer, 同意 User A 的要求, (包括B-to-A 方向的資源保留, 由 B 負責), 並說明 User B 希望 User A 為 A-to-B (B 的 recv) 此方向的stream 做 resource 的保留.

•User B 送出 183 Session Progress 後, 就開始進行 B-to-A 方向的資源保留.•Step c: User A 送出 PRACK 表示有收到 response. (A 開始進行 A-to-B 方向的資源保留)•Step d: User B 送回回應 PRACK 的 200 OK.•Step e: User A 與 User B 各已自保留好頻寬.•Step f: 當 User A 已保留好頻寬, User A 立刻送出 UPDATE, 其中的 offer 表示自己的狀態(A-to-B 方向已經 OK).•Step g: User B 以 200 OK 回應 UPDATE, 說明 B-to-A 的頻寬也保留好了.•Step h: User B 開始振鈴, 傳回 180 Ringing (for INVATE).•Step i, j: 用 PRACK 與 200 OK (for 180 Ringing) 為 Ringing 做確認的動作.•Step k: User B 拿起話筒, 因此傳回 200 OK (for INVATE).•Step l: User A 送回 ACK.•Note: 若 A 的 INVITE 沒有包括 offer, B 也可以在 1xx 中包含 offer, A 在 PRACK 中包含answer 送回.

92

92

Media Level SDP Attributes

Precondition-type = qos | token Three status: des (desired) / curr (current) / conf (confirmed)Status type: e2e (end-to-end) / local / remoteDirection tag: send (sending) / recv (receiving) / sendrecv (both) / noneStrength tag: none / mandatory / optional / failure / unknown

•SDP 為表示 preconditions, 設計了許多新的 media level SDP attributes:•目前只定義了一種 precondition-type 為 qos, 其他的保留給新的服務.•三種描述 SDP 工作時間的狀態: desired/current/confirm

•Current 表示在現在的時間. 接著用其他 tag 說明資源有無保留.•Desired 在列出為建立電話所需要的最基本的需求.•Confirmed 在列出最基本 QoS需求, 希望對方將其保留. 並且請對方在資源保留後, 馬上送回 offer. (confirmed 可以用在 answer 與 offer 中, 但目前只看到放在 answer 的例子).

•四種表示設定的 media stream 方向的 direction-tag: send/recv/senrecv/none. 表示所陳述的需求是為此方向而描述.

•send/recv 是以寫此 SDP 的 UA 為準, 表示來表示 media stream 的方向. 例如 User A 寫的 SDP 中User A 到 User B 的方向, 稱為 send. 但 User B 寫的 SDP 中要描述 User A 到 User B 的方向, 則用recv. •sendrecv表示目標是雙方向的 media stream 都有相同的需求. 雖然可以用兩行 send, recv來描述兩個獨立的 streams, 但若 precondition 相同時, 為節省空間, 會使用 sendrecv.•none 表示無方向性.

•兩種保留網路資源方式用的的 status type: e2e/local/remote•e2e 表示 end-to-end 的方式, 要做 end-to-end 間的資源保留.•採用 segmented 的方式, 以寫此 SDP 的 UA 為準, 自己稱為 local, 對方稱為 remote. 若註明 local, 表示在自己的 local network 端, 被允許使用所需的網路各類資源.•若註明 remote, 表示對方必須確認對方網路被允許使用所需的各類資源.

•Strength tag 表示當需求不符合時, 是否要警告 callee.•none 表示初始的狀態, 尚未開始執行資源的保留.•mandatory 表示這樣的資源需求條件是一定要做到的, 否則就無法建立 session.•optional 表示這樣的資源需求條件是 optional, 對方應該保留頻寬, 但若達不到要求, 仍可繼續完成session 的建立.•failure 表示資源的保留失敗. 這時在送回的 580 pre-condition failure 中, 要包含 SDP 的描述, 就會有像 a=des:qos failure e2e send 的陳述.•unknown 表示看不懂對方的 offer. 若對方使用 mandatory 的字眼, 就必須拒絕這個 offer. ex: a=des:foo unknown e2e send

93

93

Example of e2e Resource Reservation (1/2)

SDP for initial INVITEv=0o=userA 45678 001 IN IP4 stationA.network.coms=c=IN IP4 stationA.nework.comt=0 0m=audio 4444 RTP/AVP 0a=curr: qos e2e nonea=des: qos mandatory e2e sendrecv

SDP for 183 responsev=0o=userB 12345 001 IN IP4 stationB.network.coms=c=IN IP4 stationB.nework.comt=0 0m=audio 6666 RTP/AVP 0a=curr: qos e2e nonea=des: qos mandatory e2e sendrecva=conf: qos e2e recv

•這裡說明圖 5-22 各個訊息中, 所帶著的 SDP 內容.•SDP for initial INVITE (step a)

•m=audio 4444 RTP/AVP 0 在 A to B 方向使用 RTP type=0 的audio 傳輸, A’s port # =4444. 關於此 media stream 的 attributes:•a=curr: qos e2e none 目前的狀態是尚未有 end-to-end 的 QoS •a=des: qos mandatory e2e sendrecv表示 User A 希望 sending 與receiving 雙向的傳輸都一定要有 QoS.

•SDP for 183 Session Progress (step b)•m=audio 6666 RTP/AVP 0 在 B to A 方向使用 RTP type=0 的audio 傳輸, B’s port # =6666. 關於此 media stream 的 attributes:•a=curr: qos e2e none 目前的狀態是尚未有 end-to-end 的 QoS•a=des: qos mandatory e2e sendrecv表示 User B 希望 sending 與receiving 雙向的傳輸都一定要有 QoS•a=conf: qos e2e recv 表示 User B 希望 User A 保留 A-to-B 方向的資源, 並在完成資源保留後送來一個 offer. User B 也將會處理 B-to-A 方向的保留資源.

94

94

Example of e2e Resource Reservation (2/2)

SDP for UPDATEv=0o=userA 45678 001 IN IP4 stationA.network.coms=c=IN IP4 stationA.nework.comt=0 0m=audio 4444 RTP/AVP 0a=curr: qos e2e senda=des: qos mandatory e2e sendrecv

SDP for 200 responsev=0o=userB 12345 001 IN IP4 stationB.network.coms=c=IN IP4 stationB.nework.comt=0 0m=audio 6666 RTP/AVP 0a=curr: qos e2e sendrecva=des: qos mandatory e2e sendrecv

•這裡說明圖 5-22 各個訊息中, 所帶著的 SDP 內容.•SDP for UPDATE (step f)

•a=curr: qos e2e send 目前的狀態是 caller 保留 caller-to-callee 方向的資源, 已完成 send 方向 end-to-end 的 QoS•a=des: qos mandatory e2e sendrecv表示 caller 希望 sending 與receiving 雙向的傳輸都一定要有 QoS

•SDP for 200 OK (for UPDATE) (step g)•a=curr: qos e2e sendrecv目前的狀態是雙向都已完成 end-to-end 的 QoS•a=des: qos mandatory e2e sendrecv表示 callee希望 sending 與receiving 雙向的傳輸都一定要有 QoS

95

95

Segmented Status ReservationEach participant deals with network access permission at its own end.

UserA@network.com UserB@network.com

Local resource reservation

INVITEv=00=userA 45678 001 IN IP4 stationA.network.coms=c= IN IP4 stationA.network.comt=0 0m=audio 4444 RTP/AVP 0a=curr: qos local sendrecva=curr: qos remote nonea=des: qos mandatory local sendrecva=des: qos mandatory remote sendrecv

Local resource reservation

SIP/2.0 180 Ringingv=00=userB 12345 001 IN IP4 stationB.network.coms=c= IN IP4 stationB.network.comt=0 0m=audio 6666 RTP/AVP 0a=curr: qos local sendrecva=curr: qos remote sendrecva=des: qos mandatory local sendrecva=des: qos mandatory remote sendrecv

PRACK (for 180response)

SIP/2.0 200 (OK) (forPRACK)

SIP/2.0 200 (OK) (forINVITE)

ACK

a

b

c

d

e

f

•在範例中, User A 打電話給 User B. 網路使用 segmented status (i.e., aggregate) 的 local policing 的方式保留頻寬.•Step a: User A 要先保留下自己 local network 所需的資源, 才送出 INVITE, 其中包括session description:

•m=audio 4444 RTP/AVP 0 在 A-to-B 方向使用 RTP type=0 的 audio 傳輸, A’s port # =4444. 關於此 media stream 的 attributes:•a=curr: qos local sendrecv目前的狀態是 User A 已經為雙向的傳送, 保留下自己網路端的資源.•a=curr: qos remote none 但是目前的狀態是不曉得對方 (User B) 的是否能保留下資源.•a=des: qos mandatory local sendrecv表示 User A 希望自己網路在 sending 與receiving 雙向的傳輸都一定要有 QoS.•a=des: qos mandatory remote sendrecv表示 User A 希望對方的網路在 sending 與 receiving 雙向的傳輸都一定要有 QoS

•Step b: User B 得知 User A 已保留資源, 因此在保留自己這端的資源後, 才送出 180 Ring (之後才能開始振鈴), 其中包括 session description:

•m=audio 6666 RTP/AVP 0 在 B-to-A 方向使用 RTP type=0 的 audio 傳輸, B’s port # =6666. 關於此 media stream 的 attributes:•a=curr: qos local sendrecv目前的狀態是 User B 已經在自己網路端為雙向的傳送, 保留下資源.•a=curr: qos remote sendrecv目前的狀態是知道對方 User A 的網路已保留下資源•a=des: qos mandatory local sendrecv表示 User B 希望自己網路對 sending 與receiving 雙向的傳輸都要有 QoS.•a=des: qos mandatory remote sendrecv表示 User B 希望 User A 的網路對於sending 與 receiving 雙向的傳輸都要有 QoS

•Step c, d: 用 PRACK 與 200 OK (for PRACK) 為頻寬的保留做確認的動作.•Step k: User B 拿起話筒, 因此傳回 200 OK (for INVATE).•Step l: User A 送回 ACK.

96

Usage of SIP for Features and Services

• Call Forwarding

• Consultation Hold

97

97

Usage of SIP for Features/Services (1/2)Personal Mobility (Registrar)Call-transfer application (with REFER method)One number service through forking proxyCall-completion services (by Retry-After: header)Click-to-call applications or Web service (SIP address is a URL)Existing supplementary services in traditional telephony

Call waiting, call forwarding, multi-party calling, call screening

•SIP 一個很重要的優點是 SIP extension 都可與過去的標準相容, 另一個優點是很容易提供新的服務. 以下說明之前已經介紹過的例子:•SIP registrar 的機制本身就可提供 personal mobility.•使用 REFER 做 call transfer, Fig 5-20•利用 forking proxy 做 one-number service, Fig 5-7•利用 Retry-After: header 做 call-completion service, Fig 5-6•可以在 SIP 位址放入 Web URL, 就可以得到 MIME content 的 HTML document, 或是 image, 或是進行 click-to-call service.•所有傳統電話所支援的 CLASS services, 包括 call waiting, call forwarding, multiparty calling, call screening.

98

98

Usage of SIP for Features/Services (2/2)Proxy invokes various types of advanced feature logic.

Policy server (call-routing, QoS)Feature server (subscriber-specific feature data, ex: screening lists, forwarding information)Authentication serverUse the services of an IN SCP over INAPUse Open Service Access (OSA)

•Proxy 還可以做為其他服務的重要角色, 如•Proxy 做為 Policy server 載有 call-routing 資訊, QoS相關資訊, 決定是否讓電話接通. Proxy 可以有 screening lists, forwarding 等資料, 做特殊客製化的服務. (other example: pre-pay call).•Proxy 做為 Authentication server, 決定使用者有無權力打電話.•透過 proxy 將電話轉送到 Intelligent network (IN) 上的 Service Control Point (SCP), 使用 IN 的服務. 這需要 proxy 瞭解 IN Application Part 的協定. 或者採用 Open Service Access (OSA) 這樣的平台, 以 Application Programming Interfaces (API) 來撰寫 proxy 與 SCP 間的連結.

99

99

Call Forwarding

Call-forwarding-on-busyCall-forwarding-on-no-answer

TimeoutCANCEL method

Call-forwarding unconditional

INVITE sip:user2@server.work.com SIP/2.0From: sip:user1To: sip:user2@work.comContact: User1CSeq: 1 INVITE

SIP/2.0 100 TryingFrom: sip:user1To: sip:user2@work.comCSeq: 1 INVITE

INVITE sip:user2@server.work.com SIP/2.0From: sip:user1To: sip:user2@work.comContact: User1CSeq: 1 INVITE

SIP/2.0 486 Busy HereFrom: sip:user1To: sip:user2@work.comCSeq: 1 INVITE

INVITE sip:user3@server.work.com SIP/2.0From: sip:user1To: sip:user2@work.comCSeq: 2 INVITE

SIP/2.0 200 OKFrom: sip:user1To: sip:user2@work.comContact: sip:user3@work.comCSeq: 2 INVITE

SIP/2.0 200 OKFrom: sip:user1To: sip:user2@work.comContact: sip:user3@work.comCSeq: 1 INVITE

User1 sip:Server.work.comUser2User3

•以下說明在 SIP 中如何做 call forwarding 的服務. 有多種原因造成要轉接到其他地方:•Call-forwarding-on-busy: callee若在講話中, 則電話自動轉接到另一台電話.•Call-forwarding-on-no-answer: 若 callee一直沒有回應, 則電話自動轉接到另一台電話.•Call-forwarding- unconditional service: 不論 callee狀況為何, 直接自動轉接到另一台電話.

•圖中顯示的是 call-forwarding-on-busy 的電話流程. User 1 打電話給 User 2. User 2 事先設定好如果自己在講話中, 則電話自動轉接到 User 3.

•當 User 1 送出 INVITE, 透過 proxy 給 User 2. 但此時 User 2 在講話中, 因此送回486 busy here 給 proxy. Proxy 查詢 database 後, 重新送出 INVITE 給 User 3.

•其中 To: header 仍指向 User 2, 可讓 User 3 知道這是一通 call forwarding 的電話.•486 表示有成功連絡到 callee, 但因某些原因, callee無意願接電話. response 中可以有 Retry-after: header, 也可以轉送到別處 (ex: voice mail). 如果 callee知道其他地方也沒有辦法連絡到 callee的話, 就會送回600 busy everywhere.

•User 3 送回 200 OK, 表示電話以接起通話.•其中 Contact: header 指向 User 3, 可讓 User 1 與 User 3 間直接建立起trunk.•如果 proxy 希望所有訊息都透過它傳送, 以做其他的服務, 可以用 Record-route: header 將自己記錄下來.

•Call-forwarding-on-no-answer: 當 proxy 送出 INVITE 給 User 2 後, 啟動 timer. 若 callee一直沒有回應, 則 proxy 送出 CANCEL 給 User 2, 而且送出 INVITE 到 User 3.•Call-forwarding- unconditional service 是不論 callee狀況為何, proxy 直接自動轉接到另一台電話.

100

100

Consultation Hold

User A asks User B a question, and User B need to check with User C for the correct answer.User B could use the REFER method to transfer the call to User C.A SIP UPDATE

INVITE sip:User A@there SIP/2.0From: sip:User B@hereCall-ID: 12345SDP Description

SIP/2.0 200 OKFrom: sip:User B@hereCall-ID: 12345SDP Description

ACK sip:User A@there SIP/2.0From: sip:User B@hereCall-ID: 12345

Conversation

UPDATE sip:User A@there SIP/2.0From: sip:User B@hereCall-ID: 12345Session Descriptiona=inactive

SIP/2.0 200 OKFrom: sip:User B@hereCall-ID: 12345Session Descriptiona=inactive

On hold

UPDATE sip:User A@there SIP/2.0From: sip:User B@hereCall-ID: 12345Session Descriptiona=sendrecv

SIP/2.0 200 OKFrom: sip:User B@hereCall-ID: 12345Session Descriptiona=sendrecv

User B calls User C, speaks, then hangs up

User A User B User C

a

b

c

d

e

f

gh

i

j

•這是 User A 與 B 通電話的過程中 (ex: A 問 B 一個問題), User B 暫時停止與 User A 通話 (只是 hold, 沒有掛斷). 接下來 User B 與 User C 建立通話(ex: B 詢問 C 答案). 當通話結束後, User B 切斷與 User C 的連結, 又重新開啟與 User A 的連線 (ex: B 回答 A 的問題, 所以稱為 Consultation Hold).

•和 REFER 不一樣, 下 call waiting 命令的話機角色不同.•Steps a-d: 開始時 User A 與 User B 依據正常程序建立電話. •Step e: User B 送出 UPDATE, 希望改變電話狀況為 inactive.

•在 UPDATE 中, 要指出 hold 那一通電話, 所以 Call-ID: 123456 要與 INVITE 的相同.•利用設定 SDP media 的 attribute 為 inactive, 希望暫時 hold 電話. 利用相同方式, 也可以設定 SDP media 的 attribute 為 sendonly.

•Steps f, g: 送回 200 OK, media 進入 on hold 狀態.•Step h: User B 依正常程序 (INVITE - BYE) 與 User C 通話.•Step i, j: User B 送出 UPDATE, 希望改變電話狀況為 active.

•在 UPDATE 中, 以 Call-ID: 123456 指出是那一通電話, 並設定 SDP media 的 attribute 為 sendrecv,表示開始通話,

101

Interworking

• PSTN Interworking

• Interworking with H.323

•使用 SIP 做為電話建立的 IP 網路, 必須與其他電話系統並存. 因此在此處提出與 PSTN 和與 H.323 網路 interworking 的方式.

102

102

SIP to PSTN Call

INVITE

183 (Session Progress)Session description

One-way audio

Manager@work.com Proxy.work.com PSTN switch

a

b

g

i

j

m

100 (Trying)INVITE

100 (Trying)

183 (Session Progress)Session description

IAM

ACM

One-way audio

ANM

200 (OK)Updated session description

200 (OK)Updated session description

ACK

ACK

Two-way audio Two-way audio

c

de

f

h

k

l

n

o

NGW

•SIP 與 PSTN 互動的目標: seamless interworking, 讓 SIP device 得到PSTN 上所有的服務.•PSTN 上使用 SS7 的 ISUP 來管控電話流程. 因此在 gateway 上同時要有SIP 與 ISUP. 第六章將說明 SIP-based 的網路上, 如何控制 media gateway. 第七章將說明 signaling gateway 如何與 SS7 互動.•如果是 Boss 以 SIP phone 打給 PSTN (Collins 在家中), 會透過 NGW (Network Gateway) 來處理兩個網路的溝通, 如上圖.

•NGW (network gateway) 可以利用 To: header 可找到 PSTN 電話號碼, 再放入 IAM (initial address message) 中的 calling party number. •利用 From: header 如果是以電話號碼表示的 SIP URI, 就可以讓對方得到 Caller-ID 的服務.•基本上 IAM 對應 INVITE, ACM (Address Complete Message) 對應183 Session Progress), ANM (Answer Message) 對應 200 OK. 但不是訊息中所有 parameters 都有一對一的對應.

•如果是 PSTN 打給 SIP phone, 就如同圖例 Fig 5-28. SIP 會使用 180 ring 來驅使 PSTN phone 產生 ring tone. 也可使用 183 session progress 中帶著 ring tone 的 media 描述來達成. •有許多訊息在圖中被省略. 另外, 若為達到可靠性, 也可加入 PRACK 等訊息.

103

103

PSTN Interworking

RFC 3372 - Session Initiation Protocol for Telephones (SIP-T): Context and ArchitecturesPSTN – SIP – PSTN

RFC 3204 - MIME media types for ISUP and QSIG ObjectsMIME media typesFor ISUP

The whole issue of interworking with SS7 is fundamental to the success of VoIP in the real world.

•與 PSTN 互動的困難度在於 SIP 與 ISUP 訊息並沒有 1 對 1 的對應, 其中的參數也不見得有對應.•專為此問題而提出了 RFC SIP-T (Session Initiation Protocol for Telephones (SIP-T):Context and Architectures). 它是一個 BCP (Best Current Practice), 不算是 SIP 的 extension, 只是提出 SIP 與 PSTN 互動的最佳模式.•在 SIP-T 中提出在 SIP message body 部份 (multiparts), 採用 ISO-10646 十六進位碼的 MIME 格式包裝, 來載送 ISUP 或 QSIG 訊息. 包裝的方式寫在 RFC 3204 - MIME media types for ISUP and QSIG Objects

•QSIG is the analogous signaling protocol used between PBXs to support calls within private telephony networks.

•SIP INFO 訊息也可以在電話中隨時傳送 PSTN 產生的一些訊息.•VoIP 若要成功, 與 SS7 的互動是非常重要的一環.

104

104

Interworking with H.323

SIP-H.323 interworking gateway

Interworking Gateway

H.323Endpoint

SIPUserAgent

SIP

SIP

H.323Signaling

H.323Signaling

H.323 endpoint

H.323gatekeeper

SIP Client

SIP Server

•由 SIP-H.323 Interworking group 定義的 standard draft “draft-agrawal-SIP-h323-interworking-reqs-07.txt”, 已在 2001 Feb. 送到 IESG, 希望能成為 Information RFC. 目前最新版是 version 7, 在 2005 Jan 5 從approved-announcement sent”狀態送到 RFC Ed Queue 這個狀態中, 如果順利下一個狀態便會是 RFC Editor State.•Interworking gateway 做為兩個 protocols 的轉譯器.

•在 SIP 端, 可能本身就要是 SIP registrar, 也可能包含 proxy 的功能.•在 H.323 端, 可能本身就要是 gatekeeper.

105

105

INVITETo: Terminal@H323.net

c=IN IP4 123.45.6.7m=audio 8000 RTP/AVP 0

Setupfaststart [logical chan info = G711 Tx,G711 RX 123.45.6.7:8000

Alerting

180 (Ringing)

Connectfaststart [logical chan info = G711 Tx,

G711 RX 123.67.8.9:2000200 (OK)To: Terminal@H323.net

c=IN IP4 123.67.8.9m=audio 2000 RTP/AVP 0

ACK

Two-way voiceTwo-way voice

SIP Client Gateway H.323 Terminal

a

d

f

b

c

e

g

h

Fast connect is used.

A Call from SIP to H.323 (1/2)

•這是一個 SIP caller 打電話給 H.323 電話. 假設使用 H.323 Fast Connect procedure, 而且不透過 gatekeeper 來控制.•如果有 gatekeeper 加入, 所有的 RAS 訊號, 在 SIP 網路都是看不到的.•SDP 的資訊會對應到 Q.931 SETUP 訊息中的 faststart元件中的 logical channel information.

•例如 RTP payload type=0 轉成 G.711 Tx (傳送), G.711 Rx (接收), SIP client 的 IP=123.45.6.7 與 8000 port, 放在 Rx 之後.

•在這個例子中, H.323 terminal 透過 Connect 訊息傳回 logical channel 的資料, 在 gateway 包在 200 OK 內送到 SIP client.•如果 H.323 terminal 選擇放在 Altering 或其他像 Call Proceeding 訊息送回logical channel information, gateway 可以很簡單的將相關資料存起, 等到200 OK 才一起送回 SIP client.•由於兩端都得到對方的 IP:port, RTP payload type, 所以 media 是可以不經過 Gateway 傳送.

106

INVITETo: Terminal@H323.net

c=IN IP4 123.45.6.7m=audio 8000 RTP/AVP 0

200 (OK)To: Terminal@H323.net

c=IN IP4 123.67.8.9m=audio 2000 RTP/AVP 0

Setupfaststart [logical chan info = G711 TX,G711 RX 123.45.6.7:8000

Connect (no faststart)

Terminal Capability SetG711 TX. G711 RX

Terminal Capability Set Ack

Terminal Capability SetG711 TX, G711 RX

Terminal Capability Set Ack

Open Logical Channel

Open Logical Channel AckRX=123.67.8.9:2000

ACKOpen Logical Channel

Open Logical Channel AckRX=123.45.6.7:8000

SIP Client Gateway H.323 Terminal

H.225.0

H.245

SIP

a

b

c

d

e

f

g

h

i

j

k

l

m

A Call from SIP to H.323 (2/2)

Fast Connect is not used.

•假設 H.323 terminal 不會使用 H.323 Fast Connect procedure, 整個流程就會非常煩複.•Q.931 SETUP 訊息中可以包括 faststart元件中的 logical channel information. 但 H.323 terminal 看不懂, 也無法用 Connect 傳回相關參數.因此當 H.323 電話被接起後, 送出 Connect, 接著必須以 H.254 交換 capacity, 接著傳送要建立起 H.323 terminal 到 gateway 的單向 media 的訊號. Gateway 此時送回 200 OK 給 SIP client. 最後傳送要建立起 gateway 到H.323 terminal 的單向 media 的訊號.

107

107

Setupfaststart [logical chan info = G711 TX,G711 RX 123.67.8.9:2000

SIP ClientGatewayH.323 Terminal

a

b

c

d

e

f

g

h

INVITETo: User@SIP.net

c=IN IP4 123.67.8.9m=audio 2000 RTP/AVP 0

180 (Ringing)

Alerting

200 (OK)To: User@SIP.net

c=IN IP4 123.45.6.7m=audio 8000 RTP/AVP 0

Connectfaststart [logical chan info - G711 TX

G711 RX 123.45.6.7:800

ACK

Two-way voiceTwo-way voice

A Call from H.323 to SIP with Fast Connection

•這是一個 H.323 打電話給 SIP 電話. 假設使用 H.323 Fast Connect procedure, 而且不透過 gatekeeper 來控制.•Q.931 SETUP 訊息及 H.225 的 session 資訊會對應到 SIP 與 SDP. •180 Ring 可對應到 Alerting.•SIP 用 200 OK 將相關資料送回. 再轉成 Connect.•假設 H.323 terminal 不會使用 H.323 Fast Connect procedure, 整個流程就會非常煩複.•如果 Q.931 SETUP 訊息中沒有 faststart元件與 logical channel information. 所以Gateway 會使用預設值來設定 INVITE 中的 session capacity. 之後透過 H.245 交換的資訊, 會透過 UPDATE 通知 SIP client 修改原先 media 的設定. 請參考課本圖5-33.

108

108

Summary

The future for signaling in VoIP networksSimple, yet flexibleEasier to implementFit well with the media gateway control protocols

SIP is the protocol of choice for the evolution of third-generation wireless networks.

SIP-based mobile devices will become availableSIP-based network elements will be introduced within mobile networks.