From a0acccffa597052becf746862e64a6fb2425f1ab Mon Sep 17 00:00:00 2001 From: "Kevin P. Fleming" Date: Mon, 25 Jul 2005 19:13:21 +0000 Subject: [PATCH] fix line-ending style (bug #4778) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@6201 65c4cc65-6c06-0410-ace0-fbb531ad65f3 --- doc/README.jitterbuffer | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/doc/README.jitterbuffer b/doc/README.jitterbuffer index 738a05719a..705dc5f5ae 100755 --- a/doc/README.jitterbuffer +++ b/doc/README.jitterbuffer @@ -4,11 +4,12 @@ Steve Kann -The new jitterbuffer, PLC, and the IAX2-integration of the new jitterbuffer have been integrated -into Asterisk. The jitterbuffer is generic and work is going on to implement it in SIP/RTP as well. +The new jitterbuffer, PLC, and the IAX2-integration of the new jitterbuffer +have been integrated into Asterisk. The jitterbuffer is generic and work is +going on to implement it in SIP/RTP as well. -Also, we've added a feature called "trunktimestamps", which adds individual timestamps to -trunked frames within a trunk frame. +Also, we've added a feature called "trunktimestamps", which adds individual +timestamps to trunked frames within a trunk frame. Here's how to use this stuff: @@ -96,7 +97,8 @@ and fix that. But we should also figure out how to make the receiver more robus cases like this. chan_iax2 will actually help fix this a bit if it's more than 3 seconds or so, but at -some point we should try to think of a better way to detect this kind of thing and resynchronize. +some point we should try to think of a better way to detect this kind of thing and +resynchronize. Different clock rates are handled very gracefully though; it will actually deal with a sender sending 20% faster or slower than you expect just fine.