CSeq
:To ensure that transcation are processed in the appropriate sequence, a sequential number is assigned to each transaction with a SI
Psession. This sequential number is known as the command sequence(CSeq).
branch ID
:The branch ID identifies a transaction branch between two SIP entities. A difference between CSeq and branch ID is that the CSeq is
used end to end between two SIP entities.
If the request message contains one or more Route headers, then use the topmost Route header to determine the next hop for the messa
ge
If the request message containts no Route headers, the use the R-URI to forward the message.
'lr' URI parameter in the Router heaer stands for loose routing.
Loose routing implies the route to be followed by a request message is strictly defined through a set of Route headers("Route set")
without affecting the R-URI.
loose routing
: When a SIP Proxy receives a request message it will check the Route header present in the message. If the proxy determines from th
e Route header that this message is destined for this proxy, then the proxy removes the Route header and process the message. If the
SIP proxy determines from the Route header that this message is not destined for this proxy, then it will forward the message based
on the above-described rule(loose routing).
Via Header(transaction trail)
:Each entity that sends or forwards a request message adds a Via header to the request message, containing transport indicator(SIP/2
.0/UDP) and address of sending entity(127.0.0.1:5060) and branch value(branch=z9hG4bK-d87543, unique character string whithin the SI
P application on the host)
Response message routing is done top to bottom through the Via header set.
For a request message, routing is based on Route header and R-URI; for a response message, routing is based on Via header.
The Via header in the ACK request in reponse to a non-2XX final response will contain the same branch value as the corresponding INV
ITE request.
When a UAC cancels an INVITE transaction, it uses the same branch ID for the CANCEL transaction as was used for the INVITE transacti
on that it wants to cancel.
The subsequent transaction path is formed by a set of headers, called Record-Route headers, representing the set of proxies through
which a subsequent transaction will be routed. When a proxy want to be able to apply charging for a media session, it has to remain
in the SIP session.
It is not possible for a proxy to remove itself from a SIP signaling path once the SIP session is established.
The SIP session responder may typically include the Record-Route set in the 200 OK. If preconditions apply or early media is used, t
hen the Record-Route set will be sent in a provisional response.
To facilitate transparent and convenient addressing, the parties involved in
the establishment of a SIP session exchange their contact addresses. The user
agent that initiates the SIP session, by sending the initial INVITE
transaction, includes a Contact header in the initial INVITE request message.
The remote party of this SIP session includes a Contact header in a response
message, e.g. in the 200 OK.
UA-A uses the stored Record-Route set and contact address to set the Route
hedaer and R-URI rescpectively, in the ACK request to UA-B. UA-B uses the
stroed Record-Route set and contact address to set Route headers and R-URI in
the BYE request to UA-A.
Subsequent transaction are regular transaction and follow generic transaction
handling rules.
* Routing the request message is based on Router header and R-URI.
* A transaction trail is built up, consisting of a concaenation of branches,
reflect in a set of Via headers.
* A transaction (except ACK) has one final response and zero or more
provisional responses.
* Response message follows the same path as the request message.
* Retransmission of the request message and of the final response message may
be applide.
The sender of this request message has to apply DNS resolution in order to
determine transport protocol, IP address, and port number.
* NAPTR record query : this is used to obtain an overview of supported
services for this domain(proxy1.ims.operator-A.se) - for example, SIP over
UPD(_sip._tcp.proxy1.ims.operator-A.se).
* SRV record query : this is used to obtain host name of the SIP server
associated with the selected SIP service.
* A record query or AAA record query : This is used to obtain IP address of
the host.
Response messesge routing is esiaer than request message routing, since the
Via Headers contain the required IP service, the IP address, and the port
number.(Via: SIP/2.0/UDP 164.48.60.241;branch=z9hG4bK-d87543.
Reliability of Request Messages.
UAC starts a timer that governs the retranmission of this request message to
the next entity. This timer, referred to as 'timer A', is loaded with a
default value of 500ms. If no reponse, UAC will retransmit the request
message. The arrival of the retransmitted request message is again verified
through timer A, set to twice the default value, i.e. 2 x 500ms.
Unlike regular provisional responses, the 100 Trying is not propagated further
to the initiator of the INVITE transaction. When the UAC receive the 100
Trying, it knows that the next entity has received the INVITE. The sending of
the 100 Trying is based on the topmost Via header.
When P1 receives a retransmitted INVITE request, it determines that this
INVITE request constitutes a retransmission. The UAS state model within P1
will generate the 100 Trying response, but will not further process the
request message. The retransmitted request message is sent over the same
branch as the initial reqeust message, so carries the same branch identifier
in the Via header.
*UAC->UAS. For a non-retransmitted request message, the branch identifier
creates a new UAS instance; for a retransmitted request message, the branch
identifier indentifies the existing UAS instance.
*UAS-> UAC. The brance identifier identifies the exiting UAC instance.
The UAC ackknowledges the final response by sending an acknowledgement to the
UAS. The receipt of the final response completes the transaction for the UAC
and the receipt of the ACK completes the transaction for the UAS.
The provisional response is not sent reliably. Hence, the UAS take care not to
include information in the provisional response that is necessary for the
further handling of the transaction or for the further handling of the SIP
session.
The UAS applies a similar retransmission method for the final response as the
UAC applies for the request message. When the UAS has sent the final response,
it starts a timer(Timer G) that monitors the receipt of the ACK message for this
transaction.
For an unsuccessful final reponse, transmission and retransmission is hop by
hop.
When called party wants to receive confirmation of the successful arrival of
the provisional response at calling party, then called party may request an
acknowledgement(PRACK) from calling party.
* The PRACK transaction consist of a request message and final response(for
ACK transaction, there is no response)
* The support of the PRACK method is optional for a UA, whereas the support of
the ACK method is mandatory
* PRACK uses its own branch-ID and CSeq value
There may be multiple provisional response for a transaction; each provisional
response have a provisional acknowledgement associated with it. For this
reason, a provisional acknowledgement needs double identification; (i) the
transaction(with the sip session) it belong to; and (ii) the provisional
response with transaction it belong to.
* RSeq : Response sequence, used in a provisional response when that
provisional response is sent reliably. The RSeq header is a numerical value
identifying the response whith a transaction.
* RAck : Response Acknowledgement, used in a PRACK request message. The RAck
header is a combination of two numerical values; (i) the Response
sequence(RSeq) value for the which the PRACK is requested; and (ii) the
Command Sequence (CSeq) value of the transaction of this provisional
response. The combination of CSeq and RSeq uniquely identifies a particular
provisonal response of a particular transaction.
When called party receives a PRACK request, called party now knows that the
183 Session Progress has arrived, so can take further action like the playing
of an announcement.
Reliale response is an optional feature. UAS may apply reliable provisional
response only when both the INVITE initiator and the INVITE responder support
this feature. This support is indicated through the 'Supported' header. For
example:
INVITE sip:john.smith@company-x.se SIP/2.0
Supported : 100rel
The optina tag "100rel" is derived from "100 response class"(i.e. the class of
provisional response, excluding 100 Trying) and "rel"(reliable transmission).
The INVITE responder may indicatte in the provisional response that a reliable
provisional response is required. For example;
SIP/2.0 183 Session progress
Require: 100rel
If the INVITE request does not contain Require: 100 real, but contains
Supported: 100rel, then INVITE responder may determine per provisional
response whether reliable transmission applies.
A CANCEL transaction is a regular transaction in the sense that it consist of
a request and a final response message on a CANCEL transaction. The CANCEL
request is used only to cancel the processing of a particular INVITE
transaction. Hence, there is no need to provide any response to the CANCEL
request, other than a 200 OK, indicating that the request is received and will
be forwarded to the next hop.
When a CANCEL request arrives at an intermediate proxy, the proxy need to
match this CANCEL request with the associated INVITE transaction. This is done
by the same brach identifier for the CANCEL request as for the INVITE request.
Besides the branch identifier, the following headers in the CANCEL request
should be identical, per CANCEL hop, to the corresponding headers int the
INVITE request that is to be canceled:
* Request URI(R-URI). Using the same R-URI ensures that the CANCEL request is
routed to the same application in the UAS
* Route Header. The identical Router Header in the CANCEL request may needed
for a stateless proxy to route the CANCEL request to the same transport
address as for the INVITE request.
* Via Header. Since CANCEL is a hop-by-hop transaction, the CANCEL request
contains a single Via header only. The branch identifier will be identical to
that for the INVITE transaction for the reasons given above.
* Command Sequence. should be the same as for the INVITE transaction
When the UAS receives a CANCEL request, it generate a final response for the
INVITE transaction. The final response 487 Request Terminated is used for the
this purpose.
Since the CANCEL reqeust is send on a hop-by-hop basis, it is not possible for
the UAS to infrom the UAC about the failure of canceling the INVITE
transaction.
The cancellation of a transaction would not be possible prior to receiving the
first provisional response for the transaction.
The calling party has received a provisional response(except 100 Trying) from
the called party, a dialog is established between calling and called party.
Prior to the final response, the dialog between calling and called party is
referred to as early dialog.
The dialog identifier is composed of From tag, To tag, Call ID.
The PRACK message indicates to UA-B that UA-A has received the 183 Session
Progress and that UA-A is ready to receive (early) media.The early media may,
for example, be a personalized ringback tone generated by the terminal. The
180 Ringing provisional response gets the SIP phone to transit to the alerting
state;the subscriber may then see an indication on the display that the call
has reached the destination subscriber and that alerting has started.
The proxy forks the SIP INVITE request to the intended receiver and to a media
server. Both UA-B and media server uses establish a SIP dialog with UA-A. At
this point, both dialogs are early dialog. The media server uses the early
dialog with UA-A to transfer media to that UA-A. When UA-B answers the call,
the early dialog between UA-B and UA-A transits to the confrimed state. UA-A
will discard the early dialog with the media server and will accept only media
from UA-B.(page 208, Figure 7.41)
When early media transfer ceases(e.g. the playing of an alerting announcement
is finished), the early dialog used for the transfer of that early media is no
longer needed. Application server may send an explicit indication to the
calling party that this dialog is terminated. This indication id done through
the 199 Early Dialog Terminated response.
