⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc3267.txt

📁 RFC 的详细文档!
💻 TXT
📖 第 1 页 / 共 5 页
字号:

Sjoberg, et. al.            Standards Track                    [Page 22]

RFC 3267        RTP Payload Format for AMR and AMR-WB          June 2002


4.3.5.3. Multi-Channel Payload Carrying Multiple Frames

   The following diagram shows a two channel payload carrying 3 frame-
   blocks, i.e., the payload will contain 6 speech frames.

   In the payload all speech frames contain the same mode 7.4 kbit/s
   (FT=4) and are not damaged at IP origin.  The CMR is set to 15, i.e.,
   no specific mode is requested.  The two channels are defined as left
   (L) and right (R) in that order.  The encoded speech bits is
   designated dXY(0).. dXY(K-1), where X = block number, Y = channel,
   and K is the number of speech bits for that mode.  Exemplifying this,
   for frame-block 1 of the left channel the encoded bits are designated
   as d1L(0) to d1L(147).






































Sjoberg, et. al.            Standards Track                    [Page 23]

RFC 3267        RTP Payload Format for AMR and AMR-WB          June 2002


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | CMR=15|1|1L FT=4|1|1|1R FT=4|1|1|2L FT=4|1|1|2R FT=4|1|1|3L FT|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |4|1|0|3R FT=4|1|d1L(0)                                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                               d1L(147)|d1R(0) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   : ...                                                           :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       d1R(147)|d2L(0)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   : ...                                                           :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |d2L(147|d2R(0)                                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   : ...                                                           :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                       d2R(147)|d3L(0)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   : ...                                                           :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               d3L(147)|d3R(0)                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   : ...                                                           :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                       d3R(147)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
















Sjoberg, et. al.            Standards Track                    [Page 24]

RFC 3267        RTP Payload Format for AMR and AMR-WB          June 2002


4.4. Octet-aligned Mode

4.4.1. The Payload Header

   In octet-aligned mode, the payload header consists of a 4 bit CMR, 4
   reserved bits, and optionally, an 8 bit interleaving header, as shown
   below:

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+- - - - - - - -
   |  CMR  |R|R|R|R|  ILL  |  ILP  |
   +-+-+-+-+-+-+-+-+- - - - - - - -

   CMR (4 bits): same as defined in section 4.3.1.

   R: is a reserved bit that MUST be set to zero.  All R bits MUST be
      ignored by the receiver.

   ILL (4 bits, unsigned integer): This is an OPTIONAL field that is
      present only if interleaving is signalled out-of-band for the
      session.  ILL=L indicates to the receiver that the interleaving
      length is L+1, in number of frame-blocks.

   ILP (4 bits, unsigned integer): This is an OPTIONAL field that is
      present only if interleaving is signalled.  ILP MUST take a value
      between 0 and ILL, inclusive, indicating the interleaving index
      for frame-blocks in this payload in the interleave group.  If the
      value of ILP is found greater than ILL, the payload SHOULD be
      discarded.

   ILL and ILP fields MUST be present in each packet in a session if
   interleaving is signalled for the session.  Interleaving MUST be
   performed on a frame-block basis (i.e., NOT on a frame basis) in a
   multi-channel session.

   The following example illustrates the arrangement of speech frame-
   blocks in an interleave group during an interleave session.  Here we
   assume ILL=L for the interleave group that starts at speech frame-
   block n.  We also assume that the first payload packet of the
   interleave group is s and the number of speech frame-blocks carried
   in each payload is N. Then we will have:

   Payload s (the first packet of this interleave group):
     ILL=L, ILP=0,
     Carry frame-blocks: n, n+(L+1), n+2*(L+1), ..., n+(N-1)*(L+1)

      Payload s+1 (the second packet of this interleave group):



Sjoberg, et. al.            Standards Track                    [Page 25]

RFC 3267        RTP Payload Format for AMR and AMR-WB          June 2002


     ILL=L, ILP=1,
     frame-blocks: n+1, n+1+(L+1), n+1+2*(L+1), ..., n+1+(N-1)*(L+1)
       ...

   Payload s+L (the last packet of this interleave group):
     ILL=L, ILP=L,
     frame-blocks: n+L, n+L+(L+1), n+L+2*(L+1), ..., n+L+(N-1)*(L+1)

   The next interleave group will start at frame-block n+N*(L+1).

   There will be no interleaving effect unless the number of frame-
   blocks per packet (N) is at least 2.  Moreover, the number of frame-
   blocks per payload (N) and the value of ILL MUST NOT be changed
   inside an interleave group.  In other words, all payloads in an
   interleave group MUST have the same ILL and MUST contain the same
   number of speech frame-blocks.

   The sender of the payload MUST only apply interleaving if the
   receiver has signalled its use through out-of-band means.  Since
   interleaving will increase buffering requirements at the receiver,
   the receiver uses MIME parameter "interleaving=I" to set the maximum
   number of frame-blocks allowed in an interleaving group to I.

   When performing interleaving the sender MUST use a proper number of
   frame-blocks per payload (N) and ILL so that the resulting size of an
   interleave group is less or equal to I, i.e., N*(L+1)<=I.

4.4.2. The Payload Table of Contents and Frame CRCs

   The table of contents (ToC) in octet-aligned mode consists of a list
   of ToC entries where each entry corresponds to a speech frame carried
   in the payload and, optionally, a list of speech frame CRCs, i.e.,

   +---------------------+
   | list of ToC entries |
   +---------------------+
   | list of frame CRCs  | (optional)
    - - - - - - - - - - -

      Note, for ToC entries with FT=14 or 15, there will be no
      corresponding speech frame or frame CRC present in the payload.

   The list of ToC entries is organized in the same way as described for
   bandwidth-efficient mode in 4.3.2, with the following exception; when
   interleaving is used the frame-blocks in the ToC will almost never be
   placed consecutive in time.  Instead, the presence and order of the
   frame-blocks in a packet will follow the pattern described in 4.4.1.




Sjoberg, et. al.            Standards Track                    [Page 26]

RFC 3267        RTP Payload Format for AMR and AMR-WB          June 2002


   The following example shows the ToC of three consecutive packets,
   each carrying 3 frame-blocks, in an interleaved two-channel session.
   Here, the two channels are left (L) and right (R) with L coming
   before R, and the interleaving length is 3 (i.e., ILL=2).  This makes
   the interleave group 9 frame-blocks large.

   Packet #1
   ---------

   ILL=2, ILP=0:
   +----+----+----+----+----+----+
   | 1L | 1R | 4L | 4R | 7L | 7R |
   +----+----+----+----+----+----+
   |<------->|<------->|<------->|
     Frame-    Frame-    Frame-
     Block 1   Block 4   Block 7

   Packet #2
   ---------

   ILL=2, ILP=1:
   +----+----+----+----+----+----+
   | 2L | 2R | 5L | 5R | 8L | 8R |
   +----+----+----+----+----+----+
   |<------->|<------->|<------->|
     Frame-    Frame-    Frame-
     Block 2   Block 5   Block 8

   Packet #3
   ---------

   ILL=2, ILP=2:
   +----+----+----+----+----+----+
   | 3L | 3R | 6L | 6R | 9L | 9R |
   +----+----+----+----+----+----+
   |<------->|<------->|<------->|
     Frame-    Frame-    Frame-
     Block 3   Block 6   Block 9

   A ToC entry takes the following format in octet-aligned mode:

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |F|  FT   |Q|P|P|
   +-+-+-+-+-+-+-+-+

   F (1 bit): see definition in Section 4.3.2.




Sjoberg, et. al.            Standards Track                    [Page 27]

RFC 3267        RTP Payload Format for AMR and AMR-WB          June 2002


   FT (4 bits unsigned integer): see definition in Section 4.3.2.

   Q (1 bit): see definition in Section 4.3.2.

   P bits: padding bits, MUST be set to zero.

   The list of CRCs is OPTIONAL.  It only exists if the use of CRC is
   signalled out-of-band for the session.  When present, each CRC in the
   list is 8 bit long and corresponds to a speech frame (NOT a frame-
   block) carried in the payload.  Calculation and use of the CRC is
   specified in the next section.

4.4.2.1. Use of Frame CRC for UED over IP

   The general concept of UED/UEP over IP is discussed in Section 3.6.
   This section provides more details on how to use the frame CRC in the
   octet-aligned payload header together with a partial transport layer
   checksum to achieve UED.

   To achieve UED, one SHOULD use a transport layer checksum, for
   ex

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -