Internet Engineering Task Force J. Elwell
Internet Draft Siemens
draft-elwell-sip-session-retention-00.txt
Expires: August 2005 February 2005
Session retention during SIP INVITE/Replaces
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,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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 proposes a method or retaining a session when a SIP
dialog between two UAs is replaced by another dialog between those
same two UAs in order to update dialog-related information such as
identity.
Elwell Expires - August 2005 [Page 1]
Session retention during SIP INVITE/ReplacesFebruary 2005
Table of Contents
1 Introduction....................................................3
2 Background......................................................3
3 Proposal........................................................5
4 Open issues.....................................................5
5 Security Considerations.........................................5
6 Author's Addresses..............................................6
7 References......................................................6
Elwell Expires - August 2005 [Page 2]
Session retention during SIP INVITE/ReplacesFebruary 2005
1 Introduction
The Session Initiation Protocol (SIP) [SIP] uses the Session
Description Protocol (SDP) [SDP] for establishing a session
comprising one or more media streams between User Agents (UAs).
Session negotiation using SDP takes place in accordance with the
offer/answer model [OA]. When establishing a SIP INVITE-initiated
dialog, session negotiation normally takes place in parallel. The
session remains associated with the dialog and terminates when the
dialog terminates, normally as a result of a SIP BYE transaction.
There are circumstances where a dialog between two SIP UAs may need
to be replaced by a new dialog between those same two UAs in order to
update certain dialog-related information. This may need to be done
without disruption to media flows, and hence retention of the
existing session would seem desirable. The background to this is
given in section 2. Section 3 proposes a solution to the problem,
involving small changes to [SIP] and [Replaces].
2 Background
During dialog establishment there are various means by which the SIP
INVITE request can indicate to the UAS the identity of the UAC user.
One example is the From header, although this suffers from lack of
authentication. Other examples are Authenticated Identity Body [AIB]
and the Identity header [ID]. The UAC generally assumes that the
identity of the UAS user is the identity placed in the To header,
although in some circumstances retargeting of the request can render
this inaccurate. Study continues on how to provide authenticated
identity information in a response.
There has also been discussion on how to indicate change of identity
during a dialog.
One example of where identity can change during a dialog involves
interworking with a legacy network via a UA that acts as a gateway.
Establishment of an INVITE-initiated dialog (and associated session)
to or from a gateway generally involves signalling the identity of
the user of the legacy network (e.g., a telephone number in a sip: or
tel: URI). Transfer or similar behaviour within the legacy network
can cause this identity to change. It would be highly desirable to be
able to signal the new identity to the peer UA, which could use it
for display purposes, call logging purposes, etc..
Another example is where a SIP B2BUA has third party call control
capabilities and can join two dialogs together. When an existing
dialog is joined to a different dialog from that to which it was
Elwell Expires - August 2005 [Page 3]
Session retention during SIP INVITE/ReplacesFebruary 2005
previously joined, there may be a need to signal a new identity to
the peer UA on the existing dialog.
Recent discussions on how to achieve signalling of a new identity
have led to consideration of several candidate solutions. Some of
those solutions involved retaining the dialog and signalling the new
identity using the (re)INVITE method or the UPDATE method [UPD], but
these all have unresolved issues. The solution finding the most
favour involved establishing a new dialog using the INVITE method
with the Replaces header [REPL] and exploiting existing identity-
related signalling in the INVITE transaction.
With the latter solution, the UA wishing to report a new identity
issues an INVITE request addressed to the peer UA (e.g., by means of
a Globally Routable UA URI (GRUU) [GRUU] and includes in that request
a Replaces header field identifying the existing dialog. The From
header in conjunction with authenticated identity information in the
INVITE request advises the UAS of the new identity. From the
perspective of the UAS, this looks exactly like a call transfer
situation, which in general is the event that has led to the need to
carry out this action. The only difference in the cases considered
here is that the UAC for the INVITE/Replaces request is already a
participant in the replaced dialog.
Because in this case the replaced dialog and the new dialog are both
between the same two UAs, the question arises as to what should
happen to the session associated with the replaced dialog. According
to section 15 of [SIP], the BYE transaction, which occurs when the
dialog is replaced, terminates the session. The INVITE/Replaces
transaction will initiate a new session to replace the original
session. However, the new session may be identical in all respects to
the replaced session. This is particularly likely to be the case in
the gateway example above. Both sessions will be between the gateway
and the peer UA and in general will comprise the same media and
parameters. When transfer in the legacy network occurs, any switching
of media streams occurs within that legacy network and should not
have impact on the media streams flowing between the gateway and the
peer UA in the SIP network. In fact, any disruption to the existing
session could have a detrimental effect, since the disruption might
occur slightly later than the disruption in the legacy network, by
which time meaningful media might have started to flow again between
the new endpoint in the legacy network and the peer UA in the SIP
network. For example, in the case of audio one of the users may have
started to speak. Closing down a session and establishing a new
session could cause disruption to the flow of media.
To overcome this it would be useful to have a means of retaining the
existing session when replacing the dialog in this manner.
Elwell Expires - August 2005 [Page 4]
Session retention during SIP INVITE/ReplacesFebruary 2005
3 Proposal
An SDP offer or answer contains a session ID and version. Repeated
offer/answer exchanges during an existing dialog for the purpose of
modifying the session will use the same session ID but increment the
version, in accordance with [OA].
In order to retain the existing session without change when
establishing a new dialog to replace an existing dialog between the
same two UAs, it is proposed that the SDP offer in the
INVITE/Replaces request contain the same session ID and the same
version as the existing session on the replaced dialog. In this
situation, and assuming the UAS accepts the INVITE/Replaces request
by sending a 2xx response, both UAs MUST retain the existing session
without modification and without disrupting the media streams. All
session parameters MUST remain the same, including any session keys
for secured media. The UAS MUST NOT follow this behaviour if the
remote targets of the two dialogs do not match or if any SDP
parameters have changed.
It is also proposed that in order to modify the existing session, the
SDP offer in the INVITE/Replaces request contain the same session ID
as the existing session and a version incremented by one. If the UAS
accepts the INVITE/Replaces together with the modified session by
sending a 2xx response, both UAs MUST retain the existing session
modified in accordance with the offer/answer. If the UAS cannot
accept the modified session it will issue a 488 response as normal.
The UAS MUST NOT follow this behaviour if the remote targets of the
two dialogs do not match.
Any other values for session ID and version in the offer in the
INVITE/Replaces request MUST be treated as a request to establish a
new session and terminate the existing session.
These proposed changes would need to be documented as follows:
- A change to section 15 of [SIP] to permit session retention
following a BYE transaction in these circumstances.
- A change to [REPL] to specify this specific behaviour when the
Replaces header is used in these circumstances.
4 Open issues
The impact of key management protocols embedded in SDP in accordance
with draft-ietf-mmusic-kmgmt-ext needs to be considered.
5 Security Considerations
Elwell Expires - August 2005 [Page 5]
Session retention during SIP INVITE/ReplacesFebruary 2005
The security considerations of [REPL] apply. In addition, in order to
prevent an unauthorized party replacing an existing dialog and
forcing continuation of an existing session, the proposal includes
requirements to ensure that the UAC of the INVITE/Replaces request is
the remote UA in the existing dialog.
6 Author's Addresses
John Elwell
Siemens Communications
Technology Drive
Beeston
Nottingham, UK, NG9 1LA
email: john.elwell@siemens.com
7 References
[AIB] J. Peterson, "Session Initiation Protocol (SIP) Authenticated
Identity Body (AIB) Format", RFC 3893.
[GRUU] J. Rosenberg, "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)",
draft-ietf-sip-gruu-02 (work in progress).
[ID] J. Peterson, C. Jennings, "Enhancements for Authenticated
Identity Management in Session Initiation Protocol (SIP)", draft-
ietf-sip-identity-03 (work in progress).
[OA] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the
Session Description Protocol (SDP)", RFC 3264.
[REPL] R. Mahy, B. Biggs, R. Dean, "The Session Initiation Protocol
'Replaces' Header ", RFC 3891.
[SDP] M. Handley, V. Jacobson, "SDP: Session Initiation Protocol",
RFC 2327.
[SIP] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation
protocol", RFC 3261.
[UPD] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311.
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
Elwell Expires - August 2005 [Page 6]
Session retention during SIP INVITE/ReplacesFebruary 2005
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
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 Expires - August 2005 [Page 7]