[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04                                                
     TISPAN NGN requirements to SIP     June 2007


   SIPPING                                                Roland Jesske
   Internet Draft                                      Denis Alexeitsev
   Intended Status: private                            Deutsche Telekom
   draft-jesske-sipping-tispan-requirements-04         M. Garcia-Martin
                                                                  Nokia
   Expires: December 2007                                     June 2007



Input Requirements for the Session Initiation Protocol (SIP) in support
 for the European Telecommunications Standards Institute, draft-jesske-
                     sipping-tispan-requirements-04


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 6, 2007.

   Copyright Notice

   Copyright (C) The IETF Trust (2007).

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



Jesske                 Expires - December 2007               [Page 1]


     TISPAN NGN requirements to SIP     June 2007


   requirements should help to find SIP solutions to provide the
   services described within this document.





Table of Contents

   1. Conventions....................................................2
   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).............10
      3.7 Communication Waiting (CW)................................10
      3.8 Communications Diversion (CDIV)...........................11
   4. Security Considerations.......................................11
   5. Contributors..................................................11
   6. Acknowledgments...............................................12
   7. References....................................................12
      7.1 . Normative References....................................12
      7.2 Informational References..................................12
   8. Authors' Addresses............................................13
   9. Full Copyright Statement......................................14
   10. Intellectual Property........................................14
   11. Acknowledgment...............................................15



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.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 2007               [Page 2]


     TISPAN NGN requirements to SIP     June 2007


   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



Jesske                 Expires - December 2007               [Page 3]


     TISPAN NGN requirements to SIP     June 2007


   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.

   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:


Jesske                 Expires - December 2007               [Page 4]


     TISPAN NGN requirements to SIP     June 2007


   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.
   REQ-GEN-8:
   For services it is needed to sent from an application server point
   indications and notifications to the user. This is needed to provide
   a indication to the user that a Service is fulfilled now or that
   special procedures or actions from a user or application server are
   expected. Notifications are needed for the user or application server
   that such a action was successfully processed.

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


Jesske                 Expires - December 2007               [Page 5]


     TISPAN NGN requirements to SIP     June 2007


   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.4Advice 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



Jesske                 Expires - December 2007               [Page 6]


     TISPAN NGN requirements to SIP     June 2007


   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

   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



Jesske                 Expires - December 2007               [Page 7]


     TISPAN NGN requirements to SIP     June 2007


   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).
   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



Jesske                 Expires - December 2007               [Page 8]


     TISPAN NGN requirements to SIP     June 2007


   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.
   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:



Jesske                 Expires - December 2007               [Page 9]


     TISPAN NGN requirements to SIP     June 2007


   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].

   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.



Jesske                 Expires - December 2007              [Page 10]


     TISPAN NGN requirements to SIP     June 2007


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.

   IANA Considerations

   This document describes the use of the Reason header field described
   within RFC 3326 [2]. No additional SIP elements are defined within
   this document. Therefore, this document does not provide any action
   to IANA.

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

Jesske                 Expires - December 2007              [Page 11]


     TISPAN NGN requirements to SIP     June 2007


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).

   [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.




Jesske                 Expires - December 2007              [Page 12]


     TISPAN NGN requirements to SIP     June 2007


   [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.
   [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.

8.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



Jesske                 Expires - December 2007              [Page 13]


     TISPAN NGN requirements to SIP     June 2007


   Email:  miguel.an.garcia@nokia.com

   Changes from Version 02 to 03
   Modification of AoC requirements due to TISPAN discussions

   Changes from Version 03 to 04
   Add GEN-REQ-8

9.Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


10.Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.



Jesske                 Expires - December 2007              [Page 14]


     TISPAN NGN requirements to SIP     June 2007




11.
   Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).













































Jesske                 Expires - December 2007              [Page 15]