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.
• 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. (adsbygoogle = window.adsbygoogle || []).push({});
- 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 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 đó. (adsbygoogle = window.adsbygoogle || []).push({});
• 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.
- Nếu chứa tham số maddr: việc gửi tr−ờng đến địa chỉ đa sắc thái đ−ợc liệt kê ở đây, sử dụng cổng đ−ợc chỉ ra trong “sent - by” hoặc cổng 5060 nếu không có cổng nào có mặt. Đáp ứng đ−ợc gửi sử dụng TTL chỉ ra trong tham số “ttl”, hoặc TTL = 1 thì tham số này không có mặt.
- Nếu tr−ờng Via thứ hai không chứa tham số maddr và là 1 tr−ờng receiver
- tagged, thì sẽ gửi bản tin đến địa chỉ trong tham số received, sử dụng cổng chỉ ra trong giá trị sent-by, hoặc sử dụng cổng 5060 nếu tham số này không có mặt.
- Nếu không rơi vào các tr−ờng hợp tr−ớc, thì gửi bản tin đến địa chỉ chỉ ra bởi giá trị sent - by trong tr−ờng tiêu đề Via thứ hai.
• 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.