idnits 2.17.1 draft-jesske-sipping-tispan-requirements-04.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 643. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 654. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 661. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 667. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 2007) is 6158 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TISPAN NGN requirements to SIP June 2007 4 SIPPING Roland Jesske 5 Internet Draft Denis Alexeitsev 6 Intended Status: private Deutsche Telekom 7 draft-jesske-sipping-tispan-requirements-04 M. Garcia-Martin 8 Nokia 9 Expires: December 2007 June 2007 11 Input Requirements for the Session Initiation Protocol (SIP) in support 12 for the European Telecommunications Standards Institute, draft-jesske- 13 sipping-tispan-requirements-04 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on December 6, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 45 This document describes a set of requirements to the Session 46 Initiation Protocol (SIP) [2] in support for simulation services 47 provided in the context of ETSI Next Generation Networks (NGN). These 48 requirements should help to find SIP solutions to provide the 49 services described within this document. 51 Table of Contents 53 1. Conventions....................................................2 54 2. 2. Overview....................................................2 55 3. Requirements in Support of Simulation Services.................4 56 3.1 General Requirements.......................................4 57 3.2 Anonymous Communication Rejection (ACR)....................5 58 3.3 Terminating Identification Presentation/Restriction (TIP/TIR) 59 ...............................................................5 60 3.4 Advice of Charge (AoC).....................................6 61 3.5 Communication Completion on Busy Subscriber (CCBS) and 62 Communication Completion on no Reply (CCNR)....................7 63 3.6 Malicious Communication Identification (MCID).............10 64 3.7 Communication Waiting (CW)................................10 65 3.8 Communications Diversion (CDIV)...........................11 66 4. Security Considerations.......................................11 67 5. Contributors..................................................11 68 6. Acknowledgments...............................................12 69 7. References....................................................12 70 7.1 . Normative References....................................12 71 7.2 Informational References..................................12 72 8. Authors' Addresses............................................13 73 9. Full Copyright Statement......................................14 74 10. Intellectual Property........................................14 75 11. Acknowledgment...............................................15 77 1. Conventions 79 This document does not specify any protocol of any kind. Therefore, 80 the usage of the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 81 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 82 "OPTIONAL" in this document, as described in RFC-2119 [1], does not 83 apply. 85 2.2. Overview 87 The European Telecommunications Standards Institute (ETSI) 88 Telecommunications and Internet converged Services and Protocols for 89 Advanced Networking (TISPAN) is defining the release 1 of the TISPAN 90 Next Generation Network (NGN) aiming the creation of a multimedia 91 fixed network. Generally NGN is largely based on the 3rd Generation 92 mobile Partnership Project (3GPP) IP Multimedia Subsystem (IMS) 93 Release 7 with additions required to support the fixed access.. 95 The TISPAN NGN project has selected SIP profiled by 3GPP TS 24.229 96 [4] for the IMS as the protocol used to establish and tear down 97 multimedia sessions in the context of NGN. The goal for TISPAN is 98 that only one IMS core specification is defined for both fixed and 99 wireless multimedia applications. 101 While ETSI is committed to the creation of new multimedia 102 applications and services, the importance of provided support to 103 existing Integrated Services Digital Network and Public Switched 104 Telephone Network (ISDN/PSTN) supplementary services has been also 105 acknowledged. We refer to supplementary services provided with SIP in 106 the context of NGN as 'simulation services'. They are referred to as 107 simulation services because they need to be adapted to be provided 108 with SIP, so small variations are expected when compared with the 109 equivalent ISDN/PSTN supplementary service. For example, all the 110 services that depend on a busy condition from a user who is using a 111 single telephone become broader in SIP when the user is using and 112 registered from different terminals, since the busy indication from 113 one terminal might not indicate that the user is not willing to 114 accept other sessions in other terminals. 116 3GPP TS 24.229 [4] is used to simulate the regarding services, but to 117 fulfill the requirements defined within ETSI TISPAN NGN Release 1 118 some further SIP support is needed. 120 Note that sometimes the realization of a service requires the 121 implementation of a number of SIP extensions in SIP User Agents. We 122 do not expect SIP UAs not implementing those extensions to provide a 123 service to the user. In that case, the basic session will be provided 124 without the additional service. 126 This document defines some input requirements to support the 127 implementation of simulation services. Particularly, we have listed 128 those requirements for which we do not have a clear indication of the 129 implementation, or that clarify the behaviour of the service. 130 However, we do not list all the requirements that describe a service. 131 Readers interested in a comprehensive set of requirements should 132 refer to the ETSI specifications for the corresponding PSTN/ISDN 133 supplementary service (even when such specification does not consider 134 SIP or IMS). We have included a list of the PSTN/ISDN supplementary 135 services specification as references. 137 It is generally understood that not every requirement listed in this 138 memo will require a SIP extension. A companion memo, Analysis of 140 TISPAN req. to SIP [5] provides an analysis of possible 141 implementations of these requirements and explores different 142 extensions when those are needed. 144 All mentioned 3GPP and ETSI Standards are free available under 145 http://pda.etsi.org/pda/queryform.asp and 146 http://www.3gpp.org/ftp/Specs/html-info/. 148 The resulting work of this collaboration will eventually be 149 contributed to International Telecommunication Union - 150 Telecommunication Standardization Sector (ITU-T) as part of their NGN 151 work to have an alignment between the work of the standardization 152 organizations. 154 Some of the services for which we have produced requirements are 155 classified as "regulatory services", i.e., required by national 156 administrations as a prerequisite for the operation of the network. 157 We have marked these services as an assistance to provide an 158 indication of prioritization when developing solutions. 160 3.Requirements in Support of Simulation Services 162 3.1 General Requirements 163 This section provides a collection of general requirements that are 164 applicable to all the services described later. Solutions developed 165 to meet the rest of the requirements must have into account those 166 described in here. 168 REQ-GEN-1: 169 All simulation services must provide interoperability with the 170 PSTN/ISDN. By interoperability we mean that, in the case that a 171 simulation or supplementary service is provided to one of the users 172 when one of the endpoints is located in the PSTN and the other is 173 located in the NGN IMS network, the user should receive the service 174 without any degradation as if the service were provided in the native 175 network. 176 REQ-GEN-2: 177 Most of the PSTN/ISDN services are targeting sessions where audio is 178 the only media stream, while SIP allows to establish a session with 179 any type of media. The user's experience should not be limited to 180 that of the traditional supplementary services. Thus, when 181 applicable, the simulation services should be applicable to any type 182 of communication, including but not restricted only to, audio calls 183 (e.g., including instant messaging, video calls, etc.). 184 REQ-GEN-3: 186 SIP User Agents not providing a simulation service should not be 187 influenced by the establishment of a given communication; they are 188 simple not able to provide the related service. 189 REQ-GEN-4: 190 It must be possible to convey the language(s) known to the caller. 191 REQ-GEN-5: 192 It must be possible to indicate that the caller is an operator. 193 REQ-GEN-6: 194 It must be possible to assert that the caller has priority. 195 REQ-GEN-7: 196 Note: we seem to have requirements, based on the PSTN/ISDN, to 197 indicate that some calls are data calls, test calls, or originated in 198 a payphone. We need to find the correct formulation of those 199 requirements. 200 REQ-GEN-8: 201 For services it is needed to sent from an application server point 202 indications and notifications to the user. This is needed to provide 203 a indication to the user that a Service is fulfilled now or that 204 special procedures or actions from a user or application server are 205 expected. Notifications are needed for the user or application server 206 that such a action was successfully processed. 208 3.2 Anonymous Communication Rejection (ACR) 209 This service allows a callee to instruct the network to automatically 210 reject incoming communications when the caller is anonymous. The ACR 211 supplementary service is described in ETSI EN 300 798 [19]. The 212 services also contains provisions for exceptional cases where the 213 service is overridden. One of these cases consist of a PSTN 214 originated call where the network could not provide an identification 215 of the calling party number, such as is the case when the call was 216 originated in an analogue network. 218 ACR is a regulatory service. 220 REQ-ACR-1: 221 The originating network shall be able to indicate to the terminating 222 network, that the caller has requested anonymity. 223 REQ-ACR-2: 224 The ACR simulation service requires the caller to be informed that 225 the communication was rejected because the SIP request was anonymous 226 and the callee had the ACR service activated. 228 3.3 Terminating Identification Presentation/Restriction (TIP/TIR) 229 These services support the presentation or restriction of a callee's 230 identity to the caller. They are the simulation of the ISDN/PSTN 231 Connected Line Identification Presentation/Restriction (COLP/COLR) 232 supplementary services. The network does not assert the identity 233 referred to in this service; the callee merely indicates an 234 additional identity where he is reachable, e.g., for a new future 235 communication. 237 The service is useful in scenarios where the caller dialled a SIP URI 238 that is translated to another SIP URI, such as the case when a user 239 dials a free-phone URI that is translated to a real URI. The callee 240 may want to indicate the real addressable URI to the caller. 242 The corresponding COLP supplementary service is described in ETSI EN 243 300 094 [7]. The corresponding COLR supplementary service is 244 described in ETSI ETS 300 095 [8]. 246 TIP and TIR are regulatory services. 248 REQ-TIP-1: 249 In addition to any network asserted identity, it must be possible for 250 the callee to indicate in a SIP response an additional identity where 251 the user is reachable for future direct communications. Note that the 252 requirement refers to the user, not to the same instance of the User 253 Agent. 254 REQ-TIP-2: 255 The identity mentioned in REQ-TIP-1 must be formatted as a SIP URI 256 [2] or TEL URL [3]. A translation between SIP URI and TEL URL by the 257 network is not requested. 258 REQ-TIP-3: 259 The identity mentioned in REQ-TIP-1 is considered an end user 260 supplied information that is not asserted by the network. 262 3.4Advice of Charge (AoC) 263 The Advice of Charge service allows the caller to request the 264 displaying of tariff information related to the communication. The 265 caller can request the displaying of charging information at setup 266 time (AoC-S), during a session (AoC-D), or at the end of it (AoC-E), 267 including a few seconds after the communication has ended. 269 The AoC-S supplementary service is described in ETSI ETS 300 178 270 [15]. The AoC-D supplementary service is described in ETSI ETS 300 271 179 [16]. The AoC-E supplementary service is described in ETSI ETS 272 300 180 [17]. 274 REQ-AoC-1: 275 The AoC service must be possible to be invoked at the time a 276 communication is initiated. 277 REQ-AoC-2: 278 It must be possible for a caller to receive charging information once 279 the service has been invoked at the time a communication is 280 initiated, during the communication, and when the communication has 281 ended. 282 REQ-AoC-3: 283 The information supplied to the user is asynchronously generated, 284 updated and reported to the user when new charging information is 285 available. For example, when the cumulative charging value changes 286 more then a certain predefined value; or, as time passes by, the 287 charging implications might change; or a re-INVITE can request new 288 media streams that will impact charging. Asynchronously transport 289 means that the information shall be transported at any time during 291 and after (e.g., within a certain period of time) the communication, 292 but within the session context, when it is needed. 294 3.5 Communication Completion on Busy Subscriber (CCBS) and 295 Communication Completion on no Reply (CCNR) 296 CCBS and CCNR are very similar in nature, thus, we describe the 297 requirements for both services at the same time. 299 Communication Completion on Busy Subscriber (CCBS) provides the 300 caller with the ability to complete a requested communication to a 301 busy callee without having to make a new communication attempt when 302 the callee becomes not busy anymore. It is possible for the caller to 303 request several communications to be under the CCBS requested status. 304 Also the callee can be subject to several CCBS communications from 305 different callers. Additionally, the service provides queue 306 management to arbitrate several CCBS requests to the same callee. The 307 CCBS supplementary service is described in ETSI EN 300 357 [18]. 309 Communication Completion on no Reply (CCNR) provides the caller with 310 the ability to complete a requested communication to a callee without 311 having to make a new communication attempt when the callee showed 312 activity. The CCNR supplementary service is described in ETSI EN 301 313 134 [14]. 315 For the purpose of this service, we provide the following definitions 316 (sources: ETSI EN 300 357 [18] and ETSI EN 301 134 [14]): 318 CCBS/CCNR request: 319 an instance of an activation of the CCBS/CCNR service which is held 320 in a queue pending the correct conditions for the CCBS/CCNR service 321 to be completed. 323 Suspended CCBS/CCNR request: 324 a CCBS/CCNR request which cannot be served even if callee is in the 325 appropriate state because the caller is busy. 327 CCBS/CCNR service duration timer: 328 maximum time the CCBS/CCNR service will remain activated for the 329 caller within the network. 331 CCBS call: 332 a communication generated by the network connecting the caller to the 333 callee, resulting from the callers' acceptance of a CCBS recall. 335 CCBS recall: 336 an indication informing the caller that the network is ready to 337 initiate a CCBS call to the callee and that the network is awaiting a 338 response to this indication. 340 Requirements affecting CCBS/CCNR: 342 Invocation: 344 REQ-CCBS/CCNR-1: 345 In order to assure that end-to-end functionality of the CCBS/CCNR 346 services is possible, there must be a mechanism whereby the caller 347 gets knowledge of the availability of the CCBS/CCNR service at the 348 callee or the PSTN/ISDN terminal on a communication by communication 349 basis. 350 REQ-CCBS/CCNR-2: 351 It must be possible for the caller to invoke the CCBS/CCNR service. 353 Control of callee status and information to the caller: 355 REQ-CCBS/CCNR-3: 356 The CCBS/CCNR simulation service should be able to handle queues and 357 arbitrate multiple simultaneous CCBS/CCNR requests according to a 358 locally defined policy (e.g., first in first out). 359 REQ-CCBS/CCNR-4: 360 The entity providing the CCBS/CCNR service needs to know the change 361 of the status at the callee's (e.g., in CCBS a transition when the 362 callee sends or receive a BYE request for an existing session; in 363 CCNR any activity indicated by the presence of the user, such as a 364 key press or any other interaction with the device). 365 REQ-CCBS/CCNR-5: 366 The entity providing the CCBS/CCNR service needs to learn the 367 capability of the callee's UAs to provide an indication of the change 368 of status, not later than upon failure response (CCBS) or not later 369 than the alerting phase (CCNR). 370 REQ-CCBS/CCNR-6: 371 The CCBS/CCNR service duration timer expires after a certain time 372 controlled by the entity providing the CCBS/CCNR service. 373 REQ-CCBS/CCNR-7: 374 It must be possible for the network to prioritize CCBS/CCNR recalls 375 towards the callee, above regular calls. This implies that any 376 communication performed as a result of the execution of a CCBS/CCNR 377 request should be distinguishable from regular communications. 378 REQ-CCBS/CCNR-8: 379 The CCBS/CCNR service must be able to inform the caller when the 380 service-specific condition related to the callee's state is met. 381 REQ-CCBS/CCNR-9: 382 There must be a mechanism whereby the callee can accept or reject 383 CCBS/CCNR requests. 384 REQ-CCBS/CCNR-10: 385 If the caller accepts a CCBS recall, other terminating calls towards 386 the callee should be treated as if the callee were already busy. 387 REQ-CCBS/CCNR-11: 389 There must be a mechanism whereby the entity providing CCBS/CCNR 390 service can suspend, resume and cancel CCBS/CCNR subscriptions. 391 REQ-CCBS/CCNR-12: 392 When the service-specific condition related to the callee's state is 393 met, the CCBS/CCNR service must be able to reach the caller at any of 394 the locations where he is logged. 395 REQ-CCBS/CCNR-13: 396 The service-specific condition related to the callee's state must 397 take into account the state of the user at different terminals he 398 might be using. 400 Suspend state: 402 REQ-CCBS/CCNR-14: 403 The entity providing the CCBS/CCNR service needs to know the change 404 of the status at the caller's (e.g., to find out when a pending 405 CCBS/CCNR request can be resumed or to allocate a time-slot to 406 execute a pending CCBS/CCNR request). 407 REQ-CCBS/CCNR-15: 408 Should the caller be busy at the time of executing CCBS/CCNR request, 409 the request is suspended until its status changes (back to free 410 status). 411 REQ-CCBS/CCNR-16: 412 During the period of time when a CCBS/CCNR request is in suspended 413 state for a given caller, no other CCBS/CCNR request execution must 414 be performed for that caller. 415 REQ-CCBS/CCNR-17: 416 A suspended CCBS/CCNR request is resumed when caller's status changes 417 to non-busy. The new place in the queue of that subscription is 418 chosen according to a local policy. 419 REQ-CCBS/CCNR-18: 420 The suspension of a CCBS/CCNR request of a user must not impact other 421 users in the same queue for the same callee. 422 REQ-CCBS/CCNR-19: 424 There must be a mechanism whereby CCBS/CCNR request initiators can 425 check or cancel their pending CCBS/CCNR requests. 427 3.6 Malicious Communication Identification (MCID) 428 The Malicious Communication Identification (MCID) enables the callee 429 to indicate that an incoming communication is considered to be 430 malicious and it should be identified and registered. The MCID 431 supplementary service is described in ETSI ETS 300 128 [9]. 433 REQ-MCID-1: 434 In order to support the MCID simulation service there must be a 435 mechanism whereby a user can provide an indication that an incoming 436 request or session is considered to be malicious. The user can 438 provide this indication at the start, during or within a certain time 439 after a session or request. 440 REQ-MCID-2: 441 For interoperability reasons, the MCID simulation service logic needs 442 to get the knowledge that, even if the originator identity is missing 443 in the signalling, it can available upon request. This is due to, 444 e.g., interworking with the PSTN network, where, in some cases, the 445 originator's identity is only available upon explicit request. The 446 information can be received asynchronously in a time-frame of 1-30 447 seconds even after the session has been closed. 449 Note: Requirement REQ-MCID-1 reads about the ability of the callee to 450 provide an indication of malicious call, but there is no requirement 451 to supply the caller's identity to the called. 453 3.7 Communication Waiting (CW) 454 This service provides the ability of the callee to be informed at the 455 time a communication is coming in that no resources are available for 456 that incoming communication. The callee has then the choice of 457 accepting, rejecting or ignoring the incoming communication, which is 458 outside the scope of he service. The caller will be informed that his 459 communication is waiting. The CW supplementary service is described 460 in ETSI ETS 300 056 [6]. 462 REQ-CW-1: 463 For implement the CW simulation service it is envisioned the usage of 464 an application server that detects some busy conditions on behalf of 465 the user. To support this scenario a mechanism to inform the callee 466 that a communication is in waiting state is required. 467 REQ-CW-2: 468 It must be possible for the CW service to inform the caller that an 469 application server is holding the communication until the callee is 470 available. 472 3.8 Communications Diversion (CDIV) 473 This simulation service allows the diversion of incoming 474 communications to a third party. Communications are diverted upon one 475 of several events (e.g., the callee is busy). The service comprises 476 the equivalent PSTN/ISDN supplementary service for Call Forwarding 477 Unconditional (CFU), Call Forwarding Busy (CFB), Call Forwarding on 478 No Reply (CFNR), and Call Deflection (CD). The CFU supplementary 479 service is described in ETSI ETS 300 200 [11]. The CFB supplementary 480 service is described in ETSI EN 300 199 [10]. The CFNR supplementary 481 service is described in ETSI EN 300 201 [12]. The CD supplementary 482 service is described in ETSI ETS 300 202 [13]. 484 REQ-CDIV-1: 485 It must be possible that the caller is informed that a communication 486 is being diverted. 487 REQ-CDIV-2: 488 It must be possible for the diverting user to express his privacy 489 requirements with respect his identity. 490 REQ-CDIV-3: 491 The reason of the redirection must be available to the caller, 492 callee, and network intermediaries (e.g., voice mail server). 493 REQ-CDIV-4: 494 It must be possible for the caller, the callee, and network 495 intermediaries to be informed about the identity of the caller, 496 diverting parties, and callee, if these identities are available. 498 4. Security Considerations 499 This memo provides a collection of requires to SIP for the 500 implementation of some PSTN/ISDN simulation services in Next 501 Generation Networks. Some or most of these services require to 502 consider the security threats and provide a solution for them. 504 IANA Considerations 506 This document describes the use of the Reason header field described 507 within RFC 3326 [2]. No additional SIP elements are defined within 508 this document. Therefore, this document does not provide any action 509 to IANA. 511 5.Contributors 512 Keith Drage 513 GSM Optimus House 514 SN5 6PP Swindon 515 United Kingdom 516 Phone: +44 1793 897312 517 Email: drage@lucent.com 519 Sebastien Garcin 520 France Telecom 521 38-40, Rue du General Leclerc 522 92130 Issy Les Moulineaux 523 France 525 6. Acknowledgments 526 These document has been heavily discussed in the ETSI TISPAN WG3 and 527 the IETF sipping-tispan mailing list. The authors and contributors 528 would like to thank Paul Kyzivat, Christian Schmidt, Phil Mart, Hans- 529 Erik van Elburg, Michael Hammer, Tom Taylor, Shida Schubert, Jeroen 530 van Bemmel, Silvia Tessa, Anna-Martinez Rebordosa and Rocky Wang for 531 keeping the discussion alive and helpful comments. 532 7.References 534 7.1. Normative References 535 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 536 Levels," BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). 538 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 539 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 540 Session Initiation Protocol," RFC 3261, June 2002. 541 [3] Schulzrinne, H., "The tel URI for Telephone Numbers," RFC 3966, 542 December 2004. 544 7.2 Informational References 545 [4] 3GPP, "Internet Protocol (IP) multimedia call control protocol 546 based on Session Initiation Protocol (SIP) and Session Description 547 Protocol (SDP); Stage 3," 3GPP TS 24.229 5.13.0, June 2005. 548 [5] Jesske, R., "Analysis of the Input Requirements for the Session 549 Initiation Protocol (SIP) in support for the European 550 Telecommunications Standards Institute (ETSI) Next Generation 551 Networks (NGN) simulation service," draft-jesske-sipping-tispan- 552 analysis-00 (work in progress), June 2005. 553 [6] ETSI, "Integrated Services Digital Network (ISDN); Call Waiting 554 (CW) Supplementary Service; Service Description," ETSI ETS 300 555 056, October 1991. 556 [7] ETSI, "Integrated Services Digital Network (ISDN); Connected 557 Line 558 Identification Presentation (COLP) Supplementary Service; Service 559 Description," ETSI EN 300 094 v2.1.1, June 2000. 560 [8] ETSI, "Integrated Services Digital Network (ISDN); Connected 561 Line Identification Restriction (COLR) Supplementary Service; 562 Service Description," ETSI ETS 300 095, January 1992. 563 [9] ETSI, "Integrated Services Digital Network (ISDN); Malicious 564 Call Identification (MCID) Supplementary Service; Service 565 Description," ETSI ETS 300 128, March 1992. 566 [10] ETSI, "Integrated Services Digital Network (ISDN); Call 567 Forwarding Busy (CFB) Supplementary Service; Service 568 Description," ETSI EN 300 199, June 2001. 569 [11] ETSI, "Integrated Services Digital Network (ISDN); Call 570 Forwarding Unconditional (CFU) Supplementary Service; Service 571 Description," ETSI ETS 300 200, December 1994. 573 [12] ETSI, "Integrated Services Digital Network (ISDN); Call 574 Forwarding No Reply (CFNR) Supplementary Service; Service 575 Description,"ETSI EN 300 201, May 2001. 576 [13] ETSI, "Integrated Services Digital Network (ISDN); 577 Call Forwarding Deflection (CD) Supplementary Service; 578 Service Description," ETSI ETS 300 202, December 1994. 579 [14] ETSI, "Integrated Services Digital Network (ISDN); Completion 580 of Calls on No Reply (CCNR) Supplementary Service; Service 581 Description,"ETSI EN 301 134 v1.1.1, October 1998. 582 [15] ETSI, "Integrated Services Digital Network (ISDN); Advice of 583 Charge: Charging Information at Call Set-up Time (AOC-S) 584 Supplementary Service; Service Description,"ETSI ETS 300 178, 585 November 1992. 586 [16] ETSI, "Integrated Services Digital Network (ISDN); Advice of 587 Charge: Charging Information During the Call (AOC-D) Supplementary 588 Service; Service Description," ETSI ETS 300 179, November 1992. 589 [17] ETSI, "Integrated Services Digital Network (ISDN); Advice of 590 Charge: Charging Information at the End of the Call (AOC-E) 591 Supplementary Service; Service description," ETSI ETS 300 180, 592 November 1992. 593 [18] ETSI, "Integrated Services Digital Network (ISDN); Completion 594 of Calls to Busy Subscriber (CCBS) Supplementary Service; Service 595 Description," ETSI EN 300 357 v1.2.1, May 2001. 596 [19] ETSI, "Services and Protocols for Advanced Networks (SPAN); 597 Anonymous Call Rejection (ACR) Supplementary Service; Service 598 description," ETSI EN 301 798 v1.1.1, October 2000. 600 8.Authors' Addresses 602 Roland Jesske 603 Deutsche Telekom 604 Am Kavalleriesand 3 605 Darmstadt 64307 606 Germany 607 Email: r.jesske@t-com.net 609 Denis Alexeitsev 610 Deutsche Telekom 611 Am Kavalleriesand 3 612 Darmstadt 64307 613 Germany 614 Email: d.alexeitsev@t-com.net 616 Miguel A. Garcia Martin (editor) 617 Nokia 618 P.O. Box 407 619 NOKIA GROUP, FIN 00045 620 Finland 621 Email: miguel.an.garcia@nokia.com 623 Changes from Version 02 to 03 624 Modification of AoC requirements due to TISPAN discussions 626 Changes from Version 03 to 04 627 Add GEN-REQ-8 629 9.Full Copyright Statement 631 Copyright (C) The IETF Trust (2007). 633 This document is subject to the rights, licenses and restrictions 634 contained in BCP 78, and except as set forth therein, the authors 635 retain all their rights. 637 This document and the information contained herein are provided on an 638 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 639 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 640 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 641 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 642 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 643 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 645 10.Intellectual Property 647 The IETF takes no position regarding the validity or scope of any 648 Intellectual Property Rights or other rights that might be claimed to 649 pertain to the implementation or use of the technology described in 650 this document or the extent to which any license under such rights 651 might or might not be available; nor does it represent that it has 652 made any independent effort to identify any such rights. Information 653 on the procedures with respect to rights in RFC documents can be 654 found in BCP 78 and BCP 79. 656 Copies of IPR disclosures made to the IETF Secretariat and any 657 assurances of licenses to be made available, or the result of an 658 attempt made to obtain a general license or permission for the use of 659 such proprietary rights by implementers or users of this 660 specification can be obtained from the IETF on-line IPR repository at 661 http://www.ietf.org/ipr. 663 The IETF invites any interested party to bring to its attention any 664 copyrights, patents or patent applications, or other proprietary 665 rights that may cover technology that may be required to implement 666 this standard. Please address the information to the IETF at 667 ietf-ipr@ietf.org. 669 11. 670 Acknowledgment 672 Funding for the RFC Editor function is provided by the IETF 673 Administrative Support Activity (IASA).