Early Media

An example of a scenario where SDP may need to be sent in a provisional
response is an early-media scenario. In early-media scenarios, the media is estab-lished before the call has been accepted (i.e., before 200 OK is sent). These sce-narios are typical in the PSTN, where it is common to play announcements to the
caller before the call is answered. In this case, early media would flow from called
to caller. In other scenarios, it is also necessary to let early media flow from caller
to called. An example of these could be the toll-free routing services that prompt
the user for the telephone number before routing the call. In this case, the caller
would typically need to send DTMF tones before the call has been answered.
Early-media scenarios in SIP are typically implemented by having the called
party send back a 183 (Session progress) provisional response that includes an
SDP. If the early media needs to flow from caller to called, the SDP would contain
the address where media needs to be sent by the caller. If the early media needs
only to flow from called to caller (e.g., an early announcement), then the SDP
would indicate to the caller the address where RTCP reports need to be sent.
Another scenario where SDP needs to be sent in a provisional response is a
SIP call establishment with QoS preconditions. This scenario will be explained in
Chapter 21, and it also requires that provisional responses are delivered reliably.
In order to cope with the general issue of assuring reliability in provisional
response, the IETF has defined an extension to the SIP protocol. This extension is
specified in [RFC 3262], and introduces a new SIP method (PRACK) and an
option tag for this extension (100rel).
15.4.2 How It Works
Let us imagine, for instance, that John makes a call to his voice-mail system in order
to listen to his stored messages. In a typical setup, the voice mail first plays a wel-come announcement and then accepts the call (i.e., sends 200 OK). Once the call
is accepted, the voice mail starts playing the stored messages. In this case, the wel-come announcement is a form of early media. Let us see how this works in detail.
John ’ s UA would generate an INVITE request that includes a Supported header
with the option tag 100rel. When receiving the INVITE, the voice mail sends back
a 183 (Session progress) provisional response containing the SDP answer. This
response needs to be sent back reliably, so the voice mail includes in the response
a Require header that contains the option tag 100rel.
2
The response also con-tains a new header fi eld called RSeq, which will also be present in the subsequent
PRACK. RSeq allows the voice mail to know what provisional response the PRACK is
acknowledging.
When John ’ s UA receives the 183 response, it generates a PRACK request that
contains the received RSeq header field. When the PRACK request reaches the
voice mail, the voice mail is sure that the 183 response was delivered to the UAC.
The voice mail sends a 200 OK response to the PRACK. The voice mail plays the
welcome announcement, and when the announcement is done, the voice mail
2
The voice mail knows that it can require John’s UA to use PRACK because John signaled in the
request that this extension is supported.
15.4 Reliability of provisional responses
346 CHAPTER 15 Extending SIP
sends a 200 OK fi nal response to the INVITE (i.e., answers the call) and starts
playing the stored messages. This is shown in Figure 15.7, where we are assuming
that the fi rst 183 response was lost.
John VMS
INVITE
Supported: 100rel
183 Session progress
Require: 100rel
As PRACK is not received,
the VMS re-sends the
provisional response
183 Session progress
Require: 100rel
PRACK
200 OK (PRACK)
VMS plays welcome
announcement
200 OK (INVITE)
ACK
VMS plays stored messages
FIGURE 15.7
Readers may wonder what is the use of the 200 OK response to the PRACK
request. The 183 response is already acknowledged with the PRACK request, so
why generate another message? This has to do with our discussion at the begin-ning of the chapter. New SIP extensions have to comply with the SIP architectural
principles. One such principle is the Transactional principle, which states that
new messages added to SIP should comply with the request-response model. This
is important because many of the rules of operation in SIP are based on general
processing of requests and responses. This includes reliability mechanisms, routing
mechanisms, and state maintenance rules. For instance, if we add a new method
such as PRACK, we also need to consider that it will need to have its correspond-ing response. By doing this, for instance, we assure that proxies do not need to be
347
modified to handle the PRACK. Proxies are prepared to handle all new methods
in the same way, provided they follow the request-response mechanism.
In this case, the solution is less effi cient (one more message), but it is more
general, and therefore allows us to benefi t from underlying SIP rules of operation
and to leverage its extensible design.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License