draft-ietf-avtext-rtp-stream-pause-04.txt   draft-ietf-avtext-rtp-stream-pause-05.txt 
Network Working Group B. Burman Network Working Group B. Burman
Internet-Draft A. Akram Internet-Draft A. Akram
Updates: 5104 (if approved) Ericsson Updates: 5104 (if approved) Ericsson
Intended status: Standards Track R. Even Intended status: Standards Track R. Even
Expires: April 17, 2015 Huawei Technologies Expires: April 30, 2015 Huawei Technologies
M. Westerlund M. Westerlund
Ericsson Ericsson
October 14, 2014 October 27, 2014
RTP Stream Pause and Resume RTP Stream Pause and Resume
draft-ietf-avtext-rtp-stream-pause-04 draft-ietf-avtext-rtp-stream-pause-05
Abstract Abstract
With the increased popularity of real-time multimedia applications, With the increased popularity of real-time multimedia applications,
it is desirable to provide good control of resource usage, and users it is desirable to provide good control of resource usage, and users
also demand more control over communication sessions. This document also demand more control over communication sessions. This document
describes how a receiver in a multimedia conversation can pause and describes how a receiver in a multimedia conversation can pause and
resume incoming data from a sender by sending real-time feedback resume incoming data from a sender by sending real-time feedback
messages when using Real-time Transport Protocol (RTP) for real time messages when using Real-time Transport Protocol (RTP) for real time
data transport. This document extends the Codec Control Messages data transport. This document extends the Codec Control Messages
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 17, 2015. This Internet-Draft will expire on April 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Requirements Language . . . . . . . . . . . . . . . . . . 7 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 7
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Point to Point . . . . . . . . . . . . . . . . . . . . . 7 3.1. Point to Point . . . . . . . . . . . . . . . . . . . . . 7
3.2. RTP Mixer to Media Sender . . . . . . . . . . . . . . . . 8 3.2. RTP Mixer to Media Sender . . . . . . . . . . . . . . . . 8
3.3. RTP Mixer to Media Sender in Point-to-Multipoint . . . . 9 3.3. RTP Mixer to Media Sender in Point-to-Multipoint . . . . 9
3.4. Media Receiver to RTP Mixer . . . . . . . . . . . . . . . 10 3.4. Media Receiver to RTP Mixer . . . . . . . . . . . . . . . 10
3.5. Media Receiver to Media Sender Across RTP Mixer . . . . . 10 3.5. Media Receiver to Media Sender Across RTP Mixer . . . . . 10
skipping to change at page 3, line 9 skipping to change at page 3, line 9
4.3. Apply to Individual Sources . . . . . . . . . . . . . . . 12 4.3. Apply to Individual Sources . . . . . . . . . . . . . . . 12
4.4. Consensus . . . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Consensus . . . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Message Acknowledgments . . . . . . . . . . . . . . . . . 12 4.5. Message Acknowledgments . . . . . . . . . . . . . . . . . 12
4.6. Request Retransmission . . . . . . . . . . . . . . . . . 13 4.6. Request Retransmission . . . . . . . . . . . . . . . . . 13
4.7. Sequence Numbering . . . . . . . . . . . . . . . . . . . 13 4.7. Sequence Numbering . . . . . . . . . . . . . . . . . . . 13
4.8. Relation to Other Solutions . . . . . . . . . . . . . . . 13 4.8. Relation to Other Solutions . . . . . . . . . . . . . . . 13
5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 14 5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Expressing Capability . . . . . . . . . . . . . . . . . . 15 5.1. Expressing Capability . . . . . . . . . . . . . . . . . . 15
5.2. Requesting to Pause . . . . . . . . . . . . . . . . . . . 15 5.2. Requesting to Pause . . . . . . . . . . . . . . . . . . . 15
5.3. Media Sender Pausing . . . . . . . . . . . . . . . . . . 16 5.3. Media Sender Pausing . . . . . . . . . . . . . . . . . . 16
5.4. Requesting to Resume . . . . . . . . . . . . . . . . . . 17 5.4. Requesting to Resume . . . . . . . . . . . . . . . . . . 18
5.5. TMMBR/TMMBN Considerations . . . . . . . . . . . . . . . 19 5.5. TMMBR/TMMBN Considerations . . . . . . . . . . . . . . . 19
6. Participant States . . . . . . . . . . . . . . . . . . . . . 19 6. Participant States . . . . . . . . . . . . . . . . . . . . . 19
6.1. Playing State . . . . . . . . . . . . . . . . . . . . . . 20 6.1. Playing State . . . . . . . . . . . . . . . . . . . . . . 20
6.2. Pausing State . . . . . . . . . . . . . . . . . . . . . . 20 6.2. Pausing State . . . . . . . . . . . . . . . . . . . . . . 20
6.3. Paused State . . . . . . . . . . . . . . . . . . . . . . 21 6.3. Paused State . . . . . . . . . . . . . . . . . . . . . . 21
6.3.1. RTCP BYE Message . . . . . . . . . . . . . . . . . . 21 6.3.1. RTCP BYE Message . . . . . . . . . . . . . . . . . . 21
6.3.2. SSRC Time-out . . . . . . . . . . . . . . . . . . . . 22 6.3.2. SSRC Time-out . . . . . . . . . . . . . . . . . . . . 22
6.4. Local Paused State . . . . . . . . . . . . . . . . . . . 22 6.4. Local Paused State . . . . . . . . . . . . . . . . . . . 22
7. Message Format . . . . . . . . . . . . . . . . . . . . . . . 22 7. Message Format . . . . . . . . . . . . . . . . . . . . . . . 23
8. Message Details . . . . . . . . . . . . . . . . . . . . . . . 25 8. Message Details . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.2. PAUSED . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.2. PAUSED . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.3. RESUME . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.3. RESUME . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.4. REFUSED . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.4. REFUSED . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.5. Transmission Rules . . . . . . . . . . . . . . . . . . . 28 8.5. Transmission Rules . . . . . . . . . . . . . . . . . . . 28
9. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Offer-Answer Use . . . . . . . . . . . . . . . . . . . . 32 9.1. Offer-Answer Use . . . . . . . . . . . . . . . . . . . . 32
9.2. Declarative Use . . . . . . . . . . . . . . . . . . . . . 33 9.2. Declarative Use . . . . . . . . . . . . . . . . . . . . . 33
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 33 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 33
10.1. Offer-Answer . . . . . . . . . . . . . . . . . . . . . . 33 10.1. Offer-Answer . . . . . . . . . . . . . . . . . . . . . . 34
10.2. Point-to-Point Session . . . . . . . . . . . . . . . . . 35 10.2. Point-to-Point Session . . . . . . . . . . . . . . . . . 35
10.3. Point-to-Multipoint using Mixer . . . . . . . . . . . . 39 10.3. Point-to-Multipoint using Mixer . . . . . . . . . . . . 39
10.4. Point-to-Multipoint using Translator . . . . . . . . . . 41 10.4. Point-to-Multipoint using Translator . . . . . . . . . . 41
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
12. Security Considerations . . . . . . . . . . . . . . . . . . . 45 12. Security Considerations . . . . . . . . . . . . . . . . . . . 45
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 45 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 45
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
15.1. Normative References . . . . . . . . . . . . . . . . . . 46 15.1. Normative References . . . . . . . . . . . . . . . . . . 46
15.2. Informative References . . . . . . . . . . . . . . . . . 46 15.2. Informative References . . . . . . . . . . . . . . . . . 46
Appendix A. Changes From Earlier Versions . . . . . . . . . . . 47 Appendix A. Changes From Earlier Versions . . . . . . . . . . . 47
A.1. Modifications Between Version -02 and -03 . . . . . . . . 47 A.1. Modifications Between Version -04 and -05 . . . . . . . . 47
A.2. Modifications Between Version -01 and -02 . . . . . . . . 48 A.2. Modifications Between Version -03 and -04 . . . . . . . . 47
A.3. Modifications Between Version -00 and -01 . . . . . . . . 48 A.3. Modifications Between Version -02 and -03 . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 A.4. Modifications Between Version -01 and -02 . . . . . . . . 48
A.5. Modifications Between Version -00 and -01 . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
As real-time communication attracts more people, more applications As real-time communication attracts more people, more applications
are created; multimedia conversation applications being one example. are created; multimedia conversation applications being one example.
Multimedia conversation further exists in many forms, for example, Multimedia conversation further exists in many forms, for example,
peer-to-peer chat application and multiparty video conferencing peer-to-peer chat application and multiparty video conferencing
controlled by central media nodes, such as RTP Mixers. controlled by central media nodes, such as RTP Mixers.
Multimedia conferencing may involve many participants; each has its Multimedia conferencing may involve many participants; each has its
skipping to change at page 11, line 36 skipping to change at page 11, line 36
possible reasons why a receiver may pause an RTP sender. Pausing and possible reasons why a receiver may pause an RTP sender. Pausing and
resuming is time-dependent, i.e. a receiver may choose to pause an resuming is time-dependent, i.e. a receiver may choose to pause an
RTP stream for a certain duration, after which the receiver may want RTP stream for a certain duration, after which the receiver may want
the sender to resume. This time dependency means that the messages the sender to resume. This time dependency means that the messages
related to pause and resume must be transmitted to the sender in related to pause and resume must be transmitted to the sender in
real-time in order for them to be purposeful. The pause operation is real-time in order for them to be purposeful. The pause operation is
arguably not very time critical since it mainly provides a reduction arguably not very time critical since it mainly provides a reduction
of resource usage. Timely handling of the resume operation is of resource usage. Timely handling of the resume operation is
however likely to directly impact the end-user's perceived quality however likely to directly impact the end-user's perceived quality
experience, since it affects the availability of media that the user experience, since it affects the availability of media that the user
expects to receive more or less instantly. expects to receive more or less instantly. It may also be highly
desirable for a receiver to quickly learn that an RTP stream is
intentionally paused on the RTP sender's own behalf.
4.2. Message Direction 4.2. Message Direction
It is the responsibility of an RTP stream receiver, who wants to It is the responsibility of an RTP stream receiver, who wants to
pause or resume a stream from the sender(s), to transmit PAUSE and pause or resume a stream from the sender(s), to transmit PAUSE and
RESUME messages. An RTP stream sender who likes to pause itself, can RESUME messages. An RTP stream sender who likes to pause itself, can
often simply do it, but sometimes this will adversely affect the often simply do it, but sometimes this will adversely affect the
receiver and an explicit indication that the RTP stream is paused may receiver and an explicit indication that the RTP stream is paused may
then help. Any indication that an RTP stream is paused is the then help. Any indication that an RTP stream is paused is the
responsibility of the RTP stream sender and may in some cases not responsibility of the RTP stream sender and may in some cases not
skipping to change at page 13, line 16 skipping to change at page 13, line 16
4.6. Request Retransmission 4.6. Request Retransmission
When the stream is not affected as expected by a PAUSE or RESUME When the stream is not affected as expected by a PAUSE or RESUME
request, the request may have been lost and the sender of the request request, the request may have been lost and the sender of the request
will need to retransmit it. The retransmission should take the round will need to retransmit it. The retransmission should take the round
trip time into account, and will also need to take the normal RTCP trip time into account, and will also need to take the normal RTCP
bandwidth and timing rules applicable to the RTP session into bandwidth and timing rules applicable to the RTP session into
account, when scheduling retransmission of feedback. account, when scheduling retransmission of feedback.
When it comes to resume requests that are more time critical, the When it comes to resume requests or unsolicited paused indications
best resume performance may be achieved by repeating the request as that are more time critical, the best performance may be achieved by
often as possible until a sufficient number have been sent to reach a repeating the message as often as possible until a sufficient number
high probability of request delivery, or the stream gets delivered. have been sent to reach a high probability of message delivery, or at
an explicit indication that the message was delivered. For resume
requests, such explicit indication can be delivery of the RTP stream
being requested to be resumed.
4.7. Sequence Numbering 4.7. Sequence Numbering
A PAUSE request message will need to have a sequence number to A PAUSE request message will need to have a sequence number to
separate retransmissions from new requests. A retransmission keeps separate retransmissions from new requests. A retransmission keeps
the sequence number unchanged, while it is incremented every time a the sequence number unchanged, while it is incremented every time a
new PAUSE request is transmitted that is not a retransmission of a new PAUSE request is transmitted that is not a retransmission of a
previous request. previous request.
Since RESUME always takes precedence over PAUSE and are even allowed Since RESUME always takes precedence over PAUSE and are even allowed
skipping to change at page 17, line 7 skipping to change at page 17, line 11
This can either be as a result of receiving a PAUSE, or be based on This can either be as a result of receiving a PAUSE, or be based on
some local sender consideration. When it does, it sends a PAUSED some local sender consideration. When it does, it sends a PAUSED
indication, containing the available PauseID. Note that PauseID is indication, containing the available PauseID. Note that PauseID is
incremented when sending an unsolicited PAUSED (without having incremented when sending an unsolicited PAUSED (without having
received a PAUSE). It also sends the PAUSED indication in the next received a PAUSE). It also sends the PAUSED indication in the next
two regular RTCP reports, given that the pause condition is then two regular RTCP reports, given that the pause condition is then
still effective. still effective.
There is no reply to a PAUSED indication; it is simply an explicit There is no reply to a PAUSED indication; it is simply an explicit
indication of the fact that an RTP stream is paused. This can be indication of the fact that an RTP stream is paused. This can be
helpful for the RTP stream receiver, for example to understand that helpful for the RTP stream receiver, for example to quickly
transmission is deliberately and temporarily suspended and no understand that transmission is deliberately and temporarily
specific corrective action is needed. suspended and no specific corrective action is needed.
The RTP stream sender may want to apply some local consideration to The RTP stream sender may want to apply some local consideration to
exactly when the RTP stream is paused, for example completing some exactly when the RTP stream is paused, for example completing some
media unit or a forward error correction block, before pausing the media unit or a forward error correction block, before pausing the
stream. stream.
The PAUSED indication also contains information about the RTP The PAUSED indication also contains information about the RTP
extended highest sequence number when the pause became effective. extended highest sequence number when the pause became effective.
This provides RTP stream receivers with first hand information This provides RTP stream receivers with first hand information
allowing them to know whether they lost any packets just before the allowing them to know whether they lost any packets just before the
skipping to change at page 22, line 20 skipping to change at page 22, line 20
packets from some other participant for the last five RTCP reporting packets from some other participant for the last five RTCP reporting
intervals it removes that participant from the receiver list. Any intervals it removes that participant from the receiver list. Any
streams that were paused by that removed participant SHALL be streams that were paused by that removed participant SHALL be
resumed. resumed.
6.4. Local Paused State 6.4. Local Paused State
This state can be entered at any time, based on local decision from This state can be entered at any time, based on local decision from
the RTP stream sender. As for Paused State (Section 6.3), the RTP the RTP stream sender. As for Paused State (Section 6.3), the RTP
stream sender SHALL send a PAUSED indication to all known RTP stream stream sender SHALL send a PAUSED indication to all known RTP stream
receivers, when entering the state, and repeat it in the next two receivers, when entering the state, and repeat it a sufficient number
regular RTCP reports, unless the stream was already in paused state of times to reach a high probability that the message is correctly
(Section 6.3). When using TMMBN 0 as PAUSED indication, being in delivered, unless the stream was already in paused state
paused state, and entering local paused state, the RTP stream sender (Section 6.3).
SHALL send TMMBN 0 with itself included in the TMMBN bounding set.
Editor's note: Consider specifying an explicit PAUSED ACK message
that stops this message retransmission.
When using TMMBN 0 as PAUSED indication, being in paused state, and
entering local paused state, the RTP stream sender SHALL send TMMBN 0
with itself included in the TMMBN bounding set.
As indicated in Figure 4, this state has higher precedence than As indicated in Figure 4, this state has higher precedence than
paused state (Section 6.3) and RESUME messages alone cannot resume a paused state (Section 6.3) and RESUME messages alone cannot resume a
paused RTP stream as long as the local decision still applies. paused RTP stream as long as the local decision still applies.
Pausing an RTP stream MUST NOT affect the sending of RTP keepalive Pausing an RTP stream MUST NOT affect the sending of RTP keepalive
[RFC6263][RFC5245] applicable to that RTP stream. [RFC6263][RFC5245] applicable to that RTP stream.
When leaving the state, the stream state SHALL become Playing, When leaving the state, the stream state SHALL become Playing,
regardless whether or not there were any RTP stream receivers that regardless whether or not there were any RTP stream receivers that
skipping to change at page 29, line 14 skipping to change at page 29, line 14
All messages defined in this specification, as well as TMMBR/TMMBN All messages defined in this specification, as well as TMMBR/TMMBN
used for pause/resume purposes (Section 5.5), MAY use either Regular, used for pause/resume purposes (Section 5.5), MAY use either Regular,
Early or Immediate timings, taking the following into consideration: Early or Immediate timings, taking the following into consideration:
o PAUSE SHOULD use Early or Immediate timing, except for o PAUSE SHOULD use Early or Immediate timing, except for
retransmissions that SHOULD use Regular timing. retransmissions that SHOULD use Regular timing.
o The first transmission of PAUSED for each (non-wrapped) PauseID o The first transmission of PAUSED for each (non-wrapped) PauseID
SHOULD be sent with Immediate or Early timing, while subsequent SHOULD be sent with Immediate or Early timing, while subsequent
PAUSED for that PauseID SHOULD use Regular timing. PAUSED for that PauseID SHOULD use Regular timing. Unsolicited
PAUSED (sent when entering Local Paused State (Section 6.4))
SHOULD always use Immediate or Early timing, until PAUSED for that
PauseID is considered delivered at least once to all receivers of
the paused RTP stream, after which it SHOULD use Regular timing.
Editor's note: Consider specifying a PAUSED ACK message as
explicit indication of reception.
o RESUME SHOULD always use Immediate or Early timing. o RESUME SHOULD always use Immediate or Early timing.
o The first transmission of REFUSED for each (non-wrapped) PauseID o The first transmission of REFUSED for each (non-wrapped) PauseID
SHOULD be sent with Immediate or Early timing, while subsequent SHOULD be sent with Immediate or Early timing, while subsequent
REFUSED for that PauseID SHOULD use Regular timing. REFUSED for that PauseID SHOULD use Regular timing.
9. Signaling 9. Signaling
The capability of handling messages defined in this specification MAY The capability of handling messages defined in this specification MAY
skipping to change at page 45, line 49 skipping to change at page 45, line 49
13. Contributors 13. Contributors
Daniel Grondal contributed in the creation and writing of early Daniel Grondal contributed in the creation and writing of early
versions of this specification. Christian Groves contributed versions of this specification. Christian Groves contributed
significantly to the SDP config attribute and its use in Offer/ significantly to the SDP config attribute and its use in Offer/
Answer. Answer.
14. Acknowledgements 14. Acknowledgements
Daniel Grondal made valuable contributions during the initial Daniel Grondal made valuable contributions during the initial
versions of this draft. Christian Groves and Bernard Aboba provided versions of this draft. Emil Ivov, Christian Groves and Bernard
valuable review comments. Aboba provided valuable review comments.
15. References 15. References
15.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
skipping to change at page 47, line 42 skipping to change at page 47, line 42
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis,
"RTP Payload Format for Scalable Video Coding", RFC 6190, "RTP Payload Format for Scalable Video Coding", RFC 6190,
May 2011. May 2011.
Appendix A. Changes From Earlier Versions Appendix A. Changes From Earlier Versions
NOTE TO RFC EDITOR: Please remove this section prior to publication. NOTE TO RFC EDITOR: Please remove this section prior to publication.
A.1. Modifications Between Version -02 and -03 A.1. Modifications Between Version -04 and -05
o Added text in sections 4.1, 4.6, 6.4 and 8.5 on retransmission and
timing of unsolicited PAUSED, to improve the message timeliness
and probability of reception.
A.2. Modifications Between Version -03 and -04
o Change of Copyright boilerplate
A.3. Modifications Between Version -02 and -03
o Changed the section on SDP signaling to be more explicit and clear o Changed the section on SDP signaling to be more explicit and clear
in what is supported, replacing the 'paused' parameter and the in what is supported, replacing the 'paused' parameter and the
'dir' attribute with a 'config' parameter that can take a value, 'dir' attribute with a 'config' parameter that can take a value,
and an explicit listing of what each value means. and an explicit listing of what each value means.
o Added a sentence in section on paused state (Section 6.3) that o Added a sentence in section on paused state (Section 6.3) that
pause must not affect RTP keepalive. pause must not affect RTP keepalive.
o Replaced REFUSE message name with REFUSED throughout, to better o Replaced REFUSE message name with REFUSED throughout, to better
skipping to change at page 48, line 25 skipping to change at page 48, line 35
sent unsolicited due to RTP sender local considerations, the TMMBN sent unsolicited due to RTP sender local considerations, the TMMBN
message includes the RTP stream sender itself as part of the message includes the RTP stream sender itself as part of the
bounding set. bounding set.
o Clarified that there is no reply to a PAUSED indication. o Clarified that there is no reply to a PAUSED indication.
o Improved the IANA section. o Improved the IANA section.
o Editorial improvements. o Editorial improvements.
A.2. Modifications Between Version -01 and -02 A.4. Modifications Between Version -01 and -02
o Replaced most text on relation with other signaling technologies o Replaced most text on relation with other signaling technologies
in previous section 5 with a single, summarizing paragraph, as in previous section 5 with a single, summarizing paragraph, as
discussed at IETF 90 in Toronto, and placed it as the last sub- discussed at IETF 90 in Toronto, and placed it as the last sub-
section of section 4 (design considerations). section of section 4 (design considerations).
o Removed unused references. o Removed unused references.
A.3. Modifications Between Version -00 and -01 A.5. Modifications Between Version -00 and -01
o Corrected text in section 6.5 and 6.2 to indicate that a PAUSE o Corrected text in section 6.5 and 6.2 to indicate that a PAUSE
signaled via TMMBR 0 cannot be REFUSED using TMMBN > 0 signaled via TMMBR 0 cannot be REFUSED using TMMBN > 0
o Improved alignment with RTP Taxonomy draft, including the change o Improved alignment with RTP Taxonomy draft, including the change
of Packet Stream to RTP Stream of Packet Stream to RTP Stream
o Editorial improvements o Editorial improvements
Authors' Addresses Authors' Addresses
 End of changes. 18 change blocks. 
31 lines changed or deleted 61 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/