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