Thứ Ba, 5 tháng 8, 2014

[JAIN SIP] chương 3 : SIP MESSAGE

CHƯƠNG 3 : SIP MESSAGE
SIP là giao thức dựa trên ký tự. Có nghĩa là thông tin được trao đổi bên trong giao thức được mã hóa dưới dạng chuỗi hay ký tự. SIP messages được chia thành nhiều dòng ký tự riêng biệt được gọi là line. Mỗi Line là 1 chuỗi các ký tự nối liền nhau  và  ngăn cách với line khác bởi 2 ký tự Carriage Return (phím xuống dòng) và Line Feed (tín hiệu xuống dòng).
Có 2 loại SIP messages : requests và responses.  Cả hai loại đều có 1 Start line, 1 hay nhiều header fields (trường tiêu đề),  một empty line – chỉ ra kết thúc của header fields, và 1 message body (nếu có) .
P3_SIPMessage.png
Header fields bao gồm : field namefield value, ngăn cách nhau bởi dấu 2 chấm và kết thúc bằng ký tự xuống dòng.
Ví dụ :
To : sip:khangdang@niit.com
Contact: sip:thanhnguyen@214.25.100.2
Trong đó:  To và Contact là field name.
sip:khangdang@niit.com, sip:thanhnguyen@214.25.100.2 là field value.
Message body không bắt buộc phải có, chúng được sử dụng để chứa một vài loại thông tin khác như thông tin SDP,…
I. Start line:
1. Trong SIP requests:
start line được gọi là request line, nó chứa :
- Loại request (như : INVITE, BYE, CANCEL,…)
- Request-URI : là 1 SIP URI mà request này sẽ gởi đến.
- Protocol version (phiên bản giao thức SIP)
Tất cả được tách biệt bằng khoảng trắng.
Cấu trúc :
p2_table_cautrucStartLine.png
Ví dụ : INVITE  sip:khangdang@niit.com SIP 2.0
Trong đó: - loại request là INVITE
- Request-URI : sip:khangdang@niit.com
- protocol version : SIP 2.0
2. Trong SIP response:
start line được gọi là status line (dòng trạng thái), nó bao gồm :
- protocol version : phiên bản giao thức.
- status code : mã trạng thái.
- reason phrase : một cụm từ diễn đạt status code.
Mỗi thành phần cách nhau bằng khoảng trắng.
Cấu trúc :
p2_table_cautrucStartLineResponse.png
Vi dụ : SIP 2.0 180 Ringing
Trong đó, - protocol-version : SIP 2.0
- status –code : 180
- Reason phrase : Ringing
Dưới đây là 1 bảng miêu tả status code và reason phrase thường dùng trong SIP
p2_table_statuscodeResponse.png
II. Header field :
Header field được bắt đầu sau start line trong requests và responses, chúng cung cấp thông tin về request hay response hoặc message body mà request hoặc response chứa. Mỗi header field bao gồm 1 filename1 field value được tách biệt nhau bởi dấu hai chấm(:) .
Thứ tự trước sau của các header field trong  SIP message không quan trọng.
Ví dụ:
To : sip:khangdang@niit.com
Contact: sip:thanhnguyen@214.25.100.2
Hay Contact trước , To sau đều được cả
Contact: sip:thanhnguyen@214.25.100.2
To : sip:khangdang@niit.com
Nếu 1 header field có nhiều field value khác nhau thì các field value này được tách biệt nhau bằng dấu phẩy và thứ tự của chúng rất quan trọng.
Ví dụ :
Route: sip:proxy1.niit.com, sip:proxy2.niit.com
Header fields có thể chứa nhiều tham số (parameter), mỗi tham số bao gồm tên tham số và giá trị tham số được tách biệt nhau bằng dấu bằng =,tham số này cách biệt tham số khác hoặc field value bằng dấu chấm phẩy ; .
Ví dụ:
From: sip:khan@niit.com;tag=34522549
Chúng ta tìm hiểu về 1 số header field quan trọng:
1. From :
From header field chỉ ra địa chỉ UAC biễu diễn dưới dạng SIP URI, được lưu giữ trong location service dưới dạng Address of Record(AOR).
Ví dụ : From: sip:khangdang@niit.com , From: Khangdang Wales <sip:khangdang@niit.com>
From header field cũng chứa tham số bắt buộc tag. Tham số tag này được sử dụng cho mục đích nhận biết 1 dialog ( cuối phần này chúng tôi sẽ giải thích về Dialog, Call và Transaction).  
Ví dụ :  From: sip:khangdang@niit.com;tag=34522549
2. To
To header field là bắt buộc phải có trong mỗi SIP message, được sử dụng để chỉ ra địa chỉ AOR của người nhận.
Ví dụ: To: sip:khangdang@niit.com
To: Khangdang <sip:khangdang@niit.com>
To header field cũng chứa tham số tag không định nghĩa trong request nhưng bắt buộc phải định nghĩa giá trị tham số tag này trong response đầu tiên phản hồi request này, giá trị tham số tag của To header cùng với tag của From header được sử dụng để nhận dạng 1 dialog.
Ví dụ :  To: sip:khangdang@niit.com;tag=62527549
3. Call-ID:
Call-ID header field bắt buộc phải có trong tất cả SIP requests và responses. Nó là một phần của Dialog được sử dụng để nhận dạng call (cuộc gọi) giữa 2 UA.  Call-ID được  tạo ra bởi UAC dưới dạng chuỗi kết hợp bao gồm : chuỗi nhận dạng cộng với  host hay địa chỉ IP của UAC cách biệt nhau bằng dấu @.
Ví dụ : Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@niit.com  
*Lưu ý: Call-ID được sử dụng để nhận biết 1 call, 1 call có thể có nhiều  dialog. Tag của From được sử dụng để nhận biết 1 dialog được tạo từ UAC. Tag của To sử dụng để nhận biết 1 dialog được tạo từ UAS.  
4. Via
Via header field  ghi lại tất cả địa chỉ host hoặc IP của UAC và các proxy mà 1 request đi qua, để bắt buộc 1 response trả về cũng phải đi đúng theo con đường này nhưng theo chiều ngược lại với request.  Mỗi khi request đi qua 1 proxy sẽ tạo ra 1 Via địa chỉ proxy này vào message. Còn response sao chép tất cả Via của request, mỗi khi response đi qua 1 proxy sẽ xóa giá trị Via đầu tiên trong message.  
Via header field bao gồm 2 trường:
+  Trường sent-protocol : chứa giao thức  gởi message.
Ví dụ : SIP/2.0/UDP , SIP/2.0/TCP,…
+  Trường sent-by : chứa tên host hoặc địa chỉ IP và port nếu có.  
Các tham số dành cho Via:
+ received : Nếu request đi qua 1 proxy mà địa chỉ IP chỉ là địa chỉ mạng cục bộ. Lúc này, received sẽ chứa địa chỉ IP của NAT hay firewall proxy ( tức là địa chỉ Internet).
Ví dụ: Via: SIP/2.0/TCP 192.168.1.2; received=112.4.25.50.
Trong đó, 192.168.1.2 là địa chỉ mạng cục bộ nên received chứa địa chỉ IP internet của NAT.
+ branch : được tính toán từ hàm băm của các header : Request-URI, To, From, Call-ID và CSeq. Branch được sử dụng để nhận biết 1 transaction (cuối phần này chúng tôi sẽ giải thích dialog, call và transaction).
Ví dụ: Via: SIP/2.0/UDP 125.114.3.2:5060; branch= z9hG4bKl740ws
5. Contact:
Contact header field được sử dụng để truyền một URI (địa chỉ) nhận biết người khởi tạo request. Contact header có thể hiện diện trong request và cả response. Mỗi khi UA nhận được một Contact header , URI trong contact này sẽ được lưu giữ và sử dụng trong quá trình định tuyến các request và response bên trong 1 dialog. Ví dụ, contact header của "200 OK" response trả lời 1 INVITE, có thể cho phép ACK request và tất cả request và response tương lai trong 1 dialog được gởi trực tiếp đến các UA bằng URI trong Contact header của chính UA.
Ví dụ : Contact: <sip:thanhnguyen@115.44.23.2>
Contact header bắt buộc phải hiện diện INVITE request và 200 OK response của 1 cuộc gọi. Ngoài ra, contact cũng có thể hiện diện trong các request khác và 1XX, 2XX, 3XX, 485 responses nhưng không bắt buộc. Trong 1 vài trường hợp, URI của contact không phải là địa chỉ trực tiếp của UA. Ví dụ, UA bên trong 1 firewall, thì URI của contact phải là địa chỉ firewall.
Contact ngoài bắt buộc chứa URI, nó cũng có thể chứa tên hiển thị.
Ví dụ : Contact: ThanhNguyen <sip:thanhnguyen@115.44.23.2>


*lưu ý: Via được sử dụng để gởi response theo đúng tuyến đường của request, còn Contact được dùng cho các response và request tương lai.

6. Record-Route và Route:
Record-Route header field chứa danh sách các firewall proxy dưới dạng SIP URI mà request đầu tiên đi qua, được sử dụng để bắt buộc tất cả các request trong tương lai phải đi qua các firewall proxy có trong danh sách này.
Firewall Proxy không cho phép liên lạc trực tiếp các UA hay các thiết bị được bảo vệ bởi nó, bắt buộc sự liên lạc phải thông qua nó. Do đó, trong trường hợp này Contact header field không thể hoạt động được.
Đối với các request kế tiếp, nội dung của Record-Route trong request đầu tiên sẽ được sao chép lại vào Route header field của request kế tiếp thuộc cùng 1 dialog. Route hoạt động như Record-Route, chỉ khác là Record-Route ghi lại địa chỉ của các Firewall proxy mỗi khi request đi qua nên nội dung của nó luôn được cập nhật, còn nội dung của Route không bao giờ được thay đổi trong các request tiếp theo.  

7. CSeq:
CSeq header field là 1 header field bắt buộc trong mỗi request. CSeq chứa số nguyên (gọi là CSeq number) và kiểu request. CSeq number được khởi tạo ở thời điểm bắt đầu 1 call và được tăng thêm 1 cho mỗi request mới thuộc cùng 1 dialog, ngoại trừ CANCEL và ACK request. CSeq number được sử dụng để phân biệt 1 request trước đó được truyền lại hay 1 request mới. Kiểu request trong CSeq thể hiện mối tương quan giữa các request và response trong cùng 1 transaction.
8. Max-Forwards:
Max-Forwards header field chứa 1 số nguyên dương,  được sử dụng để chỉ ra số bước truyền lớn nhất mà 1 SIP request có thể đi qua. Giá trị của Max –Forwards sẽ giảm đi mỗi khi request đi qua 1 proxy. Khi proxy nhận request có Max-Forwards là 0, request sẽ bị loại bỏ và gởi 1 response “483 Too Many Hops” đến người gởi.
Ví dụ:  Max-Forwards : 70
III. SIP Message Body:
SIP requests và responses có thể chứa nhiều message body. Message body thường là 1 SDP chứa các đối tượng: text, image, application, voice, video,..
Message body được chuyển đổi qua lại giữa các UA. Các proxy không được thêm, xóa, sửa message body.
Để tăng khả năng của message body, một số Sip header field được sử dụng, đó là: Content-Type, Content-Length, Content-Encoding.
1.Content-Type:
Content-Type header field được sử dụng để chỉ ra loại nội dung trong message body.  Content-Type có định dạng là type/sub-type, nếu header field này không được miêu tả thì mặc định là application/sdp.   
Một số Content-Type thông dụng trong Sip Request và Response :
Ví dụ : content-type:application/sdp
2. Content-Length:
Content-Length được sử dụng để chỉ ra số các octet (octet là khối dữ liệu có kích thước 8 bit) trong message body. Nếu giá trị của Content-Length là 0, tức là chỉ ra không có message body trong sip message.
Ví dụ : Content-Length: 349
3. Content-Encoding:
Content-Encoding header field được sử dụng để chỉ ra lược đồ mã hóa được áp dụng cho message body. Điều này cho phép UAS xác định lược đồ giải mã cần thiết để hiểu được message body.
Ví dụ: Content-Encoding: gzip
IV. Mối quan hệ giữa Call, Dialog, Transaction và Message:
-  Message : là chuỗi ký tự riêng lẽ được trao đổi giữa 1 UAC và 1 UAS. Có 2 loại message : Request và Response.
- Transaction : xảy ra giữa UAC và UAS, bao gồm tất cả các message từ request đầu tiên được gởi từ UAC cho đến final response được gởi từ UAS. Nếu request là INVITE và final request không phải 2xx, thì ACK cũng thuộc cùng 1 transaction. Ngược lại, ACK dành cho 2xx response là 1 transaction tách biệt.
-  Dialog : là mối quan hệ peer-to-peer giữa 2 UA tồn tại 1 thời gian nào đó. 1 dialog được nhận dạng bởi Call-ID, tag của From header field (trong request) và tag của To header field (trong response).
- Call : Sự trao đổi media giữa 2 hay nhiều UA. Call còn được gọi là "session" hay "call session". Trong 1 Dialog mà có sự trao đổi media thì Dialog được gọi là Session, ngược lại nếu trong 1 Dialog mà không có sự trao đổi media thì Dialog không được gọi là Session

Không có nhận xét nào:

Đăng nhận xét