Nghiên cứu giao thức thiết lập phiên ( SIP ) ứng dụng cho xây dựng hệ thống dịch vụ IP Centrex

LỜI CẢM ƠN
Trước khi đi vào nội dung chính của luận văn, em xin chân thành cảm ơn
Tiến sĩ Hoàng Minh, phó giám đốc Học viện Bưu chính Viễn thông, người đã hết
sức tạo điều kiện về thời gian và công việc cũng như đã giúp đỡ và hướng dẫn
em rất nhiều trong quá trình thực hiện và hoàn thiện đề tài. Em xin chân thành
cảm ơn các thày, cô giáo khoa Công nghệ thông tin – Trường Đại học công nghệ
- Đại học Quốc Gia Hà Nội đã chỉ dạy và cung cấp các kiến thức cơ bản trong
suốt khóa học. Các kiến thức nền tảng này đã giúp em rất nhiều trong việc
nghiên cứu và thiết kế các mô hình hệ thống cũng như lập trình các thành phần
phần mềm. Em xin chân thành cảm ơn các anh lãnh đạo Trung tâm Công nghệ
Thông tin CDiT, học viện Công nghệ Bưu chính Viễn thông nơi em công tác, đã
tạo điều kiện về công việc để cho em có thêm nhiều thời gian thực hiện nghiên
cứu. Tôi cũng xin chân thành cảm ơn các anh chị em đồng nghiệp tại Trung tâm
Công nghệ Thông tin CDiT và các anh chị tại Công ty cổ phần đầu tư phát triển
công nghệ và truyền thông – NEO, những người đã cổ vũ, động viên và giúp đỡ
tôi rất nhiều về mặt kỹ thuật trong quá trình thực hiện đề tài nghiên cứu. Xin
chân thành cảm ơn bạn bè và gia đình đã động viên, giúp đỡ tôi trong suốt quá
trình học tập nghiên cứu để thực hiện thành công luận văn tốt nghiệp này.

Hà Nội – tháng 11 năm 2006
Đỗ Đức Huy

-1-

MỤC LỤC
LỜI CẢM ƠN 1
MỤC LỤC 1
DANH SÁCH HÌNH VẼ 3
BẢNG CÁC TỪ VIẾT TẮT, THUẬT NGỮ 5

MỞ ĐẦU 8
1. Đặt vấn đề 8
2. Phương pháp nghiên cứu 10
3. Nội dung báo cáo 10
Chương 1: TỔNG QUAN VỀ GIAO THỨC SIP 12
1.1. Giới thiệu giao thức 12
1.1.1. Lịch sử phát triển 12
1.1.2. SIP và H323 13
1.1.3. Vai trò của SIP trong mạng viễn thông 15
1.2. Đặc điểm kỹ thuật của giao thức SIP 18
1.2.1. Các đặc điểm kỹ thuật chính 18
1.2.2. Cấu trúc giao thức 30
Chương 2: CÁC VẤN ĐỀ VÀ KHẢO SÁT THỰC NGHIỆM 36
2.1. Một số vấn đề thực tế với SIP 36
2.1.1. Ảnh hưởng của NAT 36
2.1.2. Các giải pháp vượt qua NAT 38
2.1.3. Ảnh hưởng của firewall 42
2.2. Các khảo sát thực nghiệm 43
2.2.1. Các SIP softphone 44
2.2.2. Các SIP server 45
Chương 3: IP CENTREX – MÔ HÌNH VÀ CÁC THÀNH PHẦN 47
3.1. Tổng quan về IP Centrex 47
3.1.1. Khái niệm chung 47
3.1.2. Vị trí và chức năng của IP Centrex trong mạng NGN 52
3.1.3. Cơ hội phát triển ở Việt Nam 58
3.2. Nghiên cứu một số giải pháp về IP Centrex 58
3.2.1. Cấu trúc tổng thể hệ thống IP-Centrex 58
3.2.2. Một số cấu trúc điển hình 59
3.2.3. Phân tích và lựa chọn giải pháp 67
Chương 4: ỨNG DỤNG SIP TRONG HỆ THỐNG IP-CENTREX 70

4.1. Mô hình thiết kế tổng thể hệ thống IP Centrex 70
4.1.1. Mô hình hóa hệ thống 70
4.1.2. Yêu cầu bài toán 73
4.2. Đề xuất giải pháp và mô hình thiết kế tổng thể 74
4.3. Thiết kế chi tiết các module hệ thống 75
4.3.1. Phân hệ mạng 75
4.3.2. Phân hệ media 84
-2-

4.3.3. Phân hệ dịch vụ 85
4.3.4. Phân hệ OAM 89
4.3.5. Các dịch vụ của IP-Centrex 90
Chương 5: THỬ NGHIỆM HỆ THỐNG 92
5.1. Mục tiêu thử nghiệm 92
5.2. Mô hình hệ thống thử nghiệm 92
5.3. Nội dung thử nghiệm 92
5.3.1. Dịch vụ Call Forward – Busy 93
5.3.2. Dịch vụ Single-Line Extension 93
5.3.3. Dịch vụ music-on-hold 94
5.4. Kết quả thử nghiệm 94
KẾT LUẬN 95
TÀI LIỆU THAM KHẢO 97
Tài liệu tiếng Anh 97
Địa chỉ các trang WEB 97

-3-

DANH SÁCH HÌNH VẼ
Hình 1. Vị trí của SIP trong mô hình NGN 17
Hình 2. Lưu đồ đăng ký vị trí 25

Hình 3. Lưu đồ thiết lập phiên 27
Hình 4. SIP stack 30
Hình 5. Tìm gọi không thành công do NAT timeout 38
Hình 6. Vị trí của STUN server trong hệ thống SIP 39
Hình 7. Lỗi chuyển đổi địa chỉ ngẫu nhiên 41
Hình 8. Mô hình dịch vụ Centrex truyền thống 47
Hình 9. Mô hình hệ thống cung cấp dịch vụ IP-Centrex 49
Hình 10. Vai trò vị trí của IP Centrex trong NGN 56
Hình 11. Cấu trúc tổng thể hệ thống IP Centrex 58
Hình 12. Kiến trúc hệ thống IP Centrex dựa trên chuyển mạch Class 5 60
Hình 13. Cấu trúc hệ thống IP Centrex sử dụng chuyển mạch mềm SoftSwitch 62
Hình 14. Nguyên tắc xử lý cuộc gọi có dịch vụ trong Softswitch 62
Hình 15. Hoạt động của một số dịch vụ dựa trên Softswitch 63
Hình 16. Hướng xử lý cuộc gọi trong mô hình IP Centrex sử dụng Softswitch 63
Hình 17. Giải pháp IP Centrex sử dụng Softswitch của LongBoard 64
Hình 18. Giải pháp IP Centrex sử dụng Softswitch của Convedia 65
Hình 19. Cấu trúc hệ thống IP Centrex sử dụng Call Server 65
Hình 20. Giải pháp IP Centrex của GlobalTech 66
Hình 21. Kiến trúc phát triển dịch vụ trong hệ thống SURPASS của Siemens 67
Hình 22. Mô hình tương tác giữa các tác nhân trong và ngoài IP Centrex 70
Hình 23. Thiết kế tổng thể phần mềm hệ thống IP-Centrex 74
Hình 24. Hướng cuộc gọi trong IP Centrex 75
Hình 25. Cấu trúc phần mềm phân hệ mạng 76
Hình 26. Lưu đồ xử lý client transaction 80
Hình 27. Lưu đồ xử lý server transaction: 81
Hình 28. Thiết kế phần mềm phân hệ media 84
Hình 29. Thiết kế phần mềm phân hệ dịch vụ 85
-4-

Hình 30. Mô hình hệ thống 89

Hình 31. Mô hình thử nghiệm IP-Centrex 92

-5-

BẢNG CÁC TỪ VIẾT TẮT, THUẬT NGỮ
ACD
Automatic Call Distribution
AIN
Advanced Intelligent Network
API
Application Programming Interface
BER
Bit Error Rate
CDMA
Code Division Multiplexing Access
Centrex
Central Office Exchange Service
CFB
Conference Block
CGI
Common Gateway Interface
CHB
Call Handling Block
CO
Central Office
CRC
Cycle Redundance Check
CSB
Call Setup Block
CTI

Computer Telecommunication Intergrated
DHCP
Dynamic Protol
ETSI
Euro Telecommunication Institutre
FMC
Fix to Mobile Convergence
GSM
Global System for Mobile Communications
GUI
Graphic User Interface
HTTP
Hyper Text Tranfer Protocol
IETF
Internet Engineering Task Force
IN
Intelligent Network
IP
Internet Protocol
IPC
Inter-Process Communication
ISDN
Intergrated Services Digital Network
ITU
International Telecommunication Union
IVR
Interactive Voice Response
LAN
Local Area Network
LMAP

Lightweight MTA Authentication Protocol
LS
Location Service
MGCP
Media Gateway Control Protocol
-6-

MMI
Man-Machine Interface
MML
Man-Machine Language
NAT
Network Address Translation
NATP
Network Address Translation Protocol
NGN
Next Generation Network
OAM
Operation and Management
OSA
Open Service Architecture
PBX
Private Branch Exchange
PDA
Personal Data Assistant
PSTN
Public Switched Telephone Network
QoS
Quality of Service
RAS

Remote Access Server
RSVP
Resource ReSerVation Protocol
RTC
Realtime Comunication
RTCP
Real Time Control Protocol
RTP
Real Time Protocol
RTSP
Real Time Streaming Protocol
SCIP
Simple Conference Invitation Protocol
SDP
Session Description Protocol
SIP
Session Initation Protocol
SNMP
Simple Network Management Protocol
SPS
SIP Proxy server
STUN
Simple Traversal of UDP through NAT
TCP
Transmission Protocol
TDMA
Time Division Multiplexing Access
TFTP
Trivival File Tranfer Protocol
TLS

Transport Layer Protocol
TU
Transaction User
UAC
User Agent Client
UAS
User Agent Server
UDP
User Datagram Protocol
URI
Uniform Resource Identifier
-7-

URL
Uniform Resource Locator
VNPT
Vietnam Posts and Telecomunications
VoIP
Voice over IP
VPN
Virtual Private Network
XML
Extended Markup Language
-8-

MỞ ĐẦU
1. Đặt vấn đề
Central office exchange service – Centrex – là một hệ thống cung cấp dịch vụ đặt tại
phía tổng đài nhằm cung cấp các dịch vụ thoại (như quay số tắt, chặn số gọi, tạm ngừng
cuộc gọi…) tương tự như một hệ thống tổng đài PBX. Dịch vụ này đã được triển khai từ

đầu những năm 1960 với các hệ thống analog và ISDN nhằm cung cấp các đường truyền
thuê riêng để tổ chức nên các nhóm thoại riêng biệt cho từng tổ chức đơn vị sử dụng. Do
có nhiều lợi ích nên thời gian đầu hệ thống nhận được sự hưởng ứng và phát triển mạnh.
Nửa cuối những năm 1990, với xuất hiện của công nghệ Voice over IP, chi phí cho
các dịch vụ viễn thông giảm đã ảnh hướng lớn đến sự phát triển của các hệ thống Centrex
truyền thống. Mặt khác, dịch vụ Centrex truyền thống cũng không đáp ứng được những
đòi hỏi ngày càng cao của người sử dụng theo xu hướng hội tụ của viễn thông và internet.
Sự ra đời của IP Centrex là một hướng tất yếu nhằm thay thế dần cho các hệ thống dịch
vụ truyền thống. Thay vì sử dụng công nghệ chuyển mạch kênh PSTN truyền thống, IP
Centrex sử dụng IP làm cơ sở truyền dẫn nhằm kết hợp cả mạng thoại và mạng dữ liệu,
làm tăng hiệu quả hoạt động của hệ thống và mở rộng mức độ cung cấp dịch vụ từ cục bộ
lên mức toàn cầu.
Hiện nay, một thành phần ngày càng trở nên thiết yếu và đóng vai trò quan trọng
trong IPCentrex đó là giao thức khởi tạo phiên SIP. Vốn được thiết kế để phục vụ cho IP
phone, nhưng SIP không chỉ đơn giản là một giao thức telephony mà cũng rất phù hợp
cho các ứng dụng multimedia, đặc biệt là đối với messaging. Các SIP server có thể liên
kết với nhau tạo nên môi trường dịch vụ trên phạm vi rộng, có thể phối hợp với các
gateway để đạt tới các vùng dịch vụ non-SIP, cũng như có thể cung cấp dịch vụ với các
media server, feature server phù hợp. Trước kia, trong các hệ thống Centrex truyền thống
cũng như với hiện trạng hệ thống mạng viễn thông, người ta chủ yếu sử dụng giao thức
H323, việc nghiên cứu ứng dụng SIP còn chưa được chú ý. Hiện nay, ngày càng nhiều
các hãng danh tiếng trên thế giới như BroadSoft, LongBoard… đã chú trọng đến nghiên
cứu SIP để ứng dụng vào các hệ thống của họ, đặc biệt là hệ thống IP Centrex.
Các bản tin SIP sử dụng định dạng text rất gần gũi với HTTP. Định dạng text cho
phép dễ dàng mở rộng nội dung của bản tin, dễ theo dõi hoạt động, cũng như tái sử dụng
lại các mô hình đã thành công với HTTP (chẳng hạn mô hình servlets, digest
authentication). Tuy nhiên định dạng text cũng gây nhiều khó khăn đối với người phát
-9-

triển chưa có nhiều kinh nghiệm, vì sự linh hoạt luôn tỷ lệ nghịch với sự chặt chẽ trong cú

pháp.
Sự linh hoạt của SIP có được là do tính độc lập của nó. Bản thân SIP chỉ định nghĩa
các thủ tục để thiết lập các phiên kết nối giữa các cặp SIP client (end-to-end), trong khi
hoạt động của dịch vụ cũng như đặc điểm media là tùy thuộc vào client và dựa trên các
chuẩn khác (chẳng hạn RTP/RSVP, SDP, audio codecs). Nói cách khác, SIP là một chuẩn
mở.
Các chuẩn viễn thông truyền thống thường là rất chi tiết và chặt chẽ, đầy đủ tới tận
mức ứng dụng. Điều này hạn chế tính mở, tuy nhiên theo các chuyên gia thì đây lại là một
trong những lý do mà H.323 sớm chiếm được ưu thế trong thị trường Internet phone.
Trong khi đó SIP được thiết kế để có thể tồn tại lâu dài, dễ dàng thích nghi và tiến hóa. Ví
dụ đơn giản như chẳng hạn sau này xuất hiện một giao thức kiểm soát QoS hiệu quả hơn
RSVP, việc bổ sung giao thức mới vào ứng dụng sẽ được thực hiện độc lập với SIP. Quan
điểm mở của SIP khuyến khích nhà phát triển mạnh dạn chuẩn bị trước các nền tảng cho
đầu cuối của họ mà không ngại bị lỗi thời, chẳng hạn như Microsoft đã tích hợp SIP stack
vào trong kiến trúc RTC client của hệ điều hành Windows XP, sẵn sàng cho việc phát
triển các ứng dụng SIP-based phía người dùng cuối.
Hiện nay ở trong nước, khi mà VoIP mới được đưa vào khai thác chưa lâu và đều dựa
trên H.323, thì SIP hầu như còn chưa được biết đến. Tuy nhiên trên thế giới thị trường
SIP hiện đang đạt mức tăng trưởng khoảng 66% với dự báo sẽ đạt 2,2 tỷ USD trong năm
nay (số liệu từ IDC, 2003), trong đó phần lớn là từ các doanh nghiệp sử dụng SIP-enabled
IP PBX. Các nghiên cứu ứng dụng và mở rộng SIP cũng đã và đang được tiến hành từ hai
năm nay, với mục tiêu khuyến khích ứng dụng giao thức này trong nhiều lĩnh vực. Có thể
kể tới SIP-CPL (Call Processing Language) mô tả kịch bản cuộc gọi với các thẻ XML,
SIP-CGI định nghĩa giao diện qua đó các thành phần SIP có thể truyền tham số tới ứng
dụng, hay các chuẩn ứng dụng SIP phía server như SIP Servlet, JAIN SIP và PARLAY.
Mô hình ứng dụng SIP có rất nhiều điểm tương đồng với mô hình ứng dụng NGN, đây
cũng là lý do mà nhiều hãng đã trình làng các giải pháp NGN với hầu hết các thành phần
dựa trên SIP.
Nghiên cứu làm chủ giao thức SIP là cần thiết, khi mà hiện nay xu hướng chuyển
dịch mạng viễn thông sang NGN đã xuất hiện và trở thành vấn đề thiết thực đối với định

hướng phát triển hạ tầng viễn thông Việt Nam. Mặc dù SIP chưa phải là một giao thức
hoàn chỉnh song SIP cũng đã có được những ứng dụng nhất định, ngoài ra các biến thể
của SIP cũng đã góp phần đáng kể trong NGN và việc ứng dụng SIP vào xây dựng hệ
-10-

thống IP Centrex là một định hướng cần được nghiên cứu. Với đề tài này, tôi hy vọng sẽ
đạt được những mục đích sau:
 Nghiên cứu tìm hiểu nội dung và các đặc tính kỹ thuật của giao thức SIP thông qua
các RFC và các chuẩn liên quan.
 Nghiên cứu mô hình và các thành phần của hệ thống IP Centrex.
 Nghiên cứu ứng dụng SIP vào xây dựng hệ thống IP Centrex với một số tính năng cơ
bản.
2. Phƣơng pháp nghiên cứu
Phần lớn nội dung lý thuyết về SIP sẽ được nghiên cứu từ RFC3261 và các chuẩn liên
quan. Ngoài ra tôi sẽ tham khảo các diễn đàn viễn thông quốc tế trên Internet để có các
thông tin về các hoạt động nghiên cứu phát triển SIP trên thế giới, cũng như các khuyến
nghị và kinh nghiệm của các chuyên gia về VoIP/SIP/NGN.
Các nội dung và cấu trúc của hệ thống IP Centrex được tham khảo từ những cấu trúc
hệ thống đang được phát triển tại các hãng danh tiếng. Từ đó tôi sẽ tổng hợp và đưa ra
một mô hình phù hợp ứng dụng các thành quả nghiên cứu về SIP
Về sản phẩm, trước hết tôi sẽ nghiên cứu RFC3261 và các chuẩn liên quan, thử
nghiệm một số SIP softphone và SIP server công cộng trên Internet (hoặc open source),
sau đó sẽ xây dựng thử một SIP server đơn giản với tính năng hạn chế (đủ để hai đầu cuối
gọi được cho nhau). SIP server đơn giản này một mặt sẽ cho phép xác định tính khả thi
của đề tài, mặt khác sẽ giúp tôi có được kinh nghiệm thực tế để có thể thiết kế lại SIP
server hoàn chỉnh và ứng dụng vào trong mô hình tổng thể của hệ thống IP Centrex
3. Nội dung báo cáo
Dựa theo tên đề tài và đề cương đăng ký, tôi xin được chia báo cáo đề tài ra làm hai
phần chính. Phần đầu của báo cáo tôi sẽ trình bày những vấn đề cơ bản nhất về giao thức
thiết lập phiên SIP, với mục đích giúp cho những người mới bắt đầu có thể hình dung

được quá trình phát triển, đặc điểm của giao thức, hoạt động của các thành phần trong
giao thức và mối quan hệ giữa chúng (chương 1). Bên cạnh đó, trong phần này tôi cũng
xin nêu các vấn đề thực tế nảy sinh trong việc ứng dụng SIP, và các giải pháp do cộng
đồng nghiên cứu phát triển SIP đề xuất cùng với kết quả khảo sát một số phần mềm SIP
(open-source và free-ware) đã và đang được sử dụng trong thực tế (chương 2). Ngoài ra,
theo các góp ý từ các thày hướng dẫn, tôi cũng đã bổ sung các ý kiến liên quan đến việc
so sánh SIP với H.323 của một số chuyên gia nổi tiếng trong lĩnh vực VoIP cũng như
những nhận xét chủ quan về vấn đề này.
-11-

Phần tiếp theo của báo cáo tôi sẽ trình bày một số vấn đề cơ bản về hệ thống IP
Centrex và việc ứng dụng các nghiên cứu về SIP để xây dựng mô hình hệ thống IP
Centrex sử dụng call server. Trong chương 3, tôi xin nêu các khái niệm tổng quan về hệ
thống IP Centrex và một số nghiên cứu về các cấu trúc và giải pháp IP Centrex trên thế
giới. Từ các nghiên cứu đó, tôi sẽ phân tích và lựa chọn một giải pháp để phát triển trong
điều kiện thực tiễn của đơn vị và thực tiễn trong nước. Tiếp theo trong chương 4, tôi xin
trình bày mô hình thiết kế hệ thống IP Centrex theo giải pháp được chọn và thiết kế chi
tiết của một số module chính trong hệ thống. Phần thử nghiệm một số dịch vụ cơ bản của
hệ thống được tiến hành tại đơn vị nghiên cứu và được trình bày tại chương 5.
Ngoài ra, tại phần cuối cùng của báo cáo, tôi xin nêu ra một số kiến nghị và định
hướng phát triển tiếp theo của đề tài nhằm tiếp tục bám sát các nghiên cứu trên thế giới và
đưa nội dung của đề tài vào thực tiễn mạng lưới.
-12-


Chƣơng 1: TỔNG QUAN VỀ GIAO THỨC SIP
1.1. Giới thiệu giao thức
1.1.1. Lịch sử phát triển [4,5,8,9]
Từ đầu năm 1996, IETF bắt đầu có các nghiên cứu về SIP. Ban đầu giao thức này có
tên là SCIP (Simple Conference Invitation Protocol), sau đó đổi tên thành Session

Invitation Protocol. Đến bản draft thứ ba thì giao thức này được đặt tên lại là Session
Initiation Protocol và giữ tên này cho đến nay.
Phiên bản chuẩn đầu tiên về SIP (1.0) được IETF công bố đầu năm 1999 dưới dạng
RFC2543, còn mới nhất là SIP/2.0 RFC3261[8] được công bố giữa năm 2002.
Cha đẻ của SIP là Henning Schulzrinne, thuộc Trường ĐH Columbia
(www.cs.columbia.edu). H. Schulzrinne là một trong những thành viên đầu tiên của nhóm
nghiên cứu IETF MMUSIC, và là tác giả của SCIP. Hiện nay, Schulzrinne vẫn là một
thành viên tích cực của IETF có nhiều đóng góp trong việc nghiên cứu phát triển SIP.
Một thành viên khác của IETF đáng được nhắc đến là Jonathan Rosenberg
(DynamicSoft). Rosenberg bắt đầu tham gia vào nhóm MMUSIC của IETF từ giữa năm
1998, và đã có rất nhiều nghiên cứu giá trị, đặc biệt là đối với sự ra đời của phiên bản
SIP/2.0. Một trong những nguồn tài liệu chính của đề tài này là thư viện của Rosenberg
trên Internet (tại địa chỉ www.jdrosen.net/papers).
Sau khi IETF công bố phiên bản SIP/2.0, các nghiên cứu ứng dụng SIP trở nên sôi
động hơn với sự nhập cuộc của các đại gia như Microsoft, Cisco. Tuy nhiên cho đến nay,
các nỗ lực ứng dụng SIP vẫn còn nhiều vấn đề cần tháo gỡ, đặc biệt là ảnh hưởng của
NAT và Firewall đối với các gói tin RTP. Ngoài ra nội dung trong các chuẩn vẫn còn
chưa chính xác và đang được hoàn thiện, chẳng hạn đã tìm được gần 70 lỗi của RFC3261,
trong đó mới giải quyết được 2 lỗi.
Về các hoạt động nghiên cứu ứng dụng SIP, có thể tham khảo tại các địa chỉ sau:
 SIP Forum (www.sipforum.org): Là một diễn đàn phi lợi nhuận với mục tiêu thúc
đẩy ứng dụng SIP trong lĩnh vực truyền thông multimedia/realtime qua Internet và
các thiết bị không dây NGN. SIP Forum được điều hành bởi DynamicSoft (công ty
của Rosenberg), hiện có 32 thành viên là các hãng lớn như Alcatel, Avaya, AT&T,
Siemens
-13-

 SIP Center (www.sipcenter.com): Website này cung cấp nhiều tài nguyên cho việc
phát triển SIP như các softphone, các kịch bản test Đây cũng là khu trưng bày trực
tuyến các sản phẩm SIP với các tên tuổi hàng đầu trong lĩnh vực truyền thông.

 VoIP Forum (www.voip-forum.com): Đăng các tin tức về VoIP nói chung và SIP nói
riêng.
Một số website khác có thể tìm thấy các tài nguyên hỗ trợ phát triển SIP như
vovida.org (nhiều open source), www.cs.columbia.edu (các SIP server công cộng)
Trong đó đáng chú ý nhất là IETF Mailing-list lưu trữ các thảo luận giữa các thành viên
trong các nhóm nghiên cứu của IETF (www1.ietf.org/mail-archive/working-groups),
ngoài ra trên site này dễ dàng tìm thấy các RFC và các bản draft liên quan đến SIP:
[14,15]
 www1.ietf.org/html.charters/sip-charter.html
 www1.ietf.org/html.charters/sipping-charter.html
1.1.2. SIP và H323 [11,12,14,15]
Trong lĩnh vực VoIP hiện nay phổ biến nhất là hai họ giao thức SIP và H.323. H.323
là chuẩn được ITU-T đề xuất và được đưa vào ứng dụng trước. Trong khi đó SIP là chuẩn
được xây dựng sau (1996) bởi IETF, các ứng dụng của SIP mới bắt đầu xuất hiện gần đây
nhưng đã nhanh chóng thu hút được sự quan tâm của nhiều nhà phát triển. Trên các diễn
đàn VoIP quốc tế cũng đã có nhiều bài viết so sánh hai họ giao thức này, cũng như các
tranh cãi giữa hai phe ủng hộ đối với từng giao thức. Hầu hết các bài so sánh đều cho thấy
ưu điểm của SIP so với H.323.
H.323 là trường hợp điển hình của một giao thức phức tạp, xác định (deterministic)
và đi theo bộ. Mô tả về H.323 phân tán trên sáu tài liệu chính, định nghĩa tất cả các
component của một mạng voice/video/data: đầu cuối, gateway, gatekeeper, MCUs và các
feature server. Ngoài ra còn có một số giao thức liên quan như Q.931 (báo hiệu), RAS
(giao tiếp đầu cuối và gatekeeper) và H.245 (media codec). Để thực hiện một cuộc gọi
thoại đơn giản, tất cả các giao thức này đều phải góp mặt với hàng tá bản tin báo hiệu
được gửi qua lại, trong khi SIP chỉ cần 4 bản tin.
Lợi thế của H.323 so với SIP chính là sự ra đời sớm hơn. Có rất nhiều thư viện cho
H.323 stack đã được kiểm thử, và có thể yên tâm mua lại các thư viện này để phát triển
dịch vụ. Tuy nhiên sự phức tạp của giao thức khiến cho H.323 rất khó khăn trong việc
thích ứng với thực tế hiện nay, khi mà sự phát triển của IP network đã vượt ra khỏi những
tiên liệu ban đầu của những người thiết kế H.323.

-14-

Các thử nghiệm của Creative Labs trên H.323 cho thấy khả năng thiết lập cuộc gọi
thành công trong các tình huống mất/lỗi gói tin là khá tệ, trong khi đó thực nghiệm cho
thấy SIP chỉ gặp vấn đề đối với các tình huống trễ gói tin. Các chuyên gia cho rằng
nguyên nhân chính là thủ tục báo hiệu kiểu ISDN (Q.931) của H.323 không phù hợp với
IP network.
Trong khi đó ý tưởng thiết kế của SIP là rất đơn giản. Ban đầu SIP dự định sẽ được sử
dụng như một cơ chế để kết nối các đầu cuối vào hội đàm multi-point, cho phép mọi
người trong cuộc hội đàm có thể trao đổi ý kiến dưới dạng text đơn thuần. Nhưng tác giả
của SIP, Henning Schulzrinne, nhanh chóng nhận ra rằng SIP rất phù hợp với IP
Telephony. Tuy nhiên tôn chỉ của SIP vẫn là duy trì tối đa tính độc lập của giao thức đối
với phần media, vì thế sử dụng SIP để thiết lập một cuộc thoại hay một trò chơi multi-
player cũng không có gì khác nhau.
Sử dụng định dạng text cho các bản tin SIP cũng là một quyết định tinh tế. H.323 sử
dụng các bản tin đóng gói theo kiểu packet nhị phân có nhiều ưu điểm dễ thấy như chiếm
băng thông ít hơn (tính trên cùng một đơn vị dữ liệu), phân tích bằng chương trình đơn
giản hơn. Tuy nhiên, khi thực hành với H.323 có thể nhận thấy những người thiết kế giao
thức này đã quá lạm dụng khả năng phân cấp của quy tắc đóng gói BER (Basic Encoding
Ruler), khiến cho việc truy xuất vào các trường của bản tin rất phiền phức.
Trong khi đó lợi thế của định dạng text là dễ đọc → dễ debug, ngoài ra tính linh hoạt
và khả năng mở rộng của định dạng text là không hạn chế. Nhược điểm chiếm nhiều băng
thông của định dạng text bị xóa nhòa khi mà trên thực tế các bản tin SIP chỉ có độ dài
khoảng vài trăm byte. Tuy nhiên việc phân tích các thành phần của bản tin SIP đòi hỏi
chương trình cần phải có các thuật toán thông minh hơn so với việc phân tích một cách
máy móc gói tin BER mà H.323 sử dụng.
Henning Schulzrinne đã có ý đồ tận dụng lại các thuật toán text-parsing khi sử dụng
cú pháp của HTTP 1.1 cho các bản tin SIP. Trong một số trường hợp SIP server được
nhúng dưới dạng module vào một web server (chẳng hạn Apache) để thừa kế phần phân
tích bản tin theo cú pháp HTTP 1.1. Các chuyên gia cũng lưu ý khi áp dụng các module

HTTP vào SIP cần đảm bảo có sự hỗ trợ bảng mã UTF-8, và phải tách được lớp vận
chuyển (vì HTTP chỉ sử dụng lớp vận chuyển là TCP).
Các chuyên gia đều nhất trí rằng ưu điểm vượt trội của SIP so với H.323 chính là kiến
trúc tích hợp theo hàng ngang, cho phép các giao thức liên quan trong một ứng dụng có
thể "lắp ghép với nhau như trò chơi Lego" (trích lời Schulzrinne). Trong khi đó H.323 có
rất nhiều ràng buộc cần tuân thủ, nó mô tả mọi thứ từ media codec cho tới lớp vận
chuyển. Còn Rosenberg phát biểu: "Về cơ bản, sự thành công của Internet là tách được
-15-

các phần dọc (vertical) của ứng dụng thành các module ngang (horizontal), chẳng hạn như
tách được lớp vận chuyển ra khỏi dịch vụ".
Tham khảo:




SIP cũng không phải là không có nhược điểm. Lớp vận chuyển của SIP đuợc dùng
chủ yếu là UDP cho phép giảm thiểu tài nguyên và hỗ trợ vượt NAT, song UDP thiếu các
chức năng về tính toàn vẹn của bản tin (như checksum, CRC). Điều này đòi hỏi thuật toán
phân tích bản tin SIP phải được thiết kế cẩn thận, nếu không chỉ cần một hay một vài bit
bị thay đổi ngẫu nhiên trên đường truyền cũng có thể làm sập SIP stack hoặc cập nhật rác
vào CSDL. Đáng tiếc là những người thiết kế giao thức này quá “chung thủy” với định
dạng thuần text của HTTP (trong khi HTTP được thiết kế trên TCP). Nếu như SIP được
thiết kế để bổ sung khả năng kiểm tra tính toàn vẹn của bản tin (điều này không khó), thì
sự kết hợp của SIP trên nền UDP sẽ là trọn vẹn.
1.1.3. Vai trò của SIP trong mạng viễn thông
Có nhiều tiêu chí để đánh giá tầm quan trọng của một giao thức báo hiệu trong viễn
thông. Tuy nhiên một giao thức tốt phải là một giao thức hỗ trợ tốt các chức năng báo
hiệu, có khả năng thích ứng linh hoạt với sự thay đổi của lớp dịch vụ điều khiển cuộc gọi
bên trên và phù hợp với xu hướng phát triển của mạng lưới trong tương lai.

Về khả năng hỗ trợ báo hiệu:
 Như đã phân tích ở trên, SIP là một giao thức được phát triển phục vụ cho thoại trên
IP tương tự như H.323. SIP đáp ứng đầy đủ các chức năng thiết lập phiên của một
giao thức báo hiệu điều khiển cuộc gọi (đã được phân tích rất rõ trong RFC 3261).[8]
 Ngoài khả năng hỗ trợ VoIP, SIP cũng rất phù hợp với các ứng dụng truyền thông đa
phương tiện, đặc biệt là với tin nhắn nhanh vì tính đơn giản của SIP. Hiện tại chương
trình Messenger của Microsoft đã sử dụng giao thức này.
Về khả năng thích ứng:
 SIP có khả năng hỗ trợ các ứng dụng điều khiển cuộc gọi một cách linh hoạt, điều đó
có được là do tính độc lập của nó. Bản thân SIP chỉ định nghĩa các thủ tục để thiết
lập các phiên kết nối giữa các cặp SIP client (end-to-end), trong khi hoạt động của
-16-

dịch vụ cũng như đặc điểm media là tùy thuộc vào client và dựa trên các chuẩn khác
(chẳng hạn RTP/RSVP, SDP, audio codecs).
 Các chuẩn viễn thông truyền thống thường là rất chi tiết và chặt chẽ, đầy đủ tới tận
mức ứng dụng (Mô hình top-down). Điều này hạn chế tính mở, tuy nhiên theo các
chuyên gia thì đây lại là một trong những lý do mà H.323 sớm chiếm được ưu thế
trong thị trường Internet phone. Trong khi đó SIP được thiết kế để có thể tồn tại lâu
dài, dễ dàng thích nghi và tiến hóa (Mô hình bottom-up). Ví dụ đơn giản như chẳng
hạn sau này xuất hiện một giao thức kiểm soát QoS hiệu quả hơn RSVP, việc bổ
sung giao thức mới vào ứng dụng sẽ được thực hiện độc lập với SIP. Quan điểm mở
của SIP khuyến khích nhà phát triển mạnh dạn chuẩn bị trước các nền tảng cho đầu
cuối của họ mà không ngại bị lỗi thời, chẳng hạn như Microsoft đã tích hợp SIP
stack vào trong kiến trúc RTC client của hệ điều hành Windows XP, sẵn sàng cho
việc phát triển các ứng dụng SIP-based phía người dùng cuối.
Về khả năng phát triển trong tương lai: [4,11,12,14,15]
 Như đã phân tích, dù đều là các giao thức được thiết kế ban đầu để phục vụ cho
VoiP, nhưng khác với H.323. Mô hình phát triển ứng dụng trên SIP có rất nhiều
điểm tương đồng với mô hình ứng dụng trong NGN. Trong NGN, các dịch vụ rất đa

dạng và thường hội tụ dưới dạng ứng dụng multimedia nên rất linh hoạt, ví dụ có thể
là ứng dụng thuần thoại như VoiP, hoặc thuần text như SMS hay Instance Message
nhưng cũng có thể lại là ứng dụng đa phương tiện như Video Conference…. Yêu cầu
của NGN chỉ có thể đáp ứng được khi giao thức lớp báo hiệu có đủ độ linh hoạt.
H.323 không thể đáp ứng điều đó, vì nó là một chuẩn đóng. Ngược lại, SIP lại rất dễ
thích nghi, đặc biệt là trong trường hợp phối hợp với các giao thức khác. Ví dụ, bằng
việc bổ sung các bản tin mới (MESSAGE, NOTIFY, INFO) hay sử dụng kết hợp với
một giao thức khác (như giao thức mô tả phiên SDP, RFC 2327), SIP có khả năng hỗ
trợ nhiều loại ứng dụng khác nhau, tuỳ theo nhu cầu phát triển dịch vụ.
Từ những phân tích trên có thể thấy SIP sẽ đóng một vai trò quan trọng đặc biệt khi
mạng lõi NGN chuyển sang hoạt động hoàn toàn trên IP (NGN IMS-Based). Các ứng
dụng của SIP khi đó sẽ rất phong phú.
-17-



Hình 1. Vị trí của SIP trong mô hình NGN
Hình trên có thể thấy trong NGN, SIP chiếm một vai trò rất quan trọng. Thực thể đầu
não trong NGN, Softswitch, hỗ trợ cả SIP và H.323. Tuy nhiên, như đã phân tích ở trên,
H.323 chỉ là giải pháp tạm thời trong giai đoạn đầu. Trong các pha kế tiếp, SIP hầu như
thay thế H.323 trong vai trò giao thức báo hiệu.
Có hai mô hình quan trọng phát triển dịch vụ trên SIP như trên hình vẽ:
 Mô hình Service-node: Với mô hình này, các ứng dụng (application server) sẽ giao
tiếp trực tiếp với các thực thể điều khiển cuộc gọi (call agent) như Softswitch, SIP
Server… bằng giao thức SIP và thực hiện điều khiển các thành phần cung cấp tài
nguyên dịch vụ (Media Server, Resource Server…) bằng việc kết hợp với một số
giao thức khác.
 Mô hình dựa trên OSA: Trong mô hình này, SIP được sử dụng giữa Call Agent và
khối OSA để cung cấp giao diện chuẩn mở (Parlay API, JAIN…). Các ứng dụng sẽ
điều khiển logic cuộc gọi thông qua việc gọi các hàm chuẩn mà OSA cung cấp.

Mỗi mô hình đều có các đặc điểm riêng, tuy nhiên đều cho thấy SIP đóng một vai trò
quan trọng trong kiến trúc phát triển dịch vụ của NGN. Các ứng dụng rất phong phú, có
thể kể đến như Messaging, VoiceMail, Video Conference,… và đặc biệt là IP Centrex.
-18-


1.2. Đặc điểm kỹ thuật của giao thức SIP
1.2.1. Các đặc điểm kỹ thuật chính [8,18,19,20,22]
1.2.1.1. Chức năng và các thành phần
SIP được thiết kế để tạo ra các phiên (session) media giữa các đầu cuối, qua đó các
đầu cuối có thể trao đổi các loại hình thông tin khác nhau như âm thanh, hình ảnh, văn
bản SIP cung cấp các chức năng cho phép các đầu cuối (SIP client) thỏa thuận các đặc
điểm của phiên kết nối đang được thiết lập giữa chúng (như giao thức truyền media, địa
chỉ ), sửa đổi các tham số phiên trong quá trình trao đổi, và kết thúc phiên.
Cũng giống như các giao thức VoIP khác, SIP được thiết kế để địa chỉ hóa chức năng
của báo hiệu và quản lý phiên truyền thông trong một mạng thoại gói. Các báo hiệu cho
phép các thông tin về cuộc gọi có thể được chuyển tới đầu cuối kia. Chức năng quản lý
báo hiệu tạo ra khả năng điều khiển thuộc tính cuộc đầu cuối đến đầu cuối.
SIP cung cấp các khả năng sau:
 Phát hiện vị trí đầu cuối đích – SIP cung cấp địa chỉ phân tích, ánh xạ tên và chuyển
hướng cuộc gọi.
 Phát hiện khả năng truyền thông của đầu cuối đích – Thông qua một giao thức mô tả
(thường là SDP), SIP quyết định mức thấp nhất của dịch vụ chung giữa các đầu cuối.
Phiên truyền thông được thiết lập chỉ dựa trên khả năng truyền thông sẵn có của các
đầu cuối
 Xác định khả năng sẵn sàng của đầu cuối đích – Một cuộc gọi sẽ không hoàn thành,
không thực hiện được vì lý do đầu cuối đích không sẵn sàng cho việc truyền thông.
SIP quyết định xem liệu cuộc gọi được nối đến có thành công hay không hay không
có trả lời sau khi chuyển một loạt các bản tin. Sau đó SIP sẽ gửi bản tin thông báo lý
do của việc đầu cuối đích không sẵn sàng.

 Thiết lập phiên truyền thông giữa đầu cuối bắt đầu và đầu cuối đích – Nếu một cuộc
gọi có thể hoàn thành thì SIP sẽ khởi tạo một phiên truyền thông giữa các đầu cuối.
SIP cũng cung cấp chức năng thay đổi cuộc gọi giữa chừng như thêm một đầu cuối
vào trong một cuộc gọi hội nghị hay thay đổi thuộc tính truyền dẫn hoặc codec.
 Điều khiển việc chuyển tiếp và kết thúc cuộc gọi – SIP cung cấp chức năng chuyển
tiếp cuộc gọi từ đầu cuối này đến đầu cuối khác. Trong quá trình chuyển tiếp SIP
thiết lập một phiên truyền thông đơn giản giữa chuyển tiếp và đầu cuối mới (được
-19-

xác định bởi các bên chuyển tiếp) và kết thúc phiên truyền thông giữa người chuyển
tiếp và cuộc gọi chuyển tiếp.
Để các client có thể tìm được nhau, và hỗ trợ một số chức năng khác, các SIP server
được sử dụng với vị trí tương tự như gatekeeper trong H.323. Các loại SIP server gồm có:
 SIP Proxy server (SPS): Là một chương trình có nhiệm vụ trung chuyển các bản tin
SIP giữa các client. SPS phiên dịch các bản tin SIP nhận được, sửa đổi (nếu cần) và
chuyển tiếp tới địa chỉ phù hợp. Để hỗ trợ SPS trong việc quản lý các client, một
chương trình hỗ trợ gọi là Location service được sử dụng (còn gọi là Location server,
Location database).
 SIP Registrar server: Làm nhiệm vụ xử lý bản tin REGISTER từ các client và cập
nhật vào Location service. Thủ tục đăng ký này (login) cho phép SIP Proxy server có
được thông tin về vị trí và tham số của các client. Thông thường Proxy server tích
hợp chức năng của Registrar.
 SIP Redirect server: Được thiết kế phục vụ cho các đầu cuối di chuyển giữa các SIP
domain. Redirect server phân tích bản tin INVITE và trả về các địa chỉ tương ứng
(không chuyển tiếp bản tin). Một SIP server tích hợp có thể hoạt động ở chế độ
proxy, hoặc redirect, hoặc linh động.
Ghi chú: Để có thể kết nối với các mạng khác (non-SIP), các SIP gateway được sử
dụng. Trong giao thức SIP, các gateway có vị trí tương tự như các SIP client (đều gọi là
SIP end-point), nên khi nói SIP client đã bao hàm cả SIP gateway.
Các đặc điểm của SIP đã được mô tả chi tiết trong RFC3261 và cũng đã có nhiều bài

báo phân tích với các nội dung tổng thể đáng lưu ý như sau:
 Bản thân SIP không định nghĩa toàn bộ các thủ tục cần thiết để xây dựng một hệ
thống tích hợp, mà được thiết kế dưới dạng component cho phép kết hợp với một số
chuẩn khác để tạo thành một kiến trúc hoàn chỉnh. Thông thường SIP được dùng kết
hợp với SDP (RFC2327) để mô tả phiên, sử dụng RTP (RFC1889) để truyền dữ liệu
real-time và điều khiển QoS, và RTSP (RFC2326) để truyền các dữ liệu dạng stream.
Tuy nhiên hoạt động của SIP là độc lập với các giao thức đó.
 SIP không cung cấp một dịch vụ nào cụ thể, mà cung cấp các thủ tục căn bản
(primitive) để xây dựng các dịch vụ khác nhau. Đặc điểm dịch vụ được thỏa thuận
giữa các đầu cuối SIP, thường là dưới dạng SDP. Các dịch vụ đơn giản hay đặc thù
có thể được lập trình tại phía người dùng cuối, trong khi các dịch vụ mang tính cộng
đồng có thể được thực hiện tại SIP Application Server của nhà cung cấp dịch vụ.
 Các đầu cuối SIP được đánh địa chỉ theo kiểu email (username@domain). Sơ đồ địa
chỉ dạng E.164 cũng được hỗ trợ (tùy theo chính sách của location service).
-20-

 SIP cung cấp một tập các chức năng bảo mật, bao gồm các kỹ thuật chống tấn công
dạng DoS, nhận thực client (thừa kế từ HTTP), các kỹ thuật đảm bảo toàn vẹn và an
toàn thông tin.
 SIP có thể hoạt động trên nền IPv4 hoặc IPv6, sử dụng giao thức lớp vận chuyển là
UDP (chủ yếu), TCP hoặc TLS.
1.2.1.2. Các bản tin SIP
Hoạt động của SIP dựa trên việc trao đổi các bản tin SIP giữa các thực thể. Các bản
tin SIP có thể là các request từ phần tử client (UAC - User Agent Client) gửi tới phần tử
server (UAS – User Agent Server), hoặc các đáp ứng trên hướng ngược lại.
Cần lưu ý về khái niệm phần tử client và phần tử server khi nghiên cứu RFC3261,
chúng khác với SIP client và SIP server. SIP client là một chương trình chạy phía người
sử dụng, còn SIP server là một chương trình khác phục vụ cho các SIP client. SIP client
và SIP server đều là những thực thể SIP, trong mỗi thực thể SIP sẽ có phần tử client và
phần tử server. Để tránh hiểu lầm, trong tài liệu này từ đây về sau sẽ quy ước khi khi sử

dụng các thuật ngữ client và server là nói đến các thực thể SIP client và SIP server.
Có hai loại bản tin SIP được định nghĩa: bản tin request và bản tin đáp ứng. Các bản
tin request được phân biệt theo tên (chẳng hạn như INVITE, ACK ), trong khi các bản
tin đáp ứng được đánh số (như 100, 401 ). Trong các trao đổi giữa hai thực thể SIP, phần
tử gửi request và nhận đáp ứng gọi là UAC (User Agent Client), còn phần tử nhận request
và gửi trả đáp ứng gọi là UAS (User Agent Server).
Các bản tin SIP có định dạng text, sử dụng tập ký tự UTF-8. Cấu trúc của các bản tin
SIP tuân theo RFC2822 (Internet Message Format), tương tự như HTTP. Để có cái nhìn
trực quan, hãy xem một ví dụ về bản tin INVITE dưới đây:







-21-




INVITE sip: SIP/2.0

Via: SIP/2.0/UDP 10.206.18.114:5060
From: Dinh KC <sip:>;tag=71789cad
To: sip:
Contact: sip::5060
Call-ID:
CSeq: 10595796 INVITE
Content-Length: 177

Content-Type: application/sdp
User-Agent: eStara SoftPHONE
Supported: com.estara.mux

v=0
o=eStara 10595796 10595796 IN IP4 10.206.18.114
s=eStara
c=IN IP4 10.206.18.114
t=0 0
m=audio 8000 RTP/AVP 0 4 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Đây là một bản tin request, có nội dung gồm các dòng text liên tiếp nhau, các dòng
phân tách bởi ký tự LF ('\n') hoặc cặp ký tự CR-LF ('\r\n').
Dòng đầu tiên (start-line) của một bản tin request gọi là Request-Line, có cấu trúc
gồm 3 phần: Method, Request-URI và SIP-Version. Trong ví dụ trên, Method là
"INVITE", Request-URI là "sip:", còn SIP-Version là "SIP/2.0". Các
phần này phân tách nhau bởi một dấu cách (space).
Các dòng tiếp theo mô tả các trường header của bản tin SIP, mỗi trường gồm hai
phần là tên và giá trị. Các phần này này tách nhau bởi dấu hai chấm (":"), hai bên có thể
có các dấu cách. Bản tin ví dụ trên có 10 trường header, trong đó trường CSeq được dùng
để phát hiện các bản tin được phát lại.
Danh sách các trường header được kết thúc bởi một dòng trống, sau dòng trống này
(phần còn lại của bản tin SIP) gọi là body. Độ dài của phần body được xác định bằng giá
trị trường Content-Length, còn ý nghĩa phần body được xác định theo giá trị trường
Content-Type (với SIP giá trị này thông thường là "application/sdp"). Thông thường chỉ
có bản tin INVITE và đáp ứng 2xx (success) mới có phần body.
1.2.1.2.1. Các bản tin request
RFC3261 định nghĩa 6 loại request ứng với các Method sau:

 REGISTER: Client sử dụng request này để khởi đầu thủ tục đăng ký với Registrar
server. Request-URI trong trường hợp này phải là SIP domain, ví dụ "sip:iptel.org".
Method
Request-URI

Danh
sách
các
trường
header

Body
-22-

 INVITE: Request này được khởi đầu từ một client (chủ gọi), sẽ được chuyển tiếp qua
một hoặc một số proxy server để đến được client bị gọi. Request-URI trong trường
hợp này là địa chỉ SIP của client bị gọi (ví dụ "sip:") hoặc một
contact-name mà bị gọi đã đăng ký.
 CANCEL: Được sử dụng để hủy bỏ một request chưa kết thúc (chưa nhận được đáp
ứng hoàn thành). Ví dụ sau khi gửi bản tin INVITE, trong khi client bị gọi chưa trả
lời thì client chủ gọi có thể gửi CANCEL để hủy cuộc gọi. Bản tin CANCEL còn
được tạo ra bởi proxy server trong trường hợp gọi forking (nhân bản INVITE tới
nhiều client), khi một client trả lời thì gửi CANCEL đến các client còn lại. Một số
chú ý khi dùng bản tin CANCEL:
Chỉ nên dùng CANCEL để hủy bỏ INVITE request. Các request loại khác sẽ
được trả lời ngay lập tức, vì vậy nếu dùng CANCEL dễ gây ra mất đồng bộ
(race condition).
Không gửi CANCEL trước khi nhận được ít nhất một đáp ứng 1xx.
Số thứ tự trong trường CSeq được lấy từ bản tin INVITE.
CANCEL chỉ có ý nghĩa trên từng chặng, không được forward. Request-URI

của bản tin CANCEL phải trùng với bản tin request cần hủy.
Đáp ứng cho CANCEL luôn là 200 (Ok)
 ACK: Bản tin ACK được sử dụng trong những chặng UDP, khi một UAC đã gửi
request và đã nhận được đáp ứng hoàn thành. UAC này gửi ACK để báo nhận cho
đáp ứng đã nhận được, thông báo cho UAS đối tác không gửi lại đáp ứng nữa.
Trường hợp đặc biệt là đối với đáp ứng 200 (Ok) cho bản tin INVITE, thì bản tin
ACK có thể được gửi trực tiếp từ đầu cuối tới đầu cuối (không thông qua proxy).
Một số chú ý:
Không có đáp ứng cho ACK.
Số thứ tự trong trường CSeq được lấy từ bản tin đáp ứng.
 BYE: Request này được sử dụng để kết thúc một phiên media đã được kết nối,
thường là gửi trực tiếp từ đầu cuối tới đầu cuối chứ không thông qua proxy server.
 OPTIONS: Được sử dụng để truy vấn các khả năng của đầu cuối hoặc của proxy
server, các khả năng này gồm có các method được hỗ trợ, các kiểu nội dung (content
types), các mở rộng, các kiểu mã hóa (codecs)
Trong số các method trên, cần lưu ý CANCEL và ACK là hai trường hợp đặc biệt.
Các method khác đều có nhiệm vụ khởi đầu một transaction, trong khi CANCEL và ACK
-23-

được gửi trong ngữ cảnh của một transaction đã tồn tại. Ngoài ra RFC3261 cũng "phân
biệt đối xử" với INVITE. Chi tiết về transaction sẽ được trình bày trong các phần sau.
Các mở rộng của SIP sau này định nghĩa thêm một số method mới: REFER,
UPDATE, INFO, MESSAGE, SUBSCRIBE, NOTIFY.
1.2.1.2.2. Các bản tin đáp ứng
Các bản tin đáp ứng cũng có cấu trúc tương tự như các bản tin request, chỉ khác ở
dòng đầu tiên. Trong các đáp ứng, dòng đầu tiên gọi là Status-Line và có cấu trúc gồm 3
phần tách nhau bởi một dấu cách: SIP-Version, Status-Code và Reason-Phrase. Ví dụ:


SIP/2.0 404 Not Found

Via: SIP/2.0/UDP 192.168.1.114:5060
From: Dinh KC <sip:>;tag=71789cad
To: sip:
Call-ID:
CSeq: 10595796 INVITE
Server: Sip EXpress router (0.8.11pre24 (i386/linux))
Content-Length: 0
Các bản tin đáp ứng được nhận dạng nhờ Status-Code (có dạng 3 chữ số thập phân).
Phần Reason-Phrase đưa vào chỉ để phục vụ hiển thị. RFC3261 định nghĩa khá nhiều bản
tin đáp ứng, và phân thành các loại sau:
 1xx - Thông báo (provisioning): Thông báo đã nhận được request và đang xử lý.
 2xx - Thành công (success): Thông báo request đã được xử lý thành công. RFC3261
chỉ định nghĩa một đáp ứng thuộc nhóm này là 200 (Ok).
 3xx - Chuyển hướng (redirect): Thông báo request cần phải thực hiện lại trên hướng
khác.
 4xx - Lỗi client: Bản tin request tương ứng bị lỗi, hoặc request không được chấp
nhận.
 5xx - Lỗi server: Thông báo request hợp lệ, nhưng không xử lý được do lỗi tại UAS.
 6xx - Lỗi chung
Trong đó các đáp ứng từ 2xx đến 6xx gọi là đáp ứng hoàn thành. Trên các chặng
truyền không tin cậy (UDP), các đáp ứng hoàn thành được điều khiển phát lại và cần có
ACK, trong khi các đáp ứng 1xx thì không.
1.2.1.2.3. Các trƣờng header
Reason-Phrase
Status-Code
-24-

Hầu hết các thông tin điều khiển của SIP được chứa trong các trường header. Thông
thường thì mỗi trường header nằm trên một dòng của các bản tin SIP, tuy nhiên nếu dòng

quá dài thì cũng được phép tách xuống cho dễ nhìn (áp dụng một số quy tắc mở rộng).
Ví trí tương đối của các trường header trong bản tin SIP là không quan trọng, tuy
nhiên một số trường header quan trọng đối với xử lý proxy được khuyến nghị là đưa lên
đầu, chẳng hạn như Via, Route, Proxy-Require, Max-Forwards, Proxy-Authorization.
Giống như trong HTTP, mỗi trường header có cấu trúc gồm phần tên và phần giá trị.
Giữa hai phần này ngăn cách bởi ký tự hai chấm (":"), xung quanh có thể có các dấu cách
hoặc tab. Trong phần giá trị có thể có các tham số mở rộng.
Phần tên của trường header là một chuỗi ký tự không chứa các ký tự đặc biệt (thông
thường chỉ gồm các chữ cái và dấu gạch nối), không phân biệt chữ hoa hay chữ thường.
RFC3261 định nghĩa 46 trường header khác nhau, về sau trong các nghiên cứu mở rộng
SIP xuất hiện thêm một số trường header mới. Các trường header của SIP là độc lập với
HTTP, mặc dù có một số trường trùng tên giữa hai giao thức.
Một trường header có thể kèm theo các tham số bằng cách sử dụng dấu chấm phẩy
(";") và cú pháp "param-name[=param-value]", tên tham số không phân biệt hoa -
thường. Ví dụ:
Via: SIP/2.0/UDP 10.1.1.1:4540
;received
=68.44.20.1
;rport
=9988
Nếu giá trị tham số không bao trong cặp nháy kép, thì khi so sánh cũng không phân
biệt chữ hoa - chữ thường. Ngoài ra cần lưu ý hai bên ";" và "=" cũng có thể có các dấu
cách và/hoặc tab. Ý nghĩa giá trị của một trường header cũng như tên và giá trị các tham
số hoàn toàn do trường header đó quy định.
Một loại trường header có thể xuất hiện nhiều lần trong bản tin SIP, trong trường hợp
này thứ tự của chúng là quan trọng. Các header hay xuất hiện nhiều lần gồm có: Via,
Record-Route, Route. Có thể kết hợp các trường header trùng tên làm một, trong đó các
phần giá trị sẽ được nối với nhau bằng dấu phẩy (comma) theo thứ tự xuất hiện.
Bốn trường điều khiển nhận thực WWW-Authenticate, Authorization, Proxy-
Authenticate và Proxy-Authorization là các trường hợp cần được xử lý đặc biệt vì chúng

có định dạng riêng (sử dụng dấu phẩy để phân tách các tham số).
WWW-Authenticate: Digest realm="iptel.org", nonce="3f3c5db8e0bf5bc34d9cde"
Cuối cùng, tên một số trường header có dạng viết tắt bằng một chữ cái (compact
form), ví dụ như "Call-ID" có tên tắt là "i", "Contact" có tên tắt là "m"