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
6xx: Global - Farlure : Yêu cầu không được đáp ứng tại mọi Server
3.3. Thân bản tin SIP ( SIP Message Body ) 3.3.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.3.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.3.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.3.4 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.4 Định nghĩa các trường tiêu đề và mã trạng thái trong bản tin SIP
3.4.1 Định nghĩa các trường tiêu đề
3.4.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.4.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ị.
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.
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.
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 danh sách. Server sao chép trường tiêu đề Record- route vào trường tiêu đề Route của các yêu cầu tiếp theo trong cùng một nhánh call, với thứ tự các yêu cầu ngược lại để yêu cầu là gần nhất với UAC.
Nếu trường tiêu đề chứa trường tiêu đề Contact thì UAC chủ gọi bổ sung nội dung của nó như một tiêu đề Route cuối cùng. Trừ khi điều này gây lặp, bất kỳ
Client nào đều phải gửi yêu cầu tiếp theo bất kỳ đối với nhánh gọi này đến Request - URI đầu tiên trong trường tiêu đề yêu cầu Route và loại bỏ lối vào này. 11) Tiêu đề Require
Client sử dụng trường tiêu đề yêu cầu Require để nói cho các UAS về các tuỳ chọn mà Client mong đợi các Server hỗ trợ để xử lý thích hợp yêu cầu. Nếu một Server không hiểu tuỳ chọn nó phải đáp lại bằng cách quay trở về mã trạng thái 420 ( Bad Extension) và liệt kê những tuỳ chọn nó không hiểu trong tiêu đề Unsupported đó.
12) Tiêu đề Timestamp
Trường tiêu đề chung Timestamp miêu tả khi nào Client gửi yêu cầu đến Server. Giá trị của Timestamp chỉđáng kểđến Client và nó có thể sử dụng bất kỳđơn vị thời gian nào. Server phải hồi âm với cùng giá trị chính xác và có thể bổ sung thêm số dấu phẩy động để chỉ ra thời gian đã trôi từ khi nó nhận được yêu cầu.
13) Tiêu đề To
Trường tiêu đề chung To đặc tả phía nhận của yêu cầu, có cùng ngữ pháp SIP - URI với trường From. Các đáp ứng và yêu cầu phải thừa nhận trường tiêu đề chung To, chỉ ra phía nhận trong yêu cầu.
Tham số Tag phục vụ như một cơ chế chung để phân biệt nhiều trường hợp người sử dụng được định danh bằng một SIP - URL. Khi Proxy chia các yêu cầu, thì cần có phương tiện để phân biệt các đáp ứng từ mỗi chủ gọi. Trường Tag trong trường tiêu đề To dùng để phân biệt đáp ứng ở UAC.
14) Tiêu đề User - Agent
Trường tiêu đề chung User - Agent chứa thông tin về Agent User Client khởi tạo yêu cầu .
15) Tiêu đề Via
Trường Via chỉ ra tuyến mà yêu cầu đi qua do đó ngăn chặn được các yêu cầu bị lặp và đảm bảo trả lời trên cùng đường yêu cầu.
Request
Client khởi tạo yêu cầu phải chèn vào yêu cầu. Một trường Via chứa tên Host, địa chỉ mạng, số cổng mặc định hoặc số cổng để nhận được đáp ứng. Một Proxy nên kiểm tra trường tiêu đề Via đỉnh nhất để đảm bảo rằng nó chứa địa chỉ mạng chính xác của người gửi, khi nhìn từ Proxy. Nếu địa chỉ người gửi là không chính xác, Proxy phải bổ sung thuộc tính “received”.
Một Proxy gửi một yêu cầu đến địa chỉ quảng bá thì phải bổ sung tham số “maddr” vào trường tiêu đề Via, và cả tham số “ttl”. Nếu Server nhận yêu cầu chứa tham số “maddr” trong trường Via đỉnh nhất, thì nó nên gửi đáp ứng đến địa chỉ quảng bá đã liệt kê trong tham số ”maddr”.
Via Receiver - Tagged
Thông thường mỗi Host gửi hoặc định hướng bản tin SIP bổ sung vào trường Via để chỉ ra tuyến ngang qua. Tuy nhiên, có thể rằng NTAs thay đổi địa chỉ nguồn và cổng của yêu cầu, trong trường hợp này trường tiêu đề Via không thể tin vào việc trả lời tuyến. Để ngăn chặn điều này, một Proxy nên kiểm tra trường tiêu đề
Via đỉnh nhất đểđảm bảo rằng nó chứa địa chỉ mạng chính xác của người gửi, khi được nhìn từ phía Proxy. Nếu địa chỉ người gửi không chính xác, Proxy phải bổ sung tham số received vào trường tiêu đề Via, trường này được chèn vào bởi hop trước đó.
Response
Trường tiêu đề Via trong đáp ứng được xử lý bởi Proxy hoặc UAC theo quy tắc sau:
1.Trường tiêu đề Via đầu tiên nên chỉ ra Proxy hoặc Client xử lý đáp ứng này. Nếu không thì bản tin sẽ bị loại bỏ. Ngoài ra còn loại bỏ trường Via này. 2.Nếu không có trường tiêu đề Via thứ hai, thì đáp ứng này được định ra cho