[TriLUG] IP Phone

[Jon Carnes]

There are designers on the Asterisk list that can answer that question
better than me but I'll take a whack at it.  

The problem your describing was very much a limitation of early VoIP
implementations. They've gotten around it in a few ways, but the primary
method is to implement QoS on the network. In that way the latencies
don't change and the Voice (carrier signal) traffic flows quickly from
the server to the modem or fax.

Additionally we mark the extension as Fax/Modem and remove any stutter
controls and compression - so that the original tone signal arrives as
quickly as possible and as unchanged as possible to and from the modem.

It obviously works as we have many clients with faxes and even modems -
all of which work fine.

Note: we have seen some problems with older modems, but when replaced by
newer modems the problems went away. To me that indicates that the
signaling provided by VoIP is just on the edge of acceptability.

Jon Carnes

On Wed, 2004-01-21 at 11:28, Jim Ray wrote:
> Prolly a function of the A/D and D/A in the PCI card.  If Brother Nyquist
> really rules, then the designers of that card have the sampling rate and
> dynamic range set properly.  Me thinks 3.4 kHz BW would be a piece of cake
> yet would recommend testing prior to making a claim.
> 
> /jim
> 
> -----Original Message-----
> From: trilug-bounces at trilug.org [mailto:trilug-bounces at trilug.org] On Behalf
> Of Rob Lockhart
> Sent: Wednesday, January 21, 2004 11:05 AM
> To: Triangle Linux Users Group discussion list
> Subject: Re: [TriLUG] IP Phone
> 
> 
> Jon I meant to ask you a question at the last meeting, but it is perhaps a
> bit technical in nature.
> 
> How does the VoIP system handle POTS sample rate recovery and NTR for
> sampling over an IP network without such capabilities?  Otherwise, I would
> assume that things like Tivos and such (you have to have a land line for
> unhacked DirecTivo) that require POTS modem access for pay-per-view and
> other such things would not work reliably (due to a high connect rate
> causing a high bit-per-symbol allocation) the QAM signalling getting screwed
> up by the irregularly-arriving packets.  I could even imagine that, say,
> network latency being very low and consistent during training, and then a
> few seconds later having different latency (or jitter) characteristics than
> during training, that this may cause the CPE modem to train up at a higher
> rate than the VoIP system can compensate for, thus it may cause the
> narrowband modem link to drop and attempt retrain.
> 
> Just curious....
> 
> Of course this is very hard to detect with your ear and the right
> decoding/encoding techniques but I doubt they'll work very well for a
> 33.6kbps or higher connect rate (due to the density of the constellation).
> 
> Regards,
>   -Rob
> 
> 
> -- 
> TriLUG mailing list        : http://www.trilug.org/mailman/listinfo/trilug
> TriLUG Organizational FAQ  : http://trilug.org/faq/
> TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
> TriLUG PGP Keyring         : http://trilug.org/~chrish/trilug.asc