--- 1/draft-ietf-mmusic-media-loopback-09.txt 2009-02-21 02:12:06.000000000 +0100 +++ 2/draft-ietf-mmusic-media-loopback-10.txt 2009-02-21 02:12:06.000000000 +0100 @@ -1,54 +1,64 @@ Internet Draft K. Hedayat - Expires: January 28, 2009 Brix Networks + Expires: August 18, 2009 Brix Networks N. Venna Brix Networks P. Jones Cisco Systems, Inc. A. Roychowdhury Hughes Systique Corp. C. SivaChelvan Cisco Systems, Inc. N. Stratton BlinkMind, Inc. - July 28, 2008 + February 18, 2009 An Extension to the Session Description Protocol (SDP) for Media Loopback - draft-ietf-mmusic-media-loopback-09 + draft-ietf-mmusic-media-loopback-10 Status of this Memo - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - 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. + This Internet-Draft is submitted to IETF in full conformance with + the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. + other groups may also distribute working documents as Internet- + Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." 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 http://www.ietf.org/shadow.html. + This Internet-Draft will expire on August 18, 2009. + 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 The wide deployment of Voice over IP (VoIP), Real-time Text and Video over IP services has introduced new challenges in managing and maintaining voice/real-time Text/video quality, reliability, and overall performance. In particular, media delivery is an area that needs attention. One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter. This is typically referred to as "active @@ -64,60 +74,59 @@ serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP, Real-time Text and Video Over IP performance metrics. Table of Contents 1. Introduction..................................................3 2. Terminology...................................................4 3. Offering Entity Behavior......................................4 4. Answering Entity Behavior.....................................4 - 5. SDP Constructs Syntax.........................................4 - 5.1 Loopback Type Attribute...................................4 + 5. SDP Constructs Syntax ......................................... 5 + 5.1 Loopback Type Attribute ................................... 5 5.2 Loopback Mode Attribute...................................6 5.3 Generating the Offer for Loopback Session.................7 - 5.4 Generating the Answer for Loopback Session................8 - 5.5 Offerer Processing of the Answer..........................9 + 5.4 Generating the Answer for Loopback Session + 5.5 Offerer Processing of the Answer ......................... 10 5.6 Modifying the Session....................................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.2 Direct loopback RTP payload format.......................13 - 8. RTCP Requirements............................................14 + 8. RTCP Requirements ............................................ 15 9. Congestion Control...........................................15 10. Examples....................................................15 10.1 Offer for specific media loopback type..................15 10.2 Offer for choice of media loopback type.................16 10.3 Offer for choice of media loopback type with rtp-start-loopback...........................................17 10.4 Response to INVITE request rejecting loopback media.....18 10.5 Response to INVITE request rejecting loopback media with - rtp-start-loopback...........................................18 - 11. Security Considerations.....................................19 + rtp-start-loopback ........................................... 19 + 11. Security Considerations ..................................... 20 12. Implementation Considerations...............................20 13. IANA Considerations.........................................20 13.1 SDP Attributes..........................................20 13.2 MIME Types..............................................21 14. Acknowledgements............................................30 15. Normative References........................................30 1. Introduction The overall quality, reliability, and performance of VoIP, 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 the delivered media there is a need to monitor the performance of the media transport. One method of monitoring and managing the overall quality of VoIP, Real-time Text and Video over IP Services is through monitoring the quality of the media in an active session. This type of "active monitoring" of services is a method - of pro-actively managing the performance and quality of VoIP based services. 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 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 information). Another method involves deployment of special endpoints that always loop incoming media back for sessions. Although the latter method has been used and is functional, it does not scale to support large networks and introduces new network @@ -168,21 +177,21 @@ Two new media attributes are defined: one indicates the type of loopback and one indicates the mode of the loopback. 5.1 Loopback Type Attribute The loopback type is a property media attribute with the following syntax: a=loopback: - 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-choices = loopback-type-choice-1 | 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-1 = "rtp-pkt-loopback" loopback-type-choice-2 = "rtp-media-loopback" loopback-type-choice-3 = "rtp-start-loopback" The loopback type is used to indicate the type of loopback. The @@ -211,39 +221,39 @@ Loopback-source and loopback-mirror are loopback modes defined in 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 networks for purpose of NAT and Firewall traversal. If an RTP relay is present, the loopback-source's packets are dropped by the RTP relay until the loopback-mirror has started transmitting media and the media state within the RTP relay is established. This loopback attribute is used to specify the media type for transmitting media packets by the loopback-mirror prior to the loopback process for the purpose of setting media state within the - network. In the presence of this loopback attribute the loopback- - mirror will transmit media, according to the description that - contains this attribute, until it receives media from the loopback- - source. The loopback-mirror MAY include this attribute in the - answer if it is not present in the offer. This may be necessary if - the loopback-mirror is aware of NAT's, firewalls, or RTP relays on - the path of the call. In this case the loopback-source MUST accept - media according to rtp-start-loopback attribute. After the first - media packet is received from the loopback-source, the loopback- - mirror MUST terminate the transmission of rtp-start-loopback media - and MUST start looping back media as defined by the other loopback - attributes present in the offer. If an offer includes the - rtp-start-loopback attribute it MUST also include at least one - other attribute as defined in this section. The loopback-source is - able to filter rtp-start-loopback packets from other types of - loopback with the payload type of the packet. The media port number - for rtp-start-loopback MUST be the same as the corresponding - loopback attribute that will take over after the reception of first - media packet from the offering entity. + network. In the presence of this loopback attribute the + loopback-mirror will transmit media, according to the description + that contains this attribute, until it receives media from the + loopback-source. The loopback-mirror MAY include this attribute in + the answer if it is not present in the offer. This may be + necessary if the loopback-mirror is aware of NAT's, firewalls, or + RTP relays on the path of the call. In this case the loopback- + source MUST accept media according to rtp-start-loopback attribute. + After the first media packet is received from the loopback-source, + the loopback-mirror MUST terminate the transmission of + rtp-start-loopback media and MUST start looping back media as + defined by the other loopback attributes present in the offer. If + an offer includes the rtp-start-loopback attribute it MUST also + include at least one other attribute as defined in this section. + The loopback-source is able to filter rtp-start-loopback packets + from other types of loopback with the payload type of the packet. + The media port number for rtp-start-loopback MUST be the same as + the corresponding loopback attribute that will take over after the + reception of first media packet from the offering entity. It is recommended that an offering entity specifying media with either rtp-pkt-loopback or rtp-media-loopback attribute also specify the rtp-start-loopback attribute unless the offering entity is certain that its media will not be blocked by a network entity as explained above. 5.2 Loopback Mode Attribute The loopback mode is a value media attribute that is used to @@ -255,27 +265,27 @@ The loopback-mode values are loopback-source and loopback-mirror. loopback-source: This attribute specifies that the sender is the media source and expects the receiver to act as a loopback-mirror. loopback-mirror: This attribute specifies that the receiver will mirror (echo) all received media back to the sender of the RTP stream. No media is generated locally by the receiver for transmission in the mirrored stream unless rtp-start-loopback is - requested. + requested by the loopback-source or included in the response by + loopback-mirror. is a media format description. The format descrption has the semantics as defined in section 5.14 of RFC 4566[RFC4566]. When loopback-mode is specified as loopback-source, the media format corresponds to the RTP payload types the source is willing to send. - When loopback-mode is specified as loopback-mirror, the media format corresponds to the RTP payload types the mirror is willing to receive. The payload types specified in m= line for a loopback-source specify the payloads the source is willing to receive. Similarly, for the loopback-mirror these payload types specify the payloads it is willing to send. The loopback mode attribute does not apply to rtp-start-loopback attribute and MUST be ignored if received by the answering entity. @@ -317,23 +327,20 @@ Example: m=audio 41352 RTP/AVP 112 a=loopback:rtp-pkt-loopback a=loopback-source:0 8 a=rtpmap:112 encaprtp/8000 Example: m=audio 41352 RTP/AVP 112 a=loopback:rtp-pkt-loopback a=loopback-source:0 8 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 If an answerer wishes to accept the loopback request it MUST include both the loopback mode and loopback type attribute in the answer. If a stream is offered with loopback-source or loopback-mirror attributes, the corresponding stream MUST be loopback-mirror or loopback-source respectively, provided that answerer is capable of supporting the requested loopback-type. For example, if the offer contains: @@ -395,27 +401,27 @@ An offered stream with loopback-source MAY be rejected if the loopback-type is not specified, the specified loopback-type is not supported, or the endpoint cannot honor the offer for any other reason. The Loopback request may be rejected by setting the media port number to zero in the answer as per RFC 3264 [RFC3264]. 5.5 Offerer Processing of the Answer The answer to a loopback-source MUST be loopback-mirror. The - answer to a loopback-mirror MUST be loopback-source. The loopback- - mode line MUST contain at least one codec the answerer is willing - to send or receive depending on whether it is the loopback-source - or the loopback-mirror. In addition, the "m=" line MUST contain at - least one codec that the answerer is willing to send or receive - depending on whether it is the loopback-mirror or the loopback- - source. + answer to a loopback-mirror MUST be loopback-source. The + loopback-mode line MUST contain at least one codec the answerer is + willing to send or receive depending on whether it is the loopback- + source or the loopback-mirror. In addition, the "m=" line MUST + contain at least one codec that the answerer is willing to send or + receive depending on whether it is the loopback-mirror or the + loopback-source. If the answer does not contain a=loopback-mirror or a=loopback-source or contains any other standard mode attributes, it is assumed that the loopback extensions are not supported by the target UA. 5.6 Modifying the Session At any point during the loopback session, either participant may 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 @@ -1361,22 +1369,22 @@ [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3611] Almeroth, K., Caceres, R., Clark, A., Cole, R., Duffield, N., Friedman, T., Hedayat, K., Sarac, K. and M. Westerlund, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003. - [RFC4234] Crocker, P. Overell, "Augmented ABNF for Syntax - Specification: ABNF", RFC 4234, October 2005. + [RFC5234] Crocker, P. Overell, "Augmented ABNF for Syntax + Specification: ABNF", RFC 5234, October 2005. [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, @@ -1433,65 +1439,18 @@ Chelliah SivaChelvan Cisco Systems, Inc. 2200 East President George Bush Turnpike Richardson, TX 75082 US Phone: +1 972 813 5224 EMail: chelliah@cisco.com URI: http://www.cisco.com/ - Nathan Stratton BlinkMind, Inc. 2027 Briarchester Dr. Katy, TX 77450 Phone: +1 832 330 3810 EMail: nathan@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).