GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5993

Internet Engineering Task Force (IETF) X. Duan Request for Comments: 5993 S. Wang Category: Standards Track China Mobile Communications Corporation ISSN: 2070-1721 M. Westerlund

                                                            K. Hellwig
                                                          I. Johansson
                                                           Ericsson AB
                                                          October 2010
                       RTP Payload Format for
     Global System for Mobile Communications Half Rate (GSM-HR)

Abstract

 This document specifies the payload format for packetization of
 Global System for Mobile Communications Half Rate (GSM-HR) speech
 codec data into the Real-time Transport Protocol (RTP).  The payload
 format supports transmission of multiple frames per payload and
 packet loss robustness methods using redundancy.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc5993.

Duan, et al. Standards Track [Page 1] RFC 5993 RTP Payload Format for GSM-HR October 2010

Copyright Notice

 Copyright (c) 2010 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
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
 2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
 3.  GSM Half Rate  . . . . . . . . . . . . . . . . . . . . . . . .  3
 4.  Payload Format Capabilities  . . . . . . . . . . . . . . . . .  4
   4.1.  Use of Forward Error Correction (FEC)  . . . . . . . . . .  4
 5.  Payload Format . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.1.  RTP Header Usage . . . . . . . . . . . . . . . . . . . . .  6
   5.2.  Payload Structure  . . . . . . . . . . . . . . . . . . . .  6
     5.2.1.  Encoding of Speech Frames  . . . . . . . . . . . . . .  8
     5.2.2.  Encoding of Silence Description Frames . . . . . . . .  8
   5.3.  Implementation Considerations  . . . . . . . . . . . . . .  8
     5.3.1.  Transmission of SID Frames . . . . . . . . . . . . . .  8
     5.3.2.  Receiving Redundant Frames . . . . . . . . . . . . . .  8
     5.3.3.  Decoding Validation  . . . . . . . . . . . . . . . . .  9
 6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   6.1.  3 Frames . . . . . . . . . . . . . . . . . . . . . . . . . 10
   6.2.  3 Frames with Lost Frame in the Middle . . . . . . . . . . 11
 7.  Payload Format Parameters  . . . . . . . . . . . . . . . . . . 11
   7.1.  Media Type Definition  . . . . . . . . . . . . . . . . . . 12
   7.2.  Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . 13
     7.2.1.  Offer/Answer Considerations  . . . . . . . . . . . . . 14
     7.2.2.  Declarative SDP Considerations . . . . . . . . . . . . 14
 8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
 9.  Congestion Control . . . . . . . . . . . . . . . . . . . . . . 15
 10. Security Considerations  . . . . . . . . . . . . . . . . . . . 15
 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
   12.2. Informative References . . . . . . . . . . . . . . . . . . 17

Duan, et al. Standards Track [Page 2] RFC 5993 RTP Payload Format for GSM-HR October 2010

1. Introduction

 This document specifies the payload format for packetization of GSM
 Half Rate (GSM-HR) codec [TS46.002] encoded speech signals into the
 Real-time Transport Protocol (RTP) [RFC3550].  The payload format
 supports transmission of multiple frames per payload and packet loss
 robustness methods using redundancy.
 This document starts with conventions, a brief description of the
 codec, and payload format capabilities.  The payload format is
 specified in Section 5.  Examples can be found in Section 6.  The
 media type specification and its mappings to SDP, and considerations
 when using the Session Description Protocol (SDP) offer/answer
 procedures are then specified.  The document ends with considerations
 related to congestion control and security.
 This document registers a media type (audio/GSM-HR-08) for the Real-
 time Transport Protocol (RTP) payload format for the GSM-HR codec.
 Note: This format is not compatible with the one provided back in
 1999 to 2000 in early draft versions of what was later published as
 RFC 3551.  RFC 3551 was based on a later version of the Audio-Visual
 Profile (AVP) draft, which did not provide any specification of the
 GSM-HR payload format.  To avoid a possible conflict with this older
 format, the media type of the payload format specified in this
 document has a media type name that is different from (audio/GSM-HR).

2. Conventions Used in This Document

 This document uses the normal IETF bit-order representation.  Bit
 fields in figures are read left to right and then down.  The leftmost
 bit in each field is the most significant.  The numbering starts from
 0 and ascends, where bit 0 will be the most significant.
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC 2119 [RFC2119].

3. GSM Half Rate

 The Global System for Mobile Communications (GSM) network provides
 with mobile communication services for nearly 3 billion users
 (statistics as of 2008).  The GSM Half Rate (GSM-HR) codec is one of
 the speech codecs used in GSM networks.  GSM-HR denotes the Half Rate
 speech codec as specified in [TS46.002].
 Note: For historical reasons, these 46-series specifications are
 internally referenced as 06-series.  A simple mapping applies; for
 example, 46.020 is referenced as 06.20, and so on.

Duan, et al. Standards Track [Page 3] RFC 5993 RTP Payload Format for GSM-HR October 2010

 The GSM-HR codec has a frame length of 20 ms, with narrowband speech
 sampled at 8000 Hz, i.e., 160 samples per frame.  Each speech frame
 is compressed into 112 bits of speech parameters, which is equivalent
 to a bit rate of 5.6 kbit/s.  Speech pauses are detected by a
 standardized Voice Activity Detection (VAD).  During speech pauses,
 the transmission of speech frames is inhibited.  Silence Descriptor
 (SID) frames are transmitted at the end of a talkspurt and about
 every 480 ms during speech pauses to allow for a decent comfort noise
 (CN) quality on the receiver side.
 The SID frame generation in the GSM radio network is determined by
 the GSM mobile station and the GSM radio subsystem.  SID frames come
 during speech pauses in the uplink from the mobile station about
 every 480 ms.  In the downlink to the mobile station, when they are
 generated by the encoder of the GSM radio subsystem, SID frames are
 sent every 20 ms to the GSM base station, which then picks only one
 every 480 ms for downlink radio transmission.  For other
 applications, like transport over IP, it is more appropriate to send
 the SID frames less often than every 20 ms, but 480 ms may be too
 sparse.  We recommend as a compromise that a GSM-HR encoder outside
 of the GSM radio network (i.e., not in the GSM mobile station and not
 in the GSM radio subsystem, but, for example, in the media gateway of
 the core network) should generate and send SID frames every 160 ms.

4. Payload Format Capabilities

 This RTP payload format carries one or more GSM-HR encoded frames --
 either full voice or silence descriptor (SID) -- representing a mono
 speech signal.  To maintain synchronization or to indicate unsent or
 lost frames, it has the capability to indicate No_Data frames.

4.1. Use of Forward Error Correction (FEC)

 Generic forward error correction within RTP is defined, for example,
 in RFC 5109 [RFC5109].  Audio redundancy coding is defined in RFC
 2198 [RFC2198].  Either scheme can be used to add redundant
 information to the RTP packet stream and make it more resilient to
 packet losses, at the expense of a higher bit rate.  Please see
 either RFC for a discussion of the implications of the higher bit
 rate to network congestion.
 In addition to these media-unaware mechanisms, this memo specifies an
 optional-to-use GSM-HR-specific form of audio redundancy coding,
 which may be beneficial in terms of packetization overhead.
 Conceptually, previously transmitted transport frames are aggregated
 together with new ones.  A sliding window can be used to group the
 frames to be sent in each payload.  Figure 1 below shows an example.

Duan, et al. Standards Track [Page 4] RFC 5993 RTP Payload Format for GSM-HR October 2010

  1. -+——–+——–+——–+——–+——–+——–+——–+–

| f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) |

  1. -+——–+——–+——–+——–+——–+——–+——–+–
    <---- p(n-1) ---->
             <----- p(n) ----->
                      <---- p(n+1) ---->
                               <---- p(n+2) ---->
                                        <---- p(n+3) ---->
                                                 <---- p(n+4) ---->
            Figure 1: An Example of Redundant Transmission
 Here, each frame is retransmitted once in the following RTP payload
 packet. f(n-2)...f(n+4) denote a sequence of audio frames, and
 p(n-1)...p(n+4) a sequence of payload packets.
 The mechanism described does not really require signaling at the
 session setup.  However, signaling has been defined to allow the
 sender to voluntarily bound the buffering and delay requirements.  If
 nothing is signaled, the use of this mechanism is allowed and
 unbounded.  For a certain timestamp, the receiver may acquire
 multiple copies of a frame containing encoded audio data.  The cost
 of this scheme is bandwidth, and the receiver delay is necessary to
 allow the redundant copy to arrive.
 This redundancy scheme provides a functionality similar to the one
 described in RFC 2198, but it works only if both original frames and
 redundant representations are GSM-HR frames.  When the use of other
 media coding schemes is desirable, one has to resort to RFC 2198.
 The sender is responsible for selecting an appropriate amount of
 redundancy, based on feedback regarding the channel conditions, e.g.,
 in the RTP Control Protocol (RTCP) [RFC3550] receiver reports.  The
 sender is also responsible for avoiding congestion, which may be
 exacerbated by redundancy (see Section 9 for more details).

5. Payload Format

 The format of the RTP header is specified in [RFC3550].  The payload
 format described in this document uses the header fields in a manner
 consistent with that specification.
 The duration of one speech frame is 20 ms.  The sampling frequency is
 8000 Hz, corresponding to 160 speech samples per frame.  An RTP
 packet may contain multiple frames of encoded speech or SID
 parameters.  Each packet covers a period of one or more contiguous

Duan, et al. Standards Track [Page 5] RFC 5993 RTP Payload Format for GSM-HR October 2010

 20-ms frame intervals.  During silence periods, no speech packets are
 sent; however, SID packets are transmitted every now and then.
 To allow for error resiliency through redundant transmission, the
 periods covered by multiple packets MAY overlap in time.  A receiver
 MUST be prepared to receive any speech frame multiple times.  A given
 frame MUST NOT be encoded as a speech frame in one packet and as a
 SID frame or as a No_Data frame in another packet.  Furthermore, a
 given frame MUST NOT be encoded with different voicing modes in
 different packets.
 The rules regarding maximum payload size given in Section 3.2 of
 [RFC5405] SHOULD be followed.

5.1. RTP Header Usage

 The RTP timestamp corresponds to the sampling instant of the first
 sample encoded for the first frame in the packet.  The timestamp
 clock frequency SHALL be 8000 Hz.  The timestamp is also used to
 recover the correct decoding order of the frames.
 The RTP header marker bit (M) SHALL be set to 1 whenever the first
 frame carried in the packet is the first frame in a talkspurt (see
 definition of the talkspurt in Section 4.1 of [RFC3551]).  For all
 other packets, the marker bit SHALL be set to zero (M=0).
 The assignment of an RTP payload type for the format defined in this
 memo is outside the scope of this document.  The RTP profiles in use
 currently mandate binding the payload type dynamically for this
 payload format.
 The remaining RTP header fields are used as specified in RFC 3550
 [RFC3550].

5.2. Payload Structure

 The complete payload consists of a payload table of contents (ToC)
 section, followed by speech data representing one or more speech
 frames, SID frames, or No_Data frames.  The following diagram shows
 the general payload format layout:
    +-------------+-------------------------
    | ToC section | speech data section ...
    +-------------+-------------------------
    Figure 2: General Payload Format Layout

Duan, et al. Standards Track [Page 6] RFC 5993 RTP Payload Format for GSM-HR October 2010

 Each ToC element is one octet and corresponds to one speech frame;
 the number of ToC elements is thus equal to the number of speech
 frames (including SID frames and No_Data frames).  Each ToC entry
 represents a consecutive speech or SID or No_Data frame.  The
 timestamp value for ToC element (and corresponding speech frame data)
 N within the payload is (RTP timestamp field + (N-1)*160) mod 2^32.
 The format of the ToC element is as follows.
     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |F| FT  |R R R R|
    +-+-+-+-+-+-+-+-+
 Figure 3: The TOC Element
 F: Follow flag; 1 denotes that more ToC elements follow; 0 denotes
    the last ToC element.
 R: Reserved bits; MUST be set to zero, and MUST be ignored by
    receiver.
 FT:  Frame type
    000 = Good Speech frame
    001 = Reserved
    010 = Good SID frame
    011 = Reserved
    100 = Reserved
    101 = Reserved
    110 = Reserved
    111 = No_Data frame
 The length of the payload data depends on the frame type:
 Good Speech frame:   The 112 speech data bits are put in 14 octets.
 Good SID frame:   The 33 SID data bits are put in 14 octets, as in
    the case of Speech frames, with the unused 79 bits all set to "1".
 No_Data frame:   Length of payload data is zero octets.
 Frames marked in the GSM radio subsystem as "Bad Speech frame", "Bad
 SID frame", or "No_Data frame" are not sent in RTP packets, in order
 to save bandwidth.  They are marked as "No_Data frame", if they occur
 within an RTP packet that carries more than one speech frame, SID
 frame, or No_Data frame.

Duan, et al. Standards Track [Page 7] RFC 5993 RTP Payload Format for GSM-HR October 2010

5.2.1. Encoding of Speech Frames

 The 112 bits of GSM-HR-coded speech (b1...b112) are defined in TS
 46.020, Annex B [TS46.020], in their order of occurrence.  The first
 bit (b1) of the first parameter is placed in the most significant bit
 (MSB) (bit 0) of the first octet (octet 1) of the payload field; the
 second bit is placed in bit 1 of the first octet; and so on.  The
 last bit (b112) is placed in the least significant bit (LSB) (bit 7)
 of octet 14.

5.2.2. Encoding of Silence Description Frames

 The GSM-HR codec applies a specific coding for silence periods in so-
 called SID frames.  The coding of SID frames is based on the coding
 of speech frames by using only the first 33 bits for SID parameters
 and by setting all of the remaining 79 bits to "1".

5.3. Implementation Considerations

 An application implementing this payload format MUST understand all
 the payload parameters that are defined in this specification.  Any
 mapping of the parameters to a signaling protocol MUST support all
 parameters.  So an implementation of this payload format in an
 application using SDP is required to understand all the payload
 parameters in their SDP-mapped form.  This requirement ensures that
 an implementation always can decide whether it is capable of
 communicating when the communicating entities support this version of
 the specification.

5.3.1. Transmission of SID Frames

 When using this RTP payload format, the sender SHOULD generate and
 send SID frames every 160 ms, i.e., every 8th frame, during silent
 periods.  Other SID transmission intervals may occur due to gateways
 to other systems that use other transmission intervals.

5.3.2. Receiving Redundant Frames

 The reception of redundant audio frames, i.e., more than one audio
 frame from the same source for the same time slot, MUST be supported
 by the implementation.

Duan, et al. Standards Track [Page 8] RFC 5993 RTP Payload Format for GSM-HR October 2010

5.3.3. Decoding Validation

 If the receiver finds a mismatch between the size of a received
 payload and the size indicated by the ToC of the payload, the
 receiver SHOULD discard the packet.  This is recommended, because
 decoding a frame parsed from a payload based on erroneous ToC data
 could severely degrade the audio quality.

Duan, et al. Standards Track [Page 9] RFC 5993 RTP Payload Format for GSM-HR October 2010

6. Examples

 A few examples below highlight the payload format.

6.1. 3 Frames

 Below is a basic example of the aggregation of 3 consecutive speech
 frames into a single packet.
    The first 24 bits are ToC elements.
    Bit 0 is '1', as another ToC element follows.
    Bits 1..3 are 000 = Good speech frame
    Bits 4..7 are 0000 = Reserved
    Bit 8 is '1', as another ToC element follows.
    Bits 9..11 are 000 = Good speech frame
    Bits 12..15 are 0000 = Reserved
    Bit 16 is '0'; no more ToC elements follow.
    Bits 17..19 are 000 = Good speech frame
    Bits 20..23 are 0000 = Reserved
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|0 0 0|0 0 0 0|1|0 0 0|0 0 0 0|0|0 0 0|0 0 0 0|b1           b8|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
    |b9   Frame 1                                                b40|
    +                                                               +
    |b41                                                         b72|
    +                                                               +
    |b73                                                        b104|
    +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |b105       b112|b1                                          b24|
    +-+-+-+-+-+-+-+-+                                               +
    |b25  Frame 2                                                b56|
    +                                                               +
    |b57                                                         b88|
    +                                               +-+-+-+-+-+-+-+-+
    |b89                                        b112|b1           b8|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
    |b9   Frame 3                                                b40|
    +                                                               +
    |b41                                                         b72|
    +                                                               +
    |b73                                                        b104|
    +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |b105       b112|
    +-+-+-+-+-+-+-+-+

Duan, et al. Standards Track [Page 10] RFC 5993 RTP Payload Format for GSM-HR October 2010

6.2. 3 Frames with Lost Frame in the Middle

 Below is an example of a payload carrying 3 frames, where the middle
 one is No_Data (for example, due to loss prior to transmission by the
 RTP source).
    The first 24 bits are ToC elements.
    Bit 0 is '1', as another ToC element follows.
    Bits 1..3 are 000 = Good speech frame
    Bits 4..7 are 0000 = Reserved
    Bit 8 is '1', as another ToC element follows.
    Bits 9..11 are 111 = No_Data frame
    Bits 12..15 are 0000 = Reserved
    Bit 16 is '0'; no more ToC elements follow.
    Bits 17..19 are 000 = Good speech frame
    Bits 20..23 are 0000 = Reserved
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|0 0 0|0 0 0 0|1|1 1 1|0 0 0 0|0|0 0 0|0 0 0 0|b1           b8|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
    |b9   Frame 1                                                b40|
    +                                                               +
    |b41                                                         b72|
    +                                                               +
    |b73                                                        b104|
    +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |b105       b112|b1                                          b24|
    +-+-+-+-+-+-+-+-+                                               +
    |b25  Frame 3                                                b56|
    +                                                               +
    |b57                                                         b88|
    +                                               +-+-+-+-+-+-+-+-+
    |b89                                        b112|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

7. Payload Format Parameters

 This RTP payload format is identified using the media type "audio/
 GSM-HR-08", which is registered in accordance with [RFC4855] and uses
 [RFC4288] as a template.  Note: Media subtype names are case-
 insensitive.

Duan, et al. Standards Track [Page 11] RFC 5993 RTP Payload Format for GSM-HR October 2010

7.1. Media Type Definition

 The media type for the GSM-HR codec is allocated from the IETF tree,
 since GSM-HR is a well-known speech codec.  This media type
 registration covers real-time transfer via RTP.
 Note: Reception of any unspecified parameter MUST be ignored by the
 receiver to ensure that additional parameters can be added in the
 future.
 Type name: audio
 Subtype name: GSM-HR-08
 Required parameters: none
 Optional parameters:
    max-red: The maximum duration in milliseconds that elapses between
    the primary (first) transmission of a frame and any redundant
    transmission that the sender will use.  This parameter allows a
    receiver to have a bounded delay when redundancy is used.  Allowed
    values are integers between 0 (no redundancy will be used) and
    65535.  If the parameter is omitted, no limitation on the use of
    redundancy is present.
    ptime: See [RFC4566].
    maxptime: See [RFC4566].
 Encoding considerations:
    This media type is framed and binary; see Section 4.8 of RFC 4288
    [RFC4288].
 Security considerations:
    See Section 10 of RFC 5993.
 Interoperability considerations:
    The media subtype name contains "-08" to avoid potential conflict
    with any earlier drafts of GSM-HR RTP payload types that aren't
    bit-compatible.

Duan, et al. Standards Track [Page 12] RFC 5993 RTP Payload Format for GSM-HR October 2010

 Published specifications:
    RFC 5993, 3GPP TS 46.002
 Applications that use this media type:
    Real-time audio applications like voice over IP and
    teleconference.
 Additional information: none
 Person & email address to contact for further information:
    Ingemar Johansson <ingemar.s.johansson@ericsson.com>
 Intended usage: COMMON
 Restrictions on usage:
    This media type depends on RTP framing, and hence is only defined
    for transfer via RTP [RFC3550].  Transport within other framing
    protocols is not defined at this time.
 Authors:
    Xiaodong Duan <duanxiaodong@chinamobile.com>
    Shuaiyu Wang <wangshuaiyu@chinamobile.com>
    Magnus Westerlund <magnus.westerlund@ericsson.com>
    Ingemar Johansson <ingemar.s.johansson@ericsson.com>
    Karl Hellwig <karl.hellwig@ericsson.com>
 Change controller:
    IETF Audio/Video Transport working group, delegated from the IESG.

7.2. Mapping to SDP

 The information carried in the media type specification has a
 specific mapping to fields in the Session Description Protocol (SDP)
 [RFC4566], which is commonly used to describe RTP sessions.  When SDP
 is used to specify sessions employing the GSM-HR codec, the mapping
 is as follows:
 o  The media type ("audio") goes in SDP "m=" as the media name.

Duan, et al. Standards Track [Page 13] RFC 5993 RTP Payload Format for GSM-HR October 2010

 o  The media subtype (payload format name) goes in SDP "a=rtpmap" as
    the encoding name.  The RTP clock rate in "a=rtpmap" MUST be 8000,
    and the encoding parameters (number of channels) MUST either be
    explicitly set to 1 or omitted, implying a default value of 1.
 o  The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
    "a=maxptime" attributes, respectively.
 o  Any remaining parameters go in the SDP "a=fmtp" attribute by
    copying them directly from the media type parameter string as a
    semicolon-separated list of parameter=value pairs.

7.2.1. Offer/Answer Considerations

 The following considerations apply when using SDP offer/answer
 procedures to negotiate the use of GSM-HR payload in RTP:
 o  The SDP offerer and answerer MUST generate GSM-HR packets as
    described by the offered parameters.
 o  In most cases, the parameters "maxptime" and "ptime" will not
    affect interoperability; however, the setting of the parameters
    can affect the performance of the application.  The SDP offer/
    answer handling of the "ptime" parameter is described in
    [RFC3264].  The "maxptime" parameter MUST be handled in the same
    way.
 o  The parameter "max-red" is a stream property parameter.  For
    sendonly or sendrecv unicast media streams, the parameter declares
    the limitation on redundancy that the stream sender will use.  For
    recvonly streams, it indicates the desired value for the stream
    sent to the receiver.  The answerer MAY change the value, but is
    RECOMMENDED to use the same limitation as the offer declares.  In
    the case of multicast, the offerer MAY declare a limitation; this
    SHALL be answered using the same value.  A media sender using this
    payload format is RECOMMENDED to always include the "max-red"
    parameter.  This information is likely to simplify the media
    stream handling in the receiver.  This is especially true if no
    redundancy will be used, in which case "max-red" is set to 0.
 o  Any unknown media type parameter in an offer SHALL be removed in
    the answer.

7.2.2. Declarative SDP Considerations

 In declarative usage, like SDP in the Real Time Streaming Protocol
 (RTSP) [RFC2326] or the Session Announcement Protocol (SAP)
 [RFC2974], the parameters SHALL be interpreted as follows:

Duan, et al. Standards Track [Page 14] RFC 5993 RTP Payload Format for GSM-HR October 2010

 o  The stream property parameter ("max-red") is declarative, and a
    participant MUST follow what is declared for the session.  In this
    case, it means that the receiver MUST be prepared to allocate
    buffer memory for the given redundancy.  Any transmissions MUST
    NOT use more redundancy than what has been declared.  More than
    one configuration may be provided if necessary by declaring
    multiple RTP payload types; however, the number of types should be
    kept small.
 o  Any "maxptime" and "ptime" values should be selected with care to
    ensure that the session's participants can achieve reasonable
    performance.

8. IANA Considerations

 One media type (audio/GSM-HR-08) has been defined, and it has been
 registered in the media types registry; see Section 7.1.

9. Congestion Control

 The general congestion control considerations for transporting RTP
 data apply; see RTP [RFC3550] and any applicable RTP profiles, e.g.,
 "RTP/AVP" [RFC3551].
 The number of frames encapsulated in each RTP payload highly
 influences the overall bandwidth of the RTP stream due to header
 overhead constraints.  Packetizing more frames in each RTP payload
 can reduce the number of packets sent and hence the header overhead,
 at the expense of increased delay and reduced error robustness.  If
 forward error correction (FEC) is used, the amount of FEC-induced
 redundancy needs to be regulated such that the use of FEC itself does
 not cause a congestion problem.

10. Security Considerations

 RTP packets using the payload format defined in this specification
 are subject to the security considerations discussed in the RTP
 specification [RFC3550], and in any applicable RTP profile.  The main
 security considerations for the RTP packet carrying the RTP payload
 format defined within this memo are confidentiality, integrity, and
 source authenticity.  Confidentiality is achieved by encryption of
 the RTP payload, and integrity of the RTP packets through a suitable
 cryptographic integrity protection mechanism.  A cryptographic system
 may also allow the authentication of the source of the payload.  A
 suitable security mechanism for this RTP payload format should
 provide confidentiality, integrity protection, and at least source
 authentication capable of determining whether or not an RTP packet is
 from a member of the RTP session.

Duan, et al. Standards Track [Page 15] RFC 5993 RTP Payload Format for GSM-HR October 2010

 Note that the appropriate mechanism to provide security to RTP and
 payloads following this may vary.  It is dependent on the
 application, the transport, and the signaling protocol employed.
 Therefore, a single mechanism is not sufficient, although if
 suitable, the usage of the Secure Real-time Transport Protocol (SRTP)
 [RFC3711] is recommended.  Other mechanisms that may be used are
 IPsec [RFC4301] and Transport Layer Security (TLS) [RFC5246] (e.g.,
 for RTP over TCP), but other alternatives may also exist.
 This RTP payload format and its media decoder do not exhibit any
 significant non-uniformity in the receiver-side computational
 complexity for packet processing, and thus are unlikely to pose a
 denial-of-service threat due to the receipt of pathological data; nor
 does the RTP payload format contain any active content.

11. Acknowledgements

 The authors would like to thank Xiaodong Duan, Shuaiyu Wang, Rocky
 Wang, and Ying Zhang for their initial work in this area.  Many
 thanks also go to Tomas Frankkila for useful input and comments.

12. References

12.1. Normative References

 [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC3264]   Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
             with Session Description Protocol (SDP)", RFC 3264,
             June 2002.
 [RFC3550]   Schulzrinne, H., Casner, S., Frederick, R., and V.
             Jacobson, "RTP: A Transport Protocol for Real-Time
             Applications", STD 64, RFC 3550, July 2003.
 [RFC3551]   Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
             Video Conferences with Minimal Control", STD 65,
             RFC 3551, July 2003.
 [RFC4566]   Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
             Description Protocol", RFC 4566, July 2006.
 [RFC5405]   Eggert, L. and G. Fairhurst, "Unicast UDP Usage
             Guidelines for Application Designers", BCP 145, RFC 5405,
             November 2008.

Duan, et al. Standards Track [Page 16] RFC 5993 RTP Payload Format for GSM-HR October 2010

 [TS46.002]  3GPP, "Half rate speech; Half rate speech processing
             functions", 3GPP TS 46.002, June 2007, <http://
             www.3gpp.org/ftp/Specs/archive/46_series/46.002/
             46002-700.zip>.
 [TS46.020]  3GPP, "Half rate speech; Half rate speech transcoding",
             3GPP TS 46.020, June 2007, <http://www.3gpp.org/ftp/
             Specs/archive/46_series/46.020/46020-700.zip>.

12.2. Informative References

 [RFC2198]   Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
             Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
             Parisis, "RTP Payload for Redundant Audio Data",
             RFC 2198, September 1997.
 [RFC2326]   Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
             Streaming Protocol (RTSP)", RFC 2326, April 1998.
 [RFC2974]   Handley, M., Perkins, C., and E. Whelan, "Session
             Announcement Protocol", RFC 2974, October 2000.
 [RFC3711]   Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
             Norrman, "The Secure Real-time Transport Protocol
             (SRTP)", RFC 3711, March 2004.
 [RFC4288]   Freed, N. and J. Klensin, "Media Type Specifications and
             Registration Procedures", BCP 13, RFC 4288,
             December 2005.
 [RFC4301]   Kent, S. and K. Seo, "Security Architecture for the
             Internet Protocol", RFC 4301, December 2005.
 [RFC4855]   Casner, S., "Media Type Registration of RTP Payload
             Formats", RFC 4855, February 2007.
 [RFC5109]   Li, A., "RTP Payload Format for Generic Forward Error
             Correction", RFC 5109, December 2007.
 [RFC5246]   Dierks, T. and E. Rescorla, "The Transport Layer Security
             (TLS) Protocol Version 1.2", RFC 5246, August 2008.

Duan, et al. Standards Track [Page 17] RFC 5993 RTP Payload Format for GSM-HR October 2010

Authors' Addresses

 Xiaodong Duan
 China Mobile Communications Corporation
 53A, Xibianmennei Ave., Xuanwu District
 Beijing,   100053
 P.R. China
 EMail: duanxiaodong@chinamobile.com
 Shuaiyu Wang
 China Mobile Communications Corporation
 53A, Xibianmennei Ave., Xuanwu District
 Beijing,   100053
 P.R. China
 EMail: wangshuaiyu@chinamobile.com
 Magnus Westerlund
 Ericsson AB
 Farogatan 6
 Stockholm,   SE-164 80
 Sweden
 Phone: +46 8 719 0000
 EMail: magnus.westerlund@ericsson.com
 Karl Hellwig
 Ericsson AB
 Ericsson Allee 1
 52134 Herzogenrath
 Germany
 Phone: +49 2407 575-2054
 EMail: karl.hellwig@ericsson.com
 Ingemar Johansson
 Ericsson AB
 Laboratoriegrand 11
 SE-971 28 Lulea
 Sweden
 Phone: +46 73 0783289
 EMail: ingemar.s.johansson@ericsson.com

Duan, et al. Standards Track [Page 18]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5993.txt · Last modified: 2010/10/19 14:50 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki