SIPCORE Working Group C. Holmberg
Internet-Draft I. Sedlacek
Intended status: Standards Track Ericsson
Expires: December 11, 2011 June 9, 2011
Indication of features supported by proxy
draft-holmberg-sipcore-proxy-feature-02.txt
Abstract
The Session Initiation Protocol (SIP) "Caller Preferences" extension
defined in RFC 3840 provides a mechanism that allows a SIP message to
convey information relating to the originator's capabilities. This
document makes it possible for SIP proxies to convey similar
information, by extending the rr-param rule defined in RFC 3261, so
that the header field parameter can be used to convey feature tags
that indicate features supported by the proxy.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 11, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Holmberg & Sedlacek Expires December 11, 2011 [Page 1]
Internet-Draft proxy feature June 2011
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Use-case: IMS Service Continuity, handover of session
in alerting state . . . . . . . . . . . . . . . . . . . . 3
1.2. Use-case: IMS Enhanced Service Continuity . . . . . . . . 3
1.2.1. Use-case: IMS Enhanced Service Continuity, ATCF
discovery . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2. Use-case: IMS Enhanced Service Continuity,
identifying sessions subject to handover . . . . . . . 4
1.3. Use-case: IMS Inter-UE Transfer . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. User Agent behavior . . . . . . . . . . . . . . . . . . . . . 5
6. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Feature tag semantics . . . . . . . . . . . . . . . . . . . . 6
8. Direction . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Example: IMS Service Continuity, handover session in
alerting state . . . . . . . . . . . . . . . . . . . . . . 6
9.2. Example: IMS Enhanced Service Continuity, ATCF
discovery . . . . . . . . . . . . . . . . . . . . . . . . 7
9.3. Example: IMS Enhanced Service Continuity, identifying
sessions subject to handover . . . . . . . . . . . . . . . 8
9.4. Example: IMS Inter-UE Transfer . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 9
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
14.1. Normative References . . . . . . . . . . . . . . . . . . . 10
14.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Holmberg & Sedlacek Expires December 11, 2011 [Page 2]
Internet-Draft proxy feature June 2011
1. Introduction
The SIP "Caller Preferences" extension defined in RFC 3840 [RFC3840]
provides a mechanism that allows a SIP message to convey information,
using feature tags, relating to the originator's capabilities.
Feature information can be useful for other SIP entities, that might
trigger actions and enable functions based on features supported by
other SIP entities.
This document extends the rr-param rule defined in RFC 3261
[RFC3261], so that it can be used to convey feature tags indicating
support of features in SIP proxies. The rr-param rule is used in the
SIP Path, Route, Record-Route and Service-Route header fields.
1.1. Use-case: IMS Service Continuity, handover of session in alerting
state
The 3rd Generation Partnership Project (3GPP) defines a IP Multimedia
Subsystem (IMS) Service Continuity mechanism [3GPP.23.237] for
handover of Packet Switched (PS) sessions to Circuit Switched (CS)
calls.
The handover is controlled by a Service Centralization and Continuity
Application Server (SCC AS). When a session is established the User
Equipment (UE) needs to determine whether SCC AS in signalling path
of the session supports handover of session in alerting state (i.e.
180 Ringing response has already been sent or received but the dialog
is not confirmed dialog yet) or not.
When handover occurs and a session in alerting state exists and both
UE and SCC AS indicated support of the handover of session in
alerting state, then the UE and SCC AS perform handover for the
session in alerting state.
NOTE: The UE indicates the support of the handover of session in
alerting state by the feature tag included in Contact header field.
Section 9.1 shows an example flow for this use-case.
1.2. Use-case: IMS Enhanced Service Continuity
The 3rd Generation Partnership Project (3GPP) defines a IP Multimedia
Subsystem (IMS) Service Continuity mechanism [3GPP.23.237] for
handover of Packet Switched (PS) sessions to Circuit Switched (CS)
calls. The handover can be performed by a Service Centralization and
Continuity Application Server (SCC AS), or by a SCC AS together with
an Access Transfer Control Function (ATCF), that acts as a SIP proxy.
Holmberg & Sedlacek Expires December 11, 2011 [Page 3]
Internet-Draft proxy feature June 2011
Delegating part of the session handover functionality to an ATCF
provides advantages related to voice interruption during session
handover etc, since it is located in the same network as the user.
1.2.1. Use-case: IMS Enhanced Service Continuity, ATCF discovery
In order for a SCC AS to delegate part of the session handover
functionality to an ATCF, when it receives a SIP REGISTER request, it
needs to be informed whether there is a proxy that provides ATCF
functionality in the registration path.
Section 9.2 shows an example flow for this use-case.
1.2.2. Use-case: IMS Enhanced Service Continuity, identifying sessions
subject to handover
In order for ATCF to perform the delegated part of the session
handover functionality, ATCF needs to know which sessions are subject
to handover as decided by SCC AS.
Section 9.3 shows an example flow for this use-case.
1.3. Use-case: IMS Inter-UE Transfer
The 3rd Generation Partnership Project (3GPP) defines inter-UE
transfer enhancements [3GPP.24.837] which enhance delivery of media
of a session to several User Equipments (UE).
The Service Centralization and Continuity Application Server (SCC AS)
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.
Triggered by requests from the controller UE, the SCC AS serving the
controller UE transfers media of the session to other UEs, called
controlee UEs, by sending INVITE request offering the media to be
transferred.
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
controller UE) is already in the signalling path.
If so, the SCC AS proxies the signalling without further handling as
there is already an existing local hub for the session.
If not, the SCC AS acts as local hub for the session.
Section 9.4 shows an example flow for this use-case.
Holmberg & Sedlacek Expires December 11, 2011 [Page 4]
Internet-Draft proxy feature June 2011
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
3. Definitions
The rr-param rule defined in RFC 3261 [RFC3261]:
rr-param = generic-param
is extended to:
rr-param = generic-param / feature-param
where feature-param is defined in Section 9 of RFC 3840 [RFC3840].
4. Requirements
1. It SHALL be possible for a SIP intermediary to indicate, in a SIP
routing header field (e.g Record-Route, Service-Route, Path), support
(for a session or registration) for a particular feature/capability.
2. It SHALL be possible to indicate whether indicated support of a
feature/capability is only applicable in a certain direction of the
signalling path associated with the SIP routing header field, in
which the feature/capability support is indicated.
5. User Agent behavior
This specification does not specify any new User Agent behavior.
6. Proxy behavior
When a proxy inserts a Path header field (during registration), a
Service-Route header field (during registration) or a Record-Route
header field (during a dialog establishment), it MAY insert a feature
tag in the header field.
If a feature tag is inserted in a Path or Service-Route header field
during registration, the resource identified by the URI in the header
field MUST provide support for the associated feature for all dialogs
Holmberg & Sedlacek Expires December 11, 2011 [Page 5]
Internet-Draft proxy feature June 2011
associated with the registration, until the registration is
terminated or re-freshed.
If a feature tag is inserted in a Record-Route header field during a
dialog establishment, the resource identified by the URI in the
header field MUST provide support for the associated feature until
the dialog is terminated.
7. Feature tag semantics
The feature tag in a header field constructed using rr-param rule
indicates support of the feature in the resource identified by the
URI in the header field.
In order to insert a feature tag in a SIP header field constructed by
using rr-param rule, the feature specification MUST specify the
semantics of the feature tag when inserted in that specific header
field. Unless the feature specification defines such semantics, a
the feature tag MUST NOT be included in that specific header field.
NOTE: If a route set is built using Path, Record-Route or Service-
Route header fields, any inserted feature tag will be copied into the
associated Route header fields, together with other header field
parameters. This specification does not define any specific meaning
of the feature tags present in Route header fields in such cases.
8. Direction
When a proxy inserts a feature tag in order to indicate support of a
capability, the indicated capability might be indicated both towards
downstream and upstream SIP entities.
In order to indicate a capability only towards SIP entities in one
direction, either the feature tag semantics need to be defined in a
way so that SIP entities know whether the indicated capability
applies to them or not, or alternatively, the SIP entity that inserts
the feature tag needs to ensure that the feature tag is only sent
towards the direction for which the capability applies.
9. Examples
9.1. Example: IMS Service Continuity, handover session in alerting
state
Based on the presence of g.3gpp.srvcc-alerting feature tag in a
Holmberg & Sedlacek Expires December 11, 2011 [Page 6]
Internet-Draft proxy feature June 2011
Record-Route header field Alice determines that SCC AS serving Alice
in signalling path of the session supports the handover of session in
alerting state and when hand over occurs and session in alerting
state exists, this specific session can be handed over.
NOTE: As P1 only wants to indicate the capability towards Alice, it
only inserts the feature tag in the Record-Route header field of the
response sent towards Alice.
NOTE: The Contact header field of the 200 OK response to the INVITE
request contains the GRUU of Bob, so it would be inappropriate to
indicate the SCC AS support of handover feature in the Contact header
field.
Alice P1 (SCC AS Bob
of Alice)
| | |
|--- INVITE---------------->| |
| | |
| |--- INVITE---------------->|
| | Record-Route: P1 |
| | |
| | |
| |<-- 200 OK ----------------|
| | Record-Route: P1 |
| | |
|<-- 200 OK ----------------| |
| Record-Route: P1;g.3gpp.srvcc-alerting |
| | |
Figure 1: Example call flow
9.2. Example: IMS Enhanced Service Continuity, ATCF discovery
Based on the presence of g.3gpp.atcf feature tag in a Path header
field the REGISTRAR (and SCC AS invoked by REGISTRAR) determines that
ATCF is in the path for terminating requests sent to Alice.
NOTE: The Contact header field of the REGISTER request contains a URI
at which Alice can be directly reached, so it would be inappropriate
to indicate the ATCF support of handover feature in the Contact
header field.
Holmberg & Sedlacek Expires December 11, 2011 [Page 7]
Internet-Draft proxy feature June 2011
Alice P1 (ATCF) REGISTRAR
| | |
|--- REGISTER-------------->| |
| | |
| |--- REGISTER-------------->|
| | Path: P1;+g.3gpp.atcf |
| | |
| | |
| |<-- 200 OK ----------------|
| | Path: P1;+g.3gpp.atcf |
| | Service-Route: REG |
|<-- 200 OK ----------------| |
| Path: P1;+g.3gpp.atcf | |
| Service-Route: REG | |
| | |
Figure 2: Example call flow
9.3. Example: IMS Enhanced Service Continuity, identifying sessions
subject to handover
Based on the presence of g.3gpp.srvcc feature tag in a Record-Route
header field the ATCF determines that the session is subject to the
handover.
Alice P2 (ATCF) P1 (SCC AS Bob
of Alice)
| | | |
|--- INVITE->| | |
| |--- INVITE---->| |
| | Record-Route: P2 |
| | |--- INVITE---------------->|
| | | Record-Route: P1, P2 |
| | | |
| | | |
| | |<-- 200 OK ----------------|
| | | Record-Route: P1, P2 |
| | | |
| |<--- 200 OK----| |
| | Record-Route: P1;g.3gpp.srvcc, P2 |
|<-- 200 OK--| | |
| Record-Route: P1;g.3gpp.srvcc, P2 |
| | | |
Figure 3: Example call flow
Holmberg & Sedlacek Expires December 11, 2011 [Page 8]
Internet-Draft proxy feature June 2011
9.4. Example: IMS Inter-UE Transfer
Based on the presence of g.3gpp.iut-focus feature tag in a Record-
Route header field the SCC AS serving Cecil determines that the
session already has a local hub.
NOTE: The Contact header field of the INVITE request contains the
GRUU of Bob, so it would be inappropriate to indicate the SCC AS
support of the handover feature in the Contact header field.
Alice Cecil P1 (SCC AS P2 (SCC AS Bob
of Alice) of Cecil)
| | | | |
| Session of audio and video between Alice and Bob where |
| SCC AS of Alice is in signalling path |
|<======================+=================================>|
| | | | |
|--move audio to Cecil->| | |
| | | | |
| | |-INVITE----> | |
| | | Record-Route: P1;g.3gpp.iut-focus
| | | | |
| | | | |
| | | | |
| |<-INVITE-----------------------| |
| | Record-Route: P2 | |
| | Record-Route: P1;g.3gpp.iut-focus |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
Figure 4: Example call flow
10. IANA Considerations
TBD
11. Security Considerations
Feature tags can provide sensitive information about a SIP entity.
RFC 3840 cautions against providing sensitive information to another
Holmberg & Sedlacek Expires December 11, 2011 [Page 9]
Internet-Draft proxy feature June 2011
party. Once this information is given out, any use may be made of
it.
12. Acknowledgements
Thanks to Paul Kyzivat for his comments and guidance on the mailing
list.
13. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-holmberg-sipcore-proxy-feature-01
o Requirement section added
o Use-cases and examples updated based on work in 3GPP
Changes from draft-holmberg-sipcore-proxy-feature-00
o Additional use-cases added
o Direction section added
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
14.2. Informative References
[3GPP.23.237]
3GPP, "IP Multimedia Subsystem (IMS) Service Continuity;
Stage 2", 3GPP TS 23.237 8.7.0, March 2010.
[3GPP.24.837]
3GPP, "IP Multimedia (IM) Core Network (CN) subsystem
inter-UE transfer enhancements; Stage 3", 3GPP TR 24.837
Holmberg & Sedlacek Expires December 11, 2011 [Page 10]
Internet-Draft proxy feature June 2011
10.0.0, April 2011.
Authors' Addresses
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com
Ivo Sedlacek
Ericsson
Scheelevaegen 19C
Lund 22363
Sweden
Email: ivo.sedlacek@ericsson.com
Holmberg & Sedlacek Expires December 11, 2011 [Page 11]