Thiết lập và giải phúng cuộc gọi SIP

II. So sỏnh chuyển mạch mềm và chuyển mạch truyền thống

3.7. Thiết lập và giải phúng cuộc gọi SIP

Quỏ trỡnh thiết lập và giải phúng cuộc gọi SIP được mụ tả trong hỡnh 5.2:

Trong mạng SIP quỏ trỡnh thiết lập và giải phúng một phiờn kết nối thường gồm 6 bước sau:

1 Đăng ký, khởi tạo và định vị dịch vụ đầu cuối.

2. Xỏc định phương tiện của cuộc gọi, tức đa ra một miờu tả phiờn mà đầu cuối được mời tham dự.

3. Xỏc định mong muốn của đầu cuối bị gọi, trả lời hay khụng. Phớa bị gọi phải gửi bản tin xỏc nhận chấp nhận cuộc gọi hay từ chối.

4. Thiết lập cuộc gọi.

5. Thay đổi hay điều khiển cuộc gọi (thớ dụ nh chuyển cuộc gọi). 6. Giải phúng cuộc gọi.

Chương IV: BẢN TIN SIP

SIP là giao thức dạng văn bản sử dụng bộ ký tự ISO 10646 trong mó húa UTF-8 (RFC 2279). Điều này tạo cho SIP tớnh linh hoạt, mở rộng và dễ thực thi cỏc ngụn ngữ lập trỡnh cấp cao như Java,... Cỳ phỏp của SIP gần giống với giao thức HTTP, nổ cho phộp dựng lại mó và đơn giản húa sự liờn kết của cỏc mỏy chủ SIP với cỏc mỏy chủ. Web Tuy nhiờn, lưu ý rằng SIP khụng phải là một dạng mở rộng của HTTP. Khỏc với HTTP, SIP cú thể sử dụng giao thức UDP.

Bản tin SIP cú thể là một yờu cầu từ Client tới một Server hay đú là một đỏp ứng tử Server gửi lại Client.

SIP-message = Request/ Response

Cả hai bản tin yờu cầu và đỏp ứng đều cú một khuụn dạng chung. Cả hai loạt đề gồm một dũng khởi đầu (start-line), một hay nhiều tiờu đề, một chỉ thị kết cuối tiờu đề và một tựy chọn thõn bản tin:

Generic - message = start-line * message-header [message-body]

+ start - line = Request-line/ Status-line (general-header)

+ message – header = Request-heade/ Response header/ Entity-header

4.1. Bản tin yờu cầu Request

Bản tin Request (yờu cầu) cú khuụn dạng nh sau:

Request = Request-line *(General-header/ Request-header/ Entity-header) CLRF (ký tự xuống dũng)

[message-bodyl]

Ta thấy bản tin Request gồm hai phần cơ bản: Request-line (dũng yờu cầu) và header (phần tiờu dề):

Thành phần Request-line bắt dầu bởi một cờ chỉ thị, tiếp theo là Request- URI và phiờn bản sử dụng, kết cuối bởi CRLF. Cỏc thành phần được phõn cỏch bởi ký tự SP.

Request-line = Method SP Request-URI SP Sip-Version CRLF

1 ) Method (Chỉ thị SIP)

Cỏc chỉ thị bắt dầu khụng được hỗ trợ bởi Proxy Server hay Redirect Server. Với SIP người ta định nghĩa 6 chỉ thị sau:

Method= INVLTE/ACK/OPTION/ BYE/CANCEL/REGISTER

a) INVITE: Chỉ thị INVITE 'hụng bỏo rằng User hoặc dịch vụ được mời tham gia vào một phiờn hội thoại. Một Server sẽ tự động trả lời một lời mời tham gia hội thoại nếu Uscr đó sẵn sàng tham gia bằng đỏp ứng 200 OK.

Nếu như một UA (User Agent) nhận được một yờu cầu INVLTE cho “Call – leg” với số Cscq cao hơn cỏc INVITE trước cú cựng Call-LD, nó sẽ kiểm tra cỏc từ định danh phiờn bỏn. Nội dung của phần miờu tả phiờn sẽ được xem xột nếu nú muốn thay đổi, UA phải xem xột cỏc trường tiờu đề cho việc thay đổi, UA phải cập nhật những trạng thỏi nội bộ hoặc những thụng tin phỏt ra như kết quả tiờu đề đú. Nếu miờu tả phiờn thay đổi UAS phải diều chỉnh lại cỏc thụng số của phiờn hội thoại cho phự hợp sau khi yờu cầu User xỏc nhận. Chỉ thị này được đa ra bởi SIP Proxy, Redirect Server và UAS cũng nh Client.

b) ACK: Yờu cầu ACK xỏc nhận Client đó nhận được đỏp ứng cuối cựng cho yờu cầu INVLTE (ACK chỉ sử dụng cho yờu cầu INVITE). Khi UAC chấp nhận đỏp ứng 2xx, tất cả cỏc đỏp ứng cuối cựng khỏc của Proxy đầu tiờn hay của UAC đầu tiờn nhận được trả lời. Trường "Via" được đa vào Host để phỏt ra yờu cầu ACK sau khi UAC nhận được một đỏp ứng 2xx hoặc Proxy đầu tiờn nhậnđược một đỏp ứng non-2xx.

Yờu cầu ACK cú thể chứa một thõn bản tin (message body) với phần miờu tả phiờn cuối cựng cho User được gọi. Nếu nh thõn bản tin ACK rỗng, User được gọi sẽ sử dụng phần miờu tả phiờn trong yờu cầu INVITE.

Một Proxy Server nhận một yờu cầu ACK sau khi gửi đi cỏc đỏp ứng 3xx, 4xx, 5xx hay 6xx phải quyết định ACK là của nú hay là của cỏc UA hoặc Proxy Server phớa bờn kia. Quyết định đú dựa trờn việc xem xột thẻ địa chỉ trong trường "To". Nếu thẻ của trường "To" trong ACK phự hợp với thẻ địa chỉ trong trường tiờu đề "To" của đỏp ứng và cỏc trường tiờu đề "From", "Call-LD", "Cseq" của đỏp ứng phự hợp với cỏc trường của ACK thỡ chứng tỏ rằng ACK là dành cho Proxy Server.

Chỉ thị này phải được đưa ra bởi SIP Proxy, Redirect Server, UA cũng nh

Client.

c) OPTION: Chỉ thị OPTION dựng để hỏi về khả năng của SIP Server. Nếu một Server cú khả năng liờn lạc với User thỡ cú thể đỏp ứng lại yờu cầu OPTION bằng một tập hợp cỏc khả năng của nú. Chỉ thị này được đa ra bởi SIP Proxy, Redirect Server, UA, Register, Client.

d) BYE: UAC sử dụng chỉ thị BYE để thụng bỏo cho Server rằng nú muốn giải phúng cuộc gọi. Nếu yờu cầu INVLTE chứa một tiờu đề "Contact", User được gọi phải gửi yờu cầu BYE tới địa chỉ trong trường "Contact". Chỉ thị này phải được đa ra bởi một Proxy Server và khụng được phỏt ra bời Redirect Server và UAS.

e) CANCEL: Yờu cầu CANCEL được dựng để hủy bỏ một yờu cầu sắp thực hiện với cựng giỏ trị trong cỏc trường Call-LD, From, To và Cseq của yờu cầu đú.

UAC hay Proxy Client cú thể phỏt ra một yờu cầu CANCEL tại mọi lỳc. Proxy trong trường hợp đặc biệt cú thể gửi một yờu cầu CANCEL tới đớch mà khụng trả lại một đỏp ứng cuối cựng sau khi nú đó nhậnđược cỏc đỏp ứng 2xx hay 6xx cho một hay nhiều yờu cẩu tỡm kiếm song song (Parallel Search).

Cỏc trường Call-LD, Cseq, To, From trong CANCEL đều giống nh trong yờu cầu ban đầu yờu cầu mà nú muốn hủy bỏ). Tuy nhưiờn, để Client phõn biệt được cỏc đỏp ứng cho yờu cầu CANCEL với cỏc đỏp ứng cho yờu cầu ban đầu thỡ thành phần Cseq Method sẽ được thiết lập trong CANCEL.

Khi một UAS nhậnđược yờu cầu CANCEL, nú khụng phải phỏt ra một đỏp ứng 2xx cho yờu cầu hủy bỏ ban đầu

Redirect Server và UAS khi nhận được một yờu cầu CANCEL sẽ đỏp ứng bằng một trạng thỏi 200 nếu như tồn tại giao dịch SIP hoặc trạng thỏi 48 1 nếu khụng tồn tại giao dịch.

Chỉ thị này được phỏt ra bởi tất cả cỏc loại SIP Proxy Server.

f) REGLSTER: Chỉ thị REGLSTER được dựng để dăng ký danh sỏch địa chỉ của User trong trường tiờu đề To với SIP Server. UA cú thể đăng ký với một Local Server lỳc khởi dộng bằng cỏch gửi đi một yờu cầu REGISTER tới tất cả cỏc SIP Server cú địa chỉ đa hướng là "Sip. Mcasr. nẹt".

Client trỏnh việc gửi đi một đăng ký mới cho tới khi nú nhận được đỏp ứng trả lại từ Server cho đăng ký trước dú. Client cú thể đăng ký với nhiều dịch vụ khỏc nhưau và nú nhất thiết phải sử dụng cỏc giỏ trị Call-ID khỏc nhau

í nghĩa của trường tiờu đề yờu cầu REGISTER được định nghĩa dưới đõy. Ta cú thể định nghĩa địa chỉ bản ghi (Address of record) nh địa chỉ SIP.

To: Trường tiờu đề To chứa dịa chỉ bản ghi trong suốt quỏ trỡnh bản đăng ký được tạo ra và cập nhật.

From: Trường tiờu đề From chứa địa chỉ bản ghi của người muốn đăng ký.

Requetl-URI: Trường Request-URI chỉ ra đớch của yờu cầu đăng ký. Núi chung cỏc trường trong miền Request-URL và To đều cú giỏ trị giống nhau.

Call- /D: Tất cỏ cỏc đăng ký từ cựng một User đều sử dụng một giỏ trị tiờu đề Call-ID.

Cseq: Cỏc đăng ký với cựng một giỏ trị Cau-LD phải được tăng chỉ số Cseq lờn một giỏ trị.

Colltact: Yờu cầu dăng ký cú thể chứa một trường tiờu dề Contact. Nếu nh

yờu cầu khụng chứa tiờu dề Contact, bản đăng ký sẽ giữ nguyờn khụng đổi. Server cú thể trả lại danh sỏch đăng ký hiện tại bằng đỏp ứng 200 OK.

2) Request- URI

Trường Request-URI cú khuụn dạng theo SIP URL. NÃ thụng bỏo cho User hoặc dịch vụ về địa chỉ hiện tại. Khỏc với trường "To ' , Request-URI cú thể được ghi lại bởi Proxy. Khi sử dụng như một Request-URI, SIP URL phải chứa cỏc tham số transport- param, maddr-param, ttl-param và cỏc thành phần tiờu đề. Một Server khi nhận được một SIP URL (địa chỉ SIP) với những thành phần đú sẽ hủy bỏ chỳng trước khi tiến hành xử lý.

Điển hỡnh là, UAS thiết lập trường Request-URI và trường "To" trong cựng một SIP URL coi như khụng thay đổi trong một khoảng thời gian dài. Tuy nhiờn, nếu như UAC dành cho phớa bị gọi nhiều hướng trực tiếp, từ trường tiờu đề Contact của một đỏp ứng cho yờu cầu trước đú, trường "To" sẽ vẫn chứa thụng số "long-term", địa chỉ cụng cộng trong khi Request-URI cú thể thiết lập cỏc địa chỉ dự phũng. Proxy Server vằ Redirect Server cú thể dựng những thụng tin chứa trong trường Request-URI và trường tiờu đề của yờu cầu để quản lý cỏc yờu cầu và ghi lại trường Request-URI.

Host-post của Request-URI điển hỡnh phự hợp với một trong cỏc "Host name" của Server nhận. Nếu khụng, Server phải ủy quyền cho yờu cầu tới dịa chỉ “indicate” hoặc trả lại đỏp ứng 404 (Not found: khụng tỡm thấy) nếu nú khụng muốn hay khụng thể thực hiện được. Vớ dụ, Request-URI và "Server host name" cú thể khũng phự hợp trong trường hợp từng lửa xử lý cuộc gọi đi. Cỏch hoạt động đú giống như của HTTP Proxy.

Nếu SIP Server nhận được một yờu cầu với một URI đa ra một cấu trúc khỏc hơn SIP mà Server đú khụng hiểu được, Server phải gửi lại một đỏp ứng 400 (Bad Request). Nó phải thực hiện việc đú ngay cả khi trường tiờu đề "To" chứa một cấu trỳc mà nú khụng hiểu.

3) SIP Version (phiờn bỏn SIP)

Phiờn bản SIP (SIP version) là cỏc bản SIP được da ra cỏc lần khỏc nhau. Cả hai bản tin Request và Rcsponse đều chứa phiờn bản của SIP được sử dụng. Hiện tại phiờn bản SIP là 2.0.

4) Option tag

Thẻ tựy chọn (Option tag) được dựng dể chỉ định cỏc lựa chọn mới trong SIP. Cỏc thẻ tựy chọn được sử dụng trong trường Unsupport và Require.

Cỳ phỏp: Option-lag = token

Cỏc tựy chọn mới (new options) được dăng ký bởi tổ chức IANA (Intemet Assigned Number Authority).

Khi đăng ký thỡ cần phải cú cỏc thụng tin sau:

Tờn và mụ tả của cỏc Option. Tờn cú độ dài khụng quỏ 20 ký tự. Thụng bỏo về tổ chức cú quyền thay đổi Option.

Thụng tin liờn lạc (hũm thư hay địa chỉ Email). - Đăng ký phải được gửi tới địa chỉ: iana@Lana.crg.

Tiờu đề của bản tin Request

Trong khuụn dạng bản tin Request ta thấy cú 3 dạng trường tiờu đề của bản tin Request: General-header, Rcqucst-headcr và Entity-header

General-header Acept | Acept-encoding | Acept-language | Call-id | Contact | Cseq | Date | Encryption | Expires | From | Record-route | Timestamp | To | Via Request-header Authorization | Contact | Hide | Max-forwards | Organization . | Priority | Proxy-authorization | Proxy- Require | Route | Require | Respone-Key | Subject | User-agent

Entity-header = Content-Encoding : | Content-length | Content-type