Embed Size (px)
Citation preview
Giao thức SIP
A.Tổng quan về giao thức SIP
I.Giao thức SIP
Giao thức SIP (Secssion Initiation Protocol ) là giao thức báo hiệu điều khiển lớp ứng dụng được dùng để thiết lập , duy trì , kết thúc các phiên truyền thông đa phương tiện ( multimedia ) có một hoặc nhiều người tham gia . Các phiên multimedia bao gồm thoại internet , hội nghị và các ứng dụng tương tự có liên quan đến các phương tiện truyền đạt ( media ) như âm thanh , hình ảnh và dữ liệu . SIP sử dụng các bản tin mời ( INVITE ) để thiết lập các phiên và để mang các thông tin mô tả phiên truyền dẫn . SIP hỗ trợ các phiên đơn bá ( unicast ) và quảng bá ( multicast ) tương ứng các cuộc gọi điểm tới điểm và cuộc gọi đa điểm .
SIP là một giao thức để thiết lập các phiên truyền thông . Các phiên SIP bao gồm :
Hội họp đa phương tiện qua internet . Các cuộc gọi điện thoại qua internet . Các phiên video qua internet . Phân phối đa phuong tiên .
Các phần tử của SIP có thể liên lạc thông qua :
Liên lạc cá nhân . Phát quảng bá . Thông qua tổ hợp của các quan hệ liên lạc cá nhân hoặc một tổ hợp
của tất cả những phương tiên trên .
Trong các môi trường IPv4 và IPv6 thông qua :
UDP TCP SCTP hoặc TLS trên nền TCP
SIP là một giao thức mở rộng đơn giản
Các phương tiên ( Methods ) – Định nghĩa về phiên truyền thông . Khối mào đầu ( Headers ) – Mô tả về phiên truyền thông . Phần thông tin báo ( Message Body ) – SDP , ký tự , XML .
II.Sự phát triển của giao thức SIP
Đầu tiên SIP chỉ đơn thuần là một giao thức dùng để thiết lập phiên quảng bá cho Internet2 ( từ giữa đến cuối thập kỉ 90 ) . SIP được phát triển bởi SIP Working Group trong IETF. Phiên bản đầu tiên được ban hành vào tháng 3 năm 1999 trong tài liệu RFC 2543. Sau đó, SIP trải qua nhiều thay đổi và cải tiến. Phiên bản mới nhất hiện nay được ban hành trong IETF RFC 3261. RFC 3261 hoàn toàn tương thích ngược với RFC 2543, do đó các hệ thống thực thi theo RFC 2543 hoàn toàn có thể sử dụng với các hệ thống theo RFC 3261.
Một bản tin SIP có hai phần, phần mào đầu và phần thân. Phần thân cho phép phục vụ các ứng dụng khác nhau một cách linh hoạt. Ban đầu phần thân chỉ dùng để chuyển tải các tham số miêu tả phiên SDP như codec, địa chỉ IP đầu cuối, ... Phần thân được sử dụng để mở rộng các ứng dụng của khác nhau của SIP ví dụ như SIP-T cho liên vận PSTN-SIP-PSTN hoặc MSCML (Media Server Control Markup Language) cho dịch vụ hội nghị.
Sự phổ cập của SIP đã dẫn tới việc một loạt nhóm làm việc liên quan đến SIP được thành lập. Nhóm SIPPING (Session Initiation Protocol investigation working group) được thành lập với mục đích nghiên cứu các ứng dụng và phát triển các yêu cầu mở rộng cho SIP. Nhóm SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) có nhiệm vụ chuẩn hoá các giao thức cho các ứng dụng nhắn tin tức thời. Các nhóm làm việc khác là PINT (PSTN and Internet Internetworking), SPIRITS (PSTN/IN requesting Internet Services).
III.Các thành phần trong mạng SIP
1.Thành phần của SIP : bao gồm SIP User Agent ( UA ) và SIP server .
1.1.SIP User Agent ( người dùng Agent) :
SIP UA hoặc thiết bị đầu cuối là điểm cuối của dialog : SIP UA guiử và nhận các yêu cầu và trả lời của SIP , nó là điểm cuối của luồng đa phương tiện và nó luôn là Người dùng Equiment ( UE ) – bao gồm ứng dụng trong thiết bị đầu cuối hoặc ứng dụng phần cứng chuyên dụng . UA gồm hai phần :
Người dùng Agent Client ( UAC ) : ứng dụng của người gọi – khởi tạo request .
Người dùng Agent Server ( UAS ) : chấp nhận , gửi lại , từ chối request và gửi trả lời cho request đến thay mặt cho người sử dụng .
UA là thực thể SIP mà tương tác với với người sử dụng . Nó thường xuyên sử dụng giao diện với người sử dụng .
Tuy nhiên , một vài hệ thống sử dụng SIP không trực tiếp kết nối với người sử dụng . Ví dụ : B có thể gửi lại tất cả lời mời vào phiên được nhận từ nửa đếm đến 7 giờ sáng đến máy trả lời SIP của B > máy này tự động thiết lập phiên trong thông điệp bản ghi .
Nó cũng chứa UA – mà không nhất thiết lập duy trì tương tác với người sử dụng , nhưng vẫn trả lời mời hoặc chuyển lời mời trên dại diện của B .
1.2.SIP Server :
SIP server : Cần phân biệt SIP Server và UA server cũng như mô hình client-server . Ở đây , SIP server là một thực thể luận lý , một SIP server có thể có chức năng của nhiều loại server hay nói cách khác một SIP Server có thể hoạt động như các server khác nhau trong các trường hợp khác nhau . Trong SIP Server có các thành phần quan trọng như : Proxy Server , Redỉect Server , Location Server , Registrar Server , …
Proxy Sever :
Có thể xem các Proxy Server như các router thiết bị đầu cuối SIP mà chuyển tiếp các yêu cầu và trả lời. Tuy nhiên các Proxy SIP sử dụng nguyên tắc định tuyến
phức tạp hơn là chỉ tự động chuyển tiếp bản tin dựa vào bảng định tuyến. Chuẩn về SIP cho phép các Proxy thực hiện các hoạt động chẳng hạn như xác định tính hợp lệ của bản tin, xác thực người sử dụng, phân nhánh các request, phân giải địa chỉ, hủy bỏ các cuộc gọi đang chờ. Sự linh hoạt của các proxy SIP cho phép các nhà khai thác và quản trị mạng sử dụng các proxy cho các mục đích khác nhau và trong các vị trí khác nhau trong mạng (chẳng hạn như Proxy biên, Proxy lõi, và Proxy của các doanh nghiệp).
Một Proxy Server được thiết kế trong suốt với các UA. Các Proxy Server được phép thay đổi các bản tin chỉ theo một số cách cụ thể và hạn chế. Ví dụ, một proxy không được phép thay đổi phần thân bản tin SDP của bản tin INVITE.
Forking proxy: SIP proxy server định tuyến thông điệp đến nhiều hơn một đích
được gọi là proxy phân nhánh. Forking Proxy có thể định tuyến thông điệp song
song hoặc theo thứ tự. Ví dụ của Forking Proxy song song là việc rung chuông
đồng thời của tất cả các điện thoại trong nhà. Forking Proxy theo thứ tự chứa proxy
thử rung chuông lần lượt các vị trí khác nhau, có thể rung chuông trong một chu kỳ
thời gian nhất định nếu người dùng không nhấc máy thì thử UA mới.
Redirect Server :
Truy nhập dữ liệu và dịch vụ định vị để tìm địa chỉ của user và gửi trả về bản tin lớp 300 để thông báo thiết bị chuyển hướng bản tin tới địa chỉ khác – tự liên lạc thông qua địa chỉ trả về .
c.Registrar Sever : là sever nhận bản tin SIP REGISTER yêu cầu và cập nhật thông tin từ bản tin request vào “ location database “ nằm trong Location Sever .
d.Location Sever
Lưu thông tin trạng thái hiện tại của người dùng trong mạng SIP .
2.Các bản tin SIP mào đầu và đánh số :
Dưới đây là các bản tin của SIP :
INVITE : bắt đầu thiết lập cuộc gọi bằng cách gửi bản tin mời đầu cuối khác tham gia
ACK : bản tin này khẳng định máy trạm đã nhận được bản tin trả lời bản tin INVITE
BYE : bắt đầu kết thúc cuộc gọi
CANCEL : hủy yêu cầu nằm trong hàng đợi
REGISTER : đầu cuối SIP sử dụng bản tin này để đăng ký với máy chủ đăng ký
OPTION : sử dụng để xác định năng lực của máy chủ
INFO : sử dụng để tải các thông tin như âm báo DTMF
Những bản tin trao đổi giữa A và B để thiết lập một phiên :
3. Khuôn dạng thông điệp :
Thông điệp SIP gồm 3 phần: start line, header của thông điệp và body.
Client gửi yêu cầu (request) và server trả lời bằng response. Giao dịch SIP bao
gồm yêu cầu từ client, 0 hoặc nhiều provisional response và final response từ
server.
3.1. SIP response
Status line là dòng bắt đầu của response.
Các bản tin đáp ứng được chia thành thành hai nhóm bao gồm 6 loại bản tin, mỗi
bản dùng một mã trạng thái nằm trong một dải mã.
Khuôn dạng thông điệp SIP
SIP version Status code Reason Phrase
Cấu trúc Response Line
SIP response
Provisional (1xx): Bản tin này dùng để chỉ thị tiến trình nhưng không kết
thúc giao dịch SIP (tìm kiếm, rung chuông, xếp hàng).
Final (2xx, 3xx, 4xx, 5xx, 6xx): Bản tin này chỉ thị kết thúc giao dịch SIP.
1xx: Provisional – đã nhận yêu cầu và đang tiếp tục xử lý yêu cầu. Tìm
kiếm, rung chuông, xếp hàng đợi, nó được phát khi quá trình xử lý chưa thể kết
thúc ngay được. Phía phát cần phải dừng quá trình truyền các yêu cầu khi nhận
được bản tin này.
2xx: Success – Các yầu đã được xử lý thành công (nhận, hiểu và đã được
tiếp nhận).
3xx: Redirection – Cần tiến hành thêm các hoạt động để có thể đáp ứng được
các yêu cầu. Chúng được gửi bởi các Redirect Server.
4xx: Client Error – Lỗi do phía Client, các yêu cầu sai cú pháp hoặc không
đáp ứng đúng yêu cầu của Server.
5xx: Server Error – Lỗi phía Server, server bị sự cố và không đáp ứng được
các yêu cầu hợp lệ.
6xx: Global Failure – Lỗi tổng thể, các yêu cầu không thể được đáp ứng tại
bất kỳ server nào.
cụ thể :
1xx: Phản hồi thông tin :
100: đang thử : máy đựợc gọi đã tiếp nhận được yêu cầu bên gọi và gửi bản
tin này mang tính chất phản hồi để thử
180: đổ chuông : Máy được gọi đổ chuông, và gửi bản tin chuông về cho bên
gọi.
181: cuộc gọi đang chuyển hướng: May được gọi lập trình chuyển hướng đến
một máy khác trong khi nó đang bận hoặc không xử lý cuộc gọi của bên gọi.
182 : đang xếp hàng đợi : chờ đợi vì có nhiều yêu cầu đến cùng lúc
183: Phiên đang tiến hành: Có phiên cuộc gọi khác đang đựơc tiến hành với
máy đựợc gọi
2xx: Phản hồi thành công
200 OK phản hồi thành công : được dùng khi bên được yêu cầu trả lời thành
công yêu cầu của bên yêu cầu: ỏ ví dụ trên ta dùng hai bản tin 200 ok. Trong đó
bản tin đầu tiên do máy được gọi phản hồi lại máy gọi khi nó trả lời thành công bản
tin chuông. Còn trong bản tin 200 OK thứ hai do máy gọi phản hồi đến máy được
gọi khi nó đã gọi thành công cuộc gọi và chấp nhận kết thúc cuộc gọi.
3xx: Phản hồi chuyền hướng
300: có nhiều lựa chọn
301: đã dời đi vĩnh viễn
302: tạm thời dời đi
305: dùng proxy
380: dịch vụ thay thế
4xx: Yêu câu thất bại
400: yêu cầu sai
401: không được quyền: chỉ dùng với cơ quan đăng kiểm , các proxy phải
dùng yêu cầu cấp phép cho proxy 407
402: yêu cầu trả tiền :Dự trữ để phòng trong tương lai: Ví dụ khi bạn dùng
điện thoại di động, tiền trong tài khoản của bạn gần hết, trước khi thiết lập cuộc gọi
theo yêu cầu của bạn thì tổng đài sẽ thêm một thông báo:"Tài khoản của bạn sắp
hệt , xin vui lòng nạp thêm để có thê tiếp tục sử dụng"...
403: cấm
404: Không tìm thấy người dùng:"Thuê bao quý khách vừa gọi Không có,
xin vui lòng thứ lại"
405: Phương thức không được phép
406: Không được chấp nhận
407: cần có sự cấp phép cho proxy
408: yêu cầu bị hết giờ : Không tìm thấy người dùng trong thời gian cho
phép
410: đã không còn , người dùng đã từng tồn tại nhưng bây giờ không còn
được sử dụng nữa:"Thuê bao quý khách vừa gọi hiện đang tạm khóa, mong quý
khách vui lòng gọi lại sau"
413: Đơn vị yêu cầu quá lớn: "cuộc gọi không thể thực hiện được"
414: URI của yêu cầu quá tải :"mạng quá tải"
415: kiểu phương tiện không được hỗ trợ: ví dụ : tin nhắn đa phương tiện
không thể gửi đến và nhận từ một số máy di động không hỗ trơn GPRS
416: giản đồ URI không được hỗ trợ
420: phần mở rộng không đúng: Sử dụng phần mở rộng của giao thức SIP
không đúng nên máy chủ không hiểu được
421: Yêu cầu có phần mở rộng
423: Quãng quá ngắn
480: tạm thời không hoạt động
481: cuộc gọi/giao dịch không tồn tại
482: phát hiện thấy lặp
483: quá nhiều chặng trung tuyến
484:địa chỉ không hoàn chỉnh
485: tối nghĩa
486: đang bận
487: yêu cầu bị chấm dứt
488: Không được chấp nhận tại đây
491: yêu cầu đang chờ
493: không thể giải mã được : Không thể giải mã phần thân của S/MIME
5xx: Lỗi máy chủ
500: lỗi bên trong máy chủ
501: chưa khai báo: Phương thức yêu cầu SIP này chưa đựơc khai báo ở đây
502: gateway sai
503: dịch vụ không có
505: phiên bản không được hỗ trợ: Máy chủ không hỗ trợ giao thức SIP này
513: thông điệp quá lớn
6xx: Thất bại toàn cục
600: tất cả mọi nơi đều bận
603: từ chối
604: không tồn tại ở bất cứ đâu
606: Không được chấp nhận
3.2. SIP request
Request line là dòng đầu tiên của request. Tên giao thức chỉ ra mục đích của
request và request-URI chứa đích của request.
Các phương thức SIP
Các phương thức SIP có thể xem như là các kiểu thông điệp. Chúng xác định yêu cầu đang được tạo
bởi thiết bị của người dùng (hoặc thực thể mạng trong một số trường hợp). Các phương thức SIP cơ bản
hiện tại được định nghĩa để sử dụng trong IMS: ACK, BYE, CANCEL, INVITE, REGISTER, UPDATE..
Method Request URI SIP version
Cấu trúc Request Line
SIP request
3.3. Các trường header
Khuôn dạng của các trường header:
Tên của trường header: giá trị của trường header
Có các trường header bắt buộc và tùy chọn trong mỗi thông điệp. Có 6 trường
header có tính bắt buộc trong mỗi SIP thông điệp: To, From, Cseq, Call-ID, Max-
Forward, Via.
3.4. Message Body
Message Body được tách khỏi trường header bởi dòng trống. Thông điệp SIP có
thể mang bất kỳ kiểu nào của body, kể cả body nhiều phần sử dụng mã hóa MIME
(Multipurpose Internet Mail Extension ). SIP sử dụng MIME để mã hóa body của
nó. Do đó, body của SIP được mô tả giống như phần đính kèm vào email.
Đặc tính quan trọng của body là chúng truyền từ đầu cuối đến đầu cuối. Proxy không cần phân tích cú pháp của thông điệp body để định tuyến thông điệp. Thực tế, UA có thể lựa chọn để mã hóa nội dung của thông điệp body end to end. Trong trường hợp này, proxy sẽ không thể biết kiểu phiên nào đang được thiết lập giữa hai UA
4. Chức năng của SIP
4.1. Thiết lập, sửa đổi và kết thúc phiên
SIP độc lập với kiểu của phiên đa phương tiện được điều khiển và kỹ thuật sử
dụng để mô tả phiên. Nó rất hữu ích cho hội nghị, cuộc gọi audio, whiteboard được
chia sẻ và các phiên chơi game. Các phiên bao gồm các luồng RTP (Real Time
Protocol) mang audio và video thường xuyên được mô tả bằng SDP, nhưng có một
vài kiểu phiên khác có thể được mô tả với các giao thức mô tả khác. SIP được sử
dụng để phân phối mô tả phiên giữa các bên tham gia tiềm năng. Khi mô tả phiên
được phân phối, SIP có thể sử dụng để thỏa thuận và sửa các tham số của phiên và
kết thúc phiên.
Ví dụ sau đây mô tả tất cả các chức năng này. B muốn có một phiên audio-video
với A và dự định dùng codec PCM (Pulse Code Modulation) để mã hóa voice.
Trong ví dụ này, bên phân phối phiên bao gồm B gửi cho A mô tả phiên với codec
PCM. A thích sử dụng codec ADPCM vì nó tốn ít băng thông hơn, do đó A thuyết
phục B sử dụng ADPCM. Cuối cùng cả hai sử dụng codec ADPCM, nhưng phiên
không thể được thiết lập cho đến khi việc thỏa thuận này kết thúc.
Đột nhiên, ở giữa phiên audio-video, A quyết định muốn bỏ thành phần video. A
sửa phiên chỉ có audio. Khi B quyết định cuộc hội thoại đã kết thúc, phiên được kết
thúc.
4.2. Tính di động của người sử dụng
SIP không thể phân phối mô tả phiên cho các bên tham gia cho đến khi họ được
định vị. Người dùng có thể thường xuyên được liên lạc tại vài vị trí. Khi đó, họ có
vài địa chỉ IP khác nhau phụ thuộc vào máy mà họ sử dụng và muốn nhận phiên
đến chỉ tại vị trí hiện tại của họ. Ví dụ, người khác có thể muốn nhận phiên mời
trên máy trạm của họ vào buổi sáng khi người sử dụng đến nơi làm việc, trên máy
tính tại nhà vào buổi tối và trên điện thoại cầm tay khi họ đi du lịch.
SIP URI: người sử dụng trong môi trường SIP được định nghĩa bởi SIP Uniform
Resource Identity (URI). Khuôn dạng của SIP URI tương tự như địa chỉ email, bao
gồm username và domain name:
sip: [email protected]
Trong ví dụ trước, nếu chúng ta tra cứu SIP server (điều khiển domain
company.com) chúng ta sẽ tìm thấy người sử dụng có username là B. URI của B có
thể là SIP:[email protected], chỉ ra rằng host có địa chỉ IP là 131.160.1.112 có
username là B.
Registration (đăng ký): chú ý rằng, người sử dụng đăng ký vị trí hiện tại của họ
cho server nếu họ muốn được tìm thấy. Trong ví dụ trên, B đang làm việc trên
laptop của mình có địa chỉ IP là 131.160.1.112. Tên login là B. B đăng ký vị trí
hiện tại của mình với server của công ty. Bây giờ A muốn gọi B. A muốn có địa chỉ
SIP Public của B sip: [email protected]) vì nó được in trong business card của B.
Vì vậy, khi server tại thanglong.com được liên hệ và hỏi về B, nó biết nơi mà B
có thể liên lạc và kết nối được tạo.
5.Thiết lập và hủy cuộc gọi SIP
Trước tiên ta tìm hiểu hoạt động của máy chủ ủy quyền và máy chủ chuyển đổi
+ Hoạt động của máy chủ ủy quyền (Proxy Server)
Hoạt động của Proxy server được trình bày như trong hình ….Client SIP
[email protected] gửi bản tin INVITE cho [email protected] để mời tham gia
cuộc gọi.
Các bước như sau:
+ Bước 1: [email protected] gửi bản tin INVITE cho UserB ở miền hotmail.com,
bản tin này đến proxy server SIP của miền hotmail.com (Bản tin INVITE có thể đi
từ Proxy server SIP của miền yahoo.com và được Proxy này chuyển đến Proxy
server của miền hotmail.com).
+ Bước 2: Proxy server của miền hotmail.com sẽ tham khảo server định vị
(Location server) để quyết định vị trí hiện tại của UserB.
+ Bước 3: Server định vị trả lại vị trí hiện tại của UserB (giả sử là
+ Bước 4: Proxy server gửi bản tin INVITE tới [email protected]. Proxy server
thêm địa chỉ của nó trong một trường của bản tin INVITE.
+ Bước 5: UAS của UserB đáp ứng cho server Proxy với bản tin 200 OK.
+ Bước 6: Proxy server gửi đáp ứng 200 OK trở về [email protected].
+ Bước 7: [email protected] gửi bản tin ACK cho UserB thông qua proxy server.
+ Bước 8: Proxy server chuyển bản tin ACK cho [email protected]
+ Bước 9: Sau khi cả hai bên đồng ý tham dự cuộc gọi, một kênh RTP/RTCP được
mở giữa hai điểm cuối để truyền tín hiệu thoại.
+ Bước 10: Sau khi quá trình truyền dẫn hoàn tất, phiên làm việc bị xóa bằng cách
sử dụng bản tin BYE và ACK giữa hai điểm cuối.
+ Hoạt động của máy chủ chuyển đổi địa chỉ (Redirect Server):
Hoạt động của Redirect Server được trình bày như hình .
Các bước như sau:
+ Bước 1: Redirect server nhân được yêu cầu INVITE từ người gọi (Yêu cầu này
có thể đi từ một proxy server khác).
+ Bước 2: Redirect server truy vấn server định vị địa chỉ của B.
+ Bước 3: Server định vị trả lại địa chỉ của B cho Redirect server.
+ Bước 4: Redirect server trả lại địa chỉ của B đến người gọi A. Nó không phát yêu
cầu INVITE như proxy server.
+ Bước 5: User Agent bên A gửi lại bản tin ACK đến Redirect server để xác nhận
sự trao đổi thành công.
+ Bước 6: Người gọi A gửi yêu cầu INVITE trực tiếp đến địa chỉ được
trả lại bởi Redirect server (đến B). Người bị gọi B đáp ứng với chỉ thị thành công
(200 OK), và người gọi đáp trả bản tin ACK xác nhận. Cuộc gọi được thiết lập.
Ngoài ra SIP còn có các mô hình hoạt động liên mạng với SS7 (đến
PSTN) hoặc là liên mạng với chồng giao thức H.323.
B.Các giao thức trong SIP
Các giao thức khác của IÈT có thể sử dụng để xây dựng những ứng dụng SIP .
SIP có thể hoạt động cùng với nhiều giao thức như :
RSVP ( Reource Revervation Protocol ) : Giao thức chiếm trước tài
nguyên mạng .
RTP ( Real-time tranpsport Protocol ) : Giao thức vận chuyển thời
gian thực .
RTSP ( Real Time Streaming Protocol ) : Giao thức tạo luồng thời
gian thực .
SAP ( Session Advertisement Protocol ) : Giao thức thông báo phiên
kết nối .
SDP ( Session Description Protocol ) : Giao thức mô tả phiên kết nối
đa phương tiện .
MIME ( Multipurpose Internet mail Extension – Mở rộng thư tín
Internet đa mục đích .
HTTP ( Hypertext Transfer protocol ) : Giao thức truyền siêu văn bản .
COPS ( Common Open policy Service ) : Dịch vụ chính sách mở
chung .
OSP ( Open Settlement protocol ) : Giao thức thỏa thuận mở .
I.RSVP ( Reource Revervation Protocol ) : Giao thức chiếm trước tài nguyên
mạng.
RSVP là một cơ chế báo hiệu dùng để dành riêng tài nguyên trên một mạng.
RSVP không phải là một giao thức định tuyến. Việc quyết định tuyến do IGP (gồm
cả các mở rộng TE) và CSPF.
Công việc của RSVP là báo hiệu và duy trì tài nguyên dành riêng qua một mạng.
Trong MPLS TE, RSVP dự trữ băng thông tại mặt phẳng điều khiển (control-plane
layer); không có chính sách lưu lượng trên mặt phẳng chuyển tiếp (forwarding-
plane). Khi sử dụng cho các mục đích khác (như VoIP hay DLSW+reservations),
RSVP có thể được dùng để dành riêng không gian hàng đợi công bằng có trọng số
(WFQ – Weighted Fair Queuing) hay xây dựng các ATM SVC.
- RSVP có ba chức năng cơ bản:
* Thiết lập và duy trì đường đi (Path setup and maintenance)
* Hủy đường đi (Path teardown)
* Báo lỗi (Error signalling)
- RSVP là một giao thức trạng thái mềm (soft-state protocol). Nghĩa là cần tái báo
hiệu trên mạng để làm tươi định kỳ cho nó. Với RSVP, một yêu cầu bị hủy nếu nó
được chỉ định xóa khỏi mạng bằng RSVP hay hết thời gian dành riêng (reservation
times out).
1.Các loại thông điệp trong RSVP : có 6 loại thông điệp trong RSVP như sau :
a) Path – sử dụng để yêu cầu tài nguyên dành trướcb) Resv – Gửi đáp ứng bản tin đường để thiết lập và duy trì dự trữ tài
nguyên.c) PathTear- Sử dụng đề xóa dự trữ tài nguyên khỏi mạng theo hướng đi.d) ResvTear – Sử dụng để xóa bỏ tài nguyên khỏi mạng theo hướng về.e) PathErr – Thông báo lỗi bản tin Pathf) ResvErr- Thông báo lỗi bản tin Resvg) ResvConf – Là một bản tin tùy chọn, gửi ngược lại tới phía gửi của bản
tin Resv đề xác nhận rằng tài nguyên dự trữ xác định thực sự đã được cài đặt
h) ResvTearConf- Sử dụng để xác nhận dự trữ tài nguyên xác định đã bị xóa khỏi mạng.
2.Mô hình hoạt động ( Gồm 6 bước ) :
Bước 1: Ứng dung trên Host A sẽ tạo 1 phiên đến máy đích co Ip : 128.32.32.69 bằng RSVP tại host A .
Bước 2 : Tại host A , RSVP sẽ tạo bản tin Path và sẽ gửi đến router gần nhất R1 nhằm đưa đến địa chỉ 128.32.32.69 .
Bước 3 : Bản tin Path tiếp tục thông qua R5 và R4 cho đến khi đến đích là Host B .
Bước 4 : Ứng dụng tại host B sẽ tiếp nhận RSVP này và kiểm tra phiên 128.32.32.69. Kiểm tra xem các bản tin này có tồn tại trong phiên không .
Bước 5 : Host B sử dụng RSVP tạo ra bản tin Resv gửi ngược lại R4 về địa chỉ gửi là 24.1.70.210
Bước 6 : Bản tin Resv tiếp tục thông qua R5 và R1 cho đến khi tới Host A.
3. Các chức năng của RSVP:
3.1.Thiết lập và duy trì đường đi:
a.Thiết lập đường đi (Path Setup):
- Sau khi đầu đường hầm (tunnel headend) hoàn thành CSPF cho một đường hầm
cụ thể, nó gửi một thông điệp Path đến nút kế tiếp (next-hop) dọc theo đường đi đã
tính toán đến đích. LSR gửi thông điệp Path được gọi là LSR ngược dòng
(upstream router), và LSR nhận thông điệp được gọi là LSR xuôi dòng (down-
stream router). LSR ngược dòng con duoc goi la trạm trước đó ( phop – previous
hop).
R4
R5
R3R2
R1
Host A
24.1.70.210
Host B
128.32.32.69
PATHPATH
PATH
PATH
RESV
RESV31
2
- Sau khi LSR xuôi dòng nhận một thông điệp Path, nó kiểm tra định dạng của
thông điệp, sau đó kiểm tra lượng băng thông mà thông điệp yêu cầu. Tiến trình
này được gọi là điều khiển chấp nhận (admission control).
- Nếu việc kiểm tra này thành công và thông điệp Path được phép dành riêng băng
thông như nó yêu cầu, LSR xuôi dòng tạo một thông điệp Path mới và gửi đến nút
kế trong đối tượng tuyến tường minh (ERO – Explicit Route Object). Thông điệp
Path tiếp tục được chuyền đi đến khi nào chúng đến được nút cuối cùng trong ERO
– đuôi đường hầm MPLS TE (tunnel tail).
- Đuôi đường hầm thực hiện điều khiển chấp nhận trên thông điệp Path giống như
các LSR xuôi dòng khác. Khi nó nhận ra rằng nó là đích đến của thông điệp Path
nó trả lời lại bằng thông điệp Resv. Resv đóng vai trò như là một ACK báo về cho
LSR ngược dòng. Resv chứa một thông báo rằng thỏa mãn sự dành riêng đến cuối
đường hầm và thông tin nhãn đến (incoming label) cho LSR ngược dòng sử dụng
để gửi các gói dọc theo TE LSP đến đích.
b.Duy trì đường đi (Path Maintenance):
- Thoạt nhìn, việc duy trì đường đi giống như thiết lập đường đi. Mỗi 30 giây đầu
đường hầm gửi một thông điệp Path đến láng giềng xuôi dòng của nó. Nếu một
LSR gửi đi một dãy 4 thông điệp Path và không thấy Resv, nó nghĩ rằng sự dành
riêng bị mất và gửi một thông điệp ngược dòng (message upstream) báo rằng sự
dành riêng bị mất.
- Các thông điệp Path và Resv được gửi độc lập và bất đồng bộ giữa các láng giềng
với nhau. Thông điệp Resv được dùng để làm tươi (refresh) một sự dành riêng đang
tồn tại chứ không phải trả lời cho thông điệp Path.
3.2. Hủy đường đi:
-Nếu một nút (thường là đầu đường hầm) quyết định một sự dành riêng không còn
cần thiết trong mạng, nó gửi một thông điệp PathTear dọc theo đường thông điệp
Path đã đi và một ResvTear dọc theo đường của Resv.
- Thông điệp ResvTear được gửi để hồi đáp cho PathTear báo hiệu đuôi đường
hầm. PathTear và ResvTear cũng được gửi để trả lời một điều kiện lỗi trong mạng.
-Không giống thông điệp làm tươi, PathTear không cần đi đến hết downstream
trước khi nhận được kết quả.
3.3. Báo lỗi:
- Thỉnh thoảng, tín hiệu RSVP có thể bị lỗi. Các lỗi này được báo hiệu bằng thông
điệp PathErr hay ResvErr. Thông điệp lỗi được gửi ngược dòng về phía nguồn của
lỗi; một PathErr được gửi ngược dòng từ một nút xuôi dòng và một ResvErr được
gửi xuôi dòng từ một nút ngược dòng.
II. RTP ( Real Time Tranpsport Protocol ) : Giao thức vận chuyển thời gian
thực .
RTP – từ viết tắt của Real Time Transport Protocol (Giao thức Vận chuyển Thời
gian Thực) đặc tả một tiêu chuẩn định dạng gói tin dùng để truyền âm thanh và
hình ảnh qua internet. Tiêu chuẩn này được khai báo trong RFC 1889. Nó được
phát triển bởi nhóm Audio Video Transport Working và được ban hành lần đầu tiên
vào năm 1996.
RTP và RTCP liên kết rất chặt chẽ với nhau – RTP truyền dữ liệu thực trong khi
RTCP được dùng để nhận thông tin phản hồi về chất lượng dịch vụ.
1.RTP (even port-port chẵn)
_ RTP cung cấp chức năng mạng vận chuyển end-to-end cho những ứng dụng
truyền dữ liệu mà yếu cầu thời gian thực (real-time) như là âm thanh và video.
Những chức năng đó bao gồm nhận diện loại dự liệu, số trình tự, tham số thời gian
và giám sát tiến trính gởi.
- RTP là thành phần quan trọng của VoIP bởi vì nó cho phép thiết bị đích sắp xếp
và điều chỉnh lại thời gian cho gói tin thoại trước khi được gởi đến người dùng.
- Sequence number được tăng thêm bởi 1 đối với từng gói tin, giá trị khởi đầu ( của
gói tin đầu tiên ) được chọn ngẫu nhiên để nhằm mục đích bảo mật. Xem xét giá trị
trong trường này, receiver có thể xác định được gói tin bị mất hoặc out of oder tính
tóan sác xuất mất gói hay để điều chỉnh thời gian playout của dữ liệu nhằm đảm
bảo chất lượng của dịch vụ.
- Timestamp được sử dụng để tính tóan đồng bộ cũng như jitter của dữ liệu, vì vậy
giá trị trong trường này luôn tăng một cách tuyến tính và đơn điệu tùy thuộc theo
xung clock lấy mẫu được sử dụng cho từng lọai dữ liệu ( vd video là 90kHz) bắt
đầu từ thời điểm byte đầu tiên của gói RTP. Giá trị đầu tiên cũng được chọn ngẫu
nhiên.
2.RTCP(Real-Time Transport Control Protocol)odd port-port lẻ
- RTCP giám sát chất lượng của quá trình phân phối dữ liệu và cung cấp tiến trình
điều khiển thông tin. RTCP cung cấp thông tin phản hồi dựa theo điều kiện của
mạng:
- RTCP cung cấp cơ chế cho những thiết bị liên quan trong phiên (session) RTP
trao đổi thông tin về giám sát và điều khiển phiên.
- RTCP giám sát chất lượng của các yếu tố như là đếm gói (packet count), mất gói,
độ trễ, jitter. RTCP truyền gói bằng 1% băng thông của phiên, nhưng ở một tốc độ
xác định trong ít nhất mỗi 5 giây.
- Tham số thời gian Network Time Protocol(NTP) dưa vào các xung được đồng bộ.
- Tham số thời gian RTP tương ứng thì được tạo ngẫu nhiên và dựa vào tiến trính
lấy mẫu gói dữ liệu. Cả hai NTP và RTP thì được đặt trong gói RTCP bởi người
gởi dữ liệu.
III. RTSP ( Real Time Streaming Protocol ) : Giao thức tạo luồng thời gian
thực .
Là giao thức điều khiển kiểm soát hệ thống mạng , được thiết kế sử dụng trong
hệ thống giải trí và truyền thông để kiểm soát Streaming media Severs . Giao thức
được sử dụng để thiết lập và kiểm soát các phương tiện truyền thông giữa các điểm
cuối phiên . Người dùng đưa ra các lệnh VCR , như chạy hay tạm dừng , để điều
khiển thời gian thực trong việc phát lại các file media từ sever .
IV. SDP ( Session Description Protocol ) : Giao thức mô tả phiên kết nối đa
phương tiện .
Là giao thức cho phép client chia sẻ thông tin về phiên kết nối cho các client
khác. Nó đóng một vai trò quan trọng trong VoIP.
1.Mô tả SDP:
SDP không phải là một giao thức lớp vận chuyển, nó không thực sự vận chuyển
dữ liệu giữa các client mà nó chỉ thiết lập cấu trúc thông tin về các thuộc tính của
luồng dữ liệu, dữ liệu thực sự được truyền đi bởi các giao thức SIP, RTSP hay
HTTP.
Thông tin trong gói SDP ở dạng ASCII gồm nhiều dòng, mỗi dòng là 1 trường.
Ví dụ bản tin SDP:
v=0
o=bsmith 2208988800 2208988800 IN IP4 68.33.152.147
s=
c=IN IP4 20.1.25.50
t=0 0
a=recvonly
m=audio 0 RTP/AVP 0 1 101
a=rtpmap:0 PCMU/8000
Trường Ý nghĩa
V Phiên bản của giao thức
OChủ của phiên kết nối, nhận dạng, phiên bản phiên kết nối, Loại
mạng, Loại địa chỉ, IP của chủ.
S Tên phiên kết nối
I Miêu tả kết nối
U URI
E E-mail của người cần liên lạc
P Số điện thoại của người cần liên lạc
C Thông tin kết nối:: IP version and CIDR IP address
k Khóa mã hóa như clear text,base64, uri
mLoại mạng, port kết nối,phương thức vận chuyển,danh sách định
dạng
t Thời điểm bắt đầu và kết thúc kết nối
a Thuộc tính.
Ý nghĩa của các trường
2.Hoạt động của SDP:
Client gửi SIP request, thiết bị sẽ tạo một gói SDP gửi trả lại. Gói SDP này mang
thông tin về phiên kết nối. Sau đây là một ví dụ:
v=0
o=thang 2890844526 2890844526 IN IP4 host.hanoi.example.com
s=
c=IN IP4 host.hanoi.example.com
t=0 0
m=audio 49170 RTP/AVP 0 8 97
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 51372 RTP/AVP 31 32
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
Trong ví dụ trên, người gửi là Thắng , lắng nghe kết nối từ
host.hanoi.example.com. Gói được gửi tới bất kỳ ai muốn tham gia phiên kết nối.
Kết nối của Alice hỗ trợ ba loại kết nối cho audio là PCMU, PCMIA và iLBC, hai
loại kết nối video H.261 và MPV. Nếu Ngọc muốn tham gia kết nối thì gửi lại bản
tin SDP:
v=0
o=ngoc 2808844564 2808844564 IN IP4 host.hanoi2.example.com
s=
c=IN IP4 host.hanoi2.example.com
t=0 0
m=audio 49174 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 49170 RTP/AVP 32
a=rtpmap:32 MPV/90000
3.Bảo mật cho SDP:
Bản tin SDP mang thông tin về phiên kết nối như nhận dạng phiên kết nối, IP
người gửi, người nhận,… Nếu kẻ tấn công bắt được những gói SDP này nó có thể
thay đổi giá trị trong các trường rồi gửi đi. Nhưng điều này hoàn toàn có thể khắc
phục bằng phương pháp chứng thực user của SIP.
V. MIME ( Multipurpose Internet mail Extension – Mở rộng thư tín Internet
đa mục đích .
MIME cung cấp cách thức kết hợp nhiều loại dữ liệu khác nhau vào trong một
thông điệp duy nhất có thể được gởi qua Internet dùng Email hay Newgroup.
Thông tin được chuyển đổi theo cách này trông giống như những khối ký tự ngẫu
nhiên. Những thông điệp sử dụng chuẩn MIME có thể chứa hình ảnh, âm thanh và
bất kỳ những loại thông tin nào khác có thể lưu trữ được trên máy tính. Hầu hết
những chương trình xử lý thư điện tử sẽ tự động giải mã những thông báo này và
cho phép bạn lưu trữ dữ liệu chứa trong chúng vào đĩa cứng.
VI. HTTP ( Hypertext Transfer protocol ) : Giao thức truyền siêu văn bản .
Là một trong năm giao thức chuẩn về mạng Internet, được dùng để liên hệ thông
tin giữa Máy cung cấp dịch vụ (Web server) và Máy sử dụng dịch vụ (Web client)
là giao thức Client/Server dùng cho World Wide Web-WWW, HTTP là một giao
thức ứng dụng của bộ giao thức TCP/IP (các giao thức nền tảng cho Internet).
Cấu trúc của HTTP Message
HTTP là một giao thức kiểu client/server; client đưa ra các request, và server sẽ trả
lời các request này. Cấu trúc các HTTP message vì thế cũng thay đổi theo yếu tố
này. Có một định dạng cho HTTP request và cho các response.
1.HTTP Request
Mỗi request bắt đầu với một Request-Line. Dòng này chỉ ra phương thức mà client
yêu cầu, tài nguyên, và phiên bản của HTTP mà client có thể hỗ trợ. Request-Line
có thể có tiếp sau một hay nhiều header và một message body.
Một HTTP request bắt đầu với một Request-Line và có thể bao gồm các header và
message body. Phần header có thể mô tả quá việc truyền dữ liệu, xác định các yêu
cầu hay phần message body kèm theo.
GET / HTTP/1.1
Accept: */*
Accept-Language: en-us A
ccept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Host: www.ft.com
Connection: Keep-Alive
Request-Line chứa ba mục phân biệt, đó là method, uri, và phiên bản HTTP, mỗi
mục được phân tách bởi một hay nhiều khoảng trống.
Một HTTP Request-Line có một phương thức, một địa chỉ định danh tài nguyên
(URI), và thông báo phiên bản HTTP.
Phương thức được xác định trên dòng đầu tiên của Request-Line. HTTP định nghĩa
tất cả là 8 phương thức. Một HTTP server chỉ được yêu cầu hỗ trợ các phương thức
GET và HEAD; nếu chúng hỗ trợ các phương thức HTTP khác, sự hỗ trợ đó phải
được gắn với các quy tắc của HTTP. Đặc tả HTTP cũng có các mở rộng để các
phương thức khác có thể được bổ sung trong tương lai.
Mục tiếp theo trong Request-Line là Request-uri. Mục này cung cấp địa chỉ định
danh tài nguyên cho một tài nguyên. Ví dụ, Request-uri là /, chỉ ra một request cho
tài nguyên gốc. Cho các request không yêu cầu một tài nguyên cụ thể (như là
TRACE request hay trong một số trường hợp cả OPTIONS request), client có thể
dùng một dấu * cho Request-uri.
Mục cuối cùng trong Request-Line là phiên bản HTTP. Như trong ví dụ, phiên bản
HTTP là 1.1 chứa trong đoạn text HTTP/1.1.
Tiếp sau Request-Line, một HTTP request có thể bao gồm một hay nhiều dòng
message header. Một message header có thể chứa các loại general header, request
header, hoặc entity header. General header áp dụng trong truyền dữ liệu; request
header áp dụng cho các request cụ thể, và entity header áp dụng cho message body
trong request.
Một HTTP request luôn chứa một dòng trống sau Request-Line và bất kỳ header
nào. Nếu request bao gồm một message body, phần body đi sau một dòng trống.
Dòng trống - blank line rất quan trọng vì server xác định được phần kết của
request, hoặc phần kết của header. Không có dòng trống, server nhận các message
sẽ không biết được các header khác nữa có tiếp tục được truyền không.
1. HTTP Response
HTTP Response khá giống với HTTP Request. Dấu hiệu khác biệt duy nhất là
response bắt đầu với một dòng trạng thái status so với Request-Line. Status-Line,
cũng giống như Request-Line, chứa ba mục ngăn cách bởi các khoảng trống.
Một HTTP response bắt đầu với một Status-Line và có thể chứa các header và một
message body. Header có thể mô tả quá trình truyền dữ liệu, xác định response,
hoặc phần body kèm theo.
Dòng bắt đầu với phiên bản cao nhất của HTTP mà server hỗ trợ.
HTTP/1.1 200 OK
Date: Sun, 08 Oct 2000 18:46:12
GMT Server: Apache/1.3.6 (Unix)
Keep-Alive: timeout=5, max=120
Connection: Keep-Alive
Content-Type: text/html
<html>...
HTTP Status-Line bắt đầu với chỉ báo HTTP, mã trạng thái, và một đoạn text mô tả
response.
Hai mục còn lại trong Status-Line là Status-Code và Reason-Phrase. Status-Code là
một bộ ba kí tự chỉ báo kết quả của request. Status-Code phổ biến nhất là 200. Giá
trị này thông báo yêu cầu của client thành công.
Phân loại HTTP Status Code
Header Field
HTTP request và response có thể có một hay nhiều message header. Message
header bắt đầu với tên trường và dấu (“:”). Trong một số trường hợp, chỉ có tên
trường trong phần header. Trong hầu hết các trường hợp khác header chứa các
thêm thông tin khác nữa, các thông tin này đi sau dấu “:”. Một message header kết
thúc ở cuối dòng, nhưng nếu một client cần biểu diễn nhiều hơn một dòng thì dòng
tiếp theo sẽ bắt đầu với một hay nhiều kí tự trống hay kí tự gạch ngang (ascii
character 8). Ví dụ sau là của User-Agent header:
GET / HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Host: www.ft.com
Connection: Keep-Alive
Nếu một message header chứa một chuỗi giá trị phân tách bởi dấu “,”; ta có thể
tách ra thành các dòng riêng, như ví dụ sau tách các giá trị của Accept-Encoding:
GET / HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip
Accept-Encoding: deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Host: www.ft.com
Connection: Keep-Alive
Bảng sau thể hiện các HeaderField, phạm vi áp dụng của chúng trong các request
hay response, hay trong message body (entity) đi kèm với request hay response.
Header General Request Response Entity
Accept ●
Accept-Charset ●
Accept-Encoding ●
Accept-Language ●
Accept-Ranges ●
Age ●
Allow ●
Authentication-Info ●
Authorization ●
Cache-Control ●
Connection ●
Content-Encoding ●
Content-Language ●
Content-Length ●
Content-Location ●
Content-MD5 ●
Content-Range ●
Content-Type ●
Cookie ●
Cookie2 ●
Date ●
Etag ●
Expect ●
Expires ●
From ●
Host ●
If-Match ●
If-Modified-Since ●
If-None-Match ●
If-Range ●
If-Unmodified- ●
Since ●
Last-Modified ●
Location ●
Max-Forwards ● ●
Meter ●
Pragma ●
Proxy-Authenticate ●
Proxy-
Authorization
●
Range ●
Referer ●
Retry-After ●
Server ●
Set-Cookie2 ●
TE ●
Trailer ●
Transfer-Encoding ●
Upgrade ●
User-Agent ●
Vary ●
Warning ●
WWW-Authenticate ●
HTTP Header Field
Status Code
Ý nghĩa
100-199 Informational; server nhận được request nhưng kết quả cuối cùng không sẵn có.
200-299 Success; server có khả năng thực hiện các yêu cầu.
300-399 Redirection; client có thể chuyển hướng request sang một server hay tài nguyên khác
400-499 Client error; request có lỗi.
500-599 Server error; server không thể thực hiện các yêu cầu ngay cả khi request hợp lệ.
Bảng phân loại HTTP Status Code
