SIPPING
Internet Draft Y. Shen
Document: draft-shen-interaction-ind-00.txt Alcatel
Expires: July 2006 January 2006
Private Extensions to the Session Initiation Protocol (SIP) for
Service Interaction Indicator
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
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 need to set some indication in SIP message to
indicate next application server, what are allowed and what are not
Shen Expires - July 2006 [Page 1]
Service Interaction Indicator January 2006
allowed. 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.
Conventions used in this document
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 [1].
Table of Contents
1. Introduction...................................................2
2. Mechanisms.....................................................3
3. Syntax.........................................................3
4. Forward Indicator..............................................4
5. Backward Indicator.............................................5
Security Considerations...........................................5
IANA Considerations...............................................6
Reference.........................................................6
Acknowledgments...................................................6
Author's Addresses................................................6
1. Introduction
In SIP-based networks (RFC3261 [3]), 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)
But 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.
Interaction of services is depending on behavior of services on a SIP
node like application server and proxy. This document describes a
Shen Expires - July 2006 [Page 2]
Service Interaction Indicator January 2006
mechanism for service interaction in SIP. It is extensible if certain
applications need more indicators.
In PSTN/PLMN world, a parameter "service interaction indicator" in
INAP is used for exchanging service information between SCP and LEXs.
This enables service inter working between supplement services in
LEXs and IN services in SCP. The specification can be found in INAP
CS2 (EN 301 140-1 V1.3.4 (1999-06) [4]).
2. Mechanisms
A private SIP header fields, "P-Interaction-Indicator", is defined in
this document 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 applicable
for application after the application that set the indicator, then it
has the direction indicator "forward". If an indicator is applicable
for application before the application that set the indicator, then
it has the direction indicator "backward". "P-Interaction-Indicator"
can be inserted in INVITE, ACK in "forward" case and can be inserted
in 18X and 20x responses in "backward" case.
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 RFC-2234 [2].
Shen Expires - July 2006 [Page 3]
Service Interaction Indicator January 2006
PIndicator =
"P-Interaction-Indicator" HCOLON indicatorEntry
*(COMMA Indicator-entry)
indicatorEntry = "<" as-uri (SEMI indicationDirection)
*( SEMI indicatorParam )">"
as-uri= name-addr
indicationDirection = "forward"/ "backward"
indicatorParam = indToken *(HCOLON application)
indToken = "allow" / "reject"
application = application-string *(COMMA application-string)
application-string = "conferenceRequest"/
"callCompletionRequest"/"callDiversion"/application-extension
application-extension = token
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.
"indicationDirection" specifies the direction of the indicator:
"forward" means it is applicable for applications on the terminating
side. "backward" means it is applicable for applications on the
originating side.
"inToken" specifies the attribute of a set of "application". "allow"
means certain "application" SHALL be enabled. "reject" means certain
"application" MUST NOT be allowed to execute.
"application" specifies name of applications, which MUST be
understood from end to end. There are three predefined name:
"conference" for treatment of conference.
"callDiversion" is for call diversion like call forwarding
"callCompletionRequest" is for a request to create a monitoring of
state of call completion
"application-extension" are for any additional application name.
4. Forward Indicator
A forward indicator is used to inform application server on
terminating side, which services MUST NOT be allowed or SHALL be
activated.
Originating application server MAY set a forward indicator to
indicate terminating application.
Invite: marc@anywhere.com
...
Shen Expires - July 2006 [Page 4]
Service Interaction Indicator January 2006
P-Interaction-Indicator:
<SIP:as1.xxx.com;forward;reject:"CallDirversion";allow:
"CallCompletionRequest">
The application server "as1.xxx.com" sets a forward indicator in "P-
Interaction-Indicator", which indicates that requests for call
completion SHALL be accepted and call diversion MUST NOT be allowed.
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 appends a backward indicator to
indicate originating application.
200 OK
P-Interaction-Indicator:
<SIP:as1.xxx.com;forward;reject:"CallDirversion";allow:
"CallCompletionRequest">, <SIP:as2.xxx.com;backward;reject:"
Conference">
The application server "as2.xxx.com" appends a backward indicator,
which indicates that conference treatment on the originating side
MUST NOT be allowed.
Note: Backward indicator MAY be set in 18x and 20x response and send
back to originating side.
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.
P-Interaction-Indicator can be inspected by any intermediaries
participating in the Trust Domain. 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
Shen Expires - July 2006 [Page 5]
Service Interaction Indicator January 2006
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.
IANA Considerations
This document defines one new SIP private header field "P-
Interaction-Indicator" which should be registered by the IANA in the
SIP header registry.
The following is the registration for the P-Interaction-Indicator
header field:
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
Reference
1 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
2 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail Consortium and
Demon Internet Ltd., November 1997
3 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.
4 ESTI, Intelligent Network Application Protocol (INAP) Capability
Set 2 (CS2) Part 1: Protocol specification (EN 301 140-1 V1.3.4
1999-06)
Acknowledgments
Author's Addresses
Yuzhong Shen
Alcatel
Lorenzstrasse 10
70435, Stuttgart, Germany
Email: yshen@alcatel.de
Shen Expires - July 2006 [Page 6]
Service Interaction Indicator January 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006).
Shen Expires - July 2006 [Page 7]