SIP response messages

SIP response messages

SIP response messages (often just called SIP responses) provide status information in response to SIP request messages. All SIP response messages include a response code and a reason phrase. There are five SIP response message classes. They are described below.

There are also two types of SIP response messages, provisional and final. Final response messages convey the result of the request processing, and are sent reliably. Provisional responses provide information on the progress of the request processing, but may not be sent reliably. Provisional response messages start with 1xx and are also called informational response messages.


Informational (or provisional)

Informational or provisional responses indicate that a request message was received and imply that the endpoint is going to process the request. Information messages may not be sent reliably and may not require an acknowledgement.

If the SIP implementation uses Provisional Response Acknowledgement (PRACK) (RFC 3262) then informational or provisional messages are sent reliably and require a PRACK message to acknowledge that they have been received.

Informational responses can contain the following reason codes and reason phrases:

100 Trying

180 Ringing

181 Call is being forwarded

182 Queued

183 Session progress



Success responses indicate that a request message was received, understood, and accepted. Success responses can contain the following reason codes and reason phrases:

200 OK

202 Accepted



Redirection responses indicate that more information is required for the endpoint to respond to a request message. Redirection responses can contain the following reason codes and reason phrases:

300 Multiple choices

301 Moved permanently

302 Moved temporarily

305 Use proxy

380 Alternative service


Client error

Client error responses indicate that a request message was received by a server that contains syntax that the server cannot understand (i.e. contains a syntax error) or cannot comply with. Client error responses include the following reason codes and reason phrases:

400 Bad request              401 Unauthorized

402 Payment required         403 Forbidden

404 Not found                405 Method not allowed

406 Not acceptable           407 Proxy authentication required

408 Request time-out         409 Conflict

410 Gone                     411 Length required

413 Request entity too large 414 Request-URL too large

415 Unsupported media type   420 Bad extension

480 Temporarily not available

481 Call leg/transaction does not exist

482 Loop detected

484 Address incomplete       483 Too many hops

486 Busy here                485 Ambiguous

488 Not acceptable here      487 Request canceled


Server error

Server error responses indicate that a server was unable to respond to a valid request message. Server error responses include the following reason codes and reason phrases:

500 Server internal error

501 Not implemented

502 Bad gateway

502 Service unavailable

504 Gateway time-out

505 SIP version not supported


Global failure

Global failure responses indicate that there are no servers available that can respond to a request message. Global failure responses include the following reason codes and reason phrases:

600 Busy everywhere

603 Decline

604 Does not exist anywhere

606 Not acceptable


SIP message start line

The first line in a SIP message is called the start line. The start line in a request message is called the request- line and the start line in a response message is called the status-line.


Request-line             The first line of a SIP request message. The request-line includes the SIP message type, the SIP protocol version, and a Request URI that indicates the user or service to which this request is being addressed. The following example request-line specifies the INVITE message type, the address of the sender of the message (, and the SIP version:




The first line of a SIP response message. The status-line includes the SIP protocol ver- sion, the response code, and the reason phrase. The example status-line includes the SIP version, the response code (200) and the reason phrase (OK).

SIP/2.0 200 OK


SIP headers

Following the start line, SIP messages contain SIP headers (also called SIP fields) that convey message attributes and to modify message meaning. SIP headers are similar to HTTP header fields and always have the following format:


SIP messages can include the SIP headers listed in the following table:


SIP headers

SIP Header              Description

Allow                         Lists the set of SIP methods supported by the UA generating the message. All meth- ods, including ACK and CANCEL, understood by the UA MUST be included in the list of methods in the Allow header field, when present. For example:




A globally unique identifier for the call, generated by the combination of a random string and the sender’s host name or IP address. The combination of the To, From, and Call-ID headers completely defines a peer-to-peer SIP relationship between the sender and the receiver. This relationship is called a SIP dialog.

Call-ID: ddeg45e793@


Contact                     Included in SIP request messages, the Contact header contains the SIP URI of the sender of the SIP request message. The receiver uses this URI to contact the sender. For example:

Contact: Sender <sip:sender@>t



The number of bytes in the message body (in bytes).

Content-Length: 126


SIP Header              Description

Content-Type           In addition to SIP headers, SIP messages include a message body that contains information about the content or communication being managed by the SIP session. The Content-Type header specifies what the content of the SIP message is. For example, if you are using SIP with SDP, the content of the SIP message is SDP code.

Content-Type: application/sdp



The command sequence header contains a sequence integer that is increased for each new SIP request message (but is not incremented in the response message). This header also incudes the request name found in the request message request- line. For example:



Expires                     Gives the relative time after which the message (or content) expires. The actual time and how the header is used depends on the SIP method. For example:

Expires: 5



Identifies the sender of the message. Responses to a message are sent to the address of the sender. The following example includes the sender’s name (Sender) and the sender’s SIP address (sender@

From: Sender <sip:sender@>


Max-forwards           An integer in the range 0-255 that limits the number of proxies or gateways that can forward the request message to the next downstream server. Also called the number of hops, this value is decreased every time the message is forwarded. This can also be useful when the client is attempting to trace a request chain that appears to be failing or looping in mid-chain.

For example: Max-Forwards: 30


PAssertedIden– tity

The P-Asserted-Identity header is used among trusted SIP entities to carry the identity of the user sending a SIP message as it was verified by authentication. See RFC

  1. 3325. The header contains a SIP URI and an optional display-name, for example:

P-Asserted-Identity: “Example Person” <sip:>


RAck                         Sent in a PRACK request to support reliability of information or provisional response messages. It contains two numbers and a method tag. For example:

RAck: 776656 1 INVITE


SIP Header              Description



Inserted into request messages by a SIP proxy to force future requests to be routed through the proxy. In the following example, the host at IP address is a SIP proxy. The lr parameter indicates the URI of a SIP proxy in Record-Route head- ers.

Record-Route: <sip:;lr>


Route                        Forces routing for a request message through one or more SIP proxies. The following example includes two SIP proxies:

Route: <sip:;lr>, <sip:;lr>



The RSeq header is used in information or provisional response messages to support reliability of informational response messages. The header contains a single numeric value. For example:

RSeq: 33456


To                              Identifies the receiver of the message. The address in this field is used to send the message to the receiver. The following example includes the receiver’s name (Receiver) and the receiver’s SIP address (receiver@

To: Receiver <sip:receiver@>



Indicates the SIP version and protocol to be used for the SIP session and the address to which to send the response to the message that contains the Via field. The fol- lowing example Via field indicates to use SIP version 2, UDP for media com- munications, and to send the response to using port 5060.

Via: SIP/2.0/UDP

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

This entry was posted in FortiGate, FortiOS, FortiOS 5.4 Handbook on by .

About Mike

Michael Pruett, CISSP has a wide range of cyber-security and network engineering expertise. The plethora of vendors that resell hardware but have zero engineering knowledge resulting in the wrong hardware or configuration being deployed is a major pet peeve of Michael's. This site was started in an effort to spread information while providing the option of quality consulting services at a much lower price than Fortinet Professional Services. Owns PacketLlama.Com (Fortinet Hardware Sales) and Office Of The CISO, LLC (Cybersecurity consulting firm).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.