idnits 2.17.1 draft-ietf-payload-rtp-g718-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 16, 2012) is 4242 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'AMR-WB' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G718.2008' ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 5117 (Obsoleted by RFC 7667) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Zorn, Ed. 3 Internet-Draft Network Zen 4 Intended status: Standards Track Y. Wang 5 Expires: February 17, 2013 Qualcomm Incorporated 6 A. Lakaniemi 7 Independent Contributor 8 August 16, 2012 10 RTP Payload Format for G.718 Speech/Audio 11 draft-ietf-payload-rtp-g718-03 13 Abstract 15 This document specifies the Real-Time Transport Protocol (RTP) 16 payload format for the Embedded Variable Bit-Rate (EV-VBR) speech/ 17 audio codec, specified in ITU-T G.718. A media type registration for 18 this RTP payload format is also included. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on February 17, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 68 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. The G.718 Codec . . . . . . . . . . . . . . . . . . . . . 4 70 3.2. Benefits of Layered Design . . . . . . . . . . . . . . . . 6 71 3.3. Transmitting Layered Data . . . . . . . . . . . . . . . . 6 72 3.4. Scaling Scenarios and Rate Control . . . . . . . . . . . . 7 73 4. G.718 RTP Payload Format . . . . . . . . . . . . . . . . . . . 7 74 4.1. Payload Structure . . . . . . . . . . . . . . . . . . . . 8 75 4.1.1. Payload Header . . . . . . . . . . . . . . . . . . . . 8 76 4.1.2. G.718 Transport Blocks . . . . . . . . . . . . . . . . 8 77 4.2. Handling The Encoded Data . . . . . . . . . . . . . . . . 11 78 4.3. G.718 Scaling . . . . . . . . . . . . . . . . . . . . . . 13 79 4.4. CRC Verification . . . . . . . . . . . . . . . . . . . . . 13 80 4.5. G.718 Session . . . . . . . . . . . . . . . . . . . . . . 14 81 4.6. Cross-stream/Cross-layer Timing Synchronization . . . . . 14 82 4.7. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 14 83 5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 15 84 5.1. Media Type Registration . . . . . . . . . . . . . . . . . 15 85 5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 17 86 5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 17 87 5.4. Declarative Usage of SDP . . . . . . . . . . . . . . . . . 18 88 5.5. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . 18 89 5.5.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 18 90 5.5.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 18 91 5.5.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 19 92 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 20 93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 95 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 96 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 97 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 98 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 99 Appendix A. Payload Examples . . . . . . . . . . . . . . . . . . 23 100 A.1. Simple Payload Examples . . . . . . . . . . . . . . . . . 23 101 A.1.1. All The Layers in The Same Payload . . . . . . . . . . 23 102 A.1.2. Layers in Seperate RTP Streams . . . . . . . . . . . . 24 103 A.2. Advanced Examples . . . . . . . . . . . . . . . . . . . . 25 104 A.2.1. Different Update Rate for Subset of Layers . . . . . . 25 105 A.2.2. Redundant Frames With Limited Set of Layers . . . . . 26 107 1. Introduction 109 The International Telecommunication Union (ITU-T) Recommendation 110 G.718 [ITU.G718.2008] specifies the Embedded Variable Bit Rate (EV- 111 VBR) speech/audio codec. This document specifies the Real-time 112 Transport Protocol (RTP) [RFC3550] payload format for this codec. 114 2. Requirements Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 3. Background 122 3.1. The G.718 Codec 124 G.718 is an embedded variable rate speech codec having a layered 125 design. The bitstream of the G.718 core codec consists of a core 126 layer, denoted as L1, and four enhancement layers, denoted as L2-L5. 127 The bit-rates of the G.718 core codec range from 8 kbit/s (core layer 128 only) to 32 kbit/s (with all layers up to L5). Furthermore, the 129 G.718 codec also supports discontinuous transmission (DTX) and 130 comfort noise generation (CNG) by sending Silence Descriptor (SID) 131 frames during periods of non-active input signal, resulting in a 132 reduced bit-rate. The sampling frequency of the core codec is 16 kHz 133 and the codec operates on 20 ms frames. The G.718 codec is also 134 capable of narrowband operation with audio input and/or output at 8 135 kHz sampling frequency. 137 While transmitting/receiving the core layer L1 is enough for 138 successful decoding of the audio content, each of the enhancement 139 layers Ln (n being 2 to 5, inclusive) provides an improvement to 140 reconstructed audio quality. Thus, the core layer ensures the basic 141 communication while the enhancement layers can be used to improve the 142 perceptual quality. Furthermore, enhancement layers are dependent on 143 all the lower layers in a sense that successful decoding of layer Ln 144 requires also all the layers Lm with mn MUST 578 also be discarded. 580 4.5. G.718 Session 582 A G.718 session consists of one or several RTP sessions carrying 583 G.718 data encoded according to the payload format specified in 584 Section 4.1. 586 4.6. Cross-stream/Cross-layer Timing Synchronization 588 In the case where a G.718 session consists of multiple RTP sessions, 589 the RTP packets transmitted on separate RTP sessions need to be 590 synchronized in order to enable reconstruction of the frames in the 591 receiving end [RFC6051]. Since each of the RTP sessions uses its own 592 random initial value for the RTP timestamp, there is also a random 593 offset between the RTP timestamps values carrying the EDUs belonging 594 to the same encoded frame in different RTP sessions. 596 The receiver MUST use the traditional RTCP-based mechanism to 597 synchronize streams by using the RTP and NTP timestamps of the RTCP 598 Sender Reports (SR) it receives [RFC3550]. 600 4.7. RTP Header Usage 602 This section specifies the usage of some fields of the RTP header 603 (specified in Section 5 of [RFC3550]) with the G.718 RTP payload 604 format. The settings for other RTP header fields are as specified in 605 [RFC3550]. 607 The RTP timestamp corresponds to the sampling instant of the first 608 encoded sample of the earliest frame in the payload. The timestamp 609 clock frequency is 32 kHz. 611 The marker bit (M) of each of the RTP streams of the session SHALL be 612 set to value 1 if the payload carries an EDU belonging to the first 613 frame after an inactive period, i.e. an EDU from the first frame of a 614 talkspurt. For all other packets the marker bit is set to value 0. 616 5. Payload Format Parameters 618 This section defines the parameters that may be used to configure 619 optional features in the G.718 RTP transmission. 621 The parameters are defined here as part of the media subtype 622 registration for the G.718 codec. Mapping of the parameters into the 623 Session Description Protocol (SDP) [RFC4566] is also provided for 624 those applications that use SDP. In control protocols that do not 625 use MIME or SDP, the media type parameters MUST be mapped to the 626 format used with that control protocol. 628 5.1. Media Type Registration 630 This registration is done using the template defined in RFC 4288 631 [RFC4288] and following RFC 4855 [RFC4855]. 633 Type name: audio 635 Subtype name: G718 637 Required parameters: none 639 Optional parameters: 641 mode: This parameter MAY be used to indicate whether the 642 mode with layer L1 being present or the AMR-WB 643 compatible mode (with layer L1' being present) is 644 in use. If this parameter is not present or the 645 value of this parameter is equal to 0, the mode 646 with layer L1 being present is in use. Otherwise, 647 the AMR-WB compatible mode is in use. When this 648 parameter is present, the value MUST be either 0 649 or 1. 650 NOTE: When the upcoming stereo and SWB options are 651 present, the semantics of this parameter may 652 change. 654 layers: The numbers of the layers (in range from 1 to 5, 655 denoting layers from L1 to L5, respectively) 656 transmitted in this session, expressed as comma- 657 separated list of layer numbers. If the parameter 658 is present, at least layer L1 or L1' MUST be 659 included in the list of layers in one of the RTP 660 sessions included in the G.718 session. If the 661 parameter is not present, all layers up to layer 662 L5 MAY be used in the session. 664 NOTE: Why not use semantics similarly as L-ID? 666 ptime: The recommended length of time (in milliseconds) 667 represented by the media in a packet. See Section 668 6 of [RFC4566]. 670 maxptime: The maximum length of time (in milliseconds) that 671 can be encapsulated in a packet. See Section 6 of 672 [RFC4566]. 674 NOTE: Some further study is needed to see if separate parameters 675 for sending and receiving capabilities/preferences are 676 needed -- especially for upcoming stereo and SWB options. 678 NOTE: Support for upcoming SWB and stereo options needs to be 679 taken into account. Basically we can either 1) extend the 680 parameter "layers" to cover also this aspect, or 2) define 681 separate parameter(s) for these new options when more 682 details on the stereo/SWB support are available. 684 Encoding considerations: 685 This media type is framed and contains binary data; see Section 686 4.8 of [RFC4288]. 688 Security considerations: See Section 7 of RFC XXXX. 689 [RFC Editor: Upon publication as an RFC, please "XXXX" with the 690 number assigned to this document and remove this note.] 692 Interoperability considerations: None. 694 Published specification: RFC XXX. 695 [RFC Editor: Upon publication as an RFC, please "XXXX" with the 696 number assigned to this document and remove this note.] 698 Applications which use this media type: 699 For example: Voice over IP, audio and video conferencing, audio 700 streaming and voice messaging. 702 Additional information: None. 704 Person & email address to contact for further information: 705 Ari Lakaniemi, ari.lakaniemi@nokia.com 707 Intended usage: COMMON 708 Restrictions on usage: 709 This media type depends on RTP framing, and hence is only defined 710 for transfer via RTP [RFC3550]. 712 Author: Ari Lakaniemi, ari.lakaniemi@nokia.com 714 Change controller: 715 IETF Audio/Video Transport Working Group delegated from the IESG. 717 5.2. Mapping to SDP Parameters 719 The information carried in the media type specification has a 720 specific mapping to fields of the SDP [RFC4566], which is commonly 721 used to describe RTP sessions. When SDP is used to specify sessions 722 employing the G.718 codec, the mapping is as follows: 724 o The media type ("audio") goes in SDP "m=" as the media name. 726 o The media subtype ("G718") goes in SDP "a=rtpmap" as the encoding 727 name. The RTP clock rate in "a=rtpmap" MUST be 32000 for G.718. 728 NOTE: The current choice for the RTP clock rate is a 729 'placeholder'. The clock rate needs to be set according to SWB 730 sampling rate, which is still T.B.D. Since the core codec 731 employs 16000 Hz sampling rate, an integer multiple of 16000 Hz 732 seems to be a preferable choice. 734 o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and 735 "a=maxptime" attributes, respectively. 737 o Any remaining parameters go in the SDP "a=fmtp" attribute by 738 copying them directly from the media type string as a semicolon 739 separated list of parameter=value pairs. 741 5.3. Offer/Answer Considerations 743 The following considerations apply when using the SDP offer/answer 744 [RFC3264] mechanism to negotiate the G.718 transport. The parameter 745 "layers" MAY be used to indicate the layer configuration for the each 746 RTP session belonging to current G.718 session an end-point making 747 the offer is ready to transmit and wishes to receive. 749 o In case the G.718 session consists of a single RTP session, it is 750 RECOMMENDED not to impose any layer restrictions for the session 751 but to use the rate control functionality to set possible 752 restrictions on usage of the higher or highest layers. If the 753 offer includes a layer configuration parameter, the answer MAY use 754 different configuration, but the highest layer in the answer MUST 755 NOT be higher than the highest layer of the offered configuration. 757 NOTE: Support for answer modifying the layer configuration is 758 FFS. 760 o In case the G.718 session consists of multiple RTP sessions, the 761 answer MUST use the layer configurations provided in the offer for 762 the sessions it accepts. 764 5.4. Declarative Usage of SDP 766 In declarative usage, such as SDP in RTSP [RFC2326] or SAP [RFC2974], 767 the parameter "layers" SHALL be interpreted to provide a set of 768 layers that the sender MAY use in the session. 770 5.5. SDP Examples 772 Some example SDP session descriptions utilizing G.718 encodings are 773 provided below. 775 5.5.1. Example 1 777 The first example illustrates the simple case with the G.718 session 778 employing a single RTP session and the AVPF profile is offered, and 779 the answer accepts the offer without any changes. 781 Offer: 783 m=audio 49120 RTP/AVPF 97 784 a=rtpmap:97 G718/32000/1 786 Answer: 788 m=audio 49120 RTP/AVPF 97 789 a=rtpmap:97 G718/32000/1 791 5.5.2. Example 2 793 This example shows a bit more complex case where the G.718 session 794 using a single RTP session and the AVPF profile is offered with the 795 restriction to send/receive only with layers L1 and L2. The answer 796 indicates that the other end-point is happy to receive (and send) 797 layers up to L5. 799 Offer: 801 m=audio 49120 RTP/AVPF 97 802 a=rtpmap:97 G718/32000/1 803 a=fmtp:97 layers=1,2 805 Answer: 807 m=audio 49120 RTP/AVPF 97 808 a=rtpmap:97 G718/32000/1 809 a=fmtp:97 layers=1,2,3,4,5 811 5.5.3. Example 3 813 The third example shows an G.718 session using multiple RTP sessions 814 with the AVPF profile. The answerer wishes to use only layers up to 815 L3. 817 Offer: 819 m=audio 49120 RTP/AVPF 97 820 a=rtpmap:97 G718/32000/1 821 a=fmtp:97 layers=1,2 822 a=mid=1 824 m=audio 49122 RTP/AVPF 98 825 a=rtpmap:98 G718/32000/1 826 a=fmtp:98 layers=3 827 a=mid=2 828 a=depend:lay 1 830 m=audio 49124 RTP/AVPF 99 831 a=rtpmap:99 G718/32000/1 832 a=fmtp:99 layers=4,5 833 a=mid=3 834 a=depend:lay 1 2 836 Answer: 838 m=audio 49120 RTP/AVPF 97 839 a=rtpmap:97 G718/32000/1 840 a=fmtp:97 layers=1,2 841 a=mid=1 843 m=audio 49120 RTP/AVPF 98 844 a=rtpmap:98 G718/32000/1 845 a=fmtp:98 layers=3 846 a=mid=2 847 a=depend:lay 1 849 Note that the dependency signaling described in [RFC5583] is used in 850 the third example above to indicate the relationship between the 851 layers distributed into separate RTP sessions. 853 6. Congestion Control 855 As a scalable codec, G.718 implicitly provides means for congestion 856 control by providing a possibility for 'thinning' the bitstream. The 857 RTP payload format according to this specification provides several 858 different means for reducing the G.718 session bandwidth. The most 859 appropriate mechanism (in terms of impact to the user experience) 860 depends on the employed payload structure and also on the employed 861 session configuration (single RTP session or multiple RTP sessions). 862 The following means (in no particular order) can be used to assist 863 congestion control procedures -- either by the sender or by the 864 intermediate node. 866 o The payloads carrying the EDUs representing the highest layers in 867 an G.718 session can be dropped, along with all associated 868 transport blocks 870 o The transport blocks carrying the EDUs representing the highest 871 layers within the payload can be dropped 873 o Transport blocks or payloads carrying EDUs belonging to redundant 874 frames included in the payload can be dropped 876 7. Security Considerations 878 RTP packets using the payload format defined in this specification 879 are subject to the security considerations discussed in the RTP 880 specification [RFC3550], and in any appropriate RTP profile (for 881 example [RFC3551] or [RFC4585]. This implies that confidentiality of 882 the media streams is achieved by encryption; for example, through the 883 application of SRTP [RFC3711]. Because the data compression used 884 with this payload format is applied end-to-end, any encryption needs 885 to be performed after compression. 887 A potential denial-of-service threat exists for data encodings using 888 compression techniques that have non-uniform receiver-end 889 computational load. The attacker can inject pathological datagrams 890 into the stream that will increase the processing load of the decoder 891 and may cause the receiver to be overloaded. For example inserting 892 additional EDUs representing the higher enhancement layers on top of 893 the ones actually transmitted may increase the decoder load. 894 However, the G.718 codec is not particularly vulnerable to such an 895 attack, since the majority of the computational load in an G.718 896 session is associated to the encoder. Another form of possible 897 attach might be forging of codec bit-rate control messages, which may 898 result in encoder operating employing higher number of enhancement 899 layers than originally intended and thereby requiring larger amount 900 of computation resources. Therefore, the usage of data origin 901 authentication and data integrity protection of at least the RTP 902 packet is RECOMMENDED; for example, with SRTP [RFC3711]. 904 Note that the appropriate mechanism to ensure confidentiality and 905 integrity of RTP packets and their payloads is very dependent on the 906 application and on the transport and signaling protocols employed. 907 Thus, although SRTP is given as an example above, other possible 908 choices exist. 910 Note that end-to-end security with either authentication, integrity 911 or confidentiality protection will prevent a network element not 912 within the security context from performing media-aware operations 913 other than discarding complete packets. To allow any (media-aware) 914 intermediate network element to perform its operations, it is 915 required to be a trusted entity which is included in the security 916 context establishment. 918 8. IANA Considerations 920 IANA is kindly requested to register a media type for the G.718 codec 921 for RTP transport, as specified in Section 5.1 of this document. 923 9. Acknowledgements 925 Thanks to Qin Wu for useful review and commentary. 927 10. References 929 10.1. Normative References 931 [AMR-WB] 3GPP, "Speech codec speech processing functions; 932 Adaptive Multi-Rate - Wideband (AMR-WB) speech 933 codec; General description", 3GPP TS 26.171 5.0.0, 934 April 2001. 936 [ITU.G718.2008] International Telecommunications Union, "Frame Error 937 Robust Narrowband and Wideband Embedded Variable 938 Bit-Rate Coding of Speech and Audio from 8-32 939 Kbit/s", ITU-T Recommendation G.718, May 2008. 941 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 942 Requirement Levels", BCP 14, RFC 2119, March 1997. 944 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer 945 Model with Session Description Protocol (SDP)", 946 RFC 3264, June 2002. 948 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 949 Jacobson, "RTP: A Transport Protocol for Real-Time 950 Applications", STD 64, RFC 3550, July 2003. 952 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for 953 Audio and Video Conferences with Minimal Control", 954 STD 65, RFC 3551, July 2003. 956 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., 957 and K. Norrman, "The Secure Real-time Transport 958 Protocol (SRTP)", RFC 3711, March 2004. 960 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications 961 and Registration Procedures", BCP 13, RFC 4288, 962 December 2005. 964 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: 965 Session Description Protocol", RFC 4566, July 2006. 967 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and 968 J. Rey, "Extended RTP Profile for Real-time 969 Transport Control Protocol (RTCP)-Based Feedback 970 (RTP/AVPF)", RFC 4585, July 2006. 972 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 973 Formats", RFC 4855, February 2007. 975 [RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. 976 Xie, "RTP Payload Format and File Storage Format for 977 the Adaptive Multi-Rate (AMR) and Adaptive Multi- 978 Rate Wideband (AMR-WB) Audio Codecs", RFC 4867, 979 April 2007. 981 [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding 982 Dependency in the Session Description Protocol 983 (SDP)", RFC 5583, July 2009. 985 10.2. Informative References 987 [McCanne] McCanne, S., Jacobson, V., and M. Vetterli, 988 "Receiver-driven layered multicast", ACM SIGCOMM 989 Computer Communication Review Volume 26 Issue 4, 990 October 1996. 992 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real 993 Time Streaming Protocol (RTSP)", RFC 2326, 994 April 1998. 996 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 997 Announcement Protocol", RFC 2974, October 2000. 999 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, 1000 L-E., and G. Fairhurst, "The Lightweight User 1001 Datagram Protocol (UDP-Lite)", RFC 3828, July 2004. 1003 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1004 Congestion Control Protocol (DCCP)", RFC 4340, 1005 March 2006. 1007 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", 1008 RFC 5117, January 2008. 1010 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation 1011 of RTP Flows", RFC 6051, November 2010. 1013 Appendix A. Payload Examples 1015 The G.718 payload structure enables flexible transport either by 1016 carrying all layers in the same payload or separating the layers into 1017 separate payloads. The following subsections illustrate different 1018 possibilities for transport by simple examples. Note that examples 1019 do not show the full payload structure to keep the illustration 1020 simple. 1022 A.1. Simple Payload Examples 1024 A.1.1. All The Layers in The Same Payload 1026 The illustration below shows layers L1-L3 from two encoded frames 1027 encapsulated into separate payloads using single transport block. 1029 +-------+--------+-----+------+------+------+ 1030 | RTP1 | L-ID=3 |NF=0 |F1-L1 |F1-L2 |F1-L3 | 1031 +-------+--------+-----+------+------+------+ 1033 +-------+--------+-----+------+------+------+ 1034 | RTP2 | L-ID=3 |NF=0 |F2-L1 |F2-L2 |F2-L3 | 1035 +-------+--------+-----+------+------+------+ 1037 In the case where the same layers from two input frames are 1038 encapsulated into one payload using single transport block, the 1039 structure is as shown below. 1041 +-------+--------+-----+------+------+------+------+------+------+ 1042 | RTP1 | L-ID=3 |NF=1 |F1-L1 |F2-L1 |F1-L2 |F2-L2 |F3-L3 |F2-L3 | 1043 +-------+--------+-----+------+------+------+------+------+------+ 1045 The third example illustrates the case where the layers L1-L3 from 1046 two input frames are encapsulated into one payload using two separate 1047 transport blocks, the first one carrying L1 and the other one 1048 containing L2 and L3. 1050 +-------+--------+-----+------+------+ 1051 | RTP1 | L-ID=1 |NF=1 |F1-L1 |F2-L1 | 1052 +-------+--------+-----+------+------+------+------+ 1053 | L-ID=7 |NF=1 |F1-L2 |F2-L2 |F2-L2 |F2-L3 | 1054 +--------+-----+------+------+------+------+ 1056 A.1.2. Layers in Seperate RTP Streams 1058 In this case the data for each layer is transmitted in its own 1059 payload. 1061 In the first example each transport block including a single EDU is 1062 carried in its own RTP payload. 1064 +-------+--------+-----+-----+ +-------+--------+-----+-----+ 1065 | RTP1a | L-ID=1 |NF=0 |F1-L1| | RTP1b | L-ID=6 |NF=0 |F1-L2| 1066 +-------+--------+-----+-----+ +-------+--------+-----+-----+ 1068 +-------+--------+-----+-----+ +-------+--------+-----+-----+ 1069 | RTP1c |L-ID=10 |NF=0 |F1-L3| | RTP2a | L-ID=1 |NF=0 |F2-L1| 1070 +-------+--------+-----+-----+ +-------+--------+-----+-----+ 1072 +-------+--------+-----+-----+ +-------+--------+-----+-----+ 1073 | RTP2b | L-ID=6 |NF=0 |F2-L2| | RTP2c |L-ID=10 |NF=0 |F2-L3| 1074 +-------+--------+-----+-----+ +-------+--------+-----+-----+ 1076 If the payloads carry data from two consecutive input frames, the 1077 same encoded data as in the previous example is arranged as follows. 1079 +-------+--------+-----+-----+-----+ 1080 | RTP1a | L-ID=1 |NF=1 |F1-L1|F2-L1| 1081 +-------+--------+-----+-----+-----+ 1083 +-------+--------+-----+-----+-----+ 1084 | RTP1b | L-ID=6 |NF=1 |F1-L2|F2-L2| 1085 +-------+--------+-----+-----+-----+ 1087 +-------+--------+-----+-----+-----+ 1088 | RTP1c |L-ID=10 |NF=1 |F1-L3|F2-L3| 1089 +-------+--------+-----+-----+-----+ 1091 A.2. Advanced Examples 1093 A.2.1. Different Update Rate for Subset of Layers 1095 An example employing different update rates (i.e. different number of 1096 frames per packet) for selected subsets of layers. In these examples 1097 all core codec layers L1-L5 are shown. 1099 +-------+--------+-----+-----+-----+-----+-----+ 1100 | RTP1 | L-ID=1 |NF=3 |F1-L1|F2-L1|F3-L1|F4-L1| 1101 +-------+--------+-----+-----+-----+-----+-----+ 1103 +-------+--------+-----+-----+-----+-----+-----+ 1104 | RTP2a | L-ID=7 |NF=1 |F1-L2|F2-L2|F1-L3|F2-L3| 1105 +-------+--------+-----+-----+-----+-----+-----+ 1107 +-------+--------+-----+-----+-----+ 1108 | RTP3a |L-ID=14 |NF=0 |F1-L4|F1-L5| 1109 +-------+--------+-----+-----+-----+ 1111 +-------+--------+-----+-----+-----+ 1112 | RTP3b |L-ID=14 |NF=0 |F2-L4|F2-L5| 1113 +-------+--------+-----+-----+-----+ 1115 +-------+--------+-----+-----+-----+-----+-----+ 1116 | RTP2b | L-ID=7 |NF=1 |F3-L2|F4-L2|F3-L3|F4-L3| 1117 +-------+--------+-----+-----+-----+-----+-----+ 1119 +-------+--------+-----+-----+-----+ 1120 | RTP3c |L-ID=14 |NF=0 |F3-L4|F3-L5| 1121 +-------+--------+-----+-----+-----+ 1123 +-------+--------+-----+-----+-----+ 1124 | RTP3d |L-ID=14 |NF=0 |F4-L4|F4-L5| 1125 +-------+--------+-----+-----+-----+ 1127 A.2.2. Redundant Frames With Limited Set of Layers 1129 An example transmitting layers L1-L3 as primary data and L1 (of the 1130 previous frame) as redundant data is shown below. Each payload 1131 carries one primary (i.e. new) frame in one transport block and one 1132 redundant frame, which in this example is the frame preceding the 1133 primary frame, in another transport block. 1135 +-------+--------+-----+-----+--------+-----+-----+-----+-----+ 1136 | RTP1 | L-ID=1 |NF=0 |F0-L1| L-ID=3 |NF=0 |F1-L1|F1-L2|F1-L3| 1137 +-------+--------+-----+-----+--------+-----+-----+-----+-----+ 1139 +-------+--------+-----+-----+--------+-----+-----+-----+-----+ 1140 | RTP2 | L-ID=1 |NF=0 |F1-L1| L-ID=3 |NF=0 |F2-L1|F2-L2|F2-L3| 1141 +-------+--------+-----+-----+--------+-----+-----+-----+-----+ 1143 +-------+--------+-----+-----+--------+-----+-----+-----+-----+ 1144 | RTP3 | L-ID=1 |NF=0 |F2-L1| L-ID=3 |NF=0 |F3-L1|F3-L2|F3-L3| 1145 +-------+--------+-----+-----+--------+-----+-----+-----+-----+ 1147 Alternatively, the payload carrying also redundant data for a subset 1148 of layers can be arranged differently, as shown in the example below. 1150 +-------+--------+-----+-----+-----+-----+--------+-----+-----+ 1151 | RTP1 | L-ID=3 |NF=0 |F0-L1|F0-L2|F0-L3| L-ID=1 |NF=0 |F1-L1| 1152 +-------+--------+-----+-----+-----+-----+--------+-----+-----+ 1154 +-------+--------+-----+-----+-----+-----+--------+-----+-----+ 1155 | RTP2 | L-ID=3 |NF=0 |F1-L1|F1-L2|F1-L3| L-ID=1 |NF=0 |F2-L1| 1156 +-------+--------+-----+-----+-----+-----+--------+-----+-----+ 1158 +-------+--------+-----+-----+-----+-----+--------+-----+-----+ 1159 | RTP3 | L-ID=3 |NF=0 |F2-L1|F2-L2|F2-L3| L-ID=1 |NF=0 |F3-L1| 1160 +-------+--------+-----+-----+-----+-----+--------+-----+-----+ 1162 Now the first transport block carries the primary data and the second 1163 transport block carries the redundant data, which in this case covers 1164 the frame following the primary frame. The benefit of this approach 1165 is that the redundant data is included in the last (secondary) 1166 transport block of the payload, which might be beneficial for 1167 possible payload scaling operation within the network. 1169 Authors' Addresses 1171 Glen Zorn (editor) 1172 Network Zen 1173 227/358 Thanon Sanphawut 1174 Bang Na, Bangkok 10260 1175 Thailand 1177 Phone: +66 (0) 87-040-4617 1178 EMail: glenzorn@gmail.com 1180 Ye-Kui Wang 1181 Qualcomm Incorporated 1182 5775 Morehouse Drive 1183 San Diego, CA 92121 1184 USA 1186 Phone: +1-858-651-8345 1187 EMail: yekuiw@qualcomm.com 1189 Ari Lakaniemi 1190 Independent Contributor 1192 EMail: ari.lakaniemi@hotmail.com