Subject: [Sip] New draft on early media

From: Richard Barnes <[email-masked]>
Date: Thu, 08 Feb 2007 14:46:55 -0500

After the big discussions on SIPPING last summer about how to fix early 
media, and the reaction at the last couple of IETFs to Brian Stucker's 
draft on how to cope with it, I've put together a draft to try to 
consolidate all of the discussions and move toward a solution.

draft-barnes-sip-em-ps-req-sol includes three important parts:

1. Problem statement: Although there's lots of definitions of "early 
media" in existing documents, I think there's broad agreement that the 
stuff that causes problems is media that arrives before an SDP 
offer/answer exchange has completed.  The problem is therefore to enable 
the SDP exchange(s) in the INVITE transaction to complete more quickly, 
and make it more difficult (if not impossible) to send media before it 
has completed.  We are explicitly NOT trying to prevent the sending of 
media before a 200/OK or other closing of an INVITE transaction.

2. Requirements: Here, we try to create a consolidated list of 
requirements for an early media fix.

3. Analysis of Solutions: Lots of folks have put forward proposals to 
fix the early media problem.  This section tries to enumerate most of 
them and evaluate them against the requirements in section 2.

It hasn't shown up yet on the I-D tracker, so I've attached a copy.

--Richard

Network Working Group                                          R. Barnes
Internet-Draft                                               M. Lepinski
Intended status: Informational                          BBN Technologies
Expires: July 19, 2007                                  January 15, 2007

  Early Media in SIP: Problem Statement, Requirements, and Analysis of
                               Solutions
                   draft-barnes-sip-em-ps-req-sol-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 19, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   The Session Initiation Protocol (SIP) enables and permits endpoints
   in an INVITE transaction to send media packets before an SDP offer/
   answer exchange has completed; we refer to such media packets as
   early media.  The use of early media is common in current SIP
   implementations, and causes several problems, which have been
   documented elsewhere.  This document puts forward the goal of
   modifying SIP so that compliant implementations will complete an SDP

Barnes & Lepinski         Expires July 19, 2007                 [Page 1]

Internet-Draft                em-ps-req-sol                 January 2007

   exchange before sending media, and lays out high-level requirements
   for such a solution.  The set of possible solutions is then laid out,
   and each possibility examined in light of these requirements.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Elmination of Early Media  . . . . . . . . . . . . . . . .  5
     2.2.  Additional Messaging . . . . . . . . . . . . . . . . . . .  6
     2.3.  Interoperability with current SIP standards  . . . . . . .  6
     2.4.  Interoperability with the PSTN . . . . . . . . . . . . . .  6
     2.5.  Denial of Service  . . . . . . . . . . . . . . . . . . . .  6
     2.6.  IPR Constraints  . . . . . . . . . . . . . . . . . . . . .  6
   3.  Early Media Solutions  . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Minimizing SDP completion time . . . . . . . . . . . . . .  7
       3.1.1.  Fast completion of INVITE transaction  . . . . . . . .  7
       3.1.2.  Elimination of offer from INVITE . . . . . . . . . . .  8
       3.1.3.  Provisional Responses  . . . . . . . . . . . . . . . .  8
       3.1.4.  Separate INVITE transaction  . . . . . . . . . . . . .  9
       3.1.5.  Non-INVITE SIP Mechanisms  . . . . . . . . . . . . . .  9
       3.1.6.  Non-SIP mechanisms . . . . . . . . . . . . . . . . . . 10
     3.2.  Handling remaining media . . . . . . . . . . . . . . . . . 11
       3.2.1.  Unreliable SDP answer  . . . . . . . . . . . . . . . . 11
       3.2.2.  Backwards-compatibility  . . . . . . . . . . . . . . . 11
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 14

Barnes & Lepinski         Expires July 19, 2007                 [Page 2]

Internet-Draft                em-ps-req-sol                 January 2007

1.  Introduction

   A primary function of the Session Initiation Protocol (SIP,
   [RFC3261]) is to carry SDP messages that form an SDP offer/answer
   exchange [RFC3264].  The offer/answer exchange serves to negotiate
   the parameters necessary for the two end hosts to send multimedia to
   each other, including transports, port numbers, codecs, and security
   parameters (e.g., MIKEY [RFC3830]).  In the most common SIP INVITE
   transaction, the calling party (UAC) is the SDP offerer and the
   called party (UAS) is the SDP answerer; in this scenario, the SDP
   offer is carried in the SIP INVITE request, and the SDP answer in the
   200/OK response.

   Because there is often a substantial delay between the sending of an
   INVITE and the receipt a 200/OK, this assignment of SDP messages to
   SIP messages creates a substantial delay between an SDP offer and an
   SDP answer.  Consequently, there is a period of time between the two
   messages in which the two parties have asymmetric information: The
   called party has knowledge of both the SDP offered by the calling
   party and of his own intended response, while the calling party knows
   only the offer he sent.  Given this information, the called party has
   all the information he needs to begin sending media to the calling
   party (because this was included in the SDP offer); moreover, he can
   send these media without sending an SDP answer to the calling party.
   We define early media as media sent before the completion of an SDP
   offer/answer exchange.

   Ours is a different definition than is used in RFC 3960 [RFC3960],
   which defines early media as "media ... that is exchanged before a
   particular session is accepted by the called user."  The definition
   in RFC 3960 is consistent with the current usage of SDP within the
   SIP INVITE transaction, but at the same time conflates two functions
   of SIP: Negotiation of session-layer parameters (through the SDP
   offer/answer) and communication of an application-layer request and
   acceptance of a session (by the INVITE and 200/OK messages).  As
   suggested above, it is this assignment of SDP messages to SIP
   messages that creates the possibility of early media.

   Early media is known to create several problems for SIP operation:

   o  Call failure: When endpoints use early media for an extended
      period of time, timers can fire to close the UAC INVITE
      transaction before the early media finish and the UAS sends a
      200/OK.  This causes the session proposed in the initial INVITE to
      be dropped by the UAC, and in some implementations, the flow of
      media is cut off.

Barnes & Lepinski         Expires July 19, 2007                 [Page 3]

Internet-Draft                em-ps-req-sol                 January 2007

   o  Confidentiality: Techniques such as MIKEY [RFC3830]and Security
      Descriptions [RFC4568], which use SDP to establish keys for media
      security protocols, require a full SDP offer/answer exchange to
      negotiate keys.  Such keying techniques are therefore incompatible
      with early media.

   o  Access Control: In the presence of early media, a UAC must
      anticipate that media will arrive without any signaling, and thus
      is obliged to receive (and presumably render) media received from
      any host on the Internet.

   o  Interaction with forking/retargeting: When an INVITE from a UAC is
      forked or retarget to UASs that send early media, because these
      UASs send no signaling, the UAC has no information besides the
      media itself on which to base a decision as to which media stream
      to render.

   o  Denial of Service: Early media is the basis of the "voice hammer"
      attack, described in [draft-ietf-mmusic-ice].

   To date, attempts to deal with early media have failed to solve all
   of the problems caused by early media.  Such work typically has
   started from the assumption that early media is a necessary component
   of SIP (largely due to RFC 3398 [RFC3398] and RFC 3578 [RFC3578]) and
   has generally avoided the issue of whether key use-cases (such as
   PSTN interoperability) can be satisfied without the use of early
   media.  RFC 3960 presents two models for managing early media
   streams, which mitigate early-media related problems in some cases.
   However, the document neither specifies the models in sufficient
   detail nor makes their implementation a mandatory part of SIP.  More
   recently, Stucker has written a draft extending 3960 by detailing a
   more current set of early media coping mechanisms, and proposing a
   solution that uses additional SDP attributes to mitigate the problems
   caused by early media [draft-stucker-sipping-early-media-coping].
   Although Stucker's proposed solution addresses several of the above
   problems, it stops short of requiring an SDP exchange before media
   transmission.  Ejzak has also authored a recent draft regarding early
   media [draft-ejzak-sipping-p-em-auth].  However, his draft proposes
   the use of a p-header to prevent fraudulent uses of early media,
   which are largely orthogonal to the early media problems considered
   in this draft.

   In contrast to previous approaches, this draft proposes to address
   the problems of early media by normatively modifying the SIP protocol
   to preclude the transmission of early media.  In order to remove the
   possibility of early media, this modification must ensure (to the
   greatest extent possible) that the SDP offer/answer exchange has
   completed before any media are sent.  At a high level, this goal can

Barnes & Lepinski         Expires July 19, 2007                 [Page 4]

Internet-Draft                em-ps-req-sol                 January 2007

   be approached from two directions: To complete the SDP exchange as
   quickly and reliably as possible, and to forbid sending of media
   before completion.  A successful solution will combine these two
   approaches, since as progress is made on the former, the latter
   becomes less onerous.

   The goal of this draft is three-fold: First, in the above, we have
   provided a consolidated statement of the early media problem, namely
   that the presence of media before the completion of an SDP offer/
   answer exchange is harmful to the functioning of SIP calls.  Second,
   Section 2 specifies requirements for an update to SIP that eliminates
   early media, in an effort to consolidate the requirements that have
   been presented to date and enable discussion of solutions.  Third,
   Section 3 lays out the space of possible solutions, enumerating the
   trade-offs entailed by each so that consensus can be reached on the
   direction that should be taken by the SIP working group.

2.  Requirements

   There have been several informal proposals to date that would
   mitigate or eliminate early media, but each was disqualified in turn
   by requirements as perceived by the SIP and SIPPING working groups.
   In this section, we seek to create a consolidated set of requirements
   so that a consistent evaluation of solutions can move forward.
   Below, we use the term "proposed solution" to refer to a protocol
   that normatively updates the relevant standards (e.g., RFCs 3261,
   3264, and 3398) in such a way as to eliminate early media, while we
   use the term "current SIP" to refer to SIP as defined in RFC 3261 and
   related documents.

2.1.  Elmination of Early Media

   The proposed solution must define a normative modification to the SIP
   protocol (and other relevant protocols) that minimizes or eliminates
   the possibility of early media in SIP sessions; i.e., it should
   minimize or eliminate the possibility that a compliant implementation
   could send media before an SDP offer/answer exchange has completed.
   Solutions in which receipt of SDP-bearing messages is explicitly
   acknowledged (e.g., an INVITE/200/ACK or INVITE/180/PRACK exchange)
   are preferred, since these acknowledgements are the only way to
   completely eliminate early media (otherwise the answerer cannot know
   with certainty that the offerer has received his answer).  If a
   proposed solution does not include such acknowledgements, it must
   define UAS behaviors that minimize the probability of the UAS sending
   media before the UAC has received the SDP answer.

Barnes & Lepinski         Expires July 19, 2007                 [Page 5]

Internet-Draft                em-ps-req-sol                 January 2007

2.2.  Additional Messaging

   In order to minimize the impact of the proposed solution on call-
   setup times, the proposed solution should minimize the number of
   signaling messages that are required in addition to those used by
   current SIP.  Proposed solutions should accommodate the fact that
   messages sent "on the media path" (i.e. directly between the two SIP
   endpoints) will often be unable to reach their destinations due to
   current media gating techniques.

2.3.  Interoperability with current SIP standards

   The proposed solution must define how entities implementing it will
   interact with entities that implement the current SIP protocol.  The
   proposed solution should minimize the set of conditions under which a
   call would fail in such a hybrid scenario, but not in a scenario in
   which both endpoints use current SIP.

2.4.  Interoperability with the PSTN

   The proposed solution must be compatible with the creation of
   gateways to the PSTN, and may define normative updates as necessary
   to RFC 3398 and RFC 3578.

2.5.  Denial of Service

   The proposed solution must minimize the possibility of new denial of
   service attacks by minimizing the amount of state that is kept by a
   UAS prior to the completion of an offer/answer exchange.  Ideally, no
   state in addition to the SIP INVITE state machine will be required
   (i.e., the initial SDP offer/answer will be conducted statelessly).

2.6.  IPR Constraints

   The proposed solution must, to the extent possible, avoid dependence
   on technologies on which there are known IPR constraints, as this
   tends to hinder adoption.

3.  Early Media Solutions

   The fundamental goal of a system to eliminate early media is to
   ensure that an SDP offer/answer exchange has completed before media
   packets are sent.  Such a system will combine two approaches:
   Completing the SDP exchange as quickly and reliably as possible, and
   providing restrictions on the sending and receiving of media before
   such completion.  A priori, neither approach is at odds with the
   requirements stated above, so we explore the possible mechanisms for

Barnes & Lepinski         Expires July 19, 2007                 [Page 6]

Internet-Draft                em-ps-req-sol                 January 2007

   accomplishing each.  Many of the solutions below have been suggested
   on the SIP and SIPPING mailing lists already, sometimes by multiple
   people independently; we have not made an effort to attribute them.

3.1.  Minimizing SDP completion time

   The simplest way to preclude early media is for the SIP endpoints to
   ensure that an SDP exchange has completed before media packets are
   generated.  In order to convey the SDP messages comprising this
   exchange, it is necessary to modify the way that SDP messages are
   carried within SIP session establishment.  There are a variety of
   mechanisms for achieving this goal, including modifications to
   messages within the INVITE transaction, other non-INVITE SIP
   mechanisms, and protocols outside of SIP.

3.1.1.  Fast completion of INVITE transaction

   Perhaps the most straightforward approach to quickly completing an
   SDP offer/answer exchange would be to simply complete the SDP
   exchange already inherent in the SIP INVITE transaction more quickly:
   To do this, the UAS would send a 200/OK response as soon as an INVITE
   message is received, rather than awaiting an indication from a higher
   layer to do so (formally, this moves both the client and server
   INVITE transactions to the Terminated state as quickly as possible).
   In essence, this is a change to the semantic meaning of the "200/OK"
   response; rather than indicating that an application-layer session
   has begun, it would indicate that an media association had been
   established, in the sense that all necessary parameters are
   established for media to flow.  A separate message (for instance, an
   UPDATE [RFC3311]) could be used to indicate that an application-layer
   user is ready to begin exchanging media.

   Quickly completing the INVITE transaction has the potential to
   eliminate early media entirely: Because the 200 response is
   explicitly acknowledged by the ACK message, both endpoints can be
   sure that the SDP exchange is complete when the ACK is transmitted.
   In ISUP terms, a 200/OK response used in this way would correspond to
   an ACM (rather than to an ANM, as in RFC 3398), and the UPDATE (or
   similar message) would correspond to the ANM.  The failing of this
   approach is its interaction with SIP forking: Since a 200/OK message
   moves both endpoints to the Terminated state, the first UAS to
   respond would automatically cut off all other branches of the call.
   Although this issue could likely be resolved with a modification to
   rules for SIP forking, it could inhibit backward compatibility in the
   interim.

Barnes & Lepinski         Expires July 19, 2007                 [Page 7]

Internet-Draft                em-ps-req-sol                 January 2007

3.1.2.  Elimination of offer from INVITE

   One way to ensure that a UAS cannot send media until an SDP exchange
   has completed would be to forbid a UAC from including an SDP offer in
   its INVITE message, so that the SDP offer would be sent by the UAS in
   either a reliable provisional response or the 200/OK message, and the
   answer in the UAC's PRACK or ACK message.  This behavior is allowed
   by current SIP, but does not eliminate early media because it is not
   mandatory.  At first blush, reusing the existing INVITE transaction
   in this way seems appealing: Because it is a subset of behaviors
   allowed by current SIP, it will interact well with current SIP
   endpoints, and it introduces no additional messaging or state
   machinery.  However, if either endpoint does not support reliable
   provisional responses [RFC3262], this solution would prevent any
   media flows before the sending of a 200/OK (distinct from an SDP
   answer), which would cause many existing SIP applications to fail
   (including a large number of PSTN applications as they pass through
   gateways).  In addition, the ACK message is not a reliable mechanism
   for transporting SDP answers, since the UAC (as an SDP answerer)
   receives no notification that the UAS has received its answer.

3.1.3.  Provisional Responses

   Within the INVITE transaction, the only other messages sent from UAS
   to UAC (besides the INVITE, 200, and ACK messages) that could carry
   SDP information are provisional (101-199) responses (response type
   100 is excepted because it is often not retransmitted by proxies).
   Upon receipt of an INVITE message, a UAS would respond with a 1xx
   message that would complete the SDP offer/answer.  Some have
   suggested use of the 183 (Call Progress) message for this purpose, as
   is done in ICE, though another existing or new response type could in
   principle be used.

   This approach has the advantage that if the UAS does not support this
   use of provisional messages, then the call will proceed in the same
   way as with current SIP.  For PSTN gateways, this approach only
   requires the sending or understanding a single additional message.
   However, it would be difficult to use provisional responses to
   eliminate early media, since this would require them to be reliable.
   Though there exist both SIP (PRACK) and non-SIP (ICE binding request)
   messages that can acknowledge provisional responses, AT&T holds IPR
   related to reliable provisional responses.  This has limited the
   deployment of PRACK, and may have the same effect on relevant
   portions of ICE.

Barnes & Lepinski         Expires July 19, 2007                 [Page 8]

Internet-Draft                em-ps-req-sol                 January 2007

3.1.4.  Separate INVITE transaction

   The Application Server model of RFC 3960 provides an SDP exchange for
   early media by conducting separate INVITE transactions for an "Early"
   session and for the "Final" session.  In a recently proposed
   realization and extension of this model
   [draft-stucker-sipping-early-media-indirection], any entity along the
   signaling path can include an EMIND (Early Media Indirection) header
   that will prompt the UAC to initiate a separate INVITE transaction
   with a third entity, e.g., a media server to provide ring-back tones
   or balance announcements.  This transaction establishes an "Early
   Session," which is terminated when the orignal INVITE transaction is
   completed and the "Final Session" begun.

   Using a separate INVITE transaction for early media has several
   advantages: Since the answer in a 2xx response triggers an ACK in the
   early INVITE transaction, it can be used to completely prevent early
   media.  Prospects for interoperability with current SIP
   implementations are good, since no new mechanisms are employed; in
   particular, the EMIND header will be ignored by implementations that
   do not support it.  And the entire burden of state maintenance is
   placed on the UAC, which must manage both INVITE transactions.
   However, using two separate INVITE transactions incurs significant
   siganling overhead, and it is unclear that this approach, at least as
   currently specified, can eliminate early media from PSTN gateways
   that are unable to separate early and regular media.

3.1.5.  Non-INVITE SIP Mechanisms

   There are other SIP messages that could be used to carry an SDP
   answer that would be formally outside of the INVITE transaction, but
   could be contemporaneous with it.  Because these messages would be
   outside the INVITE transaction, a separate mechanism may be required
   to associate the transmitted SDP answer with the SDP offer in the
   INVITE request.

3.1.5.1.  INFO and UPDATE

   The SIP INFO method [RFC2976] is currently used to convey additional
   signaling information in the middle of a session, after the INVITE
   transaction has terminated.  However, it could also be used to convey
   information relevant to an INVITE transaction, subject to the
   constraint in RFC 2976 that an INFO request must not change the state
   of a SIP call.  While receipt of an SDP answer in an INFO request
   would change state at the TU layer (namely, in the UAC core), it
   would not change the transaction-layer state of the call.  INFO
   messages carrying SDP answers can be associated with the
   corresponding SDP offer by virtue of the fact that the INFO message

Barnes & Lepinski         Expires July 19, 2007                 [Page 9]

Internet-Draft                em-ps-req-sol                 January 2007

   carrying the answer will carry the same Call-ID as the INVITE message
   carrying the offer.  The SIP UPDATE method [RFC3311]could be likewise
   used (in fact, RFC 3311 lists early media as the main motivation for
   UPDATE, and RFC 3960 uses UPDATE messages as the basis for its
   gateway model).

   Current standards require that the UAS in an INFO or UPDATE
   transaction to send a response to an INFO or UPDATE message, so these
   messages would provide a reliable transport for SDP answers.  Just as
   with provisional responses, using INFO or UPDATE messages to convey
   SDP answers is backwards-compatible, and requires minimal
   modification to PSTN gateways.  One potential drawback is that as
   currently specified, UPDATE and INFO messages cannot be sent before a
   dialog is established (i.e., a 101-199 response is sent).  If not
   changed or lifted by the proposed solution, this restriction could
   limit the efficacy of UPDATE (or INFO) for quickly concluding an SDP
   exchange, since the required 1xx message would introduce additional
   delay in the transmission of the SDP answer.

3.1.5.2.  Other Response Codes

   In current SIP, if a UAS wishes to send early media in response to an
   INVITE, it will send the media without any SIP response.  As an
   alternative, the UAS wishing to send early media could send a 401
   response requiring http-auth with null authentication.  The UAC would
   then signal its willingness to receive the media by sending a new
   INVITE (with the nonce for null authentication).  In this model, the
   UAS's SDP answer would be sent in its 401 response, and the UAC's re-
   INVITE would confirm receipt of this answer.

   Although this proposal does provide a reliable transport for SDP
   answers, it has significant drawbacks: In addition to adding
   significant messaging overhead, it requires both endpoints to
   maintain state across INVITE transactions (in addition to the nonce
   required by null authentication).  And the prospects for backward
   compatibility with this solution are bleak: All calls to current SIP
   endpoints will fail unless the endpoints support the indicated
   authentication mechanisms, and forked calls would show unpredictable
   behavior due to the Heterogeneous Error Response Forking Problem
   (HERFP).

3.1.6.  Non-SIP mechanisms

   There are some proposals to use protocols other than SIP to resolve
   the problem of early media in SIP.  For instance, a lower-level
   protocol could be defined that could negotiate and SDP session that
   could then be used by SIP, much as TLS negotiations are conducted
   before HTTPS data are sent.  However, such a protocol would have to

Barnes & Lepinski         Expires July 19, 2007                [Page 10]

Internet-Draft                em-ps-req-sol                 January 2007

   duplicate many SIP features, and any such solution would require SIP
   entities to implement an additional protocol stack, which would have
   negative consequences for backward-compatability and PSTN
   interoperability.

3.2.  Handling remaining media

   Early media can be completely eliminated only if neither party sends
   media until it is assured that the SDP offer/answer exchange is
   completed.  Of course, this is only possible when both endpoints
   support the proposed solution and the SDP answer is carried in a
   reliable message: In this optimal case, both the offerer and the
   answerer must not send media until they have received assurance that
   the SDP exchange has completed.  The proposed solution will specify
   the two remaining cases.

3.2.1.  Unreliable SDP answer

   If both endpoints support the solution, but the solution uses an
   unreliable message to carry the SDP answer, then the offerer can be
   assured that the SDP exchange has completed (because he has received
   the answer), but the answerer cannot.  In this case, the offerer must
   not send media until the SDP exchange has completed.  The proposed
   solution should provide an explicit, deterministic criterion for when
   the answerer may send media: For instance, the answerer may be free
   to send media after it receives media from the offerer, or after a
   timer fires that is set when the answer is sent.

3.2.2.  Backwards-compatibility

   Depending on the nature of the proposed solution, one party may not
   be able to know whether the other supports the solution.  If a party
   cannot know, then it must behave as if the other party does support
   the solution (otherwise, the solution would never be used).  If a
   party can be aware of the other party's support, then the solution
   should allow a supporting party to knowingly send early media to an
   non-supporting party, since to do otherwise -- to mandate that a
   supporting party behave as it would if the other party supported the
   solution -- is incompatible with existing SIP applications that use
   early media.  Nonetheless, an implementation of the solution should
   always avoid the use of early media; it should only send early media
   when it has received early media from a non-supporting endpoint.

4.  IANA Considerations

   This document makes no request of IANA.

Barnes & Lepinski         Expires July 19, 2007                [Page 11]

Internet-Draft                em-ps-req-sol                 January 2007

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

5.  Security Considerations

   The only new security concern that arises from this draft is the
   possibility of introducing new denial of service attacks.  The
   requirement addressing this concern is stated in Section 2.5 above.
   The performance of each candidate solution against this requirement
   is examined in the section where that solution's is proposed.

6.  Acknowledgements

7.  References

7.1.  Normative References

   [RFC3261]  "SIP: Session Initiation Protocol", June 2002.

   [RFC3264]  "An Offer/Answer Model with the Session Description
              Protocol (SDP)", June 2002.

7.2.  Informative References

   [RFC2976]  "The SIP INFO Method", October 2000.

   [RFC3262]  2, "Reliability of Provisional Responses in the Session
              Initiation Protocol (SIP)", June 2002.

   [RFC3311]  "The Session Initiation Protocol (SIP) UPDATE Method",
              September 2002.

   [RFC3398]  "Integrated Services Digital Network (ISDN) User Part
              (ISUP) to Session Initiation Protocol (SIP) Mapping",
              December 2002.

   [RFC3578]  "Mapping of Integrated Services Digital Network (ISDN)
              User Part (ISUP) Overlap Signalling to the Session
              Initiation Protocol (SIP)", August 2003.

   [RFC3830]  "MIKEY: Multimedia Internet KEYing", August 2004 2004.

   [RFC3960]  "Early Media and Ringing Tone Generation in the Session
              Initiation Protocol (SIP)", December 2004.

Barnes & Lepinski         Expires July 19, 2007                [Page 12]

Internet-Draft                em-ps-req-sol                 January 2007

   [RFC4568]  "Session Description Protocol (SDP) Security Descriptions
              for Media Streams", July 2006.

   [draft-ejzak-sipping-p-em-auth]
              "Private Header (P-Header) Extension to the Session
              Initiation Protocol (SIP) for Authorization of Early
              Media", January 2007.

   [draft-ietf-mmusic-ice]
              "Interactive Connectivity Establishment (ICE): A
              Methodology for Network Address Translator (NAT) Traversal
              for Offer/Answer Protocols", October 2006.

   [draft-stucker-sipping-early-media-coping]
              "Coping with Early Media in the Session Initiation
              Protocol (SIP)", October 2006.

   [draft-stucker-sipping-early-media-indirection]
              "Early Media INDirection (EMIND) in the Session Initiation
              Protocol (SIP)", October 2006.

Authors' Addresses

   Richard Barnes
   BBN Technologies
   9861 Broken Land Pkwy
   Columbia, Maryland  21046
   USA

   Phone: +1-410-290-6169
   Email: [email-masked]

   Matt Lepinski
   BBN Technologies
   10 Moulton St.
   Cambridge, Massachusetts  02138
   USA

   Phone: +1-617-873-5939
   Email: [email-masked]

Barnes & Lepinski         Expires July 19, 2007                [Page 13]

Internet-Draft                em-ps-req-sol                 January 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Barnes & Lepinski         Expires July 19, 2007                [Page 14]


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 12 Feb 2007 14:42:28 +0100

Hi,

I haven't had time to read the document yet, but I am not sure I agree
with the statement saying that the biggest problem is media arriving
before the SDP answer. In some environments such media will not even
reach the terminal, due to gating etc.

Many implementations DO send an SDP answer (or, at least an unreliable
"preview" of the SDP answer) before (or at the same time as) early media
is sent.

And, in the cases where implementations do NOT send an SDP answer before
they start sending early media - what behavior would you be able to
standardize?

Regards,

Christer 

> -----Original Message-----
> From: Richard Barnes [mailto:[email-masked]] 
> Sent: 8. helmikuuta 2007 21:47
> To: [email-masked]; [email-masked]
> Subject: [Sip] New draft on early media
> 
> After the big discussions on SIPPING last summer about how to 
> fix early media, and the reaction at the last couple of IETFs 
> to Brian Stucker's draft on how to cope with it, I've put 
> together a draft to try to consolidate all of the discussions 
> and move toward a solution.
> 
> 1. Problem statement: Although there's lots of definitions of 
> "early media" in existing documents, I think there's broad 
> agreement that the stuff that causes problems is media that 
> arrives before an SDP offer/answer exchange has completed.  
> The problem is therefore to enable the SDP exchange(s) in the 
> INVITE transaction to complete more quickly, and make it more 
> difficult (if not impossible) to send media before it has 
> completed.  We are explicitly NOT trying to prevent the 
> sending of media before a 200/OK or other closing of an 
> INVITE transaction.
> 
> 2. Requirements: Here, we try to create a consolidated list 
> of requirements for an early media fix.
> 
> 3. Analysis of Solutions: Lots of folks have put forward 
> proposals to fix the early media problem.  This section tries 
> to enumerate most of them and evaluate them against the 
> requirements in section 2.
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 12 Feb 2007 10:08:01 -0500

Christer,

Thanks for your comments.  Responses inline.

Cheers,
--Richard

> reach the terminal, due to gating etc.

Perhaps a better term would be "media sent before an SDP answer has been 
received".  As you point out, sending media before an SDP offer/answer 
exchange has completed poses the risk that that media will not arrive. 
To put it in the terms used in the document, media clipping is a problem 
caused by early (pre-SDP-answer) media, and thus one which this document 
seeks to solve.

> "preview" of the SDP answer) before (or at the same time as) early media

This is the behavior we would like to standardize -- that an SDP answer 
is *always* sent before media of any type.  What we're trying to do with 
this document is describe the requirements for how that answer is sent, 
and consolidate the many ways people have proposed to send it.

> they start sending early media - what behavior would you be able to

We would prefer that standards not allow this behavior -- that seems 
like the right thing to me.  What's a little trickier is that you'd like 
to not have the answerer sending media before the answer has *arrived*. 
  When the answer is carried in a reliable message, you could just 
forbid sending media before receipt has been confirmed.  When the 
transport is unreliable, the situation is a little less clear, but I 
think there's still possibilities for standardization, e.g., by 
forbidding answerers to send media until they've received media.  This 
is discussed in more length in the document.

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 12 Feb 2007 14:24:05 -0600

Hi Richard,

Forcing media cut-through to occur only after an Answer has been
received
does solve SOME of the early media problems. As others have mentioned,
there
are environments that operate like this already. I also know many
products that
do not cut-through media before the answer is received.

But there are other problems related with early media. Brian Stucker's
draft
listed a bunch of them. 

Forking for example comes to mind: even if we did mandate cut-through
after
answer, we would still have problems related with forking (i.e., how to
pick
the stream that needs to be played, and how to correlate the stream with
the 
signaling). How to deal with SRTP key exchange in that scenario is an
even 
bigger problem. 

Clipping is a possible side-effect of your proposal. We'd need some
mechanism to 
mitigate it, in particular for auto-answer scenarios.

> Sent: Monday, February 12, 2007 07:08
> To: Christer Holmberg (JO/LMF)
> Cc: [email-masked]; [email-masked]
> Subject: [Sipping] Re: [Sip] New draft on early media
> 
> Christer,
> 
> Perhaps a better term would be "media sent before an SDP 
> answer has been received".  As you point out, sending media 
> before an SDP offer/answer exchange has completed poses the 
> risk that that media will not arrive. 
> To put it in the terms used in the document, media clipping 
> is a problem caused by early (pre-SDP-answer) media, and thus 
> one which this document seeks to solve.
> 
> > "preview" of the SDP answer) before (or at the same time as) early 
> > media is sent.
> 
> This is the behavior we would like to standardize -- that an 
> SDP answer is *always* sent before media of any type.  What 
> we're trying to do with this document is describe the 
> requirements for how that answer is sent, and consolidate the 
> many ways people have proposed to send it.
> 
> > And, in the cases where implementations do NOT send an SDP answer 
> > before they start sending early media - what behavior would you be 
> > able to standardize?
> 
> We would prefer that standards not allow this behavior -- 
> that seems like the right thing to me.  What's a little 
> trickier is that you'd like to not have the answerer sending 
> media before the answer has *arrived*. 
>   When the answer is carried in a reliable message, you could 
> just forbid sending media before receipt has been confirmed.  
> When the transport is unreliable, the situation is a little 
> less clear, but I think there's still possibilities for 
> standardization, e.g., by forbidding answerers to send media 
> until they've received media.  This is discussed in more 
> length in the document.
> 
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> >> After the big discussions on SIPPING last summer about how to fix 
> >> early media, and the reaction at the last couple of IETFs to Brian 
> >> Stucker's draft on how to cope with it, I've put together 
> a draft to 
> >> try to consolidate all of the discussions and move toward 
> a solution.
> >>
> >> media" in existing documents, I think there's broad agreement that 
> >> the stuff that causes problems is media that arrives before an SDP 
> >> offer/answer exchange has completed.
> >> The problem is therefore to enable the SDP exchange(s) in 
> the INVITE 
> >> transaction to complete more quickly, and make it more 
> difficult (if 
> >> not impossible) to send media before it has completed.  We are 
> >> explicitly NOT trying to prevent the sending of media 
> before a 200/OK 
> >> or other closing of an INVITE transaction.
> >>
> proposals to 
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 13 Feb 2007 14:40:45 -0500

Francois,

I think I have some responses, but I'd like to ask you first: What do 
you mean by "media cut-through"?

Thanks,
--Richard

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 13 Feb 2007 16:08:50 -0600

I mean play incoming media. 

> Sent: Tuesday, February 13, 2007 11:41
> To: Audet, Francois (SC100:3055)
> Cc: Christer Holmberg (JO/LMF); [email-masked]; [email-masked]
> Subject: Re: [Sipping] Re: [Sip] New draft on early media
> 
> Francois,
> 
> I think I have some responses, but I'd like to ask you first: 
> What do you mean by "media cut-through"?
> 
> Thanks,
> --Richard
> 
> Francois Audet wrote:
> > Hi Richard,
> > 
> > received does solve SOME of the early media problems. As 
> others have 
> > mentioned, there are environments that operate like this already. I 
> > also know many products that do not cut-through media before the 
> > answer is received.
> > 
> > draft listed a bunch of them.
> > 
> > after answer, we would still have problems related with 
> forking (i.e., 
> > how to pick the stream that needs to be played, and how to 
> correlate 
> > the stream with the signaling). How to deal with SRTP key 
> exchange in 
> > that scenario is an even bigger problem.
> > 
> > mechanism to mitigate it, in particular for auto-answer scenarios.
> > 
> > 
> answer has 
> >> been received".  As you point out, sending media before an SDP 
> >> offer/answer exchange has completed poses the risk that that media 
> >> will not arrive.
> >> To put it in the terms used in the document, media clipping is a 
> >> problem caused by early (pre-SDP-answer) media, and thus one which 
> >> this document seeks to solve.
> >>
> >> This is the behavior we would like to standardize -- that an SDP 
> >> answer is *always* sent before media of any type.  What 
> we're trying 
> >> to do with this document is describe the requirements for how that 
> >> answer is sent, and consolidate the many ways people have 
> proposed to 
> >> send it.
> >>
> that seems 
> >> like the right thing to me.  What's a little trickier is 
> that you'd 
> >> like to not have the answerer sending media before the answer has 
> >> *arrived*.
> >> forbid sending media before receipt has been confirmed.
> >> When the transport is unreliable, the situation is a little less 
> >> clear, but I think there's still possibilities for 
> standardization, 
> >> e.g., by forbidding answerers to send media until they've received 
> >> media.  This is discussed in more length in the document.
> >>
> >>> Regards,
> >>>
> >>> Christer
> >>>
> >>>
> >> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> >> This list is for NEW development of the application of SIP Use 
> >> [email-masked] for questions on current sip Use 
> >> [email-masked] for new developments of core SIP
> >>
> > 
> > 
> 
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 14 Feb 2007 17:38:20 -0500

Thanks for the clarification.  I know that choosing media streams to 
render is a big problem, but it's one I'm viewing as beyond the scope of 
what our draft is explicitly trying to address.

That said, I think that ensuring that media are preceded by an SDP 
answer is a big step in enabling better management of media streams, 
since it gives the offeror (media recipient) SDP metadata on which to 
base its decision.  Once an SDP answer is guaranteed to come before 
media, the issue can be treated more at the SDP layer (e.g. by giving 
SDP sufficient expressiveness to support decisions between media 
streams), rather than at the SIP layer.

With respect to forking in particular: You're correct that even if all 
streams from forked endpoints are preceded by SDP answers, the UAC still 
has to figure out how to deal with them.  But I think that once you 
ensure that the offer/answer finishes before media flows, SRTP keying 
gets a lot simpler, since the UAC can just do a DH exchange through your 
favorite SDP mechanism with each endpoint.

Clipping is certainly something that could be an issue, but I think it 
can be prevented.  The solution I think will work in the end is that an 
SDP answer will be sent immediately by the UAS on receipt of the INVITE, 
before any other action is taken (e.g., before the INVITE is passed to 
the TU).  For example, a PSTN gateway receiving a SIP INVITE would 
return its answer before it initiates the outbound PSTN call.  It seems 
to me like the negotion of an SDP association should precede SIP session 
establishment just like TCP negotiation would precede initiation of a 
higher-layer protocol session.

Does that make sense?
--Richard

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 14 Feb 2007 16:41:05 -0600

I think it makes sense as a starting point for a partial solution, yes. 

> Sent: Wednesday, February 14, 2007 14:38
> Thanks for the clarification.  I know that choosing media 
> streams to render is a big problem, but it's one I'm viewing 
> as beyond the scope of what our draft is explicitly trying to address.
> 
> That said, I think that ensuring that media are preceded by 
> an SDP answer is a big step in enabling better management of 
> media streams, since it gives the offeror (media recipient) 
> SDP metadata on which to base its decision.  Once an SDP 
> answer is guaranteed to come before media, the issue can be 
> treated more at the SDP layer (e.g. by giving SDP sufficient 
> expressiveness to support decisions between media streams), 
> rather than at the SIP layer.
> 
> With respect to forking in particular: You're correct that 
> even if all streams from forked endpoints are preceded by SDP 
> answers, the UAC still has to figure out how to deal with 
> them.  But I think that once you ensure that the offer/answer 
> finishes before media flows, SRTP keying gets a lot simpler, 
> since the UAC can just do a DH exchange through your favorite 
> SDP mechanism with each endpoint.
> 
> Clipping is certainly something that could be an issue, but I 
> think it can be prevented.  The solution I think will work in 
> the end is that an SDP answer will be sent immediately by the 
> UAS on receipt of the INVITE, before any other action is 
> taken (e.g., before the INVITE is passed to the TU).  For 
> example, a PSTN gateway receiving a SIP INVITE would return 
> its answer before it initiates the outbound PSTN call.  It 
> seems to me like the negotion of an SDP association should 
> precede SIP session establishment just like TCP negotiation 
> would precede initiation of a higher-layer protocol session.
> 
> Does that make sense?
> --Richard
> 
> 
> 
> 
> Francois Audet wrote:

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 15 Feb 2007 12:29:16 +0100

Hi, 

>as beyond the scope of what our draft is explicitly trying to address.

Fair enough. However, I do agree with Francois that forking is one of
the biggest issue.

>SDP metadata on which to base its decision.

I agree.

>Once an SDP answer is guaranteed to come before media, the issue can be

>rather than at the SIP layer.

Due to different paths for signalling and media, it may be difficult to
guarantee that the SDP answer reaches the UAC. But, of course, the
sooner the SDP can be sent before the media, the bigger the chance is.

>its answer before it initiates the outbound PSTN call.

That may not always be feasible/possible, but of course it can be used
as an example. 

I am not sure we need to go so much into details. I think the most
important thing is to try to provide the SDP answer as soon as possible
before the media is sent - or at latest at the same thing when the media
is sent.

For audio I guess a short clipping may not always be a big issue. But,
for video it may be, because if the initial packages are lost it may
take a relatively long time before the UAC is able to create a correct
picture.

>It seems to me like the negotion of an SDP association should 

Or the other way around, like H.323 and H.245 ;)

Regards,

Christer