DISPATCH Working Group H. Kaplan Internet Draft Acme Packet Intended status: Standards Track Expires: February 20, 2011 August 20, 2010 A Session Initiation Protocol (SIP) INFO Package for Dual-Tone Multi-Frequency (DTMF) Events draft-kaplan-dispatch-info-dtmf-package-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 February 20, 2011. Copyright and License Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Kaplan Expires February 20, 2011 [Page 1] Internet-Draft SIP INFO Package for DTMF August 2010 Abstract The SIP INFO request method now supports explicit indication and exchange of specified application information. Such usages are documented as an "INFO Package", following the requirements outlined in [info-packages]. This document specifies one such SIP INFO Package, for the purpose of indicating DTMF signals. Table of Contents 1. Introduction................................................2 2. Terminology.................................................3 3. The "dtmf" INFO Package.....................................3 3.1. Overall Description....................................3 4. Overview of Operation.......................................3 5. INFO Package Definition.....................................4 5.1. INFO 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 Author's Address..................................................7 1. Introduction Dual-Tone Multi-Frequency tones are used in numerous telephony applications, in multiple ways and for multiple purposes. From a SIP protocol perspective, they follow one or both of two paths: the RTP media path, and/or the SIP signaling path. DTMF in the media path is handled by [RFC4733], with a reasonable level of interoperability, if both ends of the session support it. There are, however, numerous cases in which DTMF tones need to be sent in the signaling path. The most often cited use-case for such is calling-card applications, where the calling-card application server is not in the media path but needs to detect DTMF tones. There are many other use-cases, however, including SIP-to-H.323 Interworking Gateways, distributed IVR and voicemail-retrieval systems, and some IP-PBX systems. Historically there have been multiple ways of exchanging DTMF in the SIP signaling path: INFO, NOTIFY and KPML [RFC4730]. KPML works by having the application server(s) create Subscriptions to the end User-Agent (UA), and the UA sends NOTIFY messages within the Kaplan Expires - February 2011 [Page 2] Internet-Draft SIP INFO Package for DTMF August 2010 SUBSCRIBE dialog to indicate the DTMF tones. To date, KPML has seen limited deployment. Another method, using non-KPML NOTIFY requests, has usually been implemented by sending NOTIFY messages in the INVITE-based dialog, without a SUBSCRIBE; but the use of NOTIFY as such is not very common. Legacy INFO usage for DTMF is widely deployed, but has no documented standard and there are at least two known variants in use (although one is arguably far more popular). The two variants use different MIME bodies in the INFO message to indicate the DTMF: an "application/dtmf" and an "application/dtmf-relay" MIME body type, with dtmf-relay being the most commonly used one. Although no standard exists for dtmf-relay, it is documented on several websites and extremely simple, with a high level of interoperability. This document is intended to standardize such a mechanism, using the INFO Package model, for a "dtmf" INFO Package. 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. The "dtmf" INFO Package This document defines a new INFO Package called "dtmf", for the purpose of exchanging DTMF tone signals in the SIP signaling path. 3.1. Overall Description The dtmf INFO Package is used to carry DTMF tone signals, indicating the specific tone and duration, in "application/dtmf-relay" type MIME bodies in INFO requests messages inside an INVITE-based dialog. 4. Overview of Operation The general concept is that the UAC and UAS negotiate support for a "dtmf" INFO Package during the initial INVITE transaction, using the [info-package] mechanism. Including the "dtmf" INFO Package name in the Recv-Info header field means the UA sending the header supports receiving DTMF events using this mechanism. When the far-end has indicated that the it 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 type attachment in the INFO, described later in this document. Kaplan Expires - February 2011 [Page 3] Internet-Draft SIP INFO Package for DTMF August 2010 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 Package Definition 5.1. INFO Package Name This document defines a SIP INFO Package as defined in [info- packages]. The INFO Package token name for this package is "dtmf". 5.2. INFO Bodies Applications using this INFO 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 button button = 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" INFO Package, per the rules in [info-packages]. If [RFC4733] (i.e., RTP-based DTMF events) 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 simultaneously. 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, and MUST also send such through a [KPML] Notify 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 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 Kaplan Expires - February 2011 [Page 4] Internet-Draft SIP INFO Package for DTMF August 2010 supported by this mechanism, the UA should generate the INFO at that time. 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 To: Bob From: Alice ;tag=1234567 Call-Id: 123456mcmxcix CSeq: 1 INVITE Contact: Accept: application/sdp, application/dtmf-relay Recv-Info: dtmf Bob checks the headers, and can support receiving "dtmf". SIP/2.0 180 Ringing Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10 To: Bob ;tag=abcdefg From: Alice ;tag=1234567 Call-Id: 123456mcmxcix CSeq: 1 INVITE Accept: application/sdp, application/dtmf-relay Recv-Info: dtmf Since he sent the Recv-Info 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 To: Bob ;tag=abcdefg From: Alice ;tag=1234567 Call-Id: 123456mcmxcix CSeq: 1 INVITE Contact: Accept: application/sdp, application/dtmf-relay Recv-Info: dtmf Kaplan Expires - February 2011 [Page 5] Internet-Draft SIP INFO Package for DTMF August 2010 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: Info-Package: dtmf Content-Disposition: Info-Package 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- packages]. 8. IANA Considerations This document will presumably register the INFO Package name "dtmf" and "application/dtmf-relay" MIME type, if it moves forward. 9. References 9.1. Normative References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [info-packages] Holmberg, C., Burger, E., Kaplan, H., "Session Initiation Protocol (SIP) INFO Method and Package Framework", draft-ietf-sipcore-info-events-08, May 2010. Kaplan Expires - February 2011 [Page 6] Internet-Draft SIP INFO Package for DTMF August 2010 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 100 Crosby Drive Bedford, MA 01703 Email: hkaplan@acmepacket.com Kaplan Expires - February 2011 [Page 7]