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

Versions: 00 01 02 03 04                                                
Internet-Draft       Input reqs. to SIP for ETSI NGN           June 2005


   Sipping Working Group                                   Roland Jesske
   Internet Draft                                       Deutsche Telekom
   Expires: December 13, 2005                           Denis Alexeitsev
                                                        Deutsche Telekom
                                                    Miguel Garcia-Martin
                                                                   Nokia
                                                           June 14, 2005


      Input Requirements for the Session Initiation Protocol (SIP) in
      support for the European Telecommunications Standards Institute
         (ETSI) Next Generation Network (NGN) simulation services
                draft-jesske-sipping-tispan-requirements-01


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet- Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 24, 2005.

   Copyright Notice

   Copyright (C) The Internet Society (2005).





Abstract


Jesske, et al.        Expires -  December 2005                 [Page 1]


Internet-Draft       Input reqs. to SIP for ETSI NGN           June 2005



   This document describes a set of requirements to the Session
   Initiation Protocol (SIP) [1] in support for simulation services
   provided in the context of ETSI Next Generation Networks (NGN).
   These requirements should help to find SIP solutions to provide the
   services described within this document.

Table of Contents

   1. Overview
   2. Requirements for supporting simulation services within SIP
      2.1 Simulation Services supported by TISPAN in Release1
      2.2 Requirements to support the TISPAN Simulation Services.
   3. Requirements with existing solutions
   4. Security Considerations
   5. IANA Considerations


1. Overview

   The European Telecommunications Standards Institute (ETSI)
   Telecommunications and Internet converged Services and Protocols for
   Advanced Networking (TISPAN) is defining the release 1 of the TISPAN
   Next Generation Network (NGN). Generally NGN is largely based on the
   3rd Generation mobile Partnership Project (3GPP) IP Multimedia
   Subsystem (IMS) Release 7.

   The TISPAN NGN project has selected SIP profiled by 3GPP TS 24.229
   [26] for the IMS as the protocol used to establish and tear down
   multimedia sessions in the context of NGN. The goal for TISPAN is
   that only one IMS core specification is defined for both wire-line
   and wire-less multimedia applications.

   While defining multimedia applications it is also needed to support
   existing Integrated Services Digital Network and Public Switched
   Telephone Network (ISDN/PSTN) supplementary services based on IMS. We
   refer to supplementary services provided with SIP in the context of
   NGN as 'simulation services'. They are referred to as simulation
   services because they need to be adapted to be provided with SIP, so
   small variations are expected when compared with the equivalent
   ISDN/PSTN supplementary service. The 3GPP TS 24.229 [26] is used to
   simulate the regarding services but to fulfill the requirements
   defined within TISPAN NGN Release 1 some further SIP support is
   needed.

   This document defines some input requirements to support the
   implementation of simulation services. It is generally understood
   that not every requirement listed in this memo will require a SIP


Jesske, et al.        Expires -  December 2005                 [Page 2]


Internet-Draft       Input reqs. to SIP for ETSI NGN           June 2005


   extension. A companion Internet Draft analyses possible
   implementations of these requirements and explores different
   extensions when those are needed.

   All mentioned 3GPP and ETSI Standards are free available under
   http://pda.etsi.org/pda/queryform.asp and
   http://www.3gpp.org/ftp/Specs/html-info/

   The resulting work of this collaboration will eventually be
   contributed to International Telecommunication Union -
   Telecommunication Standardization Sector (ITU-T) as part of their NGN
   work to have an alignment between the work of the standardization
   organizations.

2. Requirements for supporting simulation services within SIP

2.1 Simulation Services supported by TISPAN in Release 1

   The following simulation services are supported by ETSI NGN Release
   1:

   -Communications DIVersion (CDIV). This simulation service allows the
   diversion of communications and the regarding service interworking
   with the PSTN/ISDN. The service comprises the equivalent PSTN/ISDN
   supplementary service for Call Forwarding Unconditional (CFU), Call
   Forwarding Busy (CFB), Call Forwarding on No Reply (CFNR), and Call
   Deflection (CD). The CFU supplementary service is described in ETSI
   EN 300 200 [7]. The CFB supplementary service is described in ETSI EN
   300 199 [8]. The CFNR supplementary service is described in ETSI EN
   300 201 [9]. The CD supplementary service is described in ETSI EN 300
   202 [10].

   - Incoming Communication Barring (ICB). This simulation service
   allows a user to block incoming communications based on the identity
   of the caller. The Call Barring supplementary service is described in
   ETSI ETS 300 520 [22].

   - CONFerence (CONF). This simulation service provides the possibility
   to hold centralized conferences with 3 or more users. The CONF
   supplementary service is described in ETSI ETS 300 183 [14].

   - Message Waiting Indication (MWI). This simulation service provides
   the user with information about the status of a
   voice/video/multimedia mailbox. The MWI supplementary service is
   described in ETSI EN 300 650 [19].

   - Originating Indication Presentation (OIP)/Originating Indication
   Restriction (OIR). These simulation services support the presentation
   or restriction of the caller's identity to the callee. They are the


Jesske, et al.        Expires -  December 2005                 [Page 3]


Internet-Draft       Input reqs. to SIP for ETSI NGN           June 2005


   simulation of the ISDN/PSTN Calling Line Identification
   Presentation/Restriction (CLIP/CLIR) supplementary services. The CLIP
   supplementary service is described in ETSI EN 300 089 [5]. The CLIR
   supplementary service is described in ETSI EN 300 090 [6].

   - Terminating Indication Presentation (TIP)/Terminating Indication
   Restriction (TIR). These simulation services support the presentation
   or restriction of callee's identity to the caller. They are the
   simulation of the ISDN/PSTN Connected Line Identification
   Presentation/Restriction (COLP/COLR) supplementary services. The COLP
   supplementary service is described in ETSI EN 300 094 [23]. The COLR
   supplementary service is described in ETSI EN 300 095 [24].


   - Communication Waiting (CW). This simulation service provides the
   ability of the callee to be informed at the time a communication is
   coming in, and that no resources are available for that incoming
   communication. The callee has then the choice of accepting, rejecting
   or ignoring the incoming communication. The caller will be informed
   that his communication is waiting. The CW supplementary service is
   described in ETSI ETS 300 056 [11].

   - Communication HOLD (HOLD). This simulation service supports the
   possibility of suspending the communication (on hold) while for
   example another communication with another user is to be done. The CW
   supplementary service is described in ETSI ETS 300 139 [12].

   - Anonymous Communication Rejection (ACR). This simulation service
   allows a user to reject incoming communications when the caller is
   anonymous. The ACR supplementary service is described in ETSI EN 300
   798 [21].

   - Advice of Charge (AoC). This simulation service allows the caller
   to request the displaying of tariff information related to the
   communication. The service can operate at setup time (AoC-S), during
   a session (AoC-D), or at the end of it (AoC-E). The AoC-S
   supplementary service is described in ETSI ETS 300 178 [16]. The
   AoC-D supplementary service is described in ETSI ETS 300 179 [17].
   The AoC-E supplementary service is described in ETSI ETS 300 180
   [18].

   - Communication Completion on Busy Subscriber (CCBS). This simulation
   service supports the ability of a caller to complete a requested
   communication to a busy callee without having to make a new
   communication attempt when the callee becomes not busy anymore. It is
   possible for the caller to request several communications to be under
   the CCBS requested status. Also the callee can be subject to several
   CCBS communications from different callers. Additionally, the service
   provides queue management to arbitrate several CCBS requests to the


Jesske, et al.        Expires -  December 2005                 [Page 4]


Internet-Draft       Input reqs. to SIP for ETSI NGN           June 2005


   same callee. The CCBS supplementary service is described in ETSI EN
   300 357 [15].

   - Communication Completion on no Reply (CCNR). This simulation
   service supports the ability of the caller to complete a requested
   communication to a callee without having to make a new communication
   attempt when the callee showed activity (a communication attempt was
   done). The CCNR supplementary service is described in ETSI EN 301 134
   [25].

   - Malicious Communication IDentification (MCID). This simulation
   service enables the callee to indicate that an incoming communication
   is considered to be malicious and it should be identified and
   registered. The MCID supplementary service is described in ETSI ETS
   300 128 [13].

   - Explicit Communication Transfer (ECT). This simulation service
   allows the user having two separate sessions to connect the other two
   users together into a single session. The ECT supplementary service
   is described in ETSI EN 300 367 [20].


2.2 Requirements to support the TISPAN Simulation Services.

   [REQ-GEN-1]
   For all simulation services interoperability with the PSTN/ISDN is
   needed. Solutions that support the following requirements must
   interwork with the corresponding PSTN/ISDN supplementary service.

   [REQ-ACR-1]
   The ACR simulation service requires the caller to be informed that
   the communication was rejected due to this service. This is needed to
   inform the upstream elements (UAC, e.g., a PSTN/ISDN gateway) about
   the reason for the rejection.

   [REQ-ACR-2]
   It must be possible that authorized callers are not subject to the
   ACR service, thus, allowing the callee to receive anonymous requests
   from authorized callers. This effectively requires a mechanism to
   override the ACR service depending on the identity and authorization
   of the caller.

   This is needed, e.g., for when a police officer or any other
   authority is anonymously calling to a user having the ACR simulation
   service enabled.

   [REQ-TIP-1]
   For supporting the TIP/TIR service when a communication is
   interworking with SIP-based Private Branch Exchanges (PBX) a


Jesske, et al.        Expires -  December 2005                 [Page 5]


Internet-Draft       Input reqs. to SIP for ETSI NGN           June 2005


   mechanism is required whereby the private extension of a PBX user is
   conveyed to the caller. This allows the caller to call back the PBX
   user directly.

   For example a user calling a PBX desk (e.g., +49 6151 83 0000 for
   Deutsche Telekom in Darmstadt) will be forwarded to an Extension
   (e.g., +49 6151 83 5940 for Roland Jesske). It is required that the
   caller gets the latter identity, which is allocated to the callee.

   [REQ-TIP-2]
   The identity mentioned in REQ-TIP-1 has to be backwards compatible
   with the SIP identity described within RFC 3325 [4].

   [REQ-AoC-1]
   In order to support the AoC simulation service, a mechanism is needed
   whereby the caller can invoke the AoC simulation service in a given
   communication. This invocation is sent when initializing the
   communication.

   [REQ-AoC-2]
   As part of the AoC simulation service a mechanism is needed to
   asynchronously transport the charging information. This information
   will be displayed to the requesting user.

   Asynchronously transport means that the information shall be
   transported at any time during and after (e.g., within a certain
   period of time) the communication, but within the session context,
   when it is needed.

   [REQ-CCBS-1]
   In order to assure that end to end functionality of the CCBS service
   is possible, it is required that the UAC gets knowledge of the
   availability of the CCBS service at the UAS or the PSTN/ISDN terminal
   on a communication by communication basis.

   [REQ-CCBS-2]
   The entity providing the CCBS service needs to know the change of the
   status of a UAS (e.g., a transition from busy to idle) and it should
   have the ability to recognize if the UAS is able to provide such
   indication.

   [REQ-CCBS-3]
   The CCBS simulation service should be able to handle queues and
   arbitrate multiple simultaneous CCBS requests according to a locally
   defined policy (e.g., first in first out).

   [REQ-CCBS-4]
   It should be also possible for CCBS request initiators to suspend,
   resume and cancel their pending CCBS requests.


Jesske, et al.        Expires -  December 2005                 [Page 6]


Internet-Draft       Input reqs. to SIP for ETSI NGN           June 2005



   [REQ-CCNR-1]
   In order to assure that end to end functionality of the CCNR service
   is possible, it is required that the UAC gets knowledge of the
   availability of the CCNR service at the UAS or the PSTN/ISDN terminal
   on a communication by communication basis.

   [REQ-CCNR-2]
   The entity providing the CCNR service needs to know the change of the
   status of a UAS (e.g., a transition from idle to another state) and
   it should have the ability to recognize if the UAS is able to provide
   such indication.

   [REQ-CCNR-3]
   The CCNR simulation service should be able to handle queues and
   arbitrate multiple simultaneous CCNR requests according to a locally
   defined policy (e.g., first in first out).

   [REQ-CCNR-4]
   It should be also possible for CCNR request initiators to suspend,
   resume and cancel their pending CCNR requests.

   [REQ-MCID-1]
   In order to support the MCID simulation service there must be a
   mechanism whereby a user can provide an indication that an incoming
   request or session is considered to be malicious. The user can
   provide this indication at the start, during or within a certain time
   after a session or request.

   Note: The requirement reads about the ability of the callee to
   provide an indication of malicious call, but there is no requirement
   to supply the caller's identity to the called.

   [REQ-MCID-2]
   For interoperability reasons, the MCID simulation service logic needs
   to get the knowledge that, even if the originator identity is missing
   in the signalling, it can available upon request. This is due to,
   e.g., interworking with the PSTN network, where, in some cases, the
   originator's identity is only available upon explicit request. The
   information can be received asynchronously in a timeframe of 1-30
   seconds even after the session has been closed.


   [REQ-CW-1]
   To implement the CW simulation service, ETSI envisages the usage of
   an application server that detects some busy conditions on behalf of
   the user. To support this scenario a mechanism is required to inform
   the callee that a communication is waiting.



Jesske, et al.        Expires -  December 2005                 [Page 7]


Internet-Draft       Input reqs. to SIP for ETSI NGN           June 2005


   [REQ-CW-2]
   It must be possible for CW to inform the caller that an application
   server is holding the communication  until the callee is available.

   [REQ-CDIV-1]
   To support the CDIV simulation service it is required that the caller
   is informed if a communication diversion takes place.

   [REQ-CDIV-2]
   To support the CDIV simulation service a mechanism that shows or
   restrict the indication of the diverting user is required.

   [REQ-CDIV-3]
   To support the CDIV simulation service it is required that the reason
   of the redirection is delivered to the caller and callee.

   [REQ-CDIV-4]
   For interoperability reasons and service compatibility with the CDIV
   simulation service, it is required that the history of the
   communication is sent in forward and backward directions to the
   caller and callee, respectively.

   [REQ-CAT-1]
   For service applicability to special groups and interoperability with
   the PSTN/ISDN an indication of the originating party category is
   needed. This is needed due to the fact that some services apply a
   special behavior to special user groups (e.g., like Pay-Phones).

   [REQ-CAT-2]
   The originating party category referred to in REQ-CAT-1 must be
   inserted by a trusted entity.


4. Security Considerations

   The requirements in this document are intended to result in a
   mechanism with general applicability for ETSI NGN and are generally
   not applicable to the public Internet.

   Use of these mechanisms in any other context has serious security
   shortcomings, namely there is absolutely no guarantee that the
   information has not been modified, or was even correct in the first
   place.

5. IANA Considerations

   This document does not have any implications for IANA.




Jesske, et al.        Expires -  December 2005                 [Page 8]


Internet-Draft       Input reqs. to SIP for ETSI NGN           June 2005





References

   [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
      Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
      Session Initiation Protocol", RFC 3261, June 2002.

   [2] Barnes, M. "An Extension to the Session Initiation Protocol for
      Request History Information", draft-ietf-sip-history-info-06.txt,
      January 17, 2005.

   [3] Elwell, J.; "SIP Reason header extension for indicating
      redirection reasons", draft-elwell-sipping-redirection-reason-
      02.txt, June 2005.

   [4] Jennings, C., Peterson, J. and M. Watson, "Private Extensions to
      the Session Initiation Protocol (SIP) for Asserted Identity within
      Trusted Networks", RFC 3325, November 2002.

   [5] ETSI EN 300 089 (V3.1.1): "Integrated Services Digital Network
      (ISDN); Calling Line Identification Presentation (CLIP)
      supplementary service; Service description".

   [6] ETSI EN 300 090 (V1.2.1): "Integrated Services Digital Network
      (ISDN); Calling Line Identification Restriction (CLIR)
      supplementary service; Service description".

   [7] ETSI EN 300 200 (Edition 1): "Integrated Services Digital Network
      (ISDN); Call Forwarding Unconditional (CFU) supplementary service;
      Service description".

   [8] ETSI EN 300 199 (V1.2.1): "Integrated Services Digital Network
      (ISDN); Call Forwarding Busy (CFB) supplementary service; Service
      description".

   [9] ETIS EN 300 201 (V1.2.1): "Integrated Services Digital Network
      (ISDN); Call Forwarding No Reply (CFNR) supplementary service;
      Service description".

   [10] ETSI ETS 300 202 (Edition 1): "Integrated Services Digital
      Network (ISDN); Call Deflection (CD) supplementary service;
      Service description".

   [11] ETSI ETS 300 056 (Edition 1): "Integrated Services Digital
      Network (ISDN); Call Waiting (CW) supplementary service; Service
      description".



Jesske, et al.        Expires -  December 2005                 [Page 9]


Internet-Draft       Input reqs. to SIP for ETSI NGN           June 2005


   [12] ETSI ETS 300 139 (Edition 1): "Integrated Services Digital
      Network (ISDN); Call Hold (HOLD) supplementary service; Service
      description".

   [13] ETSI ETS 300 128 (Edition 1): "Integrated Services Digital
      Network (ISDN); Malicious Call Identification (MCID) supplementary
      service; Service description".

   [14] ETSI ETS 300 183 (Edition 1): "Integrated Services Digital
      Network (ISDN); Conference call, add-on (CONF) supplementary
      service; Service description".

   [15] ETSI EN 300 357 (V1.2.1): "Integrated Services Digital Network
      (ISDN); Completion of Calls to Busy Subscriber (CCBS)
      supplementary service; Service description".

   [16] ETSI ETS 300 178 (Edition 1): "Integrated Services Digital
      Network (ISDN); Advice of Charge: charging information at call
      set-up time (AOC-S) supplementary service; Service description".

   [17] ETSI ETS 300 179 (Edition 1): "Integrated Services Digital
      Network (ISDN); Advice of Charge: charging information during the
      call (AOC-D) supplementary service; Service description".

   [18] ETSI ETS 300 180 (Edition 1): "Integrated Services Digital
      Network (ISDN); Advice of Charge: charging information at the end
      of the call (AOC-E) supplementary service; Service description".

   [19] ETSI EN 300 650 (V1.2.1): "Integrated Services Digital Network
      (ISDN); Message Waiting Indication (MWI) supplementary service;
      Service description".

   [20] ETSI EN 300 367 (V1.2.1): "Integrated Services Digital Network
      (ISDN); Explicit Call Transfer (ECT) supplementary service;
      Service description".

   [21] ETSI EN 301 798 (V1.1.1): "Services and Protocols for Advanced
      Networks (SPAN); Anonymous Call Rejection (ACR) Supplementary
      Service; Service description".

   [22] ETSI ETS 300 520: "European digital cellular telecommunications
      system (Phase 2); Call Barring (CB) supplementary services; Stage
      1 (GSM 02.88)".

   [23] ETSI EN 300 094: "Integrated Services Digital Network (ISDN);
      Connected Line Identification Presentation (COLP) supplementary
      service; Service description".




Jesske, et al.        Expires -  December 2005                 [Page 10]


Internet-Draft       Input reqs. to SIP for ETSI NGN           June 2005


   [24] ETSI ETS 300 095: "Integrated Services Digital Network (ISDN);
      Connected Line Identification Restriction (COLR) supplementary
      service; Service description".

   [25] ETSI EN 301 134: "Integrated Services Digital Network (ISDN);
      Completion of Calls on No Reply (CCNR) supplementary service;
      Service description".

   [26] 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on
      SIP and SDP".



Contributors
      Keith Drage
      GSM OPTIMUS HOUSE
      SN5 6PP SWINDON
      United Kingdom
      Phone: +44 1793 897312
      Email: drage@lucent.com

      Sebastien Garcin
      France Telecom
      38-40, Rue du General Leclerc
      92130 Issy Les Moulineaux
      France


Acknowledgments

   The authors would like to thank Anna Martinez people of ETSI TISPAN
   WG3 for their comments.


Author's Addresses

      Roland Jesske
      Deutsche Telekom
      Am Kavalleriesand 3
      64307 Darmstadt
      Germany
      Phone: +496151835940
      Email: r.jesske@t-com.net

      Denis Alexeitsev
      Deutsche Telekom
      Am Kavalleriesand 3
      64307 Darmstadt
      Germany


Jesske, et al.        Expires -  December 2005                 [Page 11]


Internet-Draft       Input reqs. to SIP for ETSI NGN           June 2005


      Phone: +496151832130
      Email: d.alexeitsev@t-com.net

      Miguel A. Garcia-Martin
      Nokia
      P.O. Box 407
      NOKIA GROUP, FIN 00045
      Finland

      EMail: miguel.an.garcia@nokia.com

Full Copyright Statement

   Copyright (C) The Internet Society (2005).

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

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

   Intellectual Property

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

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

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement



Jesske, et al.        Expires -  December 2005                 [Page 12]


Internet-Draft       Input reqs. to SIP for ETSI NGN           June 2005


   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.












































Jesske, et al.        Expires -  December 2005                 [Page 13]