--- 1/draft-ietf-mmusic-media-loopback-05.txt 2007-04-05 22:12:31.000000000 +0200 +++ 2/draft-ietf-mmusic-media-loopback-06.txt 2007-04-05 22:12:31.000000000 +0200 @@ -1,26 +1,23 @@ K. Hedayat Internet Draft Brix Networks - Expires: April 2007 P. Jones + Expires: October 2007 P. Jones Cisco Systems, Inc. A. Roychowdhury Hughes C. SivaChelvan Cisco Systems, Inc. N. Stratton - - August 2006 - An Extension to the Session Description Protocol (SDP) for Media Loopback - draft-ietf-mmusic-media-loopback-05 + draft-ietf-mmusic-media-loopback-06 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -33,21 +30,21 @@ 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 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice - Copyright (C) The Internet Society (2006). + Copyright (C) The IETF Trust (2007). 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 @@ -166,26 +163,27 @@ 5.1 Loopback Type Attribute The loopback type is a property media attribute with the following syntax: a=loopback: Following is the Augmented BNF [RFC2234] for loopback-type: - loopback-type = loopback-type-1 | loopback-type-2 - loopback-type-1 = loopback-type-choice-1 [space - loopback-type-choice-1] - loopback-type-choice-1 = "rtp-pkt-loopback" | "rtp-media-loopback" - loopback-type-2 = loopback-type-choice-2 - loopback-type-choice-2 = "rtp-start-loopback" + 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 loopback-type values are rtp-pkt-loopback, rtp-media-loopback, and rtp-start-loopback. rtp-pkt-loopback: In this mode, the RTP packets are looped back to the sender at a point before the encoder/decoder function in the receive direction to a point after the encoder/decoder function in the send direction. This effectively re-encapsulates the RTP payload with the RTP/UDP/IP overheads appropriate for sending it in @@ -256,26 +254,27 @@ 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. is a media format description. The format descrption has the semantics as defined in section 5.14 of RFC 4566 [RFC2234]. 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. + 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. 5.3 Generating the Offer for Loopback Session If an offerer wishes to make a loopback request, it MUST include both the loopback-type and loopback-mode attribute in a valid SDP offer: @@ -556,45 +555,45 @@ The following is an example SDP fragment for encapsulated RTP. m=audio 41352 RTP/AVP 112 a=rtpmap:112 encaprtp/8000 7.2 Direct loopback RTP payload format The direct loopback RTP payload format can be used in scenarios where the 16 byte overhead of the encapsulated payload format is - significant. It MUST not be used in cases where the MTU on the - loopback path is less than the MTU on the transmit path. When - using this payload format, the receiver MUST loop back each - received packet in a separate RTP packet. + significant. This payload format MUST not be used in cases where + the MTU on the loopback path is less than the MTU on the transmit + path. When using this payload format, the receiver MUST loop back + each received packet in a separate RTP packet. 7.2.1 Usage of RTP Header fields Payload Type (PT): The assignment of an RTP payload type for this packet format is outside the scope of this document; it is either specified by the RTP profile under which this payload format is used or more likely signaled dynamically out-of-band (e.g., using SDP; section 7.3 defines the name binding). Marker (M) bit: Set to the value in the received packet. Extension (X) bit: Defined by the RTP Profile used. Sequence Number: The RTP sequence number SHOULD be generated by the loopback-mirror in the usual manner with a constant random offset. Timestamp: The RTP timestamp denotes the sampling instant for when - the loopback-mirror is transmitting this packet to the loopback- - source. The RTP timestamp MUST based on the same clock used by the - loopback-source. The initial value of the timestamp SHOULD be - random for security reasons (see Section 5.1 of RFC 3550 + the loopback-mirror is transmitting this packet to the + loopback-source. The RTP timestamp MUST based on the same clock + used by the loopback-source. The initial value of the timestamp + SHOULD be random for security reasons (see Section 5.1 of RFC 3550 [RFC3550]). SSRC: set as described in RFC 3550 [RFC3550]. CC and CSRC fields are used as described in RFC 3550 [RFC3550]. 7.2.2 RTP Payload Structure This payload format does not define any payload specific headers. The loopback-mirror simply copies the payload data from the payload @@ -641,199 +640,199 @@ This section provides examples for media descriptions using SDP for different scenarios. The examples are given for SIP-based transactions and are abbreviated and do not show the complete signaling for convenience. 10.1 Offer for specific media loopback type A client sends an INVITE request with SDP which looks like: v=0 - o=user1 2890844526 2890842807 IN IP4 126.16.64.4 + o=user1 2890844526 2890842807 IN IP4 192.0.2.11 s=Example i=An example session e=user@example.com - c=IN IP4 192.168.0.12/127 + c=IN IP4 192.0.2.12/127 t=0 0 m=audio 49170 RTP/AVP 0 a=loopback:rtp-media-loopback a=loopback-source:0 The client is offering to source the media and expects the server to mirror the RTP stream per rtp-media-loopback loopback type. A server sends a response with SDP which looks like: v=0 - o=user1 2890844526 2890842807 IN IP4 126.16.64.4 + o=user1 2890844526 2890842807 IN IP4 192.0.2.11 s=Example i=An example session e=user@example.com - c=IN IP4 192.168.0.12/127 + c=IN IP4 192.0.2.12/127 t=0 0 m=audio 49170 RTP/AVP 0 a=loopback:rtp-media-loopback a=loopback-mirror:0 The server is accepting to mirror the media from the client at the media level. 10.2 Offer for choice of media loopback type A client sends an INVITE request with SDP which looks like: v=0 - o=user1 2890844526 2890842807 IN IP4 126.16.64.4 + o=user1 2890844526 2890842807 IN IP4 192.0.2.11 s=Example i=An example session e=user@example.com - c=IN IP4 192.168.0.12/127 + c=IN IP4 192.0.2.12/127 t=0 0 m=audio 49170 RTP/AVP 0 112 113 a=loopback:rtp-media-loopback rtp-pkt-loopback a=loopback-source:0 a=rtpmap:112 encaprtp/8000 a=rtpmap:113 rtploopback/8000 The client is offering to source the media and expects the server to mirror the RTP stream at either the media or rtp level. A server sends a response with SDP which looks like: v=0 - o=user1 2890844526 2890842807 IN IP4 126.16.64.4 + o=user1 2890844526 2890842807 IN IP4 192.0.2.11 s=Example i=An example session e=user@example.com - c=IN IP4 192.168.0.12/127 + c=IN IP4 192.0.2.12/127 t=0 0 m=audio 49170 RTP/AVP 112 a=loopback:rtp-pkt-loopback a=loopback-mirror:0 a=rtpmap:112 encaprtp/8000 The server is accepting to mirror the media from the client at the packet level using the encapsulated RTP payload format. 10.3 Offer for choice of media loopback type with rtp-start-loopback A client sends an INVITE request with SDP which looks like: v=0 - o=user1 2890844526 2890842807 IN IP4 126.16.64.4 + o=user1 2890844526 2890842807 IN IP4 192.0.2.11 s=Example i=An example session e=user@example.com - c=IN IP4 192.168.0.12/127 + c=IN IP4 192.0.2.12/127 t=0 0 m=audio 49170 RTP/AVP 0 112 113 a=loopback:rtp-media-loopback rtp-pkt-loopback a=loopback-source:0 a=rtpmap:112 encaprtp/8000 a=rtpmap:113 rtploopback/8000 m=audio 49170 RTP/AVP 100 a=loopback:rtp-start-loopback The client is offering to source the media and expects the server to mirror the RTP stream at either the media or rtp level. The client also expects the server to source media until it receives packets from the server per media described with the rtp-start-loopback attribute. A server sends a response with SDP which looks like: v=0 - o=user1 2890844526 2890842807 IN IP4 126.16.64.4 + o=user1 2890844526 2890842807 IN IP4 192.0.2.11 s=Example i=An example session e=user@example.com - c=IN IP4 192.168.0.12/127 + c=IN IP4 192.0.2.12/127 t=0 0 m=audio 49170 RTP/AVP 113 a=loopback:rtp-pkt-loopback a=loopback-mirror:0 a=rtpmap:113 rtploopback/8000 m=audio 49170 RTP/AVP 100 a=rtpmap:100 pcmu/8000 a=loopback:rtp-start-loopback The server is accepting to mirror the media from the client at the packet level using the direct loopback RTP payload format. The server is also accepting to source media until it receives media packets from the client. 10.4 Response to INVITE request rejecting loopback media A client sends an INVITE request with SDP which looks like: v=0 - o=user1 2890844526 2890842807 IN IP4 126.16.64.4 + o=user1 2890844526 2890842807 IN IP4 192.0.2.11 s=Example i=An example session e=user@example.com - c=IN IP4 192.168.0.12/127 + c=IN IP4 192.0.2.12/127 t=0 0 m=audio 49170 RTP/AVP 0 a=loopback:rtp-media-loopback a=loopback-source:0 The client is offering to source the media and expects the server to mirror the RTP stream at the media level. A server sends a response with SDP which looks like: v=0 - o=user1 2890844526 2890842807 IN IP4 126.16.64.4 + o=user1 2890844526 2890842807 IN IP4 192.0.2.11 s=Example i=An example session e=user@example.com - c=IN IP4 192.168.0.12/127 + c=IN IP4 192.0.2.12/127 t=0 0 m=audio 0 RTP/AVP 0 a=loopback:rtp-media-loopback a=loopback-mirror:0 NOTE: Loopback request may be rejected by either not including the loopback mode attribute (for backward compatibility) or setting the media port number to zero, or both, in the response. 10.5 Response to INVITE request rejecting loopback media with rtp-start-loopback A client sends an INVITE request with SDP which looks like: v=0 - o=user1 2890844526 2890842807 IN IP4 126.16.64.4 + o=user1 2890844526 2890842807 IN IP4 192.0.2.11 s=Example i=An example session e=user@example.com - c=IN IP4 192.168.0.12/127 + c=IN IP4 192.0.2.12/127 t=0 0 m=audio 49170 RTP/AVP 0 a=loopback:rtp-media-loopback a=loopback-source:0 m=audio 49170 RTP/AVP 100 a=loopback:rtp-start-loopback The client is offering to source the media and expects the server to mirror the RTP stream at the media level. The client also expects the server to source media until it receives packets from the server per media described with the rtp-start-loopback attribute. A server sends a response with SDP which looks like: v=0 - o=user1 2890844526 2890842807 IN IP4 126.16.64.4 + o=user1 2890844526 2890842807 IN IP4 192.0.2.11 s=Example i=An example session e=user@example.com - c=IN IP4 192.168.0.12/127 + c=IN IP4 192.0.2.12/127 t=0 0 m=audio 0 RTP/AVP 0 a=loopback:rtp-media-loopback a=loopback-mirror:0 m=audio 0 RTP/AVP 0 a=loopback:rtp-start-loopback NOTE: Loopback request may be rejected by either not including the loopback mode attribute (for backward compatibility) or setting the media port number to zero, or both, in the response. @@ -962,33 +961,31 @@ 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. - Disclaimer of Validity - - 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 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. - Copyright Notice - Copyright (C) The Internet Society (2006). + Copyright (C) The IETF Trust (2007). 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. + Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.