SIP RFC References

RFC 2543/ RFC 3261 SIP

RFC 3665 SIP call flows basic examples
RFC 366X SIP PSTN Call Flows
RFC 4028 Session Timers in the SIP
RFC 3551 RTP/AVP
RFC 4566 Media Stream Descriptor lines

SIP BASIC OVERVIEW

 SIP Communications protocol is used for session setup, modification and teardown. It is an application layer protocol that incorporates many elements of
HTTP and SMTP. {ref1}
 UAC: node that generates request / / UAS: node that generates response {ref1}
 SIP transaction: single request and all responses to that request, which may include zero or more [ provisional (1xx) responses or final responses]
 SIP commonly uses TCP/UDP port over 5060 // SIP can be secured by using TLS. SIP over TLS 5061
 SBC which performs multiple request/responses commonly uses UDP . If SIP sessions have to traverse links that are prone to errors, it is recommended to
use TCP
 Resources on a SIP network are identified by a URI “ sip:username:password@host:port “
 Secure SIP transmission over TLS, an s is added to the end of SIP to make it SIPS sips:username:password@host:port
 SIP devices: IP phones, Call Servers, PDS, Gateways and SBCs
 SIP is a modular design and can work in concert with many other many protocols that are required to setup and support communication sessions [RTP,
SDP,RSVP,LDAP] {ref1}
 SIP Session Versus Media Session {ref1}
o Two end points establish a SIP session by exchanging SIP messages, the SIP session is used to exchange media session that needs to be
established, so the SIP session and the media session are related to one another.
o Establishment, modification and termination of the media session [the user plane] are signaled between the two-endpoints, via the SIP session
[the control plane]
 SIP session : a sip session between two communication endpoints will typically not run directly point-to-point there will be SIP proxies
residing in the signaling path. One or more SIP proxies play a role in establishing the SIP session by forwarding the invite request to the
VoIP network serving the destination address and to the registrar holding the person’s contact binding
 Media Session: on the other hand, will typically traverse fewer nodes. This is accomplished by the end-points exchanging their contact
address for media transfer, allowing the respective peers to send media directly to that contact address.
 This aspect of SIP Session [many nodes] and Media session [fewer nodes] is commonly depicted through the SIP trapezoid
 Figure shows during the SIP session establishment between UA1 and UA2, the SIP session is carried
through a number of SIP proxies, labeled P1-P4.
The Path for the media Session is defined during the SIP session establishment , but media transfer
has not started yet

When the SIP session is established, it may, for the remainder of the life of this SIP session, be
carries through a smaller number of SIP proxies.
Media transfer between the TWO UAs may now start. The relation between the SIP session and the
media session remains for the entire communication session. The media session remains “under
control” of the SIP session. A change in the definition of the media session, as well as the
termination of the media session, is signaled between the UAs through the SIP session

SIP is transaction-based protocol

The Execution is done through a client-server transaction state model. A user agent client initiates a SIP transaction; the SIP transaction is received and executed
by a user agent server {ref1}
o A sip transaction consists of a request, zero or more provisional responses and final response
o The execution of the INVITE transaction may also include the sending of an ACK request [ unsuccessful response ]
o When the INVITE transaction leads to a successful final response, it will also followed by an ACK request. That ACK request constitutes a sperate
transaction, without final response

SIP Dialog
 But what happens in the case of the INVITE request? The establishment of a SIP session starts basically with an INVITE request and is considered as completed
upon the receipt of the ACK. In this case, the transaction starts with the INVITE request and ends with the 200 OK, so the ACK is not part of the transaction. The
 ACK can be considered as a transaction on its own. However, when the final response to an INVITE is not a 2xx response, then the ACK is considered as part of
the transaction.A dialog is a complete exchange of SIP messages between two user-agents. That means that transactions are actually parts of a dialog. For
example, in the case of a SIP session establishment, a dialog starts with the INVITE-200 OK transaction, continues with the ACK and ends with the BYE-200 OK
transaction.
 The picture below depicts the dialog and transactions that take place during the establishment of a SIP session:

Sip Responses
The Responses that UAS may send to the UAC, in response to a request message are divided into response classes {ref1}
o 1xx class – provisional response
o 2xx class – success
o 3xx class – redirect
o 4xx class – request failure
o 5xx class- Server failure
o 6xx class-Global failure
Command Sequence {ref1}
o To ensure that transactions are processed in the appropriate sequence, a sequential number is assigned to each transaction within a SIP session.
This sequential number is known as the command sequence (CSeq).
o Cseq is carried over intermediate proxies
o Cseq header carries both a numerical value and name of the method
o The ACK transaction has special handling, as far as the Cseq header is concerned. An ACK transaction is closely related to an invite transaction; it
acknowledges the final response of the invite transaction. This close relation is reflected in the fact that ACK transaction contains the same Cseq
value as the INVITE transaction it belongs to
SIP Transaction State Models{ref1}
The transaction instance constitutes a process that may be created by a UA. In A way , the UA uses the services
from a transaction instance. The UA creates a request message, starts a corresponding transaction client model
instance, and passes the request message to the client state model instance, with the request to further handle
that transaction toward the remote end. The Phone application, being the user of the services from a transaction
model instance , is referred to as the Transaction User {Tu}

Functional Components of SIP: {ref1}

Sip Proxy
Is capable of performing call routing, authentication, authorization, address resolution , loop detection and load balancing.
SIP proxy can be
Stateful : aware of the state of a SIP transaction by creating a server transaction, client transaction and a response context. By being transaction aware, it is
capable of forking request, retransmitting requests and generating messages by itself. Using something like record route
Stateless: do not maintain transaction state, they transparently forward requests form the client to the server, and they send responses in the reverse direction.
Once a request or a response is forwarded to the intended recipient, all details or transaction contact of the message is purged. Consequently, stateless proxies
cannot fork requests , re-transmit requests or generate messages on their own
 
" proxies do not manipulate SIP message headers such as To, From , CALL-ID and so on. They do however , include a via header and record-route header , they
decrement the Max-Forwards header value by one "
A record-routing stateful proxy applies adaptation to the initial SIP request message indicating that it wants to be in the SIP transaction chain for all subsequent
SIP transactions. A non-record-routing SIP proxy does not make this adaption to the initial SIP request message. As a result, the respective Uas between which
the SIP session is established will not send the subsequent SIP transactions through this proxy

 
Redirect Server:
A redirect server is a server that provides location services to user agents or proxies by replying to request with the location or route to the host ultimately
services the request.
This is desirable in situations where there is a need to build highly scalable servers that do not participate in a sip transaction but simply help the proxy or user
agent reach the host by sending a single message.
Redirect servers reply to request with 3XXX response in which the contact header contains the URI of the location to the host
 
Registrar Server:
A registrar server accepts registration request from user agents and create a mapping between their address of record [A record ] and user agents location. In
other words phone number and ip address its located in. Subsequently , this mapping between the user agent AOR and location is indexed and stored in a
location server
 
Location Server:
A location server contains a mapping between a user agents AOR and location
 
B2BUA: [CUCM is B2BUA]
A B2UA is similar to a stateful sip proxy server in that it actively maintains call state , but does not have the same limitations as a SIP proxy server. i.e B2BUA can
disconnect a call and modify media information sent in the session description protocol [SDP].

How should a sip call through a B2BUA be viewed.

as two independent call legs from a SIP perspective:

1. An inbound SIP call arriving at a UA and

2. A new outbound call orginating from another UA

Why is CUCM a B2BUA ?

Because CUCM provides many other features beyond those of a SIP proxy server – call admission control,codec neg , interoperability with h323,mgcp and SIP,
CTI etc

SIP Session Establishment

SIP works: Request/Response, Structure of SIP Message {ref1}

Request Message Response Message

Request line Status line
The Request line consists of the following components in this sequence The status line contains following components
1. Method name : For Example , invite 1. SIP Protocol Version : this will be set to SIP/2.0
2. Request URI [ R-URI ] : the R-URI is the target of the request 2. Status Code : this is numerical representation of the outcome of
message. It may be a URI or an IP address. the execution of the request
3. SIP Protocol version: current version of SIP is 2.0. this denoted 3. Reason phrase: this is text string accompanying the status code. It
by adding SIP/2.0 expresses the status code in a readable format – for example,
SIP/2.0 183 session progress
Header lines Header lines
Header lines are lines of information that provide additional information the function of the header lines in the response message is identical to the
to the request message . header line may be used for purposes such as function of the header lines in the request message.
message routing, transaction identification , branch identification, SIP However there will be typically be different header lines present in a
path building , dialog identification , contact address exchange, and response message than in the request message the response message
subscriber identification relates to.
Certain SIP headers may contain a URI. Examples of such header are Some headers found in a response message are copied from the request
Route, Record-Route and contact. message.
There may be one or more parameters associated with a URI in a header, This may particularly be the case with certain system headers, such as Cseq
as is the case for the R-URI , call-id and via system headers are the headers that are used for SIP
There may also be one or more parameters associated with header line message routing and transaction handling
as a whole.
To identify parameters as URI parameters or header
parameters, angle brackets are used in a header line.
Example are as follows :
Contact : <sip:john.smith@company-x.se>;expires=3600
Contact: <sip:john.smith@company-x.se;transport=udp>
The header parameter expires=3600 indicates that the contact address
has a validity of 3600 s. The parameter transport=udp is directly
associated with the URI; it indicates that requests destined for
john.smith@company-x.se should be sent over UDP (for the SIP branch
arriving at the host of company-x.se).
 <empty line> <empty line>
Body (optional) Body (optional)
The body within a request message contains the payload that SIP The body within a response message has the same function as the body
message transfers. Body of the sip message is application information, with a request message. The actual presence of a body in a response
exchanged between end-points; its not used for message routing, message and its use depends on the applciation
transaction handling etc.
One prominent example of a message body is SDP

Initial Request Message Routing UAC to UAS

A SIP request message contains two items of information that are used for routing
 R- URI is the Destination
 May contain one or more Route Headers
o if the request contains one or more route headers, then use the topmost route header
to determine the next hop
o if the request contains no route headers, then use the R-URI to forward message
A URI contain one or more parameters, one example is the “lr” URI parameter in the route
header. the “LR” stands for losse routing . loose routing implies , route to be followed by a
request message is strictly through a set of route headers without affecting the R-URI

SIP request from one subscriber [Calling Party] to another subscriber [called party] is a representative example of communication between two
subscribers. However, many deviations are possible such as :

 the request message is routed through a stateless proxy

 one or more intermediate SIP nodes take the role of B2BUA; in this case, the ISP session from calling

 Calling Party to called party is divided into multiple SIP sessions. Each spanning a section of the SIP chain, between calling part and
called party

 The request message traverses an additional SIP proxy at the border between two interconnected VOIP networks. This routing through a
border SIP proxy may involve the use of internal versus External DNS

 request message is routed through one or more SIP application servers; this routing would be done by the service node/registrar
serving the calling or called subscriber
  the registrar of the destination subscriber or a SIP application server of the destination subscriber forwards the request message to
two or more terminals associated with the destination subscriber [parallel/sequential alerting]
o To limit the number of branches a request message may span, Max-Forwards is the header included with starting value 70. Every proxy that
forwards the request message decrements the max-forward value by 1 . when it reaches 0, a proxy will no longer forward the message but will
instead , return unsuccessful final response message 483 too many hops
Response Message Routing [ via headers]
The sending of the request message from UAC to UAS has resulted in a transaction trial being established. The Transaction trail between UA1 and UA2 runs
via a set of transaction branches. For each Sip Request and response a branch identifier is created, hence sip trail is concatenation of branch identifiers

Invite message from UA1 to it adjacent proxy has the following structure

A via header in the request message identifies a transaction branch. The SET of via headers in the request
message represents the transaction trial for this transaction. Each entity that sends or forwards a request message adds a Via header to the request message
containing the following information:

o Transport indicator
o Address of sending entity
o Branch value

A SIP response message follows the same signaling path as the request message to which this response message relates. When a UA receives a request message,
hence taking the role of UAS, it stores the received set of Via headers. This set of Via headers is stored in the server transaction state model instance; it is
needed only for the processing of this particular transaction. . The UA acting as UAS for this transaction will send zero or more provisional responses and will
send a final response. For the sending of a response, the UAS uses the set of Via headers associated with this transaction. Response message routing is hence
done top to bottom through via header set
The Entire via header set is stored by the UAS and is used for every response message to be returned for this transaction, including response transmission. There
are cases where a branch identifier is also reused in the direction from UAC to UAS. These include:

o when a UAC[or proxy] sends an ACK request in response to a non-2xx final response
o When a UAC[or proxy] retransmits a request due to expiry of a UAC state model-related timer
o When a UAC cancels INVITE, it uses the same branch identifier

Building A SIP routing path for Subsequent SIP requests [ Re-route headers]
This transaction trail, formed by the set of Via headers, is used for the routing of response message(s). In addition, proxies will build up a subsequent
transaction path. This 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. The subsequent transaction path does not have to be identical to the initial transaction path

A set of Record-Route headers is constructed, as the INVITE request message travels toward the destination UA, acting as UAS for the INVITE transaction.

Record-Route set needs to be constructed and exchanged only once. To be more specific:
Record-Route set is constructed during the sending of the initial INVITE request message
Record-Route set is included in the initial INVITE transaction response.

The UAS copies the entire Record-Route set in the response message. The Record-Route set is then conveyed to the UAC. The UAC and UAS now both have a
Record-Route set that may be used for subsequent transaction routing

The Record-Route set may be included, from UAS to UAC, in a provisional response or in the final response:

1. The 200 OK is a reliable response. The reliability of 200 OK is constituted by the ACK request message following the 200 OK.
 2. It is only after the 200 OK final response that a requirement arises for subsequent SIP transactions, hence there is no reason to return the Record-Route
set earlier than the 200 OK. The ACK request following the 200 OK will be the first request message using the Record-Route set.

3. However, if preconditions apply or early media is used, then the Record-Route set will be sent in a provisional response.

Exchanging the contact address for Subsequent SIP requests

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, i.e. the user agent that responds to the SIP session establishment request,
includes a Contact header in a response message, e.g. in the 200 OK or provinal response

Subsequent Request Message Routing

Now that we have seen how the two user agents exchange contact addresses (to address each other for subsequent transactions) and exchange Record-Route
sets (indicating what path to follow for these subsequent transactions), we will take a closer look at a typical subsequent transaction

Figure 7.20 shows a limited SIP signaling sequence for an initial INVITE transaction, showing only the request line, status line, Route headers, and Record-Route
headers, as these are the headers that are used for SIP routing. The bold text in Figure 7.20 represents the information that is stored in UA-A and UA-B for this
SIP session. Subsequent transactions will use that information, as depicted in Figure 7.21. In Figure 7.21 UA-A uses the stored Record-Route set and contact
address to set the Route headers and R-URI respectively, in the ACK request to UA-B. UA-B uses the stored Record-Route set and contact address to set Route
headers and R-URI in the BYE request to UA-A.
SIP transport considerations {ref1}
o SIP being an OSI application protocol, runs on top of a transportlayer , such as UDP, TCP or SCTP. For every branch that is established by a SIP UA, i.e.
for every transaction that is initiated and for which a request message is sent from the UAC state model instance, the transport mode has to be
determined. The Transport method used for sending a request message may be determined from the route header or from the R-URI. Consider ,
below INVITE message
 The routing of this message will be based on the topmost route header. This route header has the form of a domain name [proxy1.ims.operator-
A.se] . hence the sender of this request message has to apply DNS resolution in order to determine the transport protocol, IP address and Port
number. The following DNS services required here
o NAPTR [ Name Authority Point Record] : supported services for this domain , for e.g. UDP [_sip._UDP.proxy1.ims.operator-A.se] or
[ sip._TCP.proxy1.ims.operator-A.se]
o SRV record query : hostname of the SIP server
o A record query : IP address of hostname

The second hop for the above example invite message in this section is directed to server1.ims.operator-a.se. here , the proxy node , which received the
invite message from the UA, applies DNS queries as the UA had applied to determine SIP service, transport protocol, IP address and port number

Reliability of SIP requests and SIP Responses

o SIP reliability is the guarantee that a request message has arrived at the destination UAS and that the [final] response from the UAS has arrived at
the UAC
o One method for achieving this guarantee is the use of TCP as transport protocol for SIP
o SIP also has its own reliability mechanism , which may be used in conjunction with and independently of TCP or UDP .we will describe the following
reliability mechanism below

Reliability of Request message

UAC sets timer A of 500ms [default] for the initial INVITE, if no response received within 500ms , UAC
determines that request message did not arrive at the next entity , so the UAC will re-transmit the request
message. The arrival of the retransmitted request message is again verified through timer A, set to twice
the default value 2X500ms. Once a Provsional (or final) response is received , the UAC stops time A and will
not further transmit. When a UAC does not reciev a response with 64 x T1[=32s], the transaction is
considered to have failed and will be aborted

Reliability of Successful final response

When the entity that will be acting as UAS receives the request message and has provided the
100 Trying, it commences the processing of the request message. It may send one or more
provisional responses and it will send a final response. The UAC that had initiated the transaction
acknowledges the final response by sending an ack to UAS. The Receipt of the final response completes the transaction for the UAC and the receipt of the ACL
completes the transaction for the UAS

The provisional response, in this example 180 Ringing, is not sent reliably. Hence, the UAS takes 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 that monitors the
receipt of the ACK message for this transaction (see Figure 7.26).

Figure 7.27 shows the case where the ACK request message from UAC was lost. In this example,
where the ACK message transmission failed, the UAC will receive a retransmission of the final
response. The UAC will then retransmit the ACK message. This also shows that the UAC should remain
active for a finite duration, in order to be able to receive a possible retransmission of the final
response.

Reliability of unsuccessful final response

The reliability of the unsuccessful final response is provided in a hop-by-
hop manner between two sip entities. The rationale of this approach is
that when the invite transaction is unsuccessful, it does not lead to
establishment of a SIP session. The INVITE transaction had resulted in the
establishment of a transaction trial. The unsuccessful result of the invite
transaction leads to “cleaning up the trail”. The unsuccessful final response
is transmitted to the UAC and traverses zero or more SIP proxies, i.e. is
transmitted over one or more branches. Each time the response traverses a branch, the branch can be released
Reliability of Provisional response [Provisional Ack]
Defined in RFC 3262
There will be instances where provisional responses required to be delivered reliable,
for e.g early media or two-step offer-answer message sequence for codec negotiation.
For this Purpose Provisional acknowledgement is used, SIP METHOD PRACK.
When UA-B wants to receive confirmation of the successful arrival of the provisional
response at UA-A, then UA-B may request an ACK from UA-A.
PRACK transaction can be compared with ACK transaction. Some essential differences
are :
 the prack transaction consists of a request message and final response message
[for an ACK transaction, there is no response]
 the support for prack is optional where support for ACK is mandatory
 prack used its own branch-id and cseq

There may be multiple provisional responses for a transaction. For this reason PRACK
needs double identification
* the transaction [within the SIP session] it belongs to
* the provisional response within that transaction it belongs to

the following SIP headers are used for the PRACK

RSEQ : response sequence, used in provisional response

RACK : response ack , used in PRACK request message

In the figure you can notice that PRACK transaction doesn’t traverse sip proxies. IN addition, the PRACK request message is directed to UA-B
contact address (sip:194.151.127.212) as opposed to UA-B’s public identity (sip:john.smith@…). The provisional response for which the
PRACK is requested (183 Session progress) contains Record-Route headers and the contact address of UA-B. UA-A uses these Record-Route
headers and contact address for the routing and addressing respectively of the PRACK request to UA-B. The intermediate proxies, so far as
they do not record route, need not be aware of the PRACK transaction. The non-record routing proxies will handle just the INVITE
transaction

As stated earlier , reliable provisional response is an optional feature.

Invite initiator to indicate through the supported header Invite responder indicate through the Require header
 Both invite initiator and invite responder may request a reliable provisional response
when the Invite request contains Require:100 rel, the request for a reliable provisional response applies to any of the provisional responses
except 100 Trying for this transaction.
If However the invite request does not contain Require:100Rel , but contains supported:100rel , then the INVITE responder may determine
per provisional response whether reliable transmission applies
the use of reliable transmission of provisional response applies bot th UDP and TCP

Cancelling SIP Transaction Request

o Cancelling of SIP happens when the caller wants to abandon the call, means the processing of the SIP Invite transaction shall be cancelled.
o A SPECIAL method called CANCEL is used, A Cancel transaction is sent to the responder , requesting to the cancel the execution Invite transaction
o Because the responder has not yet responded for the invite sent , the SIP trail of the invite transaction is unknown to the sender. The exact SIP trail is
determined on hop by hop basis. In order to send a cancel instruction to the invite responder, the cancel request is sent by the INVITE intiator and by each
intermediate proxy , to the same transport address as the corresponding INVITE was sent. This same transport address includes IP address , transport
protocol and port number

o There is no need to provide any response o the CANCEL request, other than a 200 ok, indicating that the request is received and will be forwarded to the
NEXT hop
o When a CANCEL request arrives at an intermediate proxy, the proxy needs to match this cancel request with the associated invite transaction. This is done
by using the same branch identifier for the cancel request as for the invite request
o Besides a branch identifier , the following headers in the cancel request should be identical, per cancel hop , to the corresponding header in the INVIE
request [for that hop) that is to be cacnelled
 Request URI,Route header,Via header,Cseq value,From header , to Header and call-id
o When UAS receives a cancel request and has matched the cancel request with an INVITE transaction , it does three things
 Release access network resources, stopping the alerting of the called party and generate final
response for the invite transaction
 The final response 487 request terminated is used for this purpose. The invite transaction is further
terminated in the regular manner , which includes the sending of an ACK message by the UAC to the
UAS
 o Should it occur that the UAS had already sent a final response on the invite request, then the invite transaction can no longer be canceled.UAC will have to
acknowledge the 200 OK in the regular manner and then terminate the SIP session in the usual fashion by initiating a BYE transaction
o The UAC that intends to cancel an INVITE transaction, e.g. because the calling party has abandoned the call attempt, must wait until the first provisional
response is received and may then send the CANCEL request. This wait for the first provisional response before sending the CANCEL request has to be
done by each intermediate proxy in the SIP chain up to the UAS.
o A cancel request may be issued before the dialog was established, i.e before a TO tag was received.

SIP DIALOGS
Figure below depicts SIP transaction initiation between UAC and UAS. As soon as UA-A has received a
provisional response (except 100 Trying) from UA-B, a dialog is established between UA-A and UA-B.
All further SIP signaling between UA-A and UA-B , concerned with this relation , is carried through
this dialog. Also point to be noted is the dialog is established between UA-A and UA-B and not
between UAC and UAS

Confirmed dialog : when the invite transaction between UA-A and UA-B is successfully completed
(2xx class final response ) .
Early Dialog: as long as the execution of the INVITE transaction is in progress , the dialog between UA-A and UA-B is referred to as early dialog

A SIP message carries a dialog identifier , this enables a UA to associate an incoming message with a particular SIP dialog. This dialog identifier composed of
three elements from tag, to tag and call-id

a SIP dialog is strictly identified by the From tag, the To tag, and the Call-ID. From that point of view, it would be permissible for a SIP application server to
modify the URI in the From header. E.g

“notice that even the URI is changed the tag is still the same”
IETF 3261 allows to do this when compared to its predecessor 2543

Multiple Early Dialogs

A sip proxy or SIP application server on the SIP path between UAC and UAS may forward the INVITE request message to two or more destinations. Below
is the figure

When forking occurs , invite request is received on two or more terminals { parallelly or sequentially }
The Two INVITE request messages sent by the registrar to UA-B(1) and UA-B(2), except for
R-URI : the R-URI contains the contact address of the terminal
Route Header: the Route header identifies the path that shall be followed by the INVITE request message , from registrar to UA-B terminal. Different
terminals of the same subscriber may be registered via different proxies . Hence, the route headers in the INVITE messages may indicate different
proxies
Via Header [ branch ] : for each invite request message sent from the registrar, a client transaction is initiated ; for each client transaction a designated
branch identifier is used. The IP addresses in the VIA header should be identical, since the INVITE messages are sent from the same host and application
 Each UA-B may generate provisional response.in this case UA-B(1) and UA-B(2), are forwarded transparently to UA-A. The provisional responses received by UA-A, for different dialogs , will differ in atleast the following
SIP headers

TO TAG , CONTACT ADDRESS, RECORD ROUTE , CONTENT TYPE and CONTENT LENGTH

The general behavior of the forking proxy is as follows:

• Provisional responses from the respective user agent servers (UASs) will be forwarded transparently to the user agent client (UAC).
• When the UAC has received a 180 Ringing response and then receives a second 180 Ringing response, relating to a second dialog, this has no
effect on the alerting state of the terminal. That is, the terminal of the calling party remains in an alerting state.
• The receipt of multiple early dialogs by the UAC (calling party) has the side-effect that the UAC is aware that multiple terminals of the called party
are being alerted. The arrival of a second 180 Ringing (relating to another dialog) is normally not shown to the calling party.
• When a non-2xx-class final response is received from a particular UAS, the INVITE transaction with that UAS terminates (and the forking proxy will
send ACK to that UAS). The forking proxy will store the final response received from that UAS and will continue to send INVITE to other available
contact addresses (this may have been done in parallel), until a 2xx-class final response is received from a particular UAS. That final response is
forwarded to the UAC. The forking proxy cancels any INVITE transaction still ongoing to other contact address(es), in a manner that is similar to the
canceling of an INVITE transaction by a UAC.
• When none of the contact addresses returns a successful final response, the forking proxy determines “the best final response” from the set of
received final responses and returns that best final response to the UAC. IETF RFC 3261 describes the rule for determining the best final response.

There is no defined possibility for a UA to indicate in the INVITE request whether or not it supports multiple early dialogs

Target Set
The process in the registrar of matching the R-URI of the incoming INVITE request with one or more registered contact addresses, for that R-URI, is known as building the target set.

Early Media
o Early media means  a call is being established and media is transferred before the call is answered
o In this example, UA-B uses the reliable provisional response mechanism (provisional response followed by PRACK transaction) to indicate to UA-A that it (UA-B) intends to send media during the establishment of the
call
o 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
o This early media may, for example, be a personalized ringback tone generated by the terminal
o 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. There is already early media flowing to the calling party, so the terminal should not generate local ringtone
o Early media may take one of the following directions: (1) media from UA-A to UA-B ( forward media); (2) media from UA-B to UA-A ( backward media); and (3) media between UA-A and UA-B in both directions
( bothway media)

Session Description Protocol – General Description

o (V) Protocol version – version of the SDP , version 0 is only at the momet
o (O) Originator and session identifier –
 Name of the session creator
 Session identifier
 Session description version – whenever an entity provides new session description for a media
session change [add or remove codec], the version of the session will be incremented
 Network type of identifier, such as “IN” indicating internet
 IP version, such as “IPv4”
 Address of the host from where the session description is created. FQDN or IPv4 or IP6
 o (S) Session name - this text line allows the generator of the media session to give a descriptive name to media session such as private
o (C) connection information – [optional ] if this field is present , it applies to all media descriptions in the SDP, except for those media
descriptions that have designated connection information associated with it
 Network type – such as IN
 IP version 4 or 6
 Address of the host Fqdn or IPV4 or IPV6
o (T) time – the time may be used to provide a start time and stop time , specify the validity of the media session.alternatively , an unbound
session may be provided [both start time and stop time set to 0). When SDP is used with SIP , the media session is described by the SDP will
be bounded by the SIP sessionor dialog
 Session Description Protocol – Media Description
o (M) – Media – media line is built up from a number of informationa fields m=audio 61896 RTP 0 8 3 101
 Audio = media type is audio / video /text
 61896 = Port – this field indicates to which port the media stream shall be sent , if there is no designated (C) connection
information defined for this media stream, the media shall be sent to the IP address as defined
by the Connection information in the SDP general part
 RTP= this field identifies the transport protocol that is used for transporting the media stream .
two promimemt examples are
 RTP/AVP – which implies that RTP/UDP is used
 RTP/SAVP – which implies the use of SRTP/UDP
 0 8 3 101 – Media format – there may be one or media format field in the media line
 EACH MEDIA format denotes a specific codec [payload] . Media format may refer static
payload type or dynamic payload type
o Static payload – defined in the corresponding application [AVP or SAVP]
o Dynamic Payload – defined by means of attribute description line following by the media description line
o (B) – Bandwidth – the bandwidth line defines the proposed bandwidth , in kb/s for media stream [ optional]
o (A) -Attribute – various media attribute descriptions are defined. We will mention the most important and common used ones
 Ptime- this attribute defines the packetization time to be applied by the codec . if no ptime is provided for a codec , then the
packetization shall follow the rules of the application [ IETF RFC 3551 for RTP/AVP ]
 Rtpmap - A dynamic payload type definition in the m-line is defined through RTP mapping . The RTP mappings defines the payload
type in terms of codec type and clocl rate
 Fmtp- a media type may require addtiona information. An example is the following

 The following 4 attributes define the stream direction of media stream

 A=Sendrecv
 A=Recvonly
  A=Sendonly
 A=Inactive
o (C) Connection information- a media description may have connection information associated with it . this allows for different media
transport address for the different media component of a multi media call . for e.g , different IP address may be used for the audio stream
and video stream in a call

RTP

The media streams that are defines with various media lines relate to the RTP sessions , carrying media in accordance with the media descption. Each RTP
session has an RTCP session associated with it . A general rule is that the RTCP session should use the same network connection and transport protocol as the
corresponding RTP session. A further general rule is that an RTP session should use an even port number and the corresponding RTCP session the next higher
port number

SIP Messages
SIP Request Description , SIP Requests are known as methods make sip messages workable

  Core Messages

INVITE  A caller sends out this message to request another entity to join a SIP session
 A session is considered established if an invite has received a success response or an ACK has been sent
 A successful invite request established a dialog between the two user agents which continues until a bye is sent to terminate
the session
 An INVITE sent within an established dialog is known as re-invite
 Re-invite is used to change the session characteristic or refresh the state of a dialog

REGISTER  A client uses register to register the address listed in the TO header field with a SIP registrar server
 The Register request may be forwarded or proxied until it reaches an authoritive registrar of the specified domain
 It carries the AOR in the TO header od the user that is being registered
 Register request contains the time period 3600sec
 One user agent can send a register request on bhealf of another user agent. This is known as third-party registration , here the
from tag contains the uri Of the party submitting the registartion on bhealf of the part identified in the to header

ACK This indicates that the client has received a final response to an INVITE request

BYE  This is used by UAC to indicate to the server that it wishes to terminate the established SIP session
 This cannot be sent proxy server
 Bye request normally routes end to end , by passing the proxy server
  Bye cannot be sent to a pending an INVITE or an unestablished session

OPTIONS This request queries the server or user agent for its capabilities and its avaiablity
The response to a request lists the capablitites of the user agent or server
A proxy never generates an options request

CANCEL  This is used to cancel a pending request and can be sent only if the server has not replied with final response [ user agent or
proxy server can send this]
 Cancel is a HOP by HOP,
 

  Extensions

Subscribe This creates a subscriptions for important event notification

 It contains expires header field that indicates the duration of a subscription
 After a time period passes, the subscription will automatically terminate
 Subscription establishes a dialog between the user agents
 You can re-subscriptions again by sending another subscribe within the dialog before the expiration time
 A 200OK will be received for a subscription user
 Users can unsubscribe by sending another subscribe method with expire value ZERO
 

Notify  This notifies the subscriber of the occurrence of an event

 Usually a notify will trigger within a dialog when a subscription exists between the subscriber and the notifier
 Notify contain an EVENT header field indicating the event and subscription state header field indicating the current state of the
subscription
 A notify is always sent at the start and termination of as subscription
 

Publish This publishes an event to the server , such as user agent to send event information to a server
Publish is mostly useful when there are multiple sources of event information
A Publish request is similar to a notify , except that it is not sent in a dialog
 A Publish request must contain an Expires header field and a MIN-Expires header field
 

 
 

PRACK This provisional ack is sued to ensure that provisional responses are received reliably
Generally PRACK is generated by a client when it receives provisional response containing RSEQ reliable sequence number and a
supported:100rel header
PRACK contains [Rseq + Cseq ] vaule in the rack header
The prack method applies to all provisional responses except the 100 trying response , which is never realibly transported
A prack may conatin a message body ; it may be used for offer/anaswer exchange

Info This allows the exchange of application-level information among communicating entities
Info is used by a user agent to send call signaling information to another user agent with which it has established a media session
This is an end-to-end request
A proxy will always forward an INFO request

REFER This instructs the recipient to contact another entity , using the information found in the refer request
Refer must contain a Refer-to header . This is mandatory header for REFER
Refer can be sent inside or outside a dialog
A 202 accepted will trigger a REFER request which indicates that other user agent

UPDATE This modifies the state of the session without changing the state of the dialog

Message This transports instant message using SIP

Message can be sent within a dialog or outside a dialog
The contents of a message are carried in the message body as MIME attachment
A 200 OK response is normally received to indicate that the message has been delivered as its destination
SIP Responses
SIP Responses Description

1XX Informational : The request has been received and is being processed

2xx Success: the request has been received , understood and accepted

3XX Redirection : Further action needs to be taken to complete the request

4XX Client Error : the request contains bad syntax

5XX Server Error : A server failed to fulfill a valid request

6XX Global Failure : the request could not be fulfilled at any server

Establishing a SIP session and Introduction to headers [ref 3]

Forming a Request
Mandatory for all SIP messages

Method and in general, each resource within a SIP network is identified by a URI , which is expresses wither as SIP URI or SIPS URI
Request URI Example 3-1 shows the first line of a SIP INVITE message, beginning with the SIP method type (INVITE), followed by Request-URI, and ending
with the SIP version (SIP/2.0).
INVITE sip:14083926001@cl2-cucm-sub1.entcomp1.com;user=phone SIP/2.0
Via: SIP/2.0/TCP 10.118.58.68:55093;branch=z9hG4bK3cb3039b
From: "9193925002" <sip:9193925002@cl2-cucm-sub1@entcomp1.com>;
tag=f45c89b76b25000b60fc9d5d-68bf7669
To: sip:14083926001@cl2-cucm-sub1@entcompl1.com
 

VIA Indicates transport layer protocol used for exchanging SIP messages and the location to which responses have to be sent
Via: SIP/2.0/UDP 10.1.1.1:5060;branch=z9hG4bK2D1F9D1C08
 
Also included in the via header field is the branch parameter, which services as an identifier for the SIP transaction created by any request and
remains the same from the
Perspective of the UAC and the UAS ,
Subsequent requests that create new transactions must ensure that they generate new and unique values for this parameter
 
When Sip proxy handles a request, such as a SIP INVITE, it inserts a via header field before forwarding the request to the next hop. A request
 traversing proxies has more than one via header field value

From Indicates the logical entity of the user agent that initiates the request.
This field can carry initiator URI and also optional display name
Intermediary devices like SBC usually transform the contents of the from header field, this is due to enable interoperability across different SIP
networks
The from header field must carry a tag parameter.

To This header field usually idnetified the locgical entity that is supposed to process the request and is populated using SIP URI/SIPS URI or TEL
URI
The logical entity identified in the TO header may or may not be the actual UAS that process the request
In fact, the entity identified in the TO header field usually isnt the one to process the request traverses several hops
Dialog-creating requests[such as invite] must never carry a tag parmater in the TO header field., Instead, the tag parmater is populated by
the user agent that process the request

Call-ID This header field uniquely identifies all messages that belong to a SIP dialog; the SIP dialog in turn is uniquely identified by the combination of
the CALL-ID header, the From tag and the To tag

Max-Forwards This header field value limits the number for hops a request can traverse before it reaches its final destination. Every node that receives a
request either partially or completely process a SIP request.
Partial process : running syntactical checks , adding header fields or occasionally modifying a request before it is passed on to the next hop
Complete process : sending oner or more of the six response calasses after process the request.
 
Every node that partially procces the request decremnts the max-forwards header field value by one before send the request to the next hop
 
If a request is at received at a user agent /proxy that is not the final destination of the request, an explict check is run on the value of the Max-
forwards header field.
0 - request is rejected with a 483 too many hops response
none zero - it is forwarded to next hop

Cseq This header field is used to order transactions within a dialog

 
CSeq: <Sequence-Number> <Method>
the cesq number and method remain the same for each transaction in a dialog
the method matches the request for the transaction

The SIX header listed above are required for every type of sip request. However , additional header fields might also be required , depending on the type of the
SIP method [request] For example, a SIP invite requires additional header fields accompanying the six header fields to be efficiently processed by the UAS. For
example a SIP invite, the following additional header fields are required
This headers are required for invite messages and optional for other methods.
Contact This header field provides a SIP or SIPS uri at which the user agent can be contacted for subsequent requests.
For example, consider an audio call that is already established between a UAC and a UAS. Due to negotiated session policy or application
interactions, the UAS might need to send
A mid-session request to the UAC. To do so , it uses the SIP or SIPS URI indicated in the contact header field
Note that the usage of the contact header field is not restricted only to INVITE requests.this header field is also present in response to the SIP
IVNITE and other SIP methods when applicable

Allow It is recommended for the allow header field to be present within the SIP Invite.
This header field advertises the different SIP methods that can be invoked on the UAC within the scope of the dialog initiated by the SIP INViTE
request
Parsing the Allow header field allow a UAS to understand the types of requests that can be sent to the UAC during the SIP dialog.
For example , if the UAS wants to transmit dual-tone multifrequency information using the SIP info message , it can do so only iof the UAC
advertised support for the SIP info message
Is in the allow header field of the INVITE.
Allow:INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK, UPDATE,OPTIONS
Though it is recommended for UACs to include the Allow header field in INVITE requests, there might be instances when this header field isnt
included. In such cases, the UAS must not assume that UAC does not support any method; rather , it must be interpreted as the unwillingness of
the UAC to advertise what methods it supports.
The UAS can go ahead and send requests that are required to further advance the communication session. However , if the method is
unsupported by the UAC, these requests are rejected by using the 405 Method not allowed response

Supported A UAC might use this header field to enumerate the various extensions to baseline SIP that it supports
A UAS might apply these extension to baseline SIP when responding to the request, for example, if the UAC includes the timer extension in the
supported header field, it advertsies support for SIP session refresh

Accept The UAC might include the accept header field to indicate content types that are acceptable to it in responses to request or in new requests
within dialog. This header field allows user agents to advertise support for vasrious session descrption formats

Although some of the header fields listed here are optional, they are nonetheless used ubiquitously across device types and vendors for initiating
communication sessions over SIP. The Folowing
Header fields might be added in SIP INVITE requests but their exclusion does not deter the SIP session from proceeding smoothly
Optional for SIP invite messages
Require This header field enumerates extension to baseline SIP using option tags . Each option tag represents a SIP extension that the server must
support in order to process the request.
if the server cannot support a specific extension , the request is rejected with a 420 Bad extension response

Expires default 180s

This header field might be added by a UAC to limit the validity of an invitation. Once a communication session is established , this header value
has no bearing on the amount of time for which the session can last
Session- default 1800s
Expires check the session is up and established ,

MIN-SE default 1800s

   

Invite with headers Grouped [ref 4]

Request   Category

invite sip:1001@10.10.199.250:5060 SIP/2.0 Route and Transaction Related headers

via SIP/2.0/TCP 10.10.199.251:5060;branch=z9hG4bK3395a5cdb Route and Transaction Related headers

Cseq 101 INVITE Route and Transaction Related headers

     

From <sip:2002@10.10.199.251>;tag=1b1993ff-121d-4616- Identity and Dialog related headers

To <sip:1001@10.10.199.250> Identity and Dialog related headers

Call-ID 8fe4f600msmmdnaldmflmsn@10.10.199.251 Identity and Dialog related headers

P-Asseted-id <sip:2002@10.10.199.251> Identity and Dialog related headers

Remote-party-id <si:2002@10.10.199.251>;party=calling;screen=yes;privacy=offf Identity and Dialog related headers

contact <sip:2002@10.10.199.251:5060;transport=tcp> Identity and Dialog related headers

     

supported: timer,resource-priority,replaces Timer Related Headers

session-expires 1800 Timer Related Headers

MIN-SE 1800 Timer Related Headers

Expires 180 Timer Related Headers

     
Allow: invite, options, info, bye, cancel, ack, prack, update, refer, subscribe, Methods and Events
notify

Allow-Events Presence,KPML Methods and Events

     

supported: x-cisco-srtp-fallback Cisco Related Header

supported geolocation Cisco Related Header

user-agent Cisco-CUCM8.0 Cisco Related Header

cisco-guid 2414147072-3082893189-0000000002-422412766 Cisco Related Header

     

Date: Wed, 18 Feb 2015 18:37:57 GMT other headers

MAX-Forwards 70 other headers

call-info <sip:10.10.199.251:5060>;method="NOTIFY;EVENT=telephone- other headers

event;duration=500"

content-length 0 other headers

SIP Session EXPIRES and MIN0SE Headers Operation [ref 4]

During call setup – session timers and session refresh methos are negotiated and agreed on each sip trunk. Once the call is established – the session is on each
Trunk is periodically refreshed. If no session refresh or response is received , the UA send a BYE to terminate the session [ note – in CUCM 11.5 this behavior can
be overridden by the new SIP call preservation expires timer [ default = 0 sec [ call is not terminated] max value 24hrs]
SIP Message Exchange and Media Negotiation [Ref 4]
RFC 3261 Rfc 3264 [ offer /answer model]

The Offer/answer Model – SIP early Offer

The Offer/Answer Model – Sip Delayed Offer

The Offer/Answer Model – SIP Delayed Offer with Prack

Media negotiation for voice calls SDP in detail

The SDP Offer and the Answer

The SDP Offer

 The SDP Offer – Details The SDP Answer -Detaisl

The Negotiated Session

Media Negotiated for video calls

Video is fundamentally different from voice in that there are many use cases where asymmetric media flows are desirable. For example, broadband services
where the upload and download speeds are different – often by an order of magnitude. Also because encoding video is more CPU INTENSIVE than decoding
video-video endpoints can typically decode at a higher resolution than they can encode. Because of the need to support asymmetric video streams – the video
codec capabilities sent in an SDP offer and Answer should be considered to be the receive capabilities of the respective endpoints rather than the negotiated
capabilities in common with both devices

The SDP Offer and the Answer

Continued from left

SDP – OFFER SDP – ANSWER

RTCP is used for video rate adaption when congestion/packet loss encountered

Voice and video call with Desktop Sharing and FECC

Book references:
1. IMS Application Developer's Handbook
2. Cisco Voice gateways and gatekeeprs
3. Understanding Session Border controllers
4. SIP Trunk design and Deployment in Enterprise UC networks BRKUCC-2006 [ cisco live https://www.ciscolive.com/global/on-demand-library.html?
search=early
%20offer&search.event=ciscoliveus2017&search.event=ciscoliveanz2017&search.event=ciscoliveemea2017&search.event=ciscolivelatam2017&search.e
vent=ciscoliveemea2018&search.event=ciscoliveanz2018&search.event=ciscoliveus2018&search.event=ciscolivelatam2018&search.event=ciscoliveeme
a2019&search.event=ciscoliveanz2019&search.technology=scpsTechnology_collaboration&search.technology=scpsTechnology_voiceUnifiedCommunica
tion#/video/1533846608623002DG3g] [ pdf @ OneDrive\Root\000 CCIE COLLAB Exam\CCIE Colloab Written\Cisco Live Docs]
5.