Subject: RE: [Sipping] RE: draft-stein-great-00.txt

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 9 Oct 2005 08:59:13 +0200

> > [YJS] Well, G.728 is indeed low delay, but is stuck at a relatively
high bit rate.
> 
> You're not serious, are you? G.728 is 16 kbps. Sending audio 
> in 5 ms frames will cost you 64 kbps just for headers. For 
> very low latency you're always going to pay more in overhead 
> than what the codec costs you.

Now I see what you are talking about. Why do you assume that
we always have all the headers ? It is now common practice
to compress headers over BW limited links. For another case
Y.1414 or Y.vtoip uses only a single header for many streams.

> > [YJS] And G.729 is not 10 ms delay - it is 10 ms frame duration. 
> > To that you have to 
> > add the lookahead, processing time, and SW thread times, 
> > and the fact that most 
> > Internet implementations of 729 use superpackets.
> 
> If the implementation is bad, then it's not the codec's fault.

It isn't the implementation's fault either. 
The lookahead HAS to be taken into account,
and you have to take SOME time in processing
(e.g. a very good G.729 implementation requires 
about 100K cycles to encode a frame)

Then, since you are insisting on a jitter buffer implementation,
take another packet delay into account.

Unless you are designing a special purpose chip
to encode a single channel, the system will be doing other
things as well, so you NEED to have the thread delay.

Finally, if you have some way of reducing the queuing time
through the public Internet, please publish it..

> > > I think CBR (or at least having a max bit-rate) *is* important for
VoIP.
 
> > [YJS] That's interesting. Why ?
> 
> Because if I have a modem that has ~30 kbps upload and I 
> subtract the header 16 kbps overhead and about 5 kbps for 
> being safe, I'm left with 9 kbps. Using a 8 kbps codec CBR 
> will work. Using a 8 kbps (average) VBR codec will not. It's 
> a matter of never exceeding the max bandwidth of your 
> channel. If you do DTX or VBR, if will save a few bits, but 
> it cannot make your communication better.

Once again we are now understanding your assumptions.
You are assuming that the user is connected via a V.34 dial-up
modem (I worked on V.34 at the beginning, but haven't seen
one in years). Why not assume a V.92 with 56K or an ADSL 
with a Mbps or so? 
What assumptions should we make about the user connection speed
and characteristics? 

Also, you are assuming a tradition CELP-type encoder
that gives about 8 Kbps. Why not an ADPCM at 32
or an SBC at 16 or a WI at <4 Kbps ?

These are precisely the issues I would
like to discuss at the BOF.

> 
> > [YJS] Once again, you are confusing frame duration with delay. The 
> > most common codec for VoIP seems to be 723 which with lookahead and 
> > processing and software overhead is about 50 millisec each way. To 
> > this you have to add the propagation through the network. 
> > Round trip  times of 200 millisec are very common.
> 
> So because G.723.1 is bad, then everything else is?

No, but G.723.1 is not "bad". There are various trade-offs
that need to be investigated. G.723.1 is commonly used
because of its low bit-rate (yes I know that Annex D now 
gives a 6.4 Kbps rate for G.729 as well with higher quality)

> > [YJS] I disagree that nothing can be done. Nothing can be done in a 
> > pure jitter buffer system, but several good shock absorber 
> systems are
> out there.
> 
> It's not a jitter buffer thing, it's a fundamental issue. You 
> are playing packets as you receive them (need to reduce 
> latency) and then nothing comes for 200 ms (10 packets in a 
> row). Now what? The jitter buffer won't help you. The codec 
> might reconstruct about 2-3 packets decently, but after than 
> it's going to be silence and there's just nothing you can do 
> about it (unless you have some revolutionary network time machine?).

Yes, there ARE things you can do about it.
That is precisely the difference between a jitter-buffer system
and a shock-absorber one!

In any case, you have to design for the kind of behavior we expect
to see. That is neither <only isolated packets lost>, 
nor <only bursts of 5 packets lost>. Rather it is a distribution
derivable from some network model. Designing for either case
ONLY makes the quality suboptimal.

Y(J)S

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: lconroy <[email-masked]>
Date: Sun, 9 Oct 2005 14:32:05 +0100

Hi Folks,
  forgive the intrusion (and trimming the CC list), but...
I was beginning to wonder why this thread was on the SIPPING list.

Now we are talking about ROHC or other header compression schemes,
with the ones listed being produced in another SDO entirely.
Please look at ROHC and its applicability before talking about header
compression - it isn't magic sauce that can be poured on anything,
and is certainly NOT end-to-end. Pure CRTP only gets you half way.

So, to repeat - why not take this to some other WG list, or create
another independent ML for discussions leading up to a BOF?
That is the typical approach that has been used in the IETF (i.e.
this standards forum) during BOF development.

In any case, a lot of this Norwegian discussion seems to be more
applicable to AVT or ROHC, with the possible exception of reference
to shock absorbers, which seems to have drifted in through a wormhole
from of some automotive standards group.

Lord knows SIPPING is busy enough - adding this stuff seems  
unreasonable.

all the best,
   Lawrence

---

From: Greg Herlein <[email-masked]>
Date: Sun, 9 Oct 2005 18:26:45 -0700 (PDT)

> and a shock-absorber one!

Can someone please send me a reference to the "shock-absorber" 
technique?  I'm not familiar with that.

Greg

---

From: Simon Morlat <[email-masked]>
Date: Tue, 18 Oct 2005 20:19:21 +0200

Hello,

Just to add a sip-phone developer point of view to this debate on latency:
My point of view is that the problem is not on codecs. Even G723.1 is fine for 
me.
The problem is more on operating systems real-time capabilites and sound 
drivers.
It is not rare to see drivers that have up to 1 second of latency to capture 
sound and same thing for playback. Simply because they were not designed for 
real time.
The accuracy of the scheduling of the audio processing thread by the OS is 
also important: a jittered scheduling (delayed because other processes, disk 
i/o or whatever) is also a factor of latency, because it forces to enlarge 
the rtp jitter buffer of the remote receiver.

Efforts have been done on linux, fortunately. Now with 2.6 kernels and the 
excelent alsa drivers it is possible to achieve reasonnable capture/playback 
latencies (for example around 30ms on linphone which is not specially tuned, 
just simply it uses the alsa api possibilites). Using a codec like speex and 
a correct network connectivity (xDSL at least) this leads to acceptable phone 
calls, better than which is provided by GSM networks. And using the wideband 
mode of speex (16000Hz sampling frequency), it's a revolution !

Also connectivites using RTC modems are to forget from my point of view, they 
have unacceptable latencies (around 200 ms to ping my website in the best 
case...). 

Simon