Coping with Early Media in the Session Initiation Protocol (SIP)
draft-stucker-sipping-early-media-coping-03

 
Document Type Expired Internet-Draft (individual)
Last updated 2006-10-19
Stream (None)
Intended RFC status (None)
Formats
Expired & archived
plain text pdf html
Stream Stream state (No stream defined)
Document shepherd No shepherd assigned
IESG IESG state Expired
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-stucker-sipping-early-media-coping-03.txt

Abstract

Several mechanisms for early media have been proposed in the past, each attacking a different aspect of the problem. A good example of this is RFC-3960 which talks about two models of early media: the gateway model, and the application model. The gateway model uses a series of offer/answer exchanges to control the rendering of early media, but breaks down in the presence of forking (as mentioned in section 3 of RFC-3960). The application model relies on the UAS to know when it is generating early media and use RFC-3959 to keep early media and regular media streams separate to avoid clipping. Even in the presence of the recommendations in RFC-3960 some problems exist within SIP in the area of early media. Although some of these challenges are likely to never be overcome, for example when interworking with a PSTN gateway that does not take into account CPG or ACM messages (in the case of ISUP). However, the potential to improve on what is already there does exist. This document attempts to go into more detail around early media where RFC-3960 left off, what sorts of mechanisms are in use today in existing implementations to deal with the challenges at hand, derives requirements and a possible mechanism to improve upon the current model. In addition, the document goes into other areas that can complicate or be complicated by the presence of early media (especially with forking) such as SRTP keying and media flow authorization.

Authors

Brian Stucker (bstucker@nortel.com)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)