draft-ietf-mmusic-media-loopback-21.txt   draft-ietf-mmusic-media-loopback-22.txt 
MMUSIC Working Group H. Kaplan (ed.) MMUSIC Working Group H. Kaplan (ed.)
Internet-Draft Acme Packet Internet-Draft Acme Packet
Intended status: Proposed Standard K. Hedayat Intended status: Proposed Standard K. Hedayat
Expires: February 6, 2013 EXFO Expires: February 7, 2013 EXFO
N. Venna N. Venna
Saperix Saperix
P. Jones P. Jones
Cisco Systems, Inc. Cisco Systems, Inc.
N. Stratton N. Stratton
BlinkMind, Inc. BlinkMind, Inc.
August 6, 2012 August 7, 2012
An Extension to the Session Description Protocol (SDP) An Extension to the Session Description Protocol (SDP)
and Real-time Transport Protocol (RTP) for Media Loopback and Real-time Transport Protocol (RTP) for Media Loopback
draft-ietf-mmusic-media-loopback-21 draft-ietf-mmusic-media-loopback-22
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
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), its areas, and its working groups. Note that
working documents as Internet-Drafts. The list of current other groups may also distribute working documents as Internet-
Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress".
This Internet-Draft will expire on February 6, 2013 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 7, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s)
controlling the copyright in such materials, this document may not
be modified outside the IETF Standards Process, and derivative
works of it may not be created outside the IETF Standards Process,
except to format it for publication as an RFC or to translate it
into languages other than English.
Abstract Abstract
The wide deployment of Voice over IP (VoIP), Text and Video over IP The wide deployment of Voice over IP (VoIP), Text and Video over IP
services has introduced new challenges in managing and maintaining services has introduced new challenges in managing and maintaining
real-time voice/text/video quality, reliability, and overall real-time voice/text/video quality, reliability, and overall
performance. In particular, media delivery is an area that needs performance. In particular, media delivery is an area that needs
attention. One method of meeting these challenges is monitoring attention. One method of meeting these challenges is monitoring
the media delivery performance by looping media back to the the media delivery performance by looping media back to the
transmitter. This is typically referred to as "active monitoring" transmitter. This is typically referred to as "active monitoring"
of services. Media loopback is especially popular in ensuring the of services. Media loopback is especially popular in ensuring the
skipping to change at page 2, line 33 skipping to change at page 2, line 50
attributes, which enable establishment of media sessions where the attributes, which enable establishment of media sessions where the
media is looped back to the transmitter. Such media sessions will media is looped back to the transmitter. Such media sessions will
serve as monitoring and troubleshooting tools by providing the serve as monitoring and troubleshooting tools by providing the
means for measurement of more advanced VoIP, Real-time Text and means for measurement of more advanced VoIP, Real-time Text and
Video over IP performance metrics. Video over IP performance metrics.
Table of Contents Table of Contents
1. Introduction..................................................3 1. Introduction..................................................3
1.1 Use Cases Supported.......................................4 1.1 Use Cases Supported.......................................4
2. Terminology...................................................5 2. Terminology...................................................6
3. Overview of Operation.........................................6 3. Overview of Operation.........................................6
3.1 SDP Offerer Behavior......................................6 3.1 SDP Offerer Behavior......................................6
3.2 SDP Answerer Behavior.....................................6 3.2 SDP Answerer Behavior.....................................7
4. New SDP Attributes............................................7 4. New SDP Attributes............................................7
4.1 Loopback Type Attribute...................................7 4.1 Loopback Type Attribute...................................7
4.2 Loopback Role Attributes: loopback-source and loopback- 4.2 Loopback Role Attributes: loopback-source and loopback-
mirror........................................................8 mirror........................................................8
5. Rules for Generating the SDP offer/answer.....................9 5. Rules for Generating the SDP offer/answer.....................9
5.1 Generating the SDP Offer for Loopback Session.............9 5.1 Generating the SDP Offer for Loopback Session.............9
5.2 Generating the SDP Answer for Loopback Session...........10 5.2 Generating the SDP Answer for Loopback Session...........10
5.3 Offerer Processing of the SDP Answer.....................12 5.3 Offerer Processing of the SDP Answer.....................12
5.4 Modifying the Session....................................12 5.4 Modifying the Session....................................12
5.5 Establishing Sessions Between Entities Behind NAT........12 5.5 Establishing Sessions Between Entities Behind NAT........12
6. RTP Requirements.............................................12 6. RTP Requirements.............................................13
7. Payload formats for Packet loopback..........................13 7. Payload formats for Packet loopback..........................13
7.1 Encapsulated Payload format..............................13 7.1 Encapsulated Payload format..............................14
7.2 Direct loopback RTP payload format.......................16 7.2 Direct loopback RTP payload format.......................16
8. SRTP Behavior................................................17 8. SRTP Behavior................................................17
9. RTCP Requirements............................................17 9. RTCP Requirements............................................17
10. Congestion Control..........................................18 10. Congestion Control..........................................18
11. Examples....................................................18 11. Examples....................................................18
11.1 Offer for specific media loopback type..................18 11.1 Offer for specific media loopback type..................18
11.2 Offer for choice of media loopback type.................19 11.2 Offer for choice of media loopback type.................19
11.3 Answerer rejecting loopback media.......................20 11.3 Answerer rejecting loopback media.......................20
12. Security Considerations.....................................20 12. Security Considerations.....................................20
13. Implementation Considerations...............................21 13. Implementation Considerations...............................21
14. IANA Considerations.........................................22 14. IANA Considerations.........................................22
skipping to change at page 5, line 44 skipping to change at page 6, line 16
reencoding format. reencoding format.
This usage allows trouble-shooting at the codec level. The This usage allows trouble-shooting at the codec level. The
capability for path statistics is limited to what is available from capability for path statistics is limited to what is available from
RTCP reports. RTCP reports.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119. this document are to be interpreted as described in RFC 2119
[RFC2119].
SDP: Session Description Protocol, as defined in [RFC4566]. This SDP: Session Description Protocol, as defined in [RFC4566]. This
document assumes the SDP offer/answer model is followed, per document assumes the SDP offer/answer model is followed, per
[RFC3264], but does not assume any specific signaling protocol for [RFC3264], but does not assume any specific signaling protocol for
carrying the SDP. carrying the SDP.
The following terms are borrowed from [RFC3264] definitions: offer, The following terms are borrowed from [RFC3264] definitions: offer,
offerer, answer, answerer, and agent. offerer, answer, answerer, and agent.
3. Overview of Operation 3. Overview of Operation
skipping to change at page 18, line 15 skipping to change at page 18, line 21
4.1, 4.2, 4.6, and 4.7 of RFC 3611 [RFC3611]. The offerer and the 4.1, 4.2, 4.6, and 4.7 of RFC 3611 [RFC3611]. The offerer and the
answerer MAY support other RTCP-XR reporting blocks as defined by answerer MAY support other RTCP-XR reporting blocks as defined by
RFC 3611 [RFC3611]. RFC 3611 [RFC3611].
10. Congestion Control 10. Congestion Control
All the participants in a media-level loopback session SHOULD All the participants in a media-level loopback session SHOULD
implement congestion control mechanisms as defined by the RTP implement congestion control mechanisms as defined by the RTP
profile under which the loopback mechanism is implemented. For profile under which the loopback mechanism is implemented. For
audio video profiles, implementations SHOULD conform to the audio video profiles, implementations SHOULD conform to the
mechanism defined in Section 2 of RFC 3551. mechanism defined in Section 2 of RFC 3551 [RFC3551].
For packet-level loopback types, the loopback source SHOULD For packet-level loopback types, the loopback source SHOULD
implement congestion control. The mirror will simply reflect back implement congestion control. The mirror will simply reflect back
the RTP packets it receives (either in encapsulated or direct the RTP packets it receives (either in encapsulated or direct
modes), therefore the source needs to control the congestion of modes), therefore the source needs to control the congestion of
both forward and reverse paths by reducing its sending rate to the both forward and reverse paths by reducing its sending rate to the
mirror. This keeps the loopback mirror implementation simpler, and mirror. This keeps the loopback mirror implementation simpler, and
provides more flexibility for the source performing a loopback provides more flexibility for the source performing a loopback
test. test.
skipping to change at page 31, line 18 skipping to change at page 31, line 24
the document: Kaynam Hedayat, Nagarjuna Venna, Paul E. Jones, Arjun the document: Kaynam Hedayat, Nagarjuna Venna, Paul E. Jones, Arjun
Roychowdhury, Chelliah SivaChelvan, and Nathan Stratton. The Roychowdhury, Chelliah SivaChelvan, and Nathan Stratton. The
editor has made fairly insignificant changes in the end. Also, editor has made fairly insignificant changes in the end. Also,
we'd like to thank Magnus Westerlund, Miguel Garcia, Muthu Arul we'd like to thank Magnus Westerlund, Miguel Garcia, Muthu Arul
Mozhi Perumal, Jeff Bernstein, Paul Kyzivat, Dave Oran, Flemming Mozhi Perumal, Jeff Bernstein, Paul Kyzivat, Dave Oran, Flemming
Andreasen, Gunnar Hellstrom, Emil Ivov and Dan Wing for their Andreasen, Gunnar Hellstrom, Emil Ivov and Dan Wing for their
feedback, comments and suggestions. feedback, comments and suggestions.
16. Normative References 16. Normative References
[RFC2119] Bradner, S.,"Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer
Model with the Session Description Protocol (SDP)", Model with the Session Description Protocol (SDP)",
RFC 3264, June 2002. RFC 3264, June 2002.
[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
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H., Casner, S., "RTP Profile for Audio
and Video Conferences with Minimial Control", STD 65,
RFC 3551, July 2003.
[RFC3611] Almeroth, K., Caceres, R., Clark, A., Cole, R., [RFC3611] Almeroth, K., Caceres, R., Clark, A., Cole, R.,
Duffield, N., Friedman, T., Hedayat, K., Sarac, K. Duffield, N., Friedman, T., Hedayat, K., Sarac, K.
and M. Westerlund, "RTP Control Protocol Extended and M. Westerlund, "RTP Control Protocol Extended
Reports (RTCP XR)", RFC 3611, November 2003. Reports (RTCP XR)", RFC 3611, November 2003.
[RFC5234] Crocker, P. Overell, "Augmented ABNF for Syntax [RFC3711] Baugher, M., et al, "The Secure Real-time Transport
Specification: ABNF", RFC 5234, October 2005. Protocol (SRTP)", RFC 3711, March 2004.
[RFC2119] Bradner, S.,"Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2736] Handley, M., Perkins, C., "Guidelines for Writers of
RTP Payload Format Specifications", RFC 2736, BCP
0036, December 1999.
[RFC3551] Schulzrinne, H., Casner, S., "RTP Profile for Audio
and Video Conferences with Minimial Control", STD 65,
RFC 3551, July 2003.
[RFC4566] Handley, M., Jacobson, V., Perkins, C., "SDP: Session [RFC4566] Handley, M., Jacobson, V., Perkins, C., "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol
Formats", RFC 4855, February 2007. (RTCP)", RFC 4961, July 2007.
[RFC5234] Crocker, P. Overell, "Augmented ABNF for Syntax
Specification: ABNF", RFC 5234, October 2005.
17. Informative References 17. Informative References
[RFC5245] Rosenberg, J., "Interactive Connectivity [RFC5245] Rosenberg, J., "Interactive Connectivity
Establishment (ICE): A Protocol for Network Address Establishment (ICE): A Protocol for Network Address
Translator (NAT) Traversal for Offer/Answer Translator (NAT) Traversal for Offer/Answer
Protocols", RFC 5245, April 2010. Protocols", RFC 5245, April 2010.
[RFC6263] Marjou, X., Sollaud, A., "Application Mechanism for [RFC6263] Marjou, X., Sollaud, A., "Application Mechanism for
Keeping Alive the NAT Mappings Associated with RTP / Keeping Alive the NAT Mappings Associated with RTP /
 End of changes. 21 change blocks. 
33 lines changed or deleted 50 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/