SIP là giao thức dạng Text sử dụng bộ ký tự ISO 10646 trong 
mã hoá 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, 
Tol, Perl. 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 phục vụ 
SIP với các máy phục vụ Web. Tuy nhiên, 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.
                
              
                                            
                                
            
                       
            
                 11 trang
11 trang | 
Chia sẻ: maiphuongtt | Lượt xem: 4212 | Lượt tải: 1 
              
            Bạn đang xem nội dung tài liệu Các loại bản tin SIP, để tải tài liệu về máy bạn click vào nút DOWNLOAD ở trên
Chương 12: Các loại bản tin SIP
SIP là giao thức dạng Text sử dụng bộ ký tự ISO 10646 trong 
mã hoá 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, 
Tol, Perl. 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 phục vụ 
SIP với các máy phục vụ Web. Tuy nhiên, 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 chia làm hai loại: Bản tin yêu cầu từ Client 
tới Server và bản tin đáp ứng từ Server trả lời cho Client: 
SIP-message = Request/ Response
4.1.4.1. Bản tin yêu cầu (Request)
Bản tin Request có khuôn dạng gồm hai phần cơ bản: Request-
line và phần mào đầu-header (với 3 loại header):
Request=Request-line*(General-header/Request-header/ Entity-
header)
CLRF
[message-body]
Trong đó thành phần Request-line chứa tên phương thức, một 
Request – URI và số phiên bản của giao thức. Các thành phần 
được ngăn cách với nhau bằng một khoảng trắng (SP). Cũng như 
các dòng khác, dòng khởi đầu được kết thúc bằng một ký tự xuống 
dòng (CRLF).
Request-line = Method SP Request-URI SP SIP-
Version 
Trong đó:
 Method (Phương thức SIP): SIP định nghĩa 6 phương thức 
cơ bản như trong bảng 4.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 (trường hợp máy phục vụ ủy quyền).
 SIP Version: Phiên bản SIP là các bản SIP được đưa ra các 
lần khác nhau. Cả hai bản tin Request và Response đều 
chứa phiên bản của SIP được sử dụng SIP Version. Hiện tại 
phiên bản SIP là 2.0.
Bảng 4.2. Các phương thức SIP
INVITE Mời thành viên tham gia hội thoại.
ACK
Yêu cầu xác nhận đã nhận được đáp ứng 
chập nhận (OK) cho yêu cầu INVITE.
OPTIONS Hỏi khả năng của máy phục vụ SIP.
BYE Yêu cầu giải phóng cuộc gọi
CANCEL
Hủy bỏ yêu cầu sắp được thực hiện với 
cùng giá trị trong các trường Call_ID, 
From, To, Cseq của yêu cầu đó bằng cách 
ngừng quá trình tìm kiếm báo hiệu. 
REGISTER
Đăng ký danh sách địa chỉ liên hệ của 
người dùng với máy phục vụ.
4.1.4.2. Bản tin phúc đáp (Response)
Sau khi nhận và thông dịch một bản tin yêu cầu, phía nhận 
thực hiện trả lời bằng một bản tin phúc đáp. 
Khuôn dạng bản tin cũng gồm hai phần cơ bản: Status-line và 
phần mào đầu header (với 3 loại header):
Response = Status-line *(General-header/ Response-header/ Entity-
header)
CLRF
[message-body]
Trong đó thành phần Status-line có cấu trúc sau: (SP là ký tự 
phân cách):
Status-line = SIP-Version SP status-code SP Reason-
phrase
 SIP Version: Cũng giống như trong bản tin Request.
 Status-code và Reason-phrase: Status-code là một mã kết 
quả nguyên gồm 3 digit, chỉ ra kết quả của việc cố gắng 
thực hiện và mức độ thỏa mãn yêu cầu. Reason-Phrase thì 
dùng để đưa ra một lời giải thích ngắn cho Status-code. 
Status-code mục đích là để sử dụng cho Server còn Reason-
phrase là dùng cho User. Client không thể yêu cầu hiển thị 
hay kiểm tra Reason-phrase.
Status-code gồm 3 digit. Digit đầu tiên định nghĩa loại đáp 
ứng, hai digit sau không có vai trò phân loại. SIP 2.0 định nghĩa 6 
giá trị của digit đầu tiên như sau: 
Bảng 4.3. Các mã trạng thái SIP
1xx Tìm kiếm, báo hiệu, sắp hàng đợi
2xx Thành công
3xx Chuyển tiếp yêu cầu
4xx Lỗi phía người dùng
5xx Lỗi phía Server
6xx
Lỗi chung: đường dây đang bận, từ 
chối,….
Mã đáp ứng SIP có thể mở rộng được. Các ứng dụng SIP 
không yêu cầu phải hiểu rõ về ý nghĩa của tất cả mã đáp ứng được 
đăng ký mà chỉ cần hiểu các loại mã đáp ứng, ý nghĩa của digit đầu 
tiên.
4.1.4.3. Cấu trúc bản tin SIP
Cả hai loại bản tin trên đều sử dụng chung một định dạng cơ 
bản được quy định trong RFC 2822 với cấu trúc gồm một dòng 
khởi đầu (start – line), một số trường tiêu đề và một phần thân bản 
tin tuỳ chọn (hình 4.2). Cấu trúc này được tóm tắt như sau:
generic-message = start-line
*message-header
CRLF
[ message-body ]
 Với
start-line = Request-Line / Status-Line
Hình 4.2. Cấu trúc bản tin SIP
Trong đó, dòng bắt đầu, các dòng tiêu đề hay các dòng trắng 
phải được kết thúc bằng một ký tự xuống dòng (CRLF) và phải lưu 
ý rằng dòng trắng vẫn phải có để ngăn cách phần tiêu đề và phần 
thân của bản tin ngay cả khi phần thân bản tin là rỗng.
 Start line: Mỗi bản tin SIP được bắt đầu với một Start Line, 
Start Line vận chuyển loại bản tin (phương thức trong các 
Request, và mã đáp ứng trong các bản tin đáp ứng) và phiên 
bản của giao thức. Start line có thể là Request-Line (trong 
các request) hoặc là Status-Line (trong các response).
 Headers: Các trường Hearder của SIP được sử dụng để vận 
chuyển các thuộc tính của bản tin và để thay đổi ý nghĩa của 
bản tin. Chúng tương tự như các trường tiêu để của bản tin 
HTTP theo cả cú pháp và ngữ nghĩa (thực tế có một vài tiêu 
đề được mượn từ HTTP) cho nên chúng luôn có khuôn 
dạng như sau: :.
Thứ tự các trường tiêu đề khác tên là không quan trọng 
(nhưng các tiêu đề mà được sử dụng để định tuyến bởi các 
proxy sẽ được đặt trước). Thứ tự các tiêu đề có cùng tên là 
quan trọng.
Tiêu đề bản tin bao gồm bốn loại:
– Tiêu đề chung.
– Tiêu đề Request.
– Tiêu đề Response.
– Tiêu đề thực thể.
 Body: Thân bản tin được sử dụng để mô tả phiên được khởi 
tạo (ví dụ: trong một phiên multimedia phần này sẽ mang 
loại mã hóa audio và video, tốc độ lấy mẫu …), hoặc nó có 
thể được sử dụng để mang dữ liệu dưới dạng text hoặc nhị 
phân (không được dịch) mà liên quan đến phiên đó. Phần 
thân bản tin có thể xuất hiện trong cả bản tin yêu cầu và đáp 
ứng. Các loại Body bao gồm:
– SDP: Session Description Protcol.
– MIME: Multipurpose Internet Mail Extentions.
– Các phần khác: được định nghĩa trong IETF.
4.1.5. Đánh giá SIP
 SIP là giao thức đề cử được tổ chức IETF đưa ra. Nó ra đời 
với mục đích đơn giản hoá cơ chế báo hiệu và điều khiển 
cuộc gọi cho VoIP. SIP là giao thức dạng text, các lệnh SIP 
có cấu trúc đơn giản để các thiết bị đầu cuối dễ dàng phân 
tích và sửa đổi.
 Các ưu điểm nổi bật của SIP là:
- Tính mở rộng một cách tự nhiên của giao thức cho phép 
dễ dàng định nghĩa và thi hành trong tương lai.
- Cho phép tạo các thiết bị đầu cuối một cách đơn giản và 
dễ dàng mà vẫn đảm bảo chi phí thấp.
 Tuy nhiên SIP vẫn còn có các nhược điểm:
- SIP là giao thức rất mới, cần được tiếp tục hoàn thiện.
- Nó chỉ đề cập tới một phạm vi hẹp trong toàn bộ phiên 
truyền thông nên cần phải được kết hợp với các giao thức 
khác trong quá trình xây dựng một hệ thống hoàn chỉnh.
- Khả năng giao tiếp với mạng chuyển mạch kênh kém.
4.2. H.323
4.2.1. Tổng quan về H.323
Khuyến nghị H.323 đầu tiên (phiên bản 1) được ra đời vào 
tháng 5/1996, do Tổ chức Viễn Thông Quốc Tế ITU (International 
Telecommunication Union) phê chuẩn. H.323 định nghĩa cách thức 
truyền âm thanh, dữ liệu và hình ảnh thời gian thực qua các mạng 
LAN, WAN.
Với sự phát triển mạnh mẽ của thoại gói và thoại IP, phiên bản 
2 của H.323 đã ra đời, nó bổ sung sự mô tả các thành phần cấu 
thành hệ thống, các thông báo, thủ tục cho các cuộc gọi đa phương 
thức thời gian thực được thiết lập giữa hai hoặc nhiều hơn các thực 
thể giao tiếp trên mạng gói.
Khuyến nghị H.323 về một hệ thống truyền thông đa phương 
tiện trên nền IP mang tính chất toàn diện, linh hoạt. Nó hỗ trợ việc 
sử dụng các chuẩn truyền thông đã có sẵn như các chuẩn nén, 
Q931….Vì vậy ta có thể xây dựng các ứng dụng đa phương thức, 
kèm cả dữ liệu và thoại. Các ứng dụng H.323 được thị trường hoá 
do những nguyên nhân sau:
 H.323 thiết lập các chuẩn truyền thông dựa trên nền sẵn có 
là mạng IP. Nó cũng được thiết kế để bù được độ trễ trên 
mạng LAN, cho phép người sử dụng các ứng dụng đa 
phương thức mà không cần thay đổi nền mạng trước đó.
 Độ rộng dải thông mạng LAN như Ethernet ngày càng tăng, 
từ 10 đến 100 Mbps tới tận Gbps và tốc độ máy tính cá 
nhân hiện thời cũng đã đạt tới tốc độ xử lý GHz.
 Bằng việc cung cấp tính tương tác giữa thiết bị tới thiết bị, 
ứng dụng tới ứng dụng, đại lý tới đại lý, H.323 cho phép 
tương thích giữa các sản phẩm khác nhau.
 H.323 cung cấp chuẩn để giao tiếp được giữa các mạng 
LAN và các mạng khác.
 Với H.323, nhà quản lý mạng có thể tiết kiệm được giải 
thông trên mạng mà cần thiết cho truyền thông. Việc hỗ trợ 
đa phát đáp trong hội thoại với số thành viên nhỏ cũng giảm 
bớt được yêu cầu giải thông.
 H.323 được chấp nhận bởi rất nhiều các công ty máy tính, 
tổ chức viễn thông hàng đầu như ITU, Intel, Microsoft, 
Cisco, IBM thống nhất về một chuẩn chung.
Khuyến nghị H.323 bao gồm cả các yêu cầu về dịch vụ giao 
tiếp thoại và hình ảnh trong mạng LAN mà không có cơ chế đảm 
bảo về chất lượng dịch vụ (QoS). Nó cũng kết hợp chặt chẽ với 
chuẩn T.120 chỉ định dữ liệu cho cuộc hội thoại.
4.2.2. Kiến trúc mạng và các thành phần của H.323
Hình 4.3. Kiến trúc mạng và các thành phần H.323
H.323 định nghĩa 4 thành phần chính của hệ thống giao tiếp:
4.2.2.1. Đầu cuối H.323
Là các điểm đầu cuối trong mạng LAN. Terminal đơn thuần là 
máy tính cá nhân hoặc một thiết bị độc lập nào đó hỗ trợ giao tiếp 
hai chiều thời gian thực với các máy trạm khác qua thoại và dữ 
liệu. Mỗi Terminal phải đảm bảo tính tương thích với các loại 
mạng khác nhau. Các thành phần bắt buộc và tuỳ chọn của nó 
được mô tả trên hình 4.4.
Các đầu cuối H.323 phải hỗ trợ các giao thức sau:
 H.245 cho việc chuyển đổi dung lượng của đầu cuối và cho 
việc tạo lập một kênh truyền thông.
 H.225 cho việc báo hiệu và thiết lập cuộc gọi.
 RAS cho việc khai báo và các điều khiển cho phép khác với 
một Gatekeeper.
 RTP/RTCP cho việc sắp xếp thành dãy các gói tin thoại và 
hình ảnh.
Các đầu cuối H.323 cũng phải hỗ trợ G.711 vì kết nối cơ bản 
tối thiểu của H.323 là thoại. Các thành phần tuỳ chọn trong một 
đầu cuối H.323 là các Codec cho hình ảnh, giao thức T-120 cho 
hội nghị dữ liệu, và MCU cho khả năng hội nghị đa điểm.
Hình 4.4. Đầu cuối H.323
4.2.2.2. Cổng phương tiện (GW)
Hình 4.5. Cấu tạo GW
Một GW cung cấp khả năng kết nối giữa một mạng H.323 với 
các mạng khác. Ví dụ như: một GW có thể kết nối liên lạc giữa 
một đầu cuối H.323 với các mạng SCN (SCN bao gồm tất cả các 
mạng chuyển mạch thoại như kiểu PSTN). Khả năng kết nối các 
mạng khác nhau này được thực hiện bởi việc phiên dịch giao thức 
cho việc thiết lập và giải phóng cuộc gọi, bằng việc chuyển đổi các 
định dạng truyền thông giữa các mạng khác nhau, và bằng việc 
trao đổi thông tin giữa các mạng mà kết nối bởi GW. Tuy nhiên 
việc kết nối giữa các đầu cuối H.323 sẽ không đòi hỏi sự có mặt 
của một GW (Hình 4.5).