Giao thức khởi tạo phiên SIP.doc

Đồ án tốt nghiệp đại học Chơng III. Giao thức khởi tạo phiên SIP
CHƯƠNG III
GIAO thức khởi tạo phiên sip
3.1 Giới thiệu giao thức SIP
3.1.1 Chức năng của SIP
SIP là một giao thức điều khiển tầng ứng dụng có thể thiết lập, duy trì và giải tỏa
các cuộc gọi hoặc các phiên truyền thông. Các phiên truyền thông có thể là điện thoại
hội nghị, học từ xa, điện thoại Internet và các ứng dụng tơng tự khác. SIP có thể đem
lại cho các thành viên cả các phiên đơn hớng và đa hớng (đơn phát hoặc đa phát). Ngời
bắt đầu không cần thiết phải là một thành viên của phiên truyền thông. Phơng tiện và
các thành viên có thể bổ sung vào phiên hiện tại. SIP cũng có thể đợc dùng để bắt đầu
các phiên cũng nh mời các thành viên tới phiên hội thoại mà đã đợc thông báo và thiết
lập bởi các phơng tiện khác. SIP hỗ trợ các dịch vụ ánh xạ tên và các dịch vụ gián tiếp
một cách trong suốt. Vì thế nó cho phép thi hành một cách đầy đủ các dịch vụ trên
ISDN, mạng thoại thông minh và hỗ trợ các cuộc gọi di động của ngời dùng có địa chỉ
không cố định.
SIP hỗ trợ 5 dịch vụ trong việc thiết lập và kết thúc các phiên truyền thông:
- Định vị ngời dùng: Xác định vị trí của ngời dùng tiến hành hội thoại.
- Năng lực ngời dùng: Xác định các phơng thức (phơng tiện) và các tham số t-
ơng ứng trong hội thoại.
- Xác định những ngời sẵn sàng tham gia hội thoại.
- Thiết lập các tham số cần thiết cho cuộc gọi.
- Điều khiển cuộc gọi: Bao gồm cả quá trình truyền và kết thúc cuộc gọi.
SIP là một phần trong bộ giao thức chuẩn cho truyền dòng tin đa phơng thức do
IETF khuyến nghị nh RSVP ( giao thức giữ trớc tài nguyên ), RTP ( giao thức truyền
tải theo thời gian thực ), RTSP ( giao thức phân phối dòng tin đa phơng thức ), SAP
( giao thức thông báo phiên ), SDF ( giao thức mô tả phiên ). Tuy nhiên SIP hoạt động
độc lập với các giao thức trên.
SIP cũng có thể kết hợp với các giao thức báo hiệu và thiết lập cuộc gọi khác.
Theo cách đó, một hệ thống đầu cuối dùng SIP để xác định địa chỉ hợp lệ của một hệ
thống và giao thức từ một địa chỉ gửi đến là giao thức độc lập. Ví dụ, SIP có thể dùng

Lữ Văn Thắng, D2001VT
56
Đồ án tốt nghiệp đại học Chơng III. Giao thức khởi tạo phiên SIP
để chỉ ra rằng ngời tham gia có thể thông qua H323, cổng H245, địa chỉ ngời dùng rồi
dùng H225 để thiết lập cuộc gọi.
3.1.2 Các thành phần của hệ thống SIP
3.1.2.1 Các định nghĩa
Call: Một cuộc gọi gồm tất cả các thành viên trong phiên đợc mời bởi một tài
nguyên chung. Một cuộc gọi SIP đợc nhận biết bởi Call - ID.
Call leg: Call leg đợc nhận biết bởi sự kết hợp của Call - ID, To and from.
Client: Là một chơng trình ứng dụng gửi đi những yêu cầu SIP. Client có thể
ảnh hởng trực tiếp hoặc không đến ngời sử dụng. Client đợc chứa trong các
Proxy và Uers Agent.
Conference: Hội nghị là một phiên hội thoại đa phơng. Một hội nghịh có thể
không có hoặc có nhiều thành viên và bao gồm các trờng hợp nh hội nghị đa
phơng, hội nghị nhiều mắt lới ( full mesh ), cuộc gọi hai thành viên, ... Một
vài cuộc gọi có thể tạo ra một hội nghị.
Downstream: là yêu cầu gửi trực tiếp từ phía gọi đến ngời nghe ( từ UAC đến
UAS ).
Final Respone: là đáp ứng kết thúc một phiên giao dịch SIP, bao gồm các đáp
ứng sau: 2xx, 3xx, 4xx, 5xx, 6xx.
Invitation: Là yêu cầu gửi từ User hoặc Service đề nghị tham gia vào một phiên
hội thoại. Một lời mời đầy đủ gồm một yêu cầu INVITE ngay sau một yêu cầu
ACK.
Parallel search: Trong một quá trình tìm kiếm song song một Proxy đa ra một
vài yêu cầu tới ngời dùng hiện tại trong khi nhận một yêu cầu đến.
Provisional Respone: Đáp ứng tạm thời là đáp ứng đợc Server dùng để thông
báo tiến trình gọi nhng cha kết thúc một phiên giao dịch SIP, đáp ứng 1xx là
một Provisional Respone.
Server: Là một chơng trình ứng dụng có nhiệm vụ nhận các yêu cầu hợp lệ từ

các dịch vụ và gửi trả lại các đáp ứng. Server có thể là Proxy, Redirect, UAS,
Registrars.
Session: Theo đặc tả của SDP thì một phiên đa truyền thông là tập hợp những
ngời gửi và nhận cùng với dòng dữ liệu từ nơi gửi đến nơi nhận. Nó đợc xác
Lữ Văn Thắng, D2001VT
57
Đồ án tốt nghiệp đại học Chơng III. Giao thức khởi tạo phiên SIP
định bởi chuỗi các tên User, Session ID, kiểu mạng, kiểu địa chỉ và địa chỉ các
phần tử trong trờng nguồn.
SIP transaction: là quá trình xảy ra giữa một Client và một Server gồm tất cả
các bản tin từ yêu cầu đầu tiên gửi đi từ client đến server cho đến đáp ứng cuối
cùng từ Server gửi trả lại Client. Nó đợc nhận biết bởi số thứ tự CSeq. Yêu cầu
ACK có cùng số CSeq với yêu cầu INVITE tơng ứng nhng chứa một giao dịch
của riêng nó.
Upstream: Đáp ứng gửi trực tiếp từ UAS đến UAC.
URL - encoded: Là chuỗi ký tự mã hoá theo chuẩn RFC 1738.
3.1.2.2 Các thành phần của kiến trúc SIP
Xét trên quan điểm khách hàng / phục vụ ( Client /Server ), các thành phần chính
của một hệ thống SIP đợc mô tả bởi hình vẽ sau:

Trong hình trên User Agent là thiết bị đầu cuối trong mạng SIP, có thể là một máy
điện thoại SIP, có thể là máy tính chạy phần mềm đầu cuối SIP.
Proxy Server là phần mềm trung gian hoạt động cả nh server và client để thực hiện
các yêu cầu thay mặt các đầu cuối khác. Tất cả các yêu cầu đợc xử lý tại chỗ bởi Proxy
Server nếu có thể, hoặc đợc chuyển cho các máy chủ khác. Trong trờng hợp Proxy
Server không trực tiếp đáp ứng các yêu cầu này thì Proxy Server sẽ thực hiện khâu
chuyển đổi hoặc dịch sang khuôn dạng thích hợp trớc khi chuyển đi.
Lữ Văn Thắng, D2001VT
58
Hình 3.1 Cấu trúc của một hệ thống SIP

Đồ án tốt nghiệp đại học Chơng III. Giao thức khởi tạo phiên SIP
Location Server là phần mềm định vị thuê bao, cung cấp thông tin về những vị trí
có thể của phía bị gọi cho các phần mềm Proxy Server và Redirect Server.
Redirect Server là phần mềm nhận yêu cầu SIP và chuyển đổi địa chỉ SIP sang
một số địa chỉ khác và gửi lại cho đầu cuối. Không giống nh Proxy Server, Redirect
Server không bao giờ hoạt động nh một đầu cuối, tức là không gửi đi bất cứ yêu cầu
nào. Redirect Server cũng không nhận hoặc huỷ cuộc gọi.
Registrar Server là phần mềm nhận các yêu cầu đăng ký REGISTER. Trong nhiều
trờng hợp Registrar Server đảm nhiệm luôn một số chức năng an ninh nh xác nhận ng-
ời sử dụng. Thông thờng Registrar Server đợc cài đặt cùng với Proxy hoặc Rredirect
Server hoặc cung cấp dịch vụ định vị thuê bao. Mỗi lần đầu cuối đợc bật lên ( thí dụ
máy điện thoại hoặc phần mềm SIP ) thì đầu cuối lại đăng ký với Server. Nếu đầu cuối
cần thông báo cho Server về địa điểm của mình thì bản tin REGISTER cũng đợc gửi đi.
Nói chung, các đầu cuối đều thực hiện việc đăng ký lại một cách định kỳ.
3.1.3 Khái quát về hoạt động của SIP
Trong hội thoại SIP, mỗi bên tham gia ( bên gọi và bị gọi ) đợc gắn một địa chỉ
SIP hay còn gọi là SIP URL. Ngời sử dụng phải đăng ký vị trí của họ với SIP server. Để
tạo một cuộc gọi SIP, phía gọi định vị tới máy phục vụ thích ứng và sau đó gửi đi một
yêu cầu SIP. Hoạt động SIP thờng xuyên nhất là mời các thành viên tham gia hội thoại.
Thành phần Registrar đóng vai trò tiếp nhận các yêu cầu đăng ký từ UA ( User Agent )
và lu trữ các thông tin này tại một dịch vụ bên ngoài SIP ( Non SIP ).
3.1.3.1 Địa chỉ SIP
Các thành viên tham gia hội thoại đợc định danh bởi một địa chỉ SIP gọi là SIP
URL. SIP URL đợc dùng trong các bản tin SIP để thông báo về nơi gửi ( from ), đích
hiện thời ( Request URI ) và nơi nhận cuối cùng ( to ) của một yêu cầu SIP và chỉ rõ
địa chỉ gián tiếp. Một SIP URL có thể gắn vào một trang Web hoặc những hyperlink
khác để thông báo rằng ngời dùng hoặc dịch vụ có thể gọi thông qua SIP.
3.1.3.2 Giao dịch SIP
Khi có địa chỉ IP của SIP server yêu cầu đợc gửi đi theo tầng vận chuyển ( giao
thức ) TCP hay UDP. Khách hàng gửi một hàng nhiều yêu cầu SIP tới SIP server và

nhận các phúc đáp từ Server. Một yêu cầu cùng với những phúc đáp ứng cho những
Lữ Văn Thắng, D2001VT
59
Đồ án tốt nghiệp đại học Chơng III. Giao thức khởi tạo phiên SIP
nhu cầu đó tạo nên một giao dịch SIP. Tất cả các đáp ứng cho một yêu cầu phải chứa
cùng các giá trị trong trờng Call - ID Cseq, To và From. Điều đó làm cho các đáp ứng
phù hợp với các yêu cầu. Mỗi cuộc gọi trong SIP đợc định danh bởi một bộ định danh
cuộc gọi ( Call - ID ).
Yêu cầu đợc gửi đi từ đâu ( From ) tới đâu ( To ). Trờng From và To đều theo
khuôn dạng SIP - URL. Trờng CSeq lu trữ thông tin về phơng thức sử dụng trong
phiên, có dạng:
CSeq="CSeq": "DIGIT Method"
DIGIT là số nguyên không dấu 32 bit.
Nếu giao thức TCP đợc sử dụng, các yêu cầu và đáp ứng trong một giao dịch
SIP đơn giản đều đợc truyền qua cùng một kết nối TCP. Một số yêu cầu SIP từ
cùng một khách hàng đến cùng một Server có thể dùng một kiểu nối TCP hoặc
có thể dùng một kiểu kết nối mới cho mỗi yêu cầu.
Nếu khách hàng gửi yêu cầu thông qua giao thức UDP đơn hớng, các đáp ứng
sẽ đợc gửi đến các địa chỉ nằm trong trờng mào đầu "Via" của đáp ứng nếu yêu
cầu đợc gửi qua giao thức UDP đa hớng thì các đáp ứng sẽ đợc đa tới cùng một
điạ chỉ quảng bá và cổng đích. Khuôn dạng bản tin SIP không phụ thuộc vào
giao thức truyền.
3.1.3.3 Lời mời SIP
Một lời mời SIP gồm hai yêu cầu INTIVE và ACK. Yêu cầu INTIVE mời thành
viên tham gia hội thoại khi phía bị gọi đồng ý tham gia, bên gọi xác nhận đã nhận đợc
đáp ứng đó bằng cách gửi một yêu cầu ACK. Nếu phía gọi không muốn mời thành viên
tham gia cuộc gọi nữa nó sẽ gửi yêu cầu BYE thay cho ACK.
Thông điệp INTIVE chứa thành phần mô tả phiên ( SDP ) và phơng thức tiến hành
trao đổi ứng với phiên đó. Với các phiên đa hớng, "mô tả phiên" liệt kê kiểu và khuôn
dạng của các phơng tiện để phân phối cho phiên hội thoại. Với một phiên đơn hớng,

"mô tả phiên" liệt kê kiểu và khuôn dạng của các phơng tiện mà phía gọi muốn sử
dụng và nơi những dữ liệu muốn gửi đi.
Trờng hợp máy phục vụ muốn uỷ quyền ( PS: Proxy Server ). Tiến trình xảy ra nh
sau:
Proxy Server tiếp nhận lời mời INTIVE
PS tra cứu thông tin ở dịch vụ định vị ngoài SIP
Lữ Văn Thắng, D2001VT
60
Đồ án tốt nghiệp đại học Chơng III. Giao thức khởi tạo phiên SIP
PS nhận về thông tin để tạo ra địa chỉ chính xác
PS tạo lại INTIVE trong trờng Request - URI và chuyển tiếp
UAS ( User Agent Server ) cảnh báo phía bị gọi
PS nhận đáp ứng chấp nhận 200 OK từ UAS
PS trả về kết quả thành công cho phía gọi
Phía gọi gửi thông báo xác nhận ACK
Yêu cầu xác nhận đợc chuyển tiếp qua PS.
Chú ý: Một ACK có thể đợc gửi trực tiếp đến ngời đợc gọi qua Proxy. Tất cả các
yêu cầu và đáp ứng phải có cùng Call - ID.
Trờng hợp máy phục vụ gián tiếp. Tiến trình xảy ra nh sau:
PS tiếp nhận lời mời INTIVE
Liên lạc với dịch vụ định vị
Trả lời địa chỉ phía gọi
Phía gọi gửi thông báo xác nhận ACK đến PS
Phía gọi tạo một yêu cầu mới với cùng một Call - ID nhng có CSeq cao hơn tới
địa chỉ trả lời bởi Server đầu tiên
Phía bị gọi gửi đáp ứng chấp nhận 200 OK
Phía gọi gửi thông báo xác nhận ACK.
3.1.3.4 Định vị ngời dùng
Ngời đợc gọi có thể di chuyển giữa các hệ thống đầu cuối khác nhau tại các thời
điểm khác nhau. Những vị trí đó đợc đăng kí với SIP server. Một máy định vị

( Location Server ) có thể sử dụng một hay nhiều giao thức nh finger ( RFC1288[17] ),
rwhois (RFC2167[18]), LDAP(RFC1777[19], multicast - based[[20], ... để xác định hệ
thống đầu cuối mà User có thể tới. Một Location Server có thể trả lại vài vị trí mà User
đã đăng kí đồng thời tại nhiều Host hoặc bởi Location Server có lỗi. SIP server sẽ tổng
kết các kết quả để đa ra danh sách các vị trí.
Đối với các loại SIP server thì hoạt động sau khi nhận đợc các vị trí là khác nhau.
Một SIP Redirect Server sẽ trả lại danh sách cho khách hàng với tiêu đề Contact. Một
SIP Proxy Server có thể liên tục thử các địa chỉ cho đến khi cuộc gọi thành công hay
ngời đợc gọi từ chối cuộc gọi với cách thử tuần tự các địa chỉ. Một Proxy Server có thể
thực hiện một dịch vụ "anycast". Nếu Proxy Server gửi một yêu cầu SIP, nó phải bổ
sung thêm địa chỉ của chính nó vào phần đầu danh sách của "forwardes noted" trong
Lữ Văn Thắng, D2001VT
61
Đồ án tốt nghiệp đại học Chơng III. Giao thức khởi tạo phiên SIP
tiêu đề Via. Dấu hiệu Via đảm bảo rằng bản tin trả lời có thể lấy ra từ cùng một đờng
( hớng ). ở hớng đáp ứng, mỗi Host phải gỡ bỏ tiêu đề Via của chính nó, vì thế thông
tin đợc truyền nội bộ sẽ "ẩn " đối với phía bị gọi và mạng bên ngoài. Proxy Server phải
kiểm tra xem nó có phát yêu cầu tới danh sách Host (host listed) chứa trong các tham
số Via rent - by, Via received hay Via - maddr.
3.1.3.5 Thay đổi một phiên hiện tại
Trong một vài trờng hợp cần phải thay đổi các thông số của một phiên hội thoại
hiện tại. Việc đó đợc thực hiện bởi việc phát lại các INTIVE. Các INTIVE đó có cùng
trờng Call - ID nhng có trờng tiêu đề và thân bản tin khác để mang những thông tin
mới. Các bản tin INVITE đó phải có CSeq cao hơn các yêu cầu trớc.
Ví dụ: Có hai thành viên đang hội thoại và muốn có thêm một ngời thứ ba. Một
trong các thành viên sẽ mời thành viên thứ ba tham gia với một địa chỉ "multicast" mới
và đồng thời gửi một bản tin INTIVE đến thành viên thứ hai với trờng miêu tả phiên
multicast nhng có Call - ID cũ.
3.1.4 Các loại bản tin SIP
SIP là giao thức dạng TEXT sử dụng bộ kí tự ISO 10646 trong mã hoá. Điều này

tạo cho SIP tính linh hoạt và mở rộng dễ thi hành các ngôn ngữ lập trình cấp cao nh
Java, Tol, Perl. Cú pháp của SIP gần giống với giao thức HTTP, cho phép dùng lại mã
và đơn giản hoá sự liên kết của các máy phục vụ SIP với các máy phục vụ Web.
Một bản tin SIP có thể là một yêu cầu từ khách hàng tới một Server hay một đáp
ứng từ Server gửi lại khách hàng. Cả hai loại bản tin này đều sử dụng chung một định
dạng cơ bản đợc quy định trong RFC 2822 với cấu trúc gồm một dòng khởi đầu
( start - line ), một số trờng tiêu đề và và một phần thân bản tin tùy chọn. Cấu trúc này
đợc tóm tắt nh sau:
generic - message = start - line
*message - header
CRLF
[message - body]
Trong đó:
Start - line = Request - line/Status - line
(general - header)
Lữ Văn Thắng, D2001VT
62
Đồ án tốt nghiệp đại học Chơng III. Giao thức khởi tạo phiên SIP
Message - header = /Request - header
/Respone - header
/(entity - header)
Dòng khởi đầu, các dòng tiêu đề hay dòng trống phải đợc kết thúc bằng một kí tự
xuống dòng ( CRLF ) và phải lu ý rằng dòng trống vẫn phải có để ngăn cách phần tiêu
đề và thân của bản tin ngay cả khi phần thân bản tin là rỗng.
3.1.4.1 Bản tin Request
Các bản tin SIP đợc phân biệt với nhau dựa vào dòng đầu tiên ( Start - line ).
Trong đó, các bản tin yêu cầu có dòng khởi đầu là một dòng yêu cầu ( Request - line ).
Dòng này chứa tên phơng thức, một Request - URI, và một số phiên bản giao thức. Các
thành phần đợc ngăn cách với nhau bằng một kí tự trắng ( SP ). Cũng nh các dòng
khác, dòng khởi đầu đợc kết thúc bằng một kí tự xuống dòng CRLF.

Khuôn dạng bản tin Request:
Request = Request - line ( general - header/Request - header/entity - header )
CLRF
[ message - body ]
Request - line = Method SP Request - URIP SIP - Version CRF
a) Methods (Các chỉ thị)
SIP định nghĩa 6 chỉ thị sau:
Methods = INTIVE/ACK/OPTION/BYE/CANCEL/REGISTER
INTIVE
Chỉ thị INTIVE thông báo rằng User hoặc dịch vụ đợc mời tham gia vào một
phiên hội thoại. Một Server sẽ tự động trả lời một lời mời tham gia hội thoại nếu User
đã sẵn sàng tham gia bằng đáp ứng 200 OK - Respone.
Nếu nh một UA ( User Agent ) nhận đợc một yêu cầu INVITE cho Call leg với số
CSeq cao hơn các INVITE trớc có cùng Call - ID, nó sẽ kiểm tra các từ định danh
Version thì nội dung của phần miêu tả phiên sẽ đợc xem xét nếu nó muốn thay đổi và
UA phải xem xét các trờng tiêu đề cho việc thay đổi. Nếu nh có một sự thay đổi, UA
phải cập nhật những trạng thái nội bộ hoặc những thông tin phát ra nh kết quả của tiêu
đề đó. Nếu miêu tả phiên thay đổi, UAS phải điều chỉnh lại các thông số phiên hội
thoại cho phù hợp sau khi yêu cầu User xác nhận. Chỉ thị này đợc đa ra bởi SIP Proxy,
Redirect Server và UAS cũng nh khách hàng.
Lữ Văn Thắng, D2001VT
63
Đồ án tốt nghiệp đại học Chơng III. Giao thức khởi tạo phiên SIP
ACK
Yêu cầu ACK xác nhận rằng khách hàng đã nhận đợc đáp ứng cuối cùng cho yêu
cầu INVITE ( ACK chỉ sử dụng cho yêu cầu INVITE ). Khi UAC chấp nhận đáp ứng
2xx, tất cả các đáp ứng cuối cùng khác của Proxy đầu tiên hay của UAC đều nhận đợc
trả lời. Trờng Via đợc đa vào Host để phát ra yêu cầu ACK sau khi UAC nhận đợc một
đáp ứng 2xx hoặc Proxy đầu tiên nhận đợc một đáp ứng non - 2xx.
Yêu cầu ACK có thể chứa một thân bản tin ( message body ) với phần miêu tả

phiên cuối cùng dùng cho ngời đợc gọi. Nếu nh thân bản tin ACK rỗng, ngời đợc gọi
sẽ sử dụng phần miêu tả phiên trong yêu cầu INVITE.
Một Proxy Server nhận một yêu cầu ACK sau khi gửi đi các đáp ứng 3xx,4xx,5xx
hay 6xx phải quyết định ACK là của nó hay là cho các UA hoặc Proxy Server phía bên
kia. Quyết định đó dựa vào việc xem xét thẻ địa chỉ trong trờng To. Nếu thẻ địa chỉ
trong trờng tiêu đề To của ACK phù hợp với thẻ địa chỉ trong trờng tiêu đề To của đáp
ứng và các trờng tiêu đề From, Call - ID, CSeq của đáp ứng phù hợp với các trờng của
ACK thì chứng tỏ rằng ACK là dành cho Proxy Server. Chỉ thị này phải đợc đa ra bởi
SIP Proxy, Redirect Server, UA cũng nh khách hàng.
OPTION
Chỉ thị OPTION dùng để hỏi về khả năng của SIP Server. Nếu một Server có khả
năng liên lạc với User có thể đáp ứng lại yêu cầu OPTION bằng một tập hợp các khả
năng của nó. Chỉ thị này đợc đa ra bởi SIP Proxy, Redirect Server, UA, Register,
Client.
BYE
UAC sử dụng chỉ thị BYE để thông báo cho Server rằng nó muốn giải phóng cuộc
gọi. Yêu cầu BYE cũng giống nh một yêu cầu INTIVE chứa một tiêu đề Contact, ngời
đợc gọi phải gửi yêu cầu BYE tới địa chỉ. Chỉ thị này phải đợc đa ra bởi một Proxy
Server và không hỗ trợ bởi Redirect Server và UAS.
CANCEL
Yêu cầu CANCEL đợc dùng để huỷ bỏ một yêu cầu sắp đợc thực hiện với cùng
giá trị trong các trờng Call - ID, From, To và CSeq của yêu cầu đó.
UAC hay Proxy khách hàng có thể phát ra một yêu cầu CANCEL tại mọi lúc.
Proxy trong trờng hợp đặc biệt có thể gửi một yêu cầu CANCEL tới đích mà không trả
Lữ Văn Thắng, D2001VT
64
Đồ án tốt nghiệp đại học Chơng III. Giao thức khởi tạo phiên SIP
lại một đáp ứng cuối cùng sau khi nó đã nhận đợc các đáp ứng 2xx hay 6xx cho một
hay nhiều yêu cầu tìm kiếm song song ( paralled seach ).
Các trờng Call - ID, CSeq, To, From trong CANCEL đều giống nh trong yêu cầu

gốc ( yêu cầu mà nó muốn huỷ bỏ ). Tuy nhiên để khách hàng phân biệt đợc các đáp
ứng cho CANCEL với các đáp ứng cho yêu cầu gốc thì thành phần CSeq Method sẽ đ-
ợc thiết lập trong CANCEL.
Khi một UAS nhận đợc yêu cầu CANCEL, nó không phải phát ra một đáp ứng
2xx cho yêu cầu huỷ bỏ.
Redirect Server và UAS khi nhận đợc một yêu cầu CANCEL sẽ đáp ứng bằng một
trạng thái là 200 nếu nh tồn tại giao dịch SIP và trạng thái là 481 nếu không tồn tại
giao dịch .
REGISTER
Chỉ thị REGISTER đợc dùng để đăng kí danh sách địa chỉ của ngời dùng trong tr-
ờng tiêu đề To với SIP server. Nh vậy chỉ thị này dùng để đăng kí thông tin ngời dùng.
b) Request - URI
Trờng Request - URI có khuôn dạng theo SIP URL. Nó thông báo cho ngời dùng
hoặc dịch vụ về địa chỉ hiện tại. Khác với trờng To, Request - URI có thể đợc ghi lại
bởi Proxy (máy phục vụ uỷ quyền). Khi sử dụng nh một Request - URI, SIP URL
phải chứa các tham số transport - param, maddr - param, ttl - param và các thành phần
tiêu đề. Một Server khi nhận đợc một SIP URL, địa chỉ SIP với những thành phần đó
sẽ huỷ bỏ chúng trớc khi tiến hành xử lí.
Điển hình là, UAS thiết lập trờng Request - URI và trờng To trong cùng một SIP
URL coi nh không thay đổi trong một khoảng thời gian dài. Tuy nhiên, nếu nh UAC
dành cho phía bị gọi nhiều hớng trực tiếp, từ trờng tiêu đề Contact của một đáp ứng cho
yêu cầu trớc đó, trờng To sẽ vẫn chứa các thông số long - term, địa chỉ "public" trong
khi Request - URI có thể thiết lập các địa chỉ dự phòng. Proxy Server và Redirect
Server dùng những thông tin chứa trong trờng Request - URI và trờng tiêu đề của yêu
cầu để quản lí các yêu cầu và ghi lại trờng Request - URI.
Host - port của Request - URI điển hình phù hợp với một trong các "host name"
của Server nhận. Nếu không, Server phải uỷ quyền cho yêu cầu tới địa chỉ "Indicate"
hoặc trả lại đáp ứng 404 ( not found: không tìm thấy ) nếu nó không muốn hay không
thể thực hiện đợc.
Lữ Văn Thắng, D2001VT

65
Đồ án tốt nghiệp đại học Chơng III. Giao thức khởi tạo phiên SIP
Nếu SIP Server nhận đợc một yêu cầu với một URI "indicating" với một cấu trúc
khác hơn SIP mà Server đó không hiểu đợc, Server phải gửi lại một đáp ứng 400 ( Bad
Request ). Nó phải thực hiện việc đó ngay cả khi trờng tiêu đề To chứa một cấu trúc
mà nó không hiểu.
SIP Version
Cả bản tin Request và Repone đều chứa phiên bản của SIP đợc sử dụng tơng tự
nh trong bản tin HTTP. Hiện nay, có hai phiên bản SIP đợc kí hiệu là SIP và SIP/2.0.
Option Tag
Option tag đợc dùng để chỉ định định rõ các lựa chọn mới trong SIP. Các thể lựa
chọn đợc sử dụng trong trờng Supported, Unsupported và Require.
Cú pháp: Option - tag = token
New Option đợc đăng kí bởi tổ chức IANA ( Internet Assigned Number Authority ).
Khi đăng kí thì cần phải có các thông tin sau:
Tên và mô tả của "Option". Tên có độ dài không quá 20 ký tự .
Thông báo về tổ chức có quyền thay đổi "Option".
Thông tin liên lạc ( hòm th hay địa chỉ email )
Đăng ký phải đợc gửi tới
3.1.4.2 Bản tin Respones
Các bản tin đáp ứng đợc phân biệt với các bản tin yêu cầu bằng một dòng trạng
thái ( Status -line ) đợc đặt ở dòng khởi đầu của bản tin. Dòng trạng thái của bản tin
đáp ứng bao gồm tên phiên bản giao thức SIP, một mã trạng thái và một cụm văn bản
giải thích ý nghĩa của bản tin trả lời. Mỗi thành phần cũng đợc phân biệt với nhau bằng
một kí tự trắng SP. ở cuối dòng, kí tự xuống dòng CRLF đợc sử dụng để tách biệt nó
với dòng tiếp theo trong bản tin.
Khuôn dạng bản tin nh sau:
Respone = Status - line
( General - header/ Respone - header/ entity - header )
CRLF

[ message - body ]
Trong đó:
Status - Line = SIP - Version SP status - Code SP Reason - Phrase CRLF
Lữ Văn Thắng, D2001VT
66
Đồ án tốt nghiệp đại học Chơng III. Giao thức khởi tạo phiên SIP
Status - Code là một mã kết quả nguyên gồm 3 digit chỉ ra kết quả của việc cố
gắng hiểu và đáp ứng yêu cầu.
Status - Phrase thì đa ra một bản yêu cầu ngắn theo đúng nguyên văn của Status -
Code. Status - Code dùng cho máy còn Reason - Phrase là dùng cho ngời sử dụng.
Khách hàng không thể yêu cầu hiển thị hay kiểm tra Status - Phrase.
Status - code gồm 3 digit. Digit đầu tiên định nghĩa loại đáp ứng. Hai digit sau
không có vai trò phân loại. Bản SIP /2.0 cho phép 6 giá trị của digit đầu tiên nh sau:
1xx: Informational : Nhận và xử lý yêu cầu
2xx: Success : Thành công
3xx: Redirect : Chuyển tiếp yêu cầu
4xx: Client - Error : Lỗi ngời dùng, cú pháp của yêu cầu lỗi
không thoả mãn Server
5xx: Server - Error : Lỗi máy phục vụ
6xx: Global - Farlure : Yêu cầu không đợc đáp ứng tại mọi Server
Dới đây là ví dụ một số giá trị riêng của 6 digit đầu tiên của Response Code và
Reason Phrase chú thích mã tơng ứng là đáp ứng gì:
Informational = "100" ; Trying
Success = "200" ; OK
Redirection = "300" ; Multiple Choices
Client - Error = "400" ; Bad Request
Server - Error = "500" ; Internal Server Error
Global - Failure = 600 ; Busy Everywhere
Mã đáp ứng SIP có thể mở rộng đợc. Các ứng dụng SIP không yêu cầu phải hiểu
rõ về ý nghĩa của tất cả mã đáp ứng đợc đăng ký mà chỉ cần hiểu các loại mã đáp ứng,

ý nghĩa của digit đầu tiên.
3.1.5 Thân bản tin SIP ( SIP Message Body )
3.1.5.1 Body Inclusion
Yêu cầu chứa các thân bản tin trừ khi có lu ý khác. Trong đặc tả này, yêu cầu
CANCEL không chứa một thân bản tin. Còn đối với các chỉ thị ACK, INTIVE,
OPTIONS, thân bản tin bao giờ cũng là một miêu tả phiên. Việc sử dụng thân bản tin
cho yêu cầu REGISTER đang đợc nghiên cứu thêm.
Lữ Văn Thắng, D2001VT
67
Đồ án tốt nghiệp đại học Chơng III. Giao thức khởi tạo phiên SIP
Với bản tin đáp ứng, chỉ thị yêu cầu và mã trạng thái đáp ứng xác định kiểu và sự
thể hiện của các thân bản tin. Tất cả các đáp ứng đều gồm một thân bản tin. Thân bản
tin cho đáp ứng 1xx chứa thông tin t vấn về tiến trình của yêu cầu. Trong đáp ứng 2xx
cho yêu cầu INTIVE thân bản tin chứa miêu tả phiên. Trong đáp ứng 3xx thân bản tin
chứa miêu tả về các đích chọn lựa hay dịch vụ. Với các đáp ứng 4xx và lớn hơn, thân
bản tin gồm các thông tin bổ sung, các thông tin con ngời có thể đọc đợc về các
nguyên nhân gây lỗi.
3.1.5.2 Kiểu thân bản tin ( Message Body Type )
Kiểu truyền thông của thân bản tin đợc chỉ ra bởi trờng tiêu đề Content - Type. Nếu
thân bản tin đã qua mã hoá thì nó đợc chỉ ra bởi trờng tiêu đề Content - Encoding. Tập
hợp các kí tự của thân bản tin đợc chỉ ra bởi trờng tiêu đề Content - Type
3.1.5.3 Độ dài thân bản tin ( Message Body Length )
Độ dài thân bản tin tính theo Byte đợc đa ra bởi trờng tiêu đề Content - Length.
3.1.6 Khuôn dạng thoả thuận ( Comfact From )
Khi SIP đợc truyền thông qua giao thức UDP với sự xác thực và một miêu tả phiên
phức tạp thì độ dài của một yêu cầu hay đáp ứng SIP sẽ lớn hơn MTU. Để giải quyết
vấn đề này, khuôn dạng thoả thuận của SIP đợc định nghĩa bằng cách sử dụng các từ
viết tắt cho các trờng tiêu đề chung, đợc miêu tả dới đây:
Tên trờng ngắn Tên trờng dài
c Content - Type

e Content - Encoding
f From
i Call - ID
m Contract
l Content - Length
s Subject
t To
v Via
Client có thể dùng cả tên trờng ngắn và tên trờng dài trong cùng một yêu cầu và
Server cũng chấp nhận điều đó.
Lữ Văn Thắng, D2001VT
68
Đồ án tốt nghiệp đại học Chơng III. Giao thức khởi tạo phiên SIP
3.2 Định nghĩa các trờng tiêu đề và mã trạng thái trong bản tin SIP
3.2.1 Định nghĩa các trờng tiêu đề
Các trờng tiêu đề của SIP giống với các trờng tiêu đề của HTTP về cả cú pháp và
ngữ nghĩa. Các trờng tiêu đề gồm tiêu đề chung, tiêu đề yêu cầu, tiêu đề đáp ứng, tiêu
đề thực thể.
Các trờng tiêu đề yêu cầu và tùy chọn, không dùng đợc cho mỗi chỉ thị đợc liệt kê
trong bảng 3.1.
Trong đó:
o (optional): chỉ ra tùy chọn. Tùy chọn có nghĩa rằng một UA có thể
chứa trờng tiêu đề trong một yêu cầu và đáp ứng và UA có thể bỏ qua tr-
ờng tiêu đề nếu nó tồn tại trong một yêu cầu và đáp ứng.
m (mandatory): bắt buộc. Một trờng tiêu đề yêu cầu bắt buộc phải có
mặt trong một yêu cầu, và trờng tiêu đề phải đợc UAC hiểu trong quá trình
xử lý đáp ứng.
_ (not applicate): không sử dụng đợc. Có nghĩa là các trờng tiêu đề
không đợc tồn tải trong một yêu cầu. Nếu một trờng nào đó có trong yêu
cầu do lỗi thì nó phải đợc UAS bỏ qua trong quá trình nhận yêu cầu.

*: chỉ ra rằng trờng tiêu đề chỉ cần thiết nếu thân bản tin không rỗng.
m*: chỉ thị một tiêu đề nên đợc gửi, nhng Server cần phải chuẩn bị nhận
các yêu cầu mà không có trờng tiêu đề đó.
Cột Where miêu tả kiểu yêu cầu và đáp ứng mà trờng tiêu đề đợc sử dụng
Trong đó:
R: đề cập đến các trờng tiêu đề đợc sủ dụng trong các yêu cầu (đó là các
trờng tiêu đề chung và yêu cầu).
r: chỉ định một trờng tiêu đề chung hay đáp ứng, áp dụng cho tất cả các
đáp ứng.
g: đặt tên trờng tiêu đề chung.
e: đặt tên trờng tiêu đề thực thể.
c: sao chép trờng tiêu đề từ yêu cầu đến đáp ứng.
Cột proxy chỉ ra các Proxy có thể thêm các thành phần riêng biệt vào các tiêu
đề hay không.
Lữ Văn Thắng, D2001VT
69
Đồ án tốt nghiệp đại học Chơng III. Giao thức khởi tạo phiên SIP
Trong đó:
c: chỉ thị cho móc nối
m: có thể thay đổi tiêu đề
a: có thể thêm tiêu đề nếu không tồn tại
r: đọc tiêu đề
Bảng 3.1 Tóm tắt các trờng tiêu đề
Header Field where proxy ACK BYE CAN INV OPT REG
(1) (2) (3) (4) (5) (6) (7) (8) (9)
Accept R - o o o o o
Accept 415 - o o o o o
Accept r - - - o o o
Accept - Encoding R - o o o o o
Accept - Encoding 415 - o o o o o

Accept - Language R - o o o o o
Accept - Language 415 - o o o o o
Alert - Info R am - - - o - -
Allow R o o o o o o
Allow 200 - - - o o o
Allow 405 m m m m m m
Also R - o - - - -
Authorization R o o o o o o
Authorization r o o o o o o
Call - ID gc r m m m m m m
Call - Info g am - - - o o o
Contact R o - - m o o
Contact 1xx - - - o o -
Contact 2xx - - - m o o
Contact 3xx - o - o o o
Bảng 3.1 Tóm tắt các trờng tiêu đề (tiếp)
(1) (2) (3) (4) (5) (6) (7) (8) (9)
Contact 485 - o - o o o
Content - Disposition e o o - o o o
Content - Encoding e o o - o o o
Content - Language e o o o o o o
Content - Length e r m* m* m* m* m* m*
Content - Type e * * - * * *
CSeq gc r m m m m m m
Date g a o o o o o o
Encryption g r o o o o o o
Lữ Văn Thắng, D2001VT
70
Đồ án tốt nghiệp đại học Chơng III. Giao thức khởi tạo phiên SIP
Error - Info R o o o o o o

Expires g - - - o - o
From gc r m m m m m m
In - Reply - To R - - - o - -
Max - Forwards R rm o o o o o o
MIME - Version g o o o o o o
Organization g am - - - o o o
Priority R a - - - o - -
Proxy - Authenticate
401,
407
o o o o o o
Proxy - Authorization R r o o o o o o
Proxy - Require R r o o o o o o
Record - Route R amr o o o o o o
Record - Route
2xx,
401,
484
o o o o o o
Require g acr o o o o o o
Response - Key R - o o o o o
Retry - After R - - - - - o
Bảng 3.1 Tóm tắt các trờng tiêu đề (tiếp)
(1) (2) (3) (4) (5) (6) (7) (8) (9)
Retry - After
404,
413,
480,
486,
500,

503,
600,
603
o o o o o o
Route R r o o o o o o
Server r o o o o o o
Subject R - - - o - -
Supported g - o o o o o
Timestamp g o o o o o o
To gc(1) r m m m m m m
Unsupported R o o o o o o
Unsupported 420 o o o o o o
User - Agent g o o o o o o
Via gc acmr m m m m m m
Lữ Văn Thắng, D2001VT
71