draft-ietf-sipping-early-media-00.txt   draft-ietf-sipping-early-media-01.txt 
Internet Engineering Task Force SIPPING WG Internet Engineering Task Force SIPPING WG
Internet Draft G. Camarillo Internet Draft G. Camarillo
Ericsson Ericsson
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
draft-ietf-sipping-early-media-00.txt draft-ietf-sipping-early-media-01.txt
October 17, 2003 November 18, 2003
Expires: December, 2003 Expires: May, 2004
Early Media and Ringing Tone Generation Early Media and Ringing Tone Generation
in the Session Initiation Protocol in the Session Initiation Protocol
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 3, line 9 skipping to change at page 3, line 9
Information ......................................... 9 Information ......................................... 9
5 Alert-Info Header Field ............................. 9 5 Alert-Info Header Field ............................. 9
6 Acknowledgments ..................................... 10 6 Acknowledgments ..................................... 10
7 Authors' Addresses .................................. 10 7 Authors' Addresses .................................. 10
8 Bibliography ........................................ 10 8 Bibliography ........................................ 10
1 Introduction 1 Introduction
Early media refers to media (e.g., audio and video) that is exchanged 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 before a particular session is accepted by the called user. Within a
dialog, early media place from the moment the initial INVITE is sent dialog, early media occurs from the moment the initial INVITE is sent
until the UAS generates a final response. It may be unidirectional or until the UAS generates a final response. It may be unidirectional or
bi-directional, and can be generated by the caller, the callee, or bi-directional, and can be generated by the caller, the callee, or
both. Typical examples of early media generated by the callee are both. Typical examples of early media generated by the callee are
ringing tone and announcements (e.g., queuing status). Early media ringing tone and announcements (e.g., queuing status.) Early media
generated by the caller typically consist of voice commands or DTMF generated by the caller typically consists of voice commands or DTMF
tones to drive IVRs. tones to drive IVRs.
The basic SIP spec [1] only supports very simple early media. In The basic SIP spec [1] only supports very simple early media. In
order to support fully-featured early media, UAs need to implement order to support fully-featured early media, UAs need to implement
some extensions in addition to the basic SIP spec. This document some extensions in addition to the basic SIP spec. This document
describes two models to implement early media and the extensions describes two models to implement early media and the extensions
needed in each model. needed in each model.
Section 2 describes the offer/answer model in absence of early media, Section 2 describes the offer/answer model in absence of early media,
and Section 3 introduces the gateway model. In this model, the early and Section 3 introduces the gateway model. In this model, the early
skipping to change at page 8, line 6 skipping to change at page 8, line 6
SIP, as opposed to other signalling protocols, does not provide an SIP, as opposed to other signalling protocols, does not provide an
early media indicator. That is, there is no information about the early media indicator. That is, there is no information about the
presence or absence of early media in SIP. Such an indicator could be presence or absence of early media in SIP. Such an indicator could be
potentially used to avoid generation of local ringing tone by the UAC potentially used to avoid generation of local ringing tone by the UAC
when UAS intends to provide in-band ringing tone or some type of when UAS intends to provide in-band ringing tone or some type of
announcement. However, due to the way SIP works, such an indicator announcement. However, due to the way SIP works, such an indicator
would, in the majority of the cases, be of little use. would, in the majority of the cases, be of little use.
One important reason that would limit the benefit of a potential One important reason that would limit the benefit of a potential
early media indicator is the loosely coupling between SIP signalling early media indicator is the loose coupling between SIP signalling
and the media path. SIP signalling traverses a different path than and the media path. SIP signalling traverses a different path than
the media. The media path is typically optimized to reduce the end- the media. The media path is typically optimized to reduce the end-
to-end delay (e.g., minimum number of intermediaries) while the SIP to-end delay (e.g., minimum number of intermediaries) while the SIP
signalling path typically traverses a number of proxies providing signalling path typically traverses a number of proxies providing
different services for the session. Due to that reason, it is very different services for the session. Due to that reason, it is very
likely that the media packets with early media reach the UAC before likely that the media packets with early media reach the UAC before
any SIP message which could contain an early media indicator. any SIP message which could contain an early media indicator.
Nevertheless, sometimes, SIP responses arrive at the UAC before any Nevertheless, sometimes, SIP responses arrive at the UAC before any
media packet. There are situations when the UAS intends to send early media packet. There are situations when the UAS intends to send early
skipping to change at page 9, line 7 skipping to change at page 9, line 7
receives media from the PSTN over a circuit, and sends it to the IP receives media from the PSTN over a circuit, and sends it to the IP
network. The gateway is not aware of the contents of the media, and network. The gateway is not aware of the contents of the media, and
it does not exactly know when the transition from early to regular it does not exactly know when the transition from early to regular
media takes place. From the PSTN perspective, the circuit is a media takes place. From the PSTN perspective, the circuit is a
continuous source of media. continuous source of media.
4 The Application Server Model 4 The Application Server Model
The application server model consists of having UAS behave as an The application server model consists of having UAS behave as an
application server to establish early media sessions with the UAC. application server to establish early media sessions with the UAC.
The UAC indicates support for the early-session disposition type The UAC indicates support for the early-session disposition type
(defined in draft-camarillo-sipping-early-disposition) using the (defined in [6]) using the early-session option tag. This way, UASs
early-session option tag. This way, UASs know that they can keep know that they can keep offer/answer exchanges for early media
offer/answer exchanges for early media (early-session disposition (early-session disposition type) and for regular media (session
type) and for regular media (session disposition type) separate. disposition type) separate.
Sending early media using a different offer/answer exchange than the Sending early media using a different offer/answer exchange than the
one used for sending regular media helps avoid media clipping in case one used for sending regular media helps avoid media clipping in case
of forking. The UAC can reject or mute new offers for early media of forking. The UAC can reject or mute new offers for early media
without muting the sessions that will carry media when the original without muting the sessions that will carry media when the original
INVITE is accepted. The UAC can give priority to media received over INVITE is accepted. The UAC can give priority to media received over
the latter sessions. This way, the application server model the latter sessions. This way, the application server model
transitions from early to regular media at the right moment. transitions from early to regular media at the right moment.
Having a separate offer/answer exchange for early media also helps Having a separate offer/answer exchange for early media also helps
skipping to change at page 10, line 19 skipping to change at page 10, line 19
tone generation in both models. If, after following those rules, the tone generation in both models. If, after following those rules, the
UAC decides to play local ringing, it can then use the Alert-Info UAC decides to play local ringing, it can then use the Alert-Info
header field to generate it. header field to generate it.
6 Acknowledgments 6 Acknowledgments
Jon Peterson provided useful ideas on the separation between the Jon Peterson provided useful ideas on the separation between the
gateway model and the application server model. gateway model and the application server model.
Paul Kyzivat, Christer Holmberg, Bill Marshall, Francois Audet, John Paul Kyzivat, Christer Holmberg, Bill Marshall, Francois Audet, John
Hearty, Adam Roach and Rohan Mahy provided useful comments and Hearty, Adam Roach, Eric Burger, and Rohan Mahy provided useful
suggestions. comments and suggestions.
7 Authors' Addresses 7 Authors' Addresses
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Advanced Signalling Research Lab. Advanced Signalling Research Lab.
FIN-02420 Jorvas FIN-02420 Jorvas
Finland Finland
electronic mail: Gonzalo.Camarillo@ericsson.com electronic mail: Gonzalo.Camarillo@ericsson.com
skipping to change at page 11, line 9 skipping to change at page 11, line 9
Task Force, June 2002. Task Force, June 2002.
[3] J. Rosenberg and H. Schulzrinne, "Reliability of provisional [3] J. Rosenberg and H. Schulzrinne, "Reliability of provisional
responses in session initiation protocol (SIP)," RFC 3262, Internet responses in session initiation protocol (SIP)," RFC 3262, Internet
Engineering Task Force, June 2002. Engineering Task Force, June 2002.
[4] J. Rosenberg, "The session initiation protocol (SIP) UPDATE [4] J. Rosenberg, "The session initiation protocol (SIP) UPDATE
method," RFC 3311, Internet Engineering Task Force, Oct. 2002. method," RFC 3311, Internet Engineering Task Force, Oct. 2002.
[5] J. Rosenberg, "Interactive connectivity establishment (ICE): a [5] J. Rosenberg, "Interactive connectivity establishment (ICE): a
methodology for nettwork address translator (NAT) traversal for the methodology for network address translator (NAT) traversal for the
session initiation protocol (SIP)," internet draft, Internet session initiation protocol (SIP)," Internet draft, Internet
Engineering Task Force, July 2003. Work in progress. Engineering Task Force, July 2003. Work in progress.
[6] G. Camarillo, "The early session disposition type for the session
initiation protocol (SIP)," Internet Draft, Internet Engineering Task
Force, Oct. 2003. Work in progress.
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of claims of rights made available for publication and any assurances of
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/