From - Fri May 17 18:15:20 2002 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from optimus.ietf.org (ietf.org [132.151.1.19]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4HLXj2h027412; Fri, 17 May 2002 17:33:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03183; Fri, 17 May 2002 17:17:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03110 for ; Fri, 17 May 2002 17:17:23 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06040; Fri, 17 May 2002 17:17:04 -0400 (EDT) Message-Id: <200205172117.RAA06040@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , sip@ietf.org From: The IESG Date: Fri, 17 May 2002 17:17:04 -0400 Subject: [Sip] Protocol Action: The Session Initiation Protocol UPDATE Method to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The IESG has approved the publication of the following two I-Ds as Proposed Standards: o The Session Initiation Protocol UPDATE Method o Integration of Resource Management and SIP 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. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip