Tải bản đầy đủ (.doc) (55 trang)

Giao thức sip trong voip( session initiation protocol-giao thức báo hiệu điều khiển)

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (2.82 MB, 55 trang )

BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƯỜNG ĐẠI HỌC KỸ THUẬT CÔNG NGHỆ TP. HCM
ĐỀ ÁN CƠ SỞ NGÀNH MẠNG MÁY TÍNH
GIAO THỨC SIP TRONG VOIP
( SESSION INITIATION PROTOCOL : GIAO
THỨC BÁO HIỆU ĐIỀU KHIỂN)
Giáo viên hướng dẫn : Ths.Nguyễn Đức Quang
Người thực hiện : Lê Võ Hồng Thanh
MSSV : 1081020097
TP. Hồ Chí Minh, 2011
1
MỤC LỤC
Lời Mở Đầu
I . Tổng quan về giao thức SIP
1. Tổng quan về RFC
2. Tổng quan về giao thức SIP
3. Nguồn gốc sự phát triển của SIP
II. Các thành phần bên trong mạng SIP
1. SIP User Agent
2. SIP Server
3. Mối liên hệ giữa các thành phần trong mạng SIP
4. Bản tin SIP
4.1 SIP Response
4.2 SIP Request
4.3 Các trường Header
4.4 Message Body
4.5 Cấu trúc bản tin SIP
5. Chức năng của SIP
5.1 Thiết lập,sửa đổi và kết thúc phiên
5.2 Tính di động của người sử dụng
6. Thiết lập và hủy cuộc gọi SIP


III. Các giao thức hỗ trợ trong SIP
1. RSVP ( Reource Revervation Protocol ) : Giao thức chiếm trước tài nguyên
mạng.
2. RTP ( Real Time Tranpsport Protocol ) : Giao thức vận chuyển thời gian thực
3. RTCP (Real-Time Transport Control Protocol)odd port-port lẻ
2
4. RTSP ( Real Time Streaming Protocol ) : Giao thức tạo luồng thời gian thực .
5. SDP ( Session Description Protocol ) : Giao thức mô tả phiên kết nối đa
phương tiện
6. MIME ( Multipurpose Internet mail Extension – Mở rộng thư tín Internet đa
mục đích
7. HTTP ( Hypertext Transfer protocol ) : Giao thức truyền siêu văn bản
IV. Kết luận
V . Demo
1. Mục tiêu và mô hình
2. Công cụ Demo
3. Các bước
4. Kết quả
3
LỜI CẢM ƠN
Trước hết em xin gửi tới thầy giáo Ths. Nguyễn Đức Quang , lời cảm ơn chân
thành và sâu sắc đã trực tiếp hướng dẫn , chỉ bảo tận tình trong suốt quá trình em làm đề
án này.
LỜI MỞ ĐẦU
Trước đây khi đề cập đến VoIP, tiêu chuẩn quốc tế thường đề cập đến là H.323. Giao thức
H.323 là chuẩn do ITU-T phát triển cho phép truyền thông đa phương tiện qua các hệ
thống dựa trên mạng chuyển mạch gói, tập giao thức H.323 bao gồm rất nhiều giao thức
con bên trong nó như H.245, H225, Q.931… hoạt động dựa trên H.323 là rất chặt chẽ và
phức tạp. Những năm trở lại đây thì giao thức SIP lại chiếm ưu thế và dần dần thay thế
H.323.

I. TỔNG QUAN VỀ GIAO THỨC SIP :
1. Tổng quan về RFC :
Trong kỹ thuật mạng máy tính, các tài liệu RFC (Request For Comments - RFC) là 1 loạt
các bản ghi nhớ chứa những nghiên cứu mới, những phương pháp luận ứng dụng cho
công nghệ internet.
Thông qua Hội đồng Internet (Internet Society) các kỹ sư và các nhà khoa học máy tính
có thể công bố luận văn dưới hình thức là một bản ghi nhớ RFC để cho những đồng
nghiệp khác phê bình hoặc chỉ đơn thuần là để thông báo những tin tức hoặc quan điểm
mới về mặt kỹ thuật. Tổ chức chuyên trách kỹ thuật liên mạng (IETF – Internet
Engineering Task Force) chấp nhận những lý thuyết đã được công bố trong các RFC và
đã được ứng dụng thực tế như là những tiêu chuẩn cho Internet.
Mỗi một bản RFC chỉ có duy nhất một số đăng ký,một khi số đăng ký đã được công bố
thì nó sẽ không bao giờ được sữa chữa hay bị hủy bỏ. Nếu cần được chỉnh sửa thì tác giả
của nó sẽ công bố các bản chỉnh sữa vì vậy các bản RFC bị lỗi thời bởi những bản mới
4
hơn của chính nó. Hàng loạt các RFC đã đăng ký hình thành nên lịch sử tiến triển của tiêu
chuẩn Internet .
Tiến trình kiến tạo RFC không giống với những tiến trình tiêu chuẩn hóa do những tổ
chức chính quy về tiêu chuẩn như ANSI thường làm. Những chuyêng gia về kỹ thuật
mạng và truyền thông có thể tự đề bạt một bản dự thảo Internet (Internet Draft) mà không
cần sự hỗ trợ từ những cơ quan bên ngoài. Những bản RFC được công nhận thường được
công bố với sự phê chuẩn của IETF và đa số là do những chuyên gia tham dự trong các
nhóm điều hành của IETF thi hành. Khi mới bắt đầu chúng chỉ là những bản dự thảo
Internet, cách xắp xếp này cho phép những bản dự thảo này được thông qua những vòng
thăm dò ý kiến ban đầu từ những đồng nghiệp trước khi tài liệu được hoàn thành và thanh
lọc để trở thành những bản RFC.
Truyền thống của RFC là dựa vào tính thực dụng, kinh nghjệm từng trải, quyền tiêu
chuẩn hóa những bản thảo thông qua thực tế đạt được bởi các cá nhân hoặc một nhóm
cộng tác nhỏ. Điều này có ưu điểm đó là hơn rất nhiều so với quy trình chính quy do hội
đồng điều khiển mà chúng ta thường thấy ở ANSI hoặc ISO.

Các bản RFC đã từng nổi tiếng vì chất lượng của chúng. Trong các bản RFC chúng ta vừa
không gặp những sự nhập nhằng,khó hiểu là một vấn đề phổ biến trong các bản thiết kế
dự thảo, vừa không có những chức năng ngoài dự kiến do sai lầm của hội đồng gây ra đó
là những điều ám ảnh đối với các tiêu chuẩn chính quy. Và chúng đang mở đường cho
một mạng lưới đang phát triển tới tầm cỡ toàn cầu.
Hình thức RFC được khởi đầu vào năm 1969, khi nó là một phần trong hội thảo của dự án
ARPANET. Hiện nay, nó là kênh công bố chính thức của IETF, của Ủy Ban Kiến Trúc
Mạng ( Internet Architecture Board – IAB) và ở mức độ nào đó là của cộng đồng những
kỹ sư nghiên cứu về mạng lưới truyền thông máy tính toàn cầu.
Những bản RFC đầu tiên được tác giả của chúng đánh bằng máy đánh chữ và truyền tay
các bản in giữa nhóm những kỹ sư nghiên cứu tại ARPA. Tháng 12 năm 1969, các kỹ sư
nghiên cứu phân phát các bản RFC mới thông qua mạng lưới truyền thông ARPANET.
Bản RFC đầu tiên với đề tài Phần Mềm Dành Cho Máy Chủ (Host Software), được Steve
5
Crocker, một sinh viên của trường đại học California, Los Angeles ( UCLA) viết và được
công bố vào ngày 07 tháng 04 năm 1969. Trong phiên bản RFC số 3, Steve Crocker đã
đặt các bản RFC dưới quyền của “Nhóm Điều Hành Mạng – Network Working Group“,
nhóm này chưa bao giờ tồn tại chính thức mà chỉ được định nghĩa là “nhóm người này”
nhưng sự ủy quyền của “họ” vẫn tồn tại trong các RFC cho đến nay. Trường đại học
UCLA tiếp tục cho ra đời nhiều bản RFC trong những năm 1970 không những vì chất
lượng của chúng cao mà còn vì UCLA là một trong những điểm kết nối mạng đầu tiên
của ARPANET.
Từ năm 1969 đến 1998, ông Jon Postel làm chủ biên tập RFC. Sau khi hết hạn hợp đồng
tài trợ của chính phủ Mỹ, hội đồng Internet (thay mặt cho IETF) ký hợp đồng với chi
nhánh điều hành mạng (Networking Division) của trường đại học Nam California (USC)
đứng ra làm quyền biên tập và chịu trách nhiệm về việc xuất bản.
Mọi người đều có thể tiếp cận bất kỳ một bản RFC nào tại website chính thức của chủ
biên RFC : .
Hầu hết các bản RFC đều hiện hiện hữu ở dạng ASCII, đồng thời cũng có ở một số định
dạng khác. Từ năm 2006 trở đi bất kỳ một đặc tả tiêu chuẩn internet nào cũng đều ở dưới

dạng ASCII. Không phải bất kỳ bản RFC nào cũng là tiêu chuẩn, chỉ có nhóm IETF đại
diện cho nhóm chỉ đạo kỹ thuật kết nối mạng ( Internet Engineering Stearing Group –
IESG) là có quyền chuẩn y các bản RFC có thể trở thành tiêu chuẩn. Cấp bậc của các
RFC bao gồm : Đề nghị (Proposed – PS), dự thảo (Draft – DS), bảng đầy đủ (Full) – Tiêu
chuẩn Internet (Internet Standart – STD). Mỗi một biên tập phụ, thuộc một tiêu chuẩn
STD nào đó đều có một mã số riêng. Kể từ năm 2006 thì tiêu chuẩn số 1 là RFC3700.
Một số các STD tạo thành nhiều nhóm nhỏ, gồm những RFC có liên quan với nhau.
Một bản RFC thử nghiệm có thể là một tài liệu của IETF, hoặc một bản đệ trình cá nhân
lên chủ biên RFC. Trên lý thuyết, thực trạng các bản tài liệu như cái tên của nó ám chỉ - chỉ là
những “ đề nghị duyệt thảo và bình luận “ ( Request For Comments ). Trên thực tế ,một số bản tài
liệu không được nâng lên mức tiêu chuẩn vì không có người tình nguyện thực hành những chi tiết
cụ thể trong thủ tục. Một số tài liệu quan trọng cũng chỉ tồn tại như một “Bản Thảo Internet”,
trong khi có những bản RFC chính quy lại trở nên lỗi thời .
6
Một bản RFC tin tức (news) có thể là bất cứ thứ gì, từ những bản RFC hài hước ( những bản này
được công bố vào ngày 1-4 – Ngày nói đùa ) về những giao thức sở hữu cho đến những bản RFC
chủ chốt được nhiều người biết đến như RFC 1591. Một số bản RFC tin tức được nhóm lại thành
một loạt các bài “ tin tức đáng chú ý” (For Your Information – FYI). Tuy nhiên hiện nay ít ai
đăng thêm, một số FYI cũ vẫn còn rất thú vị như FYI 18 hay còn gọi là RFC 1983 bản “ từ vựng
dành cho người dùng Internet” (Internet User’s Glossary)
Một bản RFC tồn kho (historic) là một bản lỗi thời và đã có bản RFC khác thay thế nó. Những
bản này nói về một giao thức đã không còn được để ý trong hoàn cảnh Internet hiện tại hoặc đã bị
đưa ra khỏi mức tiêu chuẩn hóa vì một lý do nào đó. Một số các RFC lỗi thời còn không được liệt
kê trong danh sách các bản tồn kho, vì “ tiến trình tiêu chuẩn hóa “ (Internet Standards Process)
thường không cho phép những tham chiếu có tính quy chuẩn (normative references) đối với một
RFC đang được tiêu chuẩn hóa, từ một bản RFC có cấp độ thấp hơn. Đồng thời ít người chú ý
đến việc giải quyết những chi tiết thủ tục yêu cầu, để những bản RFC được phân loại là tồn kho,
và những thay đổi được đánh dấu vào tất cả các RFC phụ thuộc vào nó.
Dạng vô danh thường được đặt cho những bản RFC quá cũ không rõ cấp bậc là gì nếu phải công
bố. Trong một vài trường hợp những RFC đó còn hoàn toàn không được công bố. Những RFC cũ

thường chỉ là những bản “ yêu cầu duyệt thảo và bình luận “, không chú trọng việc đặc tả một
giao thức, một chu trình quản lý hoặc bất cứ một thứ gì khác mà các RFC hiện nay đang được
dùng để thực hiện.
2. Tổng quan về 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 .
7
− 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 .
− Phần mào đầu ( Headers ) – Mô tả về phiên truyền thông .

− Phần thông tin báo hay còn gọi là phần thân ( Message Body ) – SDP , ký tự
, XML .
3. Nguồn gốc 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 Internet
( 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 : nó là 1
giao thức dựa trên ý tưởng và cấu trúc của HTTP (HyperText Transfer Protocol) là giao
thức trao đổi thông tin của World Wide Web (WWW) và là 1 phần trong kiến trúc
Multimedia của IETF. 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. Các giao thức có liên quan đến SIP bao gồm :
- Giao thức đặt trước tài nguyên RSVP ( Resource Reservation Protocol )
8
- Giao thức truyền vận thời gian thực RTTP ( Real Time Transfer Protocol )
- Giao thức cảnh báo phiên SAP ( Session Announcement Protocol )
- Giao thức miêu tả phiên SDP ( Session Description Protocol )
Các chức năng của SIP là độc lập và không phụ thuộc vào bất kỳ giao thức nào thuộc các
giao thức trên. Mặt khác SIP có thể hoạt động hỗ trợ với các giao thức báo hiệu khác như
H.323 . SIP là một giao thức theo thiết kế mở do đó nó có thể mở rộng thêm các chức
năng mới. Sự linh hoạt của bản tin SIP cũng cho phép đáp ứng các dịch vụ thoại tiên tiến
bao gồm cả các dịch vụ di động.
Một bản tin SIP có hai phần, phần mào đầu ( Headers ) và phần thân ( Message Body ).
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 Project 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 Inter-networking), SPIRITS (PSTN/IN
requesting Internet Services).
II. Các thành phần bên trong mạng SIP :
Thành phần của SIP : bao gồm SIP User Agent ( UA ) và SIP server .
1. SIP User Agent:
9
SIP UA hoặc thiết bị đầu cuối là điểm cuối của dialog : SIP UA gửi - 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 – 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 :
− User Agent Client ( UAC ) : ứng dụng của người gọi – khởi tạo yêu cầu (request )
− User Agent Server ( UAS ) : chấp nhận , gửi lại , từ chối yêu cầu ( request ) và gửi
trả lời cho request đến thay mặt cho người gọi.
UA là thực thể SIP mà tương tác với người sử dụng bằng giao diện.
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 , Redirect 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 làm nhiệm vụ
chuyển tiếp các request tới thực thể khác trong mạng, như vậy chức năng chính của nó
trong mạng là định tuyến cho các bản tin đến đích. Tuy nhiên các Proxy SIP sử dụng
10
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. Các Proxy Server cũng cung cấp các chức năng khác 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ờ. Một Proxy có thể lưu (stateful) hoặc không lưu trạng thái (stateless)
của bản tin trước đó, thông thường thì Proxy có lưu trạng thái và chúng duy trì trạng thái
đó trong suốt Transaction (khoảng 32 giây). 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).
 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ị là 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ề .
 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 .
 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 .
11
3. Mối liên hệ giữa các thành phần trong mạng SIP
Trong ví dụ thứ nhất, cho ta có một cái nhìn khái quát về chức năng của Proxy
Server, Redirect Server, SIP Phone trong mạng. Giả sử thuê bao có tên user1 trong
miền dịch vụ do here.com muốn thực hiện một cuộc gọi thoại tới thuê bao có thể là
user2 ( thuộc there.com)
12
Chức năng của Proxy, Redirect Server trong mạng SIP
1. Khi User 1 muốn gọi tới User 2, trước hết nó sẽ gửi bản tin INVITE 1 đến
Proxy Server 1. Proxy Server 1 chuyển tiếp bản tin tới Redirect Server.
2. Redirect Server này xử lý và trả về mã 3xx thông báo cho Proxy Server tự thực
hiện kết nối.
3. Proxy Server 1 gửi bản tin INVITE 2 tới đích trả về bởi Redirect Server ( chính là
Stateless Proxy Server 1). Vì đây là Stateful Proxy nên thực chất bản tin INVITE
được gửi bởi Stateful Proxy là khác so với bản tin nhận được từ User1(ban đầu).

4. Stateless Proxy Server chuyển tiếp bản tin INVITE tới SIP Statefull Proxy 2.
Do là Stateless Proxy nên công việc của nó đơn giản là chuyển tiếp bản tin.
5. SIP Statefull Proxy 2 chuyển tiếp bản tin INVITE tới user2.
6. Khi user2 nhấc máy thì nó sẽ gửi bản tin 200 OK theo chiều ngược lại.
7. Sau khi nhận được bản tin 200 OK, user1 sẽ gửi xác nhận ACK tới user2.
8. Luồng RTP trực tiếp giữa hai thuê bao được thiết lập. Và cuộc gọi được thực
hiện.
Trong ví dụ thứ hai sẽ mô tả quá trình một SIP Phone đăng kí với với
Regi
s
tra
r
Server quản lý nó,hoạt động của Location Server, Proxy Server.
13
Chức năng của Location, Registrar Server trong mạng SIP
Khi một SIP Phone được kết nối với mạng. Nó liên tục gửi bản tin REGISTER
tới Registrar Server để thông báo vị trí hiện tại của nó. Giả sử trong miền dịch vụ có
tên chicago.com thì quá trình REGISTER (đăng kí) được tiến hành như sau:
1. Thuê bao có tên Carol gửi bản tin REGISTER tới Registrar Server.Server
này tiến hành xác thực. Nếu hợp lệ thì các thông tin đó được lưu trong Location
Server.
2. Khi một thuê bao khác (có tên là Bob) gửi bản tin INVITE tới Proxy Server
để xin kết nối tới thuê bao Carol. Proxy Server sẽ truy vấn các thông tin về thuê
bao bị gọi thông qua Location Server.
3. Proxy Server gửi bản tin INVITE tới thuê bao Carol để thiết lập cuộc gọi.
4. Bản tin SIP
Thông điệp SIP gồm 3 phần: start line, header của thông điệp và body.
14
Client gửi yêu cầu (request) và server trả lời bằng response. 1 phiên của SIP bao gồm
yêu cầu từ client, 0 hoặc nhiều provisional response và final response từ server.

4.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
15
• 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ác lớp Response Mã trả về Mô tả
Thông tin 100
Đang thực hiện kết nối
180 Đang đổ chuông
181

Cuộc gọi đang được chuyển tiếp
182 Được đặt vào hàng đợi
183
Phiên đang được xử lý
Thành công 200 Thành công
Chuyển hướng
300 Nhiểu lựa chọn
301 Chuyển vĩnh viễn
16
302 Chuyển tạm thời
305 Sử dụng proxy
380 Dịch vụ khác
Lỗi Client 400 Yêu cầu không hợp lệ
401 Không nhận dạng được
402 Yêu cầu thành toán
403 Bị cấm
404 Không tìm thấy
405 Phướng thức không được phép
406 Không chấp nhận
407 Yêu cầu xác thực Proxy
408 Request timeout
410 Đã dời đi
413 Yêu cầu quá dài
414 URL được yêu cầu quá lớn
415 Không hỗ trợ kiểu media
416 Không hỗ trợ URI
420 Phần mở rộng lỗi
421 Yêu cầu phần mở rộng
423 Khoảng thời gian giữa hai sự kiện quá ngắn
480 Tạm thời chưa sẵn sàng

481 Transaction không tồn tại
482 Phát hiện thấy “loop” (chu trình)
483 Quá nhiều “hop”
484 Địa chỉ không đủ
485 Mật mở không rõ ràng
486 Đang bận
487 Yêu cầu bị hủy
488 Không thể chấp nhận tại đây
491 Yêu cầu chưa được giải quyết
Lỗi Server 500 Lỗi nội tại trong server
501 Chưa được thực hiện đầu đủ
502 Gateway lỗi
503 Dịch vị không tồn tại
17
504 Server timeout
505 Phiên bản SIP không được hỗ trợ
513 Bản tin quá lớn
Lỗi toàn cục
600 Bận ở khắp mọi nơi
603 Suy sụp
604 Không tồn tại
606 Không thể chấp nhận
4.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
4.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.
4.4 Message Body
18
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.5 Cấu trúc bản tin SIP
 B ả

n tin Re

q u es

t:
INVITE s i p:b o b @

p r


oxy .c

o mp a n y .c

om SIP/2.0
Via: SIP/2.0/UDP
ph1.company.com:5060;branch=z9hG4bK83749.1
From: Alice <s

ip:ali c e@c

om p a

ny .c

om >;tag=1234567
To: Bob <s

ip:bob@p r oxy . c

ompany . c

om>
Call-ID: 1234560 1 @

ph1 . c

ompany . c

om

CSeq: 1 INVITE
Contact: <s

ip : a

lic e@

ph 1 .c

ompan y .c

om>
Content-Type: application/sdp
INVITE s i p:b o b @

p r

oxy .c

o mp a n y .c

om SIP/2.0
Content-Length:
v=0
o=alice 2890844526 28908445456 IN IP4 172.18.193.102
s=Session SDP
c=IN IP4 172.18.193.102 t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
 B ả


n tin R

e s

pon se

:
19
SIP/2.0 200 OK
Via: SIP/2.0/UDP
ph1.company.com:5060;branch=z9hG4bK83749.1
From: Alice <s

ip:alic e

@ c

ompan y .c

om >;tag=1234567
To: Bob <s

ip:bob@p r oxy .c

ompan y .c

om >;tag=9345678
Call-ID: 12345601 @


ph 1 .c

ompan y .c

om
CSeq: 1 INVITE Content-
Length:
v=0
o=bob 3800844316 3760844696 IN IP4 172.18.193.109
s=Session SDP
c=IN IP4 172.18.193.109 t=0 0
m=audio 48140 RTP/AVP 0
a=rtpmap:0 PCMU/8000
 Ý nghĩa c

ủa c

á c t rư ờ

ng t r ong b ả

n tin:
Tiêu đề SIP Mô tả
From Thường là AOR(Address of Record) của người gửi. Nó bao gồm SIP hoặc
SIPS URI và với tùy chọn tên được hiển thị.
To Mô tả người nhận của bản tin SIP, AOR của người nhận. Với chức
năng forward hay redirect thi đanh không phải là địa chỉ người nhận.
Trường này giống trường From.
Call-ID Định nghĩa series của bản tin SIP. Call-ID phải được xác định trong
mọi bản tin SIP được gửi bởi tất cả các UA trong một dialog.

Cseq Chứa một giá trị nguyên và tên phương thức. Trường này dùng để xác
định, săpx xếp, đánh dấu chuỗi SIP request trong một dialog. Cseq có
thể khác nhau giữa bản tin được truyền lại và truyền mới.
Via Xác định đường đi được chỉ ra request và các response sẽ được gửi.
Contact Chứa SIP hoặc SIPS URI của UA muốn nhận được SIP request mới.
20
Allow Liệt kê tập các phương thức SIP được hỗ trợ bởi UA.
Supported Liệt kê tập các phần mở rộng của SIP hỗ trợ bởi UA.
Require
Trường này rất giống như trường Supported nhưng là của các UA ở
xa cần thiết cho một transaction được xử lý.
C
ontent-
Type
Kiểu của phần thân của bản tin SIP (nếu có phần thân)
Content-
Length
Kích thức của phần thân bản tin SIP. Trường này là bắt buộc khi bản tin
SIP được truyền trên TCP.
5. Chức năng của SIP
5.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.
21
5.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:
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:, 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:
) 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.
6. 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)
22
Hoạt động của Proxy server được trình bày như trong hình ….Client SIP
gửi bản tin INVITE cho để mời tham gia cuộc
gọi.
Các bước như sau:
+ Bước 1: gửi bản tin INVITE cho UserB ở miền hostmail.com, bản
tin này đến proxy server SIP của miền hostmail.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
hostmail.com).
+ Bước 2: Proxy server của miền hostmail.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 Proxy server thêm
địa chỉ của nó trong một trường của bản tin INVITE.
23
+ 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ề
+ Bước 7: 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
+ 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.
24
+ 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.
III- Các giao thức hỗ trợ trong SIP
Các giao thức khác của IETF 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ở .
1. RSVP ( Reource Revervation Protocol ) : Giao thức chiếm trước tài nguyên
mạng
25

×