draft-ietf-sipcore-proxy-feature-reqs-01.txt   draft-ietf-sipcore-proxy-feature-reqs-02.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft I. Sedlacek Internet-Draft I. Sedlacek
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: March 12, 2012 September 9, 2011 Expires: April 23, 2012 October 21, 2011
Requirements for indication of features supported by a SIP proxy Requirements for indication of features supported by a SIP proxy
draft-ietf-sipcore-proxy-feature-reqs-01.txt draft-ietf-sipcore-proxy-feature-reqs-02.txt
Abstract Abstract
The Session Initiation Protocol (SIP) "Caller Preferences" extension The Session Initiation Protocol (SIP) "Caller Preferences" extension
defined in RFC 3840 provides a mechanism that allows a SIP message to defined in RFC 3840 provides a mechanism that allows a SIP message to
convey information relating to the originator's supported features/ convey information relating to the originator's supported features/
capabilities. This document defines requirements for a mechanism capabilities. This document defines requirements for a mechanism
that would allow SIP proxies to convey information relating to the that would allow SIP proxies to convey information relating to the
proxy's supported features/capabilities. proxy's supported features/capabilities.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on March 12, 2012. This Internet-Draft will expire on April 23, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Use-case: IMS Service Continuity, handover of session 1.1. Use-case: IMS Service Continuity, handover of session
in alerting state . . . . . . . . . . . . . . . . . . . . . 3 in alerting state . . . . . . . . . . . . . . . . . . . . . 3
1.2. Use-case: IMS Enhanced Service Continuity . . . . . . . . . 3 1.2. Use-case: IMS Enhanced Service Continuity . . . . . . . . . 3
1.2.1. Use-case: IMS Enhanced Service Continuity, ATCF 1.2.1. Use-case: IMS Enhanced Service Continuity, ATCF
discovery . . . . . . . . . . . . . . . . . . . . . . . 4 discovery . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2. Use-case: IMS Enhanced Service Continuity, 1.2.2. Use-case: IMS Enhanced Service Continuity,
identifying sessions subject to handover . . . . . . . 4 identifying sessions subject to handover . . . . . . . 4
1.3. Use-case: IMS Inter-UE Transfer . . . . . . . . . . . . . . 4 1.2.3. Use-case: IMS Enhanced Service Continuity,
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 indicating handover subfeature support . . . . . . . . 4
1.3. Use-case: IMS Inter-UE Transfer . . . . . . . . . . . . . . 5
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
The Session Initiation Protocol (SIP) "Caller Preferences" extension The Session Initiation Protocol (SIP) "Caller Preferences" extension
defined in RFC 3840 [RFC3840] provides a mechanism that allows a SIP defined in RFC 3840 [RFC3840] provides a mechanism that allows a SIP
message to convey information relating to the originator's supported message to convey information relating to the originator's supported
features/capabilities. features/capabilities.
It can be useful for SIP proxies to indicate supported feature/ It can be useful for SIP proxies to indicate supported feature/
capabilities, that might trigger actions and enable functions in capabilities, that might trigger actions and enable functions in
skipping to change at page 4, line 23 skipping to change at page 4, line 23
registration path. registration path.
1.2.2. Use-case: IMS Enhanced Service Continuity, identifying sessions 1.2.2. Use-case: IMS Enhanced Service Continuity, identifying sessions
subject to handover subject to handover
In order for ATCF to perform the delegated part of the session In order for ATCF to perform the delegated part of the session
handover functionality, when a session is set up, the ATCF needs to handover functionality, when a session is set up, the ATCF needs to
determine whether a SIP proxy supporting the SCC AS functionality is determine whether a SIP proxy supporting the SCC AS functionality is
in the signalling path of the session. in the signalling path of the session.
1.2.3. Use-case: IMS Enhanced Service Continuity, indicating handover
subfeature support
As the session handover functionality has been specified over several
3GPP releases, some subfeatures of the handover functionality are
optional. Examples are:
- The handover of sessions with audio on hold (called the MSC server
assisted mid-call feature); and
- The handover of sessions where a 180 Ringing response to the
initial SIP INVITE request has already been sent or received but a
final response has not been sent or received yet (called the SRVCC
for calls in alerting phase).
The SCC AS needs to be aware of support of those subfeatures in ATCF,
in order for the UE and the SCC AS to execute the correct handling
when the handover occurs.
When ATCF receives a SIP REGISTER request, the ATCF indicates the
support of those subfeatures along the indication of ATCF
functionality.
When SCC AS is informed about the new/updated binding where a proxy
indicated support of ATCF functionality along with support of those
subfeatures, the SCC AS discovers the support of those subfeatures in
the ATCF.
1.3. Use-case: IMS Inter-UE Transfer 1.3. Use-case: IMS Inter-UE Transfer
The 3rd Generation Partnership Project (3GPP) defines inter-UE The 3rd Generation Partnership Project (3GPP) defines inter-UE
transfer enhancements [3GPP.24.837] which enhance delivery of media transfer enhancements [3GPP.24.837] which enhance delivery of media
of a session to several User Equipments (UE). of a session to several User Equipments (UE).
The Service Centralization and Continuity Application Server (SCC AS) The Service Centralization and Continuity Application Server (SCC AS)
serving one of the UEs acts as local hub for the session. The UE serving one of the UEs acts as local hub for the session. The UE
controls the media of the session and is called controller UE. controls the media of the session and is called controller UE.
skipping to change at page 6, line 19 skipping to change at page 6, line 48
indication, it MUST act as if it hadn't received the indication. indication, it MUST act as if it hadn't received the indication.
REQ-10: Other SIP entities MUST be able to make routing decisions REQ-10: Other SIP entities MUST be able to make routing decisions
based on received feature/capability support indications. based on received feature/capability support indications.
REQ-11: A feature/capability support indicator MUST only be used to REQ-11: A feature/capability support indicator MUST only be used to
indicate support of a feature/capability, and MUST NOT be used to indicate support of a feature/capability, and MUST NOT be used to
indicate whether procedures associated with the feature/capability indicate whether procedures associated with the feature/capability
have been applied or not. have been applied or not.
REQ-12: A procedure for registering feature/capability indication REQ-12: It MUST be possible to determine which features/capabilities
are supported by the same proxy
REQ-13: A procedure for registering feature/capability indication
values with IANA MUST be defined. values with IANA MUST be defined.
4. Security Considerations 4. Security Considerations
Feature/capability support indications can provide sensitive Feature/capability support indications can provide sensitive
information about a SIP entity. RFC 3840 cautions against providing information about a SIP entity. RFC 3840 cautions against providing
sensitive information to another party. Once this information is sensitive information to another party. Once this information is
given out, any use may be made of it. given out, any use may be made of it.
5. IANA Considerations 5. IANA Considerations
None identified. None identified.
6. Acknowledgements 6. Acknowledgements
Thanks to Paul Kyzivat and Robert Sparks for their comments and Thanks to Paul Kyzivat and Robert Sparks for their comments and
guidance on the mailing list. Thanks to Andrew Allen and Dale Worley guidance on the mailing list. Thanks to Andrew Allen and Dale Worley
for providing text on additional use-cases. Thanks to Cullen for providing text on additional use-cases. Thanks to Cullen
Jennings for providing text on additional requirements. Thanks to Jennings for providing text on additional requirements. Thanks to
Dale Worley for providing comments and text improvement suggestions. Dale Worley for providing comments and text improvement suggestions.
Thanks to Hadriel Kaplan for telling us how SBCs mess up the
mechanisms we try to specify.
Thanks to Robert Sparks, Adam Roach and Paul Kyzivat for giving Thanks to Robert Sparks, Adam Roach and Paul Kyzivat for giving
working procedure guidance. working procedure guidance.
7. Change Log 7. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-sipcore-proxy-feature-reqs-xx
o Add text Changes from draft-ietf-sipcore-proxy-feature-reqs-01
o New REQ-12 added (old REQ-12 becomes REQ-13).
o New use-case added (section 1.2.3).
Changes from draft-ietf-sipcore-proxy-feature-reqs-00 Changes from draft-ietf-sipcore-proxy-feature-reqs-00
o New REQ-5 added (IETF#81). o New REQ-5 added (IETF#81).
o New REQ-9 added (Dale Worley). o New REQ-9 added (Dale Worley).
o Text added to REQ-4 and REQ-5, indicating that the requirement o Text added to REQ-4 and REQ-5, indicating that the requirement
applies also in cases where an entity does not support the applies also in cases where an entity does not support the
mechanism as a whole (Dale Worley). mechanism as a whole (Dale Worley).
o Usage of "session establishment transactions" terminology in o Usage of "session establishment transactions" terminology in
REQ-6, in order to avoid misunderstanding of "session" (Dale REQ-6, in order to avoid misunderstanding of "session" (Dale
Worley). Worley).
o Editorial correction in REQ-7: "additional parameter"->"additional o Editorial correction in REQ-7: "additional parameter"->"additional
skipping to change at page 7, line 34 skipping to change at page 8, line 20
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References 8.2. Informative References
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004. Initiation Protocol (SIP)", RFC 3840, August 2004.
[3GPP.23.237] [3GPP.23.237]
3GPP, "IP Multimedia Subsystem (IMS) Service Continuity; 3GPP, "IP Multimedia Subsystem (IMS) Service Continuity;
Stage 2", 3GPP TS 23.237 10.6.0, June 2011. Stage 2", 3GPP TS 23.237 10.7.0, September 2011.
[3GPP.24.837] [3GPP.24.837]
3GPP, "IP Multimedia (IM) Core Network (CN) subsystem 3GPP, "IP Multimedia (IM) Core Network (CN) subsystem
inter-UE transfer enhancements; Stage 3", 3GPP TR 24.837 inter-UE transfer enhancements; Stage 3", 3GPP TR 24.837
10.0.0, April 2011. 10.0.0, April 2011.
Authors' Addresses Authors' Addresses
Christer Holmberg Christer Holmberg
Ericsson Ericsson
 End of changes. 10 change blocks. 
17 lines changed or deleted 54 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/