SIPPING Working Group R. Jesske
Internet-Draft D. Alexeitsev
Expires: April 9, 2006 Deutsche Telekom
M. Garcia-Martin, Ed.
Nokia
October 6, 2005
Input Requirements for the Session Initiation Protocol (SIP) in support
for the European Telecommunications Standards Institute
draft-jesske-sipping-tispan-requirements-02
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 April 9, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes a set of requirements to the Session
Initiation Protocol (SIP) [2] 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.
Jesske, et al. Expires April 9, 2006 [Page 1]
Internet-Draft TISPAN NGN requirements to SIP October 2005
Table of Contents
1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements in Support of Simulation Services . . . . . . . . 4
3.1. General Requirements . . . . . . . . . . . . . . . . . . . 4
3.2. Anonymous Communication Rejection (ACR) . . . . . . . . . 5
3.3. Terminating Identification Presentation/Restriction
(TIP/TIR) . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Advice of Charge (AoC) . . . . . . . . . . . . . . . . . . 6
3.5. Communication Completion on Busy Subscriber (CCBS) and
Communication Completion on no Reply (CCNR) . . . . . . . 7
3.6. Malicious Communication Identification (MCID) . . . . . . 9
3.7. Communication Waiting (CW) . . . . . . . . . . . . . . . . 10
3.8. Communications Diversion (CDIV) . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informational References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Jesske, et al. Expires April 9, 2006 [Page 2]
Internet-Draft TISPAN NGN requirements to SIP October 2005
1. Conventions
This document does not specify any protocol of any kind. Therefore,
the usage of the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document, as described in RFC-2119 [1], does not
apply.
2. 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) aiming the creation of a multimedia
fixed network. Generally NGN is largely based on the 3rd Generation
mobile Partnership Project (3GPP) IP Multimedia Subsystem (IMS)
Release 7 with additions required to support the fixed access..
The TISPAN NGN project has selected SIP profiled by 3GPP TS 24.229
[4] 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 fixed and
wireless multimedia applications.
While ETSI is committed to the creation of new multimedia
applications and services, the importance of provided support to
existing Integrated Services Digital Network and Public Switched
Telephone Network (ISDN/PSTN) supplementary services has been also
acknowledged. 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. For example, all the
services that depend on a busy condition from a user who is using a
single telephone become broader in SIP when the user is using and
registered from different terminals, since the busy indication from
one terminal might not indicate that the user is not willing to
accept other sessions in other terminals.
3GPP TS 24.229 [4] is used to simulate the regarding services, but to
fulfill the requirements defined within ETSI TISPAN NGN Release 1
some further SIP support is needed.
Note that sometimes the realization of a service requires the
implementation of a number of SIP extensions in SIP User Agents. We
do not expect SIP UAs not implementing those extensions to provide a
service to the user. In that case, the basic session will be
Jesske, et al. Expires April 9, 2006 [Page 3]
Internet-Draft TISPAN NGN requirements to SIP October 2005
provided without the additional service.
This document defines some input requirements to support the
implementation of simulation services. Particularly, we have listed
those requirements for which we do not have a clear indication of the
implementation, or that clarify the behaviour of the service.
However, we do not list all the requirements that describe a service.
Readers interested in a comprehensive set of requirements should
refer to the ETSI specifications for the corresponding PSTN/ISDN
supplementary service (even when such specification does not consider
SIP or IMS). We have included a list of the PSTN/ISDN supplementary
services specification as references.
It is generally understood that not every requirement listed in this
memo will require a SIP extension. A companion memo, Analysis of
TISPAN req. to SIP [5] provides an analysis of 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.
Some of the services for which we have produced requirements are
classified as "regulatory services", i.e., required by national
administrations as a prerequisite for the operation of the network.
We have marked these services as an assistance to provide an
indication of prioritization when developing solutions.
3. Requirements in Support of Simulation Services
3.1. General Requirements
This section provides a collection of general requirements that are
applicable to all the services described later. Solutions developed
to meet the rest of the requirements must have into account those
described in here.
Jesske, et al. Expires April 9, 2006 [Page 4]
Internet-Draft TISPAN NGN requirements to SIP October 2005
REQ-GEN-1: All simulation services must provide interoperability with
the PSTN/ISDN. By interoperability we mean that, in the
case that a simulation or supplementary service is
provided to one of the users when one of the endpoints is
located in the PSTN and the other is located in the NGN
IMS network, the user should receive the service without
any degradation as if the service were provided in the
native network.
REQ-GEN-2: Most of the PSTN/ISDN services are targeting sessions
where audio is the only media stream, while SIP allows to
establish a session with any type of media. The user's
experience should not be limited to that of the
traditional supplementary services. Thus, when
applicable, the simulation services should be applicable
to any type of communication, including but not restricted
only to, audio calls (e.g., including instant messaging,
video calls, etc.).
REQ-GEN-3: SIP User Agents not providing a simulation service should
not be influenced by the establishment of a given
communication; they are simple not able to provide the
related service.
REQ-GEN-4: It must be possible to convey the language(s) known to the
caller.
REQ-GEN-5: It must be possible to indicate that the caller is an
operator.
REQ-GEN-6: It must be possible to assert that the caller has
priority.
REQ-GEN-7: Note: we seem to have requirements, based on the PSTN/
ISDN, to indicate that some calls are data calls, test
calls, or originated in a payphone. We need to find the
correct formulation of those requirements.
3.2. Anonymous Communication Rejection (ACR)
This service allows a callee to instruct the network to automatically
reject incoming communications when the caller is anonymous. The ACR
supplementary service is described in ETSI EN 300 798 [19]. The
services also contains provisions for exceptional cases where the
service is overridden. One of these cases consist of a PSTN
originated call where the network could not provide an identification
of the calling party number, such as is the case when the call was
originated in an analogue network.
ACR is a regulatory service.
Jesske, et al. Expires April 9, 2006 [Page 5]
Internet-Draft TISPAN NGN requirements to SIP October 2005
REQ-ACR-1: The originating network shall be able to indicate to the
terminating network, that the caller has requested
anonymity.
REQ-ACR-2: The ACR simulation service requires the caller to be
informed that the communication was rejected because the
SIP request was anonymous and the callee had the ACR
service activated.
3.3. Terminating Identification Presentation/Restriction (TIP/TIR)
These services support the presentation or restriction of a callee's
identity to the caller. They are the simulation of the ISDN/PSTN
Connected Line Identification Presentation/Restriction (COLP/COLR)
supplementary services. The network does not assert the identity
referred to in this service; the callee merely indicates an
additional identity where he is reachable, e.g., for a new future
communication.
The service is useful in scenarios where the caller dialled a SIP URI
that is translated to another SIP URI, such as the case when a user
dials a free-phone URI that is translated to a real URI. The callee
may want to indicate the real addressable URI to the caller.
The corresponding COLP supplementary service is described in ETSI EN
300 094 [7]. The corresponding COLR supplementary service is
described in ETSI ETS 300 095 [8].
TIP and TIR are regulatory services.
REQ-TIP-1: In addition to any network asserted identity, it must be
possible for the callee to indicate in a SIP response an
additional identity where the user is reachable for future
direct communications. Note that the requirement refers
to the user, not to the same instance of the User Agent.
REQ-TIP-2: The identity mentioned in REQ-TIP-1 must be formatted as a
SIP URI [2] or TEL URL [3]. A translation between SIP URI
and TEL URL by the network is not requested.
REQ-TIP-3: The identity mentioned in REQ-TIP-1 is considered an end
user supplied information that is not asserted by the
network.
3.4. Advice of Charge (AoC)
The Advice of Charge service allows the caller to request the
displaying of tariff information related to the communication. The
caller can request the displaying of charging information at setup
time (AoC-S), during a session (AoC-D), or at the end of it (AoC-E),
including a few seconds after the communication has ended.
Jesske, et al. Expires April 9, 2006 [Page 6]
Internet-Draft TISPAN NGN requirements to SIP October 2005
The AoC-S supplementary service is described in ETSI ETS 300 178
[15]. The AoC-D supplementary service is described in ETSI ETS 300
179 [16]. The AoC-E supplementary service is described in ETSI ETS
300 180 [17]].
REQ-AoC-1: It must be possible for a caller to invoke the AoC
simulation service at the time a communication is
initiated, during the communication, or a few seconds
after the communication has ended.
REQ-AoC-2: It must be possible for a caller to receive charging
information once the service has been invoked.
REQ-AoC-3: The information supplied to the user is asynchronously
generated, updated and reported to the user when new
charging information is available. For example, when the
cumulative charging value changes more then a certain
predefined value; or, as time passes by, the charging
implications might change; or a re-INVITE can request new
media streams that will impact charging. 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.
3.5. Communication Completion on Busy Subscriber (CCBS) and
Communication Completion on no Reply (CCNR)
CCBS and CCNR are very similar in nature, thus, we describe the
requirements for both services at the same time.
Communication Completion on Busy Subscriber (CCBS) provides the
caller with the ability 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
same callee. The CCBS supplementary service is described in ETSI EN
300 357 [18].
Communication Completion on no Reply (CCNR) provides the caller with
the ability to complete a requested communication to a callee without
having to make a new communication attempt when the callee showed
activity. The CCNR supplementary service is described in ETSI EN 301
134 [14].
For the purpose of this service, we provide the following definitions
(sources: ETSI EN 300 357 [18] and ETSI EN 301 134 [14]):
Jesske, et al. Expires April 9, 2006 [Page 7]
Internet-Draft TISPAN NGN requirements to SIP October 2005
CCBS/CCNR request: an instance of an activation of the CCBS/CCNR
service which is held in a queue pending the correct conditions
for the CCBS/CCNR service to be completed.
Suspended CCBS/CCNR request: a CCBS/CCNR request which cannot be
served even if callee is in the appropriate state because the
caller is busy.
CCBS/CCNR service duration timer: maximum time the CCBS/CCNR service
will remain activated for the caller within the network.
CCBS call: a communication generated by the network connecting the
caller to the callee, resulting from the callers' acceptance of a
CCBS recall.
CCBS recall: an indication informing the caller that the network is
ready to initiate a CCBS call to the callee and that the network
is awaiting a response to this indication.
Requirements affecting CCBS/CCNR:
Invocation:
REQ-CCBS/CCNR-1: In order to assure that end-to-end functionality of
the CCBS/CCNR services is possible, there must be a
mechanism whereby the caller gets knowledge of the
availability of the CCBS/CCNR service at the callee
or the PSTN/ISDN terminal on a communication by
communication basis.
REQ-CCBS/CCNR-2: It must be possible for the caller to invoke the
CCBS/CCNR service.
Control of callee status and information to the caller:
REQ-CCBS/CCNR-3: The CCBS/CCNR simulation service should be able to
handle queues and arbitrate multiple simultaneous
CCBS/CCNR requests according to a locally defined
policy (e.g., first in first out).
REQ-CCBS/CCNR-4: The entity providing the CCBS/CCNR service needs to
know the change of the status at the callee's
(e.g., in CCBS a transition when the callee sends
or receive a BYE request for an existing session;
in CCNR any activity indicated by the presence of
the user, such as a key press or any other
interaction with the device).
Jesske, et al. Expires April 9, 2006 [Page 8]
Internet-Draft TISPAN NGN requirements to SIP October 2005
REQ-CCBS/CCNR-5: The entity providing the CCBS/CCNR service needs to
learn the capability of the callee's UAs to provide
an indication of the change of status, not later
than upon failure response (CCBS) or not later than
the alerting phase (CCNR).
REQ-CCBS/CCNR-6: The CCBS/CCNR service duration timer expires after
a certain time controlled by the entity providing
the CCBS/CCNR service.
REQ-CCBS/CCNR-7: It must be possible for the network to prioritize
CCBS/CCNR recalls towards the callee, above regular
calls. This implies that any communication
performed as a result of the execution of a CCBS/
CCNR request should be distinguishable from regular
communications.
REQ-CCBS/CCNR-8: The CCBS/CCNR service must be able to inform the
caller when the service-specific condition related
to the callee's state is met.
REQ-CCBS/CCNR-9: There must be a mechanism whereby the callee can
accept or reject CCBS/CCNR requests.
REQ-CCBS/CCNR-10: If the caller accepts a CCBS recall, other
terminating calls towards the callee should be
treated as if the callee were already busy.
REQ-CCBS/CCNR-11: There must be a mechanism whereby the entity
providing CCBS/CCNR service can suspend, resume and
cancel CCBS/CCNR subscriptions.
REQ-CCBS/CCNR-12: When the service-specific condition related to the
callee's state is met, the CCBS/CCNR service must
be able to reach the caller at any of the locations
where he is logged.
REQ-CCBS/CCNR-13: The service-specific condition related to the
callee's state must take into account the state of
the user at different terminals he might be using.
Suspend state:
REQ-CCBS/CCNR-14: The entity providing the CCBS/CCNR service needs to
know the change of the status at the caller's
(e.g., to find out when a pending CCBS/CCNR request
can be resumed or to allocate a time-slot to
execute a pending CCBS/CCNR request).
REQ-CCBS/CCNR-15: Should the caller be busy at the time of executing
CCBS/CCNR request, the request is suspended until
its status changes (back to free status).
REQ-CCBS/CCNR-16: During the period of time when a CCBS/CCNR request
is in suspended state for a given caller, no other
CCBS/CCNR request execution must be performed for
that caller.
Jesske, et al. Expires April 9, 2006 [Page 9]
Internet-Draft TISPAN NGN requirements to SIP October 2005
REQ-CCBS/CCNR-17: A suspended CCBS/CCNR request is resumed when
caller's status changes to non-busy. The new place
in the queue of that subscription is chosen
according to a local policy.
REQ-CCBS/CCNR-18: The suspension of a CCBS/CCNR request of a user
must not impact other users in the same queue for
the same callee.
REQ-CCBS/CCNR-19: There must be a mechanism whereby CCBS/CCNR request
initiators can check or cancel their pending CCBS/
CCNR requests.
3.6. Malicious Communication Identification (MCID)
The Malicious Communication Identification (MCID) 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 [9].
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.
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 time-frame of 1-30 seconds even after the session
has been closed.
Note: Requirement REQ-MCID-1 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.
3.7. Communication Waiting (CW)
This service provides the ability of the callee to be informed at the
time a communication is coming in that no resources are available for
that incoming communication. The callee has then the choice of
accepting, rejecting or ignoring the incoming communication, which is
outside the scope of he service. The caller will be informed that
his communication is waiting. The CW supplementary service is
described in ETSI ETS 300 056 [6].
Jesske, et al. Expires April 9, 2006 [Page 10]
Internet-Draft TISPAN NGN requirements to SIP October 2005
REQ-CW-1: For implement the CW simulation service it is envisioned
the usage of an application server that detects some busy
conditions on behalf of the user. To support this scenario
a mechanism to inform the callee that a communication is in
waiting state is required.
REQ-CW-2: It must be possible for the CW service to inform the caller
that an application server is holding the communication
until the callee is available.
3.8. Communications Diversion (CDIV)
This simulation service allows the diversion of incoming
communications to a third party. Communications are diverted upon
one of several events (e.g., the callee is busy). 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 ETS 300 200 [11]. The CFB
supplementary service is described in ETSI EN 300 199 [10]. The CFNR
supplementary service is described in ETSI EN 300 201 [12]. The CD
supplementary service is described in ETSI ETS 300 202 [13].
REQ-CDIV-1: It must be possible that the caller is informed that a
communication is being diverted.
REQ-CDIV-2: It must be possible for the diverting user to express his
privacy requirements with respect his identity.
REQ-CDIV-3: The reason of the redirection must be available to the
caller, callee, and network intermediaries (e.g., voice
mail server).
REQ-CDIV-4: It must be possible for the caller, the callee, and
network intermediaries to be informed about the identity
of the caller, diverting parties, and callee, if these
identities are available.
4. Security Considerations
This memo provides a collection of requires to SIP for the
implementation of some PSTN/ISDN simulation services in Next
Generation Networks. Some or most of these services require to
consider the security threats and provide a solution for them.
Jesske, et al. Expires April 9, 2006 [Page 11]
Internet-Draft TISPAN NGN requirements to SIP October 2005
5. 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
6. Acknowledgments
These document has been heavily discussed in the ETSI TISPAN WG3 and
the IETF sipping-tispan mailing list. The authors and contributors
would like to thank Paul Kyzivat, Christian Schmidt, Phil Mart, Hans-
Erik van Elburg, Michael Hammer, Tom Taylor, Shida Schubert, Jeroen
van Bemmel, Silvia Tessa, and Rocky Wang for keeping the discussion
alive and helpful comments.
7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] 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.
[3] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
7.2. Informational References
[4] 3GPP, "Internet Protocol (IP) multimedia call control protocol
based on Session Initiation Protocol (SIP) and Session
Description Protocol (SDP); Stage 3", 3GPP TS 24.229 5.13.0,
June 2005.
Jesske, et al. Expires April 9, 2006 [Page 12]
Internet-Draft TISPAN NGN requirements to SIP October 2005
[5] Jesske, R., "Analysis of the Input Requirements for the Session
Initiation Protocol (SIP) in support for the European
Telecommunications Standards Institute (ETSI) Next Generation
Networks (NGN) simulation service",
draft-jesske-sipping-tispan-analysis-00 (work in progress),
June 2005.
[6] ETSI, "Integrated Services Digital Network (ISDN); Call Waiting
(CW) Supplementary Service; Service Description", ETSI ETS 300
056, October 1991, <http://webapp.etsi.org/workprogram/
Report_WorkItem.asp?WKI_ID=18>.
[7] ETSI, "Integrated Services Digital Network (ISDN); Connected
Line Identification Presentation (COLP) Supplementary Service;
Service Description", ETSI EN 300 094 v2.1.1, June 2000, <http:
//webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=9224>.
[8] ETSI, "Integrated Services Digital Network (ISDN); Connected
Line Identification Restriction (COLR) Supplementary Service;
Service Description", ETSI ETS 300 095, January 1992, <http://
webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=10>.
[9] ETSI, "Integrated Services Digital Network (ISDN); Malicious
Call Identification (MCID) Supplementary Service; Service
Description", ETSI ETS 300 128, March 1992, <http://
webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=3>.
[10] ETSI, "Integrated Services Digital Network (ISDN); Call
Forwarding Busy (CFB) Supplementary Service; Service
Description", ETSI EN 300 199, June 2001, <http://
webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=10711>.
[11] ETSI, "Integrated Services Digital Network (ISDN); Call
Forwarding Unconditional (CFU) Supplementary Service; Service
Description", ETSI ETS 300 200, December 1994, <http://
webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=5>.
[12] ETSI, "Integrated Services Digital Network (ISDN); Call
Forwarding No Reply (CFNR) Supplementary Service; Service
Description", ETSI EN 300 201, May 2001, <http://
webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=10702>.
[13] ETSI, "Integrated Services Digital Network (ISDN); Call
Forwarding Deflection (CD) Supplementary Service; Service
Description", ETSI ETS 300 202, December 1994, <http://
webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=25>.
[14] ETSI, "Integrated Services Digital Network (ISDN); Completion
Jesske, et al. Expires April 9, 2006 [Page 13]
Internet-Draft TISPAN NGN requirements to SIP October 2005
of Calls on No Reply (CCNR) Supplementary Service; Service
Description", ETSI EN 301 134 v1.1.1, October 1998, <http://
webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=2451>.
[15] ETSI, "Integrated Services Digital Network (ISDN); Advice of
Charge: Charging Information at Call Set-up Time (AOC-S)
Supplementary Service; Service Description", ETSI ETS 300 178,
November 1992, <http://webapp.etsi.org/workprogram/
Report_WorkItem.asp?WKI_ID=13>.
[16] ETSI, "Integrated Services Digital Network (ISDN); Advice of
Charge: Charging Information During the Call (AOC-D)
Supplementary Service; Service Description", ETSI ETS 300 179,
November 1992, <http://webapp.etsi.org/workprogram/
Report_WorkItem.asp?WKI_ID=14>.
[17] ETSI, "Integrated Services Digital Network (ISDN); Advice of
Charge: Charging Information at the End of the Call (AOC-E)
Supplementary Service; Service description", ETSI ETS 300 180,
November 1992, <http://webapp.etsi.org/workprogram/
Report_WorkItem.asp?WKI_ID=15>.
[18] ETSI, "Integrated Services Digital Network (ISDN); Completion
of Calls to Busy Subscriber (CCBS) Supplementary Service;
Service Description", ETSI EN 300 357 v1.2.1, May 2001, <http:/
/webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=10707>.
[19] ETSI, "Services and Protocols for Advanced Networks (SPAN);
Anonymous Call Rejection (ACR) Supplementary Service; Service
description", ETSI EN 301 798 v1.1.1, October 2000, <http://
webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=6618>.
Jesske, et al. Expires April 9, 2006 [Page 14]
Internet-Draft TISPAN NGN requirements to SIP October 2005
Authors' Addresses
Roland Jesske
Deutsche Telekom
Am Kavalleriesand 3
Darmstadt 64307
Germany
Email: r.jesske@t-com.net
Denis Alexeitsev
Deutsche Telekom
Am Kavalleriesand 3
Darmstadt 64307
Germany
Email: d.alexeitsev@t-com.net
Miguel A. Garcia Martin (editor)
Nokia
P.O. Box 407
NOKIA GROUP, FIN 00045
Finland
Email: miguel.an.garcia@nokia.com
Jesske, et al. Expires April 9, 2006 [Page 15]
Internet-Draft TISPAN NGN requirements to SIP October 2005
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 (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jesske, et al. Expires April 9, 2006 [Page 16]