idnits 2.17.1 draft-wang-avt-rtp-gsm-hr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 538. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 545. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 551. 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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 18, 2008) is 5910 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) ** Obsolete normative reference: RFC 4566 (ref. '3') (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4288 (ref. '4') (Obsoleted by RFC 6838) -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 AVT Working Group Shuaiyu Wang 2 Internet Draft Xiaodong Duan 3 Intended status: Standards Track China Mobile 4 Expires: August 18 2008 Rocky Wang 5 Ying Zhang 6 Huawei 7 February 18, 2008 9 RTP Payload Format for GSM-HR Speech Codecs 10 draft-wang-avt-rtp-gsm-hr-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on August 17 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document registers a media type for the Real-time Transport 43 protocol (RTP) payload format, which is used for the Group Special 44 Mobile half-rate speech transcoding. 46 Table of Contents 48 1. Introduction................................................2 49 1.1. Terminology............................................2 50 2. Background for GSM HR Speech codes over RTP..................3 51 2.1. GSM HR Codes...........................................3 52 2.2. A interface over IP.....................................3 53 2.3. GSM HR Speech codes over IP Scenarios...................5 54 3. GSM HR codes RTP Payload Formats.............................6 55 3.1. Payload Structure.......................................6 56 3.2. Registration of Media Type GSM-HR.......................9 57 4. Mapping MIME Parameters into SDP............................10 58 5. Security Considerations.....................................11 59 6. IANA Considerations........................................11 60 7. References.................................................12 61 7.1. Normative References...................................12 62 Author's Addresses............................................12 63 Intellectual Property Statement................................13 64 Disclaimer of Validity........................................13 66 1. Introduction 68 Global System for Mobile Communication (GSM) network has been widely 69 deployed in the last several years to provide mobile communication 70 services. GSM half rate codec (GSM-HR) is one of the compressed 71 speech codecs which are used for the basic speech service in the GSM 72 mobile networks. 74 GSM-HR denotes GSM 06.20 half-rate speech transcoding, specified in 75 ETS 300 969 which is available from ETSI at the address given in RFC 76 3551 [1] Section 4.5.8. This codec has a frame length of 112 bits. 77 For transmission in RTP, each codec frame is packed into a 14 78 octet(112 bit). The packing is specified in ETSI Technical 79 Specification TS 101 318. 81 This document registers a media type for the Real-time Transport 82 protocol (RTP) payload format for the GSM-HR codec to enabling the 83 use of the codec in the Voice over IP (VoIP) application. 85 1.1. Terminology 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC-2119 [2]. 91 2. Background for GSM HR Speech codes over RTP 93 2.1. GSM HR Codes 95 As defined in the GSM standard, the GSM physical layer is presented 96 as a combination of FDMA and TDMA. Based on the frequency division 97 principle, the entire GSM band is divided into several 200-KHz 98 channels which named as absolute radio frequency channel number in 99 the Standard (ARFCN for short). Each channel is divided into 8 100 timeslots according to the time division principle. Hence, a GSM 101 physical channel in fact corresponds to one timeslot on a certain 102 channel. 104 Timeslots are repeated according to specific disciplinarian, bringing 105 the concepts of frames and multi-frames. In GSM Standard, the 106 channels bearing voice and data services are repeated in a period of 107 26 frames. In words, the TDMA multiframe of a traffic channel (TCH) 108 consists of 26 frames, with the duration of 120 ms. 110 Among the 26 frames on a full rate speech channel (TCH/FS) or an 111 enhanced full rate speech channel (TCH/EFS), 24 are used to bear 112 speech data, one (Frame 13) to transmit the channel associated 113 signaling on a slow associated control channel (SACCH), and one 114 (Frame 26) is idle. 116 When the system adopts half rate speech channel (TCH/HS), no change 117 will bring to the multi-frame structure of the air interface. In this 118 case, the odd frames in the multi-frame are allocated to one user and 119 even frames to another, while the original Frame 13 serves as the 120 SACCH of the first user and the idle Frame 26 as the SACCH of the 121 second user. In this way, a channel previously only capable of 122 bearing one TCH/FS or TCH/EFS can now bear two TCH/HSs. The capacity 123 of the channel doubles the original. 125 2.2. A interface over IP 127 A interface is the interface between MSC and BSC. 129 +----------+ +----------+ 130 | | A interface | | 131 | BSC |<----------------------->| MSC | 132 | | TDM | | 133 +----------+ +----------+ 135 Figure 1 A interface (Legacy network). 137 According to the existing protocol, the A interface user plane is 138 only based on TDM. A interface over IP is a technique trend in 139 wireless network evolution, which can construct high bandwidth, high 140 efficiency and low cost basic networks. For A interface over IP, 141 control plane signalling over IP (SIGTRAN) has been introduced in 142 3GPP Release 7 while certain features (e.g. MSC in Pool and Layered 143 Architecture) require an intermediate signalling network for best 144 performance. In order to take full advantage of IP based technologies 145 the protocols of A interface user plane should be adapted for IP 146 based transport. 148 A interface over IP can also simplify the implementation of MSCs in a 149 pool. Furthermore, UTRAN network and more advanced RAN can use a 150 common IP backhaul with GERAN. One of the main advantages of having 151 IP based A-interface for the user plane is a much more flexible 152 network design between the BSS and the CS core. 154 IP hardware in the nodes and IP site and backbone infrastructure can 155 be shared by the A-interface control plane and the user plane. A 156 separation of the signaling network from the user plane can be 157 achieved by using technologies like VLAN tagging, virtual routing etc. 158 This will allow the operator to abolish TDM hardware and TDM 159 infrastructure and by that reduce OPEX and CAPEX. 161 Further on in most of the current networks, both BSS and CN have 162 transcoding functionality, i.e. Transcoder in BSS and Media Gateway 163 (MGW) in CN. Some core networks have been upgraded to convey 164 compressed speech over IP transport. In this case, removing TC from 165 BSS and transfer compressed speech over A interface will reduce cost 166 of transcoder device, reduce cost of transport resource and improve 167 voice quality by implementing TrFO. 169 +----------+ +----------+ 170 | | A interface | | 171 | BSC |<----------------------->| MSC | 172 | | TDM | | 173 +----------+ +----------+ 174 +-------------+ +----------+ 175 | | A interface | | 176 | BSC |<----------------------->| MGW | 177 | (with TC or | IP | with TC | 178 | without TC | | | 179 +-------------+ +----------+ 181 Figure 2 Architecture for A interface over IP. 183 2.3. GSM HR Speech codes over IP Scenarios 185 There is an enormous amount of transcoder resources installed in 186 today's GSM radio networks. Therefore the "final solution" in the 187 standard shall be flexible and allow the use of transcoders placed in 188 the BSS and/or in the CS Core Network. In addition, e.g. for the 189 purpose of migrating the A interface from a TDM to an IP interface, 190 both TDM and IP based A interface should be supported concurrently, 191 at least for the migration phase. 193 Target solution, the solution yields to align the 2G network 194 architecture with the 3G CS core network architecture, deviates from 195 the current BSS architecture, where today transcoders are 196 functionally integrated into the BSS. Allowing placing transcoders in 197 the CS core network will impacts the functional division between Base 198 Station System (BSS) and Core Network. This solution allows carrying 199 compressed speech in an efficient way across the A-interface. In 200 contrast to TFO the compressed speech is formatted directly and there 201 is no PCM stream in parallel. This will reduce the overall need for 202 transcoders in the solution and it will improve the end-to-end delay. 203 But it will require additional transcoder resources (e.g. for 204 transcoding in all Mobile-to-PSTN calls) and possibly new transcoder 205 types (e.g. GSM_HR) within the Core Network. 207 In this case, GSM-HR needs to be transferred over IP based A 208 interface if GSM-HR is applied in the air interface. 210 +-------------+ +----------+ 211 | | A interface over IP | | 212 | BSC |<----------------------->| MGW | 213 | without TC | GSM-HR | with TC | 214 | | | | 215 +-------------+ +----------+ 217 Figure 3 Deployment Scenario: compressed speech(such as GSM-HR) is 218 transferred over IP based A interface. 220 3. GSM HR codes RTP Payload Formats 222 3.1. Payload Structure 224 The GSM half rate codec has frame length of 112 bits. Every frame 225 is encoded into one 14 octet (112 bit) buffer. There shall be no 226 signature. 228 The complete payload consists of a payload header, a payload 229 table of contents, and speech data representing one or more 230 speech frame-blocks. The following diagram shows the general 231 payload format layout: 233 +----------------+-------------------+---------------- 235 | payload header | table of contents | speech data ... 237 +----------------+-------------------+---------------- 239 Figure 4 payload structure. 241 The bits in RTP buffer are numbered from r1 (the most significant 242 bit of first octet) to r112 (the least significant bit of last 243 octet). Within the GSM 06.20 codec parameter bits are numbered in 244 big-endian manner. 246 1 Encoding of speech frames 248 There are two alternative formats of a ETS 300 969 [6] speech 249 frames. The first form is for codec mode 0 (unvoiced speech), the 250 second form is for modes 1, 2 and 3 (voiced speech). 252 Parameter No. of bits Bit No.(MSB-LSB) 254 ------------------------------------------------- 256 R0 5 r1 - r5 258 LPC1 11 r6 - r16 260 LPC2 9 r17 - r25 262 LPC3 8 r26 - r33 263 INT_LPC 1 r34 265 MODE 2 r35 - r36 267 CODE1_1 7 r37 - r43 269 CODE2_1 7 r44 - r50 271 GSP0_1 5 r51 - r55 273 CODE1_2 7 r56 - r62 275 CODE2_2 7 r63 - r69 277 GSP0_2 5 r70 - r74 279 CODE1_3 7 r75 - r81 281 CODE2_3 7 r82 - r88 283 GSP0_3 5 r89 - r93 285 CODE1_4 7 r94 - r100 287 CODE2_4 7 r101 - r107 289 GSP0_4 5 r108 - r112 291 Table 1: The order of GSM 06.20 half rate speech codec parameters 292 in RTP buffer (MODE=0) 294 Parameter No. of bits Bit No.(MSB-LSB) 296 ------------------------------------------------- 298 R0 5 r1 - r5 300 LPC1 11 r6 - r16 302 LPC2 9 r17 - r25 304 LPC3 8 r26 - r33 305 INT_LPC 1 r34 307 MODE 2 r35 - r36 309 LAG_1 8 r37 - r44 311 CODE1 9 r45 - r53 313 GSP0_1 5 r54 - r58 315 LAG_2 4 r59 - r62 317 CODE2 9 r63 - r71 319 GSP0_2 5 r72 - r76 321 LAG_3 4 r77 - r80 323 CODE3 9 r81 - r89 325 GSP0_3 5 r90 - r94 327 LAG_4 4 r95 - r98 329 CODE4 9 r99 - r107 331 GSP0_4 5 r108 - r112 333 Table 2: The order of GSM 06.20 half rate speech codec parameters 334 in RTP buffer (MODE=1, 2 or 3) 336 2 Encoding of silence indication frames 338 The half-rate codec SID frame is encoded according to the ETS 300 339 971 [7]. 341 A SID frame is identified by a SID codeword consisting of 79 bits 342 which are all 1. The parameters in table 3 have to be set as 343 shown in order to mark a frame as a SID frame. 345 Parameter No. of bits Value (Hex) 347 ------------------------------------------------- 349 INT_LPC 1 116 350 MODE 2 316 352 LAG_1 8 FF16 354 CODE1 9 1FF16 356 GSP0_1 5 1F16 358 LAG_2 4 F16 360 CODE2 9 1FF16 362 GSP0_2 5 1F16 364 LAG_3 4 F16 366 CODE3 9 1FF16 368 GSP0_3 5 1F16 370 LAG_4 9 1FF16 372 GSP0_4 5 1F16 374 Table 3: SID codeword for half rate speech codec 376 3.2. Registration of Media Type GSM-HR 378 Type name: audio 380 Subtype name: GSM-HR 382 Required parameters: none 384 Optional parameters: 386 ptime: the recommended length of time (in milliseconds) 387 represented by the media in a packet and the default value is20 388 milliseconds. See Section 6 of RFC 4566 [3]. 390 Encoding considerations: 392 This media type is framed binary data (see Section 4.8 in RFC4288 393 [4]). 395 Security consideration: 397 This media type does not carry active content. It does transfer 398 compressed data. 400 Interoperability considerations: none 402 Published specification: RFC XXXX 404 Applications that use this media type: 406 Audio and video streaming and conferencing tools 408 Additional information: none 410 Person & email address to contact for further information: 412 Xiaodong Duan duanxiaodong@chinamobile.com 414 Intended usage: COMMON 416 Restrictions on usage: 418 This media type depends on RTP framing, and hence is only defined 419 for transfer via RTP (RFC 3550 [5]). Transfer within other 420 framing protocols is not defined at this time. 422 Author: 424 Xiaodong Duan duanxiaodong@chinamobile.com 426 Shuaiyu Wang wangshuaiyu@chinamobile.com 428 Change controller: 430 IETF Audio/Video Transport working group delegated from the IESG. 432 4. Mapping MIME Parameters into SDP 434 The information carried in the MIME media type specification has a 435 specific mapping to fields in the Session Description Protocol (SDP) 436 [3], which is commonly used to describe RTP sessions. When SDP is 437 used to specify sessions employing the compact bundled format for GSM 438 half-rate speech, the mapping is as follows: 440 The MIME type ("audio") goes in SDP "m=" as the media name. 442 The MIME subtype ("GSM-HR") goes in SDP "a=rtpmap" as the 443 encoding name and the sampling rate for the GSM-HR codec is 8 KHz. 445 The optional parameters "ptime" goes in the SDP "a=ptime" 446 attributes, respectively. 448 The payload type payload type value for GSM-HR is created dynamically 449 and is used in the PT field of the RTP data header. 451 5. Security Considerations 453 RTP packets using the GSM-HR payload format are subject to the 454 security considerations discussed in the RTP specification [5]. 456 A potential denial-of-service threat exists for data encodings using 457 compression techniques that have non-uniform receiver-end 458 computational load. The attacker can inject pathological datagrams 459 into the stream which are complex to decode and cause the receiver to 460 be overloaded. However, this encoding does not exhibit 461 anysignificant non-uniformity. 463 As with any IP-based protocol, in some circumstances a receiver may 464 be overloaded simply by the receipt of too many packets, either 465 desired or undesired. Network-layer authentication MAY be used to 466 discard packets from undesired sources, but the processing cost of 467 the authentication itself may be too high. 469 6. IANA Considerations 471 It is requested that one new media subtype (audio/GSM-HR) is 472 registered by IANA. For details, see Section 2. 474 7. References 476 7.1. Normative References 478 [1] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 479 Conferences with Minimal Control", RFC 3551, July 2003. 481 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 482 Levels", BCP 14, RFC 2119, March 1997. 484 [3] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 485 Description Protocol", RFC 4566, July 2006. 487 [4] Freed, N. and J. Klensin, " Media Type Specifications and 488 Registration Procedures", BCP 13, RFC 4288, December 2005. 490 [5] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 491 "RTP: A Transport Protocol for Real-Time Applications", RFC 492 3550, July 2003. 494 [6] ETS 300 969: "Digital cellular telecommunications system (Phase 495 2+); Half rate speech; Half rate speech transcoding (GSM 496 06.20)". 498 [7] ETS 300 971: "Digital cellular telecommunications system; Half 499 rate speech; Comfort noise aspects for the half rate speech 500 traffic channels (GSM 06.22)". 502 Author's Addresses 504 Xiaodong Duan 505 China Mobile Communications Corporation 506 53A, Xibianmennei Ave., Xuanwu District 507 Beijing, 100053 P.R. China 508 Email: 510 Shuaiyu Wang 511 China Mobile Communications Corporation 512 53A, Xibianmennei Ave., Xuanwu District 513 Beijing, 100053 P.R. China 514 Email: 515 Rocky Wang 516 Huawei Technologies 517 Xibianmennei AveHuawei Industrial Base, Bantian Longgang 518 Shenzhen, Guangdong Province 518129, P.R.China 520 Email: 522 Ying Zhang 523 Huawei Technologies 524 Huawei Industrial Base, Bantian Longgang 525 Shenzhen, Guangdong Province 518129, P.R.China 527 Email: 529 Intellectual Property Statement 531 The IETF takes no position regarding the validity or scope of any 532 Intellectual Property Rights or other rights that might be claimed to 533 pertain to the implementation or use of the technology described in 534 this document or the extent to which any license under such rights 535 might or might not be available; nor does it represent that it has 536 made any independent effort to identify any such rights. Information 537 on the procedures with respect to rights in RFC documents can be 538 found in BCP 78 and BCP 79. 540 Copies of IPR disclosures made to the IETF Secretariat and any 541 assurances of licenses to be made available, or the result of an 542 attempt made to obtain a general license or permission for the use of 543 such proprietary rights by implementers or users of this 544 specification can be obtained from the IETF on-line IPR repository at 545 http://www.ietf.org/ipr. 547 The IETF invites any interested party to bring to its attention any 548 copyrights, patents or patent applications, or other proprietary 549 rights that may cover technology that may be required to implement 550 this standard. Please address the information to the IETF at 551 ietf-ipr@ietf.org. 553 Disclaimer of Validity 555 This document and the information contained herein are provided on an 556 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 557 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 558 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 559 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 560 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 561 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 563 Copyright Statement 565 Copyright (C) The IETF Trust (2008). 567 This document is subject to the rights, licenses and restrictions 568 contained in BCP 78, and except as set forth therein, the authors 569 retain all their rights. 571 Acknowledgment 573 Funding for the RFC Editor function is currently provided by the 574 Internet Society.