[Asterisk-cvs] asterisk/configs codecs.conf.sample, 1.2, 1.3 iax.conf.sample, 1.43, 1.44

[markster at lists.digium.com]

Update of /usr/cvsroot/asterisk/configs
In directory mongoose.digium.com:/tmp/cvs-serv1037/configs

Modified Files:
	codecs.conf.sample iax.conf.sample 
Log Message:
Add PLC and jitter buffer and iax2 meta trunk with timestamps (bug #2532, #3400)


Index: codecs.conf.sample
===================================================================
RCS file: /usr/cvsroot/asterisk/configs/codecs.conf.sample,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- codecs.conf.sample	30 Dec 2004 01:40:47 -0000	1.2
+++ codecs.conf.sample	17 Mar 2005 21:30:19 -0000	1.3
@@ -15,3 +15,9 @@
 vbr_quality => 5
 ; true / false
 dtx => false
+
+[plc]
+; for all codecs which do not support native PLC
+; this determines whether to perform generic PLC
+; there is a minor performance penalty for this
+genericplc => true

Index: iax.conf.sample
===================================================================
RCS file: /usr/cvsroot/asterisk/configs/iax.conf.sample,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -d -r1.43 -r1.44
--- iax.conf.sample	17 Mar 2005 15:56:55 -0000	1.43
+++ iax.conf.sample	17 Mar 2005 21:30:19 -0000	1.44
@@ -61,6 +61,12 @@
 ; The jitter buffer's function is to compensate for varying
 ; network delay.
 ;
+; There are presently two jitterbuffer implementations available for * and chan_iax2;
+; the classic and the new, channel/application independent implementation.  These
+; are controlled at compile-time.  The new jitterbuffer additionally has support for PLC
+; which greatly improves quality as the jitterbuffer adapts size, and in compensating for lost
+; packets.
+;
 ; All the jitter buffer settings except dropcount are in milliseconds.
 ; The jitter buffer works for INCOMING audio - the outbound audio
 ; will be dejittered by the jitter buffer at the other end.
@@ -68,9 +74,16 @@
 ; jitterbuffer=yes|no: global default as to whether you want
 ; the jitter buffer at all.
 ;
+; forcejitterbuffer=yes|no: in the ideal world, when we bridge VoIP channels
+; we don't want to do jitterbuffering on the switch, since the endpoints
+; can each handle this.  However, some endpoints may have poor jitterbuffers 
+; themselves, so this option will force * to always jitterbuffer, even in this case.
+; [This option presently applies only to the new jitterbuffer implementation]
+;
 ; dropcount: the jitter buffer is sized such that no more than "dropcount"
 ; frames would have been "too late" over the last 2 seconds.
 ; Set to a small number.  "3" represents 1.5% of frames dropped
+; [This option is not applicable to, and ignored by the new jitterbuffer implementation]
 ;
 ; maxjitterbuffer: a maximum size for the jitter buffer.
 ; Setting a reasonable maximum here will prevent the call delay
@@ -81,18 +94,22 @@
 ; the jitter buffer can end up bigger than necessary.  If it ends up
 ; more than "maxexcessbuffer" bigger than needed, Asterisk will start
 ; gradually decreasing the amount of jitter buffering.
+; [This option is not applicable to, and ignored by the new jitterbuffer implementation]
 ;
 ; minexcessbuffer: Sets a desired mimimum amount of headroom in 
 ; the jitter buffer.  If Asterisk has less headroom than this, then
 ; it will start gradually increasing the amount of jitter buffering.
+; [This option is not applicable to, and ignored by the new jitterbuffer implementation]
 ;
 ; jittershrinkrate: when the jitter buffer is being gradually shrunk 
 ; (or enlarged), how many millisecs shall we take off per 20ms frame
 ; received?  Use a small number, or you will be able to hear it
 ; changing.  An example: if you set this to 2, then the jitter buffer
 ; size will change by 100 millisecs per second.
+; [This option is not applicable to, and ignored by the new jitterbuffer implementation]
 
 jitterbuffer=no
+forcejitterbuffer=no
 ;dropcount=2
 ;maxjitterbuffer=500
 ;maxexcessbuffer=80
@@ -100,6 +117,16 @@
 ;jittershrinkrate=1
 
 ;trunkfreq=20			; How frequently to send trunk msgs (in ms)
+
+; Should we send timestamps for the individual sub-frames within trunk frames?
+; There is a small bandwidth use for these (less than 1kbps/call), but they ensure
+; that frame timestamps get sent end-to-end properly.  If both ends of all your trunks
+; go directly to TDM, _and_ your trunkfreq equals the frame length for your codecs, you 
+; can probably suppress these.  The receiver must also support this feature, although
+; they do not also need to have it enabled.
+;
+; trunktimestamps=yes
+
 ;
 ;
 ; We can register with another IAX server to let him know where we are