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
Client này. Việc xử lý phụ thuộc vào trường Via có chứa tham số maddr hay là trường receive - tagged không.
User Agent và Redirect Server
UAS hoặc Server gửi truyền một đáp ứng dựa trên các quy định sau:
- Nếu trường tiêu đề Via đầu tiên trong yêu cầu chứa tham số maddr thì gửi đáp ứng đến địa chỉ đa sắc thái được liệt kê ở đó, sử dụng cổng chỉ ra trong sent- by, hoặc cổng 5060, các cổng không có mặt.
- Nếu địa chỉ trong giá trị sent - by của trường Via đầu tiên khác với địa chỉ nguồn của gói, thì gửi đáp ứng đến địa chỉ nguồn gói hoạt động giống với trường hợp xử lý trường tiêu đề Via receiver - tagged.
- Nếu các điều kiện trên không đúng, thì gửi đáp ứng đến địa chỉ chứa giá trị sent-by. Nếu đáp ứng được gửi sử dụng TCP, sử dụng kết nối TCP đang tồn tại nếu nó khả dụng.
3.4.1.3 Các trường tiêu đề thực thể
Các trường tiêu đề thực thểđịnh nghĩa siêu thông tin về thân bản tin hoặc nếu thân bản tin không có mặt thì nó thể hiện các tài nguyên để định danh theo yêu cầu. Thuật ngữ “tiêu đề thực thể” là thuật ngữ HTTP 1.1 ởđó phần chính của đáp ứng có
thể chứa phiên vận chuyển phần chính của bản tin. Thân của bản tin ban đầu được gọi là “thực thể”.
Tiêu đề Allow
Trường tiêu đề cho phép liệt kê tập hợp các chỉ thị được hỗ trợ bởi tài nguyên định nghĩa bởi yêu cầu URI. Mục đích các trường này là thông báo đến người nhận các chỉ thị giá trị kết hợp với tài nguyên một cách chính xác. Trường tiêu đề cho phép có mặt trong đáp ứng 405( Method Not Allowed ) và trong đáp ứng OPTION.
Khuôn dạng:
Allow = "Allow" ": " 1#Method Tiêu đề Content - Encoding
Giá trị của trường tiêu đề thực thể Content - Encoding chỉ ra các mã hoá phù hợp được ứng dụng trong phần thân của thực thể, và vì vậy cơ chế giải mã phải được ứng dụng đểđạt được kiểu phương tiện trong trường tiêu đề Content - Type.
Nếu nhiều mã hoá được dùng trong thực thể thì mã hoá phù hợp phải được sắp xếp đặt theo thứ tự chúng được dùng.
Client có thể dùng mã hoá Content vào phần chính của yêu cầu. Nếu Server không có khả năng mã hoá phần chính hoặc phần không thể nhận biết được bất kỳ giá trị Contant - Encoding nào, thì nó phải gửi đáp ứng 415( Unsupporterd Media Type ), liệt kê các mã hoá có thể chấp nhận trong tiêu đề Accept - Encoding. Một Server có thể áp dụng Content - Encoding vào phần chính trong các đáp ứng. Server chỉ được sử dụng các mã hoá đã liệt kê trong tiêu đề Accep - Encoding trong yêu cầu.
Tiêu đề Content - Length
Giá trị trường tiêu đề Content - Length chỉ ra kích cỡ phần chính của bản tin, là số octet tính theo thập phân gửi đến phía nhận. Các ứng dụng nên dùng trường này để chỉ ra kích cỡ phần chính của bản tin đã truyền đi, bất kể kiểu phương tiện gì của thực thể. Giá trị Content - Length lớn hơn hoặc bằng 0 đều được sử dụng ( bằng 0 khi phần chính trong bản tin không có ). Nếu một Server nhận yêu cầu UDP không có trường Content - Length thì nó phải giả sử rằng yêu cầu bao vây phần dư của gói. Nếu Server nhận yêu cầu UDP có trường Content - Length, mà giá trị của nó lớn
hơn kích cỡ của phần thân bản tin gửi trong yêu cầu, thì Client nên tạo ra đáp ứng lớp 400. Nếu có dữ liệu bổ sung trong gói UDP sau khi byte cuối cùng của thân bản tin được đọc, thì Server phải xử lý phần dữ liệu như bản tin riêng. Điều này cho phép nhiều bản tin được đặt trong cùng một gói UDP.
Tiêu đề Content - Type
Tiêu đề Content - Type chỉ ra kiểu phương tiện của thân bản tin gửi đến phía nhận