| SIPCORE Working Group | C.H. Holmberg |
| Internet-Draft | I.S. Sedlacek |
| Intended status: Standards Track | Ericsson |
| Expires: December 11, 2011 | June 09, 2011 |
Indication of features supported by proxy
draft-holmberg-sipcore-proxy-feature-02.txt
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.
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 (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.
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.
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.
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. 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.
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.
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.
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.
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].
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].
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.
This specification does not specify any new User Agent 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 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.
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.
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.
Based on the presence of g.3gpp.srvcc-alerting feature tag in a 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 |
| | |
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.
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 | |
| | |
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 |
| | | |
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 |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
TBD
Feature tags can provide sensitive information about a SIP entity. RFC 3840 cautions against providing sensitive information to another party. Once this information is given out, any use may be made of it.
Thanks to Paul Kyzivat for his comments and guidance on the mailing list.
[RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-holmberg-sipcore-proxy-feature-01
Changes from draft-holmberg-sipcore-proxy-feature-00
| [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. |
| [3GPP.23.237] | 3GPP, "IP Multimedia Subsystem (IMS) Service Continuity; Stage 2", 3GPP TS 23.237 10.7.0, September 2011. |
| [3GPP.24.837] | 3GPP, "IP Multimedia (IM) Core Network (CN) subsystem inter-UE transfer enhancements; Stage 3", 3GPP TR 24.837 10.0.0, April 2011. |