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 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ú lưu ý 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.
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 (adsbygoogle = window.adsbygoogle || []).push({});
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 đú.
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, nhưng 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.
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 (adsbygoogle = window.adsbygoogle || []).push({});
(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 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 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 Warning r o o o o o o WWW - Authenticate R o o o o o o WWW - Authenticate 401 o o o o o o
3.2.1.1 Khuụn dạng trường tiờu đề
Cỏc trường tiờu đề kể trờn thường gồm tờn trường, sau đú là dấu ”:”, và giỏ trị của trường.
Khuụn dạng của trường tiờu đề bản tin như sau:
message - header = field - name ":" [ field - value ] CRLF field - name = token
field - value = *( field - content | LWS )
Trong đú field - content là cỏc OCTET tạo nờn giỏ trị trường tiờu đề và bao gồm * TEXT - UTF8 hoặc sự kết hợp của token, separators và quoted - string.
3.2.1.2 Cỏc trường tiờu đề chung
Cỏc trường tiờu đề chung ỏp dụng cho cả cỏc bản tin yờu cầu và bản tin đỏp ứng. Cỏc tờn trường “general- header” cú thể được mở rộng khi kết hợp với sự thay đổi về phiờn bản giao thức. Tuy nhiờn, trường tiờu đề mới hoặc đang thử nghiệm cú thể cú nghĩa như cỏc trường tiờu đề chung nếu tất cả cỏc bờn trong phiờn truyền thụng đều nhận biết được chỳng là cỏc trường “tiờu đề chung”. Cỏc trường tiờu đề khụng nhận biết được xử lý như cỏc trường “tiờu đề thực thể”.
1) Tiờu đề Accept
Khi cú sự xuất hiện của trường Accept, Server sẽ phỏt đi một giỏ trị mặc định của ứng dụng /sdp. Giống như một trường tiờu đề yờu cầu, nú chỉ được sử dụng trong cỏc chỉ thị cú thõn bản tin.
2) Tiờu đề Accept - Endcoding
Trường tiờu đề yờu cầu Accept - Endcoding cũng giống như tiờu đề Accept nhưng hạn chế mó nội dung biểu diễn sự chấp nhận của đỏp ứng.
3) Tiờu đề Accept - Language
Cỳ phỏp phần tiờu đề ngụn ngữ chấp nhận quy định về lệnh trong ngụn ngữ dựa vào tham số q giống như ỏp dụng vào SIP. Trường tiờu đề yờu cầu Accept - Language cho phộp Client thụng bỏo cho Server ngụn ngữ nú mong muốn để nhận reason phrases, miờu tả phiờn hay đỏp ứng trạng thỏi được truyền tải như thõn bản tin. Một Proxy cú thể sử dụng trường này để trợ giỳp việc lựa chọn đớch đối với cỏc cuộc gọi.
4) Tiờu đề Call -ID
Trường tiờu đề chung Call - ID xỏc định một lời mời thành viờn hoặc tất cả cỏc đăng ký của một Client thành viờn một cỏch duy nhất. Chỳ ý rằng một hội nghị đa phương tiện đơn giản cú thể thờm vài cuộc gọi với cỏc Call - ID khỏc nhau, nếu người sử dụng mời nhiều lần khỏc nhau đến cựng một hội nghị.
Đối với một yờu cầu INVITE, một UAS bị gọi khụng nờn cảnh bỏo với người sử dụng đú nếu người sử dụng đó đỏp lại Call - ID trong yờu cầu INVITE. Nếu người sử dụng đó là một thành viờn của hội nghị và cỏc tham số của hội nghị đó được chứa trong miờu tả phiờn khụng cú thay đổi, thỡ UAS bị gọi này cú thể chấp nhận cuộc gọi bất chấp Call - ID. Một lời mời cho Call - ID hoặc phiờn hiện tại cú thể thay đổi cỏc tham số của hội nghị. Một ứng dụng của Client cú thể đưa ra một chỉ thị đơn giản tới người sử dụng về cỏc tham số của hội nghị đó được thay dổi và chấp nhận cuộc gọi tự động hoặc nú cú thể yờu cầu người sử dụng xỏc nhận .
Một người sử dụng cú thể được mời đến cựng một hội nghị hoặc cuộc gọi sử dụng nhiều Call - ID khỏc nhau. Client cú thể loại những bản sao này nếu muốn bằng cỏch sử dụng cỏc nhận dạng trong miờu tả phiờn.
Chỉ thị REGISTER và OPTION sử dụng giỏ trị Call - ID để yờu cầu được giống hoàn toàn với đỏp ứng. Tất cả cỏc yờu cầu REGISTER đưa ra bởi một Client phải cú cựng một Call - ID.
5) Tiờu đề Contact (adsbygoogle = window.adsbygoogle || []).push({});
Trường tiờu đề chung Contact cú thể xỏc nhận trong yờu cầu INVITE, OPTION, ACK, REGISTER và trong đỏp ứng 1xx, 2xx, 3xx và 485. Thụng thường nú cung cấp URL để người sử dụng cú thể cú cỏc giao tiếp xa hơn.
• Cỏc yờu cầu INVITE, OPTION và ACK: Cỏc yờu cầu INVITE bắt buộc và yờu cầu ACK cú thể chứa tiờu đề Contact để chỉ ra vị trớ khởi tạo yờu cầu. Đối với OPTION, Contact đưa ra gợi ý về địa chỉ cỏc yờu cầu SIP cú thể được gửi đến.
• Cỏc đỏp ứng 2xx INVITE và OPTION: Một Server gửi đỏp ứng 2xx cú thể chốn vào một tiờu đề đỏp ứng Contact để chỉ ra địa chỉ SIP trong cựng một Call - ID. Trường tiờu đề Contact chứa địa chỉ của Server hoặc của Proxy, nếu Host ở phớa sau tường lửa. Giỏ trị tiờu đề được sao chộp vào trường Request - URI của yờu cầu tiếp theo cho cuộc gọi này. Nếu đỏp ứng khụng chứa tiờu đề Record - Route thỡ địa chỉ trong trường tiờu đề Contact được bổ sung như phần tử cuối cựng trong trường tiờu đề Route. Nếu một UA sử dụng cả TCP và UDP nú khụng nờn chỉ thị một tham số truyền tải trong URI.
• Cỏc đỏp ứng INVITE 1xx: Một UAS gửi một đỏp ứng 1xx cú thể chốn vào tiờu đề đỏp ứng Contact. Nú cũng cú ý nghĩa như đỏp ứng 1xx và đỏp ứng Invite 2xx. Chỳ ý rằng yờu cầu CANCEL phải khụng được gửi đến địa chỉ đú, đỳng hơn là nú cựng đường dẫn như yờu cầu ban đầu.
• Cỏc yờu cầu RIGISTER: Yờu cầu REGISTER cú thể chứa trường tiờu đề Contact chỉ ra vị trớ người sử dụng cú thể đến. Yờu cầu RIGISTER định nghĩa trường Contact “*” chỉ được sử dụng với expire ‘0’ để loại bỏ tất cả cỏc đăng ký người sử dụng đặc biệt. Một tham số expire tuỳ chọn chỉ ra thời gian kết thỳc của đăng ký. Nếu Contact nào khụng cú tham số expire thỡ trường tiờu đề expires được sử dụng như giỏ trị mặc định.
• Cỏc đỏp ứng 2xx REGISTER : Một đỏp ứng REGISTER cú thể quay về tất cả cỏc vị trớ mà người sử dụng hiện tại cú thể đạt đến. Một tham số expire mặc định
• Cỏc đỏp ứng 3xx và 405 : Trường tiờu đề đỏp ứng Contact cú thể sử dụng chung với mó đỏp ứng 3xx và 485 để chỉ ra một hoặc nhiều địa chỉ thay thế. Nú cú thể xuất hiện trong cỏc đỏp ứng trong chỉ thị BYE, INVITE, OPTION. Trường tiờu đề Contact chứa URIs đưa ra vị trớ mới hoặc tờn của User để thử hoặc cú thể là cỏc tham số truyền tải bổ sung đặc biệt.
• Cỏc đỏp ứng 4xx, 5xx, 6xx: Trường tiờu đề đỏp ứng CONTACT cú thể được sử dụng trong cỏc đỏp ứng 4xx, 5xx, 6xx để chỉ ra vị trớ để bổ xung thụng tin về lỗi cú thể tỡm ra.
Một trường tiờu đề đỏp ứng Contact cú thể chứa bất kỳ URI thớch hợp để chỉ ra bị