Florian Zumbiehl wrote:
> Well, that's what I meant by "With VoIP, it can be
somewhat difficult to
> get hold of that DAC's clock, [...]". However, I'd
argue that
> gettimeofday() (alone) is not the only possibility, but
rather the
> timing of incoming packets usually is likely to be
derived from the same
> clock that also drives the DAC, so that could be used
for timing
> outgoing packets on VoIP connections, too. Even though
a kind of PLL
> between the incoming packets and the transmission
scheduler probably
> would be sensible then, so as to reduce jitter and to
ensure
> uninterrupted transmission in case silence suppression
kicks in or
> something.
>
> And then there is RTCP, of course ...
>
The incoming timing is pretty much useless for VoIP, for a
couple of
reasons.
First, in an openpbx to openpbx connection, there is nothing
to get
things started if you just rely on the other end. Also, it
would only
work if the packet rate is the same from both ends. Most
commonly, that
is the case. Don't expect it to be true at all times,
though.
Second, VoIP channels stop and start with VAD, and other
flow control
schemes. Also, jitter would demand a pretty long settling
time for a
PLL, so I doubt such a thing could work. Also, if both ends
used that
kind of PLL scheme they could hunt around trying to track
each other.
Something might be possible, but it seems like a research
topic. Having
had no time to do the research we currently send from a
local clock,
which does at least get things functional.
Regards,
Steve
_______________________________________________
Openpbx-dev mailing list
Openpbx-dev openpbx.org
http://lists.openpbx.org/mailman/listinfo/openpbx-dev
|