[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/