One document matched: draft-elwell-sip-state-update-02.txt
Differences from draft-elwell-sip-state-update-01.txt
Internet Engineering Task Force J. Elwell
Internet Draft Siemens
V. Venkataramanan
Sylantro Systems Corp
draft-elwell-sip-state-update-02.txt
Expires: December 2004 June 2004
State update during a SIP dialog
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
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
RFC 3667.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress. "
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document examines the need for updating state information, such
as remote party identity, during a SIP dialog. It explores existing
mechanisms that might be appropriate and proposes minor
clarifications to existing RFCs and drafts to achieve this.
Elwell et alia Expires - December 2004 [Page 1]
State update during a SIP dialog June 2004
Table of Contents
1 Introduction....................................................3
2 State information subject to change during a dialog.............3
3 Applicability of existing mechanisms............................4
3.1 UPDATE........................................................4
3.2 re-INVITE.....................................................5
3.3 INVITE with Replaces header...................................6
4 Proposal........................................................6
5 Clarifications to RFC 3261[1]...................................7
6 Clarifications to RFC 3311 [2]..................................8
7 Clarification to RFC 3325 [4]..................................10
8 Clarification to draft-ietf-sip-authid-body-02 [6].............11
9 Changes........................................................11
10 Author's Addresses............................................11
11 Normative References..........................................11
Elwell et alia Expires - December 2004 [Page 2]
State update during a SIP dialog June 2004
1 Introduction
Certain information exchanged between SIP [1] UAs during an INVITE
transaction can be stored at a receiving UA for the lifetime of the
resulting dialog and/or made available to the user (e.g., via a
display in the case of a human user). One example is the identity of
the peer user (as supplied in the To or From header, the
Authenticated Identity Body (AIB) or the P-Asserted-Identity header).
Another example is the Subject header. This information forms part of
the state of a dialog at a UA.
Under certain circumstances some of this state information may need
to be changed. For example, when interworking with a PSTN, there may
be a change of party in the PSTN (e.g., because of call transfer).
The PSTN party identity sent to the peer SIP UA in the To or From
header, the AIB or the P-Asserted-Identity header during dialog
establishment normally reflects the identity of the PSTN user. If the
identity of the PSTN user changes during the lifetime of the dialog,
this information needs to be updated at the UA.
A second example involves 3rd party call control. A B2BUA performing
3rd party call control can perform actions such as call transfer that
cause a change of membership of the call. An existing UA that remains
involved in the call and retains its dialog with the B2BUA needs to
be updated with the identity of the new remote party.
A third example also involves 3rd party call control. In this case a
B2BUA forms a conference and acts as a conference focus. It therefore
needs to indicate this to any existing UA whose dialog is
"transferred" into that conference.
A fourth example is where a user changes the subject during a dialog.
The revised subject needs to be communicated to the remote UA.
Existing mechanisms for changing a session during a dialog (re-INVITE
and UPDATE transactions) may be a suitable basis for making other
state changes, but it is not at present clear if and how these
mechanisms are applicable.
2 State information subject to change during a dialog
The following information exchanged during the INVITE transaction can
change during the lifetime of the resulting dialog.
- Call-Info header.
- Alert-Info header (early dialogs only).
Elwell et alia Expires - December 2004 [Page 3]
State update during a SIP dialog June 2004
- Contact header (change of feature tags [3]).
- Reply-To header.
- Subject header.
- P-Asserted-Identity header [4].
- Privacy header [5] (for use in conjunction with updated identity
information).
- Authenticated Identity Body (AIB) [6].
- Bodies with Content-Disposition "icon" or "alert".
In addition consideration should be given to the following headers:
Allowed, Supported, Required. These would not normally be expected to
change at a UA reporting a state change. However, there might be some
B2BUA arrangements where Allowed, Supported and Required are sent by
the B2BUA on behalf of another UA, and if that other UA changes,
these headers might change.
Current studies on including location information in SIP messages [7]
should also take into account the need to update location information
during a dialog. One application might be a direction service, which
provides directions from the caller's current location to a given
venue. As the caller's location changes (e.g., as detected by GPS),
the location information may need to be updated. Another application
is emergency calling, where more accurate location information
becomes known during the dialog.
3 Applicability of existing mechanisms
3.1 UPDATE
The UPDATE mechanism [2] provides a means for updating the session
using a 2-message sequence (request/response) during an INVITE-
initiated dialog. Although one of the prime motivations for UPDATE is
use during an early dialog (in conjunction with the PRACK method),
where re-INVITE cannot be used, UPDATE can also be used during a
confirmed dialog. The RFCs concerned are unclear on the use of UPDATE
for updating the following state information:
Call-Info header. According to [2], this is optional in an UPDATE
request, but no semantics are given. It is unclear whether this is
allowed to differ from what was in the INVITE request or response,
and if so the meaning of this.
Elwell et alia Expires - December 2004 [Page 4]
State update during a SIP dialog June 2004
Alert-Info header. According to [2], this is not applicable in an
UPDATE request. However, a possible use during an early dialog would
be to change the alerting indication or ringback tone.
Contact header. According to [2], this is mandatory in an UPDATE
request. In [3] there is mention of updating feature parameters
during a dialog.
Reply-To header. This is not allowed in an UPDATE request.
Subject header. According to [2], this is not allowed in an UPDATE
request.
P-Asserted-Identity header. According to [4], this header is not
allowed in an UPDATE request.
Privacy header. There is no mention in [5] of using this header in an
UPDATE request.
AIB. [6] does provide for the use of AIB in a request within the
context of an existing dialog. However, it does not mention UPDATE
specifically. Also, it does not mention semantics, e.g., whether an
AIB in a request in an existing dialog overrides any AIB in the
original request or response.
Content-Disposition "icon" or "alert". There is no mention of bodies
with these Content-Disposition values, but presumably nothing to
prevent their inclusion.
3.2 re-INVITE
The re-INVITE mechanism [1] provides a means for updating the session
during an INVITE-initiated dialog. It differs from UPDATE in that it
uses a three message sequence (request, response, ACK), and this
takes account of possible delays while a user is consulted on the
proposed update. Therefore for updating the session on a confirmed
dialog, re-INVITE will often be preferred to UPDATE. If state
information needs to be updated at the same time as the session, re-
INVITE might be the preferred choice. At other times UPDATE might be
the preferred choice for updating state information. Another
consideration is that some SIP implementations do not currently
support UPDATE.
The RFCs concerned are unclear on the use of re-INVITE for updating
the following state information:
Call-Info header. According to [1], this is optional in an INVITE
request, but there is no specific mention of re-INVITE. It is unclear
Elwell et alia Expires - December 2004 [Page 5]
State update during a SIP dialog June 2004
whether this is allowed to differ from what was in the original
INVITE request or response, and if so the meaning of this.
Contact header. According to [1], this is mandatory in a re-INVITE
request. In [3] there is mention of updating feature parameters
during a dialog.
Reply-To header. According to [1], this is optional in an INVITE
request, but there is no specific mention of re-INVITE. It is unclear
whether this is allowed to differ from what was in the original
INVITE request or response, and if so the meaning of this.
Subject header. According to [2], this is optional in an INVITE
request, but there is no specific mention of re-INVITE. It is unclear
whether this is allowed to differ from what was in the original
INVITE request or response, and if so the meaning of this.
P-Asserted-Identity header. There is no mention in [4] of using this
header in a re-INVITE request.
Privacy header. There is no mention in [5] of using this header in a
re-INVITE request.
AIB. [6] does provide for the use of AIB in a request within the
context of an existing dialog. However, it does not mention re-INVITE
specifically. Also, it does not mention semantics, e.g., whether an
AIB in a request in an existing dialog overrides any AIB in the
original request or response.
Content-Disposition "icon" or "alert". There is no mention of bodies
with these Content-Disposition values in a re-INVITE request, but
presumably nothing to prevent their inclusion.
3.3 INVITE with Replaces header
Rather than updating state information for the existing dialog, a new
dialog could be created using an INVITE addressed to the remote
contact (assuming this is a GRUU) and the Replaces header, thereby
causing the new dialog to replace the existing dialog. This is a
heavyweight method of achieving the desired results. In particular it
requires support of the Replaces header, support of GRUUs, and re-
negotiation of the session.
4 Proposal
It is proposed that the use of the UPDATE method for updating state
information during a confirmed or early dialog be endorsed. It is
also proposed that the use of the re-INVITE method be endorsed for
updating state information during a confirmed dialog for cases where
Elwell et alia Expires - December 2004 [Page 6]
State update during a SIP dialog June 2004
the peer UA does not support UPDATE or when the session is to be
updated at the same time.
In order to achieve this, clarifications are required to some
existing RFCs:
- RFC 3261: Clarify that a re-INVITE can be used to update dialog-
related information during a dialog, i.e., not just a target refresh
or a session description change.
- RFC 3311: Clarify that an UPDATE can be used without a session
description in order to update dialog-related information. This is
already implicit in some places, but a few places seem to require an
UPDATE request to contain an SDP offer.
- RFC 3323: This does not specify specific procedures for particular
methods and does not make any distinction between a request outside
of an existing dialog or a request within a dialog. Therefore as it
stands it is in theory equally applicable to UPDATE and re-INVITE as
it is to INVITE. However, certain privacy services may not be
possible to provide during a dialog if not already provided from the
start of the dialog. Its main usefulness seems to be to indicate
privacy for an updated P-Asserted-Identity header or an updated
Authenticated Identity Body. No changes are proposed.
- RFC 3325: Allow the use of the P-Asserted-Identity header with the
UPDATE method. The RFC does not specify specific procedures for
particular methods and does not make any distinction between a
request outside of an existing dialog or a request within a dialog.
Therefore as it stands it is equally applicable to UPDATE (with the
proposed change) and re-INVITE as it is to INVITE. Therefore no
procedural changes need to be made.
- draft-ietf-sip-authid-body-02: Add mention of use of AIB in re-
INVITE or UPDATE.
The remainder of this draft proposes detailed clarifications.
5 Clarifications to RFC 3261[1]
Add the following paragraph to the end of 12 (prior to 12.1):
"A dialog can also have certain other state information that can
change during the lifetime of the dialog. This includes the session
description (as negotiated by SDP offer/answer), information from
certain other headers and information from certain other bodies.
Examples from this RFC include the Alert-Info, Call-Info, Reply-To
and Subject headers and bodies with a value of "icon" or "alert" in
the Content-Disposition header. Extensions may define other headers
Elwell et alia Expires - December 2004 [Page 7]
State update during a SIP dialog June 2004
or bodies containing information that contributes to the state of a
dialog and can change during the lifetime of the dialog."
Add two new paragraphs to the end of 12.2 (prior to 12.2.1):
"A request, whether or not it is a target refresh request, MAY
update certain other information transmitted at the time of dialog
establishment. Examples include the following headers from this
RFC: Alert-Info, Call-Info, Reply-To and Subject. Other extensions
may define other headers that are appropriate for updating during a
dialog. In addition, a request, whether or not it is a target
refresh request, MAY update a body with a value of "icon" or
"alert" in the Content-Disposition header.
"In this RFC, the only request defined that is suitable for
updating information during a dialog is re-INVITE (see section 14).
Other extensions may define different requests suitable for
updating information during a dialog."
Add to the end of the first paragraph of 14.1:
"A UAC MAY send a session description that is unchanged, if the
purpose of the re-INVITE is solely for updating dialog-related
information."
6 Clarifications to RFC 3311 [2]
General
Call-Info
Alert-Info
Reply-To
Subject
Add to the end of the last paragraph of section 1:
"It can also be sent by a UA within a dialog (early or confirmed)
to update dialog-related information in addition to or instead of
updating session parameters."
Replace the last sentence of section 3:
Old text: "There are additional constraints on when UPDATE can be
used, based on the restrictions of the offer/answer model."
New text: "The UPDATE method can also be used without SDP
offer/answer in order to update only dialog-related information and
not the session. There are additional constraints on when UPDATE
can be used with SDP offer/answer, based on restrictions of the
offer/answer model."
Elwell et alia Expires - December 2004 [Page 8]
State update during a SIP dialog June 2004
Change "MAY" to "SHOULD" in the 2nd paragraph of section 4:
Old text: "An unreliable provisional response MAY contain an Allow
header field listing the UPDATE method ...
New text: "An unreliable provisional response SHOULD contain an
Allow header field listing the UPDATE method ...
Extend the last sentence of the 3rd paragraph of section 4:
Old text: "Creation of this dialog is necessary in order to receive
UPDATE requests from the callee."
New text: "Creation of this dialog is necessary in order to receive
UPDATE requests from the callee and in order to receive an SDP
offer in an UPDATE request from the caller."
Add the following paragraph at the end of section 4:
"Although a UAS for an INVITE request must use a reliable
provisional response in order to ensure that an early dialog is
created before issuing an UPDATE request towards the caller, a UAC
for an INVITE request will know that an early dialog is established
even if it receives an unreliable provisional response. The UAC for
the INVITE request MAY then issue an UPDATE request without an SDP
offer towards the callee, subject to having received an appropriate
Allow header field."
Replace the 3rd sentence of section 5.1:
Old text: "Although UPDATE can be used on confirmed dialogs, it is
RECOMMENDED that a re-INVITE be used instead."
New text: "Although UPDATE can be used on confirmed dialogs, it is
RECOMMENDED that a re-INVITE be used instead if there is a need to
seek user approval."
Replace the last sentence of the 2nd bullet of section 5.1:
Old text: "Of course, it can't send an UPDATE if it has not
received answers to any other offers it sent in either PRACK or
UPDATE, or has not generated answers for any other offers it
received in an UPDATE from the callee."
New text: "Of course, it can't send an UPDATE containing an offer
if it has not received answers to any other offers it sent in
either PRACK or UPDATE, or has not generated answers for any other
offers it received in an UPDATE from the callee."
Elwell et alia Expires - December 2004 [Page 9]
State update during a SIP dialog June 2004
Add a new paragraph at the end of section 5.2:
"If a UA receives an UPDATE request with no session description for
an existing dialog, the UA MUST NOT include a session description
in the response. In this case the UPDATE request is for the purpose
of target refresh or updating other dialog-related information".
Change the following row in table 1:
Old: Alert-Info -
New: Alert-Info o
Change the following rows in table 2:
Old: Reply-To -
New: Reply-To o
Old: Subject - -
New: Subject o
7 Clarification to RFC 3325 [4]
In section 9.1, change the additional entry to table 1 of RFC 3261 as
follows (to make UPDATE optional):
Old:
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-Asserted-Identity adr - o - o o -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
o o o - - -
New:
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-Asserted-Identity adr - o - o o -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
o o o - o -
Elwell et alia Expires - December 2004 [Page 10]
State update during a SIP dialog June 2004
8 Clarification to draft-ietf-sip-authid-body-02 [6]
Add the following to the first paragraph of section 5:
"An AIB in a request within the context of an existing dialog
(e.g., re-INVITE, UPDATE) can be used to replace the corresponding
identity transmitted at the start of the dialog."
9 Changes
Draft-02: The following changes have been made compared with draft
01:
- Addition of bodies with Content-Disposition "icon" or "alert" to
state information that can be changed during a call. (Sections 2,
3.1, 3.2 and 5).
- Addition to section 5 of proposed text for section 12 of RFC3261
elaborating on the state of a dialog.
- Deletion of the open issue in section 5 concerning the ability to
have more than one concurrent re-INVITE request outstanding. There
was a feeling that it might get too complex.
- Addition of discussion on location information in section 2.
10 Author's Addresses
John Elwell
Siemens Communications
Technology Drive
Beeston
Nottingham, UK, NG9 1LA
email: john.elwell@siemens.com
Venkatesh Venkataramanan
Sylantro Systems Corp
910 E Hamilton Ave,
Campbell, CA 95008
Sylantro inc.
email: Venkatesh.Venkataramanan@sylantro.com
11 Normative References
[1] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation
protocol", RFC 3261.
Elwell et alia Expires - December 2004 [Page 11]
State update during a SIP dialog June 2004
[2] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE
method", RFC 3311.
[3]J. Rosenberg, H. Schulzrinne, P. Kyzivat, "Indicating User Agent
Capabilities in the Session Initiation Protocol (SIP)", draft-ietf-
sip-callee-caps-03.txt (work in progress).
[4] C. Jennings, J. Peterson, M. Watson, "Private Extensions to the
Session Initiation Protocol (SIP) for Asserted Identity within
Trusted Networks", RFC 3325.
[5] J. Peterson. "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323.
[6] J. Peterson. "SIP Authenticated Identity Body (AIB) Format",
draft-ietf-sip-authid-body-02.txt (work in progress).
[7] J. Polk, B. Rosen. "Requirement for Session Initiation Protocol
Location Conveyance", draft-ietf-sipping-location-requirements-00.txt
(work in progress).
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
Elwell et alia Expires - December 2004 [Page 12]
State update during a SIP dialog June 2004
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Elwell et alia Expires - December 2004 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 06:52:54 |