One document matched: draft-alvestrand-one-rtp-00.txt
Network Working Group H. Alvestrand
Internet-Draft Google
Intended status: Standards Track August 11, 2011
Expires: February 12, 2012
SDP Grouping for Single RTP Sessions
draft-alvestrand-one-rtp-00
Abstract
This document describes an extension to the Session Description
Protocol (SDP) to describe RTP sessions where media of multiple top
level types, for example audio and video, are carried in the same RTP
session.
This document is presented to the RTCWEB, AVTCORE and MMUSIC WGs for
consideration.
Requirements Language
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].
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 February 12, 2012.
Copyright Notice
Copyright (c) 2011 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
Alvestrand Expires February 12, 2012 [Page 1]
Internet-Draft Single RTP Session Grouping August 2011
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements for a solution . . . . . . . . . . . . . . . . . . 3
3. SDP Grouping Framework Parameter . . . . . . . . . . . . . . . 3
4. Use in Offer/Answer . . . . . . . . . . . . . . . . . . . . . . 4
5. Interaction with other extensions . . . . . . . . . . . . . . . 4
6. RTCP bandwidth considerations . . . . . . . . . . . . . . . . . 5
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
11.1. Normative References . . . . . . . . . . . . . . . . . . . 7
11.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Alvestrand Expires February 12, 2012 [Page 2]
Internet-Draft Single RTP Session Grouping August 2011
1. Introduction
In the work with the RTCWEB specifications
[I-D.ietf-rtcweb-overview], a need was discovered for representing
within the SDP framework an SDP session consisting of a single RTP
session, where that single RTP session, mapped to a single transport
flow, contained multiple top-level data types.
This is advantageous for the use case where there is no desire for
different treatment by the network of the different flows in the
session, there exist other appropriate mechanisms (for instance based
on SSRC) to identify the flows in the session to the applications,
and where the handling of multiple RTP sessions would increase the
work required to establish the session (for instance by requiring
multiple ICE [RFC5245] negotiations, or handling of failure cases
where one RTP session is established and another is not).
This document describes how to represent such a session.
2. Requirements for a solution
The requirements for our representation are:
o It should be possible to represent an SDP session consisting of a
single RTP session, where that session carries both audio and
video.
o If this description is presented in an Offer in the offer/answer
model to an entity that does not understand it, the resulting
Answer should contain a valid description of an SDP session
consisting of one video RTP session and one audio RTP session.
3. SDP Grouping Framework Parameter
This document defines a new semantics extension called TOGETHER
within the SDP Grouping framework [RFC5888].
If this semantics extension is present in an SDP Session-level
a=group: line, the semantics are that the two or more m lines are
intended to be read as components of a single RTP session, creating a
single SSRC numbering space that can contain components of all the
types described in the referenced media sections.
The following properties of the media sections are REQUIRED:
Alvestrand Expires February 12, 2012 [Page 3]
Internet-Draft Single RTP Session Grouping August 2011
o The defined RTPMAP values of the section MUST NOT overlap
o The profile of the sections MUST be the same (e.g RTP/AVPF)
The media sections MAY contain connection data (port numbers or ICE
parameters), but some of these may be ignored in processing (see next
section).
4. Use in Offer/Answer
This extension MAY be included in an Offer; if it is not included in
an Offer, it MUST NOT be included in an answer. [Note: I believe
this to be true for all extensions within the Grouping framework.
Check.]
If the responder understands the semantics of the TOGETHER extension,
the parameters of the first section MUST be used to establish the RTP
session, and the parameters for the other sections MUST be ignored.
The following parameters are taken from the first section only:
o Port number from the m= line
o All media-level attributes defined in RFC 5245 section 15.1 - this
includes "candidate", "remote-candidates", "ice-mismatch", "ice-
ufrag", "ice-pwd"
The bandwidth of the "m" line is treated specially: The values for
all "m=" lines in the group are added together, and the resulting
value is taken to be the negotiated bandwidth value for the RTP
session.
The expected behaviour when the extension is present in an offer and
not understood is that the generated answer will not contain the
"a=group:TOGETHER" line, and that each sections' parameters will be
used.
5. Interaction with other extensions
If other extensions modify the bandwidth calculation algorithm, those
extensions will have to take into consideration how bandwidth from
multiple sections of the SDP description should be merged.
Alvestrand Expires February 12, 2012 [Page 4]
Internet-Draft Single RTP Session Grouping August 2011
6. RTCP bandwidth considerations
A concern has been raised that when audio and video are combined, the
bandwidth of RTCP reports required for an audio stream may exceed the
bandwidth of the audio stream itself, which seems a bit bizarre.
While not critical (overall RTCP bandwidth is still limited to 5% of
the total bandwidth), this warrants a little more study.
Considering a combined RTP session with one sender and one recipient,
four 1-Mbit/sec video flows and four 100-Kbit/sec audio flows flowing
in one direction.
The total bandwidth is 4.4 Mbit/sec, so if the RTCP share of the
bandwidth is 5% as recommended by RFC 3550 section 6.2, the RTCP
bandwidth limit is 220 Kbits/sec. Eight SSRCs need to be reported
on.
[CHECK: Does this mean there are 9 reporters (8 senders and 1
receiver), or 2 reporters (1 of each)? Assuming 9.]
Each report sender will have 24.4 Kbits/second of RTCP bandwidth at
its disposal. Assuming a packet size of 100 bytes (11 bytes per SSRC
reported on), the maximum RTCP rate allowed is 30 RTCP packets per
second, which is slightly slower than the typical audio heartbeat
flow of 50 packets per second (20 ms interval).
If this is deemed excessive, one can adopt the RTP/AVPF model of
5-second regular RTCP reports with additional availability of "on-
demand" RTCP packets. But the RTCP feedback interval also enters
into congestion control algorithms, which may complicate the picture.
7. Examples
The examples are taken from RFC 4317, "SDP Offer/Answer Examples".
Alvestrand Expires February 12, 2012 [Page 5]
Internet-Draft Single RTP Session Grouping August 2011
Offer
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
a=group:TOGETHER foo bar
m=audio 49170 RTP/AVP 0 8 97
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 51372 RTP/AVP 31 32
a=mid:bar
b=AS:1000
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
This is a request to have both audio and video sent over port 49170.
If this can't be done, audio will be sent over port 49170, and video
will be sent on port 51372. The total bandwidth, if combined, is
1200 Kbits/second; if separated, 200 Kbits goes to audio and 1000
Kbits goes to video.
Answer, from an entity that understands TOGETHER
v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
s=
c=IN IP4 host.biloxi.example.com
t=0 0
a=group:TOGETHER foo bar
m=audio 49174 RTP/AVP 0
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
m=video 49170 RTP/AVP 32
a=mid:bar
b=AS:1000
a=rtpmap:32 MPV/90000
Alvestrand Expires February 12, 2012 [Page 6]
Internet-Draft Single RTP Session Grouping August 2011
Answer, from an entity that understands grouping, but does not
understand TOGETHER
v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
s=
c=IN IP4 host.biloxi.example.com
t=0 0
m=audio 49174 RTP/AVP 0
a=mid:foo
a=rtpmap:0 PCMU/8000
b=AS:200
m=video 49170 RTP/AVP 32
a=mid:bar
a=rtpmap:32 MPV/90000
b=AS:1000
8. IANA Considerations
This document requests IANA to register the new SDP Grouping semantic
extension called TOGETHER.
9. Security Considerations
No new security issues have been raised specifically for this
extension.
Third-party interceptors that sniff negotiation but do not understand
the extension may end up listening to the wrong port number for some
of the media flows. This is not deemed greatly harmful.
10. Acknowledgements
This draft is based on a discussion between a number of participants
at the Quebec City IETF, July 2011, about the issue of multiplexing
audio and video on a single network transport using RTP.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Alvestrand Expires February 12, 2012 [Page 7]
Internet-Draft Single RTP Session Grouping August 2011
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
11.2. Informative References
[I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Brower-
based Applications", draft-ietf-rtcweb-overview-00 (work
in progress), June 2011.
Author's Address
Harald Tveit Alvestrand
Google
Kungsbron 2
Stockholm, 11122
Sweden
Email: harald@alvestrand.no
Alvestrand Expires February 12, 2012 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 01:16:40 |