Está en la página 1de 7

SIP messages[edit]

SIP is a text-based protocol with syntax similar to that of HTTP. There are two different
types of SIP messages: requests and responses. The first line of a request has amethod,
defining the nature of the request, and a Request-URI, indicating where the request should be
sent.
[12]
The first line of a response has a response code.
For SIP requests, RFC 3261 defines the following methods:
[13]

Main article: List of SIP request methods
REGISTER: Used by a UA to indicate its current IP address and the URLs for which
it would like to receive calls.
INVITE: Used to establish a media session between user agents.
ACK: Confirms reliable message exchanges.
CANCEL: Terminates a pending request.
BYE: Terminates a session between two users in a conference.
OPTIONS: Requests information about the capabilities of a caller, without setting up
a call.
A new method has been introduced in SIP in RFC 3262:
[14]

PRACK (Provisional Response Acknowledgement): PRACK improves network
reliability by adding an acknowledgement system to the provisional Responses
(1xx). PRACK is sent in response to provisional response (1xx).
The SIP response types defined in RFC 3261 fall in one of the following categories:
[15]

Main article: List of SIP response codes
Provisional (1xx): Request received and being processed.
Success (2xx): The action was successfully received, understood, and accepted.
Redirection (3xx): Further action needs to be taken (typically by sender) to complete
the request.
Client Error (4xx): The request contains bad syntax or cannot be fulfilled at the
server.
Server Error (5xx): The server failed to fulfill an apparently valid request.
Global Failure (6xx): The request cannot be fulfilled at any server.
.

SIP Requests
We have described how an INVITE request looks like and said that the
request is used to invite a callee to a session. Other important requests
are:
ACK This message acknowledges receipt of a final response to
INVITE. Establishing of a session utilizes 3-way hand-shaking due to
asymmetric nature of the invitation. It may take a while before the
callee accepts or declines the call so the callee's user agent
periodically retransmits a positive final response until it receives an
ACK (which indicates that the caller is still there and ready to
communicate).
BYE Bye messages are used to tear down multimedia sessions. A
party wishing to tear down a session sends a BYE to the other party.
CANCEL Cancel is used to cancel not yet fully established session. It
is used when the callee hasn't replied with a final response yet but
the caller wants to abort the call (typically when a callee doesn't
respond for some time).
REGISTER Purpose of REGISTER request is to let registrar know of
current user's location. Information about current IP address and port
on which a user can be reached is carried in REGISTER messages.
Registrar extracts this information and puts it into a location
database. The database can be later used by SIP proxy servers to
route calls to the user. Registrations are time-limited and need to be
periodically refreshed.
The listed requests usually have no message body because it is not
needed in most situations (but can have one). In addition to that many
other request types have been defined but their description is out of the
scope of this document.

the previous SIP session example we have seen that requests are sent by
clients to servers. We will now discuss what that request actually contains.
The following is the format of INVITE request as sent by user1.
INVITE sip:user2@server2.com SIP/2.0
Via: SIP/2.0/UDP pc33.server1.com;branch=z9hG4bK776asdhds Max-Forwards: 70
To: user2 <sip:user2@server2.com>
From: user1 <sip:user1@server1.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.server1.com
CSeq: 314159 INVITE
Contact: <sip:user1@pc33.server1.com>
Content-Type: application/sdp
Content-Length: 142

---- User1 Message Body Not Shown ----
The first line of the text-encoded message is called Request-Line. It
identifies that the message is a request.
Request-Line
Method SP Request-URI SP SIP-Version CRLF
[SP = single-space & CRLF=Carriage Return + Line Feed (i.e. the character inserted when you press
the "Enter" or "Return" key of your computer)]
Here method is INVITE, request-uri is "user2@server2.com" and SIP
version is 2.
The following lines are a set of header fields.
Via:
It contains the local address of user1 i.e. pc33.server1.com where it
is expecting the responses to come.
Max-Forward:
It is used to limit the number of hops that this request may take
before reaching the recipient. It is decreased by one at each hop. It is
necessary to prevent the request from traveling forever in case it is
trapped in a loop.
To:
It contains a display name "user2" and a SIP or SIPS URI
<user2@server2.com>
From:
It also contains a display name "user1" and a SIP or SIPS URI
<user1@server1.com>. It also contains a tag which is a pseudo-
random sequence inserted by the SIP application. It works as an
identifier of the caller in the dialog.
Call-ID:
It is a globally unique identifier of the call generated as the
combination of a pseudo-random string and the softphone's IP
address.
The Call-ID is unique for a call. A call may contain several dialogs. Each dialog is
uniquely identified by a combination of From, To and Call-ID. If you are in
confusion click here.
CSeq:
It contains an integer and a method name. When a transaction starts,
the first message is given a random CSeq. After that it is incremented
by one with each new message. It is used to detect non-delivery of a
message or out-of-order delivery of messages.
Contact:
It contains a SIP or SIPS URI that is a direct route to user1. It
contains a username and a fully qualified domain name(FQDN). It
may also have an IP address.
Via field is used to send the response to the request. Contact field is used to send
future requests. That is why the 200 OK response from user2 goes to user1 through
proxies. But when user2 generates a BYE request (a new request and not a
response to INVITE), it goes directly to user1 bypassing the proxies.
Content-Type:
It contains a description of the message body (not shown).
Content-Length:
It is an octet (byte) count of the message body.
The header may contain other header fields also. However those fields are
optional. Please note that the body of the message is not shown here. The
body is used to convey information about the media session written
in Session Description Protocol (SDP). You may continue your journey through
SIP without worrying about SDP right now. However it doesn't hurt to take a
peep.
Your SIP request is waiting to get a SIP response message.




The reply code is an integer number from 100 to 699 and indicates type of
the response. There are 6 classes of responses:
1xx are provisional responses. A provisional response is response
that tells to its recipient that the associated request was received but
result of the processing is not known yet. Provisional responses are
sent only when the processing doesn't finish immediately. The
sender must stop retransmitting the request upon reception of a
provisional response.
Typically proxy servers send responses with code 100 when they
start processing an INVITE and user agents send responses with
code 180 (Ringing) which means that the callee's phone is ringing.
2xx responses are positive final responses. A final response is the
ultimate response that the originator of the request will ever receive.
Therefore final responses express result of the processing of the
associated request. Final responses also terminate transactions
i
.
Responses with code from 200 to 299 are positive responses that
means that the request was processed successfully and accepted.
For instance a 200 OK response is sent when a user accepts
invitation to a session (INVITE request).
A UAC
i
may receive several 200 messages to a single INVITE
request. This is because a forking
i
proxy (described later) can
fork
i
the request so it will reach several UAS
i
and each of them will
accept the invitation. In this case each response is distinguished by
the tag parameter in To header field. Each response represents a
distinct dialog
i
with unambiguous dialog identifier.
3xx responses are used to redirect a caller. A redirection response
gives information about the user's new location or an alternative
service that the caller might use to satisfy the call. Redirection
responses are usually sent by proxy servers. When a proxy receives
a request and doesn't want or can't process it for any reason, it will
send a redirection response to the caller and put another location into
the response which the caller might want to
try. It can be the location of another proxy or the current location of
the callee (from the location database created by a registrar). The
caller is then supposed to re-send the request to the new location.
3xx responses are final.
4xx are negative final responses. a 4xx response means that the
problem is on the sender's side. The request couldn't be processed
because it contains bad syntax or cannot be fulfilled at that server.
5xx means that the problem is on server's side. The request is
apparently valid but the server failed to fulfill it. Clients should usually
retry the request later.
6xx reply code means that the request cannot be fulfilled at any
server. This response is usually sent by a server that has definitive
information about a particular user. User agents usually send a 603
Decline response when the user doesn't want to participate in
the session.
In addition to the response class the first line also contains reason phrase.
The code number is intended to be processed by machines. It is not very
human-friendly but it is very easy to parse and understand by machines.
The reason phrase usually contains a human-readable message describing
the result of the processing. A user agent should render the reason phrase
to the user.
The request to which a particular response belongs is identified using the
CSeq header field. In addition to the sequence number this header field
also contains method of corresponding request. In our example it was
REGISTER request.


SIP/2.0 200 OK
Via: SIP/2.0/UDP site4.server2.com;branch=z9hG4bKnashds8;received=192.0.2.3
Via: SIP/2.0/UDP site3.server1.com;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via: SIP/2.0/UDP pc33.server1.com;branch=z9hG4bK776asdhds;received=192.0.2.1
To: user2 <sip:user2@server2.com>;tag=a6c85cf
From: user1 <sip:user1@server1.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.server1.com
CSeq: 314159 INVITE
Contact: <sip:user2@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131

---- User2 Message Body Not Shown ----
Status Line
The first line in a response is called Status line.
SIP-Version SP Status-Code SP Reason-Phrase CRLF
[SP = single-space & CRLF=Carriage Return + Line Feed (i.e. the character inserted
when you press the "Enter" or "Return" key of your computer)]
Here SIP version is 2, Status-Code is 200 and Reason Phrase is OK.
The header fields that follow the status line are similar to those in a request.
I will just mention the differences
Via:
There are more than one via field. This is because each element
through which the INVITE request has passed has added its identity
in the Via field. Three Via fields are added by softphone of user1,
server1 the first proxy and server2 the second proxy. The response
retraces the path of INVITE using the Via fields. On its way back,
each element removes the corresponding Via field before forwarding
it back to the caller.
To:
Note that the To field now contains a tag. This tag is used to
represent the callee in a dialog.
Contact:
It contains the exact address of user2. So user1 doesn't need to use
the proxy servers to find user2 in the future.
It is a 2xx response. However responses can be differnet depending on
particular situations. Learn about the different types of SIP responses.