The very first request issued by a client is likely to be REGISTER, because this is the
request that provides the server with an address at which the user can be reached for SIP
sessions. The REGISTER request is somewhat similar to the Registration Request
between a terminal and a gatekeeper in H.323.
• In this scenario, Collins has logged in to host station1.work.com. This causes a
REGISTER request to be sent to the local registrar.
• Note the format of the Via: header and in particular the fact that it specifies the
transport being used. The default is the User Datagram Protocol (UDP).
• Note also that the Via: header contains a branch parameter which will discusses in
• The From: header field indicates the address of the individual who has initiated the
• The To: header field indicates the “address of record” of the user being registered
and is the address that the registrar will store for that user. In other words, this is
the address at which the user wants to be contactable.
• The From: and To: fields will be identical if a user is registering himself. The two
fields need not be identical, however, which means that one individual can
perform a registration on behalf of another.
• Note that the From: field in our example contains a tag parameter, which is a
pseudoran- dom value generated at the sender of the request and is used for identifica- tion purposes.
• The Call-ID: header field is set by the originating client. In order to avoid the
possibility that different clients might choose the same Call-ID, the recommended
syntax for the Call-ID is [email protected]
, thereby making the Call-ID host specific.
• In Figure 5-8, Collins has inserted a Contact: header field that indicates that future
SIP messages should be routed to sip:[email protected]
.work.com. In other words,
messages that are addressed to sip:Collins @work.com should be forwarded to
• The REGISTER request does not contain a message body, since the mes- sage is
not used to describe a session of any kind. Therefore, the Content- Length: field is
set to 0
• The response to the REGISTER request is positive, as indicted by the 200 (OK) in
the response line.
• Note that the content of the Via: header field is copied from request to response.
The content of the CSeq: (or command sequence) header field is also copied from
request to response. The CSeq: header field indicates the method used in the
request and an integer num- ber.
• the use of the CSeq is very important in other requests where dif- ferent requests
can be issued for the same Call-ID, in which case the CSeq is used to avoid
ambiguity. A response to any request must use the same value of CSeq as used in
the request itself.
• Through the use of the Expires: header, Collins has requested that the registration
be effective for 2 hours. The registrar can change this time.
• If it is specified as a number of seconds, the maximum value is such that a
registration may be active for up to approximately 136 years,
• If a REGISTER request contains an Expires: header with a value that is too short
(the registration is to be active for too short a time), then the REGISTER request
will be rejected with the status code 423 (Interval too brief). The response will
include the Min-Expires: header field, which specifies the minimum registration
interval that the registrar will accept.
To cancel a registration request it can be done by sending another REGISTER request for the
same address of record and Contact and specifying a registration interval of 0. In this case,
the REG- ISTER request would be identical to the first REGISTER request, with the
exceptions that the CSeq integer is incremented and the Expires header field contains the
value 0. If Collins wanted to cancel all existing registra- tions, then he would send a
REGISTER message with the Expires header field set to 0 and the Contact header field
populated with the wildcard char- acter *. The Expires header value of 0 indicates the
cancellation of a Regis- tration and the Contact: header value of * indicates that the request is
applicable to all contact information for Collins. • TheTo:headerfieldisnotusedtocontaintheaddress of the registrar.
• TheRegistrar’saddressisindicatedinthefirstlineof the request.
• TheREGISTERrequestdoesnotcontainamessage body, since the message is
not used to describe a session of any kind.
The INVITE request is the most fundamental and important SIP request, as it is the
request used to initiate a session (i.e., establish a call).
SIP Call Sequence: Invitation
• TheINVITErequestisthemostfundamentaland important SIP request, as it is the request
used to initiate a session (i.e., establish a call).
• – The INVITE request is issued to
• – this signaling flow does not traverse any proxies. Otherwise the
message would be addressed to sip:manag