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 <sip:alice@example.net>;tag=1234567
To: Bob <sip:bob@example.com>
Call-Id: 123456mcmxcix
CSeq: 1 INVITE
Contact: <sip:alice@192.0.2.1>
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 <sip:alice@example.net>;tag=1234567
To: Bob <sip:bob@example.com>;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 <sip:alice@example.net>;tag=1234567
To: Bob <sip:bob@example.com>;tag=abcdefg
Kaplan Expires - May 2007 [Page 5]
DTMF Info-Event Package November 2007
Call-Id: 123456mcmxcix
CSeq: 1 INVITE
Contact: <sip:bob@192.0.2.2>
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 <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>
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]