--- 1/draft-ietf-mmusic-media-loopback-01.txt 2006-02-04 17:19:09.000000000 +0100 +++ 2/draft-ietf-mmusic-media-loopback-02.txt 2006-02-04 17:19:09.000000000 +0100 @@ -1,26 +1,26 @@ K. Hedayat Internet Draft Brix Networks - Expires: December 27,2005 P. Jones + Expires: May 11, 2006 P. Jones Cisco Systems, Inc. A. Roychowdhury Flextronics Software Systems C. SivaChelvan Cisco Systems, Inc. N. Stratton BroadVoice - June 27, 2005 + November 7, 2005 An Extension to the Session Description Protocol (SDP) for Media Loopback - draft-ietf-mmusic-media-loopback-01.txt + draft-ietf-mmusic-media-loopback-02 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 @@ -193,21 +193,21 @@ to the analog interface and after the decoder so that the RTP packets are subsequently re-encoded prior to transmission back to the sender. rtp-start-loopback: In certain scenarios it is possible that the media transmitted by the offering entity is blocked by a network element until the answering entity starts transmitting packets. 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 - offering entityÆs packets are dropped by the RTP relay until the + offering entity’s packets are dropped by the RTP relay until the answering entity 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 answering entity prior to the loopback process for the purpose of setting media state within the network. In the presence of this loopback attribute the answering entity will transmit media, according to the description that contains this attribute, until it receives media from the offering entity. After the first media packet is received from the offering entity, the answering entity MUST terminate the transmission of rtp-start-loopback media and @@ -240,23 +240,21 @@ 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 reciver for transmission in the mirrored stream. The loopback mode attribute does not apply to rtp-start-loopback - attribute and MAY be omitted. If the loopback mode attribute is - present with the rtp-start-loopback attribute it MUST be ignored by - the answering entity. + attribute and MUST be ignored if received by the answering entityt. 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: Example: a=loopback:rtp-media-loopback a=loopback-source @@ -305,26 +303,25 @@ a=loopback:rtp-media-loopback rtp-pkt-loopback a=loopback-source The answer that is capable of supporting the offer and chooses to loopback the media using the rtp-media-loopback type MUST contain: a=loopback:rtp-media-loopback a=loopback-mirror 5.4.1 Rejecting the Loopback Offer - 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 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, according to RFC 3264 [RFC3264], in the - answer. + 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. In addition, the "m=" line MUST contain at least one codec that the answerer is willing to both send and receive. If the answer does not contain a=loopback-mirror or a=loopback-source or contains any other standard mode attributes, @@ -343,53 +340,56 @@ An answering entitity that is compliant to this specification and accepting a media with rtp-pkt-loopback loopback-type MUST re-generate all of the RTP header fields as it does when transmitting other media. However, the answering entity MUST maintain the timing information of the received RTP packets when generating the RTP timestamp for the transmit packets. Maintaining the timing information of the RTP packets enables the offerer to re-construct the incoming media and take account for impairments from gaps in the media due to packet loss. Note that RTP Sequence - numbers are re-generated by the UAS and will not provide packet - loss information to the receiver of the loopback media. + numbers are re-generated by the answering entity and will not + provide packet loss information to the receiver of the loopback + media. An answering entity that is compliant to this specification and accepting a media with rtp-media-loopback loopback-type MUST transmit all received media back to the sender . The incoming media MUST be treated as if it were to be played (e.g. the media stream MAY receive treatment from PLC algorithms). The answering entity MUST re-generate all the RTP header fields as it would when - transmitting media. The UAS MAY choose to encode the loopback media - according to any of the media descriptions supported by the UAC. - Furthermore, in cases where the same media type is looped back, the - UAS MAY choose to preserve number of frames/packet and bitrate of - the encoded media according to the received media. + transmitting media. The answering entity MAY choose to encode the + loopback media according to any of the media descriptions supported + by the offering entity. Furthermore, in cases where the same media + type is looped back, the answering entity MAY choose to preserve + number of frames/packet and bitrate of the encoded media according + to the received media. 7. RTCP Requirements The use of the loopback attribute is intended for monitoring of media quality of the session. Consequently the media performance information should be exchanged between the offering and the answering entities. An offering or answering entity that is compliant to this specification SHOULD support RTCP per [RFC3550] and RTCP-XR per RFC 3611 [RFC3611]. Furthermore, if the client or the server choose to support RTCP-XR, they SHOULD support RTCP-XR - Statistics Summary Report Block and VoIP Metric Reports Block per - sections 4.6 and 4.7 of RFC 3611 [RFC3611]. The client and the + Loss RLE report block, Duplicate RLE report block, Statistics + Summary report block, and VoIP Metric Reports Block per sections + 4.1, 4.2, 4.6, and 4.7 of RFC 3611 [RFC3611]. The client and the server MAY support other RTCP-XR reporting blocks as defined by RFC 3611 [RFC3611]. 8. Examples This section provides examples for media descriptions using SDP for - different scenarios. The examples are given for SIP based + different scenarios. The examples are given for SIP-based transactions and are abbreviated and do not show the complete signaling for convenience. 8.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 s=Example @@ -609,21 +609,21 @@ [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, STD 1, 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, STD 1, November 2003. [RFC2234] Crocker, P. Overell, "Augmented ABNF for Syntax - Specification: ABNFö, RFC 3611, STD 1, November 1997. + Specification: ABNF”, RFC 3611, STD 1, November 1997. Authors' Addresses Kaynam Hedayat Brix Networks 285 Mill Road Chelmsford, MA 01824 US Phone: +1 978 367 5611 @@ -660,22 +660,22 @@ EMail: chelliah@cisco.com URI: http://www.cisco.com/ Nathan Stratton BroadVoice 900 Chelmsford Street Tower Three Lowell, MA 01851 US - Phone: +1 978 418 7320 - EMail: nstratton@broadvoice.com + Phone: +1 410 908 7587 + EMail: nathan@robotics.net URI: http://www.broadvoice.com/ IPR Disclosure Acknowledgement 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.