Network Working Group A. Ligot Internet-Draft University of Namur Intended status: Informational T. Froment Expires: January 15, 2009 Alcatel-Lucent July 14, 2008 Providing guidance for Session Initiation Protocol (SIP) services draft-ligot-bliss-sip-services-guide-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 15, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Ligot & Froment Expires January 15, 2009 [Page 1] Internet-Draft SIP Services Guide July 2008 Abstract Implementing Session Initiation Protocol (SIP) advanced features and services requires to use numerous specifications. Today, for each service in the scope of BLISS, one can already find references to many possible specifications which do not cover the same things. Some of them are primitive operations, requirements or call flow examples, some have a scope larger than the others, or can not be compared at the same level. Very often, architecture hypothesis are hidden behind the same service name, either assuming that an intermediary; like an application server, has an active role in the service, or, as opposed, assuming a pure end-to-end model where only endpoint implementations are involved. The goal of this document is not to present the best solutions or give recommendations; but to give an overview of every standard specification related to these services, centralizing and categorizing them as input to the working group. Ligot & Froment Expires January 15, 2009 [Page 2] Internet-Draft SIP Services Guide July 2008 Table of Contents 1. Introduction, scope . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Call Forwarding . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Description . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Frameworks and requirements . . . . . . . . . . . . . . . 8 3.3. Call flow samples . . . . . . . . . . . . . . . . . . . . 8 3.3.1. Endpoint based Call Forwarding . . . . . . . . . . . . 8 3.3.2. Intermediary based Call Forwarding . . . . . . . . . . 8 3.4. Specifications . . . . . . . . . . . . . . . . . . . . . . 9 4. Call Transfer . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Description . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Frameworks and requirements . . . . . . . . . . . . . . . 10 4.3. Call flow samples . . . . . . . . . . . . . . . . . . . . 10 4.3.1. Using REFER from the transferor to the transferee . . 10 4.3.2. Using REFER from the transferor to the target . . . . 11 4.3.3. Using MESSAGE . . . . . . . . . . . . . . . . . . . . 11 4.4. Specifications . . . . . . . . . . . . . . . . . . . . . . 11 5. Hold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Frameworks and requirements . . . . . . . . . . . . . . . 13 5.3. Call flow samples . . . . . . . . . . . . . . . . . . . . 13 5.3.1. Using (re-)INVITE with SDP 'send-only' parameter . . . 13 5.4. Specifications . . . . . . . . . . . . . . . . . . . . . . 13 6. Call Baring . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Frameworks and requirements . . . . . . . . . . . . . . . 14 6.3. Call flow samples . . . . . . . . . . . . . . . . . . . . 14 6.3.1. Intermediary based call baring . . . . . . . . . . . . 14 6.3.2. Endpoint based call baring . . . . . . . . . . . . . . 14 6.4. Specifications . . . . . . . . . . . . . . . . . . . . . . 15 7. Conference . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 16 7.2. Frameworks and requirements . . . . . . . . . . . . . . . 16 7.3. Call flow samples . . . . . . . . . . . . . . . . . . . . 16 7.4. Specifications . . . . . . . . . . . . . . . . . . . . . . 16 8. Call parking . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Description . . . . . . . . . . . . . . . . . . . . . . . 18 8.2. Frameworks and requirements . . . . . . . . . . . . . . . 18 8.3. Call flow samples . . . . . . . . . . . . . . . . . . . . 18 8.4. Specifications . . . . . . . . . . . . . . . . . . . . . . 18 9. Do not disturb . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Description . . . . . . . . . . . . . . . . . . . . . . . 19 9.2. Frameworks and requirements . . . . . . . . . . . . . . . 19 9.3. Call flow samples . . . . . . . . . . . . . . . . . . . . 19 9.4. Specifications . . . . . . . . . . . . . . . . . . . . . . 19 10. Call Completion . . . . . . . . . . . . . . . . . . . . . . . 20 Ligot & Froment Expires January 15, 2009 [Page 3] Internet-Draft SIP Services Guide July 2008 10.1. Description . . . . . . . . . . . . . . . . . . . . . . . 20 10.2. Frameworks and requirements . . . . . . . . . . . . . . . 20 10.3. Call flow samples . . . . . . . . . . . . . . . . . . . . 20 10.4. Specifications . . . . . . . . . . . . . . . . . . . . . . 20 11. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 13. Security Considerations . . . . . . . . . . . . . . . . . . . 23 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 15.1. Normative References . . . . . . . . . . . . . . . . . . . 25 15.2. Informative References . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Intellectual Property and Copyright Statements . . . . . . . . . . 33 Ligot & Froment Expires January 15, 2009 [Page 4] Internet-Draft SIP Services Guide July 2008 1. Introduction, scope BLISS working group is chartered to facilitate effective feature interoperability for advanced services sharing common functional primitives utilizing SIP. In particular, it focuses on advanced call features requiring non-trivial call control. The objective of this document is not to give recommendation or to give a technical appreciation of referenced specifications. So, references that could be found in this document SHOULD NOT be considered as the recommended way of implementing any service. This document aims at providing the current "snapshot" of "SIP services" specifications, centralizing what currently exist. This first version presented here shows that the number of specifications around call features is quite impressive, sometimes individual drafts have addressed a very specific problem that has been forgotten in the Internet draft morgue. Some other specifications like ISDN ones have to be considered from a different point of view: they are most of the time referencing existing IETF specifications when they exist, generally trying to additionally standardize the format of a user profile which contains the configuration elements of the service. This approach assumes that there is a user profile database, operated somewhere, which is of course out of IETF scope. In that case, goal is indeed not to give any appreciation on these external specifications, but to describe which differences may exist between them, and if they diverge, try to explain why. Thus, this document categorizes them in order to outline what is currently missing and which documents can be compared at the same "level". Indeed, very often, the confusion around service specifications arises when this it not clear if it can be assumed that an 'active intermediary' (a proxy, B2BUA, application server....) contributes to the service implementation or not. Difficulty is increased by the fact architecture considerations are clearly out of IETF scope, but still need to be taken into account when providing recommendations. This document clarifies this situation each time it is possible, outlining if the referenced specifications assume a "pure end-to-end" or an "intermediary" model. For that purpose it separates the call flows in two sub-sections called "Endpoint based" or "Intermediary based". This is of course a simplification of the architecture alternatives, but it appears to be enough to clarify the discussion. Today, service categories that are considered as in-scope of BLISS are the following: o Call forwarding Ligot & Froment Expires January 15, 2009 [Page 5] Internet-Draft SIP Services Guide July 2008 o Call Transfer o Hold o Call Baring o Conference o Call parking o Do not disturb o Call completion This list will be the starting point of this guide, it MAY be extended to other topics in the future if it is considered as useful. For each of these services, it provides: o first, a short description of the service; o second, user's requirements or frameworks which give grounds of any implementation; o third, references to documents that contain call flows showing the application of the service; o inally, a short description of any specification that has been identified (possibly erroneously) as useful to implement a service, giving some "hints" on why it is referenced in this context In this third version ISDN and TISPAN references has been replaced with 3GPP specifications. Theses specifications are more up to date and sometimes more complete. While this is not a particular service, it should be noted that BLISS working group is working on a draft about automatic call handling: ACH [I-D.ietf-bliss-ach-analysis] Ligot & Froment Expires January 15, 2009 [Page 6] Internet-Draft SIP Services Guide July 2008 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Ligot & Froment Expires January 15, 2009 [Page 7] Internet-Draft SIP Services Guide July 2008 3. Call Forwarding 3.1. Description Call forwarding allows users to divert a call from its destination without answering it. There are a few cases of call forwarding. For example, users should be able to forward calls towards another person when he is already on the phone, when he does not answer or when he is unavailable. Call forwarding should also allow users to setup unconditional forwarding based on a set of rules. Call forwarding always occur before the establishment of the call (see Call Transfer). 'Call Forwarding' (CFx) is also called 'Call diversion' (CDIV). 3.2. Frameworks and requirements o 3GPP 22 082 [3GPP.22.082], from 3GPP specification gives general specifications of call forwarding and provides requirements, terminology and definitions. 3.3. Call flow samples 3.3.1. Endpoint based Call Forwarding o DESCRIPTION: endpoints can also implement call forwarding. No specification example of this solution has been found. o MANDATORY: no mandatory specification found for this service. o OPTIONAL: terminals that implements this kind of forwarding could base their implementation on LESS [I-D.wu-iptel-less] 3.3.2. Intermediary based Call Forwarding o DESCRIPTION: sections 7,8,9 of [I-D.ietf-sipping-service-examples] present some cases of call forwarding. These call flows are mainly implementation dependent. 3GPP 24 604 [3GPP.24.604], from TISPAN, uses call flows like those from sipping-service-examples. It just additionally defines the user profile data model related to this service. The same technique of call forwarding is also described into section 3.1 of [I-D.ietf-bliss-problem-statement]. o MANDATORY: none o OPTIONAL: RFC 3880 (CPL) [RFC3880] or TISPAN profile defined into 3GPP 24 604 [3GPP.24.604] can be used by the user to tell the configuration to the server. RFC 4458 (URI for applications) Ligot & Froment Expires January 15, 2009 [Page 8] Internet-Draft SIP Services Guide July 2008 [RFC4458] and RFC 4244 (history-info) [RFC4244] can be used to add information about the diversion inside the SIP dialog 3.4. Specifications o RFC 4458 (URI for applications) [RFC4458] specifies two new parameters for the contact field that could be added when a call is forwarded. These parameters are 'cause' and 'target': they allow voicemails, for instance, to send an adapted greeting to the caller who has been transferred. o RFC 4244 (history-info) [RFC4244] introduces a new optional header: 'history-info' which contains the list of previous target URIs of the call and could contain additional values such as the cause of each call forwarding, levels of privacy, etc. o 3GPP 24 604 [3GPP.24.604] from 3GPP present a solution based on a centralized server. This specification even specifies a way for the user to send the expected configuration to the server. o RFC 3880 (CPL) [RFC3880], CPL, presents a XML based script language which can be used by end users in order to upload rules of call forwarding to their proxy. The proxy should interpret this set of rules and apply them without any action from the endpoint. o Like CPL, LESS [I-D.wu-iptel-less] is a language that could be used to configure call forwarding but on the end point side. o RFC 3841 [RFC3841] could be used to register fall back destination for a user. While this specification can be use in order to implement a particular kind of call forwarding, this is not the primary goal of this specification. However, this specification could be useful to allow a caller, in particular conditions, to bypass or cancel a call forwarding. For instance, the specification shows an example where the caller refuses to be transferred to a voicemail; in that case, appropriate error messages are sent. o As call forwarding often comes with privacy requirements, RFC 3323 [RFC3323] could be helpful but it also introduces some requirements over the network infrastructure since it assumes a privacy server is deployed somewhere. Ligot & Froment Expires January 15, 2009 [Page 9] Internet-Draft SIP Services Guide July 2008 4. Call Transfer 4.1. Description Call transfer occurs when a communication is already established between parties and one of them, the transferor, wants to transfer the other party, the transferee, to another party, the target, which is not already a member of the on going dialog. Requirements for this services often include privacy and authentication. The target of a transfer could also be a service, a conference room, or something else... Transfer could be "managed". In this case, the transferor invites the target, establishes a communication with it while the other party is usually on hold and then ends its communication with it. Finally, it transfers the transferee to the target. 4.2. Frameworks and requirements o Section 4 of cc-transfer [I-D.ietf-sipping-cc-transfer] gives the requirements of such service. o 3GPP 22 091 [3GPP.22.091], from 3GPP specifications, like the previous one gives a complete description of the service including user's requirements. 4.3. Call flow samples 4.3.1. Using REFER from the transferor to the transferee o DESCRIPTION: Sections 4 and 5 of service-examples [I-D.ietf-sipping-service-examples] show some basic call flows of transfer using a REFER message sent by the transferor, the user who wants to transfer the other party in the current dialog. This solution is also used in draft-ietf-sipping-cc-transfer [I-D.ietf-sipping-cc-transfer] for instance, in section 6. o MANDATORY: Both parties MUST support RFC 3515 (REFER) [RFC3515]. This also implies the support of RFC 3265 (Event notifications) [RFC3265] o OPTIONAL: RFC 3892 ('Referred-by') [RFC3892] Ligot & Froment Expires January 15, 2009 [Page 10] Internet-Draft SIP Services Guide July 2008 4.3.2. Using REFER from the transferor to the target o DESCRIPTION: draft-ietf-sipping-cc-transfer, section 7.2 [I-D.ietf-sipping-cc-transfer]. This solution, unlike the previous one, allows the transferor to hide the sip URI of the target to the transferee. This solution is also referenced by 3GPP 24 629 [3GPP.24.629] o MANDATORY: The transferor and the target MUST support RFC 3515 (REFER) [RFC3515] and RFC 3265 (Event notifications) [RFC3265]. o OPTIONAL: RFC 3891 ('Replace' header) [RFC3891] and RFC 4538 (tdialog) [RFC4538] MAY also be supported by the transferor and the transferee. 4.3.3. Using MESSAGE o DESCRIPTION: This particular transfer is only presented into Section 6 of service-examples [I-D.ietf-sipping-service-examples]. Instead of using REFER, this solution proposes that the transferor sends a MESSAGE message to the target or the transferee with the URI of the other party. This solution implicitly relies on an action done by the end user. o MANDATORY: none o OPTIONAL: none 4.4. Specifications o RFC 3515 (REFER) [RFC3515] specifies the REFER method which allows a terminal to ask another terminal to send another SIP request. This is the most commonly used method for doing transfer. o When the target receives the REFER request, it sends, in most cases, an INVITE to the transferee. This INVITE carries information about the call which is replaced using RFC 3891 ('Replace' header) [RFC3891] and RFC 4538 (tdialog) [RFC4538]. Thanks to this information, the transferee SHOULD accept this INVITE without sending an error '486 Busy Here'. RFC 3892 ('Referred-by') [RFC3892] lets it knows who sent the REFER. RFC 3893 (Authenticated Identity Body) [RFC3893] allows to sign this information. o REFER implies an event package, RFC 3265 (Event notifications) [RFC3265], that can be suppressed using RFC 4488 (Suppression of events related to REFER) [RFC4488]. This event package allows the transferor to get information about the status of the transfer. Ligot & Froment Expires January 15, 2009 [Page 11] Internet-Draft SIP Services Guide July 2008 INVITE usage also implies to support events as specified in RFC 4235 (Event package for INVITE) [RFC4235]. o In order to prevent the INVITE generated by the REFER to reach all terminals of the transferee, GRUU [I-D.ietf-sip-gruu] allows to get a unique address to the user agent concerned by the new INVITE. o Presence [RFC3856] could be a source of information about the status of one user which can help application to define next target of a call. o Users may desire to initiate a transfer which is not managed by their terminal. In this case RFC 4730 [RFC4730] allows intermediaries to receive events from the keypad of the user's terminal. o Like with RFC 3840 [RFC3840] and RFC 3841 [RFC3841], capabilities of the target could be received by the transferor using RFC 4508 [RFC4508]. o Privacy [RFC3323] is also a basic requirement for this service. Ligot & Froment Expires January 15, 2009 [Page 12] Internet-Draft SIP Services Guide July 2008 5. Hold 5.1. Description It is often useful to prevent the other party from listening to the conversation for a short period. Instead of hearing the other party, the party on hold could hear a music. Moreover, the terminal on hold SHOULD know it is on hold in order to give a correct feedback to the user. 5.2. Frameworks and requirements A stage 1 description of this service can be found in 3GPP 22 083 [3GPP.22.083]. 5.3. Call flow samples 5.3.1. Using (re-)INVITE with SDP 'send-only' parameter o DESCRIPTION: In this solution a renegotiation of the media is done using SDP protocol. It establishes a new mono directional communication in order to replace the first bi-directional communication. This solution is presented into 3GPP 24 610 [3GPP.24.610] o MANDATORY: none o OPTIONAL: RFC 3725 (3PCC) [RFC3725] could be supported by the party which wants to put the other one on hold. 5.4. Specifications o RFC 3725 (3PCC) [RFC3725], is referenced in previous documents to force the other party to listen to music. In that case, the party on hold will generate a third party call between the caller and a media server. o If some music has to be sent from a server, a media server may be involved, this is partially defined into RFC4240 (Media Services) [RFC4240]. Ligot & Froment Expires January 15, 2009 [Page 13] Internet-Draft SIP Services Guide July 2008 6. Call Baring 6.1. Description Users SHOULD be able to block, or make any preventive action on unsolicited calls based on a set of rules. This service could be executed either on the endpoint or on an intermediary server. Service provider could also be interested in setting a set of rules on top of users ones. 6.2. Frameworks and requirements o draft-froment-sipping-spit-requirements [I-D.froment-sipping-spit-requirements]. This document defines a set of requirements to define policies allowing to make any kind of reactive actions to prevent SPIT. o draft-tschofenig-sipping-framework-spit-reduction [I-D.tschofenig-sipping-framework-spit-reduction]. This document describes a framework for the usage of SPIT policies. o 3GPP 22 088 [3GPP.22.088] from 3GPP specifications gives user's requirements for this service. 6.3. Call flow samples 6.3.1. Intermediary based call baring o DESCRIPTION: This solution allows a proxy to reject a call before this call actually reaches the end user. This is the most efficient way to prevent undesirable calls such as SPIT. o MANDATORY: none o OPTIONAL: The callee could consider configuring an intermediary, for instance using: spit-policy [I-D.tschofenig-sipping-spit-policy], or CPL [RFC3880], etc. 6.3.2. Endpoint based call baring o DESCRIPTION: This solution is not incompatible with the previous one. In that case, the endpoint decides to reject the call using 4xx error messages. o MANDATORY: none o OPTIONAL: LESS [I-D.wu-iptel-less] could be a standardized way for implementing this service. Ligot & Froment Expires January 15, 2009 [Page 14] Internet-Draft SIP Services Guide July 2008 6.4. Specifications o spit-policy [I-D.tschofenig-sipping-spit-policy]. This is a policy document format specification proposal for the requirements defined in draft-froment-sipping-spit-requirements [I-D.froment-sipping-spit-requirements]. This can be used to implement Call barring, but scope is larger since it can be used to make white or black lists, or to have different reactive actions (block, polite block, ask for a Turing test, ask for consent, send an email...), depending on the policies. o acr-code [I-D.ietf-sip-acr-code] defines criteria which can be used to reject calls: Privacy [RFC3323], using P-Asserted-Identity header [RFC3325] or by reading the content of From header. RFC 5079 (Error 433) [RFC5079] defines an error message '433 Anonymity Disallowed'. o 3GPP 24 611 [3GPP.24.611] defines the service data model to be put on an application server and introduces a set of rules, based on an XML document. o CPL [RFC3880] and LESS [I-D.wu-iptel-less] allow users to write down a set of rules, those are stored on a server for the first one, and in user's terminal for the second one. Ligot & Froment Expires January 15, 2009 [Page 15] Internet-Draft SIP Services Guide July 2008 7. Conference 7.1. Description Conference allows more than two peoples to speak together. It may also provide users with some features like allowing to invite somebody inside the conference or moderate the room, ... Most of these requirements are very well defined into RFC 4245 [RFC4245] 7.2. Frameworks and requirements o RFC 4245 (Conferencing Requirements) [RFC4245] only defines which conferencing requirements are expected from users. o RFC 4353 (Conferencing Framework) [RFC4353] does not specify any service but terms, roles, actions of each participant, user or software. o RFC 4597 (Conferencing Scenarios) [RFC4597] presents some scenarios of conferences which could lead to some problems unless followed carefully. 7.3. Call flow samples o DESCRIPTION: sections 10 and 11 of service-examples [I-D.ietf-sipping-service-examples] show some very basics call flows of conferencing. o MANDATORY: nothing is required for terminals that only want to join a conference room. o OPTIONAL: RFC 4575 (Conference Package) [RFC4575], RFC 4579 (Conferencing for User Agent) [RFC4579] could be useful for a terminal willing to control the conference room. 7.4. Specifications o RFC 4575 (Conference Package) [RFC4575] allows users to get information over the current room by defining an event package. When a user joins a room, he could, for example, subscribe to this event package and receive notifications when somebody else joins this room. uri-list-conferencing [I-D.ietf-sip-uri-list-conferencing] gives another way to publish his URI while joining the conference and allows other users to retrieve the list of members of the current room. conference- list-event [I-D.koren-sipping-conference-list-event] presents another list of events related to conferences. Ligot & Froment Expires January 15, 2009 [Page 16] Internet-Draft SIP Services Guide July 2008 o RFC 4579 (Conferencing for User Agent) [RFC4579] explains how to add or remove somebody from a conference room by using REFER/ INVITE or REFER/BYE. It also explains how to create a conference room using an INVITE and how headers like Join [RFC3911] or Replace [RFC3891] SHOULD be used. This document also presents features allowing users to change their User Agents without leaving the room or allowing users to convert simple dialog with two parties into a conference. As adding somebody inside a conference is basically a transfer, there is more documentation of this in the "Transfer" section above. 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]. o 3GPP 24 605 [3GPP.24.605] uses specifications from IETF but includes some documentation about linking a conference server with a PSTN gateway. This document does not include any reference to RFC 4575 (Conference Package) [RFC4575] o RFC 4240 (Media Services) [RFC4240] defines media servers and how they can be used for making announcements. RFC 5022 (MSCML) [RFC5022] explains how to control them. o Even if RFC 3550 (RTP) [RFC3550] is not directly related to SIP, it specifies how RTP streams could be mixed. o adhoc-conferencing [I-D.camarillo-sipping-adhoc-conferencing] gives specifications for using servers in ad-hoc mode. Ligot & Froment Expires January 15, 2009 [Page 17] Internet-Draft SIP Services Guide July 2008 8. Call parking 8.1. Description Call parking allows users to put a call on hold, hang up their terminal and retrieve the call from this terminal or from another terminal using a unique URI. 8.2. Frameworks and requirements None found 8.3. Call flow samples o sections 15 and 16 of service-examples [I-D.ietf-sipping-service-examples] show some very basic call flows of conferencing. 8.4. Specifications o A first specification of call parking could be found into: draft-procter-bliss-call-park-extension [I-D.procter-bliss-call-park-extension]. o Call parking could be considered as equivalent to two transfers to a specific type of conference room. In that case, specifications described above could be reused. o The call which is parked could be considered as 'on hold'. Ligot & Froment Expires January 15, 2009 [Page 18] Internet-Draft SIP Services Guide July 2008 9. Do not disturb 9.1. Description This service should allow users to prevent temporary calls from one or all users from disturbing him. This means he does not want INVITE messages matching per-defined rules to make his terminal ring because he will not answer. There is, at the present time, no particular specification. (other than sending an error message from RFC 3261 [RFC3261], for example, to the caller). However a draft: draft-elwell-bliss-dnd-00 [I-D.elwell-bliss-dnd] provides an analysis of the current situation. 9.2. Frameworks and requirements None found 9.3. Call flow samples None found 9.4. Specifications None found Ligot & Froment Expires January 15, 2009 [Page 19] Internet-Draft SIP Services Guide July 2008 10. Call Completion 10.1. Description o This service enables the caller to establish a communication with the callee even if at the time of the communication initiation, the callee is not able to answer the call (busy, not available, ...) without having to restart a new communication. 10.2. Frameworks and requirements o EN 301 134 [EN301134] describes these services from the end user side. This document describes only the case where the user, in switched circuit environment has no free channel available to receive the current call. In a SIP environment, this can be compared with the error '486 Busy Here'. 10.3. Call flow samples None found 10.4. Specifications o ietf-bliss-call-completion [I-D.ietf-bliss-call-completion] proposes a specification where the service is implemented thanks to a new event package. o 3GPP 24 615 [3GPP.24.615] gives some details about call waiting service. Ligot & Froment Expires January 15, 2009 [Page 20] Internet-Draft SIP Services Guide July 2008 11. Conclusion This version shows that specifications are actually numerous. It also shows that there is a lack of framework and requirements. Information is difficult to find, and is sometimes hidden in individual contributions which are not always understood by non-IETF people as "unofficial". It MAY partially explain why SIP services implementers are not always satisfied and it clearly does not help interoperability. That's why this document was created. Some external references, like the ISDN specifications, have a different objective and are difficult to compare since they take some assumptions on the network architecture. Proposal of this document on this problem is to split the problem in two parts: the pure- endpoint based architectures, and the others based on an intermediary. We do believe that all these specifications are a good illustration of "what is done elsewhere", and that it may be taken as input for building BLISS recommendations. Ligot & Froment Expires January 15, 2009 [Page 21] Internet-Draft SIP Services Guide July 2008 12. IANA Considerations This document does not require any actions by IANA. Ligot & Froment Expires January 15, 2009 [Page 22] Internet-Draft SIP Services Guide July 2008 13. Security Considerations TBC Ligot & Froment Expires January 15, 2009 [Page 23] Internet-Draft SIP Services Guide July 2008 14. Acknowledgments Ligot & Froment Expires January 15, 2009 [Page 24] Internet-Draft SIP Services Guide July 2008 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. 15.2. Informative References [3GPP.22.082] 3GPP, "Call Forwarding (CF) Supplementary Services; Stage 1", 3GPP TS 22.082 3.0.2, March 2004. [3GPP.22.083] 3GPP, "Call Waiting (CW) and Call Hold (HOLD) supplementary services; Stage 1", 3GPP TS 22.083 3.0.1, October 1999. [3GPP.22.088] 3GPP, "Call Barring (CB) supplementary services; Stage 1", 3GPP TS 22.088 3.0.2, November 2000. [3GPP.22.091] 3GPP, "Explicit Call Transfer (ECT) supplementary service; Stage 1", 3GPP TS 22.091 3.1.0, October 2000. [3GPP.24.505] 3GPP, "TISPAN; PSTN/ISDN simulation services: Conference (CONF); Protocol specification", 3GPP TS 24.505 8.0.0, March 2008. [3GPP.24.604] 3GPP, "Communication Diversion (CDIV) using IP Multimedia (IM)Core Network (CN) subsystem; Protocol specification", 3GPP TS 24.604 8.0.0, June 2008. [3GPP.24.605] 3GPP, "Conference (CONF)using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification", 3GPP TS 24.605 8.0.0, June 2008. [3GPP.24.610] 3GPP, "Communication HOLD (HOLD) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification", 3GPP TS 24.610 8.0.0, June 2008. [3GPP.24.611] 3GPP, "Anonymous Communication Rejection (ACR) and Ligot & Froment Expires January 15, 2009 [Page 25] Internet-Draft SIP Services Guide July 2008 Communication Barring (CB)using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification", 3GPP TS 24.611 8.0.1, June 2008. [3GPP.24.615] 3GPP, "Communication Waiting (CW) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol Specfication", 3GPP TS 24.615 0.3.0, May 2008. [3GPP.24.629] 3GPP, "Explicit Communication Transfer (ECT)using IP Multimedia (IM)Core Network (CN) subsystem;; Protocol specification", 3GPP TS 24.629 8.0.0, June 2008. [EN301134] "Integrated Services Digital Network (ISDN); Completion of Calls on No Reply (CCNR); supplementary service; Service description", 2005. [I-D.camarillo-sipping-adhoc-conferencing] Camarillo, G. and A. Johnston, "Ad-Hoc Conferencing in the Session Initiation Protocol (SIP)", draft-camarillo-sipping-adhoc-conferencing-00 (work in progress), March 2004. [I-D.elwell-bliss-dnd] Elwell, J. and S. Srinivasan, "An Analysis of Do Not Disturb (DND) Implementations in the Session Initiation Protocol (SIP)", draft-elwell-bliss-dnd-01 (work in progress), November 2007. [I-D.froment-sipping-spit-requirements] Tschofenig, H., Dawirs, G., Froment, T., Wing, D., and H. Schulzrinne, "Requirements for Authorization Policies to tackle Spam and Unwanted Communication for Internet Telephony", draft-froment-sipping-spit-requirements-02 (work in progress), February 2008. [I-D.ietf-bliss-ach-analysis] Elwell, J., "An Analysis of Automatic Call Handling Implementation Issues in the Session Initiation Protocol (SIP)", draft-ietf-bliss-ach-analysis-02 (work in progress), May 2008. [I-D.ietf-bliss-call-completion] Worley, D., Huelsemann, M., and D. Alexeitsev, "Call Completion for Session Initiation Protocol (SIP)", draft-ietf-bliss-call-completion-02 (work in progress), Ligot & Froment Expires January 15, 2009 [Page 26] Internet-Draft SIP Services Guide July 2008 June 2008. [I-D.ietf-bliss-problem-statement] Rosenberg, J., "Basic Level of Interoperability for Session Initiation Protocol (SIP) Services (BLISS) Problem Statement", draft-ietf-bliss-problem-statement-02 (work in progress), February 2008. [I-D.ietf-sip-acr-code] Rosenberg, J., "Rejecting Anonymous Requests in the Session Initiation Protocol (SIP)", draft-ietf-sip-acr-code-05 (work in progress), July 2007. [I-D.ietf-sip-gruu] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft-ietf-sip-gruu-15 (work in progress), October 2007. [I-D.ietf-sip-uri-list-conferencing] Camarillo, G. and A. Johnston, "Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)", draft-ietf-sip-uri-list-conferencing-02 (work in progress), November 2007. [I-D.ietf-sipping-cc-transfer] Sparks, R., "Session Initiation Protocol Call Control - Transfer", draft-ietf-sipping-cc-transfer-09 (work in progress), December 2007. [I-D.ietf-sipping-service-examples] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, "Session Initiation Protocol Service Examples", draft-ietf-sipping-service-examples-14 (work in progress), February 2008. [I-D.ietf-sipping-transc-conf] Camarillo, G., "The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model", draft-ietf-sipping-transc-conf-03 (work in progress), June 2006. [I-D.ietf-sipping-transc-framework] Camarillo, G., "Framework for Transcoding with the Session Initiation Protocol (SIP)", draft-ietf-sipping-transc-framework-05 (work in progress), December 2006. Ligot & Froment Expires January 15, 2009 [Page 27] Internet-Draft SIP Services Guide July 2008 [I-D.koren-sipping-conference-list-event] Fortinsky, M., Ravid, I., and O. Koren, "A Conference List Information Event Package for the Session Initiation Protocol (SIP)", draft-koren-sipping-conference-list-event-03 (work in progress), July 2008. [I-D.procter-bliss-call-park-extension] Procter, M., "Implementing Call Park and Retrieve using the Session Initiation Protocol (SIP)", draft-procter-bliss-call-park-extension-01 (work in progress), February 2008. [I-D.tschofenig-sipping-framework-spit-reduction] Tschofenig, H., Schulzrinne, H., Wing, D., Rosenberg, J., and D. Schwartz, "A Framework to tackle Spam and Unwanted Communication for Internet Telephony", draft-tschofenig-sipping-framework-spit-reduction-03 (work in progress), February 2008. [I-D.tschofenig-sipping-spit-policy] Tschofenig, H., Wing, D., Schulzrinne, H., Froment, T., and G. Dawirs, "A Document Format for Expressing Authorization Policies to tackle Spam and Unwanted Communication for Internet Telephony", draft-tschofenig-sipping-spit-policy-02 (work in progress), November 2007. [I-D.wu-iptel-less] Wu, X. and H. Schulzrinne, "LESS: Language for End System Services in Internet Telephony", draft-wu-iptel-less-00 (work in progress), February 2005. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. Ligot & Froment Expires January 15, 2009 [Page 28] Internet-Draft SIP Services Guide July 2008 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004. [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004. [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004. [RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004. [RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing Language (CPL): A Language for User Control of Internet Telephony Services", RFC 3880, October 2004. [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. [RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004. [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004. [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004. [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005. [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005. Ligot & Froment Expires January 15, 2009 [Page 29] Internet-Draft SIP Services Guide July 2008 [RFC4244] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005. [RFC4245] Levin, O. and R. Even, "High-Level Requirements for Tightly Coupled SIP Conferencing", RFC 4245, November 2005. [RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006. [RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)", RFC 4458, April 2006. [RFC4488] Levin, O., "Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription", RFC 4488, May 2006. [RFC4508] Levin, O. and A. Johnston, "Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method", RFC 4508, May 2006. [RFC4538] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, June 2006. [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006. [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006. [RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597, August 2006. [RFC4730] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", RFC 4730, November 2006. [RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server Control Markup Language (MSCML) and Protocol", RFC 5022, September 2007. Ligot & Froment Expires January 15, 2009 [Page 30] Internet-Draft SIP Services Guide July 2008 [RFC5079] Rosenberg, J., "Rejecting Anonymous Requests in the Session Initiation Protocol (SIP)", RFC 5079, December 2007. Ligot & Froment Expires January 15, 2009 [Page 31] Internet-Draft SIP Services Guide July 2008 Authors' Addresses Arnaud Ligot University of Namur Rue Grandgagnage Namur 5000 Belgium Email: arnaud@cblue.be Thomas Froment Alcatel-Lucent Centre de Villarceaux, Route de Villejust Nozay, Paris 91620 France Email: Thomas.Froment@alcatel-lucent.fr Ligot & Froment Expires January 15, 2009 [Page 32] Internet-Draft SIP Services Guide July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Ligot & Froment Expires January 15, 2009 [Page 33]