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

From: [email-masked]
Date: Thu, 6 Oct 2005 10:47:45 EDT

Yaakov,

I was prompted to read your draft because of the emails. I think it is one of 
the best written descriptions of the current situation facing us in achieving 
real QoS in a real network. We have been struggling with these issues in 
attempts to use VoIP in a very large network (private) to replace current 
circuit-switched technology. Since "cheap" is not really the driver for this network, 
some of us have asked the question "Why change?" I personally am still looking 
for a reason.

I believe that anyone who does not agree that your draft accurately 
identifies the current situation and the issues does not want to be a part of the 
solution. I hope to see this draft published as an RFC very quickly.

Mike Pierce
_______________________________________________
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: [email-masked]
Date: Thu, 06 Oct 2005 20:18:25 +0200

Yaakov,

What is the purpose of this draft? Do you want the IETF
to stop all work related to real-time traffic and stick to
SDH/ISDN? Or do you want better VoIP? If you want the latter,
please remove the PSTN nostalgia from the document. It does
not help to start a real discussion.

You are comparing a network that was designed and optimized for
a single application -- 4 kHz voice -- with a general purpose
network that was deliberately >>not<< optimized for one kind of
traffic. It's no wonder that the special purpose network has
some advantages for its one and only application.

draft-stein-great-00.txt:
> 3.  Bandwidth and Audio Quality Problems
> [..]
> Design of standardized PSN-aware wideband encoders is a
> worthwhile task waiting to be tackled.
..
> 4.  Delay and Delay Variation Problems
> [..]
> More attention should be drawn to the perfection of shock absorber
> based systems.  These may need to be more fully integrated into the
> encoder, perhaps more specifically into the PLC mechanism.
..
> 5.  Congestion Problems
> [..]
> When congestion is detected, either by explicit notification or
> via detection of packet loss, even real-time systems should heed the
> network's warning of imminent trouble.  In addition to PLC on any missing
> packet, in the other direction rate cutback needs to be attempted, e.g. by
> lowering VAD thresholds, via adaptation of the rate of adaptive multirate
> encoders or the average output rate parameter of variable rate encoders,
> and in extreme cases by deliberate dropping of packets that are likely
> to be more effectively concealed by the PLC.

> 6.  Emulation Problems
> [..]
> [signal processing in audio conferes] Complete summing of
> audio from all users is problematic for several reasons.  It requires
> decompression and recompression of user audio, and rescaling to avoid
> excessive signal levels.  Advances would be welcome here.
These are all interestings topics. Some of them go deep into audio signal
processing. I am not sure whether the IETF is the right forum for those.

Excessive jitter and packet loss are signs of congestion. The
solution is the same as for PSTN congestion: sufficient dimensioning.

Adapting real-time flows to congested links is already explored in the
DCCP WG (you are already contributing there).

> Reduction of the connection setup delay, and the related delays for
> entering/exiting fax-relay and modem-relay modes is an important
> signalling problem to be solved.
Let's hope that such perversions will vanish quickly!

Wolfgang Beck

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 06 Oct 2005 14:48:34 -0400

Just to add some numbers to this discussion: Wenyu Jiang and I performed 
a number of end-to-end reliability tests about 3 years ago. You can find 
some related papers at http://www1.cs.columbia.edu/~wenyu/

There are solutions (or at least proposals) to some of the signal 
processing issues in the draft; I'm not sure what good it does to 
commingle those with protocol or network architecture issues. (As a 
random example, we have done work locally on efficient mixing of large 
numbers of encoded audio streams, as have others.)