SIPPING
Internet Draft Y. Shen
Document: draft-shen-interaction-ind-04.txt Alcatel-Lucent
Expires: November 2008 May 2008
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.
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 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.
Table of Contents
Shen Expires November 2008 [Page 1]
Service Interaction Indicator May 2008
1. Introduction...................................................2
2. Terminology....................................................2
3. Mechanisms.....................................................3
4. Syntax.........................................................3
5. Forward Indicator..............................................4
6. Backward Indicator.............................................5
7. Proxy Behavior.................................................5
Security Considerations...........................................6
IANA Considerations...............................................6
Reference.........................................................6
Acknowledgments...................................................7
Author's Addresses................................................7
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)
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. Terminology
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].
Shen Expires - November 2008 [Page 2]
Service Interaction Indicator May 2008
3. 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.
4. Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC-2234 [2].
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
Shen Expires - November 2008 [Page 3]
Service Interaction Indicator May 2008
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.
5. 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
...
Shen Expires - November 2008 [Page 4]
Service Interaction Indicator May 2008
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.
6. 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.
7. 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
Shen Expires - November 2008 [Page 5]
Service Interaction Indicator May 2008
(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.
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.
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
Reference
1 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
Shen Expires - November 2008 [Page 6]
Service Interaction Indicator May 2008
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.
Acknowledgments
Author's Addresses
Yuzhong Shen
Alcatel-Lucent
Lorenzstrasse 10
70435, Stuttgart
Germany
Email: yuzhongshen@gmail.com
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.
Full Copyright Statement
Shen Expires - November 2008 [Page 7]
Service Interaction Indicator May 2008
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
Shen Expires - November 2008 [Page 8]