Network Working Group S. Mundra Internet-Draft Texas Instruments, Inc. Expires: December 6, 2004 June 7, 2004 A RTP Payload for Redundant Non-Audio Data draft-smundra-avt-rtp-red-non-audio-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. 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. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 6, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document specifies an RTP payload format for encoding redundant non-audio data for use with RFC 2198 redundancy scheme. The primary motivation for the payload format described herein is accurate loss detection and sequencing, and to make the redundancy mechanism independent of clock rate being used for non-audio data. It is hoped that use of this payload format will simplify the implementation of RFC 2198 redundancy mechanism for non-audio data and may improve efficiency of redundancy mechanism if RTCP extended reports (XR) were available to RTP senders. Mundra Expires December 6, 2004 [Page 1] Internet-Draft A RTP Payload for Redundant Non-Audio Data June 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. RTP Payload Format for Non-audio Data . . . . . . . . . . . . 4 3. MIME Registration . . . . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. SDP Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. Use With Audio/Telephone-event . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 7 9.2 Informative References . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . 10 Mundra Expires December 6, 2004 [Page 2] Internet-Draft A RTP Payload for Redundant Non-Audio Data June 2004 1. Introduction [Note to RFC Editor: All reference to RFCXXXX and RFCYYYY are to be replaced when those drafts are published as RFCs.] Voice band data sessions such as Fax, Modem, TTY(Text Phone) sessions that originate in PSTN (Public circuit Switched Telephone Network), when carried over an IP network, the gateways present at the intersection of the IP and the PSTN network typically terminate the Voice band data and then relay the non-audio data over IP network to the destination. The relay mechanism and data encoding formats for carrying voice band data session over IP network have been specified in [8], [9], [10], [11]. Voice band telephone events such as DTMF digits can also be relayed over IP network as specified in [12]. The term "non-audio" data in this memo is used to refer to RTP payload formats specified in [8], [9], [11], [12] and [13] for encoding data such as Fax, Modem, Text, DTMF Digits for transport using RTP over IP networks. The motivation for the payload format specified in this document are the characteristics that differentiate the non-audio data have. RTP timestamps are typically not useful or meaningful for rendering or sequencing the data at receiver and sequence numbers are of importance. RTP sessions involving non-audio data can tolerate higher latency however are less forgiving tolerant of any packet loss experienced on the network. The RFC 2198 audio redundancy payload format is one of the methods that is used to provide redundancy on the IP network. When relay mechanism are used the audio data is encoded using non-audio payload formats and timestamp often lose their significance and sequence numbers alone are of interest. The packets may not be available at regular interval and inter packet interval can easily get larger such that the 14 bit timestamp offset field specified in RFC 2198 for redundant encoding block header may limit one's ability to send the old data redundantly. Accurate loss detection and sequencing may be difficult or unreliable under some loss scenarios for non-audio data as the redundancy payload format does not preserve sequence numbers. Latency tolerance for non-audio session may be higher and RTP senders can make use of RTCP extended reports (see [14]) and can increase the efficiency of redundancy scheme which is limited with RFC2198 redundancy mechanism for the reason mentioned above. This draft attempts to simplify the implementation of redundancy mechanism for non-audio data by specifying a new redundant payload format for non-audio data. The new payload format differs from the one specified in [1] by encoding the 14-bit timestamp offset field in the redundant encoding block header as specified in section below. Mundra Expires December 6, 2004 [Page 3] Internet-Draft A RTP Payload for Redundant Non-Audio Data June 2004 2. RTP Payload Format for Non-audio Data This document defines a new payload format for use with RFC2198 redundancy scheme. The 14 bit "timestamp offset" field in the redundant encoding block header specified in [1] is encoded as Market-bit (1 bit) and sequence number offset (13 bits) as shown in figure below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| block PT |M| seqno offset | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The bits are as specified below: F: This field is as specified in [1]. block PT: This filed is as specified in [1]. block length: This field is as specified in [1]. M: This is the marker bit value in the RTP header this block was transmitted originally with. seqno offset: 13 bits unsigned offset of sequence number of this block relative to sequence number given in RTP header. The primary encoding block header is as specified in Section 3 of [1]. There are no other changes to the payload format and other details about redundancy scheme from Section 3 of [1] apply. 3. MIME Registration This document defines a new variant of payload format specified in [1] and registers optional parameters for registered MIME subtype RED which go in the SDP "a=fmtp" attribute for enabling use of the payload format specified in this document. Optional parameters for MIME subtypes "audio/red" and "text/red": red: The value MUST be equal to "seqno" in order to use payload format specified in this document. The parameter is optional and MUST NOT be present when payload format specified in [1] is to be used. Mundra Expires December 6, 2004 [Page 4] Internet-Draft A RTP Payload for Redundant Non-Audio Data June 2004 level: Specifies the redundancy level that is preferred when used with payload format specified here. This parameter takes integer values. This parameter is optional for the MUST NOT be present when payload format specified in [1] is to be used. 4. IANA Considerations Two new optional parameters "red" and "level" for MIME types "audio/ red" and "text/red" are to be registered to enable use payload format defined in this document. 5. SDP Considerations The optional parameter defined for use with this payload format go in the SDP "a=fmtp" attribute. Offer/Answer Considerations: The Offer/Answer SDP exchange model is described in [2]. fmtp parameter "red": The parameter MUST be present and MUST be equal to "seqno" in both Offer and Answer. fmtp parameter "level": The parameter is declarative and indicates preferred level of redundancy to be used and both Offer and Answer MAY have different values. Parameters "red" and "level" MUST NOT be present in an Answer if they were not present in the Offer. Only an Offerer can offer these parameters in an Offer when the session is being created or modified. This behavior is REQUIRED as per the procedure specified in [3] for registering optional parameters for existing MIME subtype. An Offerer SHOULD also use parameter "pt" to indicate desired level of redundancy to allow proper redundancy level negotiation when the Answerer negotiates payload format specified in [1]. An Answerer when selects non-audio payload format specified here can use parameter "level" alone to indicate the desired level of redundancy. Example: SDP example below shows use of this payload format with encoding audio/t38: m=audio 11000 RTP/AVP 100 98 0 a=rtpmap:98 T38/8000 a=rtpmap:100 RED/8000 a=fmtp:100 98/98/98; red=seqno; level=3 Mundra Expires December 6, 2004 [Page 5] 6. Use With Audio/Telephone-event Telephone events such as DTMF digits that are sent using the mechanism specified in [1] provide resiliency against packet loss during an event. A single event when encoded using telephone-event encoding can result in multiple packets with increasing sequence numbers but same timestamp. Sending all these packets as redundant payload would put additional burden on the receivers as timestamp which uniquely identify a telephone-event are not preserved in this payload format. In addition this sender behavior would be a waste of bandwidth. The redundancy is required across distinct events as loss of intermediate events can result in operation failure with the severity which depends on the application being used. Application using this payload format for redundancy when telephone events are encoded using telephone-event encoding method MUST send only those packets as redundant payload that have E-bit in their payload set to 1. Only one packet per event SHOULD be sent as redundant payload even if there are retransmissions of packet with E-bit set. Note that the telephone events do not have to occur in a 2.048 second window (assuming a clock rate of 8000Hz) for them to be included as redundant payload. Thus an IVR (Interactive Voice Response) system which is used for calling card application can choose a redundancy level of 10 allowing improve resiliency against packet loss. Following figure shows the example where a user is dialing last digit of the DTMF sequence "911". For clarity, byte alignment is ignored in the figure below. In this example, the dynamic payload types 96 and 97 have been assigned for the redundancy mechanism and the telephone-event payload, respectively. Digit "9" was a 50ms long and a single packet with both M and E bit set was sent. Following that digit "1" was dialed which was 800 ms long. The digit "1" dialed last has lasted for 200 ms so far. Mundra Expires December 6, 2004 [Page 6] Internet-Draft A RTP Payload for Redundant Non-Audio Data June 2004 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | | 2 |0|0| 0 |0| 96 | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | | 0x20450 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | | 0x6648 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| block PT |M| seqno offset | block length | |1| 97 |1| from n | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| block PT |M| seqno offset | block length | |1| 97 |0| from n | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| Block PT | |0| 97 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | digit |E|R| volume | duration | | 9 |1|0| 7 | 50 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | digit |E|R| volume | duration | | 1 |1|0| 7 | 800 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | digit |E|R| volume | duration | | 1 |0|0| 20 | 200 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7. Security Considerations RTP packets using the payload format defined in this specification are subject to the security considerations discussed in [1],[4], and the RTP profile used for session. 8. Acknowledgement The author would like to thank David Lide, Herman Lo, Collin Perkins, Peter Wang for their feedback and inputs to this document. 9. References 9.1 Normative References [1] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Mundra Expires December 6, 2004 [Page 7] Internet-Draft A RTP Payload for Redundant Non-Audio Data June 2004 Bolot, J., Vega-Garcia, A. and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997. [2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [3] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003. [4] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [7] Jones, P., "Registration of the text/red MIME Sub-type, draft-ietf-avt-text-red, RFC XXXX", 2004. 9.2 Informative References [8] Hellstorm, G. and P. Jones, "RTP Payload for Text Conversation, draft-ietf-avt-rfc2793bis, RFCYYYY", 2004. [9] "ITU-T Recommendation T.38, "Procedures for real-time Group 3 facsimile communication over IP networks", 2002 with Amendment 2", January 2004. [10] "ITU-T Recommendation V.152 (Draft)", 2004. [11] "ITU-T Recommendation V.150.1 (2003) - Procedures for the end-to-end connection of V-Series DCEs over an IP network", 2003. [12] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000. [13] "ITU-T Recommendation T.140 - Text conversation protocol for multimedia application", 1998. [14] Friedman, T., Caceres, R. and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003. [15] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. Mundra Expires December 6, 2004 [Page 8] Internet-Draft A RTP Payload for Redundant Non-Audio Data June 2004 [16] Hellstrom, G., "RTP Payload for Text Conversation", RFC 2793, May 2000. [17] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999. [18] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [19] Ott, J., Wenger, S., Sato, N., Burmeister, C. and J. Rey, "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF), draft-ietf-avt-rtcp-feedback", 2004. [20] Ott, J. and E. Carrara, "Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF), draft-ietf-avt-profile-savpf", 2004. Author's Address Satish Mundra Texas Instruments, Inc. 20450 Century Blvd. Germantown, MD 20874 USA Phone: +1 301 515 6648 EMail: smundra@telogy.com Mundra Expires December 6, 2004 [Page 9] Internet-Draft A RTP Payload for Redundant Non-Audio Data June 2004 Intellectual Property Statement 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. 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 Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Mundra Expires December 6, 2004 [Page 10]