One document matched: draft-elwell-sip-state-update-00.txt
Internet Engineering Task Force J. Elwell
Internet Draft Siemens
V. Venkataramanan
Sylantro Systems Corp
draft-elwell-sip-state-update-00.txt
Expires: August 2004 February 2004
State update during a SIP dialog
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC 2026.
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.
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 identifies matters that need
to be fixed to make this possible.
Elwell et alia Expires - August 2004 [Page 1]
State update during a SIP dialog February 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 Author's Addresses..............................................6
6 Normative References............................................7
Elwell et alia Expires - August 2004 [Page 2]
State update during a SIP dialog February 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 - August 2004 [Page 3]
State update during a SIP dialog February 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].
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 were Allowed, Supported and Required are sent by
the B2BUA on behalf of another UA, and if that other UA changes,
these headers might change.
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.
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, but there is no mention in [3] of the use of feature tags in
an UPDATE request.
Reply-To header. This is not allowed in an UPDATE request.
Subject header. According to [2], this is not allowed in an UPDATE
request.
Elwell et alia Expires - August 2004 [Page 4]
State update during a SIP dialog February 2004
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.
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
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, but there is no mention in [3] of the use of feature tags in
a re-INVITE request.
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.
Elwell et alia Expires - August 2004 [Page 5]
State update during a SIP dialog February 2004
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.
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
the peer UA does not support UPDATE or when the session is to be
updated at the same time.
There are several options for documenting this:
1. Revise all the relevant RFCs (including the imminent callee
capabilities RFC).
2. Just revise the RFC 3311 (UPDATE) and RFC3261 to cover state
information update, e.g., by means of published errata.
3. Write a new RFC to extend the use of UPDATE and re-INVITE to state
information update.
5 Author's Addresses
John Elwell
Siemens Communications
Technology Drive
Beeston
Nottingham, UK, NG9 1LA
Elwell et alia Expires - August 2004 [Page 6]
State update during a SIP dialog February 2004
email: john.elwell@siemens.com
Venkatesh Venkataramanan
Sylantro Systems Corp
910 E Hamilton Ave,
Campbell, CA 95008
Sylantro inc.
email: Venkatesh.Venkataramanan@sylantro.com
6 Normative References
[1] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation
protocol", RFC 3261.
[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-02.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).
Elwell et alia Expires - August 2004 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-24 06:53:53 |