SIP Messages

Two kinds of SIP messages exist: requests initiated by

clients, and responses returned from servers.
Every message contains a header that describes the details
of communication.
SIP is a text‐based protocol with message syntax and header
fields identical to Hypertext Transfer Protocol (HTTP).
SIP messages are sent over TCP or UDP with multiple
messages carried in a single TCP connection or UDP
datagram.
 Message Headers
You use message headers to specify the calling party, called
party, route, and message type of a call. The four groups of
message headers are as follows:
 General headers—Apply to requests and responses.
 Entity headers—Define information about the message body type
and length.
 Request headers—Enable the client to include additional request
information.
 Response headers—Enable the server to include additional
response information.
Message Headers
Message Headers
 Message Requests
SIP communication features six kinds of message requests (methods) which
enable user agents and network servers to locate, invite, and manage calls.
 INVITE—This method indicates that the user or service is invited to participate in a
session. It includes a session description and, for two‐way calls, the calling party
indicates the media type.
 ACK—These requests correspond to an INVITE request. They represent the final
confirmation from the end system and conclude the transaction initiated by the INVITE
command.
 OPTIONS—This method enables you to query and collect user agents and network server
capabilities.
 BYE—This method is used by calling and called parties to release a call.
 CANCEL—This request enables user agents and network servers to cancel any in progress
request.
 REGISTER—This method is used by clients to register location information with SIP
servers.
 Message Responses
 They are sent in response to requests and indicate call success or failure, including the status of
the server.
Message Responses
 Proxy Server Example
The operational steps in the proxy mode needed to bring a two‐way
call to succession are as follows:
1. The proxy server accepts the INVITE request from the client.
2. The proxy server identifies the location by using the supplied addresses and
location services.
3. An INVITE request is issued to the address of the location returned.
4. The called party user agent alerts the user and returns a success indication
to the requesting proxy server.
5. An OK (200) response is sent from the proxy server to the calling party.
6. The calling party confirms receipt by issuing an ACK request, which is
forwarded by the proxy or sent directly to the called party.
Proxy Server Example
 Redirect Server Example
The operational steps in the redirect mode to bring a two‐way call to
succession are as follows:
1. The redirect server accepts the INVITE request from the calling party and
contacts location services with the supplied information.
2. After the user is located, the redirect server returns the address directly to
the calling party. Unlike the proxy server, the redirect server does not issue
an INVITE.
3. The user agent sends an ACK to the redirect server acknowledging the
completed transaction.
4. The user agent sends an INVITE request directly to the address returned by
the redirect server.
5. The called party provides a success indication (200 OK), and the calling party
returns an ACK.
Redirect Server Example
 Quality of Service (QoS)
QoS refers to both class of service (CoS) and type of service (ToS).
The basic goal of CoS and ToS is to achieve the bandwidth and latency
needed for a particular application.
A CoS enables a network administrator to group different packet
flows, each having distinct latency and bandwidth requirements.
A ToS is a field in an Internet Protocol (IP) header that enables CoS to
take place.
Various tools are available to achieve the necessary QoS for a given
user and application.
 QoS issues
Voice over IP (VoIP) comes with its own set of problems.
QoS can help solve some of these problems—namely, packet loss, jitter, and
handling delay.
Some of the problems QoS cannot solve are propagation delay, codec delay,
sampling delay, and digitization delay.
A VoIP phone call can be equivalent to any other large expense you would
plan for; therefore, it is important to know which parts of the budget you
cannot change and which parts you might be able to control.
The International Telecommunication Union Telecommunication
Standardization Sector (ITU‐T) G.114 recommendation suggests no more than
150 milliseconds (ms) of end‐to‐end delay to maintain “good” voice quality.
 Any customer’s definition of “good” might mean more or less delay, so keep in mind that
150 ms is merely a recommendation.
 QoS Network Toolkit
In a well‐engineered network, it is
important to separate edge and
backbone functions to achieve the
best QoS possible.
The following tools are associated
with the edge of a network:
 Additional bandwidth
 Compressed Real‐Time Transport Protocol
(cRTP)
 Queuing
 Packet classification
 Shaping traffic flows and policing
 Fragmentation
The following issues associated with
the backbone of a network tools:
 High‐speed transport
 High‐speed queuing
 Edge Functions
When designing a VoIP network, edge functions usually correspond
to wide‐area networks (WANs) that have less than a T1 or E1 line of
bandwidth from the central site.
This is not a fixed rule but merely a rule of thumb to follow so that
you know when to use edge functions and when to use backbone
functions.
The first issue of major concern when designing a VoIP network is
bandwidth constraints.
Depending upon which codec you use and how many voice samples
you want per packet, the amount of bandwidth per call can increase
drastically.
Codec Type and Sample Size Effects on Bandwidth
 Bandwidth 
 After reviewing this table, you might be asking yourself why 24 kbps of bandwidth is consumed
when you’re using an 8‐kbps codec.
 This occurs due to a phenomenon called “The IP Tax.” G.729 using two 10‐ms samples consumes 20
bytes per frame, which works out to 8 kbps.
 The packet headers that include IP, RTP, and User Datagram Protocol (UDP) add 40 bytes to each
frame.
 This “IP Tax” header is twice the amount of the payload.
 Using G.729 with two 10‐ms samples as an example, without RTP header compression, 24 kbps are
consumed in each direction per call.
 Although this might not be a large amount for T1 (1.544‐mbps), E1 (2.048‐mbps), or higher circuits,
it is a large amount (42 percent) for a 56‐kbps circuit.
 Also, keep in mind that the bandwidth in the table does not include Layer 2 headers (PPP, Frame
Relay, and so on). It includes headers from Layer 3 (network layer) and above only.
 Therefore, the same G.729 call can consume different amounts of bandwidth based upon which
data link layer is used (Ethernet, Frame Relay, PPP, and so on).
 Compressed Real‐Time Transport Protocol (cRTP)
 To reduce the large percentage of bandwidth consumed by a G.729 voice call, you can use cRTP.
 cRTP enables you to compress the 40‐byte IP/RTP/UDP header to 2 to 4 bytes most of the time.
 With cRTP, the amount of traffic per VoIP call is reduced from 24 kbps to 11.2 kbps.This is a major
improvement for low‐bandwidth links. A 56‐kbps link, for example, can now carry four G.729 VoIP
calls at 11.2 kbps each.
 cRTP uses some of the same techniques as Transmission Control Protocol (TCP) header compression.
In TCP header compression, the first factor‐of‐two reduction in data rate occurs because half of the
bytes in the IP and TCP headers remain constant over the life of the connection.
 The big gain, however, comes from the fact that the difference from packet to packet is often
constant, even though several fields change in every packet. Therefore, the algorithm can simply add
1 to every value received.
 You should use cRTP on any WAN interface where bandwidth is a concern and a high portion of RTP
traffic exists.
 You should not use cRTP on high‐speed interfaces, as the disadvantages of doing so outweigh the
advantages.
RTP Header Compression
 Queuing
 In queuing the concept of first in, first out (FIFO) exists, which means that if you are the first to
get in the line, you are the first to get out of the line. FIFO queuing was the first type of queuing
to be used in routers, and it is still useful depending upon the network’s topology.
 Today’s networks, with their variety of applications, protocols, and users, require a way to classify
different traffic. Weighted Fair Queuing (WFQ) uses multiple queues to separate flows and gives
equal amounts of bandwidth to each flow.
 This prevents one application, such as File Transfer Protocol (FTP), from consuming all
available bandwidth.
 WFQ ensures that queues do not starve for bandwidth and that traffic gets predictable service.
 Fair queuing dynamically identifies data streams or flows based on several factors. These data
streams are prioritized based upon the amount of bandwidth that the flow consumes.
 Fair queuing offers reduced jitter and enables efficient sharing of available bandwidth between all
applications.
 The network administrator must take care to ensure that the weights in WFQ are properly
invoked.
 Queuing
WFQ is simple to deploy, and it requires little additional effort from the
network administrator. Setting the weights with WFQ can further enhance its
benefits.
Customers who require more granular and strict queuing techniques can use
Custom Queuing (CQ) or Priority Queuing (PQ).
 Be sure to utilize great caution when enabling these techniques, however, as you might do more
harm than good to your network.
With PQ or CQ, it is imperative that you know your traffic and your
applications.
Many customers who deploy VoIP networks in low‐bandwidth environments
(less than 768 kbps) use IP RTP Priority or Low‐latency queuing (LLQ) to
prioritize their voice traffic above all other traffic flows.
 Packet Classification
To achieve your intended packet delivery, you must know how to properly weight
WFQ.
There are different weighting techniques and ways you can use them in networks
to achieve the amount of QoS you require.
 IP Precedence: refers to the three bits in the ToS field in an IP header. Enables a router to
group traffic flows based on the eight precedence settings and to queue traffic based upon
that information as well as on source address, destination address, and port numbers.
 Policy Routing: you can configure a defined policy for traffic flows and not have to rely
completely on routing protocols to determine traffic forwarding and routing. Policy routing
also enables you to set the IP Precedence field so that the network can utilize different
classes of service.
 RSVP: enables endpoints to signal the network with the kind of QoS needed for a particular
application. This is a great departure from the network blindly assuming what QoS
applications require.
 IP RTP Priority: a strict priority queue is created. You can use the IP RTP Priority feature to
enable use of the strict priority queuing scheme for delay‐sensitive data.
IP Header and ToS Field
 Traffic Shaping
Enables you to control the traffic going out of an interface to match its flow to the
speed of the remote, target interface and to ensure that the traffic conforms to
policies contracted for it.
You can use traffic shaping in the following situations:
 You can configure traffic shaping on an interface if you have a network with different access
rates. Suppose one end of the link in a Frame Relay network runs at 256 kbps and the other
end runs at 128 kbps. Sending packets at 256 kbps could cause the applications using the link
to fail.
 You can configure traffic shaping if you offer a subrate service. In this case, traffic shaping
enables you to use the router to partition your T1 or T3 links into smaller channels.
Prevents packet loss. It is especially important to use traffic shaping in Frame
Relay networks because the switch cannot determine which packets take
precedence and, therefore, which packets should be dropped when congestion
occurs.
 Backbone Networks
The backbone of the network is completely different than the edge of the
network, and you should not treat it with the same QoS mechanisms.
It is important to note that both edge QoS and backbone QoS must work
together to achieve the proper QoS for the various applications which might
be traversing a network.
As a rule of thumb, it is wise to use high‐speed congestion avoidance
techniques in the backbone as well as some form of high‐speed transmission,
such as POS/Synchronous Digital Hierarchy (SDH) or IP + ATM inter‐working.
You can achieve IP QoS using several different mechanisms. The actual
transport mechanism you choose is not as important as verifying that all the
tools you need are present to service your applications.
 Rules of Thumb for QoS
Before implementing QoS on the edge of a network, ask the following questions:
1. Do you have a low‐bandwidth WAN circuit?
If yes, use cRTP. Also, choose a fragmentation method.
2. Does your traffic need to be prioritized on your WAN circuits?
If yes, use some form of queuing. (LLQ is recommended first, followed by IP RTP
Priority)
3. Do you have a hub‐and‐spoke Frame Relay network or another need for shaping your
traffic flows?
If yes, select traffic shaping.
Before implementing QoS on the backbone of a network, ask the following
questions:
1. Have you chosen your high‐speed networking technology?
2. Have you ensured that the edge QoS is compatible with the backbone QoS or CoS?
3. Have you utilized a congestion avoidance mechanism on highly utilized high‐speed circuits?
These circuits must have a high percentage of loss‐tolerable protocols (such as TCP).