- This topic is empty.
3rd February 2001 at 00:25 #19784RommelGuest
Can you explain why you feel RSVP does not provide real control? Do you feel that current Dif Serv mechanisms help at all?
While I somewhat agree that gateways do not provide the total solution for QoS they provide a part of the solution, after all QoS is an end-to-end story.
Silence surpression seems to give about a 30-50% bandwidth reduction. The reason I say this is becuase in normal conversations not everyone is speaking at once.
Rommel21st March 2001 at 23:59 #19785webproGuest
Some significant problems arise when using compression codecs. G.711 provides toll quality and has much better error recovery.
Silence suppression can also impact the voice quality since there is always a transition between silense and talking.
Once test I would like to be able to perform is multiple codec processing of the same audio sample. For example, take a standard voice sample, process is through a G.711 codec, Conver it back to anolog through anoother G.711 processer then process it again through a G.729a codec. Having some PSQM scores on this would be cool. This is what will happen going from a VoIP network to the PSTN back onto a VoIP network using two different codecs. Any suggestions?
Sequention packet loss significantly affects voice quality with compression codecs. QoS is more than bandwidth shaping.
Bandwidth shaping attempts to limit the influence of other protocols on a voice converation (in reagrds to VoIP).
RSVP and other protocols are intended to ensure adequate bandwidth is avaialble before allowing the call to start. Other mechanisms exist such as a static number of calls alows per link and is managed by the VoIP system its self.
Pardon the typos, this little box is hard to type into.
Ramblings from Webpro…31st March 2001 at 16:44 #19786Andre SGuest
I agree that G.711 provides toll quality but I have a question about “error recovery for G.711”. G.711 is traditionally used in circuit switched networks with very low error frequency.Therefore I wonder about how tolerant G.711 is for los packets? Have you made measurement to verify that G.711 really has a good error recovery function??? I would apreciate if you could expand more about the “error recovery aspects for G.711..31st March 2001 at 19:31 #19787Chris TaylorGuest
I’ve got some trouble getting my head round error recovery too, because I don’t think G.711 has any error recovery. I think other schemes have some sort of error recovery, although I think this is limited to replaying previous samples or guessing the next sample rather than actually negotiating the retransmission of a sample.
But, I don’t think G.711 has anything like that. Individual voice samples for G.711 only represent 125 micro seconds, so the loss of several samples will have no effect. But, if you pack 20ms or so of samples into an IP datagram (which is realistic), and then lose one or two datagrams, then the loss would be noticed.1st April 2001 at 12:04 #19788osafiana nwankpeleGuest
i am systems engineer and very fascinated with telecoms i would want a pointer in the right direction2nd April 2001 at 17:30 #19789webproGuest
A lost packet in G.711 is handled by DSP. The DSP knows where the last packet level ended, if a packet is lost, it simply resends the last packet is received. Since it is either a 10 or 20 ms slice, it will not be noticed. The real problem is with consecutive lost packets. We use a method where since we know the level where the last packet ended, we can start the next one there and guess at the next missing packet. G.711 is very tolerant. The compressed codecs actualy have a harder time and the effects of lost packets may take 2 or 3 seconds to fully recover.4th April 2001 at 01:39 #19790RommelGuest
G711 as a codec does not replay the last packet received. There are no codecs that have error recovery built into the standard. It is the vendor’s implementation that decides it. That would be the function of the playout buffer no matter which codec you use. G711 is tolerant to packet loss because a sample only amounts ot 125 microseconds of voice where as a sample at other codecs are a much longer sample i.e. g729 10ms. That being said most vendors do not ship a single 125 microsecond sample per RTP packet and buffer at least 10 samples per frame.
G711 is built on nyquist’s theorum stating “in order to accurately reproduce a waveform one must sample twice the frequency” Voice being 3.1khz (in general) and rounded up to 4khz gives us 8000 samples per second. This is what TDM was built upon. 8000 samples at 8 bits per sample give us 64k per channel.4th April 2001 at 19:41 #19791WebproGuest
If only I could have put it so succinctly eloquently.