Subject: Protocol Action: The Session Initiation Protocol UPDATE Method to Proposed Standard

From: The IESG <[email-masked]>
Date: Fri, 17 May 2002 17:17:04 -0400

The IESG has approved the publication of the following two I-Ds as
Proposed Standards:

 o The Session Initiation Protocol UPDATE Method
	<draft-ietf-sip-update-02.txt>

 o Integration of Resource Management and SIP 
	<draft-ietf-sip-manyfolks-resource-07.txt> 

These documents are the product of the Session Initiation Protocol
Working Group.  The IESG contact persons are Allison Mankin and Scott
Bradner.

Technical Summary
 
      UPDATE is a new method for the Session Initiation protocol.  It
      allows a client to update parameters of a session (such as the
      set of media streams and their codecs) but has no impact on the
      state of the dialog. This means that it functions like a
      re-INVITE (sending a second INVITE methd), but it can be sent
      before the initial INVITE has completed, and therefore can serve
      purposes of early dialog negotiation. UPDATE needs source
      authentication and integrity protection, which are provided by
      mechanisms in RFC BBBB, the SIP protocol specification.

      Some architectures require that at session establishment time,
      once the callee has been alerted, the chances of a session
      establishment failure are minimum. One source of failure is the
      inability to reserve network resources for a session. In order to
      minimize "ghost rings", it is necessary to reserve network
      resources for the session before the callee is alerted. However,
      the reservation of network resources frequently requires learning
      the IP address, port, and session parameters from the callee.
      This information is obtained as a result of the initial offer/
      answer Exchange carried in SIP. This exchange normally causes the
      "phone To ring", thus introducing a chicken-and-egg problem:
      resources cannot be reserved without performing an initial
      offer/answer exchange, and the initial offer/answer exchange
      can't be done without performing resource reservation.

      The solution is to introduce the concept of a precondition.  A
      precondition is a set of constraints about the session which are
      introduced in the offer. The recipient of the offer generates an
      answer, but does not alert the user or otherwise proceed with
      session establishment. That only occurs when the preconditions
      are met. This can be known through a local event (such as a
      confirmation of a resource reservation), or through a new offer
      sent by the caller. Any specifics of resource reservation
      mechanisms or how a SIP endpoint might get local confirmation of
      the precondition being met are outside the scope of resource
      management integration specification.

      The preconditions are defined in the Session Description Protocol
      (SDP) parameters for the session, and the exchange in the SDP
      offer-answer, because they apply to specific media streams
      identified with the SDP body in SIP. Security needed for the
      preconditions exchanges includes source authentication and
      integrity protection, and these are provided by mechanisms in RFC
      BBBB.

Working Group Summary
 
      The resource management integration spec was simplified
      considerably by the introduction of the UPDATE method.
      After that simplifying revision, both specs were strongly
      supported by the working group for advancement.
 
Protocol Quality
 
      The specifications were reviewed for the IESG by Allison Mankin.
      John Loughney also did a careful review of the resource
      management integration spec.