Sip Fundamentals

SIP BASICS
 What is SIP
SIP is a mechanism to establish, modify and tear down
multimedia sessions.
Media setup by SIP is transported by any protocol, though most
commonly RTP (e.g. audio, video).
The protocol does not need to know about the details of a
session, and it does not care about the message body.
The simplicity of the protocol means that SIP is scalable,
extensible, and flexible in different architectures and
deployment scenarios.
When compared to H.323, fewer messages are required to
establish a session (as few as 3), and is text based, not binary,
making messages human readable.
RFC 3261 provides the details of the current release of SIP, 2.0
http://www.ietf.org/rfc/rfc3261.txt
The Basic SIP Call(Alice and
Bob)
 SIP Requests
INVITE Indicates a client is being invited to participate in a call session. RFC 3261
ACK Confirms that the client has received a final response to an INVITE request.
RFC 3261
BYE Terminates a call and can be sent by either the caller or the callee. RFC 3261
CANCEL Cancels any pending request. RFC 3261
OPTIONS Queries the capabilities of servers. RFC 3261
REGISTER Registers the address listed in the To header field with a SIP server.
RFC 3261
PRACK Provisional acknowledgement. RFC 3262
SUBSCRIBE Subscribes for an Event of Notification from the Notifier. RFC 3265
NOTIFY Notify the subscriber of a new Event. RFC 3265
PUBLISH Publishes an event to the Server. RFC 3903
INFO Sends mid-session information that does not modify the session state.
RFC 6086
REFER Asks recipient to issue SIP request (call transfer.) RFC 3515
MESSAGE Transports instant messages using SIP. RFC 3428
UPDATE Modifies the state of a session without changing the state of the dialog.
RFC 3311
 SIP RESPONSES
1xxProvisional Responses
2xxSuccessful Responses
3xxRedirection Responses
4xxClient Failure Responses
5xxServer Failure Responses
6xxGlobal Failure Responses
 UAC vs. UAS
A SIP user agent (UA) is a logical network end-
point used to create or receive SIP messages
and thereby manage a SIP session.
A user agent client(UAC) is a device that
sends SIP requests and receives responses
A user agent server(UAS) is a device that
receives requests and sends responses.
The role of the UAC or UAS is only relevant for
the transaction and most SIP UAs are both a
UAC and a UAS
 Address of Record vs. Contact
Address
An Address of Record(AoR) is a logical address
that represents a user.
A Contact Address is a physical address that
represents a device.
Usually a AoR is mapped to one or more Contact
Addresses
There is no specific syntax that differentiates the
two however
For example:
AoR: sip:jamieanderson@avaya.com
Contact Address: sip:135.20.146.15
 Transactions
A transaction is comprised of a single
request and any responses to that request.
This includes zero or more provisional
responses and one or more final responses.
The entire request and response is
considered one transaction.
The transaction is an interaction between
components and takes place in a series of
independent message exchanges.
 Dialog
A dialog represents a peer-to-peer SIP relationship between two user agents that persists for some
time.
The dialog facilitates the sequence of messages between the user agents and proper routing of
requests between both of them.
A dialog is identified at each User Agent with a dialog ID and consists of:
CID
To Tag(UAS Tag)
From Tag(UAC Tag)
Dialogs are created by a non-failure response to a request.
Specifically any 2xx message or 101-199 response
Dialogs created by a 1xx response are called early dialogs since they can still be destroyed by a failure
response
Items that are stored about a dialog are:
Dialog ID
Local Sequence Number(Requests from this UA)
Remote Sequence Number(Requests to this UA)
Local URI
Remote URI
Target(Contact)
A secure flag
The route set discussed later
Dialogs are terminated using the BYE method
Early Dialogs are terminated using the CANCEL method
 Calls vs. Sessions
There is no formal definition of Calls in SIP
Call refers to one or more dialog with the same call ID.
In a 2 party session a dialog is the same as a call
There are some scenarios where a there can be multiple
parties on the same call such as a conference.
Sessions involve the sharing of information and are
defined in the SDP RFC:
A multimedia session is a set of multimedia senders and
receivers and the data streams flowing from senders to
receivers. A multimedia conference is an example of a
multimedia session.
Often in SIP the term Session and Call are used
interchangeably but they are slightly different
Dialog vs. Call
SIP SERVERS
 SIP Proxies
A SIP proxy is used to forward SIP requests to a UAS
and responses to a UAC.
Certain headers can be changed or modified. Refer to the
RFC for each header
Eg. The TO and FROM header should never be modified since they
are specific to the dialog
Proxy Servers can be either
Stateful: transaction(or dialog) aware routing engine
Can send responses in specific cases(100 trying, 408 Request
Timeout)
Advanced routing decisions and field manipulations
Stateless: Basic message forwarder
Not transaction aware
No ability to correlate requests with their appropriate responses
 Location, Registrar and Redirection
Services
The location, registrar and redirection services are
general sip components that are usually
components of the proxy.
Location Service- servers are used by SIP Proxy or
Redirect server to obtain the mapping from logical
SIP addresses to physical SIP addresses.
Registrar- Handles registration requests and passes
the bindings between the AOR and contact address
to the Location Service.
Redirection Server- Sends 3xx responses to
requests. This is often used to direct requests to
external domains.
 Back to Back User Agent(B2BUA)
A B2BUA is a logical entity that can receive a SIP
request as a UAS process then and then generate a
new requests as a UAC to another UA using a
different dialog.
It maintains dialog state and must participate in all of
the requests sent on the dialogs it has established.
This gives the application tight system/call
management and is a natural entity to implement
the controller functionality.
Most SIP feature servers and SBCs are implemented
in this manor due the increased flexibility and
control.
Back to Back User Agent(B2BUA)
 Session Boarder Controllers
A Session Boarder Controller is a special kind of sip
server that is designed to be placed on the edge of a
network
Its main function is as a security device to prevent
application level attacks in SIP
Some examples are INVITE floods, malformed SIP packets,
man in the middle attacks
SBCs are almost always B2BUA so they are also very
useful in doing header manipulations
If there is an interoperability issue it is often easy to
resolve it at the SBC
SBCs abstract the SIP conversation and hide
information from the far side of the SBC so this often
complicates troubleshooting.
Real World SIPSort of
What headers do we need to know right now?

BEGINNER SIP HEADERS

 Request Line
The first line of any sip message is
called the request line
It consists of:
Method Name
Request URI
SIP version

METHOD REQUEST URI SIP VERSION

 To Header
The To header specifies the desired
"logical" recipient of the request, or the
address-of-record of the user or resource
that is the target of this request.
This may or may not be the ultimate
recipient of the request.
The To header field MAY contain a SIP or
SIPS URI, but it may also make use of
other URI schemes
The To header field allows for a display
name.
If the TO header contains a tag then this
 From Header
The From header field indicates the logical
identity of the initiator of the request, possibly
the user's address-of-record.
Like the To header field, it contains a URI and
optionally a display name.
It is used by SIP elements to determine which
processing rules to apply to a request (for
example, automatic call rejection).
The From URI should not contain IP addresses or
the FQDN of the host on which the UA is running,
since these are not logical names.
A UAC SHOULD use the display name
"Anonymous", along with a syntactically correct,
but otherwise meaningless URI (like
sip:thisis@anonymous.invalid), if the identity of
 Call-ID Header
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.
When requests are retried they are not
considered new requests and therefore can
have the same Call-ID
 CSeq Header
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.
The CSEQ header must not wrap around
Value must be less than 2^31 or 2147483648
This allows for a dialog to send one request a
second for 136 years
 Max-Forwards Header
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.
Initial value should be 70 as recommended by
the RFC
 VIA Header
The Via header field indicates the transport used for the
transaction
Identifies the location where the response is to be sent.
When the UAC creates a request, it MUST insert a Via
into that request.
The Via header field value MUST contain a branch
parameter which is used to identify the transaction
created by that request.
The branch ID inserted by an element compliant with RFC
3261 MUST always begin with the characters "z9hG4bK".
A proxy must always insert a via header when
forwarding the request above the existing VIA headers
 Contact Header
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.
A Contact header field value can contain a
display name, a URI with URI parameters, and
header parameters.
 Supported and Requires
Header
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 Supported header field enumerates all the
extensions supported by the UAC or UAS.
The Supported and Require header field
contains a list of option tags
Option tags and their description can be found here:
http://www.iana.org/assignments/sip-parameters
 Expires Header
The Expires header field gives the
relative time after which the
message (or content) expires.
The precise meaning of this is
method dependent.
 Allows Header
The Allow header field lists the set of methods
supported by the UA generating the message.
All methods, including ACK and CANCEL,
understood by the UA MUST be included in the list
of methods in the Allow header field, when present.
The absence of an Allow header field MUST NOT be
interpreted to mean that the UA sending the
message supports no methods. Rather, it implies
that the UA is not providing any information on
what methods it supports.
Allow headers may also be in responses and are
required in responses to Options requests
 Alert-Info Header
When present in an INVITE request, the
Alert-Info header field specifies an
alternative ring tone to the UAS.
When present in a 180 (Ringing) response,
the Alert-Info header field specifies an
alternative ringback tone to the UAC.
A typical usage is for a proxy to insert this
header field to provide a distinctive ring
feature.
 Content-Type and Content-Length
Headers
The Content-Type header field indicates the media
type of the message-body sent to the recipient.
The Content-Type header field MUST be present if the
body is not empty.
The Content-Length header field indicates the size
of the message- body, in decimal number of
octets, sent to the recipient.
If no body is present in a message, then the
Content-Length header field value MUST be set to
zero.
Content-Length is not required but should be used
Accepted-Language Header
The Accept-Language header field is
used in requests to indicate the
preferred languages for reason
phrases, session descriptions, or
status responses carried as message
bodies in the response.
If no Accept-Language header field is
present, the server SHOULD assume
all languages are acceptable to the
client.
 User-Agent and Server
Header
The User-Agent header field contains
information about the UAC
originating the request.
The Server header field contains
information about the software used
by the UAS to handle the request.
Usually this is the name and version
of software running on the UA
 Proxy-Authenticate and Proxy-
Authorization Headers
A Proxy-Authenticate header field value contains an
authentication challenge.
The Proxy-Authorization header field allows the client
to identify itself (or its user) to a proxy that requires
authentication.
Usually a proxy-authenticate challenge is provided in
a 407 proxy authentication required response
When a UAC receives a 407 response it should
include a Proxy-Authorization header with its
response to the challenge
 History-Info Header
The History-Info header provides the ability to
determine why and how the call arrived at a specific
application.
It is most commonly found in voicemail
implementations
The header contains a target URI where the call was
directed a index in chronological order and a reason
indicating why the call was redirected
The index value is string of digits separated by dots to
indicate multiple redirections in the same branch and thus
giving a tree structure
The History-Info header is defined in RFC 4244
http://www.ietf.org/rfc/rfc4244.txt
 P-Asserted-Identity Header
Various SIP RFCs define a number of Private
headers that should only be used on the trusted
network.
P-Asserted-Identity is one of these headers
P-Asserted-Identity is used for calling party
identification
Proxies can add and remove this field
This field should be stripped if sending to an un-
trusted entity
Defined in RFC 3324
http://www.ietf.org/rfc/rfc3325.txt
SIP RESPONSES
 SIP Responses
SIP responses are distinguished from requests by having a
Status-Line as their start-line.
A Status-Line consists of the protocol version followed by a
numeric Status-Code and its associated textual phrase, with
each element separated by a single SP character.
The Status-Code is a 3-digit integer result code that indicates the
outcome of an attempt to understand and satisfy a request.
The Reason-Phrase is intended to give a short textual description of
the Status-Code.
The Status-Code is intended for use by automata, whereas the
Reason-Phrase is intended for the human user.
The RFC suggests specific wordings for the reason phrase but
each system can use whatever it desires.
The first digit of the Status Code determines the class of the
response. Current 1-6 are allowed for the first digit
The second and third digit have no categorization role
 1XX: Provisional Responses
Indicates the request is received and
being processed
Response Meaning
100 Trying Extended search being performed may take a significant
time so a forking proxy must send a 100 Trying response
180 Ringing Destination user agent received INVITE, and is alerting
user of call
181 Call is Being Servers can optionally send this response to indicate a
Forwarded call is being forwarded
182 Queued Indicates that the destination was temporarily
unavailable, so the server has queued the call until the
destination is available. A server may send multiple 182
responses to update progress of the queue
183 Session in This response may be used to send extra information for
Progress a call which is still being set up
199 Early Dialog Can be used by User Agent Server to indicate to
 2xx: Successful Responses
Indicates the action was successfully
received, understood, and accepted

Response Meaning
200 OK Indicates the request was successful.
202 Accepted Indicates that the request has been accepted for
processing, but the processing has not been completed.
204 No Indicates the request was successful, but the
Notification corresponding response will not be received
 3xx: Redirection Responses
Indicates that further action needs to be
taken in order to complete the request
Response Meaning
300 Multiple Choices The address in the request resolved to several
choices, each with its own specific location, and the
user (or UA) can select a preferred communication
end point and redirect its request to that location.
301 Moved The user can no longer be found at the address in
Permanently the Request-URI, and the requesting client SHOULD
retry at the new address given by the Contact
header field
302 Moved The requesting client SHOULD retry the request at
Temporarily the new address(es) given by the Contact header
field.
305 Use Proxy The requested resource MUST be accessed through
the proxy given by the Contact field.
 4xx: Client Failure

Responses
Indicates the request contains bad syntax or cannot be fulfilled at
this server
- This list is not Meaning
Response complete
401 Unauthorized The request requires user authentication. This response is issued by
UASs and registrars
403 Forbidden The server understood the request, but is refusing to fulfill it
404 Not Found The server has definitive information that the user does not exist at the
domain specified in the Request-URI or recipient does not handle this
domain.
407 Proxy Authentication The request requires user authentication. This response is issued by
Required proxies.
408 Request Timeout Couldn't find the user in time
422 Session Interval Too It is generated by a UAS or proxy when a request contains a Session-
Small Expires header field with a duration below the minimum timer for the
server .
481 Call/Transaction Does Server received a request that does not match any dialog or transaction
Not Exist
484 Address Incomplete Request-URI incomplete. (Used often for off hook requests for CM)
486 Busy Here Callee is busy
487 Request Terminated Request has terminated by bye or cancel
488 Not Acceptable Here Some aspects of the session description of the Request-URI is not
acceptable
 5xx: Server Failure Responses
Indicates that the server failed to
fulfill an apparently valid request
Response Meaning
500 Server Internal The server encountered an unexpected condition that
Error prevented it from fulfilling the request
501 Not Implemented The SIP request method is not implemented here
502 Bad Gateway The server, while acting as a gateway or proxy, received
an invalid response from the downstream server it
accessed in attempting to fulfill the request.
503 Service Unavailable The server is temporarily unable to process the request
due to a temporary overloading or maintenance of the
server.
504 Server Time-out The server did not receive a timely response from an
external server it accessed in attempting to process the
request.
505 Version Not The server does not support this version of the SIP
Supported protocol

513 Message Too Large The server was unable to process the request since the
message length exceeded its capabilities.
 6xx: Global Failure

Responses
Indicates that the request cannot be
fulfilled at any server
Response Meaning
600 Busy Everywhere The callee's end system was contacted successfully but the callee
is busy and does not wish to take the call at this time. The
response MAY indicate a better time to call in the Retry-After
header field. If the callee does not wish to reveal the reason for
declining the call, the callee uses status code 603 (Decline)
instead. This status response is returned only if the client knows
that no other end point (such as a voice mail system) will answer
the request. Otherwise, 486 (Busy Here) should be returned.
603 Decline The callee's machine was successfully contacted but the user
explicitly does not wish to or cannot participate. The response MAY
indicate a better time to call in the Retry-After header field. This
status response is returned only if the client knows that no other
end point will answer the request.
604 Does Not Exist The server has authoritative information that the user indicated in
Anywhere the Request-URI does not exist anywhere.
606 Not Acceptable The user's agent was contacted successfully but some aspects of
the session description such as the requested media, bandwidth,
or addressing style were not acceptable
SIP REQUESTS
 SIP Requests
SIP requests are distinguished by having a
Request-Line for a start- line.
A Request-Line contains a method name, a
Request-URI, and the protocol version
separated by a single space (SP) character
A valid SIP request formulated by a UAC
MUST, at a minimum, contain the following
header fields: To, From, CSeq, Call-ID, Max-
Forwards, Via as well as a request line
 INVITE
Invites are the main way to create dialogs in
SIP
Request URI contains the party being invited
to the session
Response from INVITE is always followed by
an ACK request to ensure reliability
This is the only request that uses the ACK
Additional invites in the same dialog are often
called re-invites and are used to change the
parameters of the session
There is not request called re-invite
Invite
Invite
 ACK
ACK is required for a 3 way handshake when opening a
dialog.
If there was no 3-way there is no way for the UAS to know that
the dialog is open
ACK is a special request and there are many special
exceptions in the RFC for it
ACKs are only generated following a final response to an
Invite request
There is no response to an ACK
If the ACK is triggered by a non 2XX response it is
considered part of the original transaction
If the ACK is triggered by a 2XX response then it is
considered its own transaction
ACK
 REGISTER
The URI contains the domain that the registration is valid for.
A Register request maps and address-of-record(AOR) to one
or many contact addresses.
AOR is found in the To header
Contact addresses are in the contact header
From header indicates where the registration is from
This is almost always the same as the To header except in the case of a 3 rd party
registration.
The expires header determines how long the registration is
valid for
An expires header of 0 indicates an deregister request
Initial registration requests should always be rejected with
401 Unauthorized which will include a WWW-Authenticate
header(challenge)
Authentication is done using the Authorization
Header(response)
Registrations are sent to the registrar server which passes
the bindings it creates to the location service
Registration
Registration
 BYE
A Bye request is needed to close an
open dialog
Byes must be sent in a dialog
The caller may send a BYE as part of
an early dialog however a cancel is
more common
BYE
BYE
 CANCEL
The Cancel Request asks the UAS to
stop processing a previous request
and generate an error(487 Request
Terminated)
This should only be done for a Invite
since this is the only request that takes
any time to process
A Cancel is only valid if a final
response to the request has not been
generated
CANCEL
CANCEL
 PRACK
PRACK Methods are a way to provide reliability to
provisional responses
Typically used when connecting to the PSTN
Used if option tag 100rel is required
Provisional responses that require reliability will
include the Rseq header
Contains a sequence for the reliable responses
PRACK Message contains a RAck header
Contains the Rseq and the CSeq value from the
corresponding provisional response
Defined in RFC 3262
http://www.ietf.org/rfc/rfc3262.txt
PRACK
PRACK
PRACK
 UPDATE
Update is used to modify the
characteristics of the Session without
modifying the dialog.
This was done so that media attributes
can be changed prior to the dialog being
finalized
The most common use of this in
Avaya is a s a display update
Defined in RFC 3311
http://www.ietf.org/rfc/rfc3311.txt
UPDATE
UPDATE
 INFO
The INFO method is used for communicating mid-session
signaling information along the signaling path for the call.
The INFO method is not used to change the state of SIP
calls, nor does it change the state of sessions initiated by
SIP.
It provides additional optional information which can
further enhance the application using SIP.
Examples of uses of the INFO Method:
Carrying mid-call PSTN signaling messages between PSTN
gateways
Carrying DTMF digits generated during a SIP session
Carrying images or other non streaming information between the
participants of a session
Defined in RFC 2976
https://tools.ietf.org/html/rfc2976
 SUBSCRIBE
The SUBSCRIBE method is used to request current
state and state updates from a remote node.
The Event header contains the event package being
subscribed to
The URI will be used to determine which user or group of
events to get notifications for as well as routing
Notify requests are used to provide updates to
subscribers when needed
The Expires header in the response sets the length of
the subscription
This can not be longer than the expires header in the request
An expires header value of zero indicates an unsubscription
If the subscribe is sent outside of an existing dialog then
it creates a new dialog
The Subscribe method is described in RFC 3265
http://www.ietf.org/rfc/rfc3265.txt
SUBSCRIBE
 NOTIFY
NOTIFY messages are sent to inform subscribers of
changes in state to which the subscriber has a
subscription.
Subscriptions are typically put in place using the
SUBSCRIBE method however there are other methods
A single SUBSCRIBE request may trigger several
NOTIFY requests
The status of the subscription can be found in the
subscription state header
Subscription state could be "active", "pending", or
"terminated".
All notifies should be sent as part of the same dialog
as the subscribe that created it
The Notify method is described in RFC 3265
http://www.ietf.org/rfc/rfc3265.txt
NOTIFY
SUBSCRIBE/NOTIFY
 PUBLISH
PUBLISH requests create, modify,
and remove event state associated
with an address-of-record.
Multiple devices could generate
PUBLISH requests for a single AOR
Publish requests do not create a
dialog
The Publish method is defined in RFC
3903
http://www.ietf.org/rfc/rfc3903.txt
PUBLISH
 SIP-If-Match and SIP-Etag
On generating an initial Publish request a
Entity tag is returned in the SIP-Etag
header of the 200 OK
On any subsequent Publish the Etag is put
in the SIP-If-Match header.
This allows servers that aggregate states
such as presence to track update states
accordingly and ignore old states
These headers are found in RFC 3903
http://www.ietf.org/rfc/rfc3903.txt
SIP-Etag Example
 REFER
The Refer method is used to request another UA to
send a request.
This is most commonly found in call transfer scenarios
Invite is implied if no method is specified
A REFER results in an automatic subscription to the
refer events package for that dialog if accepted
Notifies are then sent to give progress of the update
The refer to header specifies the party to contact and
the existing dialog that is being replaced if any
If a replaces parameter is included the generated
request will also have a replaces header that specifies
and existing dialog to replace with the new dialog
REFER
REFER
REFER
REFER
 OPTIONS
The Options method allows a UA to query another
UA or a proxy server as to its capabilities.
This allows a client to discover information about
the supported methods, content types, extensions,
codecs, etc. without "ringing" the other party.
If a server receives an options message with zero in
the max forwards header it may still optionally
respond
Similar to a trace route
Options are commonly used as SIP ping to
determine if links are up
Sometime called an options ping
OPTIONS
OPTIONS
 MESSAGE
The Message method is designed for
instant messaging using SIP
This method does not establish a
dialog and each message stands on
its own.
The body of the message is usually
text/plain .
If the message is successful it
receives a 200 OK response
 Using SIP- A thought
experiment
Assuming that the refer message is
not supported, is there another way
to transfer calls using just SIP Invite
requests?
How do messages get where they are going?

SIP ROUTING
 SIP Routing Headers
The SIP headers that affect routing are:
The request URI from the request line
The VIA header
The route header
The record route header
The contact header
No other headers directly affect routing
including the to and from header although
it is often possible to implement rules on
these headers
 Route Sets
A route set is a collection of ordered
SIP or SIPS URI which represent a list
of proxies that must be traversed
when sending a particular request.
A route set can be learned, through
headers like Record-Route, or it can
be configured
Once a dialog is established the
route set does not change.
 Record-Route Header
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.
This sets the route set for the dialog.
The Record-Route is only relevant
during dialog setup and does not
have any affect on a confirmed
dialog
 Route Header
The route header represents a list of
proxies to be traversed when routing
a request.
For an initial request from a UAC the
there is usually only a single route
header representing the outgoing
proxy.
For subsequent requests in a dialog
the route header represents the
values stored in the route set.
 VIA Header(Review)
The Via header field indicates the transport used for the
transaction
Identifies the location where the response is to be sent.
When the UAC creates a request, it MUST insert a Via
into that request.
The Via header field value MUST contain a branch
parameter which is used to identify the transaction
created by that request.
The branch ID inserted by an element compliant with RFC
3261 MUST always begin with the characters "z9hG4bK".
A proxy must always insert a via header when
forwarding the request above the existing VIA headers
 Contact Header(Review)
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.
A Contact header field value can contain a
display name, a URI with URI parameters, and
header parameters.
 Routing Requests(Initial
Requests)
Initial requests in a dialog are routed somewhat
differently than subsequent requests.
Initial request usually only have the outbound
proxy configured in the route set and have to
learn the rest of the route set.
This is done using the record route header
There is also no contact address so all routing is
done using the request URI and the location
service of the proxies to the AOR.
Once a response to the initial request is received the
contact address is set to the value of the contact
header
Routing Requests(Subsequent Requests)

Subsequent requests are ones set after the

dialog is established.
The Request URI is set to the contact address
instead of the AOR
These requests follow the route headers to
their destination which is from the route set
established at dialog setup
Once all the route headers are traversed then
the message is sent to the URI address
It is possible that none of the proxies traversed in
the initial request add an record-route header and
so the route set is empty
 Routing Responses
Responses are always routed the same way
The follow the VIA header from top to bottom
VIA headers must be added to a request
when it is forwarded including the initial UAC
that sends the requests
VIA headers are added to the top of the list
in requests and removed from the top of the
list in responses as they are processed
Using this logic responses should always
follow the same path as their matching
request
 Routing Example # 1
2. Proxy Looks up next hop
- Does not add record
route 4. Proxy Looks up next hop
- Adds a VIA header to - Does not add record
the top of the list 3. Initia route
- Adds next hop to - Adds a VIA header to
route header l the top of the list
Invit
9. e200 OK

5. l vit OK
l itia

In
K

10. Proxy strips off

iti
7.
O
In

its via header

a
In 0
8. Proxy strips off its
e .2 it
00

2e0
and forwards to
11Inv
1.

via header and

the next via forwards to the
header next via header
- No Record - No Record route
route header header added
added 13.ACK (Subsequent
request)
14.BYE (Subsequent
request)
15.200 OK
12. Response arrives at 6. Request arrives at
UAC UAS
- Empty route set - Empty route set
- UAS contact - 3 entries in the VIA
address in the header
contact header - Gets UAC contact
address from the
contact header
 Routing Example # 2
2. Proxy Looks up next hop
- Adds next hop to
route header 4. Proxy Looks up next hop
- Add record route - Add record route
- Adds a VIA header to - Adds a VIA header to
the top of the list 3. Invit the top of the list
e
9. 200 OK
14.ACK
K
O
11 e it

10. Proxy strips off

7.
v

5.
8. Proxy strips off its
00

its via header

In

and forwards to via header and

20

In
.2

15
1.

the next via forwards to the

CK

e0 O
vi
.A
header next via header

t
.A

CK
- No Record - No Record route
13

K
route header header added
added

12. Response arrives at

6. Request arrives at UAS
UAC
- Route set is Proxy 1 +
- Route set is Proxy
Proxy 2
1 + Proxy 2
- 3 entries in the VIA header
- UAS contact
- Gets UAC contact address
address in the
from the contact header
contact header
 Routing Example # 3
Initial Invite from UAC to Proxy #1
 Routing Example # 3
Initial Invite from Proxy # 1 to Proxy # 2
Routing Example # 3
Initial Invite
from Proxy
#2 to Proxy
#1
Routing Example # 3
Initial
Invite
from
Proxy #1
to UAS
Routing Example # 3

200 OK
from UAS
to Proxy
#1
 Routing Example # 3
200 OK from Proxy # 1 to Proxy # 2
 Routing Example # 3
200 OK from Proxy # 2 to Proxy # 1
Routing Example # 3
200 OK from Proxy # 1 to UAC
 Routing Example # 3
ACK Request from the UAC to Proxy # 1
 Routing Example # 3
ACK Request from Proxy # 1 To Proxy # 2
 Routing Example # 3
ACK Request from Proxy # 2 To Proxy # 1
 Routing Example # 3
ACK Request from Proxy # 1 To UAS
 DNS and its role in SIP
DNS is often used in SIP in routing if the domain component of a
SIP URI is not local.
In this case we use DNS service records to locate the server to
contact.
A service record is a way to locate a server that hosts a service for
a specific domain.
For example if a proxy is to the foreign domain business.com
you would query the following service records depending on the
transport protocol used
_sip._udp.business.com
_sip._tcp.business.com
The result of this query should be a priority, weight, port and host
name/IP.
The proxy will then forward the request on to the host and port
selected
How long does SIP wait?

SIP TIMERS
 SIP Timers
Time RFC Reque Used
Value Meaning
r Section st by
T1 500ms 17.1.1.1 RTT Estimate ALL UAC/UAS
The maximum retransmit interval for Non-
UAC/UAS
T2 4s 17.1.2.2 non-INVITE requests and INVITE Invite(UAC)
responses Invite(UAS)
Maximum duration a message with
T4 5s 17.1.2.2 ALL UAC/UAS
remain in the network
INVITE request retransmit interval for
A Initially T1 17.1.1.2 Invite UAC
UDP only
B 64*T1 17.1.1.2 INVITE transaction timeout timer Invite UAC
C > 3 min 16.6 bullet 11 Proxy INVITE transaction timeout Invite Proxy
>32s for
UDP
D 17.1.2.2 Wait time for response retransmits Invite UAC
0s for
TCP/SCTP
Non-INVITE request retransmit
E Initially T1 17.1.2.2 Non-Invite UAC
interval
F 64*T1 17.1.2.2 Non-INVITE transaction timeout timer Non-Invite UAC
G Initially T1 17.2.1 INVITE response retransmit interval Invite UAS
H 64* T1 17.2.1 Wait time for ACK receipt Invite UAS
T4 for UDP
I 0s for 17.2.1 Wait time for ACK retransmits Invite UAS
TCP/SCTP
64*T1 for
UAC INVITE State Machine
UAC non-INVITE State Machine
UAS INVITE State Machine
UAS non-INVITE State Machine
Session-Expires and Min-SE Headers
If a Session is established there should be no additional signaling
messages unless there is a change in session
If the proxy goes down or there is a network event that causes the
signaling path to be impacted calls can get hung
The Session-Expires header sets the maximum time in seconds that a
session can exist without being refreshed as well as who will refresh,
UAC or UAS.
The Min-SE headers allows a UA to set the minimum value of the
Session Expires header.
If a Session Expires header below the minimum of the UAS is requested the UAS
responds with a 422 Session Interval Too Small response which includes its Min-
SE header and the UAC should resend the request with a bigger Session Expires
header
Generally the refresh of the session should be done a half the value of
the SE interval
The option tag timer specifies if these headers are supported by a UA
These two headers are defined in RFC 4028
http://www.ietf.org/rfc/rfc4028.txt
Session Description Protocol

SDP
 What is SDP?
SDP provides a standard representation to convey
media details, transport addresses, and other
session description metadata to the participants
SDP is purely a format for session description -- it
does not incorporate a transport protocol, and it is
intended to use different transport protocols as
appropriate, including the Session Announcement
Protocol , Session Initiation Protocol, Real Time
Streaming Protocol , electronic mail using the
MIME extensions, and the Hypertext Transport
Protocol.
 SDP with SIP
SIP allows to UAs to signal back and forth but
there is no way to exchange media information
SIP allows message bodies in many messages.
These message bodies contains other
protocols used to be UA such as XML, plain
text, images and SDP
SDP allows UA to exchange media properties
and capabilities to establish a media stream
If SDP is used in the body of a SIP message the
Content-Type header is set to application/sdp
 SDP Basics
SDP consists of a number of lines of
text of the format <type>=<value>
Type is exactly one character
Value is text that is defined by the type
field
There is always a session-level part
that starts with v= followed by one
or more media part which start with
an m= line
 SDP Format
Session description
Time description
v= (protocol version)
o= (originator 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=* (zero or more bandwidth
information lines)
One or more time descriptions ("t="
and "r= lines; see right)
z=* (time zone adjustments)
k=* (encryption key)
a=* (zero or more session attribute
lines)
Zero or more media descriptions
t= (time the session is active)
r=* (zero or more repeat times)
Media description, if present
m= (media name and transport
address)
i=* (media title)
c=* (connection information --
optional if included at
session level)
b=* (zero or more bandwidth
information lines)
k=* (encryption key)
a=* (zero or more media attribute
lines)
 Protocol Version
v=0
The "v=" field gives the version of
the Session Description Protocol.
Currently the only version is v=0
 Origin Field
o=<username> <sess-id> <sess-version> <nettype>
<addrtype> <unicast-address>
The "o=" field gives the originator of the session (her username
and the address of the user's host) plus a session identifier and
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.
<sess-id> is a numeric string such that the tuple of <username>,
<sess-id>, <nettype>, <addrtype>, and <unicast-address> forms a
globally unique identifier for the session.
<sess-version> is a version number for this session description. <sess-
version> is increased when a modification is made to the session data.
<nettype> is a text string giving the type of network. Initially "IN" is
defined to have the meaning "Internet
<addrtype> is a text string giving the type of the address that follows.
Initially "IP4" and "IP6" are defined.
<addrtype> is a text string giving the type of the address that follows.
Initially "IP4" and "IP6" are defined
 Session Name
s=<session name>
The "s=" field is the textual session
name.
There MUST be one and only one
"s=" field per session description.
If a session has no meaningful name,
the value "s= " SHOULD be used.
(Single space)
 Session Information
i=<session description>
The "i=" field provides textual
information about the session.
There MUST be at most one session-
level "i=" field per session
description, and at most one "i="
field per media.
This field is optional
 URI
u=<URI>
A URI is a Uniform Resource Identifier
as used by WWW clients.
The URI should be a pointer to
additional information about the
session.
This field is optional.
 Email Address and Phone
Number
e=<email address>
p=<phone number>
The "e=" and "p=" lines specify
contact information for the person
responsible for the conference.
This is not necessarily the same
person that created the conference
announcement.
These fields are optional.
 Connection Data
c=<nettype> <addrtype> <connection-address>
<nettype> is a text string giving the type of network.
Initially "IN" is defined to have the meaning "Internet
<addrtype> is a text string giving the type of the
address that follows. Initially "IP4" and "IP6" are defined.
<connection-address> is the address of the data source
A session description MUST contain either at least
one "c=" field in each media description or a single
"c=" field at the session level.
It MAY contain a single session-level "c=" field and
additional "c=" field(s) per media description, in which
case the per-media values override the session-level
settings for the respective media.
 Bandwidth
b=<bwtype>:<bandwidth>
denotes the proposed bandwidth to be used by
the session or media
<bwtype> is an alphanumeric modifier giving the
meaning of the <bandwidth> figure. Two values are:
CT used in a conference to specify the conference total
bandwidth. Gives total max BW for all streams at all sites.
AS Application specific bandwidth. Gives total maximum
bandwidth for the session. Gives the total max BW for a
single site
<bandwidth> is interpreted as bandwidth in kilobits
per second.
This field is optional
 Timing
t=<start-time> <stop-time>
The "t=" lines specify the start and stop times
for a session.
Multiple "t=" lines MAY be used if a session is
active at multiple irregularly spaced times; each
additional "t=" line specifies an additional
period of time for which the session will be
active.
Values are the decimal representation of
Network Time Protocol (NTP) time values in
seconds since 1900 .
 Repeat Times
r=<repeat interval> <active duration>
<offsets from start-time>
"r=" fields specify repeat times for a session
If a 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.
 Time Zones
z=<adjustment time> <offset> <adjustment
time> <offset>
To schedule a repeated session that spans a
change from daylight saving time to standard
time or vice versa, it is necessary to specify
offsets from the base time.
This is required because different time zones
change time at different times of day, different
countries change to or from daylight saving
time on different dates, and some countries do
not have daylight saving time at all.
 Encryption Keys
k=<method>
k=<method>:<encryption key>
If transported over a secure and trusted channel, the
Session Description Protocol MAY be used to convey
encryption keys.
A key field is permitted before the first media entry (in
which case it applies to all media in the session), or for
each media entry as required.
The following methods are defined:
k=clear:<encryption key>
k=base64:<encoded encryption key>
k=uri:<URI to obtain key>
k=prompt
The k= parameter is not very useful for SRTP since the
key changes frequently and is generally not used in
favor of the crypto attribute
 Attributes
a=<attribute>
a=<attribute>:<value>
Attributes are the primary means for extending
SDP.
Attributes may be defined to be used as "session-
level" attributes, "media-level" attributes, or both.
There can be many attributes that apply to the
media or the session
Some SDP attributes can be found in section 6 of
the RFC 4566:
http://tools.ietf.org/html/rfc4566#section-6
 Common SDP attributes
a=ptime:<packet time>
This gives the length of time in milliseconds represented by the media
in a packet.
a=rtpmap:<payload type> <encoding name>/<clock rate>
[/<encoding parameters>]
This attribute maps from an RTP payload type number (as used in an
"m=" line) to an encoding name denoting the payload format to be
used. It also provides information on the clock rate and encoding
parameters.
a=recvonly
The source of the message will only listen for audio and not transmit.
a=sendrecv
The source of this message will send and receive audio
a=sendonly
The source of this message will only send audio and not listen.
a=inactive
The source of this message will not send audio or listen for it
a=fmtp:<format> <format specific parameters>
 Media Descriptions
m=<media> <port> <proto> <fmt> ...
<media> is the media type. Currently defined media are
"audio", "video", "text", "application", and "message
<port> is the transport port to which the media stream
is sent.
<proto> is the transport protocol.
udp: denotes an unspecified protocol running over UDP
RTP/AVP: denotes RTP over UDP
RTP/SAVP: denotes the Secure Real-time Transport Protocol over
UDP
<fmt> is a media format description. The fourth and any
subsequent sub-fields describe the format of the media.
If the protocol is RTP then the fmt contains RTP payload types
Offer/Answer Model for SDP
SIP uses the Offer/Answer Model for SDP.
This means that the media information must
be negotiated
Details of this model can be found in RFC 3264
http://www.ietf.org/rfc/rfc3264.txt
One party generates and Offer and the other
the Answer
If there are a number of possible media
options the first match in the Answer is the
one used
SDP Examples
Offer Answer
SDP Examples
Offer Answer
Real World SIP Examples

TRACE EXAMPLES
 Example # 1
1. Open the attached file and draw a
ladder diagram of the call.
Include audio in the diagram
2. What is happening on the call?
3. Do you see any problems with the
call?

C:\Documents and
Settings \jamieanders on\
 Example # 2
Attached is a SIP trace from an MST.
The call is dropping. This is not a
normal disconnect.
1. Does the call drop while being
established or afterwards?
2. Why is the call dropping?
3. Using the SIP RFC determine which
party is responsible for the call
dropping? C:\Documents and
Settings \jamieanders on\
 Example # 3
Attached is a sniffer trace from a SBC. The call is
dropping. This is not a normal disconnect.
IPs from the sniffer trace are:
SBC: 10.134.115.71
C:\Documents and

SM: 10.130.240.124 Settings \jamieanders on\

CM: 10.130.240.104

1. Does the call drop while being established or

afterwards?
2. Why is the call dropping?
3. Using the SIP RFC determine which party is responsible
for the call dropping?
Questions/Comments?
Thanks

Jamie Anderson
9054746085
jamieanderson@avaya.com