星期日, 2月 17, 2019

SIP INFO

SIP Method INFO 是在 Dialog 內交換訊息。

傳統 SIP INFO 定義在 RFC 2976,運用在一些標準或私訂的應用 (legacy INFO usage):
  • RFC 3372 在 SIP 信體放 ISDN User Part (ISUP) 訊息,ITU-T 和 3GPP 也有類似規範。
  • ECMA-355 在 SIP 信體放 QSIG。
  • 作為 Media Server Control Markup Language (MSCML) (RFC 5022) 的傳送機制,使用 Require 信頭欄位的一個 option-tag 來確保接收端了解 INFO 內容。
  • 作為 Media Server Markup Language (MSML) (RFC 5707) 的傳送機制。
  • 請求快速影片更新,目前基於 RTCP 的標準機制定義在 RFC 5168。
  • 傳送 DTMF 音,所有機制都是私訂未標準化。

傳統 INFO 無法表示支援哪些應用和傳送的資訊是哪種,通常需要靜態設定,而有相容互通問題。

RFC 6086 導入 Info Package 機制,新增兩個信頭欄位 -- Recv-Info 和 Info-Package。Recv-Info 告訴對方可接受哪些 Info Package。Info-Package 信頭欄位用在 INFO 請求來表示使用哪一個 Info Package。沒有 Info-Package 的 INFO 請求則使用傳統 SIP INFO。另有 Info Package 規範定義如何應用,名稱可以註冊到 IANA。

Info Package 機制

Info-Package 信頭欄位參數

INFO 請求信體可放應用的資訊,可以是單一 MIME 類型或 multipart [RFC5621 "Message Body Handling in the SIP"]。Info Package 的 INFO 請求的信體由 Content-Disposition 信頭欄位值的 Info-Package 標示。Info Package 的 INFO 回應不能有信體。

沒定義傳送順序機制,可依賴 CSeq 信頭欄位偵測順序是否正確。如果特定應用需要額外傳送順序機制,在關聯的 Info Package 定義。

星期六, 2月 16, 2019

SIP 回應碼

SIP 回應碼 (Response Code, Status-Code) 用在 SIP 回應的頭行 (狀態行、Status-Line) 第 2 個欄位,有 3 位數字。回應碼分成暫時回應 (Provisional Response) 和最後回應 (Final Response)。依第 1 位數字分類:
回應碼分類說明
1xx暫時回應 (SIP transaction 進行中)收到請求,還在處理中。
2xx最後回應
(結束 SIP transaction)
Success請求成功。
3xxFailRedirection請改洽新位址。
4xxRequest Error特定 Server 的回應請求失敗,可能語法有誤或無法在此 server 提供。
5xxServer Error有效的請法無法在此 server 提供。
6xxGlobal Failure請求無法在任何 server 提供。

回應碼適用大部分 HTTP/1.1 回應碼,6xx 類是 SIP 新增,完整列表可見 IANA SIP 參數 登記的回應碼。每個回應碼會有對應的預設 Reason-Phrase。

UAC 必須能處理每個 class 的 x00 和 183,不認得的最後回應 MUST 當作同 class 的 x00 處理,不認得的暫時回應當作 183 Session Progress 處理。[RFC3261 8.1.3.2]

Provisional 1xx

暫時回應 (Provisional Response),表示還在進行中,要再等最後回應。

如果預期還要 200 ms 以上才會有結果,先送 1xx 回應。 可包括信體,如含 session 描述。

1xx 回應並不會可靠地傳送,不會讓 UAC 送 ACK。使用 PRACK 可可靠傳送暫時回應。

100 Trying

嘗試中。表示下一站 Proxy 已經收到請求,一些未知的動作正在進行中 (例如:資料庫查詢中),和其它暫時的回應一樣會停止 UAC 重傳 INVITE。但不同於其它暫時的回應,stateful proxy 不回送 100 Trying。

180 Ringing

振鈴中。被叫端用戶正在響鈴,一般主叫端需要產生回鈴音。

一般不含 SDP,需要主叫端自己產生回鈴音。

181 Call Is Being Forwarded

轉接中。可用來表示呼叫已經轉送到不同的目的地。

182 Queued

排隊等候中。Reason-Phrase 可提供更多細節,例如「5 calls queued; expected waiting time is 15 minutes」,可發多次更新等候狀態。

183 Session Progress

呼叫進行中 。不清楚被叫是否正在響鈴或是其它狀態,可在 Reason-Phrase 信頭欄位、或信體提供更多資訊。

UAC 必須能處理 183,不認得的暫時回應當作 183 處理。[RFC3261 8.1.3.2]

一般會含 SDP,在接通前建立不收費的 early-media,由局端提供音訊,可能應用:

  • 彩鈴,可能是不同的回鈴音、或音樂。(該用 180?)
  • 錯誤語音,「您撥的號碼錯誤,請察明後再撥」、「您撥的號碼通話中,請稍後再撥」等。
  • IVR。

early-media 需要 INVITE 提供 SDP early-offer 才能送到主叫端,如果 INVITE 沒提供 SDP 呢?回 503?

P-Early-Media header

https://thanhloi2603.wordpress.com/2017/08/05/sip-180-vs-183-vs-early-media/

待讀:https://www.ietf.org/archive/id/draft-ietf-sip-183-00.txt

Successful 2xx

請求成功。

200 OK

請求成功,附帶回傳的資訊視請求使用的 method。

204 No Notification

成功,但沒有其它 Notification,用在 SUBSCRIBE。

Redirection 3xx

提供可能滿足呼叫的用戶新位址或服務。

300 Multiple Choices

多重選擇

301 Moved Permanently

已永久遷移。受話端不再使用 Request-URI 上的位址,應該改嘗試 Contact 信頭欄位給的新位址。
發話端應該更新自己紀錄的相關資料 (如電話簿),改用新位址。

302 Moved Temporarily

暫時遷移。

305 Use Proxy

請改用代理伺服器存取。UAS 回應要求的資源必須透過給定在 Contact 欄位的 proxy 存取。

380 Alternative Service

有另外的服務。呼叫失敗,但可用說明在訊息體的另外服務。

Request Failure 4xx

來自特定 server 失敗的回應 (到其它 server 可能成功)。UAC 不應該重試沒修改的相同請求。

400 Bad Request

不當請求。請求由於 syntax 錯誤而無法處理。Reason-Phrase 應該要指出 syntax 問題細節,例如「Missing Call-ID header field」。

401 Unauthorized

未授權

402 Payment Required

要求付費

403 Forbidden

禁止

404 Not Found

用戶找不到。

405 Method Not Allowed

方法不允許。Request-URI 指定的位址不允許請求的 method 。必須包含 Allow 信頭欄位列出指定的位址允許的 method。

406 Not Acceptable

不可接受

407 Proxy Authentication Required

需要代理伺服器授權

408 Request Timeout

呼叫超時:在預定時間內無法找到用戶

410 Gone

已消失:用戶曾經存在,但已從此處消失

413 Request Entity Too Large

呼叫實體過大

414 Request-URI Too Long

呼叫 URI 過長

415 Unsupported Media Type

不支援的媒體類型。請求的信體格式不支援,*必須* 在 Accept、Accept-Encoding、或 Accept-Language 回可接受的列表。

UAC 收到回應可再依據這些信頭欄位重試。

416 Unsupported URI Scheme

不支援的URI方案

420 Bad Extension

421 Extension Required

423 Interval Too Brief

時間間隔過短

480 Temporarily Unavailable

暫時不可使用。用戶不在 (例如沒登入、啟用「勿干擾」(do not disturb)。可加 Retry-After 表示適當的再撥時間。用戶可能有其它聯繫方式。應該在 Reason-Phrase 表示更精確原因,如為什麼用戶不在。
也可能是 redirect 或 proxy server 沒有可用的轉送位置。

481 Call/Transaction Does Not Exist

通話不存在。

482 Loop Detected

偵測到迴圈。

483 Too Many Hops

經由過多。

484 Address Incomplete

地址不全。

485 Ambiguous

模糊不清。

486 Busy Here

受話端在這忙線中。回應可加 Retry-After 說明適當的再撥時間。受話端可能有其它聯繫方式,例如 voice mail,否則該用 600 Busy Everywhere。

487 Request Terminated

請求已結束。請求已經由 BYECANCEL 結束。487 不會用在回應 CANCEL。

用在 re-INVITE 需要掛斷嗎?

488 Not Acceptable Here

此處不可接受。

491 Request Pending

已經有待處理的 re-INVITE 進行中。
RFC 3261 新增,處理雙方同時互送 re-INVITE 的碰撞 (glare) 情況。

493 Undecipherable

無法解讀。

Server Failure 5xx

500 Internal Server Error

伺服器內部錯誤。

501 Not Implemented

未實作。

502 Bad Gateway

閘道器錯誤。

503 Service Unavailable

服務不可使用。

504 Server Time-out

伺服器超時。

505 SIP Version not supported

SIP 版本不支援。

513 Message Too Large

訊息過長。

Global Failures 6xx

全域失敗。

600 Busy Everywhere

各處皆忙線中。回應可加 Retry-After 說明適當的再撥時間。如果受話端不想 reveal 拒答原因,使用 603 Decline 取代。已知沒其它其它聯繫方式 (如 voice mail),否則應該使用 486 Busy Here

603 Decline

受話端拒絕。回應可加 Retry-After 說明適當的再撥時間。已知沒其它其它聯繫方式。

604 Does Not Exist Anywhere

無處存在

606 Not Acceptable

不可接受。

參考

  1. RFC 3261 Section 21

星期二, 2月 12, 2019

SIP Header: Record-Route and Route

SIP 請求的過程,UAC 和每一个經過的 Proxy,攏會加一筆頂頭 Via 來紀錄自己。回應會照這Via 紀錄反過來送回。如果請求會建立 Dialog,Dialog 建立後就知道對方位址 (Contact),後續 Dialog 內請求就直送對方,免經過這些 Proxy。

Dialog 建立過程中經過的那些 Proxy 中,如果仍要參與後續 Dialog 內的 Transaction,在經手 Dialog 建立的請求時,加上一筆頂頭 Record-Route 紀錄自己。當請求到達 UAS 後,UAS 會將全部 Record-Route 按照順序紀錄成 Route Set,並複製到回應訊息。UAC 收到回應訊息時,將全部 Record-Route 依相反順序紀錄成 Route Set。之後 Dialog 內 (如 ACK、BYE、re-INVITE) 的請求,依 Route Set 順序產生 Route 信頭,並依此順序轉送。

在 Dialog 建立請求時,UAC 也可以事先設定 Route 信頭,例如 outbound proxy。

參數
  • lr (loose router):請求先照 Route 順序傳送,最後才是請求 URI。過程中 Proxy 收到後,移除應該是自己的頂頭 Route。和 loose router 相對的,是舊 SIP 的 strict routing,需要一開始把請求 URI 移為最尾的 Route,過程中一直把頂頭 Route 移到請求 URI 使用。有 lr 參數採用 loose routing,否則採用 strict routing。
  • r2=
  • ftag=
  • nat=

UAC 發請求有 Route Set 時,如果 Route Set 的第 1 个 URI 有 lr 參數,Request-URI 放 remote target URI,Route 封頭 按順序放 Route Set 並含所有參數。如果 Route Set 的第 1 个 URI 沒有 lr 參數,Request-URI 放第 1 个 Route Set 去除 Request-URI 不允許的參數,Route 封頭按順序放剩下的 Route Set 並含所有參數,最後再加上 remote target URI。

應用:

  • 作 NAT 的 proxy 需要持續作位址轉換
  • 作 accounting 的 proxy 需要知道何時 BYE 通話結束。

SIP REGISTER 可以有 Route,忽略 Record-Route。

參考來源
  1. http://lirobo.blogspot.tw/2010/10/sip-invite.html
  2. http://kamailio.org/docs/modules/stable/modules/rr.html
  3. http://tools.ietf.org/html/rfc3261

星期日, 2月 10, 2019

SIP Definitons

SIP 用詞定義

Dialog (對話)

兩個 UA 間持續一段時間的暫時 SIP 關係,由 INVITE transaction 建立,用一組 Call-ID、From tag、和 To tag 結合起來識別。在 RFC 2543 稱為 Call Leg。
  • 目前只有 INVITE 可以建立對話。
  • BYE transaction 結束對話。
  • Dialog 內 (in-dialog):由相同的 Call-ID、From tag、和 To tag 識別,每個 SIP 請求的 CSeq 是增加的。
    • re-INVITE (沒有 To tag 是要建立不同的 session)
    • INFO
  • out-of-dialog:沒有 To tag 就是 out-of-dialog 嗎?還是指不會建立 dialog 的 transaction?
  • REGISTER 請求不會建立 dialog,所以 Record-Route 沒作用。
SIP 訊息的部件,傳遞關於 SIP 訊息的資訊,由一系列信頭欄位組成。

Header Field (信頭欄位)

SIP 訊息裡信頭 (Header) 的部件。一個信頭欄位包含一個信頭欄位名稱和 0 個以上信頭欄位值,可重複信頭欄位名稱出現在多個信頭欄位行。一個信頭欄位行裡有多個信頭欄位值用「,」隔開。有些信頭欄位只能有一個信頭欄位值,而只會有一個信頭欄位行。

Header Field Value (信頭欄位值)

一個信頭欄位值是一個值;一個信頭欄位包含 0 個以上信頭欄位值。

Informational Response

跟 Provisional Response 相同。

Initiator, Calling Party, Caller (發話端):

雙端中為了建立一個新 session (和 dialog) 發出 INVITE 請求那一端。發話端
保有其發話端角色從送一開始 INVITE 建立 dialog 開始,直到 dialog 結束。

Invitation

一個 INVITE 請求。

Invitee, Invited User, Called Party, Callee (受話端)

雙端中為了建立一個新 session 接收 INVITE 請求那一端。受話端保有其受話端角色從收到 INVITE 開始直到建立的 dialog 結束。

Route Set

一份 proxy 位址表,傳送特定請求時按照順序經過。Route Set 可透過如 Record-Route 學習、由用戶或服務提供者人工設定、或其它非 SIP 機制等設定。

Server

一個 network element,接收請求並回送回應來提供服務。 Server 範例有 Proxy、UAS、redirect server、和 registrar。

參考來源

RFC3261 §6

星期六, 2月 09, 2019

SDP

SDP (Session Description Protocol) 為了 session 發布、session 邀請、和其它形式多媒體 session 發起來描述多媒體 session。

SDP 定義在 RFC 4566 廢棄 RFC 2327RFC 3266

o=

<sess-version> 是 this session description 的版本號碼,用途 up to the creating tool,只要當 a modification is made to the session data 時要增加,建議使用 NTP 格式 timestamp。

應用

...
...

延伸閱讀

  • SDP simcap (RFC 3407 SDP Simple Capability Declaration)
  • RFC 4040 CLEARMODE
  • vbd