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

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.

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ũ

− 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)

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.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

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

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


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 @


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,

+ 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.