idnits 2.17.1 draft-jesske-sipping-tispan-requirements-03.txt: -(516): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(522): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(526): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(529): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(532): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(534): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(535): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(537): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(540): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(543): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(544): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(547): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(558): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(561): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(563): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(566): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(568): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(569): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(571): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(573): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 638. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 615. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 622. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 628. ** 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: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-jesske-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-jesske-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-jesske-', but the file name used is 'draft-jesske-sipping-tispan-requirements-03' == There are 37 instances of lines with non-ascii characters in the document. == 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 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 == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (June 2006) is 6517 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) No issues found here. Summary: 6 errors (**), 1 flaw (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Sipping Working Group 2 Internet Draft Roland Jesske 3 Expires: December 21, 2007 Denis Alexeitsev 4 Deutsche Telekom 5 M. Garcia-Martin 6 Nokia 7 22.June 2006 9 Input Requirements for the Session Initiation Protocol (SIP) in support 10 for the European Telecommunications Standards Institute, draft-jesske- 11 sipping-tispan-requirements-03 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 December 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 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). These 47 requirements should help to find SIP solutions to provide the 48 services described within this document. 50 Table of Contents 52 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 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) . . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 7.1. Normative References . . . . . . . . . . . .. . . . . . . 11 70 7.2. Informational References . . . . . . . . . .. . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 72 Intellectual Property and Copyright Statements . . . . . . . . . . 14 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 in 103 the context of NGN as 'simulation services'. They are referred to as 104 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 provided 121 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 159 This section provides a collection of general requirements that are 160 applicable to all the services described later. Solutions developed 161 to meet the rest of the requirements must have into account those 162 described in here. 164 REQ-GEN-1: 165 All simulation services must provide interoperability with the 166 PSTN/ISDN. By interoperability we mean that, in the case that a 167 simulation or supplementary service is provided to one of the users 168 when one of the endpoints is located in the PSTN and the other is 169 located in the NGN IMS network, the user should receive the service 170 without any degradation as if the service were provided in the native 171 network. 172 REQ-GEN-2: 173 Most of the PSTN/ISDN services are targeting sessions where audio is 174 the only media stream, while SIP allows to establish a session with 175 any type of media. The user's experience should not be limited to 176 that of the traditional supplementary services. Thus, when 177 applicable, the simulation services should be applicable to any type 178 of communication, including but not restricted only to, audio calls 179 (e.g., including instant messaging, video calls, etc.). 180 REQ-GEN-3: 181 SIP User Agents not providing a simulation service should not be 182 influenced by the establishment of a given communication; they are 183 simple not able to provide the related service. 185 REQ-GEN-4: 186 It must be possible to convey the language(s) known to the caller. 187 REQ-GEN-5: 188 It must be possible to indicate that the caller is an operator. 189 REQ-GEN-6: 190 It must be possible to assert that the caller has priority. 191 REQ-GEN-7: 192 Note: we seem to have requirements, based on the PSTN/ISDN, to 193 indicate that some calls are data calls, test calls, or originated in 194 a payphone. We need to find the correct formulation of those 195 requirements. 197 3.2. Anonymous Communication Rejection (ACR) 198 This service allows a callee to instruct the network to automatically 199 reject incoming communications when the caller is anonymous. The ACR 200 supplementary service is described in ETSI EN 300 798 [19]. The 201 services also contains provisions for exceptional cases where the 202 service is overridden. One of these cases consist of a PSTN 203 originated call where the network could not provide an identification 204 of the calling party number, such as is the case when the call was 205 originated in an analogue network. 207 ACR is a regulatory service. 209 REQ-ACR-1: 210 The originating network shall be able to indicate to the terminating 211 network, that the caller has requested anonymity. 212 REQ-ACR-2: 213 The ACR simulation service requires the caller to be informed that 214 the communication was rejected because the SIP request was anonymous 215 and the callee had the ACR service activated. 217 3.3. Terminating Identification Presentation/Restriction (TIP/TIR) 218 These services support the presentation or restriction of a callee's 219 identity to the caller. They are the simulation of the ISDN/PSTN 220 Connected Line Identification Presentation/Restriction (COLP/COLR) 221 supplementary services. The network does not assert the identity 222 referred to in this service; the callee merely indicates an 223 additional identity where he is reachable, e.g., for a new future 224 communication. 226 The service is useful in scenarios where the caller dialled a SIP URI 227 that is translated to another SIP URI, such as the case when a user 228 dials a free-phone URI that is translated to a real URI. The callee 229 may want to indicate the real addressable URI to the caller. 231 The corresponding COLP supplementary service is described in ETSI EN 232 300 094 [7]. The corresponding COLR supplementary service is 233 described in ETSI ETS 300 095 [8]. 235 TIP and TIR are regulatory services. 237 REQ-TIP-1: 238 In addition to any network asserted identity, it must be possible for 239 the callee to indicate in a SIP response an additional identity where 240 the user is reachable for future direct communications. Note that the 241 requirement refers to the user, not to the same instance of the User 242 Agent. 243 REQ-TIP-2: 244 The identity mentioned in REQ-TIP-1 must be formatted as a SIP URI 245 [2] or TEL URL [3]. A translation between SIP URI and TEL URL by the 246 network is not requested. 247 REQ-TIP-3: 248 The identity mentioned in REQ-TIP-1 is considered an end user 249 supplied information that is not asserted by the network. 251 3.4. Advice of Charge (AoC) 252 The Advice of Charge service allows the caller to request the 253 displaying of tariff information related to the communication. The 254 caller can request the displaying of charging information at setup 255 time (AoC-S), during a session (AoC-D), or at the end of it (AoC-E), 256 including a few seconds after the communication has ended. 258 The AoC-S supplementary service is described in ETSI ETS 300 178 259 [15]. The AoC-D supplementary service is described in ETSI ETS 300 260 179 [16]. The AoC-E supplementary service is described in ETSI ETS 261 300 180 [17]. 263 REQ-AoC-1: 264 The AoC service must be possible to be invoked at the time a 265 communication is initiated. 266 REQ-AoC-2: 267 It must be possible for a caller to receive charging information once 268 the service has been invoked at the time a communication is 269 initiated, during the communication, and when the communication has 270 ended. 271 REQ-AoC-3: 272 The information supplied to the user is asynchronously generated, 273 updated and reported to the user when new charging information is 274 available. For example, when the cumulative charging value changes 275 more then a certain predefined value; or, as time passes by, the 276 charging implications might change; or a re-INVITE can request new 277 media streams that will impact charging. Asynchronously transport 278 means that the information shall be transported at any time during 279 and after (e.g., within a certain period of time) the communication, 280 but within the session context, when it is needed. 282 3.5. Communication Completion on Busy Subscriber (CCBS) and 283 Communication Completion on no Reply (CCNR) 284 CCBS and CCNR are very similar in nature, thus, we describe the 285 requirements for both services at the same time. 287 Communication Completion on Busy Subscriber (CCBS) provides the 288 caller with the ability to complete a requested communication to a 289 busy callee without having to make a new communication attempt when 290 the callee becomes not busy anymore. It is possible for the caller to 291 request several communications to be under the CCBS requested status. 292 Also the callee can be subject to several CCBS communications from 293 different callers. Additionally, the service provides queue 294 management to arbitrate several CCBS requests to the same callee. The 295 CCBS supplementary service is described in ETSI EN 300 357 [18]. 297 Communication Completion on no Reply (CCNR) provides the caller with 298 the ability to complete a requested communication to a callee without 299 having to make a new communication attempt when the callee showed 300 activity. The CCNR supplementary service is described in ETSI EN 301 301 134 [14]. 303 For the purpose of this service, we provide the following definitions 304 (sources: ETSI EN 300 357 [18] and ETSI EN 301 134 [14]): 306 CCBS/CCNR request: 307 an instance of an activation of the CCBS/CCNR service which is held 308 in a queue pending the correct conditions for the CCBS/CCNR service 309 to be completed. 311 Suspended CCBS/CCNR request: 312 a CCBS/CCNR request which cannot be served even if callee is in the 313 appropriate state because the caller is busy. 315 CCBS/CCNR service duration timer: 316 maximum time the CCBS/CCNR service will remain activated for the 317 caller within the network. 319 CCBS call: 320 a communication generated by the network connecting the caller to the 321 callee, resulting from the callers' acceptance of a CCBS recall. 323 CCBS recall: 324 an indication informing the caller that the network is ready to 325 initiate a CCBS call to the callee and that the network is awaiting a 326 response to this indication. 328 Requirements affecting CCBS/CCNR: 330 Invocation: 332 REQ-CCBS/CCNR-1: 333 In order to assure that end-to-end functionality of the CCBS/CCNR 334 services is possible, there must be a mechanism whereby the caller 335 gets knowledge of the availability of the CCBS/CCNR service at the 336 callee or the PSTN/ISDN terminal on a communication by communication 337 basis. 338 REQ-CCBS/CCNR-2: 339 It must be possible for the caller to invoke the CCBS/CCNR service. 341 Control of callee status and information to the caller: 343 REQ-CCBS/CCNR-3: 344 The CCBS/CCNR simulation service should be able to handle queues and 345 arbitrate multiple simultaneous CCBS/CCNR requests according to a 346 locally defined policy (e.g., first in first out). 347 REQ-CCBS/CCNR-4: 348 The entity providing the CCBS/CCNR service needs to know the change 349 of the status at the callee's (e.g., in CCBS a transition when the 350 callee sends or receive a BYE request for an existing session; in 351 CCNR any activity indicated by the presence of the user, such as a 352 key press or any other interaction with the device). 353 REQ-CCBS/CCNR-5: 354 The entity providing the CCBS/CCNR service needs to learn the 355 capability of the callee's UAs to provide an indication of the change 356 of status, not later than upon failure response (CCBS) or not later 357 than the alerting phase (CCNR). 358 REQ-CCBS/CCNR-6: 359 The CCBS/CCNR service duration timer expires after a certain time 360 controlled by the entity providing the CCBS/CCNR service. 361 REQ-CCBS/CCNR-7: 362 It must be possible for the network to prioritize CCBS/CCNR recalls 363 towards the callee, above regular calls. This implies that any 364 communication performed as a result of the execution of a CCBS/CCNR 365 request should be distinguishable from regular communications. 366 REQ-CCBS/CCNR-8: 367 The CCBS/CCNR service must be able to inform the caller when the 368 service-specific condition related to the callee's state is met. 369 REQ-CCBS/CCNR-9: 370 There must be a mechanism whereby the callee can accept or reject 371 CCBS/CCNR requests. 372 REQ-CCBS/CCNR-10: 373 If the caller accepts a CCBS recall, other terminating calls towards 374 the callee should be treated as if the callee were already busy. 375 REQ-CCBS/CCNR-11: 377 There must be a mechanism whereby the entity providing CCBS/CCNR 378 service can suspend, resume and cancel CCBS/CCNR subscriptions. 379 REQ-CCBS/CCNR-12: 380 When the service-specific condition related to the callee's state is 381 met, the CCBS/CCNR service must be able to reach the caller at any of 382 the locations where he is logged. 383 REQ-CCBS/CCNR-13: 384 The service-specific condition related to the callee's state must 385 take into account the state of the user at different terminals he 386 might be using. 388 Suspend state: 390 REQ-CCBS/CCNR-14: 391 The entity providing the CCBS/CCNR service needs to know the change 392 of the status at the caller's (e.g., to find out when a pending 393 CCBS/CCNR request can be resumed or to allocate a time-slot to 394 execute a pending CCBS/CCNR request). 395 REQ-CCBS/CCNR-15: 396 Should the caller be busy at the time of executing CCBS/CCNR request, 397 the request is suspended until its status changes (back to free 398 status). 399 REQ-CCBS/CCNR-16: 400 During the period of time when a CCBS/CCNR request is in suspended 401 state for a given caller, no other CCBS/CCNR request execution must 402 be performed for that caller. 403 REQ-CCBS/CCNR-17: 404 A suspended CCBS/CCNR request is resumed when caller's status changes 405 to non-busy. The new place in the queue of that subscription is 406 chosen according to a local policy. 407 REQ-CCBS/CCNR-18: 408 The suspension of a CCBS/CCNR request of a user must not impact other 409 users in the same queue for the same callee. 410 REQ-CCBS/CCNR-19: 411 There must be a mechanism whereby CCBS/CCNR request initiators can 412 check or cancel their pending CCBS/CCNR requests. 414 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: 421 In order to support the MCID simulation service there must be a 422 mechanism whereby a user can provide an indication that an incoming 423 request or session is considered to be malicious. The user can 424 provide this indication at the start, during or within a certain time 425 after a session or request. 426 REQ-MCID-2: 427 For interoperability reasons, the MCID simulation service logic needs 428 to get the knowledge that, even if the originator identity is missing 429 in the signalling, it can available upon request. This is due to, 430 e.g., interworking with the PSTN network, where, in some cases, the 431 originator's identity is only available upon explicit request. The 432 information can be received asynchronously in a time-frame of 1-30 433 seconds even after the session has been closed. 435 Note: Requirement REQ-MCID-1 reads about the ability of the callee to 436 provide an indication of malicious call, but there is no requirement 437 to supply the caller's identity to the called. 439 3.7. Communication Waiting (CW) 440 This service provides the ability of the callee to be informed at the 441 time a communication is coming in that no resources are available for 442 that incoming communication. The callee has then the choice of 443 accepting, rejecting or ignoring the incoming communication, which is 444 outside the scope of he service. The caller will be informed that his 445 communication is waiting. The CW supplementary service is described 446 in ETSI ETS 300 056 [6]. 448 REQ-CW-1: 449 For implement the CW simulation service it is envisioned the usage of 450 an application server that detects some busy conditions on behalf of 451 the user. To support this scenario a mechanism to inform the callee 452 that a communication is in waiting state is required. 453 REQ-CW-2: 454 It must be possible for the CW service to inform the caller that an 455 application server is holding the communication until the callee is 456 available. 458 3.8. Communications Diversion (CDIV) 459 This simulation service allows the diversion of incoming 460 communications to a third party. Communications are diverted upon one 461 of several events (e.g., the callee is busy). The service comprises 462 the equivalent PSTN/ISDN supplementary service for Call Forwarding 463 Unconditional (CFU), Call Forwarding Busy (CFB), Call Forwarding on 464 No Reply (CFNR), and Call Deflection (CD). The CFU supplementary 465 service is described in ETSI ETS 300 200 [11]. The CFB supplementary 466 service is described in ETSI EN 300 199 [10]. The CFNR supplementary 467 service is described in ETSI EN 300 201 [12]. The CD supplementary 468 service is described in ETSI ETS 300 202 [13]. 470 REQ-CDIV-1: 472 It must be possible that the caller is informed that a communication 473 is being diverted. 474 REQ-CDIV-2: 475 It must be possible for the diverting user to express his privacy 476 requirements with respect his identity. 477 REQ-CDIV-3: 478 The reason of the redirection must be available to the caller, 479 callee, and network intermediaries (e.g., voice mail server). 480 REQ-CDIV-4: 481 It must be possible for the caller, the callee, and network 482 intermediaries to be informed about the identity of the caller, 483 diverting parties, and callee, if these identities are available. 485 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 492 Keith Drage 493 GSM Optimus House 494 SN5 6PP Swindon 495 United Kingdom 496 Phone: +44 1793 897312 497 Email: drage@lucent.com 499 Sebastien Garcin 500 France Telecom 501 38-40, Rue du General Leclerc 502 92130 Issy Les Moulineaux 503 France 505 6. Acknowledgments 506 These document has been heavily discussed in the ETSI TISPAN WG3 and 507 the IETF sipping-tispan mailing list. The authors and contributors 508 would like to thank Paul Kyzivat, Christian Schmidt, Phil Mart, Hans- 509 Erik van Elburg, Michael Hammer, Tom Taylor, Shida Schubert, Jeroen 510 van Bemmel, Silvia Tessa, Anna-Martinez Rebordosa and Rocky Wang for 511 keeping the discussion alive and helpful comments. 512 7. References 514 7.1. Normative References 516 [1] Bradner, S., ��Key words for use in RFCs to Indicate Requirement 517 Levels,�� BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). 519 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 520 Peterson, J., Sparks, R., Handley, M., and E. Schooler, ��SIP: 521 Session Initiation Protocol,�� RFC 3261, June 2002. 522 [3] Schulzrinne, H., ��The tel URI for Telephone Numbers,�� RFC 3966, 523 December 2004. 525 7.2. Informational References 526 [4] 3GPP, ��Internet Protocol (IP) multimedia call control protocol 527 based on Session Initiation Protocol (SIP) and Session Description 528 Protocol (SDP); Stage 3,�� 3GPP TS 24.229 5.13.0, June 2005. 529 [5] Jesske, R., ��Analysis of the Input Requirements for the Session 530 Initiation Protocol (SIP) in support for the European 531 Telecommunications Standards Institute (ETSI) Next Generation 532 Networks (NGN) simulation service,�� draft-jesske-sipping-tispan- 533 analysis-00 (work in progress), June 2005. 534 [6] ETSI, ��Integrated Services Digital Network (ISDN); Call Waiting 535 (CW) Supplementary Service; Service Description,�� ETSI ETS 300 536 056, October 1991. 537 [7] ETSI, ��Integrated Services Digital Network (ISDN); Connected Line 538 Identification Presentation (COLP) Supplementary Service; Service 539 Description,�� ETSI EN 300 094 v2.1.1, June 2000. 540 [8] ETSI, ��Integrated Services Digital Network (ISDN); Connected Line 541 Identification Restriction (COLR) Supplementary Service; Service 542 Description,�� ETSI ETS 300 095, January 1992. 543 [9] ETSI, ��Integrated Services Digital Network (ISDN); Malicious Call 544 Identification (MCID) Supplementary Service; Service Description,�� 545 ETSI ETS 300 128, March 1992. 546 [10] ETSI, ��Integrated Services Digital Network (ISDN); Call 547 Forwarding Busy (CFB) Supplementary Service; Service Description,�� 548 ETSI EN 300 199, June 2001. 549 [11] ETSI, ��Integrated Services Digital Network (ISDN); Call 550 Forwarding Unconditional (CFU) Supplementary Service; Service 551 Description,�� ETSI ETS 300 200, December 1994. 552 [12] ETSI, ��Integrated Services Digital Network (ISDN); Call 553 Forwarding No Reply (CFNR) Supplementary Service; Service 554 Description,�� ETSI EN 300 201, May 2001. 555 [13] ETSI, ��Integrated Services Digital Network (ISDN); Call 556 Forwarding Deflection (CD) Supplementary Service; Service 557 Description,�� ETSI ETS 300 202, December 1994. 558 [14] ETSI, ��Integrated Services Digital Network (ISDN); Completion of 559 Calls on No Reply (CCNR) Supplementary Service; Service 560 Description,�� ETSI EN 301 134 v1.1.1, October 1998. 561 [15] ETSI, ��Integrated Services Digital Network (ISDN); Advice of 562 Charge: Charging Information at Call Set-up Time (AOC-S) 563 Supplementary Service; Service Description,�� ETSI ETS 300 178, 564 November 1992. 566 [16] ETSI, ��Integrated Services Digital Network (ISDN); Advice of 567 Charge: Charging Information During the Call (AOC-D) Supplementary 568 Service; Service Description,�� ETSI ETS 300 179, November 1992. 569 [17] ETSI, ��Integrated Services Digital Network (ISDN); Advice of 570 Charge: Charging Information at the End of the Call (AOC-E) 571 Supplementary Service; Service description,�� ETSI ETS 300 180, 572 November 1992. 573 [18] ETSI, ��Integrated Services Digital Network (ISDN); Completion of 574 Calls to Busy Subscriber (CCBS) Supplementary Service; Service 575 Description,�� ETSI EN 300 357 v1.2.1, May 2001. 576 [19] ETSI, ��Services and Protocols for Advanced Networks (SPAN); 577 Anonymous Call Rejection (ACR) Supplementary Service; Service 578 description,�� ETSI EN 301 798 v1.1.1, October 2000. 580 Authors' Addresses 582 Roland Jesske 583 Deutsche Telekom 584 Am Kavalleriesand 3 585 Darmstadt 64307 586 Germany 587 Email: r.jesske@t-com.net 589 Denis Alexeitsev 590 Deutsche Telekom 591 Am Kavalleriesand 3 592 Darmstadt 64307 593 Germany 594 Email: d.alexeitsev@t-com.net 596 Miguel A. Garcia Martin (editor) 597 Nokia 598 P.O. Box 407 599 NOKIA GROUP, FIN 00045 600 Finland 601 Email: miguel.an.garcia@nokia.com 603 Changes from Version 02 to 03 604 Modification of AoC requirements due to TISPAN discussions 606 Intellectual Property Statement 608 The IETF takes no position regarding the validity or scope of any 609 Intellectual Property Rights or other rights that might be claimed to 610 pertain to the implementation or use of the technology described in 611 this document or the extent to which any license under such rights 612 might or might not be available; nor does it represent that it has 613 made any independent effort to identify any such rights. Information 614 on the procedures with respect to rights in RFC documents can be 615 found in BCP 78 and BCP 79. 617 Copies of IPR disclosures made to the IETF Secretariat and any 618 assurances of licenses to be made available, or the result of an 619 attempt made to obtain a general license or permission for the use of 620 such proprietary rights by implementers or users of this 621 specification can be obtained from the IETF on-line IPR repository at 622 http://www.ietf.org/ipr. 624 The IETF invites any interested party to bring to its attention any 625 copyrights, patents or patent applications, or other proprietary 626 rights that may cover technology that may be required to implement 627 this standard. Please address the information to the IETF at ietf- 628 ipr@ietf.org. 630 Disclaimer of Validity 632 This document and the information contained herein are provided on an 633 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 634 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 635 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 636 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 637 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 638 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 640 Copyright Statement 642 Copyright (C) The Internet Society (2006). This document is subject 643 to the rights, licenses and restrictions contained in BCP 78, and 644 except as set forth therein, the authors retain all their rights. 646 Acknowledgment 648 Funding for the RFC Editor function is currently provided by the 649 Internet Society.