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
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
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 (inviter-@example.com), and the SIP version:
INVITE sip:inviter@example.com SIP/2.0
Status–line
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:
<header_name>:<value>
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:
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE
Call–ID
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@10.31.101.30
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@10.31.100.20>t
Content-Length
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
CSeq
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:
CSeq: 1 INVITE
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
From
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@10.31.101.20.):
From: Sender <sip:sender@10.31.101.20>
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
P–Asserted–Iden– 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
- 3325. The header contains a SIP URI and an optional display-name, for example:
P-Asserted-Identity: “Example Person” <sip:10.31.101.50>
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
Record–Route
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 10.31.101.50 is a SIP proxy. The lr parameter indicates the URI of a SIP proxy in Record-Route head- ers.
Record-Route: <sip:10.31.101.50;lr>
Route Forces routing for a request message through one or more SIP proxies. The following example includes two SIP proxies:
Route: <sip:172.20.120.10;lr>, <sip:10.31.101.50;lr>
RSeq
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@10.31.101.30.):
To: Receiver <sip:receiver@10.31.101.30>
Via
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 10.31.101.20 using port 5060.
Via: SIP/2.0/UDP 10.31.101.20:5060
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!
