idnits 2.17.1 draft-jesske-sipping-tispan-requirements-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 542. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 553. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 560. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 566. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 333 has weird spacing: '...ication until...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 14, 2005) is 6892 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'REQ-GEN-1' on line 209 -- Looks like a reference, but probably isn't: 'REQ-ACR-1' on line 214 -- Looks like a reference, but probably isn't: 'REQ-ACR-2' on line 220 -- Looks like a reference, but probably isn't: 'REQ-TIP-1' on line 231 -- Looks like a reference, but probably isn't: 'REQ-TIP-2' on line 243 -- Looks like a reference, but probably isn't: 'REQ-AoC-1' on line 247 -- Looks like a reference, but probably isn't: 'REQ-AoC-2' on line 253 -- Looks like a reference, but probably isn't: 'REQ-CCBS-1' on line 263 -- Looks like a reference, but probably isn't: 'REQ-CCBS-2' on line 269 -- Looks like a reference, but probably isn't: 'REQ-CCBS-3' on line 275 -- Looks like a reference, but probably isn't: 'REQ-CCBS-4' on line 280 -- Looks like a reference, but probably isn't: 'REQ-CCNR-1' on line 284 -- Looks like a reference, but probably isn't: 'REQ-CCNR-2' on line 290 -- Looks like a reference, but probably isn't: 'REQ-CCNR-3' on line 296 -- Looks like a reference, but probably isn't: 'REQ-CCNR-4' on line 301 -- Looks like a reference, but probably isn't: 'REQ-MCID-1' on line 305 -- Looks like a reference, but probably isn't: 'REQ-MCID-2' on line 316 -- Looks like a reference, but probably isn't: 'REQ-CW-1' on line 325 -- Looks like a reference, but probably isn't: 'REQ-CW-2' on line 331 -- Looks like a reference, but probably isn't: 'REQ-CDIV-1' on line 335 -- Looks like a reference, but probably isn't: 'REQ-CDIV-2' on line 339 -- Looks like a reference, but probably isn't: 'REQ-CDIV-3' on line 343 -- Looks like a reference, but probably isn't: 'REQ-CDIV-4' on line 347 -- Looks like a reference, but probably isn't: 'REQ-CAT-1' on line 353 -- Looks like a reference, but probably isn't: 'REQ-CAT-2' on line 359 == Unused Reference: '2' is defined on line 384, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 388, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 3325 (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' -- Possible downref: Non-RFC (?) normative reference: ref. '20' -- Possible downref: Non-RFC (?) normative reference: ref. '21' -- Possible downref: Non-RFC (?) normative reference: ref. '22' -- Possible downref: Non-RFC (?) normative reference: ref. '23' -- Possible downref: Non-RFC (?) normative reference: ref. '24' -- Possible downref: Non-RFC (?) normative reference: ref. '25' -- Possible downref: Non-RFC (?) normative reference: ref. '26' Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 55 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Sipping Working Group Roland Jesske 2 Internet Draft Deutsche Telekom 3 Expires: December 13, 2005 Denis Alexeitsev 4 Deutsche Telekom 5 Miguel Garcia-Martin 6 Nokia 7 June 14, 2005 9 Input Requirements for the Session Initiation Protocol (SIP) in 10 support for the European Telecommunications Standards Institute 11 (ETSI) Next Generation Network (NGN) simulation services 12 draft-jesske-sipping-tispan-requirements-01 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet- Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 24, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 43 This document describes a set of requirements to the Session 44 Initiation Protocol (SIP) [1] in support for simulation services 45 provided in the context of ETSI Next Generation Networks (NGN). 46 These requirements should help to find SIP solutions to provide the 47 services described within this document. 49 Table of Contents 51 1. Overview 52 2. Requirements for supporting simulation services within SIP 53 2.1 Simulation Services supported by TISPAN in Release1 54 2.2 Requirements to support the TISPAN Simulation Services. 55 3. Requirements with existing solutions 56 4. Security Considerations 57 5. IANA Considerations 59 1. Overview 61 The European Telecommunications Standards Institute (ETSI) 62 Telecommunications and Internet converged Services and Protocols for 63 Advanced Networking (TISPAN) is defining the release 1 of the TISPAN 64 Next Generation Network (NGN). Generally NGN is largely based on the 65 3rd Generation mobile Partnership Project (3GPP) IP Multimedia 66 Subsystem (IMS) Release 7. 68 The TISPAN NGN project has selected SIP profiled by 3GPP TS 24.229 69 [26] for the IMS as the protocol used to establish and tear down 70 multimedia sessions in the context of NGN. The goal for TISPAN is 71 that only one IMS core specification is defined for both wire-line 72 and wire-less multimedia applications. 74 While defining multimedia applications it is also needed to support 75 existing Integrated Services Digital Network and Public Switched 76 Telephone Network (ISDN/PSTN) supplementary services based on IMS. We 77 refer to supplementary services provided with SIP in the context of 78 NGN as 'simulation services'. They are referred to as simulation 79 services because they need to be adapted to be provided with SIP, so 80 small variations are expected when compared with the equivalent 81 ISDN/PSTN supplementary service. The 3GPP TS 24.229 [26] is used to 82 simulate the regarding services but to fulfill the requirements 83 defined within TISPAN NGN Release 1 some further SIP support is 84 needed. 86 This document defines some input requirements to support the 87 implementation of simulation services. It is generally understood 88 that not every requirement listed in this memo will require a SIP 89 extension. A companion Internet Draft analyses possible 90 implementations of these requirements and explores different 91 extensions when those are needed. 93 All mentioned 3GPP and ETSI Standards are free available under 94 http://pda.etsi.org/pda/queryform.asp and 95 http://www.3gpp.org/ftp/Specs/html-info/ 97 The resulting work of this collaboration will eventually be 98 contributed to International Telecommunication Union - 99 Telecommunication Standardization Sector (ITU-T) as part of their NGN 100 work to have an alignment between the work of the standardization 101 organizations. 103 2. Requirements for supporting simulation services within SIP 105 2.1 Simulation Services supported by TISPAN in Release 1 107 The following simulation services are supported by ETSI NGN Release 108 1: 110 -Communications DIVersion (CDIV). This simulation service allows the 111 diversion of communications and the regarding service interworking 112 with the PSTN/ISDN. The service comprises the equivalent PSTN/ISDN 113 supplementary service for Call Forwarding Unconditional (CFU), Call 114 Forwarding Busy (CFB), Call Forwarding on No Reply (CFNR), and Call 115 Deflection (CD). The CFU supplementary service is described in ETSI 116 EN 300 200 [7]. The CFB supplementary service is described in ETSI EN 117 300 199 [8]. The CFNR supplementary service is described in ETSI EN 118 300 201 [9]. The CD supplementary service is described in ETSI EN 300 119 202 [10]. 121 - Incoming Communication Barring (ICB). This simulation service 122 allows a user to block incoming communications based on the identity 123 of the caller. The Call Barring supplementary service is described in 124 ETSI ETS 300 520 [22]. 126 - CONFerence (CONF). This simulation service provides the possibility 127 to hold centralized conferences with 3 or more users. The CONF 128 supplementary service is described in ETSI ETS 300 183 [14]. 130 - Message Waiting Indication (MWI). This simulation service provides 131 the user with information about the status of a 132 voice/video/multimedia mailbox. The MWI supplementary service is 133 described in ETSI EN 300 650 [19]. 135 - Originating Indication Presentation (OIP)/Originating Indication 136 Restriction (OIR). These simulation services support the presentation 137 or restriction of the caller's identity to the callee. They are the 138 simulation of the ISDN/PSTN Calling Line Identification 139 Presentation/Restriction (CLIP/CLIR) supplementary services. The CLIP 140 supplementary service is described in ETSI EN 300 089 [5]. The CLIR 141 supplementary service is described in ETSI EN 300 090 [6]. 143 - Terminating Indication Presentation (TIP)/Terminating Indication 144 Restriction (TIR). These simulation services support the presentation 145 or restriction of callee's identity to the caller. They are the 146 simulation of the ISDN/PSTN Connected Line Identification 147 Presentation/Restriction (COLP/COLR) supplementary services. The COLP 148 supplementary service is described in ETSI EN 300 094 [23]. The COLR 149 supplementary service is described in ETSI EN 300 095 [24]. 151 - Communication Waiting (CW). This simulation service provides the 152 ability of the callee to be informed at the time a communication is 153 coming in, and that no resources are available for that incoming 154 communication. The callee has then the choice of accepting, rejecting 155 or ignoring the incoming communication. The caller will be informed 156 that his communication is waiting. The CW supplementary service is 157 described in ETSI ETS 300 056 [11]. 159 - Communication HOLD (HOLD). This simulation service supports the 160 possibility of suspending the communication (on hold) while for 161 example another communication with another user is to be done. The CW 162 supplementary service is described in ETSI ETS 300 139 [12]. 164 - Anonymous Communication Rejection (ACR). This simulation service 165 allows a user to reject incoming communications when the caller is 166 anonymous. The ACR supplementary service is described in ETSI EN 300 167 798 [21]. 169 - Advice of Charge (AoC). This simulation service allows the caller 170 to request the displaying of tariff information related to the 171 communication. The service can operate at setup time (AoC-S), during 172 a session (AoC-D), or at the end of it (AoC-E). The AoC-S 173 supplementary service is described in ETSI ETS 300 178 [16]. The 174 AoC-D supplementary service is described in ETSI ETS 300 179 [17]. 175 The AoC-E supplementary service is described in ETSI ETS 300 180 176 [18]. 178 - Communication Completion on Busy Subscriber (CCBS). This simulation 179 service supports the ability of a caller to complete a requested 180 communication to a busy callee without having to make a new 181 communication attempt when the callee becomes not busy anymore. It is 182 possible for the caller to request several communications to be under 183 the CCBS requested status. Also the callee can be subject to several 184 CCBS communications from different callers. Additionally, the service 185 provides queue management to arbitrate several CCBS requests to the 186 same callee. The CCBS supplementary service is described in ETSI EN 187 300 357 [15]. 189 - Communication Completion on no Reply (CCNR). This simulation 190 service supports the ability of the caller to complete a requested 191 communication to a callee without having to make a new communication 192 attempt when the callee showed activity (a communication attempt was 193 done). The CCNR supplementary service is described in ETSI EN 301 134 194 [25]. 196 - Malicious Communication IDentification (MCID). This simulation 197 service enables the callee to indicate that an incoming communication 198 is considered to be malicious and it should be identified and 199 registered. The MCID supplementary service is described in ETSI ETS 200 300 128 [13]. 202 - Explicit Communication Transfer (ECT). This simulation service 203 allows the user having two separate sessions to connect the other two 204 users together into a single session. The ECT supplementary service 205 is described in ETSI EN 300 367 [20]. 207 2.2 Requirements to support the TISPAN Simulation Services. 209 [REQ-GEN-1] 210 For all simulation services interoperability with the PSTN/ISDN is 211 needed. Solutions that support the following requirements must 212 interwork with the corresponding PSTN/ISDN supplementary service. 214 [REQ-ACR-1] 215 The ACR simulation service requires the caller to be informed that 216 the communication was rejected due to this service. This is needed to 217 inform the upstream elements (UAC, e.g., a PSTN/ISDN gateway) about 218 the reason for the rejection. 220 [REQ-ACR-2] 221 It must be possible that authorized callers are not subject to the 222 ACR service, thus, allowing the callee to receive anonymous requests 223 from authorized callers. This effectively requires a mechanism to 224 override the ACR service depending on the identity and authorization 225 of the caller. 227 This is needed, e.g., for when a police officer or any other 228 authority is anonymously calling to a user having the ACR simulation 229 service enabled. 231 [REQ-TIP-1] 232 For supporting the TIP/TIR service when a communication is 233 interworking with SIP-based Private Branch Exchanges (PBX) a 234 mechanism is required whereby the private extension of a PBX user is 235 conveyed to the caller. This allows the caller to call back the PBX 236 user directly. 238 For example a user calling a PBX desk (e.g., +49 6151 83 0000 for 239 Deutsche Telekom in Darmstadt) will be forwarded to an Extension 240 (e.g., +49 6151 83 5940 for Roland Jesske). It is required that the 241 caller gets the latter identity, which is allocated to the callee. 243 [REQ-TIP-2] 244 The identity mentioned in REQ-TIP-1 has to be backwards compatible 245 with the SIP identity described within RFC 3325 [4]. 247 [REQ-AoC-1] 248 In order to support the AoC simulation service, a mechanism is needed 249 whereby the caller can invoke the AoC simulation service in a given 250 communication. This invocation is sent when initializing the 251 communication. 253 [REQ-AoC-2] 254 As part of the AoC simulation service a mechanism is needed to 255 asynchronously transport the charging information. This information 256 will be displayed to the requesting user. 258 Asynchronously transport means that the information shall be 259 transported at any time during and after (e.g., within a certain 260 period of time) the communication, but within the session context, 261 when it is needed. 263 [REQ-CCBS-1] 264 In order to assure that end to end functionality of the CCBS service 265 is possible, it is required that the UAC gets knowledge of the 266 availability of the CCBS service at the UAS or the PSTN/ISDN terminal 267 on a communication by communication basis. 269 [REQ-CCBS-2] 270 The entity providing the CCBS service needs to know the change of the 271 status of a UAS (e.g., a transition from busy to idle) and it should 272 have the ability to recognize if the UAS is able to provide such 273 indication. 275 [REQ-CCBS-3] 276 The CCBS simulation service should be able to handle queues and 277 arbitrate multiple simultaneous CCBS requests according to a locally 278 defined policy (e.g., first in first out). 280 [REQ-CCBS-4] 281 It should be also possible for CCBS request initiators to suspend, 282 resume and cancel their pending CCBS requests. 284 [REQ-CCNR-1] 285 In order to assure that end to end functionality of the CCNR service 286 is possible, it is required that the UAC gets knowledge of the 287 availability of the CCNR service at the UAS or the PSTN/ISDN terminal 288 on a communication by communication basis. 290 [REQ-CCNR-2] 291 The entity providing the CCNR service needs to know the change of the 292 status of a UAS (e.g., a transition from idle to another state) and 293 it should have the ability to recognize if the UAS is able to provide 294 such indication. 296 [REQ-CCNR-3] 297 The CCNR simulation service should be able to handle queues and 298 arbitrate multiple simultaneous CCNR requests according to a locally 299 defined policy (e.g., first in first out). 301 [REQ-CCNR-4] 302 It should be also possible for CCNR request initiators to suspend, 303 resume and cancel their pending CCNR requests. 305 [REQ-MCID-1] 306 In order to support the MCID simulation service there must be a 307 mechanism whereby a user can provide an indication that an incoming 308 request or session is considered to be malicious. The user can 309 provide this indication at the start, during or within a certain time 310 after a session or request. 312 Note: The requirement reads about the ability of the callee to 313 provide an indication of malicious call, but there is no requirement 314 to supply the caller's identity to the called. 316 [REQ-MCID-2] 317 For interoperability reasons, the MCID simulation service logic needs 318 to get the knowledge that, even if the originator identity is missing 319 in the signalling, it can available upon request. This is due to, 320 e.g., interworking with the PSTN network, where, in some cases, the 321 originator's identity is only available upon explicit request. The 322 information can be received asynchronously in a timeframe of 1-30 323 seconds even after the session has been closed. 325 [REQ-CW-1] 326 To implement the CW simulation service, ETSI envisages the usage of 327 an application server that detects some busy conditions on behalf of 328 the user. To support this scenario a mechanism is required to inform 329 the callee that a communication is waiting. 331 [REQ-CW-2] 332 It must be possible for CW to inform the caller that an application 333 server is holding the communication until the callee is available. 335 [REQ-CDIV-1] 336 To support the CDIV simulation service it is required that the caller 337 is informed if a communication diversion takes place. 339 [REQ-CDIV-2] 340 To support the CDIV simulation service a mechanism that shows or 341 restrict the indication of the diverting user is required. 343 [REQ-CDIV-3] 344 To support the CDIV simulation service it is required that the reason 345 of the redirection is delivered to the caller and callee. 347 [REQ-CDIV-4] 348 For interoperability reasons and service compatibility with the CDIV 349 simulation service, it is required that the history of the 350 communication is sent in forward and backward directions to the 351 caller and callee, respectively. 353 [REQ-CAT-1] 354 For service applicability to special groups and interoperability with 355 the PSTN/ISDN an indication of the originating party category is 356 needed. This is needed due to the fact that some services apply a 357 special behavior to special user groups (e.g., like Pay-Phones). 359 [REQ-CAT-2] 360 The originating party category referred to in REQ-CAT-1 must be 361 inserted by a trusted entity. 363 4. Security Considerations 365 The requirements in this document are intended to result in a 366 mechanism with general applicability for ETSI NGN and are generally 367 not applicable to the public Internet. 369 Use of these mechanisms in any other context has serious security 370 shortcomings, namely there is absolutely no guarantee that the 371 information has not been modified, or was even correct in the first 372 place. 374 5. IANA Considerations 376 This document does not have any implications for IANA. 378 References 380 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 381 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 382 Session Initiation Protocol", RFC 3261, June 2002. 384 [2] Barnes, M. "An Extension to the Session Initiation Protocol for 385 Request History Information", draft-ietf-sip-history-info-06.txt, 386 January 17, 2005. 388 [3] Elwell, J.; "SIP Reason header extension for indicating 389 redirection reasons", draft-elwell-sipping-redirection-reason- 390 02.txt, June 2005. 392 [4] Jennings, C., Peterson, J. and M. Watson, "Private Extensions to 393 the Session Initiation Protocol (SIP) for Asserted Identity within 394 Trusted Networks", RFC 3325, November 2002. 396 [5] ETSI EN 300 089 (V3.1.1): "Integrated Services Digital Network 397 (ISDN); Calling Line Identification Presentation (CLIP) 398 supplementary service; Service description". 400 [6] ETSI EN 300 090 (V1.2.1): "Integrated Services Digital Network 401 (ISDN); Calling Line Identification Restriction (CLIR) 402 supplementary service; Service description". 404 [7] ETSI EN 300 200 (Edition 1): "Integrated Services Digital Network 405 (ISDN); Call Forwarding Unconditional (CFU) supplementary service; 406 Service description". 408 [8] ETSI EN 300 199 (V1.2.1): "Integrated Services Digital Network 409 (ISDN); Call Forwarding Busy (CFB) supplementary service; Service 410 description". 412 [9] ETIS EN 300 201 (V1.2.1): "Integrated Services Digital Network 413 (ISDN); Call Forwarding No Reply (CFNR) supplementary service; 414 Service description". 416 [10] ETSI ETS 300 202 (Edition 1): "Integrated Services Digital 417 Network (ISDN); Call Deflection (CD) supplementary service; 418 Service description". 420 [11] ETSI ETS 300 056 (Edition 1): "Integrated Services Digital 421 Network (ISDN); Call Waiting (CW) supplementary service; Service 422 description". 424 [12] ETSI ETS 300 139 (Edition 1): "Integrated Services Digital 425 Network (ISDN); Call Hold (HOLD) supplementary service; Service 426 description". 428 [13] ETSI ETS 300 128 (Edition 1): "Integrated Services Digital 429 Network (ISDN); Malicious Call Identification (MCID) supplementary 430 service; Service description". 432 [14] ETSI ETS 300 183 (Edition 1): "Integrated Services Digital 433 Network (ISDN); Conference call, add-on (CONF) supplementary 434 service; Service description". 436 [15] ETSI EN 300 357 (V1.2.1): "Integrated Services Digital Network 437 (ISDN); Completion of Calls to Busy Subscriber (CCBS) 438 supplementary service; Service description". 440 [16] ETSI ETS 300 178 (Edition 1): "Integrated Services Digital 441 Network (ISDN); Advice of Charge: charging information at call 442 set-up time (AOC-S) supplementary service; Service description". 444 [17] ETSI ETS 300 179 (Edition 1): "Integrated Services Digital 445 Network (ISDN); Advice of Charge: charging information during the 446 call (AOC-D) supplementary service; Service description". 448 [18] ETSI ETS 300 180 (Edition 1): "Integrated Services Digital 449 Network (ISDN); Advice of Charge: charging information at the end 450 of the call (AOC-E) supplementary service; Service description". 452 [19] ETSI EN 300 650 (V1.2.1): "Integrated Services Digital Network 453 (ISDN); Message Waiting Indication (MWI) supplementary service; 454 Service description". 456 [20] ETSI EN 300 367 (V1.2.1): "Integrated Services Digital Network 457 (ISDN); Explicit Call Transfer (ECT) supplementary service; 458 Service description". 460 [21] ETSI EN 301 798 (V1.1.1): "Services and Protocols for Advanced 461 Networks (SPAN); Anonymous Call Rejection (ACR) Supplementary 462 Service; Service description". 464 [22] ETSI ETS 300 520: "European digital cellular telecommunications 465 system (Phase 2); Call Barring (CB) supplementary services; Stage 466 1 (GSM 02.88)". 468 [23] ETSI EN 300 094: "Integrated Services Digital Network (ISDN); 469 Connected Line Identification Presentation (COLP) supplementary 470 service; Service description". 472 [24] ETSI ETS 300 095: "Integrated Services Digital Network (ISDN); 473 Connected Line Identification Restriction (COLR) supplementary 474 service; Service description". 476 [25] ETSI EN 301 134: "Integrated Services Digital Network (ISDN); 477 Completion of Calls on No Reply (CCNR) supplementary service; 478 Service description". 480 [26] 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on 481 SIP and SDP". 483 Contributors 484 Keith Drage 485 GSM OPTIMUS HOUSE 486 SN5 6PP SWINDON 487 United Kingdom 488 Phone: +44 1793 897312 489 Email: drage@lucent.com 491 Sebastien Garcin 492 France Telecom 493 38-40, Rue du General Leclerc 494 92130 Issy Les Moulineaux 495 France 497 Acknowledgments 499 The authors would like to thank Anna Martinez people of ETSI TISPAN 500 WG3 for their comments. 502 Author's Addresses 504 Roland Jesske 505 Deutsche Telekom 506 Am Kavalleriesand 3 507 64307 Darmstadt 508 Germany 509 Phone: +496151835940 510 Email: r.jesske@t-com.net 512 Denis Alexeitsev 513 Deutsche Telekom 514 Am Kavalleriesand 3 515 64307 Darmstadt 516 Germany 517 Phone: +496151832130 518 Email: d.alexeitsev@t-com.net 520 Miguel A. Garcia-Martin 521 Nokia 522 P.O. Box 407 523 NOKIA GROUP, FIN 00045 524 Finland 526 EMail: miguel.an.garcia@nokia.com 528 Full Copyright Statement 530 Copyright (C) The Internet Society (2005). 532 This document is subject to the rights, licenses and restrictions 533 contained in BCP 78, and except as set forth therein, the 534 authorsretain all their rights. 536 This document and the information contained herein are provided on an 537 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 538 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 539 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 540 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 541 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 542 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 544 Intellectual Property 546 The IETF takes no position regarding the validity or scope of any 547 Intellectual Property Rights or other rights that might be claimed to 548 pertain to the implementation or use of the technology described in 549 this document or the extent to which any license under such rights 550 might or might not be available; nor does it represent that it has 551 made any independent effort to identify any such rights. Information 552 on the procedures with respect to rights in RFC documents can be 553 found in BCP 78 and BCP 79. 555 Copies of IPR disclosures made to the IETF Secretariat and any 556 assurances of licenses to be made available, or the result of an 557 attempt made to obtain a general license or permission for the use of 558 such proprietary rights by implementers or users of this 559 specification can be obtained from the IETF on-line IPR repository at 560 http://www.ietf.org/ipr. 562 The IETF invites any interested party to bring to its attention any 563 copyrights, patents or patent applications, or other proprietary 564 rights that may cover technology that may be required to implement 565 this standard. Please address the information to the IETF at ietf- 566 ipr@ietf.org. 568 Acknowledgement 570 Funding for the RFC Editor function is currently provided by the 571 Internet Society.