Internet Engineering Task Force C. Stredicke Internet Draft snom technology AG draft-stredicke-sipping-late-media-01.txt February 11, 2004 Expires: August, 2004 Indication of Service Media in the Session Initiation Protocol STATUS OF THIS MEMO This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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 To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract After a dialog has been established, there are several situations where user agents may render additional media to the user (service media). These situations include music on hold, tones after hang-up or message waiting indication. This document proposes a way to indicate which media to use for service media. C. Stredicke [Page 1] Internet Draft SIP February 8, 2003 Table of Contents 1. Problem Statement and Requirements................................3 1.1 Use Cases.........................................................3 1.2 Requirements......................................................3 2. Usage.............................................................3 2.1 Indicating service media..........................................3 2.2 Indicating service media Support..................................5 2.3 Service Types.....................................................5 2.4 Formal description................................................6 3. Security..........................................................6 4. IANA Considerations...............................................6 5. Examples..........................................................6 6. Changes from -00.txt..............................................7 7. Authors' Addresses................................................7 8. Bibliography......................................................7 C. Stredicke [Page 2] Internet Draft SIP February 8, 2003 1. Problem Statement and Requirements 1.1 Use Cases After disconnecting a telephone call, a telephone user usually hears a tone which indicates that the call has been disconnected. Typically this is a synthesized tone or an announcement like "Your call is over. Please hang up". When being put on hold, users usually hear music or other entertaining media. When a user is being transferred and there is no ring back available from the new destination, users typically hear music or generated ring back tone. When someone calls during an ongoing conversation, users usually hear a "knocking" indicating call waiting. When an operator wants to disrupt and ongoing call, a short indication like "Your call is being interrupted" is helpful for the user to stop talking. Other cases include messages like "You have one minute left on your calling card". Service media can be compared to early media in a way that it is not part of the main conversation and that it is usually not subject to billing. Service media is not limited to audio. For example, it may also be an image or short video clip that represents the company or the operator. It may also provide additional information on the call like the call duration and the cost for the call. Service media is not time-critical. It does not contain real-time information that needs minimized delay. While it is possible to generate music on hold using a third-party call control model, it becomes obvious that other service indications like hang-up indication are not possible using the third-party call control model. 1.2 Requirements SIMPLICITY. The usage of service media MUST be simple. The usage of mechanisms like third-party control is not appropriate, as the media typically is used by embedded systems which have limitations on complexity. BACKWARD-COMPATIBILITY. It MUST be possible to determine of another user agent supports the proposals in this document. BANDWIDTH EFFICIENCY. When a user agent will not render service media (e.g. because it is a machine), media MUST NOT be sent. OPENNESS. It MUST be easy to add new services. OFFLINE. To reduce the additional load for the network for service media, it SHOULD be possible to start the downloading of the media as soon as possible and to cache media in the user agents. 2. Usage 2.1 Indicating Service Media In the case of early media, SIP [1] proposes the usage of the Alert- Info header. This document proposes a similar header, Service-Media. C. Stredicke [Page 3] Internet Draft SIP February 8, 2003 The Alert-Info header cannot be used as it may be confused with early media. Because the service media downloading process should start as early as possible it is desirable that service media is indicated already during call set up. Also, it would be confusing for devices which are not aware of Service-Media to see the Alert- Info in requests or responses after the dialog is connected. The Service-Media header contains one or more URI that indicate which files MAY be used to render service media. If the dialog includes audio, there SHOULD be at least one URI that can be loaded using HTTP and represents the media in eight kilohertz mono ulaw format. If there are several possibilities listed in the Service-Media header, the user agent MUST select one of them. This selection MAY favour available schemes or media types. Typically, this protocol will be HTTP. The underlying media type cannot be determined beforehand by the URI. The user agent MAY probe the file in this case. The audio parameter gives a hint about the file format. If no match could be found, the user agent will ignore the Service-Media header. Using SIP URL is nice to save memory space for small embedded devices, but creates security problems. The user usually believes that the service announcement is for free. Allowing a SIP URL in a Service-Media header would open the door to security threats (like redirecting calls to 900 numbers). The user agent will indicate in these cases only .the call has ended please hang up. (also in the graphical user interface) and there is no way for the user to check the validity of the SIP URL. Providing service media in the phase between the BYE and the response to the BYE would allow service media to be sent from the UAC to the UAS. However, this would result in a long delay between the request and the response. If the parameter does not include a "loop" parameter, the rendering MUST be done one. If the parameter contains the keyword "endless", the rendering SHOULD be done in an endless loop until the user interacts with the user agent (for example, hangs up or picks another call) or a timeout occurs (for example, 30 seconds). Otherwise, the loop parameter indicates how many times the media should be repeated. That is an important feature for video messages and also helpful for audio messages. The user agent SHOULD cache service media files. A "size" parameter MAY indicate the size of the media. This is a useful indication for downloading HTTP files for user agents with limited memory. This is very helpful in PBX environments when most of the time the user agents play the same melody. The caching algorithm is left to the implementer. Depending on the scheme, the caching may include invalidation periods and rechecking for updates. Any element (proxy, user agent) in the dialog route MAY insert or delete Service-Media headers. Typically, a proxy will insert the Service-Media header. Allowing any element to insert Service-Media headers does not introduce new security risks, as all of these elements are allowed to modify the requests and responses anyway. By allowing the elements to modify the headers proxies near the end point may override service media C. Stredicke [Page 4] Internet Draft SIP February 8, 2003 information in favour of local information. That gives the proxy nearest to the endpoint the highest priority in defining the service media. The Service-Media header MAY be inserted into any request or reply in a dialog. Receiving Service-Media header overwrites previously received Service-Media headers. The header SHOULD be inserted as soon as possible to maximize the time for downloading the service media file. If the service media contains information about the call (for example, billing information), the Service-Media header will be inserted in the BYE request. That means that both the one who hangs up and the one who gets disconnected MAY have service media. This is different from the PSTN model, where only one party hears service media. The visibility of the Service-Media header is only within one dialog. This is because another dialog might have different proxies in the path with different Service-Media policies. 2.2 Indicating Service Media Support User-Agents that support the mechanisms described in this document insert a Supported header with "service-media". When a user-agent receives such a header, it SHOULD not use third- party call control to generate music on hold and other service media. 2.3 Service Types The media MUST be tagged with a purpose indication. The following purposes are defined in this document: - "hangup": The user agent SHOULD start rendering media to the user upon the reception of a BYE request or a response to a BYE. The rendering ends when the user interacts or after an implementation-specific timeout (for example, 15 seconds). - "hold": When a call is on hold, the media tagged with "hold" SHOULD be used. If the user agent which is being put on hold has a matching service media available, it SHOULD send an "inactive" answer [3]. - "transfer": In a blind transfer there MAY be a pause when there is no media is available. During this time, the user agent SHOULD render the media tagged with "transfer". The service media is indicated in the dialog which contains the initiating REFER [2]. If there is not "transfer" media available, user agents MAY also if "hold" media. - "call-waiting": If another call is available outside of the current dialog, the user agent SHOULD mix the service media into the current conversation. - "intrusion": In cases when the operator is about to disrupt a call (call intrusion), the user agent SHOULD prepare the user about this event. - "billing": When users pay for service time on a coin-based system, user agents SHOULD mix a sound into the conversion. Typically, this is a short beep for every coin that is being used. But it C. Stredicke [Page 5] Internet Draft SIP February 8, 2003 can also be an announcement that indicates that a prepaid service is about to end. - "hold-warning": If another call is on hold for an implementation- specific timeout (e.g. one minute), the user agent SHOULD remind the user using the ôhold-warningö media. 2.4 Formal description Service-Media = "Service-Media" HCOLON service-param *(COMMA service-param) service-param = LAQUOT absoluteURI RAQUOT *( SEMI media-param ) media-param = loop-param / purpose-param / generic-param purpose-param = "purpose" EQUAL ("hangup" / "hold" / "transfer" / "call-waiting" / "intrusion" / "billing" / "hold-warning" / token ) size-param = "size" EQUAL 1*DIGIT audio-param = "audio" EQUAL media-format video-param = "video" EQUAL media-format loop-param = "loop" EQUAL ("endless" / 1*DIGIT) The media-format description follows the syntax for the "rtpmap" parameter in SDP [4] (without the payload type). See [1] for other definitions. 3. Security Due to the resemblance with early media the proposed method to indicate service media does not introduce new security risks. For the discussion of security concerns caused by redirection and initiation see the discussion on using 3xx codes and Alert-Info in [1] as well as the redirection caused by DNS-related methods like ENUM [5]. 4. IANA Considerations SIP headers defined: Service-Media Normative description: This document 5. Examples After the call has been established, the other party hangs up and the proxy inserts a Service-Media header (routing not shown here): BYE sip:user@1.2.3.4 SIP/2.0 From: A ;tag=1 To: B ;tag=2 Call-ID: 123 CSeq: 1 BYE Service-Media: ;purpose=hangup;size=16435 ;audio="ulaw/8000/1" Content-Length: 0 SIP/2.0 200 Ok From: A ;tag=1 To: B ;tag=2 Call-ID: 123 CSeq: 1 BYE Content-Length: 0 C. Stredicke [Page 6] Internet Draft SIP February 8, 2003 The user agent downloads the provided HTTP file, possibly converts the sample rate and the format and then renders it to the user. 6. Changes from -00.txt - The term "Late Media" was replaced with "service media" to allow a broader scope of this document. - SIP URI are allowed to avoid the storage of large music files. 7. Authors' Addresses Dr. Christian Stredicke snom technology AG Pascalstr. 10B 10587 Berlin Germany Email: cs@snom.com SIP: cs@snom.com 8. Bibliography [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, Internet Engineering Task Force, June 2002. [2] R. Sparks, "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, Internet Engineering Task Force, April 2003. [3] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, Internet Engineering Task Force, June 2002 [4] M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC 2327, Internet Engineering Task Force, April 1998 [5] P. Faltstrom, "E.164 number and DNS", RFC 2916, Internet Engineering Task Force, September 2000 The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement C. Stredicke [Page 7] Internet Draft SIP February 8, 2003 Copyright (c) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. C. Stredicke [Page 8]