--- 1/draft-ietf-mmusic-media-loopback-13.txt 2010-07-28 11:14:27.000000000 +0200 +++ 2/draft-ietf-mmusic-media-loopback-14.txt 2010-07-28 11:14:27.000000000 +0200 @@ -1,28 +1,28 @@ Internet Draft K. Hedayat - Expires: October 8, 2010 EXFO + Expires: January 27, 2011 EXFO N. Venna EXFO P. Jones Cisco Systems, Inc. A. Roychowdhury Hughes Systique Corp. C. SivaChelvan Cisco Systems, Inc. N. Stratton BlinkMind, Inc. - April 8, 2010 + July 27, 2010 An Extension to the Session Description Protocol (SDP) for Media Loopback - draft-ietf-mmusic-media-loopback-13 + draft-ietf-mmusic-media-loopback-14 Status of this Memo 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. @@ -32,21 +32,21 @@ 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. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on June 30, 2010. + This Internet-Draft will expire on January 27, 2011. Copyright Notice 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 @@ -80,49 +80,49 @@ Table of Contents 1. Introduction .................................................. 3 2. Terminology ................................................... 4 3. Offering Entity Behavior ...................................... 4 4. Answering Entity Behavior ..................................... 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 ................. 6 - 5.4 Generating the Answer for Loopback Session ................ 7 - 5.5 Offerer Processing of the Answer .......................... 9 - 5.6 Modifying the Session ..................................... 9 - 5.7 Priming the loopback pump ................................. 9 + 5.3 Payload type mapping for loopback sessions ................ 6 + 5.4 Generating the Offer for Loopback Session ................. 7 + 5.5 Generating the Answer for Loopback Session ................ 8 + 5.6 Offerer Processing of the Answer .......................... 9 + 5.7 Modifying the Session .................................... 10 + 5.8 Priming the loopback pump ................................ 10 6. RTP Requirements ............................................. 10 7. Payload formats for Packet loopback .......................... 11 - 7.1 Encapsulated Payload format .............................. 11 - 7.2 Direct loopback RTP payload format ....................... 13 - 8. Payload formats for Priming the Loopback Pump ................ 15 + 7.1 Encapsulated Payload format .............................. 12 + 7.2 Direct loopback RTP payload format ....................... 14 + 8. Payload format for Priming the Loopback Pump ................. 15 8.1 Usage of RTP Header fields ............................... 15 - 8.2 Usage of SDP ............................................. 15 - 9. RTCP Requirements ............................................ 15 + 8.2 Usage of SDP ............................................. 16 + 9. RTCP Requirements ............................................ 16 10. Congestion Control .......................................... 16 - 11. Examples .................................................... 16 - 11.1 Offer for specific media loopback type .................. 16 + 11. Examples .................................................... 17 + 11.1 Offer for specific media loopback type .................. 17 11.2 Offer for choice of media loopback type ................. 17 11.3 Offer for choice of media loopback type with loopback primer ....................................................... 18 11.4 Response to INVITE request rejecting loopback media ..... 19 11.5 Response to INVITE request rejecting loopback media with loopback primer payload type ................................. 20 - 12. Security Considerations ..................................... 20 + 12. Security Considerations ..................................... 21 13. Implementation Considerations ............................... 21 - 14. IANA Considerations ......................................... 21 - 14.1 SDP Attributes .......................................... 21 - 14.2 MIME Types .............................................. 22 + 14. IANA Considerations ......................................... 22 + 14.1 SDP Attributes .......................................... 22 + 14.2 MIME Types .............................................. 23 15. Acknowledgements ............................................ 36 - 16. Normative References ........................................ 36 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 @@ -165,32 +165,32 @@ response from the answering entity for confirmation that the request is accepted. 4. Answering Entity Behavior An answering entity compliant to this specification and receiving an offer containing media descriptions with the "loopback" media attributes, MUST acknowledge the request by including the received "loopback" media attributes for each media description in its response. The server MAY reject the "loopback" request for - specific media types as defined in section 5.4.1 of this + specific media types as defined in section 5.5.1 of this specification. An answering entity that is not compliant to this specification and which receives an offer with the "loopback" media attributes MAY ignore the attribute and treat the incoming offer as a normal request. 5. SDP Constructs Syntax Two new media attributes are defined: one indicates the type of - loopback and one indicates the mode of the loopback. + loopback and the other 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 [RFC5234] for loopback-type: @@ -239,26 +239,38 @@ payload type (described in Section 8 of this document) is requested by the loopback-source or included in the response by loopback-mirror. is a media format description. The format description 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 + 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. + specify the payloads it is willing to send. This separation of + payload types allow receivers that do not understand media loopback + to reject the call. - 5.3 Generating the Offer for Loopback Session + 5.3 Payload type mapping for loopback sessions + + As specified in RFC 4566[RFC4566], the rtpmap attribute maps from + an RTP payload type number (as used in an "m=" line) to an encoding + name denoting the payload format to be used. For loopback sessions, + media formats are specified both in the "m=" line and the loopback- + mode attribute line as described in Section 5.2. This specification + extends the usage of rtpmap attribute to media formats specified in + the loopback-mode attribute line in addition to the "m=" line. + + 5.4 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: m=audio 41352 RTP/AVP 0 8 100 a=loopback:rtp-media-loopback a=loopback-source:0 8 100 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 @@ -292,21 +304,21 @@ 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 - 5.4 Generating the Answer for Loopback Session + 5.5 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. When a stream is offered with the loopback-source attribute, the corresponding stream in the response MUST be loopback-mirror and vice versa, provided that answerer is capable of supporting the requested loopback-type. For example, if the offer contains the loopback-source attribute: @@ -320,23 +332,24 @@ m=audio 41352 RTP/AVP 0 8 a=loopback:rtp-media-loopback a=loopback-mirror:0 8 As previously stated if a stream is offered with multiple loopback type attributes, the corresponding stream MUST contain only one loopback type attribute selected by the answerer. For example, if the offer contains: - m=audio 41352 RTP/AVP 0 8 + m=audio 41352 RTP/AVP 0 8 112 a=loopback:rtp-media-loopback rtp-pkt-loopback a=loopback-source:0 8 + a=rtpmap:112 encaprtp/8000 The answer that is capable of supporting the offer and chooses to loopback the media using the rtp-media-loopback type MUST contain: m=audio 41352 RTP/AVP 0 8 a=loopback:rtp-media-loopback a=loopback-mirror:0 8 As specified in section 7, if the loopback-type is rtp-pkt-loopback, either the encapsulated RTP payload format or @@ -357,52 +370,53 @@ m=audio 41352 RTP/AVP 112 a=loopback:rtp-pkt-loopback a=loopback-mirror:0 8 a=rtpmap:112 encaprtp/8000 m=audio 41352 RTP/AVP 113 a=loopback:rtp-pkt-loopback a=loopback-mirror:0 8 a=rtpmap:113 rtploopback/8000 - 5.4.1 Rejecting the Loopback Offer + 5.5.1 Rejecting the Loopback Offer 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 + 5.6 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. If the answer does not contain a=loopback-mirror or a=loopback-source, it is assumed that the loopback extensions are not supported by the target UA. - 5.6 Modifying the Session + 5.7 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 [RFC3264]. This also includes transitioning from a normal media processing mode to loopback mode, and vice a versa. - 5.7 Priming the loopback pump + 5.8 Priming the loopback pump + In certain scenarios it is possible that the media transmitted by the loopback-source is blocked by a network element until the loopback-mirror 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 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 results in a chicken and egg scenario as the looback-mirror cannot transmit any media until it receives the @@ -417,29 +431,28 @@ 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 corresponding to this payload type. After the first media packet is received from the loopback-source, the loopback-mirror MUST terminate the transmission of media for this payload type and MUST start looping back media as defined by the other loopback attributes present in the offer. 6. RTP Requirements - An answering entity that is compliant to this specification and accepting a media with rtp-pkt-loopback loopback-type MUST loopback the incoming RTP packets using either the encapsulated RTP payload format or the direct loopback RTP payload format as defined in section 7 of this specification. An answering entity that is compliant to this specification and - accepting a media with rtp-media-loopback loopback-type MUST + accepting a media with the loopback type rtp-media-loopback 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 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. @@ -449,23 +462,36 @@ The payload formats described in this section MUST be used by a loopback-mirror when rtp-pkt-loopback is the specified loopback-type. Two different formats are specified here - an encapsulated RTP payload format and a direct loopback RTP payload format. The encapsulated RTP payload format should be used when the incoming RTP header information needs to be preserved during the loopback operation. This is useful in cases where loopback source needs to measure performance metrics in both directions. However, this comes at the expense of increased packet size as described in section 7.1. The direct loopback RTP payload format - should be used when bandwidth requirement prevent the use of + should be used when bandwidth requirement prevents the use of encapsulated RTP payload format. + To keep the implementation of loopback-mirrors simple it is + mandated that no payload format other than encapsulated or direct + loopback formats can be used in the packets generated by a + loopback-mirror. As described in RFC 3550 [RFC3550], sequence + numbers and timestamps in the RTP header are generated with initial + random values for security reasons. If this were not mandated and + the source payload is sequence number aware, the loopback-mirror + will be required to understand that payload format to generate + looped back packets that do not violate RFC 3550 [RFC3550]. + Requiring looped back packets to be in one of the two formats means + loopback-mirror does not have to look into the actual payload + received before generating the loopback packets. + 7.1 Encapsulated Payload format A received RTP packet is encapsulated in the payload section of the RTP packet generated by a loopback-mirror. Each received packet MUST be encapsulated in a different packet, the encapsulated packet MAY be fragmented only if required (for example: due to MTU limitations). 7.1.1 Usage of RTP Header fields @@ -683,42 +709,42 @@ 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. 11.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 192.0.2.11 + o=alice 2890844526 2890842807 IN IP4 host.atlanta.example.com s=Example i=An example session - e=user@example.com - c=IN IP4 192.0.2.12/127 + e=alice@example.com + c=IN IP4 host.atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=loopback:rtp-media-loopback a=loopback-source:0 a=rtpmap:0 pcmu/8000 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 192.0.2.11 + o=bob 2890844526 2890842807 IN IP4 host.biloxi.example.com s=Example i=An example session - e=user@example.com - c=IN IP4 192.0.2.12/127 + e=bob@example.com + c=IN IP4 host.biloxi.example.com t=0 0 m=audio 49270 RTP/AVP 0 a=loopback:rtp-media-loopback a=loopback-mirror:0 a=rtpmap:0 pcmu/8000 The server is accepting to mirror the media from the client at the media level. 11.2 Offer for choice of media loopback type @@ -715,172 +741,170 @@ t=0 0 m=audio 49270 RTP/AVP 0 a=loopback:rtp-media-loopback a=loopback-mirror:0 a=rtpmap:0 pcmu/8000 The server is accepting to mirror the media from the client at the media level. 11.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 192.0.2.11 + o=alice 2890844526 2890842807 IN IP4 host.atlanta.example.com s=Example i=An example session - e=user@example.com - c=IN IP4 192.0.2.12/127 + e=alice@example.com + c=IN IP4 host.atlanta.example.com 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:0 pcum/8000 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 192.0.2.11 + o=box 2890844526 2890842807 IN IP4 host.biloxi.example.com s=Example i=An example session - e=user@example.com - c=IN IP4 192.0.2.12/127 + e=bob@example.com + c=IN IP4 host.biloxi.example.com t=0 0 m=audio 49270 RTP/AVP 112 a=loopback:rtp-pkt-loopback a=loopback-mirror:0 a=rtpmap:0 pcmu/8000 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. 11.3 Offer for choice of media loopback type with loopback primer A client sends an INVITE request with SDP which looks like: v=0 - o=user1 2890844526 2890842807 IN IP4 192.0.2.11 + o=alice 2890844526 2890842807 IN IP4 host.atlanta.example.com s=Example i=An example session - e=user@example.com - c=IN IP4 192.0.2.12/127 + e=alice@example.com + c=IN IP4 host.atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 112 113 114 a=loopback:rtp-media-loopback rtp-pkt-loopback a=loopback-source:0 a=rtpmap:0 pcmu/8000 a=rtpmap:112 encaprtp/8000 a=rtpmap:113 rtploopback/8000 a=rtpmap:114 loopbkprimer/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. The client also expects the server to source media until it receives packets from the server per media described with the loopbkprimer payload type. A server sends a response with SDP which looks like: v=0 - o=user1 2890844526 2890842807 IN IP4 192.0.2.11 + o=bob 2890844526 2890842807 IN IP4 host.biloxi.example.com s=Example i=An example session e=user@example.com - c=IN IP4 192.0.2.12/127 + c=IN IP4 host.biloxi.example.com t=0 0 m=audio 49270 RTP/AVP 113 a=loopback:rtp-pkt-loopback a=loopback-mirror:0 114 a=rtpmap:0 pcmu/8000 a=rtpmap:113 rtploopback/8000 a=rtmpa:114 loopbkprimer/8000 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. 11.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 192.0.2.11 + o=alice 2890844526 2890842807 IN IP4 host.atlanta.example.com s=Example i=An example session e=user@example.com - c=IN IP4 192.0.2.12/127 + c=IN IP4 host.atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=loopback:rtp-media-loopback a=loopback-source:0 a=rtpmap:0 pcmu/8000 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 192.0.2.11 + o=bob 2890844526 2890842807 IN IP4 host.biloxi.example.com s=Example i=An example session e=user@example.com - c=IN IP4 192.0.2.12/127 + c=IN IP4 host.biloxi.example.com t=0 0 m=audio 0 RTP/AVP 0 a=loopback:rtp-media-loopback a=loopback-mirror:0 a=rtpmap:0 pcmu/8000 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. 11.5 Response to INVITE request rejecting loopback media with loopback primer payload type A client sends an INVITE request with SDP which looks like: v=0 - o=user1 2890844526 2890842807 IN IP4 192.0.2.11 + o=alice 2890844526 2890842807 IN IP4 host.atlanta.example.com s=Example i=An example session - e=user@example.com - c=IN IP4 192.0.2.12/127 + e=alice@example.com + c=IN IP4 host.atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 100 a=loopback:rtp-media-loopback a=loopback-source:0 a=rtpmap:0 pcum/8000 a=rtpmap:100 loopbkprimer/8000 - 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 using the loopbkprimer payload type. A server sends a response with SDP which looks like: v=0 - o=user1 2890844526 2890842807 IN IP4 192.0.2.11 + o=bob 2890844526 2890842807 IN IP4 host.biloxi.example.com s=Example i=An example session - e=user@example.com - c=IN IP4 192.0.2.12/127 + e=bob@example.com + c=IN IP4 host.biloxi.example.com 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. 12. Security Considerations @@ -1590,23 +1614,23 @@ defined at this time. Author: Kaynam Hedayat. Change controller: IETF Audio/Video Transport working group delegated from the IESG. 15. Acknowledgements - The authors wish to thank Nagarjuna Venna, Flemming Andreasen, Jeff - Bernstein, Paul Kyzivat, and Dave Oran for their comments and - suggestions. + The authors wish to thank Nagarjuna Venna, Muthu ArulMozhi Perumal, + Flemming Andreasen, Jeff Bernstein, Paul Kyzivat, and Dave Oran for + their comments and suggestions. 16. Normative References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)",