📄 rfc3267.txt
字号:
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 + -