Requirements from various WG for MMUSIC
draft-jennings-mmusic-media-req-00

Abstract

This document outlines some of the requirements driving various consideration related to multiplexing in the MMUSIC working group to meet the needs of WebRTC, CLUE, and other working groups.

This document is only meant to be used to help drive the discussion of solutions and is not intended to become an RFC.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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."

This Internet-Draft will expire on August 17, 2013.

Copyright Notice

Copyright (c) 2013 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 Simplified BSD License.

This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. Requirements
• 4. Non-Requirements
• 5. IANA Considerations
• 6. Security Considerations
• 7. Acknowledgements
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Authors' Addresses

1. Introduction

For the past several meetings, there has been discussions around various mechanism to reduce the number of UDP ports needed by applications for RTP. This document attempts to capture some of the requirements that are important in selecting the solution for how to represent the SDP to negotiate the RTP media that is using reduced ports.

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 [RFC2119]. This document generically uses RTP to mean RTP and SRTP.

3. Requirements

This section covers the requirements from various WG for setting up media. Obviously it does not try and cover all the requirements but it tries to cover a set that seem relevant to decisions around multiplexing onto few UDP ports.

High Priority Requirements:

1. Support many media flows but minimize the number of transport flows. For instance, all media flows--or perhaps all media flows of a given type--might be multiplexed over a single transport flow.
2. Be able to successfully negotiate media with both legacy SIP devices and new devices (whether SIP or RTCWEB) with a single offer/answer exchange. If both endpoints support multiplexed media, then multiplexing should be negotiated. Otherwise, non-multiplexed media should be used. In many cases, each endpoints will have no prior knowledge of capabilities of the other endpoint.

Other Requirements:

1. Need a uniform way to allow specifications of new SDP parameters to easily explain any implications that multiplexing has on the new parameters in that specification.
2. Allow different sources (E.g. cameras) to use different codecs. For example, if one camera had hardware encoders for VP8 while another had encoders for H.264, the device may wish to negotiate different codecs.
3. Be able to to independently set parameters such as resolution bandwidth, independently for each RTCWeb Track, preferably even when they are all multiplexed over the same transport flow.
4. Be able to identify the RTCWeb tracks with an identifier that is stable over the duration of the session. More information can be found in [I-D.alvestrand-mmusic-msid].

4. Non-Requirements

Some items are not a major goal. If methods are found that work for these as well, that is great, but they are not a priority item.

1. Working with SIP proxies or B2BUA that are not compliant with the standards. The reason for this is it is just not possible to design for every possible thing that does not do what the standards require.

5. IANA Considerations

This document makes no request of IANA.

6. Security Considerations

These requirements have no additional security considerations other than those captured in [I-D.ietf-rtcweb-security-arch].

7. Acknowledgements

Thanks to ...

8. References

8.1. Normative References

8.2. Informative References

Authors' Addresses