Internet-Draft Input reqs. to SIP for ETSI NGN June 2005
Sipping Working Group Roland Jesske
Internet Draft Deutsche Telekom
Expires: December 13, 2005 Denis Alexeitsev
Deutsche Telekom
Miguel Garcia-Martin
Nokia
June 14, 2005
Input Requirements for the Session Initiation Protocol (SIP) in
support for the European Telecommunications Standards Institute
(ETSI) Next Generation Network (NGN) simulation services
draft-jesske-sipping-tispan-requirements-01
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/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 November 24, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Jesske, et al. Expires - December 2005 [Page 1]
Internet-Draft Input reqs. to SIP for ETSI NGN June 2005
This document describes a set of requirements to the Session
Initiation Protocol (SIP) [1] in support for simulation services
provided in the context of ETSI Next Generation Networks (NGN).
These requirements should help to find SIP solutions to provide the
services described within this document.
Table of Contents
1. Overview
2. Requirements for supporting simulation services within SIP
2.1 Simulation Services supported by TISPAN in Release1
2.2 Requirements to support the TISPAN Simulation Services.
3. Requirements with existing solutions
4. Security Considerations
5. IANA Considerations
1. Overview
The European Telecommunications Standards Institute (ETSI)
Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN) is defining the release 1 of the TISPAN
Next Generation Network (NGN). Generally NGN is largely based on the
3rd Generation mobile Partnership Project (3GPP) IP Multimedia
Subsystem (IMS) Release 7.
The TISPAN NGN project has selected SIP profiled by 3GPP TS 24.229
[26] for the IMS as the protocol used to establish and tear down
multimedia sessions in the context of NGN. The goal for TISPAN is
that only one IMS core specification is defined for both wire-line
and wire-less multimedia applications.
While defining multimedia applications it is also needed to support
existing Integrated Services Digital Network and Public Switched
Telephone Network (ISDN/PSTN) supplementary services based on IMS. We
refer to supplementary services provided with SIP in the context of
NGN as 'simulation services'. They are referred to as simulation
services because they need to be adapted to be provided with SIP, so
small variations are expected when compared with the equivalent
ISDN/PSTN supplementary service. The 3GPP TS 24.229 [26] is used to
simulate the regarding services but to fulfill the requirements
defined within TISPAN NGN Release 1 some further SIP support is
needed.
This document defines some input requirements to support the
implementation of simulation services. It is generally understood
that not every requirement listed in this memo will require a SIP
Jesske, et al. Expires - December 2005 [Page 2]
Internet-Draft Input reqs. to SIP for ETSI NGN June 2005
extension. A companion Internet Draft analyses possible
implementations of these requirements and explores different
extensions when those are needed.
All mentioned 3GPP and ETSI Standards are free available under
http://pda.etsi.org/pda/queryform.asp and
http://www.3gpp.org/ftp/Specs/html-info/
The resulting work of this collaboration will eventually be
contributed to International Telecommunication Union -
Telecommunication Standardization Sector (ITU-T) as part of their NGN
work to have an alignment between the work of the standardization
organizations.
2. Requirements for supporting simulation services within SIP
2.1 Simulation Services supported by TISPAN in Release 1
The following simulation services are supported by ETSI NGN Release
1:
-Communications DIVersion (CDIV). This simulation service allows the
diversion of communications and the regarding service interworking
with the PSTN/ISDN. The service comprises the equivalent PSTN/ISDN
supplementary service for Call Forwarding Unconditional (CFU), Call
Forwarding Busy (CFB), Call Forwarding on No Reply (CFNR), and Call
Deflection (CD). The CFU supplementary service is described in ETSI
EN 300 200 [7]. The CFB supplementary service is described in ETSI EN
300 199 [8]. The CFNR supplementary service is described in ETSI EN
300 201 [9]. The CD supplementary service is described in ETSI EN 300
202 [10].
- Incoming Communication Barring (ICB). This simulation service
allows a user to block incoming communications based on the identity
of the caller. The Call Barring supplementary service is described in
ETSI ETS 300 520 [22].
- CONFerence (CONF). This simulation service provides the possibility
to hold centralized conferences with 3 or more users. The CONF
supplementary service is described in ETSI ETS 300 183 [14].
- Message Waiting Indication (MWI). This simulation service provides
the user with information about the status of a
voice/video/multimedia mailbox. The MWI supplementary service is
described in ETSI EN 300 650 [19].
- Originating Indication Presentation (OIP)/Originating Indication
Restriction (OIR). These simulation services support the presentation
or restriction of the caller's identity to the callee. They are the
Jesske, et al. Expires - December 2005 [Page 3]
Internet-Draft Input reqs. to SIP for ETSI NGN June 2005
simulation of the ISDN/PSTN Calling Line Identification
Presentation/Restriction (CLIP/CLIR) supplementary services. The CLIP
supplementary service is described in ETSI EN 300 089 [5]. The CLIR
supplementary service is described in ETSI EN 300 090 [6].
- Terminating Indication Presentation (TIP)/Terminating Indication
Restriction (TIR). These simulation services support the presentation
or restriction of callee's identity to the caller. They are the
simulation of the ISDN/PSTN Connected Line Identification
Presentation/Restriction (COLP/COLR) supplementary services. The COLP
supplementary service is described in ETSI EN 300 094 [23]. The COLR
supplementary service is described in ETSI EN 300 095 [24].
- Communication Waiting (CW). This simulation service provides the
ability of the callee to be informed at the time a communication is
coming in, and that no resources are available for that incoming
communication. The callee has then the choice of accepting, rejecting
or ignoring the incoming communication. The caller will be informed
that his communication is waiting. The CW supplementary service is
described in ETSI ETS 300 056 [11].
- Communication HOLD (HOLD). This simulation service supports the
possibility of suspending the communication (on hold) while for
example another communication with another user is to be done. The CW
supplementary service is described in ETSI ETS 300 139 [12].
- Anonymous Communication Rejection (ACR). This simulation service
allows a user to reject incoming communications when the caller is
anonymous. The ACR supplementary service is described in ETSI EN 300
798 [21].
- Advice of Charge (AoC). This simulation service allows the caller
to request the displaying of tariff information related to the
communication. The service can operate at setup time (AoC-S), during
a session (AoC-D), or at the end of it (AoC-E). The AoC-S
supplementary service is described in ETSI ETS 300 178 [16]. The
AoC-D supplementary service is described in ETSI ETS 300 179 [17].
The AoC-E supplementary service is described in ETSI ETS 300 180
[18].
- Communication Completion on Busy Subscriber (CCBS). This simulation
service supports the ability of a caller to complete a requested
communication to a busy callee without having to make a new
communication attempt when the callee becomes not busy anymore. It is
possible for the caller to request several communications to be under
the CCBS requested status. Also the callee can be subject to several
CCBS communications from different callers. Additionally, the service
provides queue management to arbitrate several CCBS requests to the
Jesske, et al. Expires - December 2005 [Page 4]
Internet-Draft Input reqs. to SIP for ETSI NGN June 2005
same callee. The CCBS supplementary service is described in ETSI EN
300 357 [15].
- Communication Completion on no Reply (CCNR). This simulation
service supports the ability of the caller to complete a requested
communication to a callee without having to make a new communication
attempt when the callee showed activity (a communication attempt was
done). The CCNR supplementary service is described in ETSI EN 301 134
[25].
- Malicious Communication IDentification (MCID). This simulation
service enables the callee to indicate that an incoming communication
is considered to be malicious and it should be identified and
registered. The MCID supplementary service is described in ETSI ETS
300 128 [13].
- Explicit Communication Transfer (ECT). This simulation service
allows the user having two separate sessions to connect the other two
users together into a single session. The ECT supplementary service
is described in ETSI EN 300 367 [20].
2.2 Requirements to support the TISPAN Simulation Services.
[REQ-GEN-1]
For all simulation services interoperability with the PSTN/ISDN is
needed. Solutions that support the following requirements must
interwork with the corresponding PSTN/ISDN supplementary service.
[REQ-ACR-1]
The ACR simulation service requires the caller to be informed that
the communication was rejected due to this service. This is needed to
inform the upstream elements (UAC, e.g., a PSTN/ISDN gateway) about
the reason for the rejection.
[REQ-ACR-2]
It must be possible that authorized callers are not subject to the
ACR service, thus, allowing the callee to receive anonymous requests
from authorized callers. This effectively requires a mechanism to
override the ACR service depending on the identity and authorization
of the caller.
This is needed, e.g., for when a police officer or any other
authority is anonymously calling to a user having the ACR simulation
service enabled.
[REQ-TIP-1]
For supporting the TIP/TIR service when a communication is
interworking with SIP-based Private Branch Exchanges (PBX) a
Jesske, et al. Expires - December 2005 [Page 5]
Internet-Draft Input reqs. to SIP for ETSI NGN June 2005
mechanism is required whereby the private extension of a PBX user is
conveyed to the caller. This allows the caller to call back the PBX
user directly.
For example a user calling a PBX desk (e.g., +49 6151 83 0000 for
Deutsche Telekom in Darmstadt) will be forwarded to an Extension
(e.g., +49 6151 83 5940 for Roland Jesske). It is required that the
caller gets the latter identity, which is allocated to the callee.
[REQ-TIP-2]
The identity mentioned in REQ-TIP-1 has to be backwards compatible
with the SIP identity described within RFC 3325 [4].
[REQ-AoC-1]
In order to support the AoC simulation service, a mechanism is needed
whereby the caller can invoke the AoC simulation service in a given
communication. This invocation is sent when initializing the
communication.
[REQ-AoC-2]
As part of the AoC simulation service a mechanism is needed to
asynchronously transport the charging information. This information
will be displayed to the requesting user.
Asynchronously transport means that the information shall be
transported at any time during and after (e.g., within a certain
period of time) the communication, but within the session context,
when it is needed.
[REQ-CCBS-1]
In order to assure that end to end functionality of the CCBS service
is possible, it is required that the UAC gets knowledge of the
availability of the CCBS service at the UAS or the PSTN/ISDN terminal
on a communication by communication basis.
[REQ-CCBS-2]
The entity providing the CCBS service needs to know the change of the
status of a UAS (e.g., a transition from busy to idle) and it should
have the ability to recognize if the UAS is able to provide such
indication.
[REQ-CCBS-3]
The CCBS simulation service should be able to handle queues and
arbitrate multiple simultaneous CCBS requests according to a locally
defined policy (e.g., first in first out).
[REQ-CCBS-4]
It should be also possible for CCBS request initiators to suspend,
resume and cancel their pending CCBS requests.
Jesske, et al. Expires - December 2005 [Page 6]
Internet-Draft Input reqs. to SIP for ETSI NGN June 2005
[REQ-CCNR-1]
In order to assure that end to end functionality of the CCNR service
is possible, it is required that the UAC gets knowledge of the
availability of the CCNR service at the UAS or the PSTN/ISDN terminal
on a communication by communication basis.
[REQ-CCNR-2]
The entity providing the CCNR service needs to know the change of the
status of a UAS (e.g., a transition from idle to another state) and
it should have the ability to recognize if the UAS is able to provide
such indication.
[REQ-CCNR-3]
The CCNR simulation service should be able to handle queues and
arbitrate multiple simultaneous CCNR requests according to a locally
defined policy (e.g., first in first out).
[REQ-CCNR-4]
It should be also possible for CCNR request initiators to suspend,
resume and cancel their pending CCNR requests.
[REQ-MCID-1]
In order to support the MCID simulation service there must be a
mechanism whereby a user can provide an indication that an incoming
request or session is considered to be malicious. The user can
provide this indication at the start, during or within a certain time
after a session or request.
Note: The requirement reads about the ability of the callee to
provide an indication of malicious call, but there is no requirement
to supply the caller's identity to the called.
[REQ-MCID-2]
For interoperability reasons, the MCID simulation service logic needs
to get the knowledge that, even if the originator identity is missing
in the signalling, it can available upon request. This is due to,
e.g., interworking with the PSTN network, where, in some cases, the
originator's identity is only available upon explicit request. The
information can be received asynchronously in a timeframe of 1-30
seconds even after the session has been closed.
[REQ-CW-1]
To implement the CW simulation service, ETSI envisages the usage of
an application server that detects some busy conditions on behalf of
the user. To support this scenario a mechanism is required to inform
the callee that a communication is waiting.
Jesske, et al. Expires - December 2005 [Page 7]
Internet-Draft Input reqs. to SIP for ETSI NGN June 2005
[REQ-CW-2]
It must be possible for CW to inform the caller that an application
server is holding the communication until the callee is available.
[REQ-CDIV-1]
To support the CDIV simulation service it is required that the caller
is informed if a communication diversion takes place.
[REQ-CDIV-2]
To support the CDIV simulation service a mechanism that shows or
restrict the indication of the diverting user is required.
[REQ-CDIV-3]
To support the CDIV simulation service it is required that the reason
of the redirection is delivered to the caller and callee.
[REQ-CDIV-4]
For interoperability reasons and service compatibility with the CDIV
simulation service, it is required that the history of the
communication is sent in forward and backward directions to the
caller and callee, respectively.
[REQ-CAT-1]
For service applicability to special groups and interoperability with
the PSTN/ISDN an indication of the originating party category is
needed. This is needed due to the fact that some services apply a
special behavior to special user groups (e.g., like Pay-Phones).
[REQ-CAT-2]
The originating party category referred to in REQ-CAT-1 must be
inserted by a trusted entity.
4. Security Considerations
The requirements in this document are intended to result in a
mechanism with general applicability for ETSI NGN and are generally
not applicable to the public Internet.
Use of these mechanisms in any other context has serious security
shortcomings, namely there is absolutely no guarantee that the
information has not been modified, or was even correct in the first
place.
5. IANA Considerations
This document does not have any implications for IANA.
Jesske, et al. Expires - December 2005 [Page 8]
Internet-Draft Input reqs. to SIP for ETSI NGN June 2005
References
[1] 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.
[2] Barnes, M. "An Extension to the Session Initiation Protocol for
Request History Information", draft-ietf-sip-history-info-06.txt,
January 17, 2005.
[3] Elwell, J.; "SIP Reason header extension for indicating
redirection reasons", draft-elwell-sipping-redirection-reason-
02.txt, June 2005.
[4] Jennings, C., Peterson, J. and M. Watson, "Private Extensions to
the Session Initiation Protocol (SIP) for Asserted Identity within
Trusted Networks", RFC 3325, November 2002.
[5] ETSI EN 300 089 (V3.1.1): "Integrated Services Digital Network
(ISDN); Calling Line Identification Presentation (CLIP)
supplementary service; Service description".
[6] ETSI EN 300 090 (V1.2.1): "Integrated Services Digital Network
(ISDN); Calling Line Identification Restriction (CLIR)
supplementary service; Service description".
[7] ETSI EN 300 200 (Edition 1): "Integrated Services Digital Network
(ISDN); Call Forwarding Unconditional (CFU) supplementary service;
Service description".
[8] ETSI EN 300 199 (V1.2.1): "Integrated Services Digital Network
(ISDN); Call Forwarding Busy (CFB) supplementary service; Service
description".
[9] ETIS EN 300 201 (V1.2.1): "Integrated Services Digital Network
(ISDN); Call Forwarding No Reply (CFNR) supplementary service;
Service description".
[10] ETSI ETS 300 202 (Edition 1): "Integrated Services Digital
Network (ISDN); Call Deflection (CD) supplementary service;
Service description".
[11] ETSI ETS 300 056 (Edition 1): "Integrated Services Digital
Network (ISDN); Call Waiting (CW) supplementary service; Service
description".
Jesske, et al. Expires - December 2005 [Page 9]
Internet-Draft Input reqs. to SIP for ETSI NGN June 2005
[12] ETSI ETS 300 139 (Edition 1): "Integrated Services Digital
Network (ISDN); Call Hold (HOLD) supplementary service; Service
description".
[13] ETSI ETS 300 128 (Edition 1): "Integrated Services Digital
Network (ISDN); Malicious Call Identification (MCID) supplementary
service; Service description".
[14] ETSI ETS 300 183 (Edition 1): "Integrated Services Digital
Network (ISDN); Conference call, add-on (CONF) supplementary
service; Service description".
[15] ETSI EN 300 357 (V1.2.1): "Integrated Services Digital Network
(ISDN); Completion of Calls to Busy Subscriber (CCBS)
supplementary service; Service description".
[16] ETSI ETS 300 178 (Edition 1): "Integrated Services Digital
Network (ISDN); Advice of Charge: charging information at call
set-up time (AOC-S) supplementary service; Service description".
[17] ETSI ETS 300 179 (Edition 1): "Integrated Services Digital
Network (ISDN); Advice of Charge: charging information during the
call (AOC-D) supplementary service; Service description".
[18] ETSI ETS 300 180 (Edition 1): "Integrated Services Digital
Network (ISDN); Advice of Charge: charging information at the end
of the call (AOC-E) supplementary service; Service description".
[19] ETSI EN 300 650 (V1.2.1): "Integrated Services Digital Network
(ISDN); Message Waiting Indication (MWI) supplementary service;
Service description".
[20] ETSI EN 300 367 (V1.2.1): "Integrated Services Digital Network
(ISDN); Explicit Call Transfer (ECT) supplementary service;
Service description".
[21] ETSI EN 301 798 (V1.1.1): "Services and Protocols for Advanced
Networks (SPAN); Anonymous Call Rejection (ACR) Supplementary
Service; Service description".
[22] ETSI ETS 300 520: "European digital cellular telecommunications
system (Phase 2); Call Barring (CB) supplementary services; Stage
1 (GSM 02.88)".
[23] ETSI EN 300 094: "Integrated Services Digital Network (ISDN);
Connected Line Identification Presentation (COLP) supplementary
service; Service description".
Jesske, et al. Expires - December 2005 [Page 10]
Internet-Draft Input reqs. to SIP for ETSI NGN June 2005
[24] ETSI ETS 300 095: "Integrated Services Digital Network (ISDN);
Connected Line Identification Restriction (COLR) supplementary
service; Service description".
[25] ETSI EN 301 134: "Integrated Services Digital Network (ISDN);
Completion of Calls on No Reply (CCNR) supplementary service;
Service description".
[26] 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on
SIP and SDP".
Contributors
Keith Drage
GSM OPTIMUS HOUSE
SN5 6PP SWINDON
United Kingdom
Phone: +44 1793 897312
Email: drage@lucent.com
Sebastien Garcin
France Telecom
38-40, Rue du General Leclerc
92130 Issy Les Moulineaux
France
Acknowledgments
The authors would like to thank Anna Martinez people of ETSI TISPAN
WG3 for their comments.
Author's Addresses
Roland Jesske
Deutsche Telekom
Am Kavalleriesand 3
64307 Darmstadt
Germany
Phone: +496151835940
Email: r.jesske@t-com.net
Denis Alexeitsev
Deutsche Telekom
Am Kavalleriesand 3
64307 Darmstadt
Germany
Jesske, et al. Expires - December 2005 [Page 11]
Internet-Draft Input reqs. to SIP for ETSI NGN June 2005
Phone: +496151832130
Email: d.alexeitsev@t-com.net
Miguel A. Garcia-Martin
Nokia
P.O. Box 407
NOKIA GROUP, FIN 00045
Finland
EMail: miguel.an.garcia@nokia.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the
authorsretain 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.
Intellectual Property
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
Jesske, et al. Expires - December 2005 [Page 12]
Internet-Draft Input reqs. to SIP for ETSI NGN June 2005
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jesske, et al. Expires - December 2005 [Page 13]