SIPPING Working Group H. Kaplan Internet Draft Acme Packet Intended status: Standards Track C. Holmberg Expires: May 12, 2008 Ericsson November 12, 2007 DTMF Info-Event Package draft-kaplan-sipping-dtmf-package-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/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 May 12, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines a specific SIP Info-event package, based on the generic framework of draft-kaplan-sip-info-events-00.txt, for the purpose of exchanging DTMF events. Kaplan Expires May 12, 2008 [Page 1] DTMF Info-Event Package November 2007 Table of Contents 1. Introduction................................................2 2. Terminology.................................................3 3. Applicability...............................................3 4. Overview of Operation.......................................3 5. Info-Event Package Definition...............................4 5.1. Info-Event Package Name................................4 5.2. Info Bodies............................................4 5.3. UA Behavior............................................4 6. Example Exchange............................................5 7. Security Considerations.....................................6 8. IANA Considerations.........................................6 9. References..................................................6 9.1. Normative References...................................6 9.2. Informative References.................................7 Authors' Addresses................................................7 Intellectual Property Statement...................................8 Full Copyright Statement..........................................8 Acknowledgment....................................................8 1. Introduction The draft defines a SIP Info-event package "dtmf" for the purpose of exchanging DTMF (Dual-Tone Multi-Frequency) events through SIP signaling. The scope of this package is for collecting mid-call DTMF events only. It is not meant as a generic user-stimulus exchange mechanism, nor as a replacement for alternative forms of DTMF exchange. Many forms of SIP session communication require the ability to support DTMF event exchange, whether for PSTN/H.323/etc. compatibility, as a form of user input from limited interfaces, or as a language-agnostic form of communication. For most applications, the mechanism defined in [RFC4733] is the most efficient form of DTMF notification, as it uses specific RTP packets to convey DTMF events in the media path from end-to-end. Furthermore, [KPML] was defined to handle cases where application servers not in the media path also wish to receive DTMF event notifications. While [KPML] provides a rich and powerful set of capabilities, it comes with a price. Every SIP signaling node in the call path interested in receiving SIP-based DTMF notification must subscribe to the UA's at the ends of each call, which for some types of UA's can become a huge processing burden (e.g., PSTN-gateways, SIP-to- H.323 IWF gateways, etc.). This subscription must be created for Kaplan Expires - May 2007 [Page 2] DTMF Info-Event Package November 2007 each and every call, regardless of whether or not any DTMF tones are actually pressed during the call. Furthermore, the [KPML] model's flexibility in handling digit maps with regular-expressions, and both one-time and persistent notification models, increases the state and processing burden on UA's which handle thousands of simultaneous calls, since each subscribed package has its own behavior. Lastly, it is optional for UA's to support multiple subscriptions, which means if two application servers subscribe to the same call, the result is not deterministic: whichever application server happens to subscribe first, wins. Unlike [KPML], this "dtmf" package does not use an explicit Subscribe dialog, does not support regular-expression pattern matching, offers no options, and is generally less flexible, and therefore less complex and more efficient for some use cases. The "dtmf" package described in this draft is not intended to replace [KPML]. It is useful in certain applications where scalability and performance needs dictate a lighter-weight mechanism, but the two can co-exist. Furthermore, in certain applications, such as where the multi-digit inputs occur for a majority of calls, [KPML] may be as efficient as, or even more efficient than, this mechanism. The general mechanism proposed in this draft has been used for several years by many vendors for exchanging DTMF, but has not had the benefit of capability negotiation nor formal standardization. This draft aims at rectifying those two issues. 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. The terminology in this document conforms to RFC 2828, "Internet Security Glossary". 3. Applicability This draft proposes a package based on [INFO-EVENTS]. 4. Overview of Operation The general concept is that the UAC and UAS negotiate support for a "dtmf" Info-event package during the initial INVITE transaction, using the [INFO-EVENTS] draft mechanism. Including the "dtmf" Info- Kaplan Expires - May 2007 [Page 3] DTMF Info-Event Package November 2007 event package name in the Send-Event header means the UA sending the header supports sending INFO requests with the DTMF indication payload. Including the "dtmf" Info-event package name in the Recv- Event header means the UA sending the header supports receiving DTMF events using this mechanism. When either side has indication that the far-end supports receiving "dtmf", and the user presses a DTMF digit, the UA sends it in an INFO request. The digit pressed and the duration it was pressed for are encoded in an "application/dtmf- relay" MIME attachment in the INFO, described later. If a SIP server in the signaling path between the calling UAC and answering UAS wants to receive DTMF indications following this mechanism, they must act as a B2BUA. Such behavior is out of scope of this document. 5. Info-Event Package Definition 5.1. Info-Event Package Name This document defines a SIP Info-Event Package as defined in [INFO- EVENTS]. The info-event-package token name for this package is "dtmf". 5.2. Info Bodies Applications using this info-event package MUST include an "application/dtmf-relay" body in INFO requests to indicate which digit was pressed by the user. The body contains exactly two lines: one of the button pushed, the other of the duration. The body is described in ABNF form as follows: Dtmf-relay-body = digit-line CRLF duration-line digit-line = "Signal" EQUAL SP (DIGIT / "A" / "B" / "C" / "D" / "*" / "#") duration-line = "Duration" EQUAL SP msecs msecs = 1*4(DIGIT) ;100-5000 millisecs 5.3. UA Behavior A UA supporting this draft MUST indicate the user-pressed button through INFO if the remote UA indicated it supports receiving the "dtmf" package. If [RFC4733] (i.e., RFC 2833) was also indicated by the far-end in SDP, and the local UA supports sending such, it MUST send the event indication through both means. If the UA also supports [KPML] and some entity subscribed for the "kpml" package for the same call, the UA still MUST send dtmf indication through the Info-Event, and SHOULD also send such through a [KPML} Notify Kaplan Expires - May 2007 [Page 4] DTMF Info-Event Package November 2007 assuming it would have done so otherwise. (i.e., assuming the regex matched and so on) The UA MUST populate the "application/dtmf-relay" body, as defined earlier, with the button pressed and the duration it was pressed for. Technically, this actually requires the info-event to be generated when the user *releases* the button, however if the user has still not released a button after 5 seconds, which is the maximum duration supported by this mechanism, the UA should generate the info-event. 6. Example Exchange In the following example, Alice initiates a call to Bob. Alice can support sending or receiving "dtmf" events. Alice generates the following: (note: much has been left out for simplicity) INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10 From: Alice ;tag=1234567 To: Bob Call-Id: 123456mcmxcix CSeq: 1 INVITE Contact: Send-Event: dtmf Recv-Event: dtmf Bob checks the headers, can support receiving but not sending "dtmf". Note that since Bob does not support sending anything Alice can send, the response does not list any Send-Event events. SIP/2.0 180 Ringing Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10 From: Alice ;tag=1234567 To: Bob ;tag=abcdefg Call-Id: 123456mcmxcix CSeq: 1 INVITE Recv-Event: dtmf Since he sent the Recv-Event header in the 180, Bob also sends it in the 200. SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10 From: Alice ;tag=1234567 To: Bob ;tag=abcdefg Kaplan Expires - May 2007 [Page 5] DTMF Info-Event Package November 2007 Call-Id: 123456mcmxcix CSeq: 1 INVITE Contact: Recv-Event: dtmf At some later time, Alice presses number 6 on her keypad, for 100ms. She sends the following: INFO sip:bob@192.0.2.2 SIP/2.0 Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnabcdef From: Alice ;tag=1234567 To: Bob ;tag=abcdefg Call-Id: 123456mcmxcix CSeq: 2 INFO Contact: Event: dtmf Content-Type: application/dtmf-relay Content-Length: 26 Signal= 6 Duration= 100 7. Security Considerations There are no specific security issues for this mechanism, beyond those already applicable to SIP-based session signaling and [INFO- EVENTS]. 8. IANA Considerations This document will presumably register the Info-event package name and application/dtmf-relay MIME type, which will be done in later versions if the document moves forward. 9. References 9.1. Normative References [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [INFO-EVENTS] Kaplan, H., Holmberg, C., "SIP INFO Event Framework", draft-kaplan-sip-info-events-00.txt, November 2007. Kaplan Expires - May 2007 [Page 6] DTMF Info-Event Package November 2007 9.2. Informative References [KPML] Burger, E., Dolly, M., "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", RFC 4730, November 2006 [4733] Schulzrinne, H., Taylor, T., "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, December 2006 Author's Address Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803, USA Email: hkaplan@acmepacket.com Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Kaplan Expires - May 2007 [Page 7] DTMF Info-Event Package November 2007 Intellectual Property Statement 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. 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Kaplan Expires - May 2007 [Page 8]