SIP (Session Initiation Protocol) (RFC3261)

1
SIP(Session Initiation Protocol) (RFC3261)

SIP is an application layer protocol used to create, control & modify and terminate the multimedia
session over the internet protocol.
 Used in VoIP Technology.

 Takes help of SDP and RTP.
VoIP (Voice over Internet Protocol) ->VoIP is a technology that allow you to share voice and
multimedia session over the internet.
 Low cost.
 No extra cable.
 Flexibility.
 Video Conferencing.
SIP Applications
 Voice Call.
 Video Call.
 File transfer.
 Instant messaging.
 Video Conferencing.
 Online Games.
SIP Network Elements

 User Agent.
 Proxy Server.
 Registrar Server.
 Location Server.
 Redirect Server.
User Agent-These are the end points of SIP network. They can create, modify and terminate a
session. These are most intelligent element of SIP network.
UAC(User agent client): - It sends request and receives response.
UAS (User agent server): - It receives request and sends response.
Proxy Server- Proxy servers are nothing but just a request forwarder. They receive messages from
one UA and forwards it to another HOP. They act like a router. There are two types of proxy server.
Stateless proxy server: - It simply forwards a message as it receives. It does not any information of call or
transaction. It cannot do retransmission.
Stateful proxy server: - This type of proxy server keeps the track of every request and response received and
can use it in future if required. It can retransmit the request. It can perform call forwarding and forking type
services.
Registrar Server- It stores the information of the URI and location of the user in a database.
Redirect Server- The redirect server uses the database for location information of user and
respond with 3xx response to a user.
info@reversosolutions.com www.reversosolutions.com +91-9620020759

2
Location Server – It provides the location of a user that where it is, to proxy server and
redirect server.
SIP Architecture: -
Transaction User: -Each SIP entity except stateless proxy is
transaction user.
Transaction Layer: - Transaction layer take care of

transaction between the SIP elements. Any transaction
cannot be open loop. It should be closed. Stateless proxy do
not contain transaction layer.
Transport Layer: - It defines how a client sends request and

receives the response. And a server receives the request and
sends response. All SIP elements contain transport layer.
Syntax and Encoding: - It is the lowest layer of SIP messages.

It tells how SIP messages are encrypted.
SIP TRAPEZOID
SIP REQUEST METHODS

Core Method Extension Method
INVITE SUBSCRIBE
ACK NOTIFY
CANCEL PUBLISH
BYE REFER
REGISTER INFO
OPTION UPDATE
PRACK
MESSAGE

3
SIP RESPONSES
PROVISIONAL RESPONSES FINAL RESPONSES
1XX (Informational Response) 2XX (Successful Response)
3XX (Redirection Response)
4XX (Request Failure Response)
5XX (Service Failure Response)
6xx (Global Failure Response)
INVITE and RE-INVITE:

 A Successful INVITE Request established a Dialog between two user agents.
 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 Dialog.
BYE & CANCEL:

 BYE is used to terminate an established session
 CANCEL is used to terminate a session which is not established.
 BYE can’t be sent by proxy server but CANCEL can be.
OPTION:
 It is used to query a user agent or a proxy server about its capability.
 A proxy never generates an OPTION request.
SUBSCRIBE:
 It is used to get notification for any events
 It established a Dialog between the user agents.
 You can take re subscription again by sending another SUBSCRIBE within the Dialog before
the expiration time.
NOTIFY:
 It is used for the notification for any events.
 It will occur within a Dialog when subscription exist.
 Contain event Header.
 Always sent at start and termination of a subscription.
REFER:
 A user agent refers another user agent to access a URI for the Dialog.
 It must contain “refer-to” header.
 It can be sent inside or outside Dialog.
 202 ACCEPT is response for this request.
UPDATE:
 It can be use before and after both the time of session. But RE-INVITE can be use only after
the session established.
 UPDATE is used to change and modify a session.
PRACK:
 PRACK is used to acknowledge that 1XX response is received successfully (except 100 trying).

4
 Generally, PRACK is generated by the client when it will receive R-Seq (Reliable sequence
number) and supported 100 Rel in response.
 PRACK contain C-Seq and R-Seq in Rack Header.
INFO:
 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.
PUBLISH:
 PUBLISH is used by a user agent to send event state information to a server.
 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.
MESSAGE:
 It is used for instant messaging in SIP.
 It can be sent within a Dialog and outside the Dialog.
 Content is carried as MIME attachments.
 Response will be 200 OK for it.
1XX RESPONSES:
100 Trying: - Next Hop received the request and its taking unspecified action.
180 Ringing: - Called party is being alerted to indicate an incoming call.
181 Call is being forwarded: - A server on the path forwarded the call.
182 Queed: -Called Party is temporarily unavailable, call is not rejected, it’s in que and will receive a
final response.
183 Session in progress: - Call is in progress with no order details.
2XX RESPONES:

5
200 OK: - The request was successful.

202 Accepted: - The requested is accepted.
3XX REDIRECTION:
301 Moved Permanently: -Called party can no longer be reached at the request URI. Caller should
try again using the URI in the contact header field. New URI should be cached and used in future
requests.
302 Moved Temporarily: - Called Party at the moment, cannot be reached at the request URI. Caller
should try again using the URI in the contact header field. New URI must be cached. The Expires
header field could indicate how long this temporarily URI is valid.
305 Use Proxy: - Caller may receive this response from the called party, if the called party requires
the caller to go through a proxy. Caller should send new request to URI in contact header field,
which points to a proxy.
380 Alternative Services: -Call was not successful, caller could use another medium. Alternative
medium would be defined in the message-body of response.
4XX Client Error:
400 Bad Request: - Syntax of the request is incorrect. Request missing a required piece of data or
malformed.
401 Unauthorized: - Caller is required to authenticate with server, not done it yet or provided wrong
authentication. 401 Unauthorized is from a UAS or a registrar, 407 Proxy Authentication required is
from a SIP Proxy. UAC should retry with proper credentials.
402 Payment Required: - Call cannot be completed until payment is made.
403 Forbidden: - Server is understood the request but it is not going to allow it.
404 Not Found: - Server cannot locate the called party. Server does not claim it was able to locate
the called party in the past and this is permanent situation.
405 Method not Allowed: Request is understood but not allowed.
406 Not Acceptable: - UAC sent request with accept that lists content type the UAC understand
none of them.
408 Request time out: - UAS Could not provide response until expires has passed. UAC can retry the
same request.
413 Entity too large: - Request message body too large for the server.
414 Request URI too long: - Server is not going to accept the URI longer than it allows.
415 Unsupported media type: - Server does not support the format used in the message body.
Response must include ACCEPT to let UAC know what server supports.
480 Temporarily Unavailable
483 Too Many Hops: - max forward was zero.
486 User Busy: - Request was delivered to called party, called party is not able to take additional
calls at the moment.
487 Request Terminated: - Request being processed has been terminated by CANCEL.
488 Not Acceptable: - Specific destination resource/end point does not accept the session proposal.
5XX SERVER ERROR:

6
500 Internal Error

501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Server Time Out
505 Version not Supported
513 Message too Large
6XX GLOBAL FAILURE:
600 Busy Everywhere

603 Decline
604 Does Not Exist
606 Not Acceptable
SIP Headers
A valid SIP request formulated by a UAC must, at a minimum, contain the following header fields: To,
From, CSeq, Call-ID, Max-Forwards, and Via; all of these header fields are mandatory in all SIP
requests.
Each header field consists of a field name followed by a colon (":") and the field value.
field-name: field-value
These header fields are in addition to the mandatory request line, which contains the method,
Request-URI, and SIP version.
6 Mandatory Headers:
TO: Logical address of Callee. or the address-of-record of the user or resource that is the target of
this request.
FROM: The From header field indicates the logical identity of the initiator of the request, possibly
the user’s address-of-record.
CALL ID: The Call-ID header field acts as a unique identifier to group together a series of messages. It
MUST be the same for all requests and responses sent by either UA in a Dialog. It should be the
same in each registration from a UA.

7
C-SEQUENCE: The CSeq header field serves as a way to identify and order transactions. It consists of
a sequence number and a method. The method must match that of the request. For non-REGISTER
requests outside of a Dialog, the sequence number value is arbitrary.
MAX-FORWARD: The Max-Forwards header field serves to limit the number of hops a request can
transit on the way to its destination. It consists of an integer that is decremented by one at each
hop. If the Max-Forwards value reaches 0 before the request reaches its destination, it will be
rejected with a 483(Too Many Hops) error response.
A UAC must insert a Max-Forwards header field into each request it originates with a value that
should be 70.
VIA: Via is once own address where the response has to be receive Or The Via header field indicates
the transport used for the transaction and identifies the location where the response is to be sent.
The Via header field value MUST contain a branch parameter. This parameter is used to identify the
transaction created by that request. This parameter is used by both the client and the server.
The branch parameter value MUST be unique across space and time for all requests sent by the UA.
The exceptions to this rule are CANCEL and ACK for non-2xx responses. a CANCEL request will have
the same value of the branch parameter as the request it cancels.
An ACK for a non-2xx response will also have the same branch ID as the INVITE whose response it
acknowledges. The uniqueness property of the branch ID parameter, to facilitate its use as a
transaction ID.
The branch ID inserted by an element compliant with this specification MUST always begin with the
characters "z9hG4bK". These 7 characters are used as a magic cookie.
A Via header field value contains the transport protocol used to send the message, the client’s host
name or network address, and possibly the port number at which it wishes to receive responses.
OPTIONAL HEADERS
CONTACT: The Contact header field provides a SIP or SIPS URI that can be used to contact that
specific instance of the UA for subsequent requests. The Contact header field MUST be present and
contain exactly one SIP or SIPS URI in any request that can result in the establishment of a
Dialog.
If the Request-URI or top Route header field value contains a SIPS URI, the Contact header field must
contain a SIPS URI as well.
ROUTE: The Route header field is used to force routing for a request through the listed set of
proxies.
RECORD-ROUTE:The Record-Route header field is inserted by proxies in a request to force future

requests in the Dialog to be routed through the proxy.
*NOTE: TO UNTERSTAND ROUTE AND RECORD ROUTE PLEASE REFER SECTION 16.12.1 PAGE 118 IN
RFC3261.
PROXY AUTHENTICATE: A proxy authenticate header field value contains an authentication

challenge.
Example:
Proxy-Authenticate: Digest realm="atlanta.com",
domain="sip:ss1.carrier.com", qop="auth",
nonce="f84f1cec41e6cbe5aea9c8e88d359",
opaque="", stale=FALSE, algorithm=MD5

8
PROXY AUTHORIZATION: The Proxy-Authorization header field allows the client to identify itself (or
its user) to a proxy that requires authentication. A Proxy-Authorization field value consists of
credentials containing the authentication information of the user agent for the proxy and/or realm
of the resource being requested.
Example:
Proxy-Authorization: Digest username="Alice", realm="atlanta.com",
nonce="c60f3082ee1212b402a21831ae",
response="245f23415f11432b3434341c022"
REQUIRE: The Require header field is used by UACs to tell UASs about options that the UAC expects
the UAS to support in order to process the request. Although an optional header field, the Require
must not be ignored if it is present.
The Require header field contains a list of option tags. Each option tag defines a SIP extension that
must be understood to process the request. Frequently, this is used to indicate that a specific set of
extension header fields need to be understood.
Example:
Require: 100rel
SUPPORTED: The Supported header field enumerates all the extensions supported by the UAC or
UAS.
The Supported header field contains a list of option tags that are understood by the UAC or UAS. A
UA compliant to this specification must only include option tags corresponding to standards-track
RFCs. If empty, it means that no extensions are supported.
Example:
Supported: 100rel
WARNING: The Warning header field is used to carry additional information about the status of a
response. Warning header field values are sent with responses and contain a three-digit warning
code, host name, and warning text.
Examples:
Warning: 307 isi.edu "Session parameter ’foo’ not understood"
Warning: 301 isi.edu "Incompatible network address type ’E.164’"
WWW-AUTHENTICATE: A WWW-Authenticate header field value contains an authentication

challenge.
Example:
WWW-Authenticate: Digest realm="atlanta.com",
domain="sip:boxesbybob.com", qop="auth",
nonce="f84f1cec41e6cbe5aea9c8e88d359",
opaque="", stale=FALSE, algorithm=MD5
EXPIRES: The Expires header field gives the relative time after which the message (or content)
expires. The expiration time in an INVITE does not affect the duration of the actual session that may
result from the invitation. Session description protocols may offer the ability to express time limits
on the session duration, however. The value of this field is an integral number of seconds (in
decimal) between 0 and (2**32)-1, measured from the receipt of the request.
Example:
Expires: 5
SDP (Session description Protocol)

9
SDP is used to describe a multimedia session in a format understood by participants over a network.
It is based on OFFER/ANSWER Model. The use of SDP with SIP is given in the SDP offer answer
RFC3264. The default message body type is Application/SDP.
The calling party list their multimedia capabilities that they are willing to receive in SDP usually in
INVITE or in an ACK. The called party list their multimedia capabilities in 200OK response to the
INVITE.
SDP includes Version, Origin, Session Name, Connection Data, time, media line and attribute line.
An example SDP description is:

v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=
c=IN IP4 client.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Protocol Version
v=0
The "v=" field gives the version of the Session Description Protocol. There is no minor version
number.
Origin
o=<username><session id><version><network type><address type <address>
The "o=" field gives the originator of the session (their username and the address of the user's
host) plus a session id and session version number.
<username> is the user's login on the originating host, or it is "-"if the originating host does not
support the concept of user ids.<username> must not contain spaces.
<session id> is a numeric string such that the tuple of <username>, <session id>, <network
type>,<address type> and <address> form a globally unique identifier for the session. The method of
<session id> allocation is up to the creating tool, but it has been suggested that a Network Time
Protocol (NTP) timestamp be used to ensure uniqueness [1].
<version> is a version number for this announcement. It is needed for proxy announcements to
detect which of several announcements for the same session is the most recent. Again its usage is
up to the creating tool, so long as <version> is increased when a modification is made to the session
data. Again, it is recommended (but not mandatory) that an NTP timestamp is used.
<network type> is a text string giving the type of network. Initially "IN" is defined to have the
meaning "Internet".
<addresstype> is a text string giving the type of the address that follows. Initially "IP4" and "IP6" are
defined.
<address> is the globally unique address of the machine from which the session was created. For an
address type of IP4, this is either the fully-qualified domain name of the machine, or the dotted-
decimal representation of the IP version 4 address of the machine. For an address type of IP6, this is
either the fully-qualified domain name of the machine, or the compressed textual representation of
the IP version 6 address of the machine. For both IP4 and IP6, the fully-qualified domain name is the
form that SHOULD be given unless this is unavailable, in which case the globally unique address may

10
be substituted. A local IP address MUST NOT be used in any context where the SDP description
might leave the scope in which the address is meaningful.
In general, the "o=" field serves as a globally unique identifier for this version of this session
description, and the subfields excepting the version taken together identify the session irrespective
of any modifications.
Connection Data
c=<network type><address type><connection address>
The "c=" field contains connection data.

Typically, the connection address will be a class-D IP multicast group address. If the session is not
multicast, then the connection address contains the fully-qualified domain name or the unicast IP
address of the expected data source or data relay or data sink as determined by additional attribute
fields.
Times, Repeat Times and Time Zones
t=<start time><stop time>
"t=" fields specify the start and stop times for a conference session. Multiple "t=" fields may be used
if a session is active at multiple irregularly spaced times; each additional "t=" field specifies an
additional period of time for which the session will be active. If the session is active at regular times,
an "r=" field (see below) should be used in addition to and following a "t=" field - in which case the
"t=" field specifies the start and stop times of the repeat sequence.
r=<repeat interval><active duration><list of offsets from start-time>
"r=" fields specify repeat times for a session. For example, ifa session is active at 10am on Monday
and 11am on Tuesday for one hour each week for three months, then the <start time> in the
corresponding "t=" field would be the NTP representation of 10am on the first Monday, the <repeat
interval> would be 1 week, the<active duration> would be 1 hour, and the offsets would be zero and
25 hours. The corresponding "t=" field stop time would be the NTP representation of the end of the
last session three months later. By default, all fields are in seconds, so the "r=" and "t="fields might
be:
Example:
t=3034423619 3042462419
r=604800 3600 0 90000
Media Line:
m=<media><port><transport><fmt list>
A session description may contain a number of media descriptions. Each media description starts
with an "m=" field, and is terminated by either the next "m=" field or by the end of the session
description.
A media field also has several sub-fields:

11
<media>The first sub-field is the media type. Currently defined media are “audio", "video",
"application", "data" and "control", though this list may be extended as new communication
modalities emerge (e.g., telepresense).
<port>The second sub-field is the transport port to which the media stream will be sent. The
meaning of the transport port depends on the network being used as specified in the relevant "c"
field and on the transport protocol defined in the third sub-field. Other ports used by the media
application should be derived algorithmically from the base media port.
*Note: For transports based on UDP, the value should be in the range 1024 to 65535 inclusive. For
RTP compliance it should be an even number.
<transport>The third sub-field is the transport protocol. The transport protocol values are
dependent on the address-type field in the "c=" fields. Thus a "c=" field of IP4 defines that the
transport protocol runs over IP4. For IP4, it is normally expected that most media traffic will be
carried as RTP over UDP.
<fmt list>The fourth and subsequent sub-fields are media formats. For audio and video, these will
normally be a media payload type as defined in the RTP Audio/Video Profile.
For media whose transport protocol is not RTP or UDP the format field is protocol specific. Such
formats should be defined in an additional specification document.
For media whose transport protocol is RTP, SDP can be used to provide a dynamic binding of media
encoding to RTP payload type. The encoding names in the RTP AV Profile do not specify unique audio
encodings (in terms of clock rate and number of audio channels), and so they are not used directly in
SDP format fields. Instead, the payload type number should be used to specify the format for static
payload types and the payload type number along with additional encoding information should be
used for dynamically allocated payload types.
An example of a static payload type is u-law PCM coded single channel audio sampled at
8KHz. This is completely defined in the RTP Audio/Video profile as payload type 0, so the media field
for such a stream sent to UDP port 49232 is
m=video 49232 RTP/AVP 0
An example of a dynamic payload type is 16-bit linear encoded stereo audio sampled at
16KHz. If we wish to use dynamic RTP/AVP payload type 98 for such a stream, additional
information is required to decode it:
Attribute Line:
a=rtpmap:<payload type><encoding name>/<clock rate>[/<encodingparameters>]
RTP formats that are not registered as standard format names mustbe preceded by "X-". Thus a new
experimental redundant audio stream called GSMLPC using dynamic payload type 99 could be
specified as:
a=rtpmap:99 X-GSMLPC/8000
Such an experimental encoding requires that any site wishing to receive the media stream
has relevant configured state in its session directory to know which tools are appropriate. Note that

12
RTP audio formats typically do not include information about the number of samples per packet. If a
non-default packetization is required, the "ptime" attribute is used.
Suggested Attributes
The following attributes are suggested. Since application writers may add new attributes
as they are required, this list is not exhaustive.
a=ptime:<packet time>
This gives the length of time in milliseconds represented by the media in a packet. This is
probably only meaningful for audio data. It should not be necessary to know ptime to decode RTP or
vat audio, and it is intended as a recommendation for the encoding/packetization of audio. It is a
media attribute, and is not dependent on charset.
a=recvonly
This specifies that the tools should be started in receive-only mode where applicable. It can be
either a session or media attribute, and is not dependent on charset.
a=sendrecv
This specifies that the tools should be started in send and receive mode. This is necessary for
interactive conferences with tools such as wb which defaults to receive only mode. It can be either a
session or media attribute, and is not dependent on charset.
a=sendonly
This specifies that the tools should be started in send-only mode. An example may be where a
different unicast address is to be used for a traffic destination than for a traffic source. In such a case,
two media descriptions may be use, one sendonly and one recvonly. It can be either a session or
media attribute but would normally only be used as a media attribute, and is not dependent on
charset.
a=fmtp:<format><format specific parameters>

This attribute allows parameters that are specific to a particular format to be conveyed in a way
that SDP doesn't haveto understand them. The format must be one of the formats specified for the
media. Format-specific parameters may be any set of parameters required to be conveyed by SDP
and given unchanged to the media tool that will use this format.
------------------------------------------------------------------------------------------------------------------------------------
TRANSACTION:RFC3261/SEC17/ page122
A SIP transaction consists of a single request and any response to that request which includes zeso or
more provisional responses. And one or more final responses.
Transaction also includes the ACK only if the final response was not a 2XX response. If
response was a 2XX the ACK is not considered part of the transaction. This ACK would be a different
transaction.
(*Important Point: - When the UAC receives 200OK, the client transaction is destroyed at
transaction layer. This is done because, transaction layer is unaware of the above core. The above
core can be a proxy or or an UAC core.

13
In case of proxy, 200OK is forwarded whereas in case of UAC, an ACK is generated. Now
this ACK has to create a new transaction (transaction created by INVITE had been destroyed) at
transaction layer for its transmission, hence the ACK for 200 OK is outside the INVITE transaction.
For other non-2XX final response, the client transaction at transaction layer is not
destroyed and the ACK is generated by transaction layer. Hence in this case the ACK is within the
transaction.)
DIALOG:RFC3261/SEC12/ page69
When a UAC sends a request, the request passes through some number of proxy servers, which
forward the request towards the UAS. When the UAS generates a response, the response is
forwarded towards the UAC. UAC and UAS procedures depend strongly on two factors. First, based
on whether the request or response is inside or outside of a Dialog, and second, based on the
method of a request.
A Dialogrepresents a peer-to-peer SIP relationship between two user agents. A Dialog is
identified at each UA with a Dialog ID, which consists of a Call-ID , a From tag and a To tag.
Dialog = Call ID+TO Tag + From Tag
Means If we have all these 3 musketeers (To-TAG, From-TAG and Call-ID) while getting a request, Its
Inside of the Dialog else its Outside of the Dialog.
Very good, you learn so quickly. But What is a early Dialog state? A Dialog established by a
non-final response to a request is in the early state and it is called early Dialog state. The early Dialog
will be needed if the UAC needs to send a request to its peer within the Dialog before the initial
INVITE transaction completes. Header fields present in a provisional response are applicable as long
as the Dialog is in the early state (for example, an Allow header field in a provisional response
contains the methods that can be used in the Dialog while this is in the early state).
Means before INVITE transaction completes you can send any request other than new
INVITE request. When our favorite guy, Alice & Bob, Alice send a INVITE Request to Bob, for Bob the
INVITE Request is outside of the Dialog.
When Alice receives 180 response, its early Dialog state for Alice and this goes to confirmed
state after 200 OK response.
After receiving 200 OK Response, any request will be inside the Dialog.
SESSION:
A session is just a media stream (e.g. audio or video) flowing between peers, usually consisting of
RTP (and possibly RTCP) packets. For example, if SIP is used to make a voice call, the session is the
voice data that is sent between endpoints.
STRICT ROUTING:
In strict routing the request URI always keep changing hop by hop according to the route set
so the request is sent to the address mentioned in request URI
LOOSE ROUTING:
In Loose routing the request URI does not change. It always contains the address of
destination (final UA). But if route set is present in the message, then message will be forwarded to
top most URI mentioned in the route set but still request URI will remains same.
CODECS

14
G711: (U): PCMU

(A): PCMA
It Consumes more bandwidth than other codecs. It Compress 16 bit into 8 bit. So
compression ratio 2:1. Bit rate 64kbps. (in one direction). So for a call it is 128kbps.
It is also use by PSTN. It provides best voice quality. MOS for this codec is 4.2
G722:
It provides HD audio quality.
Bit rate is 64kbps.
There are two variant of G722-- G722.1 and G722.2.
MOS for this codec is 4.5
G729:
It requires low bandwidth.
It provides good audio quality.
Bit rate is 8kbps (in one direction). So for a call it is 16kbps.
It requires license.
A frequently used variant of G729 is G729a.
It has lower CPU requirements.
MOS for this codec is 4.0.
G723.1
We have two variant of G723.1
Bit rate of first variant 6.4kbps.and MOS is 3.9
Bit rate od second variant is 5.3kbps. and MOS is 3.7
Video Codec:
H264:
Most Common for video.
HD high resolution quality. (1080p@60kbps)
Bandwidth is 1024kbps.
VP-8:
It is Created by Google. It has same quality as H264.
Bit rate is for 720p at 30 fps = 1.2mbps
360p at 30 fps = 500kbps
180p at 30 fps= 100kbps
GSM06.10:
It was designed for GSM mobile network. It can be freely used. There is no license
required. Bit rate is 13kbps and MOS for this codec is 3.7.
BB2BUA (Back to back user agent)

15
It is a SIP user agent which receives a SIP request, then reformulates the request and send it as a
new request.
It maintains a Dialog state and must participate in all request sent on the Dialog it has
established. So, it breaks end to end nature of SIP. It adds some value-added feature to old request.
Functions of B2BUA:
Call Management (Billing, Call transfer, automatic call disconnect)
Hiding private address, network topology etc.
Example of B2BUA:
Firewall, SBC, PBX.
INTERVIEW QUESTIONS

16
1. SIP Protocol belongs to which OSI layer?

A) Network Layer
B) Session Layer
C) Application Layer
D) Data Link Layer
AnsC
2. If a INVITE request by a UAC doesn't contain SDP offer then

A) INVITE Request is not valid
B) INVITE Request is valid
Ans B
(The SDP offer can be exchanged in later stages.)
3. If a UAS rejecting an offer contained in an INVITE then

A) UAS should return a 488 (Not Acceptable Here) response.
B) UAS can't reject the offer contained by INVITE
C) INVITE request never contains a offer.
D) UAS should return a 488 (Not Acceptable Here) response SHOULD include a Warning header field
value explaining why the offer was rejected.
Ans D
4. How will you recognize a looped request?

Ans) looped request can be recognized in following way:
* The Max-Forward counts is decremented to zero.
* The Expires time has elapsed.
* The server finds itself in request's VIA list including any branch parameter.
* The Server is about to proxy the request to one of the host listed in the VIA list.
5. Why ACK is separate transaction for INVITE?

Ans) The reason for this separation is rooted in importance of delivering all 200 (OK) responses to an
INVITE to the UAC.
To deliver all 200 response to UAC, UAS alone takes the responsibility and UAC alone takes
responsibility to acknowledge them all with ACK.
Since this ACK is only re-transmitted by the UAC, Its effectively considered its own transaction.
6. Alice calls Bob, in this scenario what will be response of UAC (of alice)?
Ans) In this scenario, The UAC (of Alice) may continue with the session established by 2XX response,
or may terminate them with BYE.
UAS of Bob will ignore the CANCEL request.
7. Why CANCEL is not be challenged?

Ans) Server should not challenge the CANCEL request, since these requests can't be resubmitted.
8. Here ACK is directly sent to Alice's SIP Phone to Bob's SIP Phone, bypassing the proxies? Why?
Ans) The endpoints have learned each other's address from the contact header fields through the
INVITE/200 (OK) exchange, which was not known when the initial INVITE was sent.
9. Max-Forwards is a mandatory header field in SIP. Why? What will happen if you make Max-
Forwards as a optional header?

17
Ans) The Max-Forwards header field serves to limit the number of hops a request can transmitted on
the way to its destination. Max-Forwards field decremented by one at each hop.
Max-Forwards field is helpful to detect loop/re-transmission.
10. What happens in below case after 20 Sec?

Ans) The UAS core sets a timer for the number of seconds indicated in the header field value. When
the timer fires, the invitation is considered to be expired. If the invitation expires before the UAS has
generated a final response, a 487 (Request Terminated) response SHOULD be generated.
The UAC core also sets a timer for the number of seconds indicated int the header field value. When
the timer fires and UAC didn't receive final response, a CANCEL request should be generated.
11. What are the mandatory header fields in any SIP message? Explain each mandatory header
field.
Ans) Via, Max-Forwards, To, From, Call-ID, CSeq are the minimum required header fields in any SIP
Message.
Remember, Request line is also mandatory which has Method, Request-URI and SIP Version.
12. What is the difference between Transaction, Dialog and Session?

Ans)Transaction: A Transaction refers to fundamental unit of message exchange, between the SIP
user agents, consist of one request and all responses to that request. It basically includes a request-
response cycle.
Dialog: A peer-to-peer relationship between two use agents. It is usually created through generation
of SUCCESSFUL final response.
Session: A Session refers to the exchange of media between two or more endpoints.
Transaction (1+2+3) =======>Dialog
13. Why SDP Protocol is used with SIP protocol?

Ans) SDP is short for Session Description Protocol. SDP is used to describe and encode capabilities of
session participants. Such a description is then used to negotiate the characteristics of the session so
all the device can participate.
(for example, it includes negotiation of codes used to encode media, so all the participants will be
able to decode it, negotiation of transport protocol used n so on.)
14. What is proxy server?

Ans) Proxy Server performs routing of a session invitations according to invitee's current location,
authentication, accounting and many other important functions.
The most important task of a proxy server is to route session invitations closer to Callee.
15. What you mean by stateless proxy servers? Why they are useful? What are drawbacks?
Ans) Stateless proxy servers are simple message forwarders. They forward messages independently
of each other. Although messages are usually arranged into transactions, but stateless proxies don't
take care of transactions.
Stateless proxies are simple, but faster than stateful proxy servers. they can be used as simple load
balancers, message translators and routers.
The drawback of stateless proxy servers is that they are unable to absorb re-transmission of
messages and perform more advanced routing for instance, forking or recursive traversal.
16. What is difference between call transfer and call redirect?

Ans) In Call Transfer, the UA first establish a Dialog with the Callee, and then initiates setting up a
new Dialog between the Callee and another UA.

18
In Call Redirect, the UA doesn't answer the call, but inform the Callee to resend the INVITE to
another SIP URI.
17. What is difference between Inside Dialog, & Outside Dialog?

Ans) Before getting into this, lets understand how a Dialog gets establish. The Dialog-ID is
constituting with To-TAG, From-TAG and Call-ID. Means If we have all these 3 musketeers (To-TAG,
From-TAG and Call-ID) while getting a request, Its Inside of the Dialog else its Outside of the Dialog.
Very good, you learn so quickly. But What is a early Dialog state? A Dialog established by a non-final
response to a request is in the early state and it is called early Dialog state. The early Dialog will be
needed if the UAC needs to send a request to its peer within the Dialog before the initial INVITE
transaction completes. Header fields present in a provisional response are applicable as long as the
Dialog is in the early state (for example, an Allow header field in a provisional response contains the
methods that can be used in the Dialog while this is in the early state). Means before INVITE
transaction completes you can send any request other than new INVITE request. When our favorite
guy, Alice & Bob, Alice send a INVITE Request to Bob, for Bob the INVITE Request is outside of the
Dialog. When Alice receives 180 response, its early Dialog state for Alice and this goes to confirmed
state after 200 OK response. After receiving 200 OK Response, any request will be inside the Dialog.
18. What is the major difference between SIP Network and old PSTN Network?
Ans) In PSTN (Public Switched Telephone Network), All the state and logic stored in the network and
device(telephone) are very primitive.
Whereas SIP is used to provide the same functionality that the traditional PSTNs have, but the end-
to-end design makes SIP networks much more powerful and open the implementation of new
services that can be hardly implemented in traditional PSTNs.
SIP is end-to-end based design protocol, means all the logic stored in end devices (except routing of
SIP messages). State is also stored in end devices only, there is no single point of failure and network
designed this way scale well.
19. What are the use of provisional responses? 100 Trying and 180 Ringing, both are provisional
responses. What are the major differences?
Ans) Provisional responses are informational responses which are used for informational purpose
and they stops the further retransmission of INVITE by a UAC. 100 Trying responses indicate that
request is received by the next-hop server and stops retransmission of INVITE by a UAC. The 100
Trying responses is different from other provisional responses, in that it is never forwarded
upstream by a stateful proxy. 180 Ringing responses is use to alert the UA (caller party) that other
UA is receiving The INVITE. 180 Ringing creates early Dialog state, but 100 Trying doesn't.
20. Simple Call flow in SIP?
TRANSACTION: 3
DIALOG: 1
SESSION: 1
21. Brief introduction to SIP's layered Architecture?

Ans) We will have a brief introduction about

19
Transport Layer
Transaction Layer
Transaction User
Transport Layer defines how a client sends request and receives response and how a server receives
requests and send responses over the network.
Transaction Layer, transactions are fundamental components of SIP. A transaction is a request sent
by a client transaction (using the transport layer) to a server transaction, along with all responses to
that request sent from server transaction back to the client.
The transaction layer handles application-layer re transmission, matching of responses to requests,
and application layer time outs.
Transaction User, Each of the SIP entities, except the stateless proxy, is a transaction user.
22. What the difference between both the schemes,

SIP: username@domain.com and
SIPS: username@domain.com?
Ans) SIP uses Universal Resource Identifiers (URIs) for identifying users. A URI identifies resources on
the Internet, and those used by SIP incorporate phone numbers or names in the username. At the
beginning of this is SIP: which indicates the protocol being used. This is similar to Web site
addresses, which begin with HTTP: to indicate the protocol to use when accessing the site.
When the beginning of the address is with SIP: transmission is not encrypted.
Those beginning with SIPS: require encryption for the session.
23. SIMPLE stands for?

Ans) SIMPLE is short for Session Initiation Protocol for Instant Messaging and Presence Leveraging
Extensions. It is an extension of SIP and used to determine the presence of individuals on an IP
network and manage messages exchanged between participants.Instant messaging (IM) is used to
communicate using text messagesin a private chat room environment. IM applications can also be
used to transfer files, video, and other media and data between participants.Presence technology is
used to display the availability of contacts in a Buddy List.
24. What is the purpose of REGISTER request?

Ans) The purpose of REGISTER request is to let Registrar know user's current location. The REGISTER
request carries IP address and the port number on which user is listening or can be reached. The
Registrar server stores information in location database, which can be used later by SIP proxy servers
to route calls to the user.
25. A Loop and a Spiral are differ? How?

Ans)
Loop:
A request that arrives at a proxy, is forwarded, and later arrives back at the same proxy.
When it arrives the second time, its Request-URI is identical to the first time, and other header fields
that affect proxy operation are unchanged, so that the proxy would make the same processing
decision on the request it made the first time. Looped requests are errors, and the procedures for
detecting them and handling them are described by the protocol.
Spiral:
A spiral is a SIP request that is routed to a proxy, forwarded on wards, and arrives once again
at that proxy, but this time differs in a way that will result in a different processing decision than the
original request. Typically, this means that the request's Request-URI differs from its previous arrival.

20
A spiral is not an error condition, unlike a loop. A typical cause for this is call forwarding. A user calls
joe@example.com. The example.com proxy forwards it to Joe's PC, which in turn, forwards it to
bob@example.com. This request is proxied back to the example.com proxy. However, this is not a
loop. Since the request is targeted at a different user, it is considered a spiral, and is a valid
condition.
26. What is an early media? give an example.

Ans) Early media refers to media (e.g., audio and video) that is exchanged before a particular session
is accepted by the called user. Within a Dialog, early media occurs from the moment the initial
INVITE is sent until the User Agent Server (UAS) generates a final response. It may be unidirectional
or bidirectional, and can be generated by the caller, the Callee, or both. Typical examples of early
media generated by the Callee are ringing tone and announcements (queuing status). Early media
generated by the caller typically consists of voice commands or dual tone multi-frequency (DTMF)
tones to drive interactive voice response (IVR) systems.
27. What is Handshaking? Why 3-way Handshaking used in SIP for INVITE?
Ans) Handshaking makes it possible to connect relatively heterogeneous systems or equipment over
a communication channel.
Typically, 2 SIP entities negotiate communication parameters (such as codec for media -
audio/video) for a brief period when a connection is first established, and thereafter use those
parameters to provide optimal information (can be audio, video, text etc.) transfer over the channel
as a function of its quality and capacity.3-Way Handshaking is used in SIP, to confirm that the 200 OK
response is delivered successfully to the caller party. For this confirmation ACK is send from caller
party to called party.
28. SIP timers?

Ans) Here is a short summary of SIP timers:
Timer
Value
Description
T1 500ms default RTT estimates
T2 4S 4The Max retransmit interval for non-INVITE Request & Response
T4 5S Max Duration a message will remain in the network
Timer A Initially T1 INVITE Request retransmit interval, for UDP Only
Timer B 64*T1 INVITE transaction timeout timer
Timer D >32s for UDP
0 for TCP/SCTP Wait time for response retransmit
Timer E Initially T1 NON-INVITE transaction retransmit interval, UDP Only
Timer F 64*T1 NON-INVITE transaction timeout timer
Timer G Initially t1 INVITE response retransmission interval
Timer H 64*T1 Wait time for ACK receipt
Timer I T4 for UDP
0 for TCP/SCTP Wait time for ACK retransmits
Timer J 64*T1 for UDP
0s for TCP/SCTP Wait time for NON-INVITE request retransmits
Timer K T4 for UDP
0s for TCP/SCTP Wait time for response retransmits
29. All requests sent ____ are by default sent directly from one user agent to the other user agent.
Only requests ____ traverse SIP proxies (by default).
Ans) Hint, SIP Dialog. within a Dialog. outside a Dialog.

21
30. What is the use of Registrar Server and Redirect Server?

Ans) A Registrar Server is a SIP endpoint that accepts REGISTER requests and places the information
it receives in those requests into a location service for the domain it handles. The location service
links one or more IP addresses to the SIP URI of the registering agent. SIP registrars are logical
elements and are commonly co-located with SIP proxies. But it is also possible and often good for
network scalability to place this location service with a Redirect Server.
31. Why PRACK is added in SIP?

Ans) SIP defines two types of responses, provisional and final. Final responses convey the result of
the request processing and are sent reliably. Provisional responses provide information on the
progress of the request processing but are not sent reliably in earlier. It was later observed that
reliability was important in several cases, including interoperability scenarios with the PSTN.
Therefore, an optional capability was needed to support reliable transmission of provisional
responses. That capability is provided by PRACK (Provisional Response Acknowledgement). In order
to achieve reliability for provisional responses, Reliable provisional responses are retransmitted by
the TU with an exponential back off. Those retransmissions cease when a PRACK message is
received. The PRACK request plays the same role as ACK, but for provisional responses.
32. Which request doesn't trigger any reply?

A) BYE
B) CANCEL
C) ACK
D) None of these
Ans C
33. Use of OPTION method in SIP?
Ans) OPTION method allows a UA to query another UA or a proxy server as to its capabilities. So
basically, OPTION method allows a client to discover information about the supported methods,
content types, extensions, codec etc. without "Ringing" the other party.
34. What you understand by Record Routing?

Ans) Record Routing is mechanism by which a proxy can inform user agents that it wishes to stay on
the path of all further messages is called record routing. Such a proxy would insert Record-Route
header field into SIP messages which contain address of the proxy. Messages sent within a Dialog
will then traverse all SIP proxies that put a Record-Route header field into the message.
The recipient of the request receives a set of Record-Route header fields in the message. It must
mirror all the Record-Route header fields into responses because the originator of the request also
needs to know the set of proxies.
35. What you mean by Strict Routing and Loose Routing?

Ans) Strict Record routing according to RFC2543 rewrote the Request-URI. That means the Request-
URI always contained URI of the next hop (which can be either next proxy server which inserted
Record-Route header field or destination user agent). Because of that it was necessary to save the
original Request-URI as the last Route header field. This approach is called strict routing.
Loose routing, as specified in RFC3261, works in a little bit different way. The Request-URI is no more
overwritten, it always contains URI of the destination user agent. If there are any Route header field
in a message, then the message is sent to the URI from the topmost Route header field. This is
significant change--Request-URI doesn't necessarily contain URI to which the request will be sent. In
fact, loose routing is very similar to IP source routing.

SIP (Session Initiation Protocol) (RFC3261)

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SIP (Session Initiation Protocol) (RFC3261)

Uploaded by

Copyright:

Available Formats

1

SIP(Session Initiation Protocol) (RFC3261)

 Used in VoIP Technology.

SIP Network Elements

UAS (User agent server): - It receives request and sends response.

info@reversosolutions.com www.reversosolutions.com +91-9620020759

Transaction Layer: - Transaction layer take care of

Transport Layer: - It defines how a client sends request and

Syntax and Encoding: - It is the lowest layer of SIP messages.

SIP REQUEST METHODS

info@reversosolutions.com www.reversosolutions.com +91-9620020759

INVITE and RE-INVITE:

BYE & CANCEL:

info@reversosolutions.com www.reversosolutions.com +91-9620020759

 A PUBLISH request is similar to a NOTIFY, except that it is not sent in a dialog.

info@reversosolutions.com www.reversosolutions.com +91-9620020759

200 OK: - The request was successful.

4XX Client Error:

5XX SERVER ERROR:

info@reversosolutions.com www.reversosolutions.com +91-9620020759

500 Internal Error

6XX GLOBAL FAILURE:

600 Busy Everywhere

info@reversosolutions.com www.reversosolutions.com +91-9620020759

RECORD-ROUTE:The Record-Route header field is inserted by proxies in a request to force future

PROXY AUTHENTICATE: A proxy authenticate header field value contains an authentication

info@reversosolutions.com www.reversosolutions.com +91-9620020759

WWW-AUTHENTICATE: A WWW-Authenticate header field value contains an authentication

SDP (Session description Protocol)

info@reversosolutions.com www.reversosolutions.com +91-9620020759

An example SDP description is:

o=<username><session id><version><network type><address type <address>

info@reversosolutions.com www.reversosolutions.com +91-9620020759

c=<network type><address type><connection address>

The "c=" field contains connection data.

Times, Repeat Times and Time Zones

t=<start time><stop time>

r=<repeat interval><active duration><list of offsets from start-time>

A media field also has several sub-fields:

info@reversosolutions.com www.reversosolutions.com +91-9620020759

m=video 49232 RTP/AVP 0

m=video 49232 RTP/AVP 98

a=rtpmap:<payload type><encoding name>/<clock rate>[/<encodingparameters>]

info@reversosolutions.com www.reversosolutions.com +91-9620020759

a=fmtp:<format><format specific parameters>

info@reversosolutions.com www.reversosolutions.com +91-9620020759

Dialog = Call ID+TO Tag + From Tag

info@reversosolutions.com www.reversosolutions.com +91-9620020759

G711: (U): PCMU

BB2BUA (Back to back user agent)

info@reversosolutions.com www.reversosolutions.com +91-9620020759

info@reversosolutions.com www.reversosolutions.com +91-9620020759

1. SIP Protocol belongs to which OSI layer?

2. If a INVITE request by a UAC doesn't contain SDP offer then

3. If a UAS rejecting an offer contained in an INVITE then

4. How will you recognize a looped request?

5. Why ACK is separate transaction for INVITE?

7. Why CANCEL is not be challenged?

info@reversosolutions.com www.reversosolutions.com +91-9620020759

10. What happens in below case after 20 Sec?

12. What is the difference between Transaction, Dialog and Session?

13. Why SDP Protocol is used with SIP protocol?