[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Multiparty Multimedia Session                                  T. Taylor
Control (mmusic)                                                  Nortel
Internet-Draft                                           January 4, 2007
Updates: 4733 (if approved)
Intended status: Standards Track
Expires: July 8, 2007


   Signalling the Ability To Understand Packing of Multiple Telephony
                       Events Into One RTP Packet
                     draft-taylor-mmusic-multev-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/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 July 8, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2007).











Taylor                    Expires July 8, 2007                  [Page 1]


Internet-Draft     Signalling Event Packing Capability      January 2007


Abstract

   Section 2.5.1.5 of RFC 4733 specifies how an implementation of the
   telephony-event payload type can pack multiple short-duration event
   reports into one RTP packet.  Because this capability was added to
   RFC 4733 in a fashion which is not backward compatible with RFC 2833,
   it is desirable that a sender have the means to determine whether the
   receiver understands such packets.  This memo specifies a new SDP
   attribute, a=multev, to indicate that capability.


Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Proposed New SDP Attribute a=multev  . . . . . . . . . . . . .  5
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   6.  Normative References . . . . . . . . . . . . . . . . . . . . .  8
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .  9
   Intellectual Property and Copyright Statements . . . . . . . . . . 10






























Taylor                    Expires July 8, 2007                  [Page 2]


Internet-Draft     Signalling Event Packing Capability      January 2007


1.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in RFC 2119 [1].














































Taylor                    Expires July 8, 2007                  [Page 3]


Internet-Draft     Signalling Event Packing Capability      January 2007


2.  Introduction

   RFC 4733, recently published, has replaced RFC 2833.  The latter is
   best known as the preferred mechanism for in-band transmission of
   DTMF, but also had other applications including the transmission of
   data modem signals over RTP.  Section 2.5.1.5 of RFC 4733 introduced
   a new capability to optimize the usage of the telephone-event payload
   to carry a series of short-duration events such as those found in
   data modem signalling.  This new capability allows the sender to pack
   multiple event reports into a single RTP packet, provided that they
   occur consecutively without a pause between them.

   Unfortunately, packets containing multiple event reports cannot be
   processed properly by implementations of RFC 2833.  At best, an RFC
   2833 receiver would handle the first event in the packet
   successfully, but would ignore the remaining events in the packet.
   At worst, the RFC 2833 receiver would identify the packet as
   malformed and discard it.  In either case, meaningful information
   would fail to be transmitted.

   As a result, it is desirable for an RFC 4733 implementation to know
   in advance whether its peer acting as receiver has the capability to
   process multiple event reports in a single RTP packet.




























Taylor                    Expires July 8, 2007                  [Page 4]


Internet-Draft     Signalling Event Packing Capability      January 2007


3.  Proposed New SDP Attribute a=multev

   To meet the need just described, this memo introduces the

      a=multev

   SDP attribute.  If this attribute is present in a session
   description, it indicates that the originator of the session
   description can properly decode RTP packets containing multiple event
   reports as specified by RFC 4733 sections 2.5.1.5 and 2.5.2.4.

   The a=multev attribute MAY be present at either the session level or
   media level.  At the session level, this attribute indicates that the
   capability to decode multiple event reports in one RTP packet is
   applicable to any media stream within the session which carries the
   audio/telephone-event payload type.  At the media level, the a=multev
   attribute indicates the capability of decoding multiple event reports
   in an RTP packet for this particular stream (which typically will be
   limited to a specific set of events.)  If the attribute is present at
   both levels, the media-level occurrences serve as hints as to the
   particular streams in which packing of multiple events is expected.

   An implementation of RFC 4733 MAY choose always to report just one
   event per RTP packet, to guarantee backward compatibility.  In the
   alternative, an implementation of RFC 4733 that also supports the
   present memo MUST NOT encode multiple events into one RTP packet
   unless it has determined that its peer is able to decode those events
   properly.  The receipt of a session description containing the
   a=multev attribute is one means of making such a determination.  If
   this attribute is present only at the media level, the sender MUST
   NOT encode multiple events into one RTP packet for media streams
   other than those identified by the presence of the attribute.



















Taylor                    Expires July 8, 2007                  [Page 5]


Internet-Draft     Signalling Event Packing Capability      January 2007


4.  Security Considerations

   The a=multev attribute introduces no new security threats, with the
   possible exception that a man-in-the-middle attacker could insert the
   attribute into messages containing SDP where it was absent.  This
   would constitute a rather weak denial of service threat, since the
   SDP receiver might not choose to use the event packing capability
   even though the SDP sender seemingly signalled willingness to accept
   packed events.  Since since such an attacker is in a position to
   introduce much more effective attacks, there is little point to
   taking special measures to protect against this one.  In general,
   this points to a requirement to provide message integrity for
   signalling.






































Taylor                    Expires July 8, 2007                  [Page 6]


Internet-Draft     Signalling Event Packing Capability      January 2007


5.  IANA Considerations

   This document registers an additional SDP attribute "multev" as
   defined in this document, within the registry for "att-field (both
   session and media level)".

      multev       [RFCXXXX]

   NOTE TO THE RFC EDITOR: Please replace all occurrences of RFC XXXX by
   the RFC number assigned to this document.









































Taylor                    Expires July 8, 2007                  [Page 7]


Internet-Draft     Signalling Event Packing Capability      January 2007


6.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits,
        Telephony Tones, and Telephony Signals", RFC 4733,
        December 2006.











































Taylor                    Expires July 8, 2007                  [Page 8]


Internet-Draft     Signalling Event Packing Capability      January 2007


Author's Address

   Tom Taylor
   Nortel
   1852 Lorraine Ave
   Ottawa, Ontario  K1H 6Z8
   CA

   Email: taylor@nortel.com










































Taylor                    Expires July 8, 2007                  [Page 9]


Internet-Draft     Signalling Event Packing Capability      January 2007


Full Copyright Statement

   Copyright (C) The Internet Society (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 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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Taylor                    Expires July 8, 2007                 [Page 10]