Network Working Group A. Ligot Internet-Draft University of Namur Intended status: Informational T. Froment Expires: August 28, 2008 Alcatel-Lucent February 25, 2008 Providing guidance for Session Initiation Protocol (SIP) services draft-ligot-bliss-sip-services-guide-01 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 August 28, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Ligot & Froment Expires August 28, 2008 [Page 1] Internet-Draft SIP Services Guide February 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 August 28, 2008 [Page 2] Internet-Draft SIP Services Guide February 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 August 28, 2008 [Page 3] Internet-Draft SIP Services Guide February 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 August 28, 2008 [Page 4] Internet-Draft SIP Services Guide February 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 August 28, 2008 [Page 5] Internet-Draft SIP Services Guide February 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 While the first version of this document was only list of references from IETF and TISPAN with some comments, this second version add references from ETSI ISDN. As shown below, these specifications contain interesting non-technical descriptions of some services. Furthermore in this version, a particular attention has been given to the 'Call flow samples' section: each sample is described with more details, including a list of optional and mandatory dependencies. Ligot & Froment Expires August 28, 2008 [Page 6] Internet-Draft SIP Services Guide February 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 August 28, 2008 [Page 7] Internet-Draft SIP Services Guide February 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 EN 300 199 [EN300199], from ISDN specification describes the service of call forwarding on Busy. It gives requirements of users and defines common terms related to this kind of service. EN 300 133 [EN301133], coming from ISDN specifications, gives more 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. TS 183 004 [TS183004], 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 Ligot & Froment Expires August 28, 2008 [Page 8] Internet-Draft SIP Services Guide February 2008 o OPTIONAL: RFC 3880 (CPL) [RFC3880] or TISPAN profile defined into TS 183 004 [TS183004] can be used by the user to tell the configuration to the server. RFC 4458 (URI for applications) [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 TS 183 004 [TS183004] from TISPAN 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 August 28, 2008 [Page 9] Internet-Draft SIP Services Guide February 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 EN 300 367 [EN300367], from ISDN 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 August 28, 2008 [Page 10] Internet-Draft SIP Services Guide February 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 TS 183 029 [TS183029] 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 August 28, 2008 [Page 11] Internet-Draft SIP Services Guide February 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 August 28, 2008 [Page 12] Internet-Draft SIP Services Guide February 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 Besides ISDN specifications where there is a very short description of this service, nothing has been found. However requirements for this service are very basic. The user on Hold just wants to prevent other users from hearing him. 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 sections 1, 2 and 3 of service-examples [I-D.ietf-sipping-service-examples] and TS183 010 [TS183010] 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 August 28, 2008 [Page 13] Internet-Draft SIP Services Guide February 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 EN 301 768 [EN301768] from ISDN 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 August 28, 2008 [Page 14] Internet-Draft SIP Services Guide February 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 TS 183 011 [TS183011] defines the service data model to be put on an application server and introduces a set of rules, based on Initial Filter Criterias (IFC) specified into TS 183 033 [TS183033]. 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 August 28, 2008 [Page 15] Internet-Draft SIP Services Guide February 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 August 28, 2008 [Page 16] Internet-Draft SIP Services Guide February 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 TS 183 005 [TS183005] from TISPAN uses specifications from IETF. 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 August 28, 2008 [Page 17] Internet-Draft SIP Services Guide February 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 August 28, 2008 [Page 18] Internet-Draft SIP Services Guide February 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 August 28, 2008 [Page 19] Internet-Draft SIP Services Guide February 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 ietf-bliss-call-completion [I-D.ietf-bliss-call-completion] proposes a specification where the service is implemented thanks to a new event package. Ligot & Froment Expires August 28, 2008 [Page 20] Internet-Draft SIP Services Guide February 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 August 28, 2008 [Page 21] Internet-Draft SIP Services Guide February 2008 12. IANA Considerations This document does not require any actions by IANA. Ligot & Froment Expires August 28, 2008 [Page 22] Internet-Draft SIP Services Guide February 2008 13. Security Considerations TBC Ligot & Froment Expires August 28, 2008 [Page 23] Internet-Draft SIP Services Guide February 2008 14. Acknowledgments Ligot & Froment Expires August 28, 2008 [Page 24] Internet-Draft SIP Services Guide February 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 [EN300199] "Integrated Services Digital Network (ISDN); Call Forwarding Busy (CFB) supplementary services; Service description", 06 2001. [EN300367] "Integrated Services Digital Network (ISDN); Explicit Call Transfer (ECT) supplementary service; Service description", 2005. [EN301133] "Integrated Services Digital Network (ISDN); Selective Call Forwarding (SCF) supplementary services (unconditional, busy, and no reply); Service description", 10 1998. [EN301134] "Integrated Services Digital Network (ISDN); Completion of Calls on No Reply (CCNR); supplementary service; Service description", 2005. [EN301768] "Service and Protocols for Advanced Networks (SPAN); Anonymous Call Rejection (ACR) supplementary Service; Service description", 10 2000. [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] Ligot & Froment Expires August 28, 2008 [Page 25] Internet-Draft SIP Services Guide February 2008 Froment, T., "Requirements for Authorization Policies to tackle Spam and Unwanted Communication for Internet Telephony", draft-froment-sipping-spit-requirements-01 (work in progress), July 2007. [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-00 (work in progress), February 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-01 (work in progress), November 2007. [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-framework] Mahy, R., "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", draft-ietf-sipping-cc-framework-09 (work in progress), December 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., "Session Initiation Protocol Service Examples", draft-ietf-sipping-service-examples-13 (work in Ligot & Froment Expires August 28, 2008 [Page 26] Internet-Draft SIP Services Guide February 2008 progress), July 2007. [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. [I-D.koren-sipping-conference-list-event] Koren, O., "A Conference List Information Event Package for the Session Initiation Protocol (SIP)", draft-koren-sipping-conference-list-event-02 (work in progress), January 2008. [I-D.procter-bliss-call-park-extension] Procter, M., "An approach to Call Park/Retrieve using SIP", draft-procter-bliss-call-park-extension-00 (work in progress), March 2007. [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-02 (work in progress), November 2007. [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, Ligot & Froment Expires August 28, 2008 [Page 27] Internet-Draft SIP Services Guide February 2008 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. [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) Ligot & Froment Expires August 28, 2008 [Page 28] Internet-Draft SIP Services Guide February 2008 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. [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", Ligot & Froment Expires August 28, 2008 [Page 29] Internet-Draft SIP Services Guide February 2008 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. [RFC5079] Rosenberg, J., "Rejecting Anonymous Requests in the Session Initiation Protocol (SIP)", RFC 5079, December 2007. [TS183004] "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN);PSTN/ISDN simulation services: Communication Diversion (CDIV);Protocol specification", 01 2008. [TS183005] "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); PSTN/ISDN simulation services: Conference (CONF); Protocol specification", 01 2008. [TS183010] "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN);NGN Signalling Control Protocol;Communication HOLD (HOLD) PSTN/ISDN simulation services;Protocol specification", 04 2007. [TS183011] 7, "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN);PSTN/ISDN simulation services: Anonymous Communication Rejection (ACR) and Communication Barring (CB);Protocol specification", 01 2008. [TS183029] "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN);PSTN/ISDN simulation services: Explicit Communication Transfer (ECT);Protocol specification", 01 2008. Ligot & Froment Expires August 28, 2008 [Page 30] Internet-Draft SIP Services Guide February 2008 [TS183033] "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN);IP Multimedia;Diameter based protocol for the interfaces between the Call Session Control Function and the User Profile Server Function/Subscription Locator Function;Signalling flows and protocol details [3GPP TS 29.228 V6.8.0 and 3GPP TS 29.229 V6.6.0, modified]", 10 2007. Ligot & Froment Expires August 28, 2008 [Page 31] Internet-Draft SIP Services Guide February 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 August 28, 2008 [Page 32] Internet-Draft SIP Services Guide February 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 August 28, 2008 [Page 33]