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 <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=1234567
Call-Id: 123456mcmxcix
CSeq: 1 INVITE
Contact: <sip:alice@192.0.2.1>
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 <sip:bob@example.com>;tag=abcdefg
From: Alice <sip:alice@example.net>;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 <sip:bob@example.com>;tag=abcdefg
From: Alice <sip:alice@example.net>;tag=1234567
Call-Id: 123456mcmxcix
CSeq: 1 INVITE
Contact: <sip:bob@192.0.2.2>
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 <sip:alice@example.net>;tag=1234567
To: Bob <sip:bob@example.com>;tag=abcdefg
Call-Id: 123456mcmxcix
CSeq: 2 INFO
Contact: <sip:alice@192.0.2.1>
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]