draft-ietf-xrblock-rtcp-xr-loss-conceal-09.txt   draft-ietf-xrblock-rtcp-xr-loss-conceal-10.txt 
Audio/Video Transport Working Group A. Clark Audio/Video Transport Working Group A. Clark
Internet-Draft Telchemy Internet-Draft Telchemy
Intended status: Standards Track G. Zorn, Ed. Intended status: Standards Track G. Zorn
Expires: July 10, 2014 Network Zen Expires: September 18, 2014 Network Zen
C. Bi C. Bi
STTRI STTRI
Q. Wu, Ed. Q. Wu, Ed.
Huawei Huawei
January 6, 2014 March 17, 2014
RTCP XR Report Block for Concealment metrics Reporting on Audio RTCP XR Report Block for Concealment metrics Reporting on Audio
Applications Applications
draft-ietf-xrblock-rtcp-xr-loss-conceal-09.txt draft-ietf-xrblock-rtcp-xr-loss-conceal-10.txt
Abstract Abstract
This document defines two RTCP XR Report Blocks that allows the This document defines two RTCP XR Report Blocks that allows the
reporting of concealment metrics for audio applications of RTP. reporting of concealment metrics for audio applications of RTP.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 July 10, 2014. This Internet-Draft will expire on September 18, 2014.
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 7, line 43 skipping to change at page 7, line 43
0 = silence insertion 0 = silence insertion
1 = simple replay, no attenuation 1 = simple replay, no attenuation
2 = simple replay, with attenuation 2 = simple replay, with attenuation
3 = enhancement 3 = enhancement
Other values reserved Other values reserved
Note that the enhancement method (plc =3 )for packet loss Note that the enhancement method (plc =3 ) for packet loss
concealment offers an improved audio quality and or a better concealment offers an improved audio quality and a better
robustness against packet losses [G.711] and is equivalent to robustness against packet losses [G.711] and is equivalent to
enhanced in section 4.7.1 of [RFC3611], enhanced in section 4.7.6 of [RFC3611].
Reserved (resv): 4 bits Reserved (resv): 4 bits
These bits are reserved. They MUST be set to zero by senders and These bits are reserved. They MUST be set to zero by senders and
ignored by receivers (See [RFC6709] section 4.2). ignored by receivers (See [RFC6709] section 4.2).
block length: 16 bits block length: 16 bits
The length of this report block in 32-bit words, minus one. For The length of this report block in 32-bit words, minus one. For
the Loss Concealment Block, the block length is equal to 5. the Loss Concealment Block, the block length is equal to 5.
skipping to change at page 13, line 14 skipping to change at page 13, line 14
0 = silence insertion 0 = silence insertion
1 = simple replay, no attenuation 1 = simple replay, no attenuation
2 = simple replay, with attenuation 2 = simple replay, with attenuation
3 = enhancement 3 = enhancement
Other values reserved Other values reserved
Note that the enhancement method (plc =3) for packet loss Note that the enhancement method (plc =3 ) for packet loss
concealment offers an improved audio quality and or a better concealment offers an improved audio quality and a better
robustness against packet losses [G.711] and is equivalent to robustness against packet losses [G.711] and is equivalent to
enhanced in section 4.7.1 of [RFC3611], enhanced in section 4.7.6 of [RFC3611].
Reserved (resv): 4 bits Reserved (resv): 4 bits
These bits are reserved. They MUST be set to zero by senders and These bits are reserved. They MUST be set to zero by senders and
ignored by receivers (See [RFC6709] section 4.2). ignored by receivers (See [RFC6709] section 4.2).
Block Length: 16 bits Block Length: 16 bits
The length of this report block in 32-bit words, minus one. For The length of this report block in 32-bit words, minus one. For
the Concealment Seconds Block, the block length is equal to 4. the Concealment Seconds Block, the block length is equal to 4.
skipping to change at page 14, line 19 skipping to change at page 14, line 19
Concealed Seconds: 32 bits Concealed Seconds: 32 bits
A count of the number of Concealed Seconds that have occurred. A count of the number of Concealed Seconds that have occurred.
A Concealed Second is defined as a continuous period of one second A Concealed Second is defined as a continuous period of one second
during which any frame loss or discard due to late arrival has during which any frame loss or discard due to late arrival has
occurred. occurred.
Equivalently, a concealed second is one in which some Loss-type Equivalently, a concealed second is one in which some Loss-type
concealment has occurred. Buffer adjustment-type concealment concealment has occurred. Buffer adjustment-type concealment
SHALL not cause Concealed Seconds to be incremented, with the SHOULD NOT cause Concealed Seconds to be incremented, with the
following exception. An implementation MAY cause Concealed following exception. An implementation MAY cause Concealed
Seconds to be incremented for 'emergency' buffer adjustments made Seconds to be incremented for 'emergency' buffer adjustments made
during talkspurts. during talkspurts.
Loss-type concealment is reactive insertion or deletion of samples Loss-type concealment is reactive insertion or deletion of samples
in the audio playout stream due to effective frame loss at the in the audio playout stream due to effective frame loss at the
audio decoder. "Effective frame loss" is the event in which a audio decoder. "Effective frame loss" is the event in which a
frame of coded audio is simply not present at the audio decoder frame of coded audio is simply not present at the audio decoder
when required. In this case, substitute audio samples are when required. In this case, substitute audio samples are
generally formed, at the decoder or elsewhere, to reduce audible generally formed, at the decoder or elsewhere, to reduce audible
skipping to change at page 17, line 18 skipping to change at page 17, line 18
general guidelines on IANA considerations for RTCP XR, refer to general guidelines on IANA considerations for RTCP XR, refer to
[RFC3611]. [RFC3611].
6.1. New RTCP XR Block Type values 6.1. New RTCP XR Block Type values
This document assigns two block type values in the IANA "RTP Control This document assigns two block type values in the IANA "RTP Control
Protocol Extended Reports (RTCP XR) Block Type Registry ": Protocol Extended Reports (RTCP XR) Block Type Registry ":
Name: LCB Name: LCB
Long Name: Loss Concealment Block Long Name: Loss Concealment Block
Value <LCB> Value <NLC>
Reference: Section 3.1 Reference: Section 3.1
Name: CSB Name: CSB
Long Name: Concealment Seconds Block Long Name: Concealment Seconds Block
Value <CSB> Value <NCS>
Reference: Section 4.1 Reference: Section 4.1
[Note to RFC Editor: please replace <NLC> and <NCS> with the RTCP XR [Note to RFC Editor: please replace <NLC> and <NCS> with the RTCP XR
block type assigned by IANA for this block.] block type assigned by IANA for this block.]
6.2. New RTCP XR SDP Parameters 6.2. New RTCP XR SDP Parameters
This document also registers two new parameters in the "RTP Control This document also registers two new parameters in the "RTP Control
Protocol Extended Reports (RTCP XR) Session Description Protocol Protocol Extended Reports (RTCP XR) Session Description Protocol
(SDP) Parameters Registry": (SDP) Parameters Registry":
o "loss-conceal" o "loss-conceal"
o "conc-sec" o "conc-sec"
6.3. Contact information for registrations 6.3. Contact information for registrations
The contact information for the registrations is: The contact information for the registrations is:
Qin Wu (sunseawq@huawei.com) RAI Area Directors
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012 rai-ads@tools.ietf.org
China
7. Security Considerations 7. Security Considerations
It is believed that this proposed RTCP XR report block introduces no It is believed that this proposed RTCP XR report block introduces no
new security considerations beyond those described in [RFC3611]. new security considerations beyond those described in [RFC3611].
This block does not provide per-packet statistics so the risk to This block does not provide per-packet statistics so the risk to
confidentiality documented in Section 7, paragraph 3 of [RFC3611] confidentiality documented in Section 7, paragraph 3 of [RFC3611]
does not apply. does not apply.
8. Contributors 8. Contributors
Geoff Hunt wrote the initial draft of this document. Geoff Hunt wrote the initial draft of this document.
9. Acknowledgements 9. Acknowledgements
The authors gratefully acknowledge reviews and feedback provided by The authors gratefully acknowledge reviews and feedback provided by
Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin Connor, Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin Connor,
Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert Higashi, Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert Higashi,
Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith Lantz, Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith Lantz,
Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho, Ravi Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho, Ravi
Raviraj, Albrecht Schwarz, Tom Taylor, and Hideaki Yamada. Raviraj, Albrecht Schwarz, Tom Taylor, Hideaki Yamada and Alissa
Cooper.
10. References 10. References
10.1. Normative References 10.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", March 1997. Requirement Levels", March 1997.
[RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time
Applications", RFC 3550, July 2003. Applications", RFC 3550, July 2003.
skipping to change at page 30, line 15 skipping to change at page 30, line 15
Authors' Addresses Authors' Addresses
Alan Clark Alan Clark
Telchemy Incorporated Telchemy Incorporated
2905 Premiere Parkway, Suite 280 2905 Premiere Parkway, Suite 280
Duluth, GA 30097 Duluth, GA 30097
USA USA
Email: alan.d.clark@telchemy.com Email: alan.d.clark@telchemy.com
Glen Zorn (editor) Glen Zorn
Network Zen Network Zen
77/440 Soi Phoomjit, Rama IV Road 77/440 Soi Phoomjit, Rama IV Road
Phra Khanong, Khlong Toie Phra Khanong, Khlong Toie
Bangkok 10110 Bangkok 10110
Thailand Thailand
Phone: +66 (0) 87 502 4274 Phone: +66 (0) 87 502 4274
Email: gwz@net-zen.net Email: gwz@net-zen.net
Claire Bi Claire Bi
 End of changes. 14 change blocks. 
20 lines changed or deleted 20 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/