Preconditions For Call Setup
SIP has extensions to require preconditions.
Quality of service (QoS) can be supported in the network layer (IP layer 3)
and in the link layer below (layer 2). QoS in IP networks is independent of any
specific application and the network, therefore, need not be aware of the
specifics of the applications (be they telephony, multimedia, financial transac-
tions, or games). SIP is orthogonal to QoS.
Setting up an application such as a commercial-grade phone call with QoS
requires the support of valuable network resources (for example, giving prior-
ity to a media flow having a data rate of 100 kb/s for 30 minutes over a dis-
tance of 5,000 km). The authorization required to provide the network
resources for the SIP-initiated session involves complex procedures for
authentication, authorization, and accounting (AAA) that go beyond the top-
ics discussed here [16], [17], [18]. We will, therefore, limit the discussion of QoS
for SIP only for the simple case where the AAA issues can be ignored.
SIP enables user agents to establish sessions using the INVITE/ 200 /ACK
exchange. However, in order to establish an IP session with QoS, a more com-
plicated message exchange is required. The Integrated Services QoS protocol
assumed in these examples is the Resource Reservation Protocol (RSVP) [19].
However, the approach described here for SIP will also work with other QoS
approaches, such as setting the type of service (TOS) bits in the IP header used
in DiffServ [20].
A simplified approach to QoS would be to first establish a “best-effort” ses-
sion between user agents, then use a re-INVITEto set up the new QoS session.
However, since the SIP messaging is completely independent of the media, it
is entirely possible to successfully set up a session using SIP, only to have the
session fail because of lack of bandwidth for the media, in which case this
approach will fail. Also, there was a desire to mimic the behavior in the PSTN,
where the called party’s phone will not ring if there are not sufficient resources
(that is, trunks) to complete the call if answered. The approach described here
was developed by the PacketCable consortium [21] for the Voice over Cable
Modem project. The call flow is shown in Figure 6.9.
This call flow makes use of three extensions to SIP. The first is Early Media
[22], which allows SDP to be present in the provisional 183 Session
Progressresponse. This allows an addition media (SDP) handshake between
the user agents necessary to establish the QoS prior to the call being answered.
The second is the Reliable Provisional Responses extension to SIP, which allows
a lost provisional response such as a 183 to be detected and retransmitted (see
the sidebar “Message Retransmissions in SIP”). The receipt of the 183
response is indicated by the PRACK(Provisional Response ACKnowledgement)
[23] message. The third extension is the use of the COMET(preCOnditions
MET) [24] method, which allows the UAS to indicate the QoS preconditions
SIP Overview 121