Private Extensions to the Session Initiation Protocol (SIP) for Service Interaction Indicator
draft-shen-interaction-ind-06

Abstract

In SIP-based networks, a SIP session MAY involve several application servers on the originating and terminating side. In a certain case, an application server needs to set some indications in SIP message to indicate service information (what are invoked, what can be allowed and what should blocked). This kind of information will be also required for composition of SIP applications. There is a need to provide indicators for service interaction between SIP application servers or other SIP endpoints.

This document describes a mechanism of service interaction indicator for the Session Initiation Protocol (SIP) that enhances service interaction between SIP application servers in a trusted network.

Requirements Language

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 RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on May 17, 2010.

Copyright Notice

Copyright (c) 2009 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 the Trust Legal Provisions and are provided without warranty as described in the BSD License.

Table of Contents

1.  Introduction
2.  Mechanisms
3.  Syntax
4.  Forward Indicator
5.  Backward Indicator
6.  Proxy Behavior
7.  IANA Considerations
8.  Security Considerations
9.  Acknowledgements
10.  References
    10.1.  Normative References
    10.2.  Informative References
§  Author's Address

1.  Introduction

In SIP-based networks (RFC3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261]), there are several mechanisms for feature interactions. They may be grouped in three categories:

- Identification interaction (who is calling, who will be called)

- History interaction (what happened in this request: it was forwarded. And reasons for these happens)

- Capability interaction (Indicating user agent capabilities)

There is also a need to provide interaction indicator for further actions of involving applications. For example, for a session between user A and B, there is an application server AS1 at originating side and an application server AS2 at the terminating side. The AS1 has launched an application for user A like alarm call (alerting users in a certain physical location for a emergence case). It makes no sense if this call will be forwarded. The "alarm call" application want to indicate that a call diversion on terminating side is not wished.

A sip application server can also have the role of Service Capability Interaction Manager (SCIM) as defined in 3GPP IMS. This application server can coordinate applications in different sip application servers. Additional service information will be required for keeping service context in the SCIM server.

Interaction of services is depending on behavior of services on a SIP node like application server and proxy. This document describes a mechanism for service interaction in SIP. It is extensible if certain applications need more indicators.

2.  Mechanisms

One private SIP header field "P-Interaction-Indicator" is defined in this document.

The "P-Interaction-Indicator" header is for transporting interaction indicator that indicates application behaviors in SIP nodes in the next steps. Next steps mean time after the setting of "P-Interaction-Indicator".

It has also an indication of direction. If an indicator is in INVITE and ACK, it is applicable for application after the application that sets the indicator. It has the forward direction. If an indicator in 18X and 20x responses, it is applicable for application before the application that sets the indicator. It has the backward direction.

Typical use cases for "P-Interaction-Indicator" are a configuration with an application server on originating side and an application server on terminating side for a call. The originating application can use the forward "P-Interaction-Indicator" to indicate the terminating application server what SHALL be allowed or not allowed. The terminating application can use the backward "P-Interaction-Indicator" to indicate the originating application server what are allowed or not allowed.

The "P-Interaction-Indicator" can also be used in case of multiple application servers on terminating or originating side. For example, one application server on the terminating can also set a forward indicator for other application server behind him.

The "P-Interaction-Indicator" can also be used for applications in other SIP UA and SIP Proxy.

3.  Syntax

The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC2234 (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.) [RFC2234].

PIndicator =

"P-Interaction-Indicator" HCOLON indicatorEntry

*(COMMA Indicator-entry)

indicatorEntry = "<" as-uri *( SEMI indicatorParam )">"

as-uri= name-addr

indicatorParam = indToken *(HCOLON application)

indToken = "allow" / "block" / "invoked"

application = application-string *(COMMA application-string)

application-string = token/application-extension

The P-Interaction-Indicator fully describes the interaction indicator. Its parameters are described below:

"as-uri" specifies the URI of a SIP end point (a application server or other) that sets the interaction indicator. It is an optional

"inToken" specifies the attribute of a set of "application". "allow" means certain "application" SHALL be enabled. "invoked" means certain "application" are already executed. "block" means certain "application" MUST be blocked to execute.

"application-string" specifies name of applications, which MUST be understood from end to end.

There are several predefined name for supplementary services:

ACRCB for Anonymous Communication Rejection and Communication Barring

CCBS for Call Completion on Busy Subscriber (monitoring busy subs)

CDIV for Communication Diversion Services

CFU for Communication Forwarding Unconditional

CFB for Communication Forwarding Busy

CFNR for Communication Forwarding No Reply

CFNL for Communication Forwarding on Not Logged-In

CD for Communication Deflection

CO for Call Offering CONF for Conference

CW for Call Waiting

ECT for Explicit Communication Transfer

HOLD for Communication Hold

OIP for Originating Identification Presentation

OIR for Originating Identification Restriction

TIP for Terminating Identity Presentation

Other application name can be added here.

4.  Forward Indicator

A forward indicator is used to inform application server on terminating side, which services MUST be blocked or SHALL be activated.

Originating application server MAY set a forward indicator to indicate terminating application.

Invite: marc@anywhere.com

...

P-Interaction-Indicator: <SIP:as1.xxx.com; block:"CFU,CFU"; allow: "CCBS"; invoked: "OIP">

The application server "as1.xxx.com" sets a forward indicator in "P-Interaction-Indicator", which indicates that requests for call completion SHALL be accepted, call forwarding CFU and CFB MUST be blocked, Originating Identification Presentation OIP is invoked.

Invite: marc@anywhere.com

...

P-Interaction-Indicator: <SIP:as1.xxx.com;invoked: " CONF ">

The application server "as1.xxx.com" sets a forward indicator in "P-Interaction-Indicator", which indicates that a conference service is already happen. This means this is an invite to join a conference.

5.  Backward Indicator

A backward indicator is used to inform application server on originating side, which services MUST NOT be allowed or SHALL be activated.

Terminating application server MAY sets a backward indicator to indicate originating application.

200 OK

P-Interaction-Indicator: <SIP:as2.xxx.com; block:"CONF">

The application server "as2.xxx.com" sets a backward indicator, which indicates that conference treatment on the originating side MUST be blocked.

Note: Backward indicator is in 18x and 20x responses.

6.  Proxy Behavior

A proxy in a Trust Domain can receive a message from a node that it trusts, or a node that it does not trust. When a proxy receives a message from a node it does not trust and it contains a P- Interaction-Indicator header field, the proxy MUST remove P-Interaction-Indicator header field. If the proxy receives a message (request or response) from a node that it trusts, it does not remove the P-Interaction-Indicator header field.

When a proxy forwards a message to another node, it must first determine if it trusts that node or not. If it does not trust the element, then the proxy MUST remove the P-Interaction-Indicator header field. If it trusts the node, the proxy does not remove the P- Interaction-Indicator header field.

7.  IANA Considerations

This document defines one new SIP private header field "P-Interaction-Indicator" that should be registered by the IANA in the SIP header registry.

The following are registration information: RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number of this specification.]

Header Field Name: P-Interaction-Indicator

Compact Form: none

8.  Security Considerations

The mechanism provided in this document is a partial consideration of the problem of service interaction in SIP. Some interactions in this document result in the transfer of confidential information.

Any intermediaries participating in the Trust Domain can inspect P-Interaction-Indicator. This information is secured by transitive trust, which is only as reliable as the weakest link in the chain of trust. It MUST be removed at border of the trusted domain.

When a trusted entity sends a message to any destination the P-Interaction-Indicator header field, the entity MUST take precautions to protect the identity information from eavesdropping and interception to protect the confidentiality and integrity of that identity information. The use of transport or network layer hop-by-hop security mechanisms, such as TLS or IPSec with appropriate cipher suites, can satisfy this requirement.

9.  Acknowledgements

10.  References

10.1. Normative References

10.2. Informative References

Author's Address