draft-ietf-avtext-rtp-stream-pause-09.txt   draft-ietf-avtext-rtp-stream-pause-10.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: March 6, 2016 Huawei Technologies Expires: March 14, 2016 Huawei Technologies
M. Westerlund M. Westerlund
Ericsson Ericsson
September 3, 2015 September 11, 2015
RTP Stream Pause and Resume RTP Stream Pause and Resume
draft-ietf-avtext-rtp-stream-pause-09 draft-ietf-avtext-rtp-stream-pause-10
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 March 6, 2016. This Internet-Draft will expire on March 14, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 40 skipping to change at page 2, line 40
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . 8
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
4. Design Considerations . . . . . . . . . . . . . . . . . . . . 11 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 11
4.1. Real-time Nature . . . . . . . . . . . . . . . . . . . . 11 4.1. Real-time Nature . . . . . . . . . . . . . . . . . . . . 11
4.2. Message Direction . . . . . . . . . . . . . . . . . . . . 11 4.2. Message Direction . . . . . . . . . . . . . . . . . . . . 11
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
skipping to change at page 3, line 37 skipping to change at page 3, line 37
9.1. Offer-Answer Use . . . . . . . . . . . . . . . . . . . . 36 9.1. Offer-Answer Use . . . . . . . . . . . . . . . . . . . . 36
9.2. Declarative Use . . . . . . . . . . . . . . . . . . . . . 37 9.2. Declarative Use . . . . . . . . . . . . . . . . . . . . . 37
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1. Offer-Answer . . . . . . . . . . . . . . . . . . . . . . 38 10.1. Offer-Answer . . . . . . . . . . . . . . . . . . . . . . 38
10.2. Point-to-Point Session . . . . . . . . . . . . . . . . . 40 10.2. Point-to-Point Session . . . . . . . . . . . . . . . . . 40
10.3. Point-to-Multipoint using Mixer . . . . . . . . . . . . 44 10.3. Point-to-Multipoint using Mixer . . . . . . . . . . . . 44
10.4. Point-to-Multipoint using Translator . . . . . . . . . . 46 10.4. Point-to-Multipoint using Translator . . . . . . . . . . 46
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
12. Security Considerations . . . . . . . . . . . . . . . . . . . 50 12. Security Considerations . . . . . . . . . . . . . . . . . . . 50
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
15.1. Normative References . . . . . . . . . . . . . . . . . . 52 15.1. Normative References . . . . . . . . . . . . . . . . . . 52
15.2. Informative References . . . . . . . . . . . . . . . . . 53 15.2. Informative References . . . . . . . . . . . . . . . . . 53
Appendix A. Changes From Earlier Versions . . . . . . . . . . . 54 Appendix A. Changes From Earlier Versions . . . . . . . . . . . 54
A.1. Modifications Between Version -08 and -09 . . . . . . . . 54 A.1. Modifications Between Version -09 and -10 . . . . . . . . 54
A.2. Modifications Between Version -07 and -08 . . . . . . . . 55 A.2. Modifications Between Version -08 and -09 . . . . . . . . 54
A.3. Modifications Between Version -06 and -07 . . . . . . . . 56 A.3. Modifications Between Version -07 and -08 . . . . . . . . 55
A.4. Modifications Between Version -05 and -06 . . . . . . . . 57 A.4. Modifications Between Version -06 and -07 . . . . . . . . 56
A.5. Modifications Between Version -04 and -05 . . . . . . . . 58 A.5. Modifications Between Version -05 and -06 . . . . . . . . 57
A.6. Modifications Between Version -03 and -04 . . . . . . . . 58 A.6. Modifications Between Version -04 and -05 . . . . . . . . 58
A.7. Modifications Between Version -02 and -03 . . . . . . . . 58 A.7. Modifications Between Version -03 and -04 . . . . . . . . 58
A.8. Modifications Between Version -01 and -02 . . . . . . . . 59 A.8. Modifications Between Version -02 and -03 . . . . . . . . 58
A.9. Modifications Between Version -00 and -01 . . . . . . . . 59 A.9. Modifications Between Version -01 and -02 . . . . . . . . 59
A.10. Modifications Between Version -00 and -01 . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59
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.
skipping to change at page 50, line 40 skipping to change at page 50, line 40
one or more PAUSE requests into the RTP session, an attacker can one or more PAUSE requests into the RTP session, an attacker can
potentially prevent any media from flowing, especially when the hold- potentially prevent any media from flowing, especially when the hold-
off period is zero. The injection of PAUSE messages is quite simple, off period is zero. The injection of PAUSE messages is quite simple,
requiring knowledge of the SSRC and the PauseID. This information is requiring knowledge of the SSRC and the PauseID. This information is
visible to an on-path attacker unless RTCP messages are encrypted. visible to an on-path attacker unless RTCP messages are encrypted.
Even off-path attacks are possible as signalling messages often carry Even off-path attacks are possible as signalling messages often carry
the SSRC value, while the 16-bit PauseID have to be guessed or tried. the SSRC value, while the 16-bit PauseID have to be guessed or tried.
The way of protecting the RTP session from these injections is to The way of protecting the RTP session from these injections is to
perform source authentication combined with message integrity, to perform source authentication combined with message integrity, to
prevent other than intended session participants from sending these prevent other than intended session participants from sending these
messages. The security solution should provide replay protection, messages. The security solution should provide replay protection.
otherwise an attacker could for sessions that are long lived enough Otherwise, if a session is long-lived enough for the PauseID value to
to wrap the PauseID replay old messages at the appropriate time to wrap, an attacker could replay old messages at the appropriate time
influence the media sender state. There exist several different to influence the media sender state. There exist several different
choices for securing RTP sessions to prevent this type of attack. choices for securing RTP sessions to prevent this type of attack.
SRTP is the most common, but also other methods exist as discussed in SRTP is the most common, but also other methods exist as discussed in
"Options for Securing RTP Sessions" [RFC7201]. "Options for Securing RTP Sessions" [RFC7201].
Most of the methods for securing RTP however do not provide source Most of the methods for securing RTP however do not provide source
authentication of each individual participant in a multi-party use authentication of each individual participant in a multi-party use
case. In case one of the session participants is malicious, it can case. In case one of the session participants is malicious, it can
wreck significant havoc within the RTP session and similarly cause a wreck significant havoc within the RTP session and similarly cause a
DoS on the RTP session from within. That damage can also be DoS on the RTP session from within. That damage can also be
attempted to be obfuscated by having the attacker impersonate other attempted to be obfuscated by having the attacker impersonate other
endpoints within the session. These attacks can be mitigated by endpoints within the session. These attacks can be mitigated by
using a solution that provides true source authentication of all using a solution that provides true source authentication of all
participants' RTCP packets. However, that has other implications. participants' RTCP packets. However, that has other implications.
For multi-party sessions including a middlebox, that middlebox is For multi-party sessions including a middlebox, that middlebox is
RECOMMENDED to perform checks on all forwarded RTCP packets so that RECOMMENDED to perform checks on all forwarded RTCP packets so that
each participant only uses its set of SSRCs, to prevent the attacker each participant only uses its set of SSRCs, to prevent the attacker
utilizing another participant's SSRCs. An attacker that can send a utilizing another participant's SSRCs. An attacker that can send a
PAUSE request without it reaching any other participant than the PAUSE request that does not reach any other participants than the
media sender can have its request being unopposed. This is mitigated media sender can cause a stream to be paused without providing
in multi-party topologies that ensure that requests are seen by all opportunity for opposition. This is mitigated in multi-party
or most of the RTP session participants, enabling these participants topologies that ensure that requests are seen by all or most of the
to send RESUME. In topologies with middleboxes that consume and RTP session participants, enabling these participants to send RESUME.
process PAUSE requests, the middlebox can also mitigate such behavior In topologies with middleboxes that consume and process PAUSE
as it will commonly not generate or forward a PAUSE message if it requests, the middlebox can also mitigate such behavior as it will
knows of another participant having use for the media stream. commonly not generate or forward a PAUSE message if it knows of
another participant having use for the media stream.
The above text has been focused on using the PAUSE message as the The above text has been focused on using the PAUSE message as the
tool for malicious impact on the RTP session. That is because of the tool for malicious impact on the RTP session. That is because of the
greater impact from denying users access to RTP media streams. In greater impact from denying users access to RTP media streams. In
contrast, if an attacker attempts to use RESUME in a malicious contrast, if an attacker attempts to use RESUME in a malicious
purpose, it will result in that the media streams are delivered. purpose, it will result in that the media streams are delivered.
However, such an attack basically prevents the use the Pause and However, such an attack basically prevents the use the Pause and
Resume functionality. Thus, potentially forcing a reduction of the Resume functionality. Thus, potentially forcing a reduction of the
media quality due to limitation in available resources, like media quality due to limitation in available resources, like
bandwidth that must be shared. bandwidth that must be shared.
skipping to change at page 51, line 51 skipping to change at page 52, line 9
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. The authors would also like to thank Emil versions of this draft. The authors would also like to thank Emil
Ivov, Christian Groves, David Madnelberg, Meral Shirazipour, Spencer Ivov, Christian Groves, David Mandelberg, Meral Shirazipour, Spencer
Dawkins, Bernard Aboba, and Ben Campbell, who provided valuable Dawkins, Bernard Aboba, and Ben Campbell, who provided valuable
review comments. 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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
skipping to change at page 54, line 23 skipping to change at page 54, line 29
[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
Time Communication Use Cases and Requirements", RFC 7478, Time Communication Use Cases and Requirements", RFC 7478,
DOI 10.17487/RFC7478, March 2015, DOI 10.17487/RFC7478, March 2015,
<http://www.rfc-editor.org/info/rfc7478>. <http://www.rfc-editor.org/info/rfc7478>.
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 -08 and -09 A.1. Modifications Between Version -09 and -10
Changes based on AD review of changes:
o Editorial rewordings in Security Consideration
A.2. Modifications Between Version -08 and -09
Changes based on IETF last call and IESG comments. Changes based on IETF last call and IESG comments.
o Expanded some acronyms on first usage. o Expanded some acronyms on first usage.
o Clarified why this document updated RFC 5104. o Clarified why this document updated RFC 5104.
o Removed some unused abbreviations. o Removed some unused abbreviations.
o Clarified when TMMBR/TMMBN is expected to be used in Section 5.6. o Clarified when TMMBR/TMMBN is expected to be used in Section 5.6.
skipping to change at page 55, line 9 skipping to change at page 55, line 21
when one may still send messages not supported by every receiver when one may still send messages not supported by every receiver
of that message. Also clarified that TMMBR/TMMBN for pause is of that message. Also clarified that TMMBR/TMMBN for pause is
monolithic in capability. monolithic in capability.
o Security consideration was updated to consider replay attacks. o Security consideration was updated to consider replay attacks.
o Security consideration was updated to describe the mitigation o Security consideration was updated to describe the mitigation
against malicous RTP session participants in multi-party cases against malicous RTP session participants in multi-party cases
that seeing all messages provide. that seeing all messages provide.
A.2. Modifications Between Version -07 and -08 A.3. Modifications Between Version -07 and -08
Changes based on IESG AD Evaluation. Changes based on IESG AD Evaluation.
o Moved the mentioning of RTCWEB RFC7478 API requirements out from o Moved the mentioning of RTCWEB RFC7478 API requirements out from
3.1 to section 3, adding a couple of clarifying sentences. 3.1 to section 3, adding a couple of clarifying sentences.
o Highlighted that the use case in section 3.4 deals with a o Highlighted that the use case in section 3.4 deals with a
different direction of the pause request than the previous use different direction of the pause request than the previous use
cases. cases.
skipping to change at page 56, line 30 skipping to change at page 56, line 41
all received messages to all receivers, not only the first PAUSE all received messages to all receivers, not only the first PAUSE
message. message.
o Changed references to RFC3264 and RFC4566 to be normative. o Changed references to RFC3264 and RFC4566 to be normative.
o Updated ietf-rtcweb-use-cases-and-requirements reference to be o Updated ietf-rtcweb-use-cases-and-requirements reference to be
RFC7478. RFC7478.
o Editorial improvements and clarifications. o Editorial improvements and clarifications.
A.3. Modifications Between Version -06 and -07 A.4. Modifications Between Version -06 and -07
o Completely rewrote the Security Consideration section. o Completely rewrote the Security Consideration section.
o Aligned text such that REFUSED is always referred to as a o Aligned text such that REFUSED is always referred to as a
notification, not indication. notification, not indication.
o Added and changed text in several places, clarifying the case when o Added and changed text in several places, clarifying the case when
TMMBR/TMMBN bounding set overhead value matters, related to TMMBR/TMMBN bounding set overhead value matters, related to
whether local RTP stream sender or remote RTP stream receiver owns whether local RTP stream sender or remote RTP stream receiver owns
the TMMBR 0 restriction, and the consequences this has on pause/ the TMMBR 0 restriction, and the consequences this has on pause/
skipping to change at page 57, line 30 skipping to change at page 57, line 40
o Added SDP rules on how to handle unknown pause attribute values. o Added SDP rules on how to handle unknown pause attribute values.
o Clarified how to handle an SDP with both "ccm pause" and "ccm o Clarified how to handle an SDP with both "ccm pause" and "ccm
tmmbr". tmmbr".
o Changed from "Translator" to "Relay" in examples, to make it o Changed from "Translator" to "Relay" in examples, to make it
clearer in relation to the updated topologies draft. clearer in relation to the updated topologies draft.
o Editorial improvements. o Editorial improvements.
A.4. Modifications Between Version -05 and -06 A.5. Modifications Between Version -05 and -06
o Clarified in Message Details section for PAUSED that o Clarified in Message Details section for PAUSED that
retransmission of the message can be used to increase the retransmission of the message can be used to increase the
probability that the message reaches the receiver in a timely probability that the message reaches the receiver in a timely
fashion, and also added text that says the number of repetitions fashion, and also added text that says the number of repetitions
can be tuned to observed loss rate and the desired loss can be tuned to observed loss rate and the desired loss
probability. Also removed Editor's notes on potential ACK for probability. Also removed Editor's notes on potential ACK for
unsolicited PAUSED, since the issue is solved by the above. unsolicited PAUSED, since the issue is solved by the above.
o In the same section as above, added that PAUSED may be included in o In the same section as above, added that PAUSED may be included in
skipping to change at page 58, line 10 skipping to change at page 58, line 19
targeted stream are received. targeted stream are received.
o Changed simulcast reference, since that draft was moved from o Changed simulcast reference, since that draft was moved from
AVTCORE to MMUSIC and made WG draft. AVTCORE to MMUSIC and made WG draft.
o Changed End Point to Endpoint to reflect change in RTP Grouping o Changed End Point to Endpoint to reflect change in RTP Grouping
Taxonomy draft. Taxonomy draft.
o Editorial improvements. o Editorial improvements.
A.5. Modifications Between Version -04 and -05 A.6. Modifications Between Version -04 and -05
o Added text in sections 4.1, 4.6, 6.4 and 8.5 on retransmission and 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 timing of unsolicited PAUSED, to improve the message timeliness
and probability of reception. and probability of reception.
A.6. Modifications Between Version -03 and -04 A.7. Modifications Between Version -03 and -04
o Change of Copyright boilerplate o Change of Copyright boilerplate
A.7. Modifications Between Version -02 and -03 A.8. 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 59, line 5 skipping to change at page 59, line 11
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.8. Modifications Between Version -01 and -02 A.9. 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.9. Modifications Between Version -00 and -01 A.10. 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. 19 change blocks. 
37 lines changed or deleted 46 lines changed or added

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