Re: ip phone design considerations

From: Richard (rh86_at_azglobal.com)
Date: 06/28/04 

Date: Sun, 27 Jun 2004 21:40:18 -0700

Apparatus wrote:
> 4) Is UDP a reliable enough transmit method? Should
> I add a 100ms buffer for frame delays? Should I
> repeat the last frame if a frame is omitted?

Yes, UDP is exactly the right protocol. And even if a packet gets lost
or clobbered, a re-transmission is useless by the time it's detected and
acted upon - in the case of TCP, the transmission stream has probably
paused while this occurs too, causing more problems.

At a minimum, look at RTP (real-time protocol) which run on UDP. It
timestamps the packets at the source so playback is properly paced.
Instead of re-transmitting, figure out how you can recover the missing
packet, or approximate its content.

100mS is too much buffer. A goal with VoIP is to keep the round-trip
latency below 150mS, including the codec time, otherwise there's an
irritating delay in the speech.

Like you'll see RealPlayer do, try to buffer enough (for better
reliability), but as little as possible (for better performance / less
delay). Adapt to the performance of the data stream.

I'd shy away from VoIP interoperability unless you can source the code
somewhere easily (or use a chip implementation). It's a good model for
reference, but I think you'll find it'd make your project too complex.

> 5) What else should I consider? Any other suggestions?

* I think you are over-simplifying the non-analog parts, even if you use
an existing design. But for a student project, it needn't be
carrier-grade, and a workable solution could be hacked out.

* When demoing it, have the two subjects separated where they can
neither see nor hear the other party, except through the phone.
Otherwise, transmission delays become very noticable.

* Other ideas - change the codec real-time, based on the quality of the
connection. G.711 when you can (LAN), compression otherwise (WAN).

* Power over Ethernet is the hot marketing rage among power chip
makers. Pickup a copy of EETimes and look for the ads. Power the phone
across the LAN - not a lot of folks have seen this done yet, so it'll
have a coolness factor.

Good luck!
Richard

Relevant Pages

  • Re: Dah-de-bleedin-dah.
    ... Flutter in digital system results in delays or even worse Jitter = ... variable delays in transmission. ... results in an unpredictable delay at the end of transmission. ... Sloppy procedure doesn't work on a digital voice system. ...
    (uk.radio.amateur)
  • Re: Unicast UDP Server
    ... From what I gathered from your post, invoking "connect" with a remote address in a UDP socket will ensure that the receive callback is only invoked with data received from the specified remote address, correct? ... Without the 75 MB receive buffer, we _occasionally_ find the buffer overfilling. ... You haven't made any mention as to what your actual network speed and load is, but I'll reiterate my previous statement: only on the fastest networks, under the highest loads, should a buffer of 75MB be useful. ... If you are seeing delays that long, there's probably a better way to deal with them. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: 32MHz clock buffer and divider
    ... course I can stick the clock into a 74vhc74 strapped as a /2, ... way to find an inverter or a buffer in the other flip flop in the 74 ... Then use a divide by two and a divide by four counter to get the frequencies ... It's the best chance that delays and temperature dependencies are the same ...
    (sci.electronics.design)
  • Re: Atheros, hardware access layer, collisions
    ... setting CWmin to be very small. ... One had said that the random delays inserted before ... have to set the transmission attempts to 1 and that CWmin must ... The thing he said was that if carrier sensing "sensed" that the channel ...
    (freebsd-hackers)
  • Re: Real World Significant Sources of (what we usually call) Latency
    ... That's what I suspected - the buffer size is the big elephant in the ... sure that the actual latency is the buffer size expressed in time at the ... sample rate plus whatever other delays there are besides buffering. ...
    (rec.audio.pro)