Sip Messages and Call Flows

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 37

SIP MESSAGES AND Presented By :

CALL FLOWS Adhish Sharma


SIP OVERVIEW

• SIP is a signalling protocol used to create, modify, and terminate a multimedia session over the Internet Protocol. A session is nothing but a simple call between two
endpoints.
• An endpoint can be a smartphone, a laptop, or any device that can receive and send multimedia content over the Internet.
• SIP is an application layer protocol defined by IETF (Internet Engineering Task
• Force) standard. It is defined in RFC 3261.
• SIP embodies client-server architecture and the use of URL and URI from HTTP and a text encoding scheme and a header style from SMTP.
• SIP takes the help of SDP (Session Description Protocol) which describes a session and RTP (Real Time Transport Protocol) used for delivering voice and video over IP
network.
• SIP can be used for two-party (unicast) or multiparty (multicast) sessions.
• Other SIP applications include file transfer, instant messaging, video conferencing, online games, and steaming multimedia distribution.
• There are some entities that help SIP in creating its network. In SIP, every network
element is identified by a SIP URI (Uniform Resource Identifier) which is like an address.
• Following are the network elements:
• User Agent
• Proxy Server
• Registrar Server
• Redirect Server

Network •

Location Server
User Agent

Elements • It is the endpoint and one of the most important network elements of a SIP network. An
endpoint can initiate, modify, or terminate a session. User agents are the most
intelligent device or network element of a SIP network. It could be a softphone, a
mobile, or a laptop.
• User agents are logically divided into two parts:
• User Agent Client (UAC): The entity that sends a request and receives a response.
• User Agent Server (UAS): The entity that receives a request and sends a response.
• SIP is based on client-server architecture where the caller’s phone acts as a client which
initiates a call and the callee’s phone acts as a server which responds the call.
• Proxy Server
• It is the network element that takes a request from a user
agent and forwards it to another user.
• Basically the role of a proxy server is much like a router.
• It has some intelligence to understand a SIP request and send it
ahead with the help of URI.

Network • A proxy server sits in between two user agents.


• There can be a maximum of 70 proxy servers in between a
source and a destination.
Elements Cont.. • There are two types of proxy servers:
• Stateless Proxy Server: It simply forwards the message
received. This type of server does not store any information of
a call or a transaction.
• Stateful Proxy Server: This type of proxy server keeps track of
every request and response received and can use it in future if
required. It can retransmit the request, if there is no response
from the other side in time.
Network Elements
• Registrar Server
• The registrar server accepts registration requests from user agents. It helps users to authenticate themselves within
the network. It stores the URI and the location of users in a database to help other SIP servers within the same domain.
• Take a look at the following example that shows the process of a SIP Registration.
• Here the caller wants to register with the TMC domain. So it sends a REGISTER request to the TMC’s Registrar server
and the server returns a 200 OK response as it authorized the client.

• Redirect Server
• The redirect server receives requests and looks up the intended recipient of the request in the location database
created by the registrar.
• The redirect server uses the database for getting location information and responds with 3xx (Redirect response) to
the user. We will discuss response codes later in this tutorial.
• Location Server
• The location server provides information about a caller's possible locations to the redirect and proxy servers.
• Only a proxy server or a redirect server can contact a location server.
• The following figure depicts the roles played by each of the network elements in establishing a session.
SIP Messaging

• SIP messages are of two types: requests and responses.


• The opening line of a request contains a method that defines the request, and a Request-URI that defines where the request is to
be sent.
• Similarly, the opening line of a response contains a response code.
• Request Methods
• SIP requests are the codes used to establish a communication. To complement them, there are SIP responses that generally
indicate whether a request succeeded or failed.
• These SIP requests which are known as METHODS make SIP message workable.
• METHODS can be regarded as SIP requests, since they request a specific action to be taken by another user agent or server.
• METHODS are distinguished into two types:
• o Core Methods
• o Extension Methods
Core Methods
• There are six core methods as discussed below.
• INVITE
• INVITE is used to initiate a session with a user agent. In other
words, an INVITE method is used to establish a media session
between the user agents.
• INVITE can contain the media information of the caller in the
message body.
• A session is considered established if an INVITE has received a
success response(2xx) or an ACK has been sent.
• A successful INVITE request establishes 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 a re-
INVITE.
• Re-INVITE is used to change the session characteristics or
refresh the state of a dialog.
INVITE Example :

The following code shows how INVITE is used.


INVITE sips:Bob@TMC.com SIP/2.0
Via: SIP/2.0/TLS client.ANC.com:5061;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice<sips:Alice@TTP.com>;tag=1234567
To: Bob<sips:Bob@TMC.com>
Call-ID: 12345601@192.168.2.1
CSeq: 1 INVITE
Contact: <sips:Alice@client.ANC.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: ...
v=0
o=Alice 2890844526 2890844526 IN IP4 client.ANC.com
s=Session SDP
c=IN IP4 client.ANC.com
t=3034423619 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
• BYE

• BYE is the method used to terminate an established session. This is a SIP request
that can be sent by either the caller or the callee to end a session.
• It cannot be sent by a proxy server.
• BYE request normally routes end to end, bypassing the proxy server.
• BYE cannot be sent to a pending an INVITE or an unestablished session.
• REGISTER
• REGISTER request performs the registration of a user agent. This request is sent by
a user agent to a registrar server.

Core Methods • The REGISTER request may be forwarded or proxied until it reaches an
authoritative registrar of the specified domain.
• It carries the AOR (Address of Record) in the To header of the user that is being
Contd.. •
registered.
REGISTER request contains the time period (3600sec).
• One user agent can send a REGISTER request on behalf of another user agent. This
is known as third-party registration. Here, the From tag contains the URI of the
party submitting the registration on behalf of the party identified in the To header.
• CANCEL
• CANCEL is used to terminate a session which is not established. User agents use
this request to cancel a pending call attempt initiated earlier. It can be sent either
by a user agent or a proxy server.
• CANCEL is a hop by hop request, i.e., it goes through the elements between the
user agent and receives the response generated by the next stateful element.
Core Methods Cntd..

• ACK
• ACK is used to acknowledge the final responses to an INVITE method. An ACK always
goes
• in the direction of INVITE.ACK may contain SDP body (media characteristics), if it is not
• available in INVITE.
• ACK may not be used to modify the media description that has already been sent in the
initial INVITE.
• A stateful proxy receiving an ACK must determine whether or not the ACK should be
forwarded downstream to another proxy or user agent.
• For 2xx responses, ACK is end to end, but for all other final responses, it works on hop by
hop basis when stateful proxies are involved.
• OPTIONS
• OPTIONS method is used to query a user agent or a proxy server about its capabilities
and discover its current availability. The response to a request lists the capabilities of the
user agent or server. A proxy never generates an OPTIONS request.
Extension Methods
• Subscribe
• SUBSCRIBE is used by user agents to establish a
subscription for the purpose of getting notification
about a particular event.
• It contains an Expires header field that indicates the
duration of a subscription.
• After the time period passes, the subscription will
automatically terminate.
• Subscription establishes a dialog between the user
agents.
• You can re-subscription again by sending another
SUBSCRIBE within the dialog before the expiration
time.
• A 200 OK will be received for a subscription from User.
• Users can unsubscribe by sending another SUBSCRIBE
method with Expires value 0(zero).
Extension Methods
Contd..
• NOTIFY
• NOTIFY is used by user agents to get the occurrence of a particular event. Usually a NOTIFY will
trigger within a dialog when a subscription exists between the subscriber and the notifier.
• Every NOTIFY will get 200 OK response if it is received by notifier.
• NOTIFY contain an Event header field indicating the event and a subscriptionstate header field
indicating the current state of the subscription.
• A NOTIFY is always sent at the start and termination of a subscription.
• PUBLISH
• PUBLISH is used by a user agent to send event state 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.
Extension Methods
• REFER
Contd..
• REFER is used by a user agent to refer another user agent to access a URI for the dialog.

• REFER must contain a Refer-To header. This is a 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 has accepted the reference.

• INFO

• INFO is used by a user agent to send call signalling information to another user agent with which it has established a media
session.

• This is an end-to-end request.

• UPDATE

• A proxy will always forward an INFO request. UPDATE

• UPDATE is used to modify the state of a session if a session is not established. User could change the codec with UPDATE.

• IF a session is established, a re-Invite is used to change/update the session.

• PRACK

• PRACK is used to acknowledge the receipt of a reliable transfer of provisional response (1XX).

• Generally PRACK is generated by a client when it receive a provisional response containing an RSeq reliable sequence
number and a supported:100rel header.

• PRACK contains (RSeq + CSeq) value in the rack header.

• The PRACK method applies to all provisional responses except the 100 Trying response, which is never reliably
transported.

• A PRACK may contain a message body; it may be used for offer/answer exchange.
Message
• MESSAGE
• It is used to send an instant message using SIP. An
IM usually consists of short messages exchanged in
real time by participants engaged in text
conversation.
• MESSAGE can be sent within a dialog or outside a
dialog.
• The contents of a MESSAGE are carried in the
message body as a MIME attachment.
• A 200 OK response is normally received to indicate
that the message has been delivered at its
destination.
Response Codes
• A SIP response is a message generated by a user agent server (UAS) or SIP server to reply a
request generated by a client. It could be a formal acknowledgement to prevent retransmission of
requests by a UAC.
• A response may contain some additional header fields of info needed by a UAC.
• SIP has six responses.
• 1xx to 5xx has been borrowed from HTTP and 6xx is introduced in SIP.
• 1xx is considered as a provisional response and the rest are final responses.
• 1. 1xx: Provisional/Informational Responses
• 2. 2xx: Success Responses
• 3. 3xx: Redirect Responses
• 4. 4xx: Client Failure Responses
• 5. 5xx: Server Failure Responses
• 6. 6xx: Global Failure Responses
Informational (1XX)
• Informational (1xx)

• Informational responses are used to indicate call progress. Normally the responses are end to end (except 100 Trying). The main objective of informational responses is to stop retransmission of INVITE
requests.

• Informational responses include the following responses:

• 100 Trying

• This special case response is only a hop-by-hop request.

• It is never forwarded and may not contain a message body.

• It is used to avoid the retransmission of INVITE requests.

• 180 Ringing

• This response is used to indicate that an INVITE has been received by the user agent and alerting is taking place.

• 181 Call is Being Forwarded

• This response is used to indicate that the call has been forwarded to another endpoint.

• It gives the status of the caller, as a forwarding operation may result in the calltaking longer to be answered.

• 182 Call Queued

• This response is used to indicate that the INVITE has been received and will be processed in a queue.

• 183 Session Progress

• It indicates that information about the progress of a session may be present in a message body or media stream.

• Unlike a 100 Trying response, a 183 is an end-to-end response. It establishes early dialog.

• A typical use of this response is to allow a UAC to hear a ringtone recorded announcement in calls through a gateway into the PSTN.
Success(2XX)
• This class of responses is meant for indicating that a request has been
accepted. It includes the following responses:
• 200 OK :
• 200 OK is used to accept a session invitation.
• It indicates a successful receipt of a request.
• 202 Accepted
• 202 Accepted indicates that the UAS has received and understood the
request, but that the request may not have been authorized or processed
by the server.
• It is commonly used in responses to SUBSCRIBE, REFER methods
Redirection (3xx)
• Redirection (3xx)
• Generally these class responses are sent by redirect servers in response to INVITE. They are also known as redirect class
responses. It includes the following responses:
• 300 Multiple Choices :
• It contains multiple Contact header fields to indicate that the location service has returned multiple possible locations for the SIP
URI in the Request-URI.
• 301 Moved Permanently
• This redirection response contains a Contact header field with the new URI of the called party.
• The address can be saved and used in future INVITE requests.
• 302 Moved Temporarily
• This redirection response contains a URI that is currently valid but is not permanent.
• That is, for the specified duration of time the location is valid.
• 305 Use Proxy
• This response points to certain proxy server which is having some authoritative information about the calling party.
• This response could be sent by a UAS issuing a proxy for incoming call screening.
• 380 Alternative Service
• This response returns a URI that indicates the type of service the called party would like.
• For example, a call could be redirected to a voicemail server.
Client Error(4XX)
• Client error responses indicate that the request cannot be fulfilled as some errors are identified from the UAC side. The response codes are
generally sent by UAS. Upon receiving an error message, the client should resend the request by modifying it based on the response. Discussed
below are some of the important client error responses.
• 400 Bad Request
• This indicates that the server could not understood the request.
• Request might be missing required header fields such as To, From, Call-ID, or CSeq.
• 401 Unauthorized
• It indicates that the request need to perform authentication.
• 401 Unauthorized is normally sent by a registrar server for REGISTER request.
• The response contains WWW-Authenticate header field which requests for correct credentials from the calling user agent.
• A subsequent REGISTER will trigger from the User Agent with correct credentials.
• 402 Payment Required
• It indicates payment is required for further processing of request.
• 403 Forbidden
• 403 Forbidden is sent when the server has understood the request, found the request to be correctly formulated, but will not service the request.
• This response is not used when authorization is required.
• 404 Not Found
• It indicates that server has not found the indicated SIP URI by the User.
Server Failure (5xx)
• This class response is used to indicate that the request cannot be processed because of an error with the server. The server failed to fulfil an apparently
valid request. The response may contain a Retry-After header field. The request can be tried at other locations because there are no errors indicated in
the request. Some of the important server failure responses are discussed below.
• 500 Server Internal Error
• 500 indicates that the server has experienced some kind of error that is preventing it from processing the request.
• It is one kind of server failure that indicates the client to retry the request again at this server after several seconds.
• 501 Not Implemented
• It indicates that the server is unable to process the request because it is not supported.
• This response can be used to decline a request containing an unknown method.
• 502 Bad Gateway
• This response is sent by a proxy that is acting as a gateway to another network.
• It indicates some problem in the other network is preventing the request from being processed.
• 503 Service Unavailable
• This response indicates that the requested service is temporarily unavailable at that time.
• The request can be retried after a few seconds, or after the expiration of the Retry-After header field.
• 504 Gateway Timeout
• This response comes when the request failed due to a timeout occurred in the other network to which the gateway connects.
• It is a server error class response because the call is failing due to a failure of the server in accessing resources outside the SIP network.
Global Error (6xx)
• This response class indicates that the server knows that the request will fail wherever it is tried. As a result, the request
should not be sent to other locations. Only a server having definitive knowledge of the user identified by the Request-URI
in every possible instance should send a global error class response. Otherwise, a client error class response should be
sent. A Retry-After header field can be used to indicate when the request might be successful. Some of the important
responses are discussed below:
• 600 Busy Everywhere
• This response indicates that the call to the specified Request-URI could be answered in other locations.
• 603 Decline
• This response could indicate the called party is busy, or simply does not want to accept the call.
• 604 Does Not Exist Anywhere
• This response is similar to the 404 Not Found response but indicates that the user in the Request-URI cannot be found
anywhere.
• This response should only be sent by a server having access to all the information about the user.
• 606 Not Acceptable
• This response indicates that some aspect of the desired session is not acceptable to the UAS, and as a result, the session
cannot be established.
• The response may contain a Warning header field with a numerical code describing exactly what was not acceptable.
• The request can be retried with different media session information.
SIP Headers

• A header is a component of a SIP message


that conveys information about the
message. It is structured as a sequence of
header fields. SIP header fields in most
cases follow the same rules as HTTP header
fields. Header fieldsare defined as Header:
field, where Header is used to represent the
header field name, and field is the set of
tokens that contains the information. Each
field consists of a fieldnamefollowed by a
colon (":") and the field-value (i.e., field-
name: field-value).
SIP Header Format
SIP Header Categorization
• Headers are categorized as follows depending on their usage in SIP:
• Request and Response
• Request Only
• Response Only
• Message Body
• Request and Response Header Fields :
• Accept
• The Accept header field is used to indicate acceptable message Internet media types in the message body.
• The header field describes media types using the format type/sub-type commonly used in the Internet.
• If not present, the assumed acceptable message body format is application/sdp.
• A list of media types can have preferences set using q value parameters.
• Accept-Encoding
• The Accept-Encoding header field is used to specify acceptable message body encoding schemes.
• Encoding can be used to ensure a SIP message with a large message body fits inside a single UDP datagram.
• The use of q value parameters can set preferences. If none of the listed schemes are acceptable to the UAC, a 406 Not Acceptable response is returned. If not included, the assumed
encoding will be text/plain.
• To
• To indicates the final recipient of the request. Any response generated by a UA will contain this header field with the addition of a tag. It is a mandatory header.
• Any response generated by a proxy must have a tag added to the To header field.
• The To header field URI is never used for routing.
Request and Response Header Contd…
• Contact :-
• The Contact header field is used to convey the other user about the address of the request originator. Once a Contact header field has been received, the URI can be
cached and used for routing future requests within a dialog.
• For example, a Contact header field in a 200 OK response to an INVITE can allow the acknowledgment ACK message and all future requests during this call to bypass
proxies and go directly to the called party.
• Record-Route :-
• The Record-Route header field is used to force routing through a proxy for all subsequent requests in a session (dialog) between two UAs.
• Normally, the presence of a Contact header field allows UAs to send messages directly bypassing the proxy chain used in the initial request.
• A proxy inserting its address into a Record-Route header field overrides this and forces future requests to include a Route header field containing the address of the
proxy that forces this proxy to be included.
• A proxy wishing to implement this inserts the header field containing its own URI, or adds its URI to an already present Record-Route header field.
• The URI is constructed so that the URI resolves back to the proxy server. The UAS copies the Record-Route header field into the 200 OK response to the request.
• The header field is forwarded unchanged by proxies back to the UAC. The UAC then stores the Record-Route proxy list plus a Contact header field if present in the200 OK
for use in a Route header field in all subsequent requests.
• Organization :-
• The Organization header field is used to indicate the organization to which the originator of the message belongs.
• It can also be inserted by proxies as a message is passed from one organization to another.
• Like all SIP header fields, it can be used by proxies for making routing decisions and by UAs for making call screening decisions.
• Retry-After :-
• It is used to indicate when a resource or service may be available again.
• In 503 Service Unavailable responses, it indicates when the server will be available.
• In 404 Not Found, 600 Busy Everywhere, and 603 Decline responses, it indicates when the called UA may be available again. It contains time period in ‘sec’.
SDP
• SDP stands for Session Description Protocol. It is used to describe multimedia sessions in a format understood by the participants over a network. Depending on
this description, a party decides whether to join a conference or when or how to join a conference.
• The owner of a conference advertises it over the network by sending multicast messages which contain description of the session e.g. the name of the owner,
the name of the session, the coding, the timing etc. Depending on these information, the recipients of the advertisement take a decision about participation in
the session.
• SDP is generally contained in the body part of Session Initiation Protocol popularly called SIP.
• SDP is defined in RFC 2327. An SDP message is composed of a series of lines, called fields, whose names are abbreviated by a single lower-case letter, and are in
a required order to simplify parsing
• Purpose of SDP :-
• The purpose of SDP is to convey information about media streams in multimedia sessions to help participants join or gather info of a particular session.
• SDP is a short structured textual description.
• It conveys the name and purpose of the session, the media, protocols, codec formats, timing and transport information.
• A tentative participant checks these information and decides whether to join a session and how and when to join a session if it decides to do so.
• The format has entries in the form of <type>= <value>, where the <type>defines a unique session parameter and the <value>provides a specific value for that
parameter.
• The general form of a SDP message is:
• x=parameter1 parameter2 ... parameterN
• The line begins with a single lower-case letter, for example, x. There are neverany spaces between the letter and the =, and there is exactly one space between
each parameter. Each field has a defined number of parameters.
Session Description Parameters
• Session description (* denotes optional)
• v= (protocol version)
• o= (owner/creator and session identifier)
• s= (session name)
• i=* (session information)
• u=* (URI of description)
• e=* (email address)
• p=* (phone number)
• c=* (connection information -not required if included in all media)
• b=* (bandwidth information)
• z=* (time zone adjustments)
• k=* (encryption key)
• a=* (zero or more session attribute lines)
SIP BASIC CALL FLOW
Call Flow Of Call Hold
Precall mobility using SIP REGISTER
Midcall mobility using INVITE with Replaces
Call FLOW In case of Parallel Forking
Call Flow In case of Sequential Forking
Call Forward No Answer Call Flow
SIP to PSTN Call Flow

You might also like