SIP messages and media protocols
This section provides an overview of SIP messages and how they communicate information about SIP sessions and how SDP, RTP, and RTCP fits in with SIP communications.
SIP uses clear text messages to start, maintain, and end media sessions between SIP user agent clients (UACs) and user agent servers (UASs). These messages form a SIP dialog. A typical SIP dialog begins with an INVITE request message sent from a UAC to another UAC or to a UAS. The first INVITE request message attempts to start a SIP call and includes information about the sending UAC and the receiving UAC as well as information about the communication session.
If only two UACs are involved as shown below, the receiving UAC (Phone B) responds with a 180 Ringing and then a 200 OK SIP response message that informs Phone A that Phone B received and accepted the request. Phone A then sends an ACK message to notify Phone B that the SIP response was received. Phone A and Phone B can then participate in the RTP media session set up by the SIP messages.
When the phone call is complete, one of the UACs (in the example Phone B) hangs up sending a BYE request message to Phone A. Phone A then sends a 200 OK response to Phone B acknowledging that the session has ended.
Basic SIP dialog between two UACs
| SIP Phone A
(Sending UAC PhoneA@10.31.101.20) |
SIP Phone B
(Receiving UAC PhoneB@10.31.101.30) |
- INVITE (SIP request message to invite SIP Phone B to start a SIP session).
- 180 Ringing (SIP ringing response to the INVITE request).
- 200 OK (SIP response to the INVITE request to inform SIP Phone A
that the request is accepted).
- ACK (SIP request message to confirm that
SIP Phone A received the response from SIP Phone B).
- RTP Media session between Phone Aand Phone B.
- BYE (SIP request message from SIP Phone B to end the SIP session).
- 200 OK (SIP response to the BYE request to end the SIP session).
If a UAS in the form of a SIP proxy server is involved, similar messages are sent and received, but the proxy server participates as an intermediary in the initial call setup. In the example below the SIP proxy server receives the INVITE request from Phone A and forwards it to Phone B. The proxy server then sends a 100 Trying response to Phone A. Phone B receives the INVITE request and responds with a 180 Ringing and then a 200 OK SIP response message. These messages are received by the proxy server and forwarded to Phone A to notify Phone A that Phone B received and accepted the request. Phone A then sends an ACK message to notify Phone B that the SIP response was received. This response is received by the proxy server and forwarded to Phone B. Phone A and Phone B can then participate in the media session independently of the proxy server.
When the phone call is complete Phone B hangs up sending a BYE request message to Phone A. Phone A then sends a 200 OK response to Phone B acknowledging that the session has ended.
Basic SIP dialog between UACs with a SIP proxy server UAS
- INVITE (Forwarded by the UAS to Phone B.)
- 180 Ringing (SIP ringing response to the INVITE request.)
- 200 OK (SIP response to the INVITE request to inform Phone A that the request is accepted.)
- BYE (SIP request message from Phone B to end the SIP session.)
The SIP messages include SIP headers that contain names and addresses of Phone A, Phone B and the proxy server. This addressing information is used by the UACs and the proxy server during the call set up.
The SIP message body includes Session Description Protocol (SDP) statements that Phone A and Phone B use to establish the media session. The SDP statements specify the type of media stream to use for the session (for example, audio for SIP phone calls) and the protocol to use for the media stream (usually the Real Time Protocol (RTP) media streaming protocol).
Hardware accelerated RTP processing
Phone A includes the media session settings that it would like to use for the session in the INVITE message. Phone B includes its response to these media settings in the 200 OK response. Phone A’s ACK response confirms the settings that Phone A and Phone B then use for the media session.
Hardware accelerated RTP processing
FortiGates can offload RTP packet processing to network processor (NP) interfaces. This acceleration greatly enhances the overall throughput and resulting in near speed RTP performance.
SIP request messages
SIP sessions always start with a SIP request message (also just called a SIP request). SIP request messages also establish, maintain, and terminate SIP communication sessions. The following table lists some common SIP request message types.
Common SIP request message types
| Message Type | Description |
| INVITE | A client sends an INVITE request to invite another client to participate in a multimedia session. The INVITE request body usually contains the description of the session. |
| ACK | The originator of an INVITE message sends an ACK request to confirm that the final response to an INVITE request was received. If the INVITE request did not contain the session description, it must be included in the ACK request. |
| PRACK | In some cases, SIP uses provisional response messages to report on the progress of the response to a SIP request message. The provisional response messages are sent before the final SIP response message. Similar to an ACK request message, a PRACK request message is sent to acknowledge that a provisional response message has been received. |
| OPTIONS | The UA uses OPTIONS messages to get information about the capabilities of a SIP proxy. The SIP proxy server replies with a description of the SIP methods, session description protocols, and message encoding that are supported. |
| BYE | A client sends a BYE request to end a session. A BYE request from either end of the SIP session terminates the session. |
| CANCEL | A client sends a CANCEL request to cancel a previous INVITE request. A CANCEL request has no effect if the SIP server processing the INVITE sends a final response to the INVITE before receiving the CANCEL. |
response messages
| Message Type | Description |
| REGISTER | A client sends a REGISTER request to a SIP registrar server with information about the current location (IP address and so on) of the client. A SIP registrar server saves the information it receives in REGISTER requests and makes this information available to any SIP client or server attempting to locate the client. |
| Info | For distributing mid-session signaling information along the signaling path for a SIP call. I |
| Subscribe | For requesting the current state and state updates of a remote node. |
| Notify | Informs clients and servers of changes in state in the SIP network. |
| Refer | Refers the recipient (identified by the Request-URI) to a third party according to the contact information in the request. |
| Update | Opens a pinhole for new or updated SDP information. |
| Response codes
(1xx, 202, 2xx, 3xx, 4xx, 5xx, 6xx) |
Indicates the status of a transaction. For example: 200 OK, 202 Accepted, or 400 Bad Request. |
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 acknowledgment.
If the SIP implementation uses Provisional Response Acknowledgment (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
- Ringing
- Call is being forwarded
- Queued
SIP response messages
- 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:
- Multiple choices
- Moved permanently
- 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
- Temporarily not available
- Call leg/transaction does not exist
- 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:
- Server internal error
- Not implemented
- Bad gateway
502 Service unavailable
- Gateway time-out
- SIP version not supported
message start line
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
- Decline
- 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 requestline 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 version, 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 headers
| SIP Header | Description |
| Allow | Lists the set of SIP methods supported by the UA generating the message. All methods, 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 |
| 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 includes the request name found in the request message requestline. 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> |
headers
| SIP Header | Description |
| 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-AssertedIdentity | 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 |
| 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 headers.
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 following example Via field indicates to use SIP version 2, UDP for media communications, and to send the response to 10.31.101.20 using port 5060.
Via: SIP/2.0/UDP 10.31.101.20:5060 |
30
The SIP message body and SDP session profiles
The SIP message body and SDP session profiles
The SIP message body describes the session to be initiated. For example, in a SIP phone call the body usually includes audio codec types, sampling rates, server IP addresses and so on. For other types of SIP session the body could contain text or binary data of any type which relates in some way to the session. The message body is included in request and response messages.
Two possible SIP message body types:
l Session Description Protocol (SDP), most commonly used for SIP VoIP. l Multipurpose Internet Mail Extensions (MIME)
SDP is most often used for VoIP and FortiGates support SDP content in SIP message bodies. SDP is a textbased protocol used by SIP to control media sessions. SDP does not deliver media but provides a session profile that contains media details, transport addresses, parameter negotiation, and other session description metadata for the participants in a media session. The participants use the information in the session profile to negotiate how to communicate and to manage the media session. SDP is described by RFC 4566.
An SDP session profile always contains session information and may contain media information. Session information appears at the start of the session profile and media information (using the m= attribute) follows.
SDP session profiles can include the attributes listed in the following table.
SDP session profile attributes
| Attribute | Description |
| a= | Attributes to extend SDP in the form a=<attribute> or a=<attribute>:<value>. |
| b= | Contains information about the bandwidth required for the session or media in the form b=<bandwidth_type>:<bandwidth>. |
| c= | Connection data about the session including the network type (usually IN for Internet), address type (IPv4 or IPv6), the connection source address, and other optional information. For example:
c=IN IPv4 10.31.101.20 |
| i= | A text string that contains information about the session. For example:
i=A audio presentation about SIP |
| k= | Can be used to convey encryption keys over a secure and trusted channel. For example:
k=clear:444gdduudjffdee |
The SIP message body and SDP session profiles
| Attribute | Description |
| m= | Media information, consisting of one or more lines all starting with m= and containing details about the media including the media type, the destination port or ports used by the media, the protocol used by the media, and a media format description.
m=audio 49170 RTP 0 3 m-video 3345/2 udp 34 m-video 2910/2 RTP/AVP 3 56 Multiple media lines are needed if SIP is managing multiple types of media in one session (for example, separate audio and video streams). Multiple ports for a media stream are indicated using a slash. 3345/2 udp means UDP ports 3345 and 3346. Usually RTP uses even-numbered ports for data with the corresponding one-higher odd ports used for the RTCP session belonging to the RTP session. So 2910/2 RTP/AVP means ports 2910 and 2912 are used for RTP and 2911 and 2913 are used for RTCP. Media types include udp for an unspecified protocol that uses UDP, RTP or RTP/AVP for standard RTP and RTP/SAVP for secure RTP. |
| o= | The sender’s username, a session identifier, a session version number, the network type (usually IN for Internet), the address type (for example, IPv4 or IPv6), and the sending device’s IP address. The o= field becomes a universal identifier for this version of this session description. For example:
o=PhoneA 5462346 332134 IN IP4 10.31.101.20 |
| r= | Repeat times for a session. Used if a session will be repeated at one or more timed intervals. Not normally used for VoIP calls. The times can be in different formats. For example:
r=7d 1h 0 25h r=604800 3600 0 90000 |
| s= | Any text that describes the session or s= followed by a space. For example:
s=Call from inviter |
| t= | The start and stop time of the session. Sessions with no time restrictions (most VoIP calls) have a start and stop time of 0.
t=0 0 |
| v= | SDP protocol version. The current SDP version is 0 so the v= field is always:
v=0 |
| z= | Time zone adjustments. Used for scheduling repeated sessions that span the time between changing from standard to daylight savings time.
z=2882844526 -1h 2898848070 0 |
Example SIP messages
The following example SIP INVITE request message was sent by PhoneA to PhoneB. The first nine lines are the SIP headers. The SDP profile starts with v=0 and the media part of the session profile is the last line, starting with m=.
INVITE sip:PhoneB@172.20.120.30 SIP/2.0
Via: SIP/2.0/UDP 10.31.101.50:5060
From: PhoneA <sip:PhoneA@10.31.101.20>
To: PhoneB <sip:PhoneB@172.20.120.30>
Call-ID: 314159@10.31.101.20
CSeq: 1 INVITE
Contact: sip:PhoneA@10.31.101.20
Content-Type: application/sdp
Content-Length: 124 v=0
o=PhoneA 5462346 332134 IN IP4 10.31.101.20 s=Let’s Talk t=0 0
c=IN IP4 10.31.101.20 m=audio 49170 RTP 0 3
The following example shows a possible 200 OK SIP response message in response to the previous INVITE request message. The response includes 200 OK which indicates success, followed by an echo of the original SIP INVITE request followed by PhoneB’s SDP profile.
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.31.101.50:5060
From: PhoneA <sip:PhoneA@10.31.101.20>
To: PhoneB <sip:PhoneB@172.20.120.30>
Call-ID: 314159@10.31.101.20
CSeq: 1 INVITE
Contact: sip:PhoneB@10.31.101.30
Content-Type: application/sdp
Content-Length: 107 v=0 o=PhoneB 124333 67895 IN IP4 172.20.120.30 s=Hello! t=0 0
c=IN IP4 172.20.120.30 m=audio 3456 RTP 0
SIP can support multiple media streams for a single SIP session. Each media steam will have its own c= and m= lines in the body of the message. For example, the following message includes three media streams:
INVITE sip:PhoneB@172.20.120.30 SIP/2.0
Via: SIP/2.0/UDP 10.31.101.20:5060
From: PhoneA <sip:PhoneA@10.31.101.20>
To: PhoneB <sip:PhoneB@172.20.120.30>
Call-ID: 314159@10.31.101.20
CSeq: 1 INVITE
Contact: sip:PhoneA@10.31.101.20
Content-Type: application/sdp
Content-Length: 124 v=0
o=PhoneA 5462346 332134 IN IP4 10.31.101.20 s=Let’s Talk
Example SIP messages
t=0 0 c=IN IP4 10.31.101.20 m=audio 49170 RTP 0 3 c=IN IP4 10.31.101.20 m=audio 49172 RTP 0 3 c=IN IP4 10.31.101.20 m=audio 49174 RTP 0 3