One document matched: draft-jesske-sipping-tispan-requirements-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 02:00:13 |