Internet Engineering Task Force C. Stredicke Internet Draft snom technology AG draft-stredicke-sipping-late-media-00.txt August 11, 2003 Expires: February, 2004 Late 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 "Late Media" is presented after a dialog is disconnected or when the dialog is temporarily without media. The "Late-Media" header indicates under which circumstances late media should be rendered. Internet Draft SIP August 11, 2003 Table of Contents 1. Problem Statement and Requirements.................................3 2. Indicating Late Media..............................................3 2.1 Late-Media Indication.............................................3 2.2 End of Call.......................................................5 2.3 Other Indications.................................................5 2.4 Formal description................................................5 3. Security...........................................................5 4. IANA Considerations................................................5 5. Examples...........................................................6 6. Acknowledgments....................................................6 7. Authors' Addresses.................................................6 8. Bibliography.......................................................6 C. Stredicke [Page 2] Internet Draft SIP August 11, 2003 1. Problem Statement and Requirements After disconnecting a telephone call, a telephone user usually hears "Late Media". Typically this is a synthesized tone or an announcement like "Your call is over. Please hang up". Late Media can be compared to early media in a way that it is not part of the main conversation and that it is normally not subject to billing. Late 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. Late Media may also provide additional information on the call like the call duration and the cost for the call. While in the PSTN model early media and Late Media are sent by a central network component, the SIP model tends to leave the rendering to the user agent. It is a requirement that the Late Media does not start a new call which could possible cause additional cost for any of the participating parties. Late Media is not time-critical. Late Media does not contain real- time information that needs minimized delay. To reduce the additional load for the network for Late Media, it should be possible to start the downloading of the media as soon as possible and to cache media in the user agents. Late Media can also be used when the other party is temporarily disconnected (hold, during a transfer). Late Media is similar to Error-Info in that it also generates media when the call is already disconnected. User agents which are not implementing this document MUST not change their behaviour by additional information defined in this document (backward compatibility). 2. Indicating Late Media 2.1 Late-Media Indication In the case of early media, SIP [1] proposes the usage of the Alert- Info header. This document proposes a similar header, Late-Media. The Alert-Info header cannot be used as it may be confused with early media. Because the Late Media downloading process should start as early as possible it is desirable that Late Media is indicated already during call set up. Also, it would be confusing for devices which are not aware of late-media to see the Alert- Info in requests or responses after the dialog is connected. [Open Issue: Maybe we can re-use the Error-Info header. This header is used in a similar situation like late media in a sense that the call is finished. However, it seems more safe to introduce a new header to fulfil the backward compatibility requirement.] The Late-Media header contains one or more URI that indicate which files MAY be used to render Late Media. If there are several possibilities listed in the Alert-Info header, the user agent MUST select one of them. This selection MAY favour available schemes or media types. C. Stredicke [Page 3] Internet Draft SIP August 11, 2003 Most of the times, 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. If no match could be found, the user agent will ignore the Late-Media header. User agents MUST ignore SIP URL. Using SIP URL would be nice to save memory space for small embedded devices, but ignoring SIP URL is a necessity for security reasons. The user believes that the call is over and that the announcement is for free. Allowing a SIP URL in a Late-Media header in BYE 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 Late Media in the phase between the BYE and the response to the BYE would allow Late Media to be sent from the UAC to the UAS. However, this would result in a long delay between the request and the response. [Open Issue: In Error-Info and Alert-Info SIP URL are valid. Allowing this also in Late-Media headers would probably not open new security problems. Maybe we weaken this requirement. ] If the parameter does not include a "loop" parameter, the rendering MUST 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 Late Media files. 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 Late-Media headers. Typically, a proxy will insert the Late-Media header. Allowing any element to insert Late-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 Late Media information in favour of local information. That gives the proxy nearest to the endpoint the highest priority in defining the Late Media. The Late-Media header MAY be inserted into any request or reply in a dialog. Receiving Late-Media header overwrites previously received Late-Media headers. The header SHOULD be inserted as soon as possible to maximize the time for downloading the Late Media file. If the Late Media contains information about the call (for example, billing information), the earliest time for inserting the Late-Media header is the BYE request. C. Stredicke [Page 4] Internet Draft SIP August 11, 2003 That means that both the one who hangs up and the one who gets disconnected MAY have Late Media. This is different from the PSTN model, where only one party hears Late Media. The visibility of the Late-Media header is only within one dialog. This is because another dialog might have different proxies in the path with different Late-Media policies. 2.2 End of Call 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 a reasonable timeout (for example, 15 seconds). The user agent MUST pick Late Media that has the purpose parameter set to "end" or has no purpose parameter. 2.3 Other Indications In order to enable smart indications in other situations, the media MAY be tagged with a purpose indication. The media can then be used in the following situations: - Blind Transfer: In a blind transfer there MAY be a pause when there is no media is available. During this time, the user agent MAY render the media tagged with "transfer". The Late Media is indicated in the dialog which contains the initiating REFER [2]. - Hold: When a call is on hold, the media tagged with "hold" MAY be used. If the user agent which is being put on hold has a matching Late Media available, it SHOULD send an "inactive" answer [3]. [Open Issue: Call waiting, call completion and hold warning could also be included here. However, it seems that defining the audio profile in these cases would go too far out of scope of this document and should be left to the device setup.] 2.4 Formal description Late-Media = "Late-Media" HCOLON latemedia-param *(COMMA latemedia-param) latemedia-param = LAQUOT absoluteURI RAQUOT *( SEMI latemedia-param ) latemedia-param = loop-param / purpose-param / generic-param purpose-param = "purpose" EQUAL ("end" / "hold" / "transfer" ) loop-param = "loop" EQUAL 1*DIGIT 3. Security Due to the resemblance with early media the proposed method to indicate Late Media should not introduce new security risks. Because SIP URL is not allowed for Late Media, the risk introduced by creating a new dialog is avoided. File download normally does not cause additional costs for users. 4. IANA Considerations SIP headers defined: Late-Media Normative description: This document C. Stredicke [Page 5] Internet Draft SIP August 11, 2003 5. Examples After the call has been established, the other party hangs up and the proxy inserts an Alert-Info 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 Late-Media: ;purpose=end 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 The user agent downloads the provided http file, possibly converts the sample rate and the format and then renders it to the user. 6. Acknowledgments 7. Authors' Addresses Dr. Christian Stredicke snom technology AG Pascalstr. 10B 10587 Berlin Germany Email: cs@snom.de SIP: christian@stredicke.de 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 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 C. Stredicke [Page 6] Internet Draft SIP August 11, 2003 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 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 7]