draft-ietf-sipcore-proxy-feature-reqs-00.txt   draft-ietf-sipcore-proxy-feature-reqs-01.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: December 22, 2011 June 20, 2011 Expires: March 12, 2012 September 9, 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-00.txt draft-ietf-sipcore-proxy-feature-reqs-01.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 December 22, 2011. This Internet-Draft will expire on March 12, 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 23 skipping to change at page 2, line 23
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.3. Use-case: IMS Inter-UE Transfer . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
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 other SIP entities indicate supported feature/ It can be useful for SIP proxies to indicate supported feature/
capabilities, that might trigger actions and enable functions in by capabilities, that might trigger actions and enable functions in
other SIP entities. other SIP entities.
This document defines requirements for a mechanism that would allow This document defines requirements for a mechanism that would allow
SIP proxies to convey information relating to the proxy's supported SIP proxies to convey information related to the proxy's supported
features/capabilities. features/capabilities.
1.1. Use-case: IMS Service Continuity, handover of session in alerting 1.1. Use-case: IMS Service Continuity, handover of session in alerting
state state
The 3rd Generation Partnership Project (3GPP) defines a IP Multimedia The 3rd Generation Partnership Project (3GPP) defines a IP Multimedia
Subsystem (IMS) Service Continuity mechanism [3GPP.23.237] for Subsystem (IMS) Service Continuity mechanism [3GPP.23.237] for
handover of Packet Switched (PS) sessions to Circuit Switched (CS) handover of Packet Switched (PS) sessions to Circuit Switched (CS)
calls. calls.
skipping to change at page 4, line 4 skipping to change at page 4, line 4
1.2. Use-case: IMS Enhanced Service Continuity 1.2. Use-case: IMS Enhanced Service Continuity
The 3rd Generation Partnership Project (3GPP) defines a IP Multimedia The 3rd Generation Partnership Project (3GPP) defines a IP Multimedia
Subsystem (IMS) Service Continuity mechanism [3GPP.23.237] for Subsystem (IMS) Service Continuity mechanism [3GPP.23.237] for
handover of Packet Switched (PS) sessions to Circuit Switched (CS) handover of Packet Switched (PS) sessions to Circuit Switched (CS)
calls. The handover can be performed by a Service Centralization and calls. The handover can be performed by a Service Centralization and
Continuity Application Server (SCC AS), or by a SCC AS together with Continuity Application Server (SCC AS), or by a SCC AS together with
an Access Transfer Control Function (ATCF), that acts as a SIP proxy. an Access Transfer Control Function (ATCF), that acts as a SIP proxy.
Delegating part of the session handover functionality to an ATCF Delegating part of the session handover functionality to an ATCF
provides advantages related to voice interruption during session provides advantages related to voice interruption during session
handover etc, since it is located in the same network as the user. handover etc, since the ATCF is located in the same network as the
user.
1.2.1. Use-case: IMS Enhanced Service Continuity, ATCF discovery 1.2.1. Use-case: IMS Enhanced Service Continuity, ATCF discovery
In order for a SCC AS to delegate part of the session handover In order for an SCC AS to delegate part of the session handover
functionality to an ATCF, when it receives a SIP REGISTER request, it functionality to an ATCF, when the SCC AS is informed by the
needs to be informed whether there is a proxy that provides ATCF registrar about an accepted REGISTER transaction, the SCC AS needs to
functionality in the registration path. determine whether a proxy supporting the ATCF functionality is in the
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, ATCF needs to know which sessions are subject handover functionality, when a session is set up, the ATCF needs to
to handover as decided by SCC AS. determine whether a SIP proxy supporting the SCC AS functionality is
in the signalling path of the session.
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.
Triggered by requests from the controller UE, the SCC AS serving the Triggered by requests from the controller UE, the SCC AS serving the
controller UE transfers media of the session to other UEs, called controller UE transfers media of the session to other UEs, called
controlee UEs, by sending INVITE request offering the media to be controlee UEs, by sending INVITE request offering the media to be
transferred. transferred.
When an INVITE request is routed to the UE, the SCC AS serving the UE When an INVITE request is routed to the UE, the SCC AS serving the UE
needs to determine whether another SCC AS (i.e. SCC AS of the needs to determine whether a SIP proxy supporting the inter-UE
controller UE) is already in the signalling path. transfer enhancements functionality (i.e. SCC AS of the controller
UE) is already in the signalling path.
If so, the SCC AS proxies the signalling without further handling as If so, the SCC AS proxies the signalling without further handling as
there is already an existing local hub for the session. there is already an existing local hub for the session.
If not, the SCC AS acts as local hub for the session. If not, the SCC AS acts as local hub for the session.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 5, line 23 skipping to change at page 5, line 26
request, support of a particular feature/capability. request, support of a particular feature/capability.
REQ-3: It MUST be possible for a SIP proxy to indicate that the REQ-3: It MUST be possible for a SIP proxy to indicate that the
indicated support of a feature/capability only applies to other SIP indicated support of a feature/capability only applies to other SIP
entities in the direction towards one of the SIP endpoints in the entities in the direction towards one of the SIP endpoints in the
signalling path. signalling path.
REQ-4: A SIP proxy MUST NOT, when indicating support of a feature/ REQ-4: A SIP proxy MUST NOT, when indicating support of a feature/
capability, make any assumptions that SIP entities in the signalling capability, make any assumptions that SIP entities in the signalling
path that receive the indicator will support, or understand the path that receive the indicator will support, or understand the
meaning of, the feature/capability. meaning of, the feature/capability, or even support the proxy
feature/capability indication mechanism as a whole.
REQ-5: It MUST be possible to indicate whether indicated support of a REQ-5: A SIP proxy MUST be able to indicate support of a feature/
capability to other SIP entities in the signaling path, even if some
SIP entities in the signaling path (possibly including the UAC and/or
UAS) do not support, or understand the meaning of, the feature/
capability, or even support the proxy feature/capability indication
mechanism as a whole.
REQ-6: It MUST be possible to indicate whether indicated support of a
feature/capability applies to specific registration, to a specific feature/capability applies to specific registration, to a specific
dialog, to all dialogs created within a session, or to dialogs dialog, or to all dialogs created as part of INVITE transaction.
associated with other sessions.
NOTE: This requirement might be fully implemented as part of the NOTE: This requirement might be fully implemented as part of the
protocol mechanism, or parts might be left to be specified in a protocol mechanism, or parts might be left to be specified in a
feature/capability specification, or it might be left to be specified feature/capability specification, or it might be left to be specified
in a feature/capability specification completely. in a feature/capability specification completely.
REQ-6: It MUST be possible to assign additional parameter (either as REQ-7: It MUST be possible to assign additional parameters (either as
a single value, or a list of values) to a feature/capability a single value, or a list of values) to a feature/capability
indicator, in order to provide additional information about the indicator, in order to provide additional information about the
feature/capability. feature/capability.
REQ-7: If a SIP entity receives a feature support indication that it REQ-8: If a SIP entity receives a feature support indication that it
does not understand, it MUST act as if it hadn't received the does not understand, it MUST act as if it hadn't received the
indication. indication.
REQ-8: Other SIP entities MUST be able to make routing decisions REQ-9: If a SIP entity that does not support the proxy feature/
capability indication mechanism receives a feature support
indication, it MUST act as if it hadn't received the indication.
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-9: 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-10: A procedure for registering feature/capability indication REQ-12: 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. guidance on the mailing list. Thanks to Andrew Allen and Dale Worley
for providing text on additional use-cases. Thanks to Cullen
Jennings for providing text on additional requirements. Thanks to
Dale Worley for providing comments and text improvement suggestions.
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 Changes from draft-ietf-sipcore-proxy-feature-reqs-xx
o Add text o Add text
Changes from draft-ietf-sipcore-proxy-feature-reqs-00
o New REQ-5 added (IETF#81).
o New REQ-9 added (Dale Worley).
o Text added to REQ-4 and REQ-5, indicating that the requirement
applies also in cases where an entity does not support the
mechanism as a whole (Dale Worley).
o Usage of "session establishment transactions" terminology in
REQ-6, in order to avoid misunderstanding of "session" (Dale
Worley).
o Editorial correction in REQ-7: "additional parameter"->"additional
parameters"
o Editorial clarifications to use-cases.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References 8.2. Informative References
 End of changes. 21 change blocks. 
29 lines changed or deleted 58 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/