diff options
author | mmichelson <mmichelson@f38db490-d61c-443f-a65b-d21fe96a405b> | 2010-06-10 17:30:40 +0000 |
---|---|---|
committer | mmichelson <mmichelson@f38db490-d61c-443f-a65b-d21fe96a405b> | 2010-06-10 17:30:40 +0000 |
commit | 7934ff69d68f02053146ad0d1813509858e90d2c (patch) | |
tree | 8dff7f007a1f857417d3847bbb9186c033794317 /doc/plc.txt | |
parent | 4f9031b890c6811e93212470a8ede812f8a9e9e5 (diff) |
Add text version of PLC doc to 1.4
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@269784 f38db490-d61c-443f-a65b-d21fe96a405b
Diffstat (limited to 'doc/plc.txt')
-rw-r--r-- | doc/plc.txt | 131 |
1 files changed, 131 insertions, 0 deletions
diff --git a/doc/plc.txt b/doc/plc.txt new file mode 100644 index 000000000..1820f2e79 --- /dev/null +++ b/doc/plc.txt @@ -0,0 +1,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. |