Phương thức OPTIONS cho phép một UA truy vấn tới một UA khác hay một proxy server để nhận được thông tin về các phương thức được hỗ trợ, các kiểu nội dung và các thuộc tính mở rộng mà không cần phải thực hiện cuộc gọi tới phía bên kia. Ví dụ, trước khi một client chèn một trường tiêu đề "Require" chứa danh sách các tuỳ chọn mà nó không chắc chắn rằng UAS có thể hỗ trợ vào một bản tin INVITE, nó có thể truy vấn tới UAS đích bằng một bản tin OPTIONS để hỏi xem tuỳ chọn này có được hỗ trợ hay không. Kết quả các tuỳ chọn được hỗ trợ sẽ được lưu trong trường "Supported" của bản tin trả lời. Tất cả các UA phải hỗ trợ phương thức OPTIONS này.
Khi có nhu cầu biết được các khả năng của một tác nhân khác, UA sẽ tạo ra một bản tin OPTIONS và gửi tới tác nhân đó. Một yêu cầu OPTIONS cũng được cấu trúc theo chuẩn chung của các yêu cầu SIP.
Đáp ứng của một OPTIONS cũng được cấu trúc theo các quy tắc chuẩn của một đáp ứng SIP. Trong đó, mã của đáp ứng được chọn giống với mã của đáp ứng khi trả lời một bản tin INVITE. Đó là đáp ứng 200 (OK) khi UAS sẵn sàng chấp nhận cuộc gọi, 486 (Busy Here) khi UAS bận… Điều đó cho phép một yêu cầu OPTIONS có thể được sử dụng để xác định trạng thái cơ bản của một UAS rằng liệu UAS sẽ chấp nhận yêu cầu INVITE hay không.
Khi một yêu cầu OPTIONS được nhận ở bên trong một dialog thì một bản tin đáp ứng 200 (OK) cũng được tạo ra giống như khi nó được nhận ở bên ngoài dialog và
OPTIONS trong cách điều khiển của proxy. Đó là trong khi INVITE có thể nhận được nhiều đáp ứng 200 (OK) thì OPTIONS chỉ có nhận được một đáp ứng 200 (OK).
Nếu như đáp ứng của một bản tin OPTIONS được tạo ra bởi một proxy server, thì bản tin đáp ứng 200 (OK) sẽ mang một danh sách cho biết các khả năng của server này, và đáp ứng sẽ không có phần thân bản tin.