1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
|
What is PLC?
PLC stands for Packet Loss Concealment. PLC describes any method of generating
new audio data when packet loss is detected. In Asterisk, there are two main flavors
of PLC, generic and native. Generic PLC is a method of generating audio data on
signed linear audio streams. Signed linear audio, often abbreviated "slin," is required
since it is a raw format that has no companding, compression, or other transformations
applied. Native PLC is used by specific codec implementations, such as
iLBC and Speex, which generates the new audio in the codec's native format. Native
PLC happens automatically when using a codec that supports native PLC. Generic PLC
requires specific configuration options to be used and will be the focus of this
document.
How does Asterisk detect packet loss?
Oddly, Asterisk does not detect packet loss when reading audio in. In order to
detect packet loss, one must have a jitter buffer in use on the channel on which
Asterisk is going to write missing audio using PLC. When a jitter buffer is in use,
audio that is to be written to the channel is fed into the jitterbuffer. When the
time comes to write audio to the channel, a bridge will request that the jitter
buffer gives a frame of audio to the bridge so that the audio may be written. If
audio is requested from the jitter buffer but the jitter buffer is unable to give
enough audio to the bridge, then the jitter buffer will return an interpolation
frame. This frame contains no actual audio data and indicates the number of samples
of audio that should be inserted into the frame.
A bit of background on translation
As stated in the introduction, generic PLC can only be used on slin audio.
The majority of audio communication is not done in slin, but rather using lower
bandwidth codecs. This means that for PLC to be used, there must be a translation
step involving slin on the write path of a channel. This means that PLC cannot
be used if the codecs on either side of the bridge are the same or do not require
a translation to slin in order to translate between them. For instance, a
ulaw <-> ulaw call will not use PLC since no translation is required. In addition,
a ulaw <-> alaw call will also not use PLC since the translation path does not
include any step involving slin.
One item of note is that slin must be present on the write path of a channel
since that is the path where PLC is applied. Consider that Asterisk is bridging
channels A and B. A uses ulaw for audio and B uses GSM. This translation involves
slin, so things are shaping up well for PLC. Consider, however if Asterisk sets
up the translation paths like so:
Fig. 1
A +------------+ B
<---ulaw<---slin<---GSM| |GSM--->
| Asterisk |
ulaw--->slin--->GSM--->| |<---GSM
+------------+
The arrows indicate the direction of audio flow. Each channel has a write
path (the top arrow) and a read path (the bottom arrow). In this setup, PLC
can be used when sending audio to A, but it cannot be used when sending audio
to B. The reason is simple, the write path to A's channel contains a slin
step, but the write path to B contains no slin step. Such a translation setup
is perfectly valid, and Asterisk can potentially set up such a path depending
on circumstances. When we use PLC, however, we want slin audio to be present
on the write paths of both A and B. A visual representation of what we want
is the following:
Fig. 2
A +------------+ B
<---ulaw<---slin| |slin--->GSM--->
| Asterisk |
ulaw--->slin--->| |<---slin<---GSM
+------------+
In this scenario, the write paths for both A and B begin with slin,
and so PLC may be applied to either channel. This translation behavior has,
in the past been doable with the transcode_via_sln option in asterisk.conf.
Recent changes to the PLC code have also made the genericplc option in
codecs.conf imply the transcode_via_sln option. The result is that by
enabling genericplc in codecs.conf, the translation path set up in
Fig. 2 should automatically be used.
Additional restrictions and caveats
One restriction that has not been spelled out so far but that has been
hinted at is the presence of a bridge. The term bridge in this sense means
two channels exchanging audio with one another. A bridge is required because
use of a jitter buffer is a prerequisite for using PLC, and a jitter buffer
is only used when bridging two channels. This means that one-legged calls,
(e.g. calls to voicemail, to an IVR, to an extension that just plays back
audio) will not use PLC. In addition, MeetMe and ConfBridge calls will not
use PLC.
It should be obvious, but it bears mentioning, that PLC cannot be used
when using a technology's native bridging functionality. For instance, if
two SIP channels can exchange RTP directly, then Asterisk will never be
able to process the audio in the first place. Since translation of audio
is a requirement for using PLC, and translation will not allow for a
native bridge to be created, this is something that is not likely to be
an issue, though.
Since a jitter buffer is a requirement in order to use PLC, it should
be noted that simply enabling the jitter buffer via the jbenable option
may not be enough. For instance, if bridging two SIP channels together,
the default behavior will not be to enable jitter buffers on either channel.
The rationale is that the jitter will be handled at the endpoints to which
Asterisk is sending the audio. In order to ensure that a jitter buffer is
used in all cases, one must enable the jbforce option for channel types
on which PLC is desired.
Summary
The following are all required for PLC to be used:
* Enable genericplc in the plc section of codecs.conf
* Enable (and potentially force) jitter buffers on channels
* Two channels must be bridged together for PLC to be used
(no Meetme or one-legged calls)
* The audio must be translated between the two channels
and must have slin as a step in the translation process.
Protip
One of the restrictions mentioned is that PLC will only
be used when two audio channels are bridged together. Through the
use of Local channels, you can create a bridge even if the call
is, for all intents and purposes, one-legged. By using a combination
of the /n and /j suffixes for a Local channel, one can ensure
that the Local channel is not optimized out of the talk path
and that a jitter buffer is applied to the Local channel as well.
Consider the following simple dialplan:
[example]
exten => 1,1,Playback(tt-weasels)
exten => 2,1,Dial(Local/1@example/nj)
When dialing extension 1, PLC cannot be used because there
will be only a single channel involved. When dialing extension
2, however, Asterisk will create a bridge between the incoming
channel and the Local channel, thus allowing PLC to be used.
|
