Các trưòng tiêu đề yêu cầu cho phép Client chuyển qua các thông tin bổ sung theo yêu cầu và các thông tin về Client đến Server. Các trường này hoạt động như các bộ thay đổi theo yêu cầu với nghĩa tượng trưng với các tham số của ngôn ngữ lập trình.
1) Tiêu đề Authorziation
Một UA muốn xác định bản thân mình với một UAS hay REGISTER, sau khi nhận được đáp ứng 401, có thể làm điều này bằng cách đưa trường tiêu đề yêu cầu Authorization vào một yêu cầu. Giá trị trường Authorization bao gồm các uỷ nhiệm chứa thông tin cho phép UAS biết phạm vi hoạt động của tài nguyên đã được yêu cầu.
2) Tiêu đề Max - Forwards
Trường tiêu đề yêu cầu Max - Forwards sử dụng phương pháp SIP để hạn chế số Proxy hoặc số cổng trên hướng mà yêu cầu đi đến Server tiếp theo. Giá trị Max - Forwards là số nguyên thập phân chỉ ra số lần duy trì bản tin yêu cầu này được cho phép theo hướng truyền.
Mỗi Proxy nhận hoặc Gateway nhận yêu cầu chứa trường tiêu đề Max - Forwards phải kiểm tra và cập nhật giá trị của nó ưu tiên về việc định hướng yêu cầu:
- Nếu giá trị bằng 0: phía nhận không phải định hướng trước yêu cầu và trở về 483 ( Too many hop ). Thay vào đó, một Server có thể hoạt động như một đầu nhận cuối cùng cho các yêu cầu OPTION.
- Nếu giá trị lớn hơn 0: thì bản tin đã định hướng phải chứa trường Max- Forwards đã cập nhật với giá trị giảm đi 1.
3) Tiêu đề Priority
Trường tiêu đề yêu cầu chỉ ra sự khẩn thiết của yêu cầu khi Client nhận được. 4) Tiêu đề Proxy - Authorization
Trường tiêu đề yêu cầu Proxy - Authorization cho phép Client xác định bản thân nó cho Proxy xác thực. Giá trị trường Proxy - Authorization bao gồm các uỷ quyền có chứa thông tin xác thực của User Agent cho Proxy và/hoặc về phạm vi hoạt động của tài nguyên được yêu cầu.
5) Tiêu đề Proxy - Require
Trường Proxy - Require sử dụng để chỉ ra các điểm nhạy cảm của Proxy được hỗ trợ bởi Proxy.
6) Tiêu đề Response - Key
Client có thể sử dụng trường tiêu đề Response - Key để yêu cầu khóa mà User Agent sử dụng mã hoá đáp ứng đó.
Trường tiêu đề yêu cầu Route xác định tuyến diễn ra yêu cầu. Mỗi Host loại bỏ lối vào đầu tiên và sau đó các Proxy yêu cầu Host liệt kê lối vào đó và cũng sử dụng nó như Request - URI.
8) Tiêu đề Subject
Trường tiêu đề này được dự định để cung cấp các tổng kết, hoặc chỉ ra bản chất của Call, cho phép lọc Call mà không có sự phân tích các miêu tả hội nghị.
3.4.2. Các trường tiêu đề đáp ứng
Các trường tiêu đề đáp ứng cho phép Server bỏ qua các thông tin bổ sung về đáp ứng khi không thể đặt trong Status - Line. Các trường tiêu đề này đưa ra các thông tin về Server và về các truy nhập xa hơn đến tài nguyên được định danh bởi Request - URI.
Tuy nhiên, trường tiêu đề mới hoặc đang thử nghiệm có thể có nghĩa như trường “Respone-header” nếu tất cả các bên trong truyền thông đều nhận biết được chúng là các trường “Respone -header”. 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 đề Proxy - Authenticate
Trường tiêu đề đáp ứng Proxy - Authenticate phải được kể đến như một phần của đáp ứng 407 ( Proxy Authentication Required ). Giá trị của trường bao gồm các nhận dạng để chỉ ra hệ thông xác thực và các tham số ứng dụng vào Proxy đối với Request - URI này.
2) Tiêu đề Retry - After
Trường tiêu đề chung Retry - After có thể được sử dụng với đáp ứng 563 ( Service Unavaiable) để chỉ ra dịch vụđược mong đợi không có giá trị trong bao lâu từ khi Client yêu cầu và với đáp ứng 404 ( Not found ); 600 ( Busy ); hoặc 603 ( Decline ) để chỉ ra khi nào phía bị gọi khả dụng lại. Giá trị của trường này có thể là SIP - date hoặc số nguyên giây theo sau thời gian đáp ứng.
Trường tiêu đề đáp ứng Server chứa thông tin về phần mềm được sử dụng bởi User Agent Server để xử lý yêu cầu.
4) Tiêu đề Unsupported
Một trường tiêu đềđáp ứng Unsupported liệt kê các đặc điểm mà Server không hỗ trợ.
5) Tiêu đề Warning
Trường tiêu đềđáp ứng Warning được sử dụng để mang các thông tin bổ sung về trạng thái của đáp ứng. Một Server bất kỳ có thể bổ sung tiêu đề Warning vào đáp ứng Proxy Server phải đặt tiêu đề Warning bổ sung vào trước tiêu đề nhận thức bất kỳ.
3.4.2 Mã trạng thái
Mã đáp ứng ( Respone - Code ) của SIP được mở rộng từ mã đáp ứng trong HTTP/1.1, chỉ có những mã phù hợp của HTTP /1.1 mới được đưa vào trong SIP. 3.4.2.1 Informational 1xx
Đáp ứng Informational cho biết Server hoặc Proxy liên lạc đang thực hiện vài hoạt động và vẫn chưa nhận được một đáp ứng cuối cùng. Khách hàng phải đợi một đáp ứng xa hơn từ Server. Server gửi một đáp ứng 1xx nếu như nó muốn đợi một khoảng thời gian lớn hơn hoặc bằng 200ms để nhận được một đáp ứng cuối cùng. Một Server có thể phát ra nhiều đáp ứng 1xx. Chú ý rằng, đáp ứng 1xx không có độ tin cậy truyền dẫn, có nghĩa là nó không phải là nguyên nhân khiến cho khách hàng gửi một ARC. Các Server có thể tự do phát lại các đáp ứng Informational và khách hàng có thể kiểm tra trạng thái hiện tại của việc xử lý gọi bằng cách gọi lại các yêu cầu.
3.4.2.2 Successful 2xx
3.4.2.3 Redirection 3xx
Các đáp ứng 3xx đưa ra thông tin về vị trí mới của User, hoặc về dịch vụ để hoàn thành cuộc gọi. Chúng có thể kết thúc tìm kiếm hiện tại và có thể tạo ra một tìm kiếm mới nếu nó phù hợp.
3.4.2.4 Request Failure 4xx
Đáp ứng 4xx chỉ rõ các đáp ứng lỗi từ một Server riêng biệt. Khách hàng không thể gửi lại cùng một yêu cầu mà không có sự thay đổi
Tuy nhiên yêu cầu giống nhau từ một Server khác thì có thể vẫn thành công. 3.4.2.5 Server Failure 5xx
Đáp ứng 5xx là đáp ứng lỗi khi chính Server bị lỗi. 3.4.2.6 Global Farlures 6xx
Đáp ứng 6xx chỉ ra rằng yêu cầu không được đáp ứng tại mọi Server. 3.5 Hoạt động của SIP Client và SIP Server
SIP có thể sử dụng cả giao thức UDP ( User Datagram Protocol ) và TCP ( Transmission Control Protocol ) như những giao thức truyền.
3.5.1 Yêu cầu
Server loại bỏ những yêu cầu giống nhau và truyền lại những đáp ứng thích hợp. Sau khi nhận một yêu cầu CANCEL từ Upstream Client, một Stateful Proxy Server sẽ gửi một yêu cầu CANCEL tới tất cả các nhánh nơi nó không nhận được đáp ứng cuối cùng. Khi một UA nhận được một yêu cầu, nó sẽ kiểm tra lại trường Call - ID dựa trên cuộc gọi đang diễn ra.
Nếu như Call - ID được tìm thấy, nó sẽ so sánh giá trị Tag của trường To với “tag” của user và sẽ từ chối yêu cầu nếu như hai giá trị đó không giống nhau. Nếu giá trị của tiêu đề From ( kể cả các giá trị Tag ) giống với giá trị của cuộc gọi hiện tại, Server sẽ so sánh đến giá trị của trường tiêu đề CSeq. Nếu giá trịđó nhỏ hơn hoặc bằng giá trị CSeq hiện tại thì yêu cầu đó là yêu
cầu phát lại. Nếu không đó là một yêu cầu mới. Nếu như tiêu đề From không giống với tiêu đề From của cuộc gọi hiện tại, một cuộc gọi mới đã được thiết lập.
Nếu giá trị Call - ID không tìm thấy, một cuộc gọi mới đã được thiết lập với các giá trị được ghi vào các trường mào đầu To, From và Call - ID. Trong trường hợp này, trường tiêu đề To không chứa một thẻ địa chỉ ( Tag ). Server trả lại một đáp ứng chứa cùng một giá trị của trường To nhưng với một thẻđịa chỉ duy nhất được thêm vào thẻ địa chỉ có thể được bỏ qua nếu yêu cầu chỉ chứa một trường tiêu đề Via.
3.5.2 Đáp ứng
Một Server có thể phát ra một hay nhiều đáp ứng tạm thời trước khi gửi một đáp ứng cuối cùng nếu như một Stateful Proxy, UAS, Redirect Server hay Registrar không thể trả lời một yêu cầu cho đáp ứng cuối cùng trong vòng 200 ms, nó sẽ phát ra một đáp ứng tạm thời loại 1xx càng sớm càng tốt. Stateless Proxy không thể phát các đáp ứng tạm thời cho bản thân chúng.
3.6 Địa chỉ nguồn, địa chỉđích và các kết nối 3.6.1 Unicast UDP
Các đáp ứng được trả lại danh sách địa chỉ trong trường mào đầu Via không có địa chỉ nguồn của đáp ứng. Với cuộc gọi về các đáp ứng không được phát ra bởi next-hop stateless server mà được phát ra bởi 1 proxy hay UAS. Do đó, stateless proxy có thể sử dụng trong trường tiêu đề Via để gửi các đáp ứng.
3.6.2 Multicast UDP
Các yêu cầu có thể là quảng bá ( multicast ), yêu cầu multicast có thểđặc trưng cho một Host và không phụ thuộc vào trường Request - URI. Yêu cầu này đảm bảo rằng nó không thể ra khỏi phạm vi của một hệ thống quản lí điều này có thể thực hiện với TTL hay phạm vi quản lí tuỳ theo sự thực hiện của nó trong mạng.
Một Client nhận được một yêu cầu multicast không phải kiểm tra xem thành phần Host của trường Request -URI có giống với Host hay tên vùng của nó không. Nếu yêu cầu được nhận thông qua multicast thì đáp ứng trở lại phải thông qua multicast. Đáp ứng cho các yêu cầu multicast được phát quảng bá với cùng thông số TTL như trong yêu cầu. TTL được lấy ra từ thông số ttl trong trường tiêu đề Via.
Để tránh việc các đáp ứng bị “kép” ( implosion ), Server phải trả lời các yêu cầu multicast bằng một mã trạng thái khác với trạng thái 2xx và 6xx. Thời gian trễ của các đáp ứng nhỏ hơn hoặc bằng 1s. Server có thể ngừng các đáp ứng nếu như nó nhận được các đáp ứng có số nhỏ hơn hay đáp ứng 6xx từ nhóm các thành viên ưu tiên khác. Server không trả lời các yêu cầu CANCEL nhận được thông qua phát quảng bá để tránh việc yêu cầu bị “kép”. Proxy hoặc UAC có thể gửi 1 yêu cầu CANCEL khi nhận được một đáp ứng 2xx hay 6xx đầu tiên cho một yêu cầu multicast. Server có thể ngừng đáp ứng nếu yêu cầu đòi hỏi Server phải vi phạm các nguyên tắc xử lí bản tin cơ bản.
3.6.3 Kết nối TCP
Một kết nối TCP đơn có thể lưu trữ một hay nhiều giao dịch SIP. Một giao dịch SIP không chứa hay chứa nhiều đáp ứng tạm thời theo sau là một hay nhiều đáp ứng cuối cùng. Client có thể kết nối khi mà đáp ứng cuối cùng đầu tiên tới. Nếu Client đóng hoặc xác lập lại kết nối TCP ưu tiên để nhận được các đáp ứng cuối cùng đầu tiên, Server sẽ coi hoạt động này như một yêu cầu CANCEL. Hoạt động này phải được hạn chế vì có thể khiến Client làm việc sai chức năng dẫn đến một Proxy Server sẽ chiếm dữ một kết nối vô thời hạn.
Server không được đóng kết nối TCP cho đến khi nó gửi đi một đáp ứng cuối cùng. Tuy nhiên, bình thường thì Client chịu trách nhiệm đóng kết nối. Nếu như một Server muốn trả lại một đáp ứng cho Client mà không muốn mở một kết nối dành cho Client đó thì nó sẽ mở một kết nối khác tới danh sách địa chỉ trong trường Via. Theo cách đó một Proxy hay UA phải được xử lí đặc biệt để nhận cả các yêu cầu và đáp ứng trong cùng một kết nối thụđộng ( passive connection ).
3.7 Hoạt động của UA ( User - Agent )
Phần này mô tả các nguyên tắc mà UAC và UAS dùng để tạo và xử lí các yêu cầu và đáp ứng.
3.7.1 Phía gọi phát yêu cầu Intive yêu cầu
Khi một UAC muốn khởi tạo một cuộc gọi, nó sẽđưa ra một yêu cầu INVITE. Trường To trong yêu cầu chứa địa chỉ người gọi. Trường Request - URI chứa cùng địa chỉđó. Trường From chứa địa chỉ của phía bị gọi. Nếu địa chỉ From có thể xuất hiện trong yêu cầu phát ra từ UAC cho cùng một cuộc gọi thì phía gọi phải cài thông số Tag trong trường From. UAC có thể nhập thêm trường Contact chứa một địa chỉ mà nó muốn liên lạc sau khi người bị gọi kết thúc hội thoại với phía gọi.
Về danh sách địa chỉ trong trường địa chỉ Via. Nếu giống nhau, thì địa chỉ branch trong trường Via được kiểm tra. Nếu nó giống với một branch đã biết, đáp ứng được xử lý bởi một Virtual Client. Nếu không đáp ứng sẽ bị loại bỏ.
Nếu một yêu cầu cần được nhận thông qua giao thức TCP, Proxy sẽ kiểm tra xem nó đã có kết nối hiện tại nào tới địa chỉ của nó chưa. Nếu có thì đáp ứng sẽ được gửi qua kết nối đó. Nếu không một kết nối TCP mới sẽ được thiết lập thông qua địa chỉ và cổng trong trường Via và đáp ứng sẽ được gửi qua đó. Chú ý rằng một UAC hay Proxy đều được xử lý đặc biệt để nhận các đáp ứng tới qua một kết nối TCP. Các đáp ứng 2xx phải được truyền lại bởi các Proxy thậm chí qua cả một kết nối TCP.
3.7.2 Phía bị gọi phát đáp ứng
Khi phía bị gọi nhận được yêu cầu INTIVE, phía bị gọi có thể chấp nhận, gửi lại hay huỷ bỏ cuộc gọi. Trong tất cả các trường hợp trên nó phát ra một đáp ứng. Đáp ứng này phải sao chép lại các giá trị trong trường To, From, Call - ID CSeq và Via từ yêu cầu. Thêm vào đó, đáp ứng UAS phải bổ sung tham số Tag vào trường To nếu yêu cầu chứa nhiều hơn một trường tiêu đề Via. UAS có thể nhập thêm một trường tiêu đề Contact vào đáp ứng. Nó chứa một địa chỉ mà phía bị gọi muốn liên lạc cho giao dịch tiếp theo bao gồm cả ACK cho INVITE hiện tại. UAS lưu giữ giá
trị của trường To và From kể cả các thẻ Tag. Chúng sẽ trở thành địa chỉ nội bộ hay địa chỉ xa của các Call - leg tương ứng.
3.7.3 Phía gọi nhận được đáp ứng ban đầu
Nhiều đáp ứng có thể đến cùng một UAC cho một yêu cầu INVITE, mỗi đáp ứng được phân biệt bằng tham số Tag trong trường tiêu đề To và đại diện cho một Call - leg riêng. Phía gọi có thể công nhận hay kết thúc với mỗi đáp ứng UAS. Để thừa nhận nó gửi một yêu cầu ACK còn để kết thúc nó gửi yêu cầu BYE. Trường tiêu đề To From trong đáp ứng 200 bao gồm cả các thẻ Tag. Trường Request - URI của ACK hay BYE có thể thiết lập bất cứ địa chỉ nào được tìm thấy trong trường tiêu đề Contact nếu nó tồn tại. Lần lượt UAC sẽ sao chép các địa chỉ từ trường tiêu đề To vào trường Request -URI. UAC cũng lưu ý đến giá trị của trường tiêu đề To và From trong mỗi đáp ứng với mỗi Call - leg trường tiêu đề To sẽ trở thành địa chỉ xa còn trường From trở thành địa chỉ nội bộ.
3.7.4 Phía gọi hay bị gọi phát ra yêu cầu tiếp theo
Khi một cuộc gọi được thiết lập cả phía gọi hoặc bị gọi có thể phát ra yêu cầu INTIVE hay BYE để thay đổi hay kết thúc cuộc gọi không chú ý đến phía gọi hay bị gọi phát ra yêu cầu mới, trường tiêu đề trong yêu cầu được thiết lập như sau: Với mỗi Call - leg giá trị trường tiêu đề To sẽđược thiết lập thành địa chỉ xa còn trường From sẽ thành địa chỉ nội bộ. Trường tiêu đề Contact có thể khác với trường Contact được gửi đi trong yêu cầu hay đáp ứng trước đó. Trường Request - URI thiết lập giá trị của trường tiêu đề Contract nhận được trong một yêu cầu hay đáp