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.
3) Tiêu đề Server
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.2.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.2.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.
1) 100 Trying
Một số hoạt động không xác định sẽ đ−ợc đại diện cho cuộc gọi nh−ng User không đ−ợc định vị.
UAS sẽ đ−ợc đặt vào một vị trí nơi mà Uset đăng ký gần đây và cố gắng báo chuông cho User.
3) 181 Call Is Being Forwarded ( Cuộc gọi sắp tới )
Một Proxy Server dùng mã trạng thái để thông báo là cuộc gọi sắp tới đích 4) 182 Queued
Phía gọi tạm thời không sẵn sàng, phía bị gọi sẽ quyết định xếp hàng các cuộc gọi thay cho bỏ chúng đi. Khi bị gọi sẵn sàng, nó sẽ trả lại 1 đáp ứng trạng thái cuối cùng thích hợp. Server có thể phát ra một số đáp ứng 182 để cập nhật phía gọi vào trạng thái của hàng đợi gọi.
3.2.2.2 Successful 2xx
Yêu cầu đã đ−ợc thành công ( hoàn thành ) và kết thúc một tìm kiếm
200 OK
Yêu cầu đã đ−ợc thành công. Thông tin đ−ợc trả lại với đáp ứng tuỳ thuộc vào chỉ thị dùng trong yêu cầu. Ví dụ:
• BYE: Cuộc gọi đã kết thúc. Thân bản tin rỗng.
• CANCEL: Tìm kiếm bị huỷ bỏ. Thân bản tin rỗng.
• INVITE: Ng−ời đ−ợc gọi đồng ý tham gia hộ thoại, thân bản tin cho biết khả
năng của ng−ời đ−ợc gọi.
• OPTIONS: Bị gọi đồng ý chia sẻ khả năng, miêu tả trong thân bản tin.
• REGISTER: Việc đăng ký đã thành công. Client xử lý thân bản tin theo Content - Type.
3.2.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.
1) 300 Multiple choices
Địa chỉ trong yêu cầu có thể có vài lựa chọn ứng với các vị trí cụ thể của nó, và User hay UA có thể lựa chọn một địa chỉ −u tiên trong đó để gửi lại yêu cầu. Đáp ứng gồm một thực thể chứa danh sách về đặc điểm nguồn và vị trí mà từ đó User hay UA có thể lựa chọn một vị trí thích hợp nhất để đăng ký. Khuôn dạng của thực thể đ−ợc chỉ định bởi kiểu truyền thông trong tr−ờng tiêu đề Content - Type. Khác với HTTP, đáp
ứng SIP có thể gồm vài Contact hay một danh sách địa chỉ trong tr−ờng Contact. UA có thể dùng các giá trị của tr−ờng Contact để tự động gửi lại hoặc yêu cầu User xác nhận một sự lựa chọn.
2) 301 Moved Permanently
User không dựa trên địa chỉ trong tr−ờng Request - URI và yêu cầu khách hàng để thử lại một địa chỉ mới trong tr−ờng tiêu đề Contract. Phía gọi sẽ cập nhật danh sách cục bộ, danh sách địa chỉ và vị trí User và gửi lại các yêu cầu t−ơng lai đến danh sách địa chỉ.
3) 302 Moved Temporarily
Yêu cầu khách hàng thử lại yêu cầu tại một địa chỉ mới trong tr−ờng Contract. Khoảng thời gian phát lại yêu cầu đ−ợc trình bày trong tiêu đề Expires. Nếu nh− không có thời gian kết thúc rõ ràng thì địa chỉ đó chỉ sử dụng cho cuộc gọi hiện tại và không đ−ợc dùng cho các cuộc gọi tiếp theo.
4) 305 Use Proxy
Yêu cầu truy nhập tài nguyên thông qua Proxy đ−ợc đ−a ra bởi tr−ờng Contact. Tr−ờng Contact chứa URI của Proxy. Đáp ứng này chỉ đ−ợc phát ra bởi UAS.
5) 380 Alternative Server
Cuộc gọi ch−a hoàn thành nh−ng dịch vụ lựa chọn ( thay đổi ) đ−ợc sử dụng. Dịch vụ lựa chọn đ−ợc miêu tả trong phần thân bản tin của đáp ứng.
3.2.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.
1) 400 Bad Request
Yêu cầu không thể hiểu do sai về cú pháp. 2) 401 Unauthoried
Yêu cầu đòi hỏi xác nhận của User 3) 402 Payment Required
Dành tr−ớc cho sử dụng trong t−ơng lai 4) 403 Forbidden
Sử dụng khi Server hiểu yêu cầu nh−ng từ chối thực hiện nó. Yêu cầu không đ−ợc lặp lại khi có đáp ứng này.
5) 404 Not Found
Server có thông tin dứt khoát là User không có mặt trong chỉ định vùng trọng tr−ờng Request - URI. Trạng thái này đ−ợc trả lại khi vùng trọng tr−ờng Request - URI không khớp với vùng nhận đ−ợc bởi yêu cầu.
6) 405 Method Not Allowed
Chỉ thị trong Request - Line không cho phép nhận biết địa chỉ thông qua tr−ờng Request - URI. Đáp ứng này gồm một tr−ờng tiêu đề Allow chứa một danh sách các chỉ thị có hiệu lực cho việc nhận biết các địa chỉ.
7) 406 Not Acceptable
Tài nguyên nhận biết bởi yêu cầu chỉ có thể tạo ra các đáp ứng chứa đặc tính không chấp nhận theo tr−ờng tiêu đề Accept trong yêu cầu.
8) 407 Proxy Athentication Required
Đáp ứng này giống đáp ứng 401 nh−ng nó chỉ ra rằng khách hàng đầu tiên phải xác thực bản thân với Proxy. Proxy phải trả lại một tr−ờng tiêu đề Proxy - Authenticate chứa một yêu cầu ứng dụng cho Proxy trong yêu cầu tài nguyên. Khách hàng có thể lặp lại yêu cầu với một tr−ờng tiên đề Proxy - Authorization thích hợp.
9) 408 Request Timeout
Server không thể cung cấp một đáp ứng trong vòng thời gian cho phép. Trong một tiêu đề Expires, khách hàng có thể lặp lại yêu cầu mà không cần thay đổi tại các thời điểm sau.
10) 409 Conflict
Yêu cầu không đ−ợc hoàn thành vì sự xung đột tài nguyên. Đáp ứng này đ−ợc trả lại nếu nh− thông số hoạt động trong yêu cầu REGISTER mâu thuẫn với đăng ký hiện có. 11) 410 Gone
Yêu cầu tài nguyên không còn sẵn sàng tại Server và không có địa chỉ tới nào đ−ợc nhận biết.
12) 411 Length Required
Server từ chối yêu cầu mà không định nghĩa Content - Length. Khách hàng có thể lặp lại yêu cầu này nếu nó muốn bổ sung một tr−ờng tiêu đề Content - Length chứa độ dài của thân bản tin trong bản tin yêu cầu.
13) 413 Request Entity Too Large
Server từ chối xử lý một yêu cầu bởi vì yêu cầu quá dài so với năng lực xử lý của Server. Server có thể huỷ bỏ kết nối để ngăn khách hàng tiếp tục yêu cầu. Nếu đó chỉ là trạng thái tạm thời thì Server sẽ phát ra tr−ờng Rettry - After để thông báo sau một thời gian khách hàng có thể thử lại.
14) 414 Request - URI Too Long
Server từ chối yêu cầu vì tr−ờng Request - URI quá dài, Server không thể hiểu đ−ợc.
15) 415 Unsupported Media Type
Server từ chối phục vụ yêu cầu vì thân của yêu cầu không thuộc một khuôn dạng đ−ợc hỗ trợ bởi Server. Server có thể trả lại một danh sách các dạng có thể chấp nhận đ−ợc sử dụng các tr−ờng tiêu đề Accept, Accept - Encoding, Accept - Language.
16) 420 Bad Extension
Server không hiểu chỉ thị mở rộng giao thức trong tr−ờng tiêu đề Required hay Proxy - Require.
17) 480 Temporarily Unavaiable
Hệ thống đầu cuối bị gọi đã liên lạc thành công nh−ng phía bị gọi lại không sẵn sàng. Đáp ứng này chỉ ra một thời gian tốt hơn để cho cuộc gọi trong tiêu đề Retry - After. Reson Phrase có thể chỉ ra các nguyên nhân chính xác tại sao phía bị gọi lại không sẵn sàng. Giá trị này có thể đ−ợc thiết lập bởi UA. Đáp ứng này đ−ợc trả lại bởi một Redirect Server nhận diện đ−ợc User thông qua Request - URI nh−ng không có đ−ợc vị trí hợp lý hiện nay của User đó.
18) 481 Call Leg /Transaction does not Exist
Đáp ứng này đ−ợc trả lại khi có ba điều kiện sau:
• Server nhận đ−ợc một yêu cầu BYE mà không phù hợp với Call - leg hiện tại.
• Server nhận đ−ợc một yêu cầu CANCEL không phù hợp với các giao dịch hiện tại.
• Server nhận đ−ợc INVITE với một thẻ To không phù hợp với giá trị thẻ nội bộ. 19) 482 Loop Deteccted
Server nhận đ−ợc một yêu cầu với tr−ờng Via chứa bản thân nó. 20) 483 Too many hops
Server nhận đ−ợc một yêu cầu chứa nhiều Via entries ( Hops ) hơn sự cho phép của tr−ờng tiêu đề Max – Forwards.
21) 484 Address Incomplete
Server nhận đ−ợc một yêu cầu với địa chỉ đến To hoặc Request - URI không đầy đủ. Các thông tin bổ xung có thể đ−ợc hỗ trợ.
22) 485 Ambiguous
Địa chỉ ng−ời đ−ợc gọi cung cấp bởi yêu cầu là khó hiểu ( mơ hồ ). Đáp ứng này chứa một danh sách các địa chỉ rõ ràng có thể trong tr−ờng tiêu đề Contract. Nó đ−ợc dùng để trả lời trạng thái 404 hoặc chặn danh sách lựa chọn có thể nếu nh− địa chỉ trong yêu cầu là khó hiểu.
23) 486 Busy Here
Hệ thống đầu cuối bị gọi đã liên lạc thành công nh−ng phía gọi lại không thể tham gia thêm vào cuộc gọi. Đáp ứng này chỉ thị một thời gian tốt hơn cho cuộc gọi trong tr−ờng Retry - After.
3.2.2.5 Server Failure 5xx
Đáp ứng 5xx là đáp ứng lỗi khi chính Server bị lỗi. 1) 500 Server Internal Error
Server gặp phải một tình huống bất ngờ ngăn cản nó hoàn thành yêu cầu. Client có thể hiển thị trạng thái lỗi cụ thể và có thể thử lại yêu cầu sau vài giây.
2) 501 Not Implemented
Server không thể hỗ trợ yêu cầu chức năng để hoàn thành yêu cầu. Đây là một đáp ứng thích hợp khi Server không nhận thức rõ về chỉ thị yêu cầu và khả năng hỗ trợ của nó cho các User.
3) 502 Bad Gateway
Server khi hoạt động nh− một Gateway hoặc Proxy, nhận một đáp ứng không hợp lệ từ dowstream Server, nó sẽ cố gắng hoàn thành yêu cầu đó.
4) 503 Service Unavaiable
Server không có khả năng xử lý yêu cầu do sự quá tải tạm thời hay do bảo d−ỡng. 5) 504 Gateway Time - out
Server khi hoạt động nh− một cổng không thể nhận một đáp ứng kịp thời từ Server khác. Nó sẽ truy xuất vào để cố gắng hoàn thành yêu cầu.
Server không hỗ trợ cho version SIP dùng trong bản tin yêu cầu. Đáp ứng này chứa một thực thể miêu tả tại sao không hỗ trợ Version đó và nêu ra các giao thức khác đ−ợc hỗ trợ bởi Server.
3.2.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. 1) 600 Busy Everywhere
Hệ thống đầu cuối bị gọi đã liên lạc thành công nh−ng phía bị gọi đang bận và đang muốn thực hiện cuộc gọi tại thời điểm này. Đáp ứng này chỉ ra một thời gian tốt hơn để tiến hành cuộc gọi trong tiêu đề Retry - After. Đáp ứng này chỉ trả lại khi biết rằng không có điểm đầu cuối nào sẽ trả lời sẽ trả lại yêu cầu.
2) 603 Decline
Máy bị gọi đã liên lạc thành công nh−ng User dứt khoát không muốn hoặc không thể tham gia cuộc gọi. Đáp ứng này chỉ ra một thời gian tốt hơn để tiến hành cuộc gọi trong tiêu đề Retry - A fter.
3) 604 Dose not exist anywhere
Server có thông tin chính xác là User đ−ợc chỉ ra trong tr−ờng tiêu đề yêu cầu To không tồn tại tại bất cứ nơi nào. Việc tìm kiếm User đó ở một nơi nào đó không mang lại kết quả.
4) 606 not Acceptable
UA liên lạc thành công nh−ng một số mặt của miêu tả phiên nh− các yêu cầu về ph−ơng tiện, băng thông hay kiểu địa chỉ không đ−ợc chấp nhận. Đáp ứng 606 có nghĩa là User muốn giao tiếp nh−ng không đ−ợc chấp nhận miêu tả phiên thích hợp. Đáp ứng này gồm một danh sách các nguyên nhân tại sao mô tả phiên không đ−ợc hỗ trợ chứa trong tr−ờng tiêu đề Warning.
3.3 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.3.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