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

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.


Table of Contents

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. 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.

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 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 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             |
       |                           |                           |

					

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.

 
     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     |                           |
       |                           |                           |

					

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                   |
       |            |               |                           |

					

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                 |
       |     |                 |             |                    |
       |     |                 |             |                    |
       |     |                 |             |                    |
       |     |                 |             |                    |
       |     |                 |             |                    |
       |     |                 |             |                    |
       |     |                 |             |                    |

					

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 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

Changes from draft-holmberg-sipcore-proxy-feature-00

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 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.

Authors' Addresses

Christer Holmberg Ericsson Hirsalantie 11 Jorvas, 02420 Finland EMail: christer.holmberg@ericsson.com
Ivo Sedlacek Ericsson Scheelevägen 19C Lund, 22363 Sweden EMail: ivo.sedlacek@ericsson.com