[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/