idnits 2.17.00 (12 Aug 2021) /tmp/idnits25254/draft-ligot-bliss-sip-services-guide-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1055. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1066. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1073. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1079. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: o While members of a room MAY NOT have the same capabilities depending on their user agent, conference server may need to perform some transcoding. This is specified into:transc-conf [I-D.ietf-sipping-transc-conf] and [I-D.ietf-sipping-transc-framework]. -- 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 (July 14, 2008) is 5058 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-froment-sipping-spit-requirements-02 == Outdated reference: A later version (-06) exists of draft-ietf-bliss-ach-analysis-02 == Outdated reference: draft-ietf-bliss-call-completion has been published as RFC 6910 == Outdated reference: A later version (-04) exists of draft-ietf-bliss-problem-statement-02 == Outdated reference: draft-ietf-sip-acr-code has been published as RFC 5079 == Outdated reference: draft-ietf-sip-gruu has been published as RFC 5627 == Outdated reference: draft-ietf-sip-uri-list-conferencing has been published as RFC 5366 == Outdated reference: draft-ietf-sipping-cc-transfer has been published as RFC 5589 == Outdated reference: draft-ietf-sipping-service-examples has been published as RFC 5359 == Outdated reference: draft-ietf-sipping-transc-conf has been published as RFC 5370 == Outdated reference: draft-ietf-sipping-transc-framework has been published as RFC 5369 == Outdated reference: A later version (-05) exists of draft-procter-bliss-call-park-extension-01 == Outdated reference: A later version (-04) exists of draft-tschofenig-sipping-framework-spit-reduction-03 == Outdated reference: A later version (-03) exists of draft-tschofenig-sipping-spit-policy-02 -- Obsolete informational reference (is this intentional?): RFC 3265 (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 4244 (Obsoleted by RFC 7044) Summary: 1 error (**), 0 flaws (~~), 16 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Ligot 3 Internet-Draft University of Namur 4 Intended status: Informational T. Froment 5 Expires: January 15, 2009 Alcatel-Lucent 6 July 14, 2008 8 Providing guidance for Session Initiation Protocol (SIP) services 9 draft-ligot-bliss-sip-services-guide-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 15, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 Implementing Session Initiation Protocol (SIP) advanced features and 43 services requires to use numerous specifications. Today, for each 44 service in the scope of BLISS, one can already find references to 45 many possible specifications which do not cover the same things. 46 Some of them are primitive operations, requirements or call flow 47 examples, some have a scope larger than the others, or can not be 48 compared at the same level. Very often, architecture hypothesis are 49 hidden behind the same service name, either assuming that an 50 intermediary; like an application server, has an active role in the 51 service, or, as opposed, assuming a pure end-to-end model where only 52 endpoint implementations are involved. The goal of this document is 53 not to present the best solutions or give recommendations; but to 54 give an overview of every standard specification related to these 55 services, centralizing and categorizing them as input to the working 56 group. 58 Table of Contents 60 1. Introduction, scope . . . . . . . . . . . . . . . . . . . . . 5 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3. Call Forwarding . . . . . . . . . . . . . . . . . . . . . . . 8 63 3.1. Description . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.2. Frameworks and requirements . . . . . . . . . . . . . . . 8 65 3.3. Call flow samples . . . . . . . . . . . . . . . . . . . . 8 66 3.3.1. Endpoint based Call Forwarding . . . . . . . . . . . . 8 67 3.3.2. Intermediary based Call Forwarding . . . . . . . . . . 8 68 3.4. Specifications . . . . . . . . . . . . . . . . . . . . . . 9 69 4. Call Transfer . . . . . . . . . . . . . . . . . . . . . . . . 10 70 4.1. Description . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.2. Frameworks and requirements . . . . . . . . . . . . . . . 10 72 4.3. Call flow samples . . . . . . . . . . . . . . . . . . . . 10 73 4.3.1. Using REFER from the transferor to the transferee . . 10 74 4.3.2. Using REFER from the transferor to the target . . . . 11 75 4.3.3. Using MESSAGE . . . . . . . . . . . . . . . . . . . . 11 76 4.4. Specifications . . . . . . . . . . . . . . . . . . . . . . 11 77 5. Hold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 13 79 5.2. Frameworks and requirements . . . . . . . . . . . . . . . 13 80 5.3. Call flow samples . . . . . . . . . . . . . . . . . . . . 13 81 5.3.1. Using (re-)INVITE with SDP 'send-only' parameter . . . 13 82 5.4. Specifications . . . . . . . . . . . . . . . . . . . . . . 13 83 6. Call Baring . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 14 85 6.2. Frameworks and requirements . . . . . . . . . . . . . . . 14 86 6.3. Call flow samples . . . . . . . . . . . . . . . . . . . . 14 87 6.3.1. Intermediary based call baring . . . . . . . . . . . . 14 88 6.3.2. Endpoint based call baring . . . . . . . . . . . . . . 14 89 6.4. Specifications . . . . . . . . . . . . . . . . . . . . . . 15 90 7. Conference . . . . . . . . . . . . . . . . . . . . . . . . . . 16 91 7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 16 92 7.2. Frameworks and requirements . . . . . . . . . . . . . . . 16 93 7.3. Call flow samples . . . . . . . . . . . . . . . . . . . . 16 94 7.4. Specifications . . . . . . . . . . . . . . . . . . . . . . 16 95 8. Call parking . . . . . . . . . . . . . . . . . . . . . . . . . 18 96 8.1. Description . . . . . . . . . . . . . . . . . . . . . . . 18 97 8.2. Frameworks and requirements . . . . . . . . . . . . . . . 18 98 8.3. Call flow samples . . . . . . . . . . . . . . . . . . . . 18 99 8.4. Specifications . . . . . . . . . . . . . . . . . . . . . . 18 100 9. Do not disturb . . . . . . . . . . . . . . . . . . . . . . . . 19 101 9.1. Description . . . . . . . . . . . . . . . . . . . . . . . 19 102 9.2. Frameworks and requirements . . . . . . . . . . . . . . . 19 103 9.3. Call flow samples . . . . . . . . . . . . . . . . . . . . 19 104 9.4. Specifications . . . . . . . . . . . . . . . . . . . . . . 19 105 10. Call Completion . . . . . . . . . . . . . . . . . . . . . . . 20 106 10.1. Description . . . . . . . . . . . . . . . . . . . . . . . 20 107 10.2. Frameworks and requirements . . . . . . . . . . . . . . . 20 108 10.3. Call flow samples . . . . . . . . . . . . . . . . . . . . 20 109 10.4. Specifications . . . . . . . . . . . . . . . . . . . . . . 20 110 11. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21 111 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 112 13. Security Considerations . . . . . . . . . . . . . . . . . . . 23 113 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 114 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 115 15.1. Normative References . . . . . . . . . . . . . . . . . . . 25 116 15.2. Informative References . . . . . . . . . . . . . . . . . . 25 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 118 Intellectual Property and Copyright Statements . . . . . . . . . . 33 120 1. Introduction, scope 122 BLISS working group is chartered to facilitate effective feature 123 interoperability for advanced services sharing common functional 124 primitives utilizing SIP. In particular, it focuses on advanced call 125 features requiring non-trivial call control. The objective of this 126 document is not to give recommendation or to give a technical 127 appreciation of referenced specifications. So, references that could 128 be found in this document SHOULD NOT be considered as the recommended 129 way of implementing any service. This document aims at providing the 130 current "snapshot" of "SIP services" specifications, centralizing 131 what currently exist. 133 This first version presented here shows that the number of 134 specifications around call features is quite impressive, sometimes 135 individual drafts have addressed a very specific problem that has 136 been forgotten in the Internet draft morgue. Some other 137 specifications like ISDN ones have to be considered from a different 138 point of view: they are most of the time referencing existing IETF 139 specifications when they exist, generally trying to additionally 140 standardize the format of a user profile which contains the 141 configuration elements of the service. This approach assumes that 142 there is a user profile database, operated somewhere, which is of 143 course out of IETF scope. In that case, goal is indeed not to give 144 any appreciation on these external specifications, but to describe 145 which differences may exist between them, and if they diverge, try to 146 explain why. Thus, this document categorizes them in order to 147 outline what is currently missing and which documents can be compared 148 at the same "level". Indeed, very often, the confusion around 149 service specifications arises when this it not clear if it can be 150 assumed that an 'active intermediary' (a proxy, B2BUA, application 151 server....) contributes to the service implementation or not. 152 Difficulty is increased by the fact architecture considerations are 153 clearly out of IETF scope, but still need to be taken into account 154 when providing recommendations. This document clarifies this 155 situation each time it is possible, outlining if the referenced 156 specifications assume a "pure end-to-end" or an "intermediary" model. 157 For that purpose it separates the call flows in two sub-sections 158 called "Endpoint based" or "Intermediary based". This is of course a 159 simplification of the architecture alternatives, but it appears to be 160 enough to clarify the discussion. 162 Today, service categories that are considered as in-scope of BLISS 163 are the following: 165 o Call forwarding 166 o Call Transfer 168 o Hold 170 o Call Baring 172 o Conference 174 o Call parking 176 o Do not disturb 178 o Call completion 180 This list will be the starting point of this guide, it MAY be 181 extended to other topics in the future if it is considered as useful. 182 For each of these services, it provides: 184 o first, a short description of the service; 186 o second, user's requirements or frameworks which give grounds of 187 any implementation; 189 o third, references to documents that contain call flows showing the 190 application of the service; 192 o inally, a short description of any specification that has been 193 identified (possibly erroneously) as useful to implement a 194 service, giving some "hints" on why it is referenced in this 195 context 197 In this third version ISDN and TISPAN references has been replaced 198 with 3GPP specifications. Theses specifications are more up to date 199 and sometimes more complete. 201 While this is not a particular service, it should be noted that BLISS 202 working group is working on a draft about automatic call handling: 203 ACH [I-D.ietf-bliss-ach-analysis] 205 2. Terminology 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 209 document are to be interpreted as described in RFC 2119 [RFC2119]. 211 3. Call Forwarding 213 3.1. Description 215 Call forwarding allows users to divert a call from its destination 216 without answering it. There are a few cases of call forwarding. For 217 example, users should be able to forward calls towards another person 218 when he is already on the phone, when he does not answer or when he 219 is unavailable. Call forwarding should also allow users to setup 220 unconditional forwarding based on a set of rules. Call forwarding 221 always occur before the establishment of the call (see Call 222 Transfer). 224 'Call Forwarding' (CFx) is also called 'Call diversion' (CDIV). 226 3.2. Frameworks and requirements 228 o 3GPP 22 082 [3GPP.22.082], from 3GPP specification gives general 229 specifications of call forwarding and provides requirements, 230 terminology and definitions. 232 3.3. Call flow samples 234 3.3.1. Endpoint based Call Forwarding 236 o DESCRIPTION: endpoints can also implement call forwarding. No 237 specification example of this solution has been found. 239 o MANDATORY: no mandatory specification found for this service. 241 o OPTIONAL: terminals that implements this kind of forwarding could 242 base their implementation on LESS [I-D.wu-iptel-less] 244 3.3.2. Intermediary based Call Forwarding 246 o DESCRIPTION: sections 7,8,9 of [I-D.ietf-sipping-service-examples] 247 present some cases of call forwarding. These call flows are 248 mainly implementation dependent. 3GPP 24 604 [3GPP.24.604], from 249 TISPAN, uses call flows like those from sipping-service-examples. 250 It just additionally defines the user profile data model related 251 to this service. The same technique of call forwarding is also 252 described into section 3.1 of [I-D.ietf-bliss-problem-statement]. 254 o MANDATORY: none 256 o OPTIONAL: RFC 3880 (CPL) [RFC3880] or TISPAN profile defined into 257 3GPP 24 604 [3GPP.24.604] can be used by the user to tell the 258 configuration to the server. RFC 4458 (URI for applications) 260 [RFC4458] and RFC 4244 (history-info) [RFC4244] can be used to add 261 information about the diversion inside the SIP dialog 263 3.4. Specifications 265 o RFC 4458 (URI for applications) [RFC4458] specifies two new 266 parameters for the contact field that could be added when a call 267 is forwarded. These parameters are 'cause' and 'target': they 268 allow voicemails, for instance, to send an adapted greeting to the 269 caller who has been transferred. 271 o RFC 4244 (history-info) [RFC4244] introduces a new optional 272 header: 'history-info' which contains the list of previous target 273 URIs of the call and could contain additional values such as the 274 cause of each call forwarding, levels of privacy, etc. 276 o 3GPP 24 604 [3GPP.24.604] from 3GPP present a solution based on a 277 centralized server. This specification even specifies a way for 278 the user to send the expected configuration to the server. 280 o RFC 3880 (CPL) [RFC3880], CPL, presents a XML based script 281 language which can be used by end users in order to upload rules 282 of call forwarding to their proxy. The proxy should interpret 283 this set of rules and apply them without any action from the 284 endpoint. 286 o Like CPL, LESS [I-D.wu-iptel-less] is a language that could be 287 used to configure call forwarding but on the end point side. 289 o RFC 3841 [RFC3841] could be used to register fall back destination 290 for a user. While this specification can be use in order to 291 implement a particular kind of call forwarding, this is not the 292 primary goal of this specification. However, this specification 293 could be useful to allow a caller, in particular conditions, to 294 bypass or cancel a call forwarding. For instance, the 295 specification shows an example where the caller refuses to be 296 transferred to a voicemail; in that case, appropriate error 297 messages are sent. 299 o As call forwarding often comes with privacy requirements, RFC 3323 300 [RFC3323] could be helpful but it also introduces some 301 requirements over the network infrastructure since it assumes a 302 privacy server is deployed somewhere. 304 4. Call Transfer 306 4.1. Description 308 Call transfer occurs when a communication is already established 309 between parties and one of them, the transferor, wants to transfer 310 the other party, the transferee, to another party, the target, which 311 is not already a member of the on going dialog. 313 Requirements for this services often include privacy and 314 authentication. The target of a transfer could also be a service, a 315 conference room, or something else... 317 Transfer could be "managed". In this case, the transferor invites 318 the target, establishes a communication with it while the other party 319 is usually on hold and then ends its communication with it. Finally, 320 it transfers the transferee to the target. 322 4.2. Frameworks and requirements 324 o Section 4 of cc-transfer [I-D.ietf-sipping-cc-transfer] gives the 325 requirements of such service. 327 o 3GPP 22 091 [3GPP.22.091], from 3GPP specifications, like the 328 previous one gives a complete description of the service including 329 user's requirements. 331 4.3. Call flow samples 333 4.3.1. Using REFER from the transferor to the transferee 335 o DESCRIPTION: Sections 4 and 5 of service-examples 336 [I-D.ietf-sipping-service-examples] show some basic call flows of 337 transfer using a REFER message sent by the transferor, the user 338 who wants to transfer the other party in the current dialog. This 339 solution is also used in draft-ietf-sipping-cc-transfer 340 [I-D.ietf-sipping-cc-transfer] for instance, in section 6. 342 o MANDATORY: Both parties MUST support RFC 3515 (REFER) [RFC3515]. 343 This also implies the support of RFC 3265 (Event notifications) 344 [RFC3265] 346 o OPTIONAL: RFC 3892 ('Referred-by') [RFC3892] 348 4.3.2. Using REFER from the transferor to the target 350 o DESCRIPTION: draft-ietf-sipping-cc-transfer, section 7.2 351 [I-D.ietf-sipping-cc-transfer]. This solution, unlike the 352 previous one, allows the transferor to hide the sip URI of the 353 target to the transferee. This solution is also referenced by 354 3GPP 24 629 [3GPP.24.629] 356 o MANDATORY: The transferor and the target MUST support RFC 3515 357 (REFER) [RFC3515] and RFC 3265 (Event notifications) [RFC3265]. 359 o OPTIONAL: RFC 3891 ('Replace' header) [RFC3891] and RFC 4538 360 (tdialog) [RFC4538] MAY also be supported by the transferor and 361 the transferee. 363 4.3.3. Using MESSAGE 365 o DESCRIPTION: This particular transfer is only presented into 366 Section 6 of service-examples [I-D.ietf-sipping-service-examples]. 367 Instead of using REFER, this solution proposes that the transferor 368 sends a MESSAGE message to the target or the transferee with the 369 URI of the other party. This solution implicitly relies on an 370 action done by the end user. 372 o MANDATORY: none 374 o OPTIONAL: none 376 4.4. Specifications 378 o RFC 3515 (REFER) [RFC3515] specifies the REFER method which allows 379 a terminal to ask another terminal to send another SIP request. 380 This is the most commonly used method for doing transfer. 382 o When the target receives the REFER request, it sends, in most 383 cases, an INVITE to the transferee. This INVITE carries 384 information about the call which is replaced using RFC 3891 385 ('Replace' header) [RFC3891] and RFC 4538 (tdialog) [RFC4538]. 386 Thanks to this information, the transferee SHOULD accept this 387 INVITE without sending an error '486 Busy Here'. RFC 3892 388 ('Referred-by') [RFC3892] lets it knows who sent the REFER. RFC 389 3893 (Authenticated Identity Body) [RFC3893] allows to sign this 390 information. 392 o REFER implies an event package, RFC 3265 (Event notifications) 393 [RFC3265], that can be suppressed using RFC 4488 (Suppression of 394 events related to REFER) [RFC4488]. This event package allows the 395 transferor to get information about the status of the transfer. 397 INVITE usage also implies to support events as specified in RFC 398 4235 (Event package for INVITE) [RFC4235]. 400 o In order to prevent the INVITE generated by the REFER to reach all 401 terminals of the transferee, GRUU [I-D.ietf-sip-gruu] allows to 402 get a unique address to the user agent concerned by the new 403 INVITE. 405 o Presence [RFC3856] could be a source of information about the 406 status of one user which can help application to define next 407 target of a call. 409 o Users may desire to initiate a transfer which is not managed by 410 their terminal. In this case RFC 4730 [RFC4730] allows 411 intermediaries to receive events from the keypad of the user's 412 terminal. 414 o Like with RFC 3840 [RFC3840] and RFC 3841 [RFC3841], capabilities 415 of the target could be received by the transferor using RFC 4508 416 [RFC4508]. 418 o Privacy [RFC3323] is also a basic requirement for this service. 420 5. Hold 422 5.1. Description 424 It is often useful to prevent the other party from listening to the 425 conversation for a short period. Instead of hearing the other party, 426 the party on hold could hear a music. Moreover, the terminal on hold 427 SHOULD know it is on hold in order to give a correct feedback to the 428 user. 430 5.2. Frameworks and requirements 432 A stage 1 description of this service can be found in 3GPP 22 083 433 [3GPP.22.083]. 435 5.3. Call flow samples 437 5.3.1. Using (re-)INVITE with SDP 'send-only' parameter 439 o DESCRIPTION: In this solution a renegotiation of the media is done 440 using SDP protocol. It establishes a new mono directional 441 communication in order to replace the first bi-directional 442 communication. This solution is presented into 3GPP 24 610 443 [3GPP.24.610] 445 o MANDATORY: none 447 o OPTIONAL: RFC 3725 (3PCC) [RFC3725] could be supported by the 448 party which wants to put the other one on hold. 450 5.4. Specifications 452 o RFC 3725 (3PCC) [RFC3725], is referenced in previous documents to 453 force the other party to listen to music. In that case, the party 454 on hold will generate a third party call between the caller and a 455 media server. 457 o If some music has to be sent from a server, a media server may be 458 involved, this is partially defined into RFC4240 (Media Services) 459 [RFC4240]. 461 6. Call Baring 463 6.1. Description 465 Users SHOULD be able to block, or make any preventive action on 466 unsolicited calls based on a set of rules. This service could be 467 executed either on the endpoint or on an intermediary server. 468 Service provider could also be interested in setting a set of rules 469 on top of users ones. 471 6.2. Frameworks and requirements 473 o draft-froment-sipping-spit-requirements 474 [I-D.froment-sipping-spit-requirements]. This document defines a 475 set of requirements to define policies allowing to make any kind 476 of reactive actions to prevent SPIT. 478 o draft-tschofenig-sipping-framework-spit-reduction 479 [I-D.tschofenig-sipping-framework-spit-reduction]. This document 480 describes a framework for the usage of SPIT policies. 482 o 3GPP 22 088 [3GPP.22.088] from 3GPP specifications gives user's 483 requirements for this service. 485 6.3. Call flow samples 487 6.3.1. Intermediary based call baring 489 o DESCRIPTION: This solution allows a proxy to reject a call before 490 this call actually reaches the end user. This is the most 491 efficient way to prevent undesirable calls such as SPIT. 493 o MANDATORY: none 495 o OPTIONAL: The callee could consider configuring an intermediary, 496 for instance using: spit-policy 497 [I-D.tschofenig-sipping-spit-policy], or CPL [RFC3880], etc. 499 6.3.2. Endpoint based call baring 501 o DESCRIPTION: This solution is not incompatible with the previous 502 one. In that case, the endpoint decides to reject the call using 503 4xx error messages. 505 o MANDATORY: none 507 o OPTIONAL: LESS [I-D.wu-iptel-less] could be a standardized way for 508 implementing this service. 510 6.4. Specifications 512 o spit-policy [I-D.tschofenig-sipping-spit-policy]. This is a 513 policy document format specification proposal for the requirements 514 defined in draft-froment-sipping-spit-requirements 515 [I-D.froment-sipping-spit-requirements]. This can be used to 516 implement Call barring, but scope is larger since it can be used 517 to make white or black lists, or to have different reactive 518 actions (block, polite block, ask for a Turing test, ask for 519 consent, send an email...), depending on the policies. 521 o acr-code [I-D.ietf-sip-acr-code] defines criteria which can be 522 used to reject calls: Privacy [RFC3323], using P-Asserted-Identity 523 header [RFC3325] or by reading the content of From header. RFC 524 5079 (Error 433) [RFC5079] defines an error message '433 Anonymity 525 Disallowed'. 527 o 3GPP 24 611 [3GPP.24.611] defines the service data model to be put 528 on an application server and introduces a set of rules, based on 529 an XML document. 531 o CPL [RFC3880] and LESS [I-D.wu-iptel-less] allow users to write 532 down a set of rules, those are stored on a server for the first 533 one, and in user's terminal for the second one. 535 7. Conference 537 7.1. Description 539 Conference allows more than two peoples to speak together. It may 540 also provide users with some features like allowing to invite 541 somebody inside the conference or moderate the room, ... Most of 542 these requirements are very well defined into RFC 4245 [RFC4245] 544 7.2. Frameworks and requirements 546 o RFC 4245 (Conferencing Requirements) [RFC4245] only defines which 547 conferencing requirements are expected from users. 549 o RFC 4353 (Conferencing Framework) [RFC4353] does not specify any 550 service but terms, roles, actions of each participant, user or 551 software. 553 o RFC 4597 (Conferencing Scenarios) [RFC4597] presents some 554 scenarios of conferences which could lead to some problems unless 555 followed carefully. 557 7.3. Call flow samples 559 o DESCRIPTION: sections 10 and 11 of service-examples 560 [I-D.ietf-sipping-service-examples] show some very basics call 561 flows of conferencing. 563 o MANDATORY: nothing is required for terminals that only want to 564 join a conference room. 566 o OPTIONAL: RFC 4575 (Conference Package) [RFC4575], RFC 4579 567 (Conferencing for User Agent) [RFC4579] could be useful for a 568 terminal willing to control the conference room. 570 7.4. Specifications 572 o RFC 4575 (Conference Package) [RFC4575] allows users to get 573 information over the current room by defining an event package. 574 When a user joins a room, he could, for example, subscribe to this 575 event package and receive notifications when somebody else joins 576 this room. uri-list-conferencing 577 [I-D.ietf-sip-uri-list-conferencing] gives another way to publish 578 his URI while joining the conference and allows other users to 579 retrieve the list of members of the current room. conference- 580 list-event [I-D.koren-sipping-conference-list-event] presents 581 another list of events related to conferences. 583 o RFC 4579 (Conferencing for User Agent) [RFC4579] explains how to 584 add or remove somebody from a conference room by using REFER/ 585 INVITE or REFER/BYE. It also explains how to create a conference 586 room using an INVITE and how headers like Join [RFC3911] or 587 Replace [RFC3891] SHOULD be used. This document also presents 588 features allowing users to change their User Agents without 589 leaving the room or allowing users to convert simple dialog with 590 two parties into a conference. As adding somebody inside a 591 conference is basically a transfer, there is more documentation of 592 this in the "Transfer" section above. 594 o While members of a room MAY NOT have the same capabilities 595 depending on their user agent, conference server may need to 596 perform some transcoding. This is specified into:transc-conf 597 [I-D.ietf-sipping-transc-conf] and 598 [I-D.ietf-sipping-transc-framework]. 600 o 3GPP 24 605 [3GPP.24.605] uses specifications from IETF but 601 includes some documentation about linking a conference server with 602 a PSTN gateway. This document does not include any reference to 603 RFC 4575 (Conference Package) [RFC4575] 605 o RFC 4240 (Media Services) [RFC4240] defines media servers and how 606 they can be used for making announcements. RFC 5022 (MSCML) 607 [RFC5022] explains how to control them. 609 o Even if RFC 3550 (RTP) [RFC3550] is not directly related to SIP, 610 it specifies how RTP streams could be mixed. 612 o adhoc-conferencing [I-D.camarillo-sipping-adhoc-conferencing] 613 gives specifications for using servers in ad-hoc mode. 615 8. Call parking 617 8.1. Description 619 Call parking allows users to put a call on hold, hang up their 620 terminal and retrieve the call from this terminal or from another 621 terminal using a unique URI. 623 8.2. Frameworks and requirements 625 None found 627 8.3. Call flow samples 629 o sections 15 and 16 of service-examples 630 [I-D.ietf-sipping-service-examples] show some very basic call 631 flows of conferencing. 633 8.4. Specifications 635 o A first specification of call parking could be found into: 636 draft-procter-bliss-call-park-extension 637 [I-D.procter-bliss-call-park-extension]. 639 o Call parking could be considered as equivalent to two transfers to 640 a specific type of conference room. In that case, specifications 641 described above could be reused. 643 o The call which is parked could be considered as 'on hold'. 645 9. Do not disturb 647 9.1. Description 649 This service should allow users to prevent temporary calls from one 650 or all users from disturbing him. This means he does not want INVITE 651 messages matching per-defined rules to make his terminal ring because 652 he will not answer. 654 There is, at the present time, no particular specification. (other 655 than sending an error message from RFC 3261 [RFC3261], for example, 656 to the caller). However a draft: draft-elwell-bliss-dnd-00 657 [I-D.elwell-bliss-dnd] provides an analysis of the current situation. 659 9.2. Frameworks and requirements 661 None found 663 9.3. Call flow samples 665 None found 667 9.4. Specifications 669 None found 671 10. Call Completion 673 10.1. Description 675 o This service enables the caller to establish a communication with 676 the callee even if at the time of the communication initiation, 677 the callee is not able to answer the call (busy, not available, 678 ...) without having to restart a new communication. 680 10.2. Frameworks and requirements 682 o EN 301 134 [EN301134] describes these services from the end user 683 side. This document describes only the case where the user, in 684 switched circuit environment has no free channel available to 685 receive the current call. In a SIP environment, this can be 686 compared with the error '486 Busy Here'. 688 10.3. Call flow samples 690 None found 692 10.4. Specifications 694 o ietf-bliss-call-completion [I-D.ietf-bliss-call-completion] 695 proposes a specification where the service is implemented thanks 696 to a new event package. 698 o 3GPP 24 615 [3GPP.24.615] gives some details about call waiting 699 service. 701 11. Conclusion 703 This version shows that specifications are actually numerous. It 704 also shows that there is a lack of framework and requirements. 705 Information is difficult to find, and is sometimes hidden in 706 individual contributions which are not always understood by non-IETF 707 people as "unofficial". It MAY partially explain why SIP services 708 implementers are not always satisfied and it clearly does not help 709 interoperability. That's why this document was created. Some 710 external references, like the ISDN specifications, have a different 711 objective and are difficult to compare since they take some 712 assumptions on the network architecture. Proposal of this document 713 on this problem is to split the problem in two parts: the pure- 714 endpoint based architectures, and the others based on an 715 intermediary. 717 We do believe that all these specifications are a good illustration 718 of "what is done elsewhere", and that it may be taken as input for 719 building BLISS recommendations. 721 12. IANA Considerations 723 This document does not require any actions by IANA. 725 13. Security Considerations 727 TBC 729 14. Acknowledgments 730 15. References 732 15.1. Normative References 734 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 735 Requirement Levels", March 1997. 737 15.2. Informative References 739 [3GPP.22.082] 740 3GPP, "Call Forwarding (CF) Supplementary Services; Stage 741 1", 3GPP TS 22.082 3.0.2, March 2004. 743 [3GPP.22.083] 744 3GPP, "Call Waiting (CW) and Call Hold (HOLD) 745 supplementary services; Stage 1", 3GPP TS 22.083 3.0.1, 746 October 1999. 748 [3GPP.22.088] 749 3GPP, "Call Barring (CB) supplementary services; Stage 1", 750 3GPP TS 22.088 3.0.2, November 2000. 752 [3GPP.22.091] 753 3GPP, "Explicit Call Transfer (ECT) supplementary service; 754 Stage 1", 3GPP TS 22.091 3.1.0, October 2000. 756 [3GPP.24.505] 757 3GPP, "TISPAN; PSTN/ISDN simulation services: Conference 758 (CONF); Protocol specification", 3GPP TS 24.505 8.0.0, 759 March 2008. 761 [3GPP.24.604] 762 3GPP, "Communication Diversion (CDIV) using IP Multimedia 763 (IM)Core Network (CN) subsystem; Protocol specification", 764 3GPP TS 24.604 8.0.0, June 2008. 766 [3GPP.24.605] 767 3GPP, "Conference (CONF)using IP Multimedia (IM) Core 768 Network (CN) subsystem; Protocol specification", 3GPP 769 TS 24.605 8.0.0, June 2008. 771 [3GPP.24.610] 772 3GPP, "Communication HOLD (HOLD) using IP Multimedia (IM) 773 Core Network (CN) subsystem; Protocol specification", 3GPP 774 TS 24.610 8.0.0, June 2008. 776 [3GPP.24.611] 777 3GPP, "Anonymous Communication Rejection (ACR) and 778 Communication Barring (CB)using IP Multimedia (IM) Core 779 Network (CN) subsystem; Protocol specification", 3GPP 780 TS 24.611 8.0.1, June 2008. 782 [3GPP.24.615] 783 3GPP, "Communication Waiting (CW) using IP Multimedia (IM) 784 Core Network (CN) subsystem; Protocol Specfication", 3GPP 785 TS 24.615 0.3.0, May 2008. 787 [3GPP.24.629] 788 3GPP, "Explicit Communication Transfer (ECT)using IP 789 Multimedia (IM)Core Network (CN) subsystem;; Protocol 790 specification", 3GPP TS 24.629 8.0.0, June 2008. 792 [EN301134] 793 "Integrated Services Digital Network (ISDN); Completion of 794 Calls on No Reply (CCNR); supplementary service; Service 795 description", 2005. 797 [I-D.camarillo-sipping-adhoc-conferencing] 798 Camarillo, G. and A. Johnston, "Ad-Hoc Conferencing in the 799 Session Initiation Protocol (SIP)", 800 draft-camarillo-sipping-adhoc-conferencing-00 (work in 801 progress), March 2004. 803 [I-D.elwell-bliss-dnd] 804 Elwell, J. and S. Srinivasan, "An Analysis of Do Not 805 Disturb (DND) Implementations in the Session Initiation 806 Protocol (SIP)", draft-elwell-bliss-dnd-01 (work in 807 progress), November 2007. 809 [I-D.froment-sipping-spit-requirements] 810 Tschofenig, H., Dawirs, G., Froment, T., Wing, D., and H. 811 Schulzrinne, "Requirements for Authorization Policies to 812 tackle Spam and Unwanted Communication for Internet 813 Telephony", draft-froment-sipping-spit-requirements-02 814 (work in progress), February 2008. 816 [I-D.ietf-bliss-ach-analysis] 817 Elwell, J., "An Analysis of Automatic Call Handling 818 Implementation Issues in the Session Initiation Protocol 819 (SIP)", draft-ietf-bliss-ach-analysis-02 (work in 820 progress), May 2008. 822 [I-D.ietf-bliss-call-completion] 823 Worley, D., Huelsemann, M., and D. Alexeitsev, "Call 824 Completion for Session Initiation Protocol (SIP)", 825 draft-ietf-bliss-call-completion-02 (work in progress), 826 June 2008. 828 [I-D.ietf-bliss-problem-statement] 829 Rosenberg, J., "Basic Level of Interoperability for 830 Session Initiation Protocol (SIP) Services (BLISS) 831 Problem Statement", draft-ietf-bliss-problem-statement-02 832 (work in progress), February 2008. 834 [I-D.ietf-sip-acr-code] 835 Rosenberg, J., "Rejecting Anonymous Requests in the 836 Session Initiation Protocol (SIP)", 837 draft-ietf-sip-acr-code-05 (work in progress), July 2007. 839 [I-D.ietf-sip-gruu] 840 Rosenberg, J., "Obtaining and Using Globally Routable User 841 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 842 (SIP)", draft-ietf-sip-gruu-15 (work in progress), 843 October 2007. 845 [I-D.ietf-sip-uri-list-conferencing] 846 Camarillo, G. and A. Johnston, "Conference Establishment 847 Using Request-Contained Lists in the Session Initiation 848 Protocol (SIP)", draft-ietf-sip-uri-list-conferencing-02 849 (work in progress), November 2007. 851 [I-D.ietf-sipping-cc-transfer] 852 Sparks, R., "Session Initiation Protocol Call Control - 853 Transfer", draft-ietf-sipping-cc-transfer-09 (work in 854 progress), December 2007. 856 [I-D.ietf-sipping-service-examples] 857 Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and 858 K. Summers, "Session Initiation Protocol Service 859 Examples", draft-ietf-sipping-service-examples-14 (work in 860 progress), February 2008. 862 [I-D.ietf-sipping-transc-conf] 863 Camarillo, G., "The Session Initiation Protocol (SIP) 864 Conference Bridge Transcoding Model", 865 draft-ietf-sipping-transc-conf-03 (work in progress), 866 June 2006. 868 [I-D.ietf-sipping-transc-framework] 869 Camarillo, G., "Framework for Transcoding with the Session 870 Initiation Protocol (SIP)", 871 draft-ietf-sipping-transc-framework-05 (work in progress), 872 December 2006. 874 [I-D.koren-sipping-conference-list-event] 875 Fortinsky, M., Ravid, I., and O. Koren, "A Conference List 876 Information Event Package for the Session Initiation 877 Protocol (SIP)", 878 draft-koren-sipping-conference-list-event-03 (work in 879 progress), July 2008. 881 [I-D.procter-bliss-call-park-extension] 882 Procter, M., "Implementing Call Park and Retrieve using 883 the Session Initiation Protocol (SIP)", 884 draft-procter-bliss-call-park-extension-01 (work in 885 progress), February 2008. 887 [I-D.tschofenig-sipping-framework-spit-reduction] 888 Tschofenig, H., Schulzrinne, H., Wing, D., Rosenberg, J., 889 and D. Schwartz, "A Framework to tackle Spam and Unwanted 890 Communication for Internet Telephony", 891 draft-tschofenig-sipping-framework-spit-reduction-03 (work 892 in progress), February 2008. 894 [I-D.tschofenig-sipping-spit-policy] 895 Tschofenig, H., Wing, D., Schulzrinne, H., Froment, T., 896 and G. Dawirs, "A Document Format for Expressing 897 Authorization Policies to tackle Spam and Unwanted 898 Communication for Internet Telephony", 899 draft-tschofenig-sipping-spit-policy-02 (work in 900 progress), November 2007. 902 [I-D.wu-iptel-less] 903 Wu, X. and H. Schulzrinne, "LESS: Language for End System 904 Services in Internet Telephony", draft-wu-iptel-less-00 905 (work in progress), February 2005. 907 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 908 A., Peterson, J., Sparks, R., Handley, M., and E. 909 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 910 June 2002. 912 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 913 Event Notification", RFC 3265, June 2002. 915 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 916 Initiation Protocol (SIP)", RFC 3323, November 2002. 918 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 919 Extensions to the Session Initiation Protocol (SIP) for 920 Asserted Identity within Trusted Networks", RFC 3325, 921 November 2002. 923 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 924 Method", RFC 3515, April 2003. 926 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 927 Jacobson, "RTP: A Transport Protocol for Real-Time 928 Applications", STD 64, RFC 3550, July 2003. 930 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 931 Camarillo, "Best Current Practices for Third Party Call 932 Control (3pcc) in the Session Initiation Protocol (SIP)", 933 BCP 85, RFC 3725, April 2004. 935 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 936 "Indicating User Agent Capabilities in the Session 937 Initiation Protocol (SIP)", RFC 3840, August 2004. 939 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 940 Preferences for the Session Initiation Protocol (SIP)", 941 RFC 3841, August 2004. 943 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 944 Initiation Protocol (SIP)", RFC 3856, August 2004. 946 [RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing 947 Language (CPL): A Language for User Control of Internet 948 Telephony Services", RFC 3880, October 2004. 950 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 951 Protocol (SIP) "Replaces" Header", RFC 3891, 952 September 2004. 954 [RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) 955 Referred-By Mechanism", RFC 3892, September 2004. 957 [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) 958 Authenticated Identity Body (AIB) Format", RFC 3893, 959 September 2004. 961 [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol 962 (SIP) "Join" Header", RFC 3911, October 2004. 964 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 965 Initiated Dialog Event Package for the Session Initiation 966 Protocol (SIP)", RFC 4235, November 2005. 968 [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network 969 Media Services with SIP", RFC 4240, December 2005. 971 [RFC4244] Barnes, M., "An Extension to the Session Initiation 972 Protocol (SIP) for Request History Information", RFC 4244, 973 November 2005. 975 [RFC4245] Levin, O. and R. Even, "High-Level Requirements for 976 Tightly Coupled SIP Conferencing", RFC 4245, 977 November 2005. 979 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 980 Session Initiation Protocol (SIP)", RFC 4353, 981 February 2006. 983 [RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session 984 Initiation Protocol (SIP) URIs for Applications such as 985 Voicemail and Interactive Voice Response (IVR)", RFC 4458, 986 April 2006. 988 [RFC4488] Levin, O., "Suppression of Session Initiation Protocol 989 (SIP) REFER Method Implicit Subscription", RFC 4488, 990 May 2006. 992 [RFC4508] Levin, O. and A. Johnston, "Conveying Feature Tags with 993 the Session Initiation Protocol (SIP) REFER Method", 994 RFC 4508, May 2006. 996 [RFC4538] Rosenberg, J., "Request Authorization through Dialog 997 Identification in the Session Initiation Protocol (SIP)", 998 RFC 4538, June 2006. 1000 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 1001 Initiation Protocol (SIP) Event Package for Conference 1002 State", RFC 4575, August 2006. 1004 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 1005 (SIP) Call Control - Conferencing for User Agents", 1006 BCP 119, RFC 4579, August 2006. 1008 [RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", 1009 RFC 4597, August 2006. 1011 [RFC4730] Burger, E. and M. Dolly, "A Session Initiation Protocol 1012 (SIP) Event Package for Key Press Stimulus (KPML)", 1013 RFC 4730, November 2006. 1015 [RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server 1016 Control Markup Language (MSCML) and Protocol", RFC 5022, 1017 September 2007. 1019 [RFC5079] Rosenberg, J., "Rejecting Anonymous Requests in the 1020 Session Initiation Protocol (SIP)", RFC 5079, 1021 December 2007. 1023 Authors' Addresses 1025 Arnaud Ligot 1026 University of Namur 1027 Rue Grandgagnage 1028 Namur 5000 1029 Belgium 1031 Email: arnaud@cblue.be 1033 Thomas Froment 1034 Alcatel-Lucent 1035 Centre de Villarceaux, Route de Villejust 1036 Nozay, Paris 91620 1037 France 1039 Email: Thomas.Froment@alcatel-lucent.fr 1041 Full Copyright Statement 1043 Copyright (C) The IETF Trust (2008). 1045 This document is subject to the rights, licenses and restrictions 1046 contained in BCP 78, and except as set forth therein, the authors 1047 retain all their rights. 1049 This document and the information contained herein are provided on an 1050 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1051 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1052 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1053 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1054 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1055 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1057 Intellectual Property 1059 The IETF takes no position regarding the validity or scope of any 1060 Intellectual Property Rights or other rights that might be claimed to 1061 pertain to the implementation or use of the technology described in 1062 this document or the extent to which any license under such rights 1063 might or might not be available; nor does it represent that it has 1064 made any independent effort to identify any such rights. Information 1065 on the procedures with respect to rights in RFC documents can be 1066 found in BCP 78 and BCP 79. 1068 Copies of IPR disclosures made to the IETF Secretariat and any 1069 assurances of licenses to be made available, or the result of an 1070 attempt made to obtain a general license or permission for the use of 1071 such proprietary rights by implementers or users of this 1072 specification can be obtained from the IETF on-line IPR repository at 1073 http://www.ietf.org/ipr. 1075 The IETF invites any interested party to bring to its attention any 1076 copyrights, patents or patent applications, or other proprietary 1077 rights that may cover technology that may be required to implement 1078 this standard. Please address the information to the IETF at 1079 ietf-ipr@ietf.org. 1081 Acknowledgment 1083 Funding for the RFC Editor function is provided by the IETF 1084 Administrative Support Activity (IASA).