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

Versions: 00 01 02 03 04                                                
          Requirements on SIP for TISPAN simulation services  May 2005


   Sipping
   Internet Draft                                         Jesske Roland
   Document: Document: draft-jesske-sipping-           Deutsche Telekom
   tispan-requirements-00.txt                          Denis Alexeitsev
                                                       Deutsche Telekom
                                                          Miguel Garcia
                                                                  Nokia
   Expires: 24.November 2005                                24.May 2005





          Requirements for the Extensions to the Session Initiation
                  Protocol (SIP) for the TISPAN simulation services



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                 Expires -  November 2005               [Page 1]


          Requirements on SIP for TISPAN simulation services  May 2005



   This document describes a set of requirements and proposed
   extensions for endorsing the Session Initiation Protocol.
   used by the TISPAN NGN Project. These endorsements are needed to be
   included into the 3GPP IMS specification on SIP (TS24.229 [32]) for
   supporting the simulation services.


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. Proposed SIP extensions
      3.1 ACR[REQ-1] and [REQ-2]
      3.2 TIP/TIR [REQ-3]
      3.3 AOC [REQ-4]
      3.4 CCBS [REQ-5]
      3.5 MCID [REQ-6]
      3.6 CW [REQ-7
      3.7 CDIV [REQ-8]
   4. Security Considerations
   5. IANA Considerations


1. Overview
   ETSI TISPAN is defining the release 1 of the TISPAN NGN. Generally
   the TISPAN NGN bases on the 3GPP IMS Release 7 provided by 3GPP in
   2005.
   The TISPAN NGN Project has selected SIP profiled by 3GPP for their
   IMS as the protocol used to establish and tear down multimedia
   sessions in the context of its NGN. One requirement is that the 3GPP
   core SIP defined in TS24.229 [32] shall be used for the TISPAN IMS
   The goal for TISPAN is that only one IMS core specification is
   defined for wire-line and wire-less multimedia applications.
   While defining multimedia applications it is also needed to support
   existing ISDN/PSTN supplementary services based on IMS. These
   services used within the TISPAN IMS are called simulation services,
   because they can not fulfill 100% of the capabilities of the
   ISDN/PSTN equivalent. The 3GPP TS24.229 [32] is used to simulate the
   regarding services but to fulfill the
   requirements defined within TISPAN NGN Release 1 some further SIP
   elements are needed.

   This document defines some Requirements on the simulation services
   with regard to extensions needed in SIP and proposes such SIP
   elements. This document does not define the SIP elements in detail.


Jesske                 Expires -  November 2005               [Page 2]


          Requirements on SIP for TISPAN simulation services  May 2005




2. Requirements for supporting simulation services within SIP

2.1 Simulation Services supported by TISPAN in Release1

   The following services are supported by TISPAN Release 1

   -Communication DIVersion (CDIV). This simulation service allows the
   diversion
    of communications and the regarding service interworking with the
    PSTN/ISDN network.

   -CONFerence (CONF). This simulation service provides the possibility
   to hold conferences with 3 or more users.

   - Message Waiting Indication (MWI). This simulation service supports
   an indication sent to the user to provide him with information about
   the status of a voice/video/multimedia mail box.

   -Originating Indication Presentation (OIP)/Originating Indication
   Restriction (OIR). These simulation services support the
   presentation or restriction of an identity to the terminating user.
   They are the simulation of the ISDN/PSTN CLIP/CLIR services.

   -Terminating Indication Presentation (TIP)/Terminating Indication
   Restriction (TIR). These simulation services support the
   presentation or restriction of a identity of the terminating user to
   the originating user. They are the simulation of the ISDN/PSTN
   COLP/COLR services.

   -Communication Waiting (CW). This simulation service provides the
   ability to the terminating user to be informed at the time a
   communication is coming in, and that no resources are available for
   that incoming communication. The terminating user has then the
   choice of accepting, rejecting or ignoring the incoming
   communication. The originating user will be informed that his
   communication is waiting.

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

   -Anonymous Communication Rejection (ACR). This simulation service
   supports that communications with anonymous originating identity can
   be rejected.

   -Advice of Charge (AoC). This simulation service supports the
   displaying of tariff information to the originating user.


Jesske                 Expires -  November 2005               [Page 3]


          Requirements on SIP for TISPAN simulation services  May 2005



   -Communication Completion on Busy Subscriber (CCBS). This simulation
   service supports the ability to complete a requested communication
   to a user without having to make a new communication attempt when
   the destination B becomes not busy anymore.

   -Communication Completion on non Reply (CCNR). This simulation
   service supports the ability to complete a requested communication
   to a user without having to make a new communication attempt when
   the destination B showed activity (a communication attempt was
   done).

   -Malicious Communication IDentification (MCID). This simulation
   service enables an incoming communication to be identified and
   registered.

   -Concerning the simulation services CONF, MWI, OIP, OIR and HOLD no
   further SIP elements are needed. With regard to the other above
   mentioned services extensions of SIP are needed.

2.2 Requirements to support the TISPAN Simulation Services.

   [REQ-1]
   For supporting the ACR simulation service it is needed inform the
   originating party that the communication was rejected due to this
   service.


   [REQ-2]
   It shall be possible for authorities to override an ACR service
   offered to a terminating user.


   [REQ-3]
   For supporting the seamless interworking of PBX with SIP based PBX
   terminals it is needed to identify the private extension of a PBX
   users. This identity is required for the TIP service.


   [REQ-4]
   For the AoC simulation service a possibility is needed that the AoC
   simulation service is requested by the originating
   user. This request is sent when initializing the communication.

   [REQ-5]
   As part of the AoC simulation service a mechanism is needed to
   asynchronously transport the charging information




Jesske                 Expires -  November 2005               [Page 4]


          Requirements on SIP for TISPAN simulation services  May 2005



   [REQ-6]
   The CCBS simulation service requires specific service logic on both
   the originating and terminating side of the network. This service
   logic is managed by Application Servers. In order to assure that end
   to end functionality of the service is possible, an indication that
   CCBS is possible sent by the terminating side to the originating
   side is required.

   Also additional status information CCBS user busy/free and the
   Service status CCBS Suspend, Recall and Resume for the service is
   required.

   [REQ-7]
   For the MCID simulation service it is needed to request information
   if the
   address of the originating user is missing. It shall be possible to
   request MCID on a per Call basis.
   For interoperability reasons a Request-Response mechanism.

   [REQ-8]
   For CW simulation service it is required that terminating user shall
   be informed that a Communication is
   aiting. It shall be possible to inform the originating user, that
   the
   Communication is a waiting communication.

   [REQ-9]
   For interoperability reasons and service compatibility it is
   required that for CDIV that the call history (forwarding users,
   reasons and number of redirections)shall be send in forward and
   backward direction to the originating and terminating side.
   Additionally it is required that a the originating user may be
   informed if a communication diversion appears and shows or restrict
   the indication of the diverting user.

   [REQ-10]
   For CCNR simulation service it is needed that the terminating side
   can indicate the support of CCNR.
   Also additional status information regarding the CCNR user no-
   reply/busy/free and the Service status CCBS Suspend, Recall and
   Resume is also needed. This is also needed for interoperability
   reasons.

   [REQ-11]
   For TIP the terminating side needes to get the information "TIP
   requested" that the originating side is requesting the TIP service.

   [REQ-12]


Jesske                 Expires -  November 2005               [Page 5]


          Requirements on SIP for TISPAN simulation services  May 2005


   For all simulation services interoperability with the PSTN/ISDN is
   needed.

3. Proposed SIP extensions

The following section could be seen as collected thoughts what
possibilities are given to fulfill the above mentioned requierements.
This section show ideas and the authoe is happy for further proposals.

3.1 ACR[REQ-1] and [REQ-2]

   For this simulation service a privacy indication is needed to
   indicate that the network restricts the P-Asserted-ID and that the
   Reason header can be included in Responses.

3.2 TIP/TIR [REQ-3]

   For this simulation service an additional Identity header is needed
   that is send from the connected SIP user like the From header from
   the originating user.

3.3 AOC [REQ-4]


   For the AOC simulation a P-Header or a XML MIME could be used to
   request a AOC information (tariff information how much a call will
   be billed).

   A MIME has to be defined for providing the Charging information to
   the user.


3.4 CCBS [REQ-5]

   With regard to discussions take place in ETSI TISPAN the following
   approach to propose a CCBS Event Package was discussed:

   Proposed CCBS Event Package

   The CCBS event package aims at managing subscriptions to CCBS
   service, and especially targets queues management, according to the
   previously described mechanism.
   Specifically, the CCBS event package carries the following
   information that concurs to build a subscription target:

   caller : the subscriber to the CCBS service. When the subscription
   is handled by the caller AS on behalf of the actual caller, then
   this information is added to the Event: header as a æcallerÆ



Jesske                 Expires -  November 2005               [Page 6]


          Requirements on SIP for TISPAN simulation services  May 2005


   parameter; while when the caller is directly handling the
   subscription, this parameter can be omitted.

   callee: the user which the caller asked the CCBS service for. It is
   the target user already contained in the To: header

   queue: this information is needed for the CCBS Event Server to know
   whether to put this new subscription in the queue or not. Such
   information is an Event Header parameter.Possible values are
   "true","false", "suspend" (to suspend its place in queue), "resume"
   to resume its place in queue.

   Hence, the CCBS Event: header will look like, for example

   To start CCBS subscription:
      Event: ccbs;queue=true;caller=sip:+390112285111@example.com

   To suspend CCBS service (for instance, if caller is busy ):
      Event: ccbs;queue=suspend;caller= sip:+390112285111@example.com

   To resume CCBS service:
      Event: ccbs;queue=resume;caller= sip:+390112285111@example.com

   Since the main difference between the "ccbs" event package and the
   "dialog" event package lies in the way subscriptions and
   notifications are handled, there is no need to change the contents
   of the XML documents exchanged therein, so CCBS Event Package
   notifications should contain a Dialog Information document,
   according to the same rules described in "draft-ietf-sipping-dialog-
   package-05.txt", for example:

      <?xml version="1.0"?>
      <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                   version="0" state="full"
                   entity="sip:alice@example.com">
        <dialog id="as7d900as8">
          <state>confirmed</state>
        </dialog>
      </dialog-info>

   This allows to "tunnel" Dialog Information documents contained in
   dialog package notifications originated by endpoints into ccbs
   package notifications sent by application server.

   From discussion point of view there are thoughts that the inclusion
   of the allow-event header in all responses is useful for the CCBS
   case to indicate a CCBS possible. This is at the moment not possible
   as mentioned in RFC 3265.



Jesske                 Expires -  November 2005               [Page 7]


          Requirements on SIP for TISPAN simulation services  May 2005



3.5 MCID [REQ-6]

   For MCID an event package shall be defined to request MCID and
   request missing numbers.

   Several solutions are possible like a new event package (as shown
   below) or extending existing event packages or using a XML Mime
   Body.

   Example new Event Package:
   package name: mcid-request-info
     Body Format Syntax
     mcid-request =  mcid-request-line CRLF
      mcid-request-line  = "MCID-Request" HCOLON mcid-request; mcid-
   holding-request
     mcid-request = "MCID requested" / "MCID not requested"
     mcid-holding-status= "holding not provided"/ "holding provided"
     originating-URI = TEL-URI / SIP-URI / SIPS-URI / absolute URI

   package name: mcid-response-info
    Body Format Syntax
     mcid-information = mcid-status-line CRLF
                        [originating-URI CRLF]

      mcid-status-line  = "MCID-Info" HCOLON mcid-info-status; mcid-
   holding-status
     mcid-info-status = "MCID included"/ "MCID not included"
     mcid-holding-status= "holding not provided"/ "holding provided"
     originating-URI = TEL-URI / SIP-URI / SIPS-URI / absoluteURI



3.6 CW [REQ-7]

   For supporting this requirement a P-header or an MIME with XML
   information is needed.

3.7 CDIV [REQ-8]

   For supporting CDIV the approval of the drafts draft-ietf-sip-
   history-info-06 [1] and draft-elwell-sipping-redirection-reason-01
   [2] is needed.


3.8 CCNR [REQ-9]

   For CCNR an event package shall be defined to indicate the CCNR
   status information, call status and possibility of CCNR.


Jesske                 Expires -  November 2005               [Page 8]


          Requirements on SIP for TISPAN simulation services  May 2005


   The same solution as proposed in section 3.4 could be done.

3.9 TIP [REQ-10]

   For indicating that user A wants to have TIP a P-header or an XML-
   MIME is needed.


4. Security Considerations

   The requirements in this document are intended to result in a
   mechanism with general applicability for the NGN TISPAN and NOT on
   the Internet.

   Use of this mechanism in any other context has serious security
   shortcomings, namely that 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.





References

   [1]IETF An Extension to the Session Initiation Protocol for Request
      History Information; draft-ietf-sip-history-info-06.txt; Expires:
      April 21, 2005
   [2]Elwell; "draft-elwell-sipping-redirection-reason-01.txt"; SIP
      Reason header extension for indicating redirection reasons
   [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 ETS 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]ETSI EN 300 201 (V1.2.1): "Integrated Services Digital Network
      (ISDN); Call Forwarding No Reply (CFNR) supplementary service;
      Service description".


Jesske                 Expires -  November 2005               [Page 9]


          Requirements on SIP for TISPAN simulation services  May 2005


   [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".
   [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 186 (Edition 1): "Integrated Services Digital
      Network (ISDN); Three-Party (3PTY) supplementary service; Service
      description".
   [15]ETSI ETS 300 183 (Edition 1): "Integrated Services Digital
      Network (ISDN); Conference call, add-on (CONF) supplementary
      service; Service description".
   [16]ETSI ETS 300 164 (Edition 1): "Integrated Services Digital
      Network (ISDN); Meet-Me Conference (MMC) supplementary service;
      Service description".
   [17]ETSI EN 300 357 (V1.2.1): "Integrated Services Digital Network
      (ISDN); Completion of Calls to Busy Subscriber (CCBS)
      supplementary service; Service description".
   [18]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".
   [19]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".
   [20]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".
   [21]ETSI ETS 300 136 (Edition 1): "Integrated Services Digital
      Network (ISDN); Closed User Group (CUG) supplementary service;
      Service description".
   [22]ETSI EN 300 650 (V1.2.1): "Integrated Services Digital Network
      (ISDN); Message Waiting Indication (MWI) supplementary service;
      Service description".
   [23]ETSI EN 300 062: "Integrated Services Digital Network
      (ISDN);Direct Dialling In (DDI) supplementary service; Service
      Description".
   [24]ETSI EN 300 367 (V1.2.1): "Integrated Services Digital Network
      (ISDN);Explicit Call Transfer (ECT) supplementary service;
      Service description".
   [25]ETSI EN 301 798 (V1.1.1): "Services and Protocols for Advanced
      Networks (SPAN);Anonymous Call Rejection (ACR) Supplementary
      Service; Service description".
   [26]ETSI DTR/AT-030031: "Simultaneous Voice and Text Announcements".


Jesske                 Expires -  November 2005              [Page 10]


          Requirements on SIP for TISPAN simulation services  May 2005


   [27]ETS 300 648 (1997): "Public Switched Telephone Network (PSTN);
      Calling Line Identification Presentation (CLIP) supplementary
      service; Service description".
   [28]EN 300 659-1 (V1.2): "Public Switched Telephone Network (PSTN);
      Subscriber line protocol over the local loop for display (and
      related) services; Part 1: On-hook data transmission".
   [29]EN 300 659-2 (V1.2): "Public Switched Telephone Network (PSTN);
      Subscriber line protocol over the local loop for display (and
      related) services; Part 2: Off-hook data transmission".
   [30]EN 300 659-3 (V1.2): "Public Switched Telephone Network (PSTN);
      Subscriber line protocol over the local loop for display (and
      related) services; Part 3: Data link message and parameter
      codings".
   [31]ETS 300 649 (1997): "Public Switched Telephone Network (PSTN);
   Calling Line Identification Restriction (CLIR) supplementary
   service; Service description".
   [32] 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on
   SIP and SDP".




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



Acknowledgments

   Anna Martinez with comments and editing, the people of TISPAN WG3
   bringing in the comments.


Author's Addresses

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



Jesske                 Expires -  November 2005              [Page 11]


          Requirements on SIP for TISPAN simulation services  May 2005


      Denis Alexeitsev
      Deutsche Telekom
      Am Kavalleriesand 3
      64307 Darmstadt
      Germany
      Phone: +496151832130
      Email: d.alexeitsev@t-com.net

      Miguel Garcia
      NOKIA Corporation
      Itaemerenkatu 11-13
      00180 Helsinki
      Finland
      Phone: +358504804586
      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 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 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



Jesske                 Expires -  November 2005              [Page 12]


          Requirements on SIP for TISPAN simulation services  May 2005


   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.

Acknowledgement

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






































Jesske                 Expires -  November 2005              [Page 13]