Throughout the discussion about this problem, I've learned more or less
what the causes are. But.
is rfc3389 support planned?
thanks
___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
To
hi
with silence suppression enabled I get these:
Oct 12 15:45:55 NOTICE[1104014256]: rtp.c:289 process_rfc3389: RFC3389
support incomplete. Turn off on client if possible
is rfc3389 support planned?
roy
___
Asterisk-Users mailing list
[EMAIL
Roy Sigurd Karlsbakk wrote:
hi
with silence suppression enabled I get these:
Oct 12 15:45:55 NOTICE[1104014256]: rtp.c:289 process_rfc3389: RFC3389
support incomplete. Turn off on client if possible
is rfc3389 support planned?
I don't know if it's planned, but one of the features required to
Why not use an NTP timing source - go stratum 2 or 3. That should be
plenty for a stable clock source.
On Oct 12, 2004, at 9:52 AM, Eric Wieling wrote:
Roy Sigurd Karlsbakk wrote:
hi
with silence suppression enabled I get these:
Oct 12 15:45:55 NOTICE[1104014256]: rtp.c:289 process_rfc3389:
Darren Sessions wrote:
Why not use an NTP timing source - go stratum 2 or 3. That should be
plenty for a stable clock source.
*Timing* is what is needed, not _time_. Two different things. Besides
the obvious problems with using a remote network resource as a timing
device, I don't think many
Christopher L. Wade wrote:
Besides the obvious problems with using a remote network resource
as a timing device
Um, [hit head with idiot stick], I guess the incoming RTP stream would
be a 'remote network resource used as a timing device'. But in some
situations, we see the _problems_ with this,
We use NTP clock sources for a clock source on many of our physical T1
circuits. We use an outside stratum 1 clock source for our internal
server (stratum 2) and because we have our own server, we clock
everything else off of it (stratum 3).
Maybe I'm not familiar enough with the internals of
*Timing* is what is needed, not _time_. Two different things.
Besides the obvious problems with using a remote network resource as a
timing device, I don't think many NTP server admins would enjoy you
requesting a _time_ update on the order of 1000+ times a second? RTP
not relying on
Darren Sessions wrote:
We use NTP clock sources for a clock source on many of our physical T1
circuits. We use an outside stratum 1 clock source for our internal
server (stratum 2) and because we have our own server, we clock
everything else off of it (stratum 3).
Maybe I'm not familiar enough
Darren Sessions wrote:
Why not use an NTP timing source - go stratum 2 or 3. That should be
plenty for a stable clock source.
*Timing* is what is needed, not _time_. Two different things. Besides
the obvious problems with using a remote network resource as a timing
device, I don't
10 matches
Mail list logo
