Độ 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 đó.
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ộ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
(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 (adsbygoogle = window.adsbygoogle || []).push({});
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 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
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
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. (adsbygoogle = window.adsbygoogle || []).push({});
• 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 chỉ ra thời gian kết thúc của đăng ký.
• 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ị gọi nào có thể đạt đ−ợc, không hạn chế SIP URLs.
Các tham số sau đ−ợc định nghĩa:
- q: giá trị q chỉ ra −u tiên t−ơng đối giữa vị trí cho tr−ớc, 0<q<1, q càng lớn độ −u tiên càng cao.
- Action: tham số “action” đ−ợc sử dụng chỉ khi đăng ký với yêu cầu REGISTER. Nếu tham số này không đ−ợc đặc tả hoạt động xảy ra phụ thộc vào cấu hình Server thì trong các đáp ứng của nó, các bản sao phải chỉ ra chế độ đ−ợc sử dụng. Tham số này không đ−ợc chú ý trong các yêu cầu khác nhau.
- Expire : Tham số expire chỉ ra URI có giá trị trong bao lâu. 6) Tiêu đề Date
Là một tr−ờng tiêu đề chung phản ánh thời gian khi yêu cầu hoặc đáp ứng đ−ợc gửi đi lần đầu. Vì vậy mà các bản tin truyền lại có cùng giá trị tr−ờng tiêu đề dữ liệu nh− bản tin đầu tiên.
7) Tiêu đề Encryption
Tr−ờng tiêu đề mã hoá chung đặc tả nội dung đ−ợc mã hoá. Tr−ờng tiêu đề này th−ờng sử dụng cho các yêu cầu và đáp ứng end - to - end. Yêu cầu đ−ợc mã hoá dựa trên khoá công cộng phụ thuộc vào thực thể đ−ợc đặt tên trong tr−ờng tiêu đề To. Đáp ứng đ−ợc mã hoá dựa trên khoá công cộng truyền trong tr−ờng tiêu đề khoá đáp ứng.
Chú ý rằng bản thân khoá công cộng không đ−ợc sử dụng để mã hoá. Điều này phụ thuộc vào từng thuật toán đ−ợc sử dụng.
Đối với bất kỳ bản tin đã mã hoá nào, thì ít nhất có phần thân bản tin và có thể các tr−ờng tiêu đề khác đ−ợc mã hoá. Một ứng dụng nhận một yêu cầu hay đáp ứng chứa một tr−ờng tiêu đề Encrytion giải mã thân thực thể sau đó ghép bản tin gốc đến đ−ờng dây yêu cầu và đến các tiêu đề của bản tin ban đầu. Tiêu đề bản tin cuả phần đã giải mã thay thế hoàn toàn tiêu đề bản trong phần bản tin gốc với các tr−ờng có cùng tên.
Mã hoá chỉ để cung cấp sự bí mật : phía đích không đảm bảo rằng yêu cầu hoặc đáp ứng từ phía gửi đ−ợc liệt kê trong tiêu đề bản tin From, mà chỉ đảm bảo rằng phía gửi sử dụng khóa công cộng của phía đích. Tuy nhiên, các Proxy không có khả năng thay đổi yêu cầu hoặc đáp ứng.
Vì các Proxy có thể dựa vào sự quy định tr−ớc của chúng để kết hợp bất kỳ tr−ờng tiêu đề SIP nào, nên không có sự đảm bảo rằng các yêu cầu đã mã hoá có các tr−ờng tiêu đề “ẩn” sẽ đạt đến cùng đích nh− yêu cầu không mã hoá đ−ợc định danh khác nhau.
8) Tiêu đề From
Các đáp ứng và yêu cầu phải có tr−ờng tiêu đề chung From để chỉ ra bộ khởi đầu yêu cầu. Server sao chép tr−ờng tiêu đề From từ yêu cầu vào đáp ứng. Tr−ờng From có thể có tham số Tag. Giá trị Tag th−ờng là duy nhất và đ−ợc mã hoá ngẫu nhiên 32 bit. Một User duy trì giá trị Tag thông suốt trong một cuộc gọi đã định danh bằng Call - ID. 9) Tiêu đề Organization
Tr−ờng tiêu đề chung Organization hoặc truyền tên của tổ chức mà thực thể đ−a ra yêu cầu hoặc đáp ứng phụ thuộc vào. Tr−ờng này có thể đ−ợc sử dụng bằng phần mềm Client để lọc các cuộc gọi.
10) Tiêu đề Record - route
Tr−ờng tiêu đề đáp ứng và yêu cầu Record - Route đ−ợc bổ sung vào một yêu cầu bởi một proxy bất kỳ trong đ−ờng các yêu cầu tiếp theo cho cuộc gọi cùng nhánh. Nó chứa các SIP - URL có thể đến để xác định Proxy Server, gồm có một tham số địa chỉ ( maddr ) xác định vị trí của nó. Mỗi Proxy Server bổ sung Request - URI vào đầu của