Internet-Draft Daniele Giordano 6 November 2007 Expires: 9 May 2008 Call on hold revision for SIP protocol draft-giordano-sip-call-hold-revision-00 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. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Many RFCs and Internet Drafts describe call on hold methods adopted in SIP signaling protocol. The actual implementation may not always be ideal (reasons are explained below). This draft proposes a revision of call on hold method for SIP protocol. Giordano [Page 1] Internet-Draft Call on hold revision for SIP protocol Nov 2007 Table of Contents 1. Conventions Used In This Document . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The actual implementation . . . . . . . . . . . . . . . . . . . 3 4. New Implementation and Operations . . . . . . . . . . . . . . . 4 4.1 Example of Holding process. . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 7 Giordano [Page 2] Internet-Draft Call on hold revision for SIP protocol Nov 2007 1. Conventions Used In This Document 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 [RFC2119]. 2. Introduction Many RFCs and Internet Drafts describe call on hold methods adopted in SIP signaling protocol. The actual implementation may not always be ideal (reasons are explained below). This draft proposes a revision of call on hold method for SIP protocol. 3. The actual implementation The actual implementations of call on hold method are described in many documents. [RFC2543] paragraph B.5 "Putting Media Streams on Hold" establishes: If a party in a call wants to put the other party "on hold", i.e., request that it temporarily stops sending one or more media streams, a party re-invites the other by sending an INVITE request with a modified session description. The session description is the same as in the original invitation (or response), but the "c" destination addresses for the media streams to be put on hold are set to zero (0.0.0.0). [RFC3264] paragraph 8.4 "Putting a Unicast Media Stream on Hold" establishes: Typically, when a user "presses" hold, the agent will generate an offer with all streams in the SDP indicating a direction of sendonly, and it will also locally mute, so that no media is sent to the far end, and no media is played out. [RFC3725] paragraph 5 "Recommendations" establishes: ... Several of these flows use a "black hole" connection address of 0.0.0.0. This is an IPv4 address with the property that packets sent to it will never leave the host which sent them; they are just discarded. ... In most cases, including the recommended flows, user A will hear silence while the call to B completes. This may not always be ideal. It can be remedied by connecting the caller to a music-on-hold source while the call to B occurs. Giordano [Page 3] Internet-Draft Call on hold revision for SIP protocol Nov 2007 [RFC3725] paragraph 7 "Continued Processing" establishes: .... In particular, the version number in the SDP will need to be changed by the controller in certain cases. If the controller should issue an SDP offer on its own (for example, to place a call on hold), it will need to increment the version number in the SDP offer. [draft-ietf-sipping-sip-offeranswer] paragraph 5.3 "Hold and Resume of media" establishes: ...If UA2 has previously been "placed on hold" by UA1, via receipt of "a=sendonly", then it may initiate its own hold by sending a new offer containing "a=sendonly" to UA1. Upon receipt of that, UA1 will answer with "a=inactive" because that is the only valid answer that reflects its desire not to receive media. [draft-ietf-sip-service-examples] gives examples of hold methods in various SIP services like call hold, consultation hold, attended transfer, etc. How explained in all these documents hold is unidirectional in nature so a UA that places the other party on hold will stop sending media. The result is silence on the holded side until the transferred-to answers the call or the holder resume that. This is not ideal. An alternative is the use of a music on hold source but it's not a mandatory component in a SIP environment. 4. New Implementation and Operations When a UA receives a SIP message which places the call on hold and no music on hold sources are available It MUST play an holding tone locally in according to the regional phone line parameters. When the place on hold state is modified (e.g. the call is resumed) the UA MUST stop the holding tone. 4.1 Example of Holding process In this example setup and tear down messages are omitted and It assumes that the call is already established. Dashed lines (---) represent control messages while double dashed lines (===) represent media paths between network elements. Giordano [Page 4] Internet-Draft Call on hold revision for SIP protocol Nov 2007 Alice Proxy Bob | | | | Both way RTP Established | |<=============================>| | |INVITE(hold) | |INVITE(hold) |<-------------| |<---------------| | | 200 OK | | |--------------->| 200 OK | | |------------->| | | ACK | | ACK |<-------------| |<---------------| | | | | | No RTP Sent! | | | | ---------------- | | | play holding | | | | tone | | | ---------------- | | | | | | | | | | | | | | | | INVITE | | INVITE |<-------------| |<---------------| | | 200 OK | | |--------------->| 200 OK | | |------------->| | | ACK | | ACK |<-------------| |<---------------| | | | | ---------------- | | | stop holding | | | | tone | | | ---------------- | | | | | | Both way RTP Established | |<=============================>| | | | In this scenario, Alice and Bob are talking, then Bob places the call on hold. No RTP packets are sent and no music on hold sources are available. Alice's UA play the holding tone locally. Giordano [Page 5] Internet-Draft Call on hold revision for SIP protocol Nov 2007 5. Security Considerations This document is not directly concerned with security. 6. IANA Considerations None. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [RFC2543] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg "SIP: Session Initiation Protocol", RFC2543, March 1999. [RFC3264] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC3264, June 2002. [RFC3725] J. Rosenberg, J. Peterson, H. Schulzrinne, G. Camarillo "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", RFC3725, BCP85, April 2004. [draft-ietf-sipping-sip-offeranswer] T. Sawada, P. Kyzivat, "SIP (Session Initiation Protocol) Usage of the Offer/Answer Model", October 2007. [draft-ietf-sip-service-examples] A. Johnston, R. Sparks, C. Cunningham, S. Donovan, K. Summers, "Session Initiation Protocol Service Examples", July 2007. Giordano [Page 6] Internet-Draft Call on hold revision for SIP protocol Nov 2007 Author's Address Giordano Daniele Email: d.giordano@fastpiu.it Full Copyright Statement Copyright (C) The IETF Trust (2007). 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). Giordano Expires 9 May 2008 [Page 7]