One document matched: draft-taylor-mmusic-multev-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 10:28:41 |