draft-ietf-sip-rfc3312-update-01.txt   draft-ietf-sip-rfc3312-update-02.txt 
SIP Working Group G. Camarillo SIP Working Group G. Camarillo
Internet-Draft Ericsson Internet-Draft Ericsson
Expires: November 30, 2004 P. Kyzivat Expires: March 19, 2005 P. Kyzivat
Cisco Systems Cisco Systems
June 2004 September 18, 2004
Update to the Session Initiation Protocol (SIP) Preconditions Update to the Session Initiation Protocol (SIP) Preconditions
Framework Framework
draft-ietf-sip-rfc3312-update-01.txt draft-ietf-sip-rfc3312-update-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 30, 2004. This Internet-Draft will expire on March 19, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document updates the framework for preconditions in SIP. We This document updates the framework for preconditions in SIP. We
provide guidelines for authors of new precondition types and describe provide guidelines for authors of new precondition types and describe
how to use SIP preconditions in situations that involve session how to use SIP preconditions in situations that involve session
skipping to change at page 4, line 32 skipping to change at page 4, line 32
Specifications defining new precondition types MUST describe whether Specifications defining new precondition types MUST describe whether
or not optional preconditions are applicable, and in case they are, or not optional preconditions are applicable, and in case they are,
what is the expected behavior of a UA on reception of optional what is the expected behavior of a UA on reception of optional
preconditions. preconditions.
3.4 Suspending and Resuming Session Establishment 3.4 Suspending and Resuming Session Establishment
Section 6 of RFC 3312 [3] describes the behavior of UAs from the Section 6 of RFC 3312 [3] describes the behavior of UAs from the
moment session establishment is suspended due to a set of moment session establishment is suspended due to a set of
preconditions until is resumed when these preconditions are met. In preconditions until is resumed when these preconditions are met. In
general, the called users is not alterted until the preconditions are general, the called user is not alterted until the preconditions are
met. met.
Still, in addition to not alerting the user, each precondition type Still, in addition to not alerting the user, each precondition type
MUST define any extra actions UAs should perform or keep from MUST define any extra actions UAs should perform or refrain from
performing when session establishment is suspended. So, the behavior performing when session establishment is suspended. The behavior of
of media streams during session suspension is part of the definition media streams during session suspension is therefore part of the
of a particular precondition type. Some precondition types may allow definition of a particular precondition type. Some precondition types
media streams to send and receive packets during session suspension; may allow media streams to send and receive packets during session
others may not. Consequently, the following paragraph from RFC 3312 suspension; others may not. Consequently, the following paragraph
only appplies to QoS preconditions: from RFC 3312 only appplies to QoS preconditions:
While session establishment is suspended, user agents SHOULD not While session establishment is suspended, user agents SHOULD not
send any data over any media stream. In the case of RTP, neither send any data over any media stream. In the case of RTP, neither
RTP nor RTCP packets are sent. RTP nor RTCP packets are sent.
As a clarification to the previous paragraph, the control messages As a clarification to the previous paragraph, the control messages
used to establish connections in connection-oriented transport used to establish connections in connection-oriented transport
protocols (e.g., TCP SYNs) are not affected by the previous rule. So, protocols (e.g., TCP SYNs) are not affected by the previous rule. So,
user agents follow standard rules (e.g., the SDP a:setup attribute user agents follow standard rules (e.g., the SDP a:setup attribute
[7]) to decide when to establish the connection, regardless of the [7]) to decide when to establish the connection, regardless of the
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/