One document matched: draft-jesske-sipping-tispan-requirements-03.txt
Differences from draft-jesske-sipping-tispan-requirements-02.txt
TISPAN NGN requirements to SIP June 2006
Sipping Working Group
Internet Draft Roland Jesske
Expires: December 21, 2007 Denis Alexeitsev
Deutsche Telekom
M. Garcia-Martin
Nokia
22.June 2006
Input Requirements for the Session Initiation Protocol (SIP) in support
for the European Telecommunications Standards Institute, draft-jesske-
sipping-tispan-requirements-03
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 December 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Jesske Expires - December 2006 [Page 1]
TISPAN NGN requirements to SIP June 2006
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.
Table of Contents
1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
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) . . . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . .. . . . . . . 11
7.2. Informational References . . . . . . . . . .. . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
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
Jesske Expires - December 2006 [Page 2]
TISPAN NGN requirements to SIP June 2006
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 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
Jesske Expires - December 2006 [Page 3]
TISPAN NGN requirements to SIP June 2006
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.
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.
Jesske Expires - December 2006 [Page 4]
TISPAN NGN requirements to SIP June 2006
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.
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.
Jesske Expires - December 2006 [Page 5]
TISPAN NGN requirements to SIP June 2006
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.
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:
The AoC service must be possible to be invoked at the time a
communication is initiated.
REQ-AoC-2:
It must be possible for a caller to receive charging information once
the service has been invoked at the time a communication is
initiated, during the communication, and when the communication has
ended.
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
Jesske Expires - December 2006 [Page 6]
TISPAN NGN requirements to SIP June 2006
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]):
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.
Jesske Expires - December 2006 [Page 7]
TISPAN NGN requirements to SIP June 2006
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).
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:
Jesske Expires - December 2006 [Page 8]
TISPAN NGN requirements to SIP June 2006
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.
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
Jesske Expires - December 2006 [Page 9]
TISPAN NGN requirements to SIP June 2006
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].
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:
Jesske Expires - December 2006 [Page 10]
TISPAN NGN requirements to SIP June 2006
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.
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, Anna-Martinez Rebordosa 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 (TXT, HTML, XML).
Jesske Expires - December 2006 [Page 11]
TISPAN NGN requirements to SIP June 2006
[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.
[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.
[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.
[8] ETSI, ‘‘Integrated Services Digital Network (ISDN); Connected Line
Identification Restriction (COLR) Supplementary Service; Service
Description,’’ ETSI ETS 300 095, January 1992.
[9] ETSI, ‘‘Integrated Services Digital Network (ISDN); Malicious Call
Identification (MCID) Supplementary Service; Service Description,’’
ETSI ETS 300 128, March 1992.
[10] ETSI, ‘‘Integrated Services Digital Network (ISDN); Call
Forwarding Busy (CFB) Supplementary Service; Service Description,’’
ETSI EN 300 199, June 2001.
[11] ETSI, ‘‘Integrated Services Digital Network (ISDN); Call
Forwarding Unconditional (CFU) Supplementary Service; Service
Description,’’ ETSI ETS 300 200, December 1994.
[12] ETSI, ‘‘Integrated Services Digital Network (ISDN); Call
Forwarding No Reply (CFNR) Supplementary Service; Service
Description,’’ ETSI EN 300 201, May 2001.
[13] ETSI, ‘‘Integrated Services Digital Network (ISDN); Call
Forwarding Deflection (CD) Supplementary Service; Service
Description,’’ ETSI ETS 300 202, December 1994.
[14] ETSI, ‘‘Integrated Services Digital Network (ISDN); Completion of
Calls on No Reply (CCNR) Supplementary Service; Service
Description,’’ ETSI EN 301 134 v1.1.1, October 1998.
[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.
Jesske Expires - December 2006 [Page 12]
TISPAN NGN requirements to SIP June 2006
[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.
[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.
[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.
[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.
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
Changes from Version 02 to 03
Modification of AoC requirements due to TISPAN discussions
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
Jesske Expires - December 2006 [Page 13]
TISPAN NGN requirements to SIP June 2006
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). 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 Expires - December 2006 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-23 22:42:58 |