Subject: Re: [Sipping] New draft on early media

From: Jason Fischl <[email-masked]>
Date: Mon, 12 Mar 2007 09:37:22 -0700

3.1.1 Fast completion of INVITE transaction
I like the idea of "Fast Completion of INVITE transaction" since it  
gets us away from the whole PRACK nightmare. However, is it really  
practical to contemplate doing this? How many years will it take us  
to get SIP phone and gateway vendors to implement such a major change  
in behavior?

3.1.2 Elimination of offer from INVITE
This solution doesn't seem practical to me unless you have PRACK  
since it would not allow you to otherwise send media before the 200  
OK. If you have PRACK, then you don't need this approach.

3.1.3 Provisional responses
I am not a fan of PRACK but it does seem to be the best path to a  
solution to this problem given where we are now.  This also doesn't  
require any changes to the normative behavior of SIP.

3.1.4 Separate INVITE transaction
This one makes my head hurt a bit. I assume that this second INVITE  
transaction would either be in the same dialog as the original INVITE  
or would be sent to a gruu representing the specific UAS in the  
original INVITE? Also, I'm not sure this is any less complex to  
implement than PRACK but worth some more thought.

3.1.5 Non-INVITE SIP Mechanisms
I'd prefer to take INFO off the table.

Summary: In my opinion, of the recommended approaches,  PRACK looks  
like our best bet.

On Feb 8, 2007, at 11:46 AM, Richard Barnes wrote:

> 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]
>
> _______________________________________________
> 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

_______________________________________________
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: Jason Fischl <[email-masked]>
Date: Mon, 12 Mar 2007 09:37:22 -0700