Re: ip phone design considerations
From: Wim Lewis (wiml_at_underhill.hhhh.org)
Date: 06/29/04
- Next message: Tom Del Rosso: "Re: Audio Amusement"
- Previous message: YD: "Re: US digital terrestial TV a disaster?"
- In reply to: Apparatus: "ip phone design considerations"
- Messages sorted by: [ date ] [ thread ]
Date: 29 Jun 2004 03:45:07 GMT
In article <3360d677.0406270110.42d3df59@posting.google.com>,
Apparatus <apparatus.home@lycos.com> wrote:
>I am planning on designing an IP phone for a student project. I would
>like some advice on details that I need to take into consideration.
[...]
>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?
"Reliable enough" depends on the specific network that's carrying
the IP traffic. As others have pointed out, if you're just going over
one ethernet segment, it's pretty reliable; if you're transmitting to
another continent, expect to have packets dropped regularly.
Rather than repeating the last piece of sound if you have a gap
in the data, it's probably better to fill it with silence. This
is less distracting to a human listener (expecially if you have
a whole bunch of gaps in a row, i.e., the transmitter has stopped).
In addition to lost packets, you might also have to deal with:
- packets arriving out of order
- packets getting duplicated and arriving twice (this is rare)
- the transmitter and receiver's sample clocks being of slightly
different frequencies
- the network delay between the transmitter and the receiver
can change over time
The solutions to these are left as an exercise to the student :-)
but you'll find lots of discussion about it on the net. In general,
you end up having a tradeoff between solving these problems and
introducing more end-to-end delay. The longer the delay is, the
harder it is to hold a conversation over the link. Even fairly short
delays can have a subliminal effect on how the person at one end
perceives the other person's emotions.
(Re TCP --- the thing to realize about TCP is that a TCP packet
(that is, an IP packet carrying a piece of a TCP session) is no
more reliable than a UDP packet. TCP simply notices when a packet
has been dropped and [oversimplification] requests that it be
retransmitted. In the meantime, the receiver doesn't see any data
--- the connection pauses for a bit. This is the right behavior
for, e.g., a file transfer, but it's not what you want for a real-time
application.)
--
Wim Lewis <wiml@hhhh.org>, Seattle, WA, USA. PGP keyID 27F772C1
- Next message: Tom Del Rosso: "Re: Audio Amusement"
- Previous message: YD: "Re: US digital terrestial TV a disaster?"
- In reply to: Apparatus: "ip phone design considerations"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
