draft-ietf-mmusic-media-loopback-09.txt   draft-ietf-mmusic-media-loopback-10.txt 
Internet Draft K. Hedayat Internet Draft K. Hedayat
Expires: January 28, 2009 Brix Networks Expires: August 18, 2009 Brix Networks
N. Venna N. Venna
Brix Networks Brix Networks
P. Jones P. Jones
Cisco Systems, Inc. Cisco Systems, Inc.
A. Roychowdhury A. Roychowdhury
Hughes Systique Corp. Hughes Systique Corp.
C. SivaChelvan C. SivaChelvan
Cisco Systems, Inc. Cisco Systems, Inc.
N. Stratton N. Stratton
BlinkMind, Inc. BlinkMind, Inc.
July 28, 2008 February 18, 2009
An Extension to the Session Description Protocol (SDP) for Media An Extension to the Session Description Protocol (SDP) for Media
Loopback Loopback
draft-ietf-mmusic-media-loopback-09 draft-ietf-mmusic-media-loopback-10
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with
applicable patent or other IPR claims of which he or she is aware the provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. 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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 18, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008).
Copyright (c) 2009 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
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.
Abstract Abstract
The wide deployment of Voice over IP (VoIP), Real-time Text and The wide deployment of Voice over IP (VoIP), Real-time Text and
Video over IP services has introduced new challenges in managing Video over IP services has introduced new challenges in managing
and maintaining voice/real-time Text/video quality, reliability, and maintaining voice/real-time Text/video quality, reliability,
and overall performance. In particular, media delivery is an area and overall performance. In particular, media delivery is an area
that needs attention. One method of meeting these challenges is that needs attention. One method of meeting these challenges is
monitoring the media delivery performance by looping media back to monitoring the media delivery performance by looping media back to
the transmitter. This is typically referred to as "active the transmitter. This is typically referred to as "active
skipping to change at page 2, line 34 skipping to change at page 2, line 45
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
2. Terminology...................................................4 2. Terminology...................................................4
3. Offering Entity Behavior......................................4 3. Offering Entity Behavior......................................4
4. Answering Entity Behavior.....................................4 4. Answering Entity Behavior.....................................4
5. SDP Constructs Syntax.........................................4 5. SDP Constructs Syntax ......................................... 5
5.1 Loopback Type Attribute...................................4 5.1 Loopback Type Attribute ................................... 5
5.2 Loopback Mode Attribute...................................6 5.2 Loopback Mode Attribute...................................6
5.3 Generating the Offer for Loopback Session.................7 5.3 Generating the Offer for Loopback Session.................7
5.4 Generating the Answer for Loopback Session................8 5.4 Generating the Answer for Loopback Session
5.5 Offerer Processing of the Answer..........................9 5.5 Offerer Processing of the Answer ......................... 10
5.6 Modifying the Session....................................10 5.6 Modifying the Session....................................10
6. RTP Requirements.............................................10 6. RTP Requirements.............................................10
7. Payload formats for Packet loopback..........................10 7. Payload formats for Packet loopback .......................... 11
7.1 Encapsulated Payload format..............................11 7.1 Encapsulated Payload format..............................11
7.2 Direct loopback RTP payload format.......................13 7.2 Direct loopback RTP payload format.......................13
8. RTCP Requirements............................................14 8. RTCP Requirements ............................................ 15
9. Congestion Control...........................................15 9. Congestion Control...........................................15
10. Examples....................................................15 10. Examples....................................................15
10.1 Offer for specific media loopback type..................15 10.1 Offer for specific media loopback type..................15
10.2 Offer for choice of media loopback type.................16 10.2 Offer for choice of media loopback type.................16
10.3 Offer for choice of media loopback type with 10.3 Offer for choice of media loopback type with
rtp-start-loopback...........................................17 rtp-start-loopback...........................................17
10.4 Response to INVITE request rejecting loopback media.....18 10.4 Response to INVITE request rejecting loopback media.....18
10.5 Response to INVITE request rejecting loopback media with 10.5 Response to INVITE request rejecting loopback media with
rtp-start-loopback...........................................18 rtp-start-loopback ........................................... 19
11. Security Considerations.....................................19 11. Security Considerations ..................................... 20
12. Implementation Considerations...............................20 12. Implementation Considerations...............................20
13. IANA Considerations.........................................20 13. IANA Considerations.........................................20
13.1 SDP Attributes..........................................20 13.1 SDP Attributes..........................................20
13.2 MIME Types..............................................21 13.2 MIME Types..............................................21
14. Acknowledgements............................................30 14. Acknowledgements............................................30
15. Normative References........................................30 15. Normative References........................................30
1. Introduction 1. Introduction
The overall quality, reliability, and performance of VoIP, The overall quality, reliability, and performance of VoIP,
Real-time Text and Video over IP services rely on the performance Real-time Text and Video over IP services rely on the performance
and quality of the media path. In order to assure the quality of and quality of the media path. In order to assure the quality of
the delivered media there is a need to monitor the performance of the delivered media there is a need to monitor the performance of
the media transport. One method of monitoring and managing the the media transport. One method of monitoring and managing the
overall quality of VoIP, Real-time Text and Video over IP Services overall quality of VoIP, Real-time Text and Video over IP Services
is through monitoring the quality of the media in an active is through monitoring the quality of the media in an active
session. This type of "active monitoring" of services is a method session. This type of "active monitoring" of services is a method
of pro-actively managing the performance and quality of VoIP based
services. services.
The goal of active monitoring is to measure the media quality of a The goal of active monitoring is to measure the media quality of a
VoIP, Real-time Text or Video over IP session. A way to achieve VoIP, Real-time Text or Video over IP session. A way to achieve
this goal is to request an endpoint to loop media back to the other this goal is to request an endpoint to loop media back to the other
endpoint and to provide media statistics (e.g., RTCP and RTCP XR endpoint and to provide media statistics (e.g., RTCP and RTCP XR
information). Another method involves deployment of special information). Another method involves deployment of special
endpoints that always loop incoming media back for sessions. endpoints that always loop incoming media back for sessions.
Although the latter method has been used and is functional, it does Although the latter method has been used and is functional, it does
not scale to support large networks and introduces new network not scale to support large networks and introduces new network
skipping to change at page 5, line 7 skipping to change at page 5, line 17
Two new media attributes are defined: one indicates the type of Two new media attributes are defined: one indicates the type of
loopback and one indicates the mode of the loopback. loopback and one indicates the mode of the loopback.
5.1 Loopback Type Attribute 5.1 Loopback Type Attribute
The loopback type is a property media attribute with the following The loopback type is a property media attribute with the following
syntax: syntax:
a=loopback:<loopback-type> a=loopback:<loopback-type>
Following is the Augmented BNF [RFC4234] for loopback-type: Following is the Augmented BNF [RFC5234] for loopback-type:
loopback-type = loopback-type-choices | loopback-type-choice-3 loopback-type = loopback-type-choices | loopback-type-choice-3
loopback-choices = loopback-type-choice-1 | loopback-type-choice-2 loopback-choices = loopback-type-choice-1 | loopback-type-choice-2
| loopback-type-choice-1 1*space loopback-type-choice-2 | | loopback-type-choice-1 1*space loopback-type-choice-2 |
loopback-type-choice-2 1*space loopback-type-choice-1 loopback-type-choice-2 1*space loopback-type-choice-1
loopback-type-choice-1 = "rtp-pkt-loopback" loopback-type-choice-1 = "rtp-pkt-loopback"
loopback-type-choice-2 = "rtp-media-loopback" loopback-type-choice-2 = "rtp-media-loopback"
loopback-type-choice-3 = "rtp-start-loopback" loopback-type-choice-3 = "rtp-start-loopback"
The loopback type is used to indicate the type of loopback. The The loopback type is used to indicate the type of loopback. The
skipping to change at page 5, line 50 skipping to change at page 6, line 15
Loopback-source and loopback-mirror are loopback modes defined in Loopback-source and loopback-mirror are loopback modes defined in
section 5.2. One example of this scenario is the presence of an section 5.2. One example of this scenario is the presence of an
RTP relay in the path of the media. RTP relays exist in VoIP RTP relay in the path of the media. RTP relays exist in VoIP
networks for purpose of NAT and Firewall traversal. If an RTP networks for purpose of NAT and Firewall traversal. If an RTP
relay is present, the loopback-source's packets are dropped by the relay is present, the loopback-source's packets are dropped by the
RTP relay until the loopback-mirror has started transmitting media RTP relay until the loopback-mirror has started transmitting media
and the media state within the RTP relay is established. This and the media state within the RTP relay is established. This
loopback attribute is used to specify the media type for loopback attribute is used to specify the media type for
transmitting media packets by the loopback-mirror prior to the transmitting media packets by the loopback-mirror prior to the
loopback process for the purpose of setting media state within the loopback process for the purpose of setting media state within the
network. In the presence of this loopback attribute the loopback- network. In the presence of this loopback attribute the
mirror will transmit media, according to the description that loopback-mirror will transmit media, according to the description
contains this attribute, until it receives media from the loopback- that contains this attribute, until it receives media from the
source. The loopback-mirror MAY include this attribute in the loopback-source. The loopback-mirror MAY include this attribute in
answer if it is not present in the offer. This may be necessary if the answer if it is not present in the offer. This may be
the loopback-mirror is aware of NAT's, firewalls, or RTP relays on necessary if the loopback-mirror is aware of NAT's, firewalls, or
the path of the call. In this case the loopback-source MUST accept RTP relays on the path of the call. In this case the loopback-
media according to rtp-start-loopback attribute. After the first source MUST accept media according to rtp-start-loopback attribute.
media packet is received from the loopback-source, the loopback- After the first media packet is received from the loopback-source,
mirror MUST terminate the transmission of rtp-start-loopback media the loopback-mirror MUST terminate the transmission of
and MUST start looping back media as defined by the other loopback rtp-start-loopback media and MUST start looping back media as
attributes present in the offer. If an offer includes the defined by the other loopback attributes present in the offer. If
rtp-start-loopback attribute it MUST also include at least one an offer includes the rtp-start-loopback attribute it MUST also
other attribute as defined in this section. The loopback-source is include at least one other attribute as defined in this section.
able to filter rtp-start-loopback packets from other types of The loopback-source is able to filter rtp-start-loopback packets
loopback with the payload type of the packet. The media port number from other types of loopback with the payload type of the packet.
for rtp-start-loopback MUST be the same as the corresponding The media port number for rtp-start-loopback MUST be the same as
loopback attribute that will take over after the reception of first the corresponding loopback attribute that will take over after the
media packet from the offering entity. reception of first media packet from the offering entity.
It is recommended that an offering entity specifying media with It is recommended that an offering entity specifying media with
either rtp-pkt-loopback or rtp-media-loopback attribute also either rtp-pkt-loopback or rtp-media-loopback attribute also
specify the rtp-start-loopback attribute unless the offering entity specify the rtp-start-loopback attribute unless the offering entity
is certain that its media will not be blocked by a network entity is certain that its media will not be blocked by a network entity
as explained above. as explained above.
5.2 Loopback Mode Attribute 5.2 Loopback Mode Attribute
The loopback mode is a value media attribute that is used to The loopback mode is a value media attribute that is used to
skipping to change at page 6, line 45 skipping to change at page 7, line 12
The loopback-mode values are loopback-source and loopback-mirror. The loopback-mode values are loopback-source and loopback-mirror.
loopback-source: This attribute specifies that the sender is the loopback-source: This attribute specifies that the sender is the
media source and expects the receiver to act as a loopback-mirror. media source and expects the receiver to act as a loopback-mirror.
loopback-mirror: This attribute specifies that the receiver will loopback-mirror: This attribute specifies that the receiver will
mirror (echo) all received media back to the sender of the RTP mirror (echo) all received media back to the sender of the RTP
stream. No media is generated locally by the receiver for stream. No media is generated locally by the receiver for
transmission in the mirrored stream unless rtp-start-loopback is transmission in the mirrored stream unless rtp-start-loopback is
requested. requested by the loopback-source or included in the response by
loopback-mirror.
<fmt> is a media format description. The format descrption has the <fmt> is a media format description. The format descrption has the
semantics as defined in section 5.14 of RFC 4566[RFC4566]. When semantics as defined in section 5.14 of RFC 4566[RFC4566]. When
loopback-mode is specified as loopback-source, the media format loopback-mode is specified as loopback-source, the media format
corresponds to the RTP payload types the source is willing to send. corresponds to the RTP payload types the source is willing to send.
When loopback-mode is specified as loopback-mirror, the media When loopback-mode is specified as loopback-mirror, the media
format corresponds to the RTP payload types the mirror is willing format corresponds to the RTP payload types the mirror is willing
to receive. The payload types specified in m= line for a to receive. The payload types specified in m= line for a
loopback-source specify the payloads the source is willing to loopback-source specify the payloads the source is willing to
receive. Similarly, for the loopback-mirror these payload types receive. Similarly, for the loopback-mirror these payload types
specify the payloads it is willing to send. specify the payloads it is willing to send.
The loopback mode attribute does not apply to rtp-start-loopback The loopback mode attribute does not apply to rtp-start-loopback
attribute and MUST be ignored if received by the answering entity. attribute and MUST be ignored if received by the answering entity.
skipping to change at page 8, line 12 skipping to change at page 8, line 26
Example: m=audio 41352 RTP/AVP 112 Example: m=audio 41352 RTP/AVP 112
a=loopback:rtp-pkt-loopback a=loopback:rtp-pkt-loopback
a=loopback-source:0 8 a=loopback-source:0 8
a=rtpmap:112 encaprtp/8000 a=rtpmap:112 encaprtp/8000
Example: m=audio 41352 RTP/AVP 112 Example: m=audio 41352 RTP/AVP 112
a=loopback:rtp-pkt-loopback a=loopback:rtp-pkt-loopback
a=loopback-source:0 8 a=loopback-source:0 8
a=rtpmap:112 rtploopback/8000 a=rtpmap:112 rtploopback/8000
Note: NAT devices may change the actual port number that is used
for transmission and the expected receive port.
5.4 Generating the Answer for Loopback Session 5.4 Generating the Answer for Loopback Session
If an answerer wishes to accept the loopback request it MUST If an answerer wishes to accept the loopback request it MUST
include both the loopback mode and loopback type attribute in the include both the loopback mode and loopback type attribute in the
answer. If a stream is offered with loopback-source or answer. If a stream is offered with loopback-source or
loopback-mirror attributes, the corresponding stream MUST be loopback-mirror attributes, the corresponding stream MUST be
loopback-mirror or loopback-source respectively, provided that loopback-mirror or loopback-source respectively, provided that
answerer is capable of supporting the requested loopback-type. answerer is capable of supporting the requested loopback-type.
For example, if the offer contains: For example, if the offer contains:
skipping to change at page 9, line 44 skipping to change at page 10, line 11
An offered stream with loopback-source MAY be rejected if the An offered stream with loopback-source MAY be rejected if the
loopback-type is not specified, the specified loopback-type is not loopback-type is not specified, the specified loopback-type is not
supported, or the endpoint cannot honor the offer for any other supported, or the endpoint cannot honor the offer for any other
reason. The Loopback request may be rejected by setting the media reason. The Loopback request may be rejected by setting the media
port number to zero in the answer as per RFC 3264 [RFC3264]. port number to zero in the answer as per RFC 3264 [RFC3264].
5.5 Offerer Processing of the Answer 5.5 Offerer Processing of the Answer
The answer to a loopback-source MUST be loopback-mirror. The The answer to a loopback-source MUST be loopback-mirror. The
answer to a loopback-mirror MUST be loopback-source. The loopback- answer to a loopback-mirror MUST be loopback-source. The
mode line MUST contain at least one codec the answerer is willing loopback-mode line MUST contain at least one codec the answerer is
to send or receive depending on whether it is the loopback-source willing to send or receive depending on whether it is the loopback-
or the loopback-mirror. In addition, the "m=" line MUST contain at source or the loopback-mirror. In addition, the "m=" line MUST
least one codec that the answerer is willing to send or receive contain at least one codec that the answerer is willing to send or
depending on whether it is the loopback-mirror or the loopback- receive depending on whether it is the loopback-mirror or the
source. loopback-source.
If the answer does not contain a=loopback-mirror or If the answer does not contain a=loopback-mirror or
a=loopback-source or contains any other standard mode attributes, a=loopback-source or contains any other standard mode attributes,
it is assumed that the loopback extensions are not supported by the it is assumed that the loopback extensions are not supported by the
target UA. target UA.
5.6 Modifying the Session 5.6 Modifying the Session
At any point during the loopback session, either participant may At any point during the loopback session, either participant may
issue a new offer to modify the characteristics of the previous issue a new offer to modify the characteristics of the previous
session. In case of SIP this is defined in section 8 of RFC 3264 session. In case of SIP this is defined in section 8 of RFC 3264
skipping to change at page 30, line 43 skipping to change at page 31, line 18
[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.
[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.
[RFC4234] Crocker, P. Overell, "Augmented ABNF for Syntax [RFC5234] Crocker, P. Overell, "Augmented ABNF for Syntax
Specification: ABNF", RFC 4234, October 2005. Specification: ABNF", RFC 5234, October 2005.
[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.
[RFC2736] Handley, M., Perkins, C., "Guidelines for Writers of [RFC2736] Handley, M., Perkins, C., "Guidelines for Writers of
RTP Payload Format Specifications", RFC 2736, BCP RTP Payload Format Specifications", RFC 2736, BCP
0036, December 1999. 0036, December 1999.
[RFC3551] Schulzrinne, H., Casner, S., "RTP Profile for Audio [RFC3551] Schulzrinne, H., Casner, S., "RTP Profile for Audio
and Video Conferences with Minimial Control", STD 65, and Video Conferences with Minimial Control", STD 65,
skipping to change at page 32, line 32 skipping to change at page 33, line 4
Chelliah SivaChelvan Chelliah SivaChelvan
Cisco Systems, Inc. Cisco Systems, Inc.
2200 East President George Bush Turnpike 2200 East President George Bush Turnpike
Richardson, TX 75082 Richardson, TX 75082
US US
Phone: +1 972 813 5224 Phone: +1 972 813 5224
EMail: chelliah@cisco.com EMail: chelliah@cisco.com
URI: http://www.cisco.com/ URI: http://www.cisco.com/
Nathan Stratton Nathan Stratton
BlinkMind, Inc. BlinkMind, Inc.
2027 Briarchester Dr. 2027 Briarchester Dr.
Katy, TX 77450 Katy, TX 77450
Phone: +1 832 330 3810 Phone: +1 832 330 3810
EMail: nathan@robotics.net EMail: nathan@robotics.net
URI: http://www.robotics.net/ URI: http://www.robotics.net/
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 23 change blocks. 
55 lines changed or deleted 60 lines changed or added

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