[JAIN SIP] Chương 13 : SIP Proxy

Chương 13 : SIP Proxy

I. Định nghĩa SIP Proxy :

SIP Proxy server là một thực thể trung gian giúp định tuyến các request đến UAS và các response đến UAC hay thông qua một proxy khác. Một request có thể đi qua nhiều proxy trước khi đến UAS. Mỗi proxy sẽ  quyết định sự định tuyến và chỉnh sửa request trước khi đến UAS hay proxy khác. Trong khi đó, các response phải đi qua đúng các proxy như request đã đi qua, nhưng theo thứ tự ngược lại.

SIP Proxy thực hiện quá trình định tuyến dựa trên sự thay đổi giá trị của trường Request-URI trong mỗi request. Khi  Proxy nhận 1 request, chỉnh sửa giá trị của trường Request-URI và một số các trường khác trong request, sau đó gởi request đến 1 địa chỉ đích khác.

Một proxy có thể hoạt động theo mô hình stateful hay stateless:

-  Đối với mô hình stateless, proxy hoạt động như một thực thể chuyển tiếp đơn giản. Nó chỉ thực hiện định tuyến để chuyển tiếp mỗi request và loại bỏ hoàn toàn thông tin về request mỗi khi đã chuyển đi.  

- Đối với mô hình stateful, nó cũng thực hiện quá trình định tuyến request, đồng thời lưu lại thông tin về mỗi request đầu vào và các request gởi đi (request gởi đi là kết quả của quá trình xử lý từ request đầu vào). Nó sử dụng những thông tin này để tác động đến quá trình xử lý các request tương lai thuộc cùng dialog với request này. Một tính năng đặc biệt của stateful là có thể lựa chọn  "fork" một request, đó là định tuyến request đến nhiều đích đến khác nhau.  

Proxy hoạt động theo mô hình stateful được gọi là "Transaction Stateful Proxy", ngược lại Proxy hoạt động theo mô hình stateless được gọi là "TransactionStateless Proxy".

II. Transation Stateful Proxies :

Một transaction stateful proxy được gọi ngắn gọn là “stateful proxy”. Stateful proxy bao gồm các thành phần : server transaction, client transaction và proxy core. Một server transaction được kết hợp với một hay nhiều client transaction, nhiệm vụ của proxy core là quản lý các server transaction và client transaction.

Stateful proxy tạo 1 server transaction mới đối với 1 request mới và tạo ra một hay nhiều client transaction đối với các response dành cho request này. Những thông tin này được lưu lại trong Proxy Core, được gọi là 1 "Response Context".

1. Cách xử lý transaction của Stateful proxy:

Các cách xử lý transaction của stateful proxy được thực hiện như sau:

- Sip proxy gởi đến UAC "100 Trying" response ngay khi nó nhận được INVITE request.

- Nếu INVITE transaction được UAS trả lời với 200 OK response, proxy bảo đảm sẽ chuyển response đến được client.

- Nếu INVITE transaction được trả lời với 4xx, 5xx, 6xx thì stateful proxy phải tạo ra ACK dành cho response này. Điều này có nghĩa là các response được bảo đảm gởi đến client.

- Khi nhận 1 CANCEL request, stateful proxy sẽ tạo ra “487 Terminated” và “200 OK” response để kết thúc UAC trước, sau đó tạo ra CANCEL request mới và gởi đến UAS .

2. Cách hoạt động của stateful proxy:

a. Đối với Request (trừ ACK và CANCEL request):

Bất cứ khi nào stateful proxy nhận 1 request mà chưa có server transaction, Proxy sẽ tạo 1 server transaction mới và sau đó xử lý request trong proxy core. Sau đây là các bước trong quá trình xử lý Request trong Proxy, trừ CANCEL và ACK request – quá trình xử lý CANCEL và ACK request được miêu tả sau.

* Bước 1: Xác định tính hợp lệ của request :

Khi proxy nhận message, trước tiên nó sẽ kiểm tra tính hợp lệ của message. Một message hợp lệ phải thông qua các bước kiểm tra sau:

- Kiểm tra cú pháp : bắt buộc các request phải đúng cú pháp, nếu lỗi trả về "400 bad request" response.

- Kiểm tra trường Request-URI : nếu giá trị của trường Request-URI mà proxy không thể hiểu được, thì proxy sẽ loại bỏ request với "416 Unspported URI Scheme" response trả về.

- Kiểm tra Max-Forwards : trường Max-Forwards được sử dụng để giới hạn số proxy mà Sip request có thể đi qua. Nếu request không chứa trường Max-Forwards hoặc giá trị lớn hơn 0, sự kiểm tra này được thông qua. Còn nếu giá trị trường Max-Forwards bằng 0, proxy trả về "483 - too many hops" response.

- Kiểm tra trường Proxy-Require : Trường Proxy-Require chỉ ra các tính năng mà yêu cầu được xử lý đặc biệt ở Proxy. Trường Proxy-Require chứa một hay nhiều tham số option-tags mà Proxy không hiểu được, sẽ trả về "420 - Bad Extension" response và chứa danh sách các option-tags mà proxy không hiểu được. Trường Proxy-Require không bắt buộc phải có trong request.

- Kiểm tra trường Proxy-Authorization : trường Proxy-Authorizaion mang theo các sự ủy quyền của UA trong request gởi đến Proxy. Nếu các giá trị trong trường này Proxy không hiểu, sẽ trả về "407 Proxy Authenication Required" response. Dưới đây là ví dụ về trường Proxy-Authorization yêu cầu proxy thực hiện trong quá trình chuyển tiếp request :

Request trên yêu cầu chỉ được gởi đến username là thanhnguyen, domain là niit.com và địa chỉ là thanhnguyen@niit.com .

* Bước 2:  Xử lý thông tin định tuyến.

Request đến proxy mà có giá trị đầu tiên trong trường Route chứa địa chỉ của Proxy này.  Tình trạng này có thể xảy ra bởi các proxy trước đó hoặc UAC đã đẩy địa chỉ của proxy này vào trường Route để bắt buộc request phải đi qua Proxy này. Trong trường hợp này, Proxy sẽ xóa giá trị này bởi vừa được sử dụng và không sử dụng lại nữa.

* Bước 3: Xác định tập đích đến của request

Proxy sẽ tính toán đích đến kế tiếp của request dựa trên tập các đích đến được định nghĩa trước trong request hay được lấy từ location service. Mỗi địa chỉ trong tập đích đến là 1 URI.

Nếu Request-URI không cung cấp đủ thông tin cho proxy để xác định được tập đích đến, proxy sẽ trả về "485 Ambiguous" response.

* Bước 4: Chuyển request đến đích :

Khi đã xác định được tập đích đến, tức là request này sẽ được chuyển đến nhiều vị trí khác nhau. Proxy có thể xử lý mỗi đích đến theo thứ tự dựa trên giá trị của tham số qvalue của trường Contact. Nếu Contact không tồn tại qvalue thì mỗi đích đến được xử lý song song.   

Đối với mỗi đích đến, proxy chuyển request theo các bước sau:

- Sao chép request : đầu tiên, proxy sao chép request nhận được. Bản sao này được gọi là request copy, nó chứa tất cả các header của request nhận được. Proxy không được thay đổi thứ tự các header và không được thêm, xóa hay chỉnh sửa message body của request copy.

- Cập nhật Request-URI : Request-URI của request mới được thay thế bằng URI đích đến.

- Cập nhật trường Max-Forwards : Nếu request copy chứa trường Max-Forwards, proxy phải giảm giá trị này đi 1. Nếu request copy không chứa trường Max-Forwards, proxy phải tạo trường này và thiết lập giá trị mặc định là 70.

- Thêm giá trị cho trường Record-Route (không bắt buộc) : nếu proxy mong muốn giữ nguyên đường dẫn đối với các request tương lai trong dialog (dialog được tạo bởi request đầu vào) - tức là bắt buộc các request tương lai này cũng phải đi qua proxy này, phải chèn địa chỉ của proxy vào trường Record-Route của request copy.

- Thêm các trường phụ trợ (không bắt buộc) : proxy có thể định nghĩa các trường phụ trợ vào request copy.

- Xử lý thông tin định tuyến : Nếu proxy có chính sách bắt buộc một request cần phải đi qua một tập proxy khác, thì proxy này sẽ đẩy các URI của tập proxy vào trường Route của request copy.

-  Xác định địa chỉ, port và giao thức truyền kế tiếp.

-  Thêm giá trị cho trường Via : URI của Proxy được chèn vào trường Via của request copy.

-  Chuyển request copy : Proxy tạo ra 1 client transaction mới và chuyển request copy đến đích đến.

-  Thiết lập timer C : Khởi động timer (được gọi là Timer C) để xử lý trường hợp một INVITE không bao giờ có final response. Proxy cập nhật timer ngay khi nó nhận 1 provisonal response.

b. Cách xử lý Response:

Khi Proxy nhận được 1 response, đầu tiên proxy phải xác định client transaction phù hợp với response. Nếu không tìm thấy client transaction phù hợp, proxy phải xử lý response như stateless proxy (stateless proxy được miêu tả bên dưới). Ngược lại, nếu tìm thấy, client transaction này sẽ quản lý  response này. Sau đó, client transaction gởi nó đến proxy core và xử lý. Các bước chính trong quá trình xử lý response trong proxy core:

- Tìm response context và xác định server transaction nào được liên kết với client transaction này.

- Cập nhật timer C đối với provisional response. Đối với INVITE transaction, nếu response là provisional response với status code từ 101-> 199, proxy phải điều chỉnh lại timer C đối với client transaction này. Timer C có thể được điều chỉnh 1 giá trị khác, nhưng giá trị này phải lớn hơn 3 phút.

- Xóa giá trị đầu tiên của trường Via trong response.

- Nếu response nhận được là provisional response (trừ 100 - trying) hoặc 2XX, proxy phải gởi nó ngay lập tức. Nếu tất cả các client đã kết thúc nhưng không có final response được gởi từ server transaction, proxy sẽ tìm response tốt nhất giữa tất cả các response nó nhận được và gởi nó đến client thông qua server transaction.  

- Server transaction trong response context chịu trách nhiệm gởi response này.

- Mỗi khi 1 final response được gởi đến server transaction. Proxy phải xóa bỏ tất cả các nhánh khác mà chưa nhận được final response. Do đó, proxy tạo ra các CANCEL request dành cho mỗi nhánh đó.

c. Cách xử lý CANCEL request:

Khi stateful proxy nhận 1 CANCEL request, nó tạo ra 1 Server transaction mới và proxy core tìm kiếm các response context đang tồn tại trên proxy có server transaction chứa INVITE request mà CANCEL request này cần kết thúc. Khi đã tìm thấy, proxy gởi trở lại "200 OK" response đến client, và tạo ra CANCEL request mới cho tất cả các transaction có trong response context này.

d. Cách xử lý ACK request:

Có 2 trường hợp xử lý đối với ACK request:

- Trường hợp 1:  Proxy nhận 1 ACK request phù hợp với server transaction đang tồn tại. Vì thế, ACK request này được xử lý tại server transaction mà không cần chuyển đến proxy core.

- Trường hợp 2: Proxy nhận 1 ACK request không phù hợp với server transaction đang tồn tại. Trong trường hợp này, proxy core không tạo ra bất kỳ server transaction mới nào, nhưng sẽ gởi ACK request này dựa trên các qui tắc được miêu tả trong phần sau.

IV. Transaction Stateless Proxy:

Một Transaction Stateless Proxy còn được gọi là stateless proxy. Nó nhận request trực tiếp từ server transport, xử lý chúng dựa trên thông tin được chứa trong request, và gởi chúng đến client transport.  Tương tự, stateless proxy nhận response trực tiếp từ client transport và gởi chúng đến server transport.

Một Stateless proxy không giữ bất cứ trạng thái nào. Nó loại bỏ thông tin về message mỗi khi message được gởi đi.

 Cách hoạt động của Stateless Proxy:

Stateless proxy chẳng có khái niệm về transaction. Nó không lưu giữ thông tin, vì thế nó không giữ bất kỳ response context nào cả. 1 stateless proxy định tuyến các request và response chỉ dựa trên các tham số hiện diện trong message nhận được. Stateless proxy chỉ đơn giản là chuyển tiếp đi message.

Dưới đây là bảng liệt kê sự khác nhau về cách xử lý proxy core của stateless proxy và stateful proxy:

+ Stateless proxy chỉ có thể chuyển các request đến 1 đích đến duy nhất.

+ Sateless proxy không thể phân biệt đâu là request gốc hay request được truyền phát lại.

+ Trong stateless proxy, các request nhận được không đưa đến proxy core để tạo ra server transaction.

+ Stateless proxy không thực hiện xử lý đặc biệt nào đối với CANCEL request.

+ Để gởi đi các response, stateless proxy sử dụng giá trị của trường Via để xác định bước truyền kế tiếp.