Internet Engineering Task Force                                   SIP WG
Internet Draft                                               J.Rosenberg
draft-rosenberg-sip-unify-00.txt                             dynamicsoft
January 17, 2002
Expires: May 2002


               Unifying Early Media, Manyfolks, And HERFP

STATUS OF THIS MEMO

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.


Abstract

   The SIP working group has been grappling with a variety of very
   difficult problems lately. These include early media, coupling of
   resource reservation and call signaling, and the so-called
   Heterogeneous Error Response Forking Problem (HERFP). Additional
   problems being considered include supporting capability negotiation
   for indicating support any one of one-of-N codecs, upgrading the
   security on RTP streams, and demultiplexing media from a forked
   INVITE. In this document, we present a unified view of all of these
   problems, and present a unified solution that solves all of them in
   the same way.








J.Rosenberg                                                   [Page 1]


Internet Draft                   unify                  January 17, 2002



                           Table of Contents



   1          Introduction ........................................    5
   2          Problems ............................................    5
   2.1        One-of-N Codecs .....................................    5
   2.2        Change Ports on forked 2xx ..........................    6
   2.3        Secure Media ........................................    7
   2.4        Early Media .........................................    7
   2.5        Coupling of Resource Reservation and Signaling ......    8
   2.6        The Heterogeneous Error Response Forking Problem
   (HERFP) ........................................................    9
   3          Unifying the Problems and the Solution ..............   12
   4          The new COMET .......................................   15
   5          Application to Problems .............................   18
   5.1        One-of-N Codecs .....................................   18
   5.2        Change Ports on forked 2xx ..........................   19
   5.3        Secure Media ........................................   19
   5.4        Early Media .........................................   20
   5.5        Coupling of Resource Reservation and Signaling ......   25
   5.6        The Heterogeneous Error Response Forking Problem
   (HERFP) ........................................................   28
   6          Musings on COMET vs. re-INVITE ......................   32
   7          Proposed Process for the SIP WG .....................   32
   8          Open Issues .........................................   33
   9          Acknowledgements ....................................   34
   10         Author's Addresses ..................................   34
   11         Bibliography ........................................   34






J.Rosenberg                                                   [Page 2]


Internet Draft                   unify                  January 17, 2002


1 Introduction

   The SIP working group has been grappling with a variety of very
   difficult problems lately. These include early media, coupling of
   resource reservation and call signaling, and the so-called
   Heterogeneous Error Response Forking Problem (HERFP). Additional
   problems being considered include supporting capability negotiation
   for indicating support any one of one-of-N codecs, upgrading the
   security on RTP streams, and demultiplexing media from a forked
   INVITE. In this document, we present a unified view of all of these
   problems, and present a unified solution that solves all of them in
   the same way.

   Section 2 overviews each of these problems in more detail, and
   overviews the solutions proposed to date. Section 3 presents our
   unified view of these problems, and Section 4 presents a single
   mechanism for solving all of them at the same time. Section 5 shows
   how the proposed solution is applied to each of the problems
   discussed in Section 2.

2 Problems

2.1 One-of-N Codecs

   It is very common for SIP gateways and hardphones to use DSP chips
   for the speech compression and decompression. A common characteristic
   of these DSPs is that they can support a wide variety of codecs, but
   only one codec can be loaded at a time. Unfortunately, there is no
   clear way in SIP to signal that this is the case. A caller can
   include, in their INVITE, SDP which lists all of their codecs, but
   the offer-answer specification [1] mandates that this means the
   caller supports the ability to dynamically change between them mid-
   call, which is not possible here.

   A variety of solutions have been proposed for this problem:

        Pick One, Try Again: In this approach, the caller picks one of
             the codecs, its preferred one, and includes that in the
             INVITE. If the callee supports it, great. If not, it
             returns a 488 error. According to the SIP specification
             [2], this error response contains a list of the codecs
             supported by the caller in an SDP message [3]. The caller
             then picks from amongst those, and issues a new call
             request. This approach has numerous problems, including
             increased call setup time, and the possibility that the
             second call goes to a different device due to routing
             changes. It is also inelegant.




J.Rosenberg                                                   [Page 5]


Internet Draft                   unify                  January 17, 2002


        Say and Pray: In this approach, the caller lists all of their
             codecs in the INVITE, but simply hopes that the callee
             sticks with one of them. This clearly has disadvantages.

        a=pickone: It has been proposed on the mailing lists that the
             caller could include all of their codecs in the SDP, but
             include a new attribute, "a=pickone" which tells the callee
             to just pick one of them when responding. This approach is
             somewhat specialized, and is not backwards compatible.

        Simcap restrictions: It has been proposed on the mailing lists
             that the caller include all of their codecs in the SDP, and
             include additional parameters in the SDP which more
             concretely define their capability constraints, using the
             simcap specification [4]. However, simcap cannot express
             the constraint that only one of N codecs can be supported
             at once.

        Three-Way Handshake: It has been proposed [5] that a three-way
             handshake be used for this. The INVITE contains a full
             listing of codecs. The callee sends back a SIP provisional
             response (183 Progress) with a restricted set, which is
             those codecs amongst the list in the INVITE which the
             callee can do. The PRACK request (used for acknowledging
             the 183) contain another SDP with a single codec in it, and
             that is the one used for the session. This mechanism has
             the problem that it is not backwards compatible

   Thus, none of the proposed solutions seem satisfactory.

2.2 Change Ports on forked 2xx

   When the caller issues an INVITE, it contains the port and IP address
   in the SDP where media should be sent to. If this INVITE should
   "fork", meaning it is delivered to multiple recipients, each of them
   can answer. According to the specifications, each callee will begin
   sending media to the address and port provided in the INVITE. The
   caller will therefore receive two distinct media streams on the same
   port and address. In many cases, for RTP, they will be
   distinguishable with the SSRC parameter [6]. However, it is possible
   (although remotely) that both will pick the same SSRC, resulting in
   serious media confusion.

   It has been proposed that a three way handshake be used to solve this
   problem. The INVITE contain an initial port/address, or none at all,
   since they are not used. The 200 OK contains the port and address of
   the called party, and the SIP ACK message, sent from the caller back
   to the callee, contain an update port and address for that particular



J.Rosenberg                                                   [Page 6]


Internet Draft                   unify                  January 17, 2002


   recipient. This would avoid the media confusion. However, the
   approach has the problem that it results in clipping of an RTT worth
   of any media sent by the callee immediately after they answer the
   phone.

   Furthermore, the approach is not backwards compatible with existing
   SIP deployments.

2.3 Secure Media

   SIP can establish media that runs over RTP [6]. More recently, a
   secure version of RTP, called SRTP [7], has been developed. However,
   SRTP is not backwards compatible (obviously). We would desire for the
   caller to be able to indicate that they can do either, and then the
   called party picks one, followed by the caller responding with the
   specific address and port for the media stream.

   Robert Fairlie Cuninghame has proposed (http://www1.ietf.org/mail-
   archive/working-groups/sip/current/msg00664.html) that a three way
   exchange be used for this also. This is a different exchange than the
   one discussed above for the one-of-N codecs case; rather, in this
   exchange, the INVITE contains a complete set of capabilities, and an
   offer comes in the 200 OK, followed by an answer in the ACK.

   This approach suffers the problem that it is not backwards
   compatible, and also clips an RTT worth of media after the caller
   picks up.

2.4 Early Media

   Early media has received a tremendous amount of attention, with
   several drafts [8] [9] [10] and countless email discussions and
   presentations.

   The essence of the problems are outlined in [8]. At the core is a
   single problem - there is a need for aspects of the media sessions to
   be changed before the call is accepted. This includes rejecting
   streams, modifying streams, placing them on hold, adding media to
   them, and so on. Numerous solutions have been proposed. Rosenberg has
   proposed [8] the addition of a re-INVITE before session completion to
   update the media, all following the offer/answer exchange. Sen et.
   al. have proposed that in the case of calls with preconditions, there
   be two separate media negotiations, one for early media, and one for
   the final media, both of which would use manyfolks [9]. Mahy has
   proposed on the mailing lists to modify Rosenberg's preferred
   proposal to use a separate method, OFFER, to update the media stream.

   Also on the mailing lists, Robert Fairlie-Cuninghame has proposed



J.Rosenberg                                                   [Page 7]


Internet Draft                   unify                  January 17, 2002


   that a UAC "prod" the UAS into sending a new offer in the 1xx, which
   can be answered in the PRACK. This avoids the problem with
   overlapping INVITE, but has a separate problem, which is that the UAC
   is restricted to providing answers, not offers. This means that it
   can never add a media stream, for example.

   All of the other proposals have problems. Rosenberg's preferred
   solution, as pointed out by Mahy, suffers in that it breaks the
   ability of proxies to provide services. Sen's proposal, in the case
   of preconditions, is extremely complex, with vague semantics. Mahy's
   proposal seems workable, but its interactions with preconditions are
   undefined.

2.5 Coupling of Resource Reservation and Signaling

   The most complex of all of the problems is the coupling of resource
   reservation and signaling, which has been the result of literally
   years of back and forth proposals, compromises and specification
   work. It is now codified in the so-called "manyfolks" draft [5]. The
   essence of the problem it is trying to solve is the coupling of
   resource reservation to call state. We would like to be able to setup
   a call, and ring the callee, ONLY if resources can be reserved for
   the call. However, we need signaling to the callee in order to obtain
   the information required to perform resource reservation. The result
   is a chicken-and-egg problem. The solution is to include
   preconditions in the INVITE, which effectively tell the callee that
   it shouldn't ring the phone until resources have been reserved,
   security has been set up, or some other precondition has been met.
   Once the conditions are met, a COMET request is sent by either side
   to indicate this fact, so that ringing can occur and call setup can
   proceed.


   Manyfolks accomplishes this by a call exchange shown in Figure 1,
   copied from Figure 1 of [5]. The INVITE contains SDP with a
   precondition on a media stream. The precondition typically indicates
   that the call should not proceed unless bidirectional resources can
   be reserved for the media stream. The UAS returns a 183 response
   indicating acceptance of this precondition, and providing enough
   information for the UAC to begin performing resource reservation.
   This 183 is acknowleged with PRACK, said PRACK can contain additional
   SDP which updates the codec sets against which reservations are done.
   Once reservations are made, the UAC sends a COMET to the UAS, with
   SDP as well. This SDP is used solely to indicate that the
   precondition has been met (i.e., resources have been reserved). This
   is done by an attribute in the SDP which indicates that the
   reservation is confirmed. Once that has been sent, the UAS can begin
   alerting the callee, and it therefore sends a 180 ringing message



J.Rosenberg                                                   [Page 8]


Internet Draft                   unify                  January 17, 2002


   (which is also acknowleged with PRACK). Once the caller accepts, a
   200 OK is sent, also with SDP, mirroring that of the 183. This is
   ACKed as well.

   We have observed some problems with the current approach. Most of
   them have to do with an underspecification of behavior, including no
   clear path for smooth integration with early media. Some of the
   issues:

        o The specification does not say what happens if the SDP in the
          COMET is different beyond just indication of a confirmation
          tag. Can media streams be added or deleted? Can codecs be
          changed?

        o There is no visible way to support early media; Sen has
          proposed a dual-exchange for it, but this is extremely
          complex.

        o There is no way to indicate that, when a call is initially
          established, resources have already been reserved (for
          example, link resources in the case of access-only
          reservations). This has been raised on the list as an issue.

        o There is no way to support the case of failure of media in the
          middle of a call causing termination of the call, or other
          action.

        o There is no clear way to handle the case of addition of
          streams mid-call, which may require further reservation which
          could also fail. We believe it is possible with the documented
          approach, but is not specified or discussed.

2.6 The Heterogeneous Error Response Forking Problem (HERFP)

   HERFP, as it is called, is, in our opinion, the most complex
   remaining problem with the SIP specification.

   It relates to the rules for response processing at a forking proxy. A
   proxy never forwards more than one error response back to the UAC.
   This is needed to prevent response implosion, but more importantly,
   to support services at proxies. A forking proxy only returns an error
   response upstream if all forked requests generate an error response.
   However, a 200 OK is always forwarded upstream immediately.

   The problem is that if a request forks, and one UAS generates an
   error because the INVITE is not acceptable for some reason (no
   credentials, bad credentials, bad body type, unsupported extension,
   etc.), that response is held at the forking proxy until the other



J.Rosenberg                                                   [Page 9]


Internet Draft                   unify                  January 17, 2002




Originating (UAC)                            Terminating (UAS)
        |                  SIP-Proxy(s)                 |
        |  INVITE               |                       |
        |---------------------->|---------------------->|
        |                       |                       |
        |       183 w/SDP       |       183 w/SDP       |
        |<----------------------|<----------------------|
        |                                               |
        |                       PRACK                   |
        |---------------------------------------------->|
        |               200 OK (of PRACK)               |
        |<----------------------------------------------|
        | Reservation                       Reservation |
         ===========> <===========
        |                                               |
        |                                               |
        |               COMET                           |
        |---------------------------------------------->|
        |               200 OK (of COMET)               |
        |<----------------------------------------------|
        |
        |
        |                  SIP-Proxy(s)         User Alerted
        |                       |                       |
        |       180 Ringing     |       180 Ringing     |
        |<----------------------|<----------------------|
        |                                               |
        |                       PRACK                   |
        |---------------------------------------------->|
        |               200 OK (of PRACK)               |
        |<----------------------------------------------|
        |                                               |
        |                                       User Picks-Up
        |                  SIP-Proxy(s)         the phone
        |                       |                       |
        |       200 OK          |       200 OK          |
        |<----------------------|<----------------------|
        |                       |                       |
        |                                               |
        |                       ACK                     |
        |---------------------------------------------->|




   Figure 1: Manyfolks Basic Flow

   forks respond. Of course, another branch may find the request
   acceptable, and therefore never generate an error response. The
   effect is to cancel out the benefits of forking.
J.Rosenberg                                                  [Page 10]


Internet Draft                   unify                  January 17, 2002




         uac       p1       uas1      uas2
          |(1) INVITE         |         |
          |-------->|         |         |
          |         |(2) INVITE         |
          |         |-------->|         |
          |         |(3) INVITE         |
          |         |------------------>|
          |         |(4) 401  |         |
          |         |<--------|         |
          |         |(5) ACK  |         |
          |         |-------->|         |
          |         |(6) 180  |         |
          |         |<------------------|
          |         |(7) 180  |         |
          |         |<------------------|
          |(8) CANCEL         |         |
          |-------->|         |         |
          |(9) 200 OK         |         |
          |<--------|         |         |
          |         |(10) CANCEL        |
          |         |------------------>|
          |         |(11) 200 OK        |
          |         |<------------------|
          |         |(12) 487 |         |
          |         |<------------------|
          |         |(13) ACK |         |
          |         |------------------>|
          |(14) 401 |         |         |
          |<--------|         |         |
          |(15) ACK |         |         |
          |-------->|         |         |



   Figure 2: Basic HERFP Case


   Figure 2 shows the simplest form of the problem. In this flow, the
   UAC sends an INVITE to proxy P1, which forks to UAS1 and UAS2. UAS1
   might be a cell phone, and UAS2 a business phone. UAS1 rejects with a
   401, and so never rings. However, UAS2 does not require credentials
   (or the request already had them), and therefore it rings. However,
   the user is not at their business phone, although they are available
   at the cell phone. After ringing for 20s, the caller gives up, and
   therefore sends CANCEL. This stops UAS2 from ringing, and results in
   the proxy forwarding the now-old 401 to the UAC. The UAC is not
   likely to retry, since the user just hung up. Thus, no call is



J.Rosenberg                                                  [Page 11]


Internet Draft                   unify                  January 17, 2002


   established when it should have been.


   Another HERFP case is shown in Figure 3. This is a case of sequential
   forking for a call forwarding service. The UAC calls a user, and the
   proxy first forks the call to UAS1. The user is not there, so the
   phone rings for 5s, and is then cancelled by the proxy, which forks
   to UAS2. UAS2 challenges, resulting in a 401 being returned to the
   UAC. The UAC tries again, which causes re-invocation of the call
   forwarding service! UAC1 rings once more for another 5s, and then
   finally the call is connected to UAS2. Interestingly, if the first
   UAC doesn't challenge but the others do, and there are N phones tried
   before completion, the first phone will ring N times! A user standing
   by UAS1 but electing to not answer will probably view it as a prank
   or malicious call.

   The problem is that information needs to be propagated back to the
   UAC immediately, and the UAC needs to resubmit it, but the
   resubmission should not affect services somehow, e.g., should not
   re-invoke them as above.

3 Unifying the Problems and the Solution

   To solve these problems together, we observed the following:

        Session state and dialog State are NOT the same: The state of
             the media sessions, in terms of its media makeup, codec
             support, and so on, is orthogonal to the state of the call
             (referred to now as a dialog). A session can be active
             before an INVITE is even sent (in the case of an invitation
             to a multicast session), and it can be active after the
             call has ended in the same way. The instant a offer and an
             answer exhchange have taken place for a unciast session,
             the session exists, irregardless of the state of the
             dialog. There is no distinction between early media and
             final media. They are the same as far as the IP network is
             concerned, so any distinctions would be purely artificial.
             Because of this, it makes little sense to separately
             negotiate early media parameters from final media
             parameters, for example. Media communications begin when
             the session is established, and ends when it ends,
             irregardless of the state of the dialog. Early media is
             only early in the sense that it happens to take place
             before the dialog is established. If one wishes to account
             for communications services for billing purposes, those are
             tied to the establishment of media sessions, NOT the
             dialog, since it is the media session that enables
             communications. One can force them to be the same in order



J.Rosenberg                                                  [Page 12]


Internet Draft                   unify                  January 17, 2002


             to use the dialog state for accounting, but the fact
             remains that it is the media sessions that facilitate
             communications.

        Services are driven off of dialog state, not session state:
             Call services, such as call-forward-busy, personal
             mobility, routing and screening services, are all based on
             the state of the dialog, which is manipulated through SIP
             requests and responses. They are not driven at all by the
             session state (generally).

        INVITE affects both session and dialog state: The INVITE method,
             as specified, has the dual role of facilitating the
             exchange of SDP to establish a session, and also exchange
             messages for signaling the state of the dialog. It thus
             drives services and session state.

        We need a way to manipulate session state independent of the
             dialog: The essence of the early media problem is that we
             need a way to manipulate the state of the session without
             impacting the dialog. The essence of the various problems
             with motivated a three-way handshake, is also the need to
             modify characteristics of the session without impacting the
             dialog. This is the key.

        Manyfolks incorrectly views reservations: Manyfolks takes the
             wrong model for viewing the reservation. It views a
             precondition as special, requiring a specific method to
             indicate its achievement. The SDP in the COMET, for
             example, is used only for tunneling the bit in the SDP
             which indicates that the precondition is met. However, that
             is a statement of a CHANGE in state. SDP is meant to convey
             the full state of a session, not its changes. It is our
             view that the reservation of a media stream is just another
             piece of session state which can be manipulated. A media
             stream can be send-only, it can be receive-only. In the
             same exact way, a media stream can be reserved or not. Like
             the directionality of the stream, it can change at any
             time, and that should be signaled in the same way a new
             codec would be signaled. A precondition is nothing more
             than a statement that the dialog state should remain fixed
             in a particular state until the session state achieves a
             certain value. This, too, is a piece of state associated
             with a media stream, which can be manipulated in the exact
             same way.

        Since sessions are independent of dialogs, the process of
             modification should not differ inside or outside of a



J.Rosenberg                                                  [Page 13]


Internet Draft                   unify                  January 17, 2002




         uac       p1       uas1      uas2
          |(1) INVITE         |         |
          |-------->|         |         |
          |         |(2) INVITE         |
          |         |-------->|         |
          |         |(3) 180  |         |
          |         |<--------|         |
          |(4) 180  |         |         |
          |<--------|         |         |
          |         |(5) CANCEL         |
          |         |-------->|         |
          |         |(6) 200 OK         |
          |         |<--------|         |
          |         |(7) 487  |         |
          |         |<--------|         |
          |         |(8) ACK  |         |
          |         |-------->|         |
          |         |(9) INVITE         |
          |         |------------------>|
          |         |(10) 401 |         |
          |         |<------------------|
          |         |(11) ACK |         |
          |         |------------------>|
          |(12) 401 |         |         |
          |<--------|         |         |
          |(13) ACK |         |         |
          |-------->|         |         |
          |(14) INVITE        |         |
          |-------->|         |         |
          |         |(15) INVITE        |
          |         |-------->|         |
          |         |(16) 180 |         |
          |         |<--------|         |
          |(17) 180 |         |         |
          |<--------|         |         |
          |         |(18) CANCEL        |
          |         |-------->|         |
          |         |(19) 200 OK        |
          |         |<--------|         |
          |         |(20) 487 |         |
          |         |<--------|         |
          |         |(21) ACK |         |
          |         |-------->|         |
          |         |(22) INVITE        |
          |         |------------------>|
          |         |(23) 200 OK        |
          |         |<------------------|
          |(24) 200 OK        |         |
          |<--------|         |         |
          |(25) ACK |         |         |
          |---------------------------->|



   Figure 3: Forking HERFP Case

J.Rosenberg                                                  [Page 14]


Internet Draft                   unify                  January 17, 2002


             dialog: The process of modification of session state should
             not depend on the state of a dialog. We should have one way
             to manipulate session state. That mechanism should be
             independet of the SIP messages which carry it. This is the
             essence of the offer/answer model, and it is critical that
             this be the case for session manipulation before the call
             is accepted.

        HERFP is about updating state too: HERFP is primarily about
             passing information from UAS to UAC, and getting additional
             information. The problems caused by the current approaches
             is that the additional information is provided in a request
             (INVITE) which invokes services and creates dialog state.
             What we need is a way to pass additional information, which
             is not session state, but state nonetheless, to the UAS,
             without affecting the initial call setup. We argue that
             this is, in fact, the same problem as the others.

   Based on these observations, the solution became clear. We need a new
   method that can manipulate session state independent of the dialog
   state. That manipulation must follow the same rules for manipulation
   after the dialog is accepted. We must cast manyfolks into a light
   which views it as a manipulation of a different sort of session
   state, the state of the reservation for the session.

   To solve HERFP, we must pass back information from the UAS to UAC
   without terminating the initial dialog, and get information back to
   the UAS without affecting intermediaries.

4 The new COMET

   Our solution proposes that we take the one new method defined that
   sort-of affects session state, which is COMET, and generalize it.
   COMET is now a method, only within the context of a dialog (early or
   stablished), which may update some aspect of the session state, or
   other peripheral state relating to the dialog, but has no impact on
   the dialog itself. Reuse of the COMET name assists in backwards
   compatibility with manyfolks.

   The offer/answer model remains as defined [1]. However, a UAS can
   generate a 1xx with an answer to the offer in the INVITE. The UAC can
   generate additional offers by sending a COMET, and the answer appears
   in the 2xx. Similarly, the callee can generate additional offers in
   COMET back to the callee, with the answer in its 2xx. This means that
   the 2xx to the INVITE need not contain SDP, nor the ACK. We would
   propose to relax the constraints in bis in order to allow this. This
   may strand some ALGs that are implemented, but this is exactly the
   reason we feel that embedded ALGs inside of layer 3 boxes are a bad



J.Rosenberg                                                  [Page 15]


Internet Draft                   unify                  January 17, 2002


   idea.

   A session is considered established solely based on the offer/answer
   model, e.g., when an answer to the offer arrives. The dialog is
   created by the first 1xx or 2xx, and the call answered on 2xx.

   COMET can be sent at any time, even after the dialog is established.
   In that sense, it would work like a re-INVITE, but unlike a re-
   INVITE, would never establish a new dialog, which re-INVITE can, if
   the UAS is reconstituting state [11].

   COMETs cannot overlap, and the request glare procedures of [2] need
   to be applied to it in order to ensure that COMETs in each direction
   do not occur simultaneously.

   The general rule for offers and answers would then be the following:

        o A UA cannot send an offer when it has sent a previous offer to
          which it has not yet gotten an answer.

        o A UA cannot send an offer when it has received an offer to
          which it has not generated an answer.

        o A UA can only send an offer in a message that is sent
          reliably.

        o The answer to an offer has to occur in a message which is
          correlated to the message the offer came in.

        o If an offer does not take place in the first reliable message
          from UAC to UAS, it must be present in a reliable message from
          UAS to UAC.

   The result is that, for basic UA, the offer is in the INVITE, answer
   in 2xx, or offer in 2xx, answer in ACK, just as is specified today.
   Both of those cases are covered by the above rules. When a UA can do
   COMET and 100rel, the rules would allow for a broader range of
   exchanges.

   Any of the three-way handhake mechanisms described above can be done
   with two two-pass exchanges, as we will show below. If the UA wants
   to make sure that the session parameters of the first exchange are
   never used, it can set the stream to inactive in its offer or answer
   and then reactivate it later. It is possible to use a series of two
   pass exchanges both before and after the dialog is established.

   To solve HERFP, we further specify that any of the SIP error
   responses which solicit additional information (401, 415, 420, 484,



J.Rosenberg                                                  [Page 16]


Internet Draft                   unify                  January 17, 2002


   etc.) can instead be sent as reliable provisional responses. These
   provisional responses would use response code 155 Please Update, and
   would contain a Reason header [12] indicating the specific error and
   its reason phrase. We use a provisional responses since they are sent
   end-to-end through existing proxies, and because they do not
   terminate the transaction. That is the key to not breaking forking
   and related services.

   A benefit of this approach, everything else aside, is that it
   provides full disclosure to the caller about what has happened with
   their call. Progress on all the tried branches and their results are
   communicated back to the UAC. We believe this is very much in line
   with recent IAB directives on OPES [13], which has mandated that
   intermediaries inform the client about what is being done with their
   request.

   Upon receipt of the provisional response, the UAC can send a COMET
   message providing the updated information, whether it be credentials,
   a new body type, or a new session description, as needed. This
   information would supplant whatever was sent in the initial INVITE,
   as if the COMET were a re-INVITE, except it has no impact on the
   dialog state itself.

   To determine whether or not the UAS should send a provisional or
   final response, a proxy along the path which is invoking services on
   the request, or which forks, would insert a Require header indicating
   that this should be done. This Require would only be inserted by the
   proxies if the INVITE itself contained a Supported header indicating
   the ability to understand 155. If the UAS doesn't support it, the
   proxy can retry the request without the Require header.

   We also elect to rename the expansion of COMET, from "Conditions Met"
   to "Conditional Modification of Endpoint Thinking", as a real
   stretch, but better than "Conditions Met" for its enhanced role.

   We propose to restructure manyfolks, so that it is instead presented
   as a set of new attributes that can describe the reservation state of
   a stream, along with a new piece of state, called a precondition,
   which can itself be negotiated.

   To summarize, the key ideas are:

        o Generalize COMET to a method for updating session state or
          dialog-related state, but not dialog state itself.

        o Allow COMET to be sent in either direction within any dialog
          at any time, subject to overlapping and glare rules, even if
          the dialog is an early one.



J.Rosenberg                                                  [Page 17]


Internet Draft                   unify                  January 17, 2002


        o Allow UAS to generate provisional responses instead of error
          responses containing the error information.

        o Modify manyfolks so that its attributes are now just pieces of
          state about a media stream, like any other.

        o Use a=inactive to ensure that intermediate session parameters
          are not used when a multi-pass exchange is required.

5 Application to Problems

   We will now show below how this simple approach of separation solves
   all of the problems above in a unified way.

5.1 One-of-N Codecs



       Caller    Callee
          |(1) INVITE
          |-------->|
          |(2) 200  |
          |<--------|
          |(3) ACK  |
          |-------->|
          |(4) INVITE
          |-------->|
          |(5) 200  |
          |<--------|
          |(6) ACK  |
          |-------->|



   Figure 4: Basic Flow for One-of-N Codec Selection



   The call flow for the two-pass solution to this problem is shown in
   Figure 4. The initial INVITE (message 1) contains SDP with the
   desired streams. Each stream lists ALL of the codecs supported by the
   UA, even if they cannot be supported simultaneously. The media stream
   has a direction of inactive, to indicate it is not yet started.

   When the 200 OK arrives (message 2), it is ACKed normally. The 200 OK
   will have an m line with a subset of the codecs supported by the
   callee. If simcap is used [4], the caller will have additional
   information on other codecs as well. In parallel with the ACK, the
   caller sends a re-INVITE, this time with an m line with a single



J.Rosenberg                                                  [Page 18]


Internet Draft                   unify                  January 17, 2002


   codec, which is one of the ones supported by the UAS. THe media
   stream also changes to sendrecv, activating it. This generates its
   own 200 OK and ACK.

   This flow has exactly the same properties as the proposed three-way
   handshake. However, it is backwards compatible. The only drawback is
   an additional message exchange, although there is no latency
   associated with that, just message overheads. We think this is a
   reasonable price to pay for a unified mechanism.

   The ACK overhead can be avoided by using a COMET request instead of
   the second re-INVITE.

   In Section 5.5, we show a flow that combines one-of-N selection with
   preconditions.

5.2 Change Ports on forked 2xx


   The call flow for this case is shown in Figure 5. The initial INVITE
   (message 1) contains an m line with a valid port and address, which
   the UAC is listening on for media. The proxy forks this request to
   UAS1 and UAS2, each of which respond with a 200 OK. The proxy
   forwards both of these to the UAC. The UAC ACKs both of them.
   However, with the one from UAS2, in parallel with the ACK, it
   generates a re-INVITE that changes its receive port for the session
   with UAS2. This results in a 200 OK an ACK as normal.

   The result is that media from UAS1 and UAS2 will go on separate
   ports, allowing the UA to associate a media stream with a particular
   dialog. The latency for such establishment is identical to the
   proposed three-way handhsake for this case. However, this solution
   has important benefits. First, its backwards compatible with existing
   UA. Second, if there was no forking, the flow will avoid media
   clipping. The proposed three way handshake will always suffer media
   clipping. Media clipping only occurs here if there is forking, in
   which case the media may be mixed or jarbled for 1 RTT until the port
   is changed. If such jarbling is not acceptable, the SDP in the INVITE
   can indicate an inactive stream, and then the stream can be changed
   to active in the re-INVITE. This avoids jarbling but will clip the
   media, just as the alternate proposed three way handshake will.

   The cost of the approach is an additional INVITE/200/ACK exchange.
   That cost can be reduced by using COMET instead, at the expense of
   backwards compatibility.

5.3 Secure Media




J.Rosenberg                                                  [Page 19]


Internet Draft                   unify                  January 17, 2002




         UAC           Proxy          UAS1           UAS2
          |(1) INVITE    |              |              |
          |------------->|              |              |
          |              |(2) INVITE    |              |
          |              |------------->|              |
          |              |(3) INVITE    |              |
          |              |---------------------------->|
          |              |(4) 200 OK [1]|              |
          |              |<-------------|              |
          |              |(5) 200 OK [2]|              |
          |              |<----------------------------|
          |(6) 200 OK [1]|              |              |
          |<-------------|              |              |
          |(7) 200 OK [2]|              |              |
          |<-------------|              |              |
          |(8) ACK [1]   |              |              |
          |---------------------------->|              |
          |(9) ACK [2]   |              |              |
          |------------------------------------------->|
          |(10) INVITE   |              |              |
          |------------------------------------------->|
          |(11) 200      |              |              |
          |<-------------------------------------------|
          |(12) ACK      |              |              |
          |------------------------------------------->|



   Figure 5: Call flow for changing ports



   The flow for the secure media case is nearly identical to the one-
   of-N flow in Figure 4, and is shown in Figure 6. The initial INVITE
   uses regular RTP, but simcap is used to indicate support for SRTP.
   The 200 OK and ACK result in establishment of a media session using
   regular RTP. However, the callee knows that the caller supports SRTP
   (from simcap). So, it initiates a re-INVITE, changing the profile to
   SRTP.

5.4 Early Media


   The basic flow for an early media session is shown in Figure 7. The
   caller sends an INVITE with SDP 1 in it. This is a normal SDP,
   providing a receive address and port for a single sendrecv audio
   stream. The caller supports 100rel, so it includes a Supported header



J.Rosenberg                                                  [Page 20]


Internet Draft                   unify                  January 17, 2002




       Caller    Callee
          |(1) INVITE
          |-------->|
          |(2) 200  |
          |<--------|
          |(3) ACK  |
          |-------->|
          |(4) INVITE
          |<--------|
          |(5) 200  |
          |-------->|
          |(6) ACK  |
          |<--------|



   Figure 6: Secure Media Flow




       Caller              Callee
          |(1) INVITE SDP1    |
          |------------------>|
          |(2) 183 SDP2       |
          |<------------------|
          |(3) PRACK          |
          |------------------>|
          |(4) 200 PRACK      |
          |<------------------|
          |(5) 200 INV        |
          |<------------------|
          |(6) ACK            |
          |------------------>|



   Figure 7: Basic Early Media Flow


   in the INVITE indicating that. The Allow header also indicates
   support for COMET, which implies early media capability.

   The UAS decides to generate early media. So, it answers the original
   INVITE with a 183, which is sent reliably. This 183 contains SDP,
   which is an offer to the initial answer. The answer does not change
   the directionality of the stream, implying that media can be sent in
   either direction. Upon receipt of the answer in the 183, the session



J.Rosenberg                                                  [Page 21]


Internet Draft                   unify                  January 17, 2002


   is established (although the dialog is not). The caller hears the
   early media. Finally, the callee answers, generating a 200 OK. Since
   there is no need to modify any aspect of the session description, the
   200 OK does not contain any SDP, and therefore neither does the ACK.
   The impact of the 200/ACK is only to update the dialog state, moving
   it to established.



       Caller              Callee
          |(1) INVITE SDP1    |
          |------------------>|
          |(2) 183 SDP2       |
          |<------------------|
          |(3) PRACK          |
          |------------------>|
          |(4) 200 PRACK      |
          |<------------------|
          |(5) 200 INV SDP3   |
          |<------------------|
          |(6) ACK SDP4       |
          |------------------>|



   Figure 8: Unidirectional Early Media Flow



   A slightly more complex flow is shown in Figure 8. In this case, the
   UAS would like to use unidirectional early media, from the callee
   back to the caller. The initial INVITE from the caller is identical
   to that in 7. However, the SDP in the 183 differs. The media stream
   is marked as sendonly, indicating a unidirectional flow from caller
   to callee. The user hears the early media. Once the call is setup,
   the callee needs to change the directionality to bidirectional. So,
   it issues a new offer in its 200 OK, which is identical to its
   previous SDP, but changes the direction from sendonly to sendrecv.
   The ACK contains an answer to this, which in this case indicates no
   changes. There is a smooth transition of media from early to
   bidirectional in this case.


   The flow for refusing an early media session is shown in Figure 9.
   The flow starts like Figure 7. However, when the UAC gets the answer
   in a 183, which establishes the session before the dialog is
   answered, it decides to change it. It immmediately issues a COMET
   (message 6) with a new SDP that sets that media stream to inactive.
   This is answered in the SDP in the 200 OK to COMET. The stream is now



J.Rosenberg                                                  [Page 22]


Internet Draft                   unify                  January 17, 2002




       Caller              Callee
          |(1) INVITE SDP1    |
          |------------------>|
          |(2) 183 SDP2       |
          |<------------------|
          |(3) PRACK          |
          |------------------>|
          |(4) 200 PRACK      |
          |<------------------|
          |(5) COMET SDP3     |
          |<------------------|
          |(6) 200 COMET SDP4 |
          |------------------>|
          |(7) 200 INVITE SDP5|
          |<------------------|
          |(8) ACK SDP6       |
          |------------------>|



   Figure 9: Refusing Early Media


   inactive, so the callee sends no early media. However, when the call
   is answered, the callee decides to try to restart the session. So,
   the 200 OK to the INVITE (message 7) contains an offer, changing the
   stream to sendrecv. Since the offer is an a 200 OK, the callee
   decides to accept it, and generates an answer in the ACK, which keeps
   the stream sendrecv.

   There is nothing special in this flow about the 200 OK; the callee
   could have decided to delay turning the media stream back on until
   after the 200 OK. Alternatively, if the UAS doesn't do anything to
   re-enable the stream, the UAC can offer to do so in a COMET or re-
   INVITE immediately following the receipt of the 200 OK (which would
   presumably have no SDP).

   It is important to note that refusing early media can lead to
   clipping of the "regular" media once the call is established.
   However, the model proposed here, of a totally separated notion of
   media sessions from dialogs, would argue that there is nothing
   special about the content in the media stream upon acceptance of the
   dialog.


   To demonstrate how the proposal works nicely with services, we show a
   call forward no-answer service in a proxy, where the initial UAS uses



J.Rosenberg                                                  [Page 23]


Internet Draft                   unify                  January 17, 2002




       Caller                 Proxy               Callee 1              Callee 2
          |(1) INVITE SDP1      |                     |                     |
          |-------------------->|                     |                     |
          |                     |(2) INVITE SDP1      |                     |
          |                     |-------------------->|                     |
          |                     |(3) 183 SDP2         |                     |
          |                     |<--------------------|                     |
          |(4) 183 SDP2         |                     |                     |
          |<--------------------|                     |                     |
          |(5) PRACK            |                     |                     |
          |------------------------------------------>|                     |
          |(6) 200 PRACK        |                     |                     |
          |<------------------------------------------|                     |
          |                     |(7) CANCEL           |                     |
          |                     |-------------------->|                     |
          |                     |(8) 200 CANCEL       |                     |
          |                     |<--------------------|                     |
          |                     |(9) 487 INVITE       |                     |
          |                     |<--------------------|                     |
          |(10) 155 [487 INVITE]|                     |                     |
          |<--------------------|                     |                     |
          |                     |(11) INVITE SDP1     |                     |
          |                     |------------------------------------------>|
          |                     |(12) 183 SDP3        |                     |
          |                     |<------------------------------------------|
          |(13) 183 SDP3        |                     |                     |
          |<--------------------|                     |                     |
          |(14) PRACK           |                     |                     |
          |---------------------------------------------------------------->|
          |(15) COMET SDP4      |                     |                     |
          |---------------------------------------------------------------->|
          |(16) 200 PRACK       |                     |                     |
          |<----------------------------------------------------------------|
          |(17) 200 COMET SDP5  |                     |                     |
          |<----------------------------------------------------------------|
          |                     |(18) 200 INVITE      |                     |
          |                     |<------------------------------------------|
          |(19) 200 INVITE      |                     |                     |
          |<--------------------|                     |                     |
          |(20) ACK             |                     |                     |
          |---------------------------------------------------------------->|



   Figure 10: Early Media with Services


   early media to providing ringback, as does the second UAS that is
   rung. The initial INVITE (message 1) has a single audio stream
   listing the address and port for receiving media. This is sent to a
J.Rosenberg                                                  [Page 24]


Internet Draft                   unify                  January 17, 2002


   session as in the flows above. Since the proxy does not record-route,
   the PRACK is sent directly to the callee. No COMET is issued by the
   UAC, and it therefore receives the media on the address and port from
   SDP1. At some point later, the proxy decides to try the next address.
   So, it CANCELs the INVITE (message 7). This generates a 487 to the
   initial INVITE. Now, the proxy decides to use the new 155 response
   code, to pass on the 487 (message 10). The primary advantage of this
   is to give the UAC some indication that the branch has failed. This
   UAC can use this in any way it chooses; for UI benefits, or simply
   discard it. In this instance, it is useful for the UAC to determine
   that the early dialog with Callee 1 is terminated. One use for such
   information is to know that no more media will come, and therefore,
   the port from SDP1 is safely reusable for any further media from a
   different UAS. However, in this flow, the 155 is ignored by the UAC
   and not used for that purpose.

   The proxy now proceeds to contact the second callee (message 11).
   This callee also responds with a 183 with SDP. Since this 183 is
   provided on a separate dialog, the UAC knows that this is a different
   answer to its initial offer. So, it sends a PRACK, and at the same
   time, a COMET (message 15) to provide a new port for receiving the
   second media stream. The COMET is responded to with an answer
   (message 17), which changes no aspect of the media sessions.

   At some point, callee 2 answers, generating a 200 OK and ACK, both
   without SDP. There is no change in media, and thus a smooth
   transition from early to final media with the callee.

   This flow emphasizes how the various exchanges to manipulate the
   media composition of the "early sessions" is done effectively behind
   the back of the proxy, which doesn't know, and doesn't care. The
   services it provides are unaffected by the media changes, since its
   services are based on the INVITE. In fact, an off-the-shelf RFC2543
   compliant proxy would function perfectly in providing this service.

5.5 Coupling of Resource Reservation and Signaling

   Our proposal is to model the parameters described in manyfolks as
   just additional pieces of state about the media stream. In
   particular, the strength-tag and direction tag combined indicate the
   current reservation state of the stream. Mandatory and optional
   indicate that there is no reservation in place, but one is needed.
   The value of succeeded indicates that a reservation exists, failed
   means the attempt was made but failed.

   We would argue that it is more correct to have one variable that
   describes the state of the actual reservation, which is a boolean
   flag (on or off) plus a direction. This would be a shared parameter



J.Rosenberg                                                  [Page 25]


Internet Draft                   unify                  January 17, 2002


   (that is, a media parameter whose value is negotiated since both
   sides have input to it), much like the direction attribute in SDP
   (a=sendonly, a=recvonly, a=sendrecv). When either side learns
   information about the state of the reservation, they would update
   this parameter and send it in a COMET. The reservation state can
   change in many ways; it can fail, for example, and therefore revert
   from bidirectionally reserved to no reservation at all. This is quite
   separate from the precondition, which we believe is a separate
   variable. The precondition includes a value of the reservation state
   that must be achieved before proceeding with the call (or more
   generally, alerting the user, since it can happen during a re-
   INVITE), and a strength (mandatory, optional). The precondition
   itself can be negotiated, since it, too, like the reservation state,
   is a shared parameter.

   The precondition is met when the state of the reservation equals, or
   exceeds, the precondition. It can certainly exceed it if the
   precondition is for one direction, but the reservation state gets
   established bidirectionally. Therefore, we believe that manyfolks
   needs to define an absolute order of the values of the reservation
   state in order to correctly operate. Once that is done, a concise
   statement on preconditions can be made. Specifically, the state of
   the precondition and the state of the reservation can both evolve
   over time through updates in COMET, initiated by either side. Once
   the states reach a point where the reservation state meets or exceeds
   the precondition value, the callee can be alerted and the processing
   continues.

   Even though we believe the reservation state and the precondition are
   ideally separate attributes, we believe that this semantic can be
   associated with the existing syntax, although awkwardly.

   The confirm tag in manyfolks does not actually describe reservation
   state. It can be viewed as a single-ended parameter (that is, a
   parameter whose state is not negotiated, but rather, each side
   provides its own instance of the parameter) that requests for a new
   offer when the state of the reservation changes to a particular
   value.

   Because we propose that the various SDP exchanges are not different
   from normal SDP offer/answers, there is no longer any need for the
   separate "precondition" Content-Disposition described in manyfolks.


   We begin with the simplest case, which is a basic call, without early
   media. The flow is nearly identical to the one in manyfolks. However,
   using a pure offer/answer model as proposed moves the SDP from PRACKs
   to COMETs.



J.Rosenberg                                                  [Page 26]


Internet Draft                   unify                  January 17, 2002




       Caller                Callee
          |(1) INVITE SDP1      |
          |-------------------->|
          |(2) 183 SDP2         |
          |<--------------------|
          |(3) PRACK            |
          |-------------------->|
          |(4) 200 PRACK        |
          |<--------------------|
          |(5) reservations     |
          |.....................|
          |(6) COMET SDP3       |
          |-------------------->|
          |(7) 200 COMET SDP4   |
          |<--------------------|
          |(8) 180              |
          |<--------------------|
          |(9) PRACK            |
          |-------------------->|
          |(10) 200 PRACK       |
          |<--------------------|
          |(11) 200 OK          |
          |<--------------------|
          |(12) ACK             |
          |-------------------->|



   Figure 11: Manyfolks basic call


   The caller sends an INVITE with SDP1. This SDP has a single audio
   stream, which indicates a strength of mandatory, a direction of
   sendrecv, and a confirmation. The INVITE has a Require header to
   indicate that the UAS has to support preconditions. The UAS receives
   the INVITE, and notices the required precondition processing. The
   precondition indicates that sendrecv reservation has to be in place
   before proceeding with the call. The UAS returns a 183 with an answer
   to the SDP. This answer also indicates a mandatory precondition, with
   sendrecv direcitonality, and confirmation. This is PRACKed. Both
   sides perform resource reservation, and both succeed. The UAC issues
   a COMET request. From its perspective, the state of the reservation
   state for the media stream is now successful in the receive
   direction, so the SDP in the COMET indicates that. Since the UAS has
   also succeeded, it knows that the state of the reservation is
   actually sendrecv, and so the answer in the SDP updates the state to
   successful in the sendrecv direction. Since this is the precondition,



J.Rosenberg                                                  [Page 27]


Internet Draft                   unify                  January 17, 2002


   the UAS can now proceed with the call. It alerts the user, returns a
   180 ringing, and eventually answers the call. Note that neither the
   200 or ACK contain SDP.

   Although the flow does not appear to support early media, it does.
   Once the response to the COMET arrives, the stream is active and the
   reservations have succeeded, and thus, early media can be sent. If
   the caller wished to avoid early media, the initial offer would
   indicate an inactive media stream, which could be updated in an offer
   in the 2xx, as in the exchanges above (excepting that the offer in
   the 2xx would continue to indicate that the reservation state was
   established). The result is that there is no special casing for early
   media here, and that is because early media is not being treated
   specially, its just the normal session.


   Since the exchanges are just the normal offer/answer, other aspects
   of the media streams can be updated, in addition to the reservation
   state. For example, the codec set can be modified, in order to
   perform resource reservation for the bandwidth requirements of a
   specific codec, rather than a set. The flow for this case is shown in
   Figure 12. The call proceeds initially as in Figure 11. However, once
   the answer comes in the 183, the UAC decides to modify the codec set.
   So, it generates a new offer in a COMET. The reservation state and
   preconditions remain unchanged, but now there is a single codec. The
   answer in the 200 to the COMET also indicates no change in
   reservation or precondition state, but confirms that a single codec
   is in use, and that is used to guide the reservations.

   Once preconditions are met, an additional COMET is sent (message 8)
   with an updated offer with the new values of the reservation state
   (success in the receive direction, in the case of RSVP, for example).
   This arrives at the callee. Since the callee has also succeeded in
   their reservation (which was in the caller to callee direction), the
   callee now knows that bidirectional reservations exist. Thus, the SDP
   in the answer further updates the reservation state to succeeded in
   both directions. This meets the precondition, and so it alerts and
   the call proceeds as in Figure 11.

5.6 The Heterogeneous Error Response Forking Problem (HERFP)

   One aspect of our proposal is that a UAS can send a 155 response,
   instead of a final response, when supported by the UAC, to support
   services that are complicated by HERFP. The COMET can then be used to
   provide whatever information is requested by the error response. The
   COMET would operate just like the a re-INVITE would operate if the
   actual final response had been sent.




J.Rosenberg                                                  [Page 28]


Internet Draft                   unify                  January 17, 2002




       Caller                Callee
          |(1) INVITE SDP1      |
          |-------------------->|
          |(2) 183 SDP2         |
          |<--------------------|
          |(3) PRACK            |
          |-------------------->|
          |(4) 200 PRACK        |
          |<--------------------|
          |(5) COMET SDP3       |
          |-------------------->|
          |(6) 200 COMET SDP4   |
          |<--------------------|
          |(7) reservations     |
          |.....................|
          |(8) COMET SDP5       |
          |-------------------->|
          |(9) 200 COMET SDP6   |
          |<--------------------|
          |(10) 180             |
          |<--------------------|
          |(11) PRACK           |
          |-------------------->|
          |(12) 200 PRACK       |
          |<--------------------|
          |(13) 200 OK          |
          |<--------------------|
          |(14) ACK             |
          |-------------------->|



   Figure 12: Modifying codecs in manyfolks



   To show the effectiveness of our proposal, we once again consider the
   two scenarios of Section 2.6. The call flow for the first case is now
   shown in Figure 13, except now this time with our proposed solution.
   For brevity, we ignore the PRACKs for the provisional responses. As
   before, the caller sends an INVITE, and the proxy forks it. This
   time, the proxy inserts a Require header in the request that
   indicates services are being offered based on dialog state, and so
   the UAS should send provisionals instead of finals. UAS1 challenges
   for credentials, but this time, it sends a 155 response that contains
   the challenge in the WWW-Authenticate header (message 4). The proxy
   passes this upstream to the UAC. The UAC formulates the response, and



J.Rosenberg                                                  [Page 29]


Internet Draft                   unify                  January 17, 2002




         uac             p1             uas1            uas2
          |(1) INVITE     |               |               |
          |-------------->|               |               |
          |               |(2) INVITE     |               |
          |               |-------------->|               |
          |               |(3) INVITE     |               |
          |               |------------------------------>|
          |               |(4) 155 [401]  |               |
          |               |<--------------|               |
          |(5) 155 [401]  |               |               |
          |<--------------|               |               |
          |(6) COMET      |               |               |
          |------------------------------>|               |
          |(7) 200 COMET  |               |               |
          |<------------------------------|               |
          |               |(8) 180        |               |
          |               |<--------------|               |
          |(9) 180        |               |               |
          |<--------------|               |               |
          |               |(10) 180       |               |
          |               |<------------------------------|
          |(11) 180       |               |               |
          |<--------------|               |               |
          |               |(12) 200 INVITE|               |
          |               |<--------------|               |
          |(13) 200 INVITE|               |               |
          |<--------------|               |               |
          |               |(14) CANCEL    |               |
          |               |------------------------------>|
          |               |(15) 200 CANCEL|               |
          |               |<------------------------------|
          |               |(16) 487 INVITE|               |
          |               |<------------------------------|
          |               |(17) ACK       |               |
          |               |------------------------------>|
          |(18) ACK       |               |               |
          |------------------------------>|               |



   Figure 13: HERFP fix, scenario 1


   places it in an Authorization header in the COMET (message 6). This
   goes directly to the UAS (the proxy did not record-route). Since the
   credentials are valid, the UAS proceeds with the session and rings
   the phone. It therefore generates a 180 response to the intial INVITE



J.Rosenberg                                                  [Page 30]


Internet Draft                   unify                  January 17, 2002


   (message 8), which is passed to the UAC. UAS2 does not challenge, and
   generates an immediate 180, which is passed to the UAC as well. In
   this example, as discussed in Section 2.6, the user is at UAS1, the
   call is answered there, resulting in a 200 OK (message 12). The proxy
   cancels the branch towards UAS2, and the call completes successfully
   this time!



         uac             p1             uas1            uas2
          |(1) INVITE     |               |               |
          |-------------->|               |               |
          |               |(2) INVITE     |               |
          |               |-------------->|               |
          |               |(3) 180        |               |
          |               |<--------------|               |
          |(4) 180        |               |               |
          |<--------------|               |               |
          |               |(5) CANCEL     |               |
          |               |-------------->|               |
          |               |(6) 200 OK     |               |
          |               |<--------------|               |
          |               |(7) 487        |               |
          |               |<--------------|               |
          |               |(8) ACK        |               |
          |               |-------------->|               |
          |               |(9) INVITE     |               |
          |               |------------------------------>|
          |               |(10) 155 [401] |               |
          |               |<------------------------------|
          |(11) 155 [401] |               |               |
          |<--------------|               |               |
          |(12) COMET     |               |               |
          |---------------------------------------------->|
          |(13) 200 COMET |               |               |
          |<----------------------------------------------|
          |               |(14) 200 INVITE|               |
          |               |<------------------------------|
          |(15) 200 INVITE|               |               |
          |<--------------|               |               |
          |(16) ACK       |               |               |
          |---------------------------------------------->|



   Figure 14: HERFP fix, scenario 2






J.Rosenberg                                                  [Page 31]


Internet Draft                   unify                  January 17, 2002


   Consider the second example of Section 2.6. The flow for this
   example, this time with our proposed solution, is shown in Figure 14.
   The initial flow proceeds as in Figure 3. UAS1 is rung, and there is
   no answer, resulting in a cancellation and an attempt to ring UAS2.
   UAS2 wishes to challenge. However, this time, it issues a 155 that
   otherwise looks like a 401, which contains a WWW-Authenticate header
   with the challenge. This response is passed to the proxy and
   forwarded to the UAC (once again, PRACK requests are not shown). The
   UAC generates credentials for the challenge, and sends a COMET with
   the response to the challenge. This is sent directly to UAS2, since
   the proxy did not record-route. The credentials are accepted, causing
   the phone to ring. The user is there, so they pick up, generating a
   200 OK, which is passed to the UAC, which sends an ACK to complete
   the call. Once again, a successful call setup!

6 Musings on COMET vs. re-INVITE

   It is worth discussing the differences between COMET and re-INVITE in
   this proposed solution. The current proposal would allow COMET to
   effectively modify session state, just like re-INVITE. COMET can be
   used outside of a transaction, just like re-INVITE. Just like re-
   INVITE, it would need to include full session state when used that
   way. However, unlike re-INVITE, it cannot usefully query for user
   input, since it must be answered immediately (it is a non-INVITE
   request). In principle, COMET could establish session and dialog
   state on crashed-and-rebooted or backup servers, although only when
   used outside of an INVITE transaction (since within one, it need not
   have full state, as in the HERFP flows above, where no SDP is
   present). COMET would never be used for services at proxies or
   intermediaries because of its pure end-to-end significance. However,
   it is worth noting that proxies do not provide services on re-INVITE
   anyway, for much the same reason - it makes little sense for in-
   progress calls. In hindsight, a separate method for re-INVITE,
   although with the same semantics as re-INVITE, might have been a
   better choice. However, we feel it is too widely used to be
   deprecated, and since COMET provides no real benefit for outside-of-
   a-transaction updates above and beyond re-INVITE, we believe re-
   INVITE should continue to exist and be used.

7 Proposed Process for the SIP WG

   Our proposed action plan for IETF, should this proposal be accepted,
   is the following:

        o COMET would NOT be integrated into bis. The rules in bis on
          where offer and answer can be placed need to be generalized,
          such that its still INVITE/200 or 200/ACK for baseline
          operation, but broader when COMET is used. No other changes to



J.Rosenberg                                                  [Page 32]


Internet Draft                   unify                  January 17, 2002


          bis are needed.

        o Manyfolks would be split into a COMET definition spec, and a
          preconditions specification. The COMET specification would
          enable useful early media, although it would discuss it more
          from an example perspective. Early media, as a problem,
          becomes less complex as a result of our proposal to not view
          it as special in any way. We would also not opposed keeping
          them in one specification to speed up the process.

        o The precondition specification would depend on the COMET
          specification. It would capture just the SDP attributes and
          the allowed evolutions in the precondition and reservation
          state. It would discuss how the precondition states impact
          call processing. The draft would be significantly shorter as a
          result of its more limited scope, although it would do much
          more because of the generalization that would be accomplished.

        o There are no changes to the offer/answer specification.

   A result of this is that HERFP would not be solved in bis, but only
   through an extension. We feel this is reasonable given the relatively
   large scope of the change required to fix it. The advantage of our
   process proposal is that it doesn't delay bis at all.

8 Open Issues

   There are definitely some open issues left. They are:

        o Do we also allow an offer/answer exchange in PRACK? It might
          save some messages. I chose not to in this specification,
          primarily for simplicity.

        o Is the SDP in 1xx to INVITE an offer or answer? This
          specification says its an answer. This is different from our
          earlier proposals for early media. Keeping it as an answer is
          needed to really unify early and final media. However, it has
          the side effect of introducing transient conditions of
          multiple media streams on the same port in the case of
          forking. The alternative, making it an offer, avoids that
          problem, but introduces others. More specifically, it
          guarantees clipping of media, and requires substantial
          additional protocol machinery to signal whether an SDP is an
          offer or answer. Since it is possible to handle multiple media
          streams on the same port, but the clipping is unfixable, we
          chose to go for making it an answer.

        o More thinking needs to happen on security. It is unclear to me



J.Rosenberg                                                  [Page 33]


Internet Draft                   unify                  January 17, 2002


          if the usage of COMET to provide credentials for a different
          request creates any problems. The only one I came up with was
          that it can introduce a TCP-SYN style attack at a UAS, since
          the UAS retains transaction state even for an unauthetnicated
          request. However, this problem is less of an issue in a UAS
          than a proxy. The UAS could use 155 for the first two calls,
          and then statelessly reject any other unauthenticated
          requests. That would work for single user devices. Gateways
          typically don't challenge individual requests at all, so there
          is not likely to be an issue there either. Thus, the TCP-SYN
          style problem may not be applicable in this case because its a
          UAS, not a proxy.

        o With all of the various places one can find offers and answers
          in SIP message, it might get confusing about where one can
          find each of them, and whether a particular SDP is an answer
          to an offered one. Historically, we have gotten into trouble
          whenever there was no explicit matching between things (m
          lines in SDP). Therefore, it might be valuable to specify a
          mechanism for matching answers to offers. This would provide
          substantial flexibility in which messages they can occur,
          beyond the rules specified above. We believe this would have
          very positive impacts on 3pcc, for example, which could become
          more robust through the use of COMET to exchange the various
          offers before call completion.

9 Acknowledgements

   We'd like to thank Robert Sparks for his review and comments.

10 Author's Addresses


   Jonathan Rosenberg
   dynamicsoft
   72 Eagle Rock Avenue
   First Floor
   East Hanover, NJ 07936
   email: jdrosen@dynamicsoft.com




11 Bibliography

   [1] J. Rosenberg and H. Schulzrinne, "An offer/answer model with
   SDP," Internet Draft, Internet Engineering Task Force, Oct. 2001.
   Work in progress.



J.Rosenberg                                                  [Page 34]


Internet Draft                   unify                  January 17, 2002


   [2] J. Rosenberg, H. Schulzrinne, et al.  , "SIP: Session initiation
   protocol," Internet Draft, Internet Engineering Task Force, Oct.
   2001.  Work in progress.

   [3] M. Handley and V. Jacobson, "SDP: session description protocol,"
   Request for Comments 2327, Internet Engineering Task Force, Apr.
   1998.

   [4] F. Andreasen, "SDP simple capability negotiation," Internet
   Draft, Internet Engineering Task Force, Aug. 2001.  Work in progress.

   [5] W. Marshall et al.  , "Integration of resource management and
   SIP," Internet Draft, Internet Engineering Task Force, Aug. 2001.
   Work in progress.

   [6] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a
   transport protocol for real-time applications," Request for Comments
   1889, Internet Engineering Task Force, Jan. 1996.

   [7] R. Blom et al.  , "The secure real time transport protocol,"
   Internet Draft, Internet Engineering Task Force, Feb. 2001.  Work in
   progress.

   [8] J. Rosenberg, "SIP early media," Internet Draft, Internet
   Engineering Task Force, July 2001.  Work in progress.

   [9] S. Sen et al.  , "Early media issues and scenarios," Internet
   Draft, Internet Engineering Task Force, July 2001.  Work in progress.

   [10] E. Burger, "Why early media in sip," Internet Draft, Internet
   Engineering Task Force, Oct. 2001.  Work in progress.

   [11] J. Rosenberg, "Reconsituting call state in SIP user agents,"
   Internet Draft, Internet Engineering Task Force, July 2001.  Work in
   progress.

   [12] H. Schulzrinne, G. Camarillo, and D. Oran, "The reason header
   field for the session initiation protocol," Internet Draft, Internet
   Engineering Task Force, Dec. 2001.  Work in progress.

   [13] S. Floyd and L. Daigle, "IAB architectural and policy
   considerations for OPES," Internet Draft, Internet Engineering Task
   Force, Nov. 2001.  Work in progress.








J.Rosenberg                                                  [Page 35]


Internet Draft                   unify                  January 17, 2002


   Full Copyright Statement

   Copyright (c) The Internet Society (2002). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document. For more information consult the online list of claimed
   rights.



















J.Rosenberg                                                  [Page 36]