No subject

packet captures, it seems that while each new
channel can access/map a timingfd for use with
internal_timing, the timer itself has a single
core clock rate.

I made some changes to add a clockrate variable to
the channel structure, and used ast_settimeout to
establish a clockrate appropriate for the RTP
packetization timing required.  This approach was
only partially a success (and a tad ugly).
A further note on this approach, if a caller is
accessing an internal Asterisk app that uses
ast_streamfile(), the timing is reset to 20ms, and
without storing the timing requirement on the
channel structure, there is no easy obvious way
to restore the timing the channel requires.  Even
with storing it on the channel structure, it requires
calling ast_settimeout with the channel's required
timing after every call to ast_streamfile (way too
ugly to live)

I found that in a two party case, with no media
re-invites and different packetization requirements,
that the last party to establish their RTP session
would govern the clockrate.  That party would receive
their RTP packets at a regular interval which would
be very close to the correct timing.  The other party
would receive a very jittery RTP stream, with the actual
udp packet timestamp being a multiple of the 2nd parties
packetization interval.

I thought the issue might be in the smoother, and to
a degree it is.  Since there appears to be a limitation
of a single core clock when using the timer fd, the
smoother has to 'batch' RTP packets when it has enough
audio data for more than one RTP packet.  The smoother
code can easily be fixed to only send one audio packet,
but that requires that it be called/trigger at the correct
interval.

If you've followed my poor description this far, my question
is can the /dev/[zap|dahdi]/timer interface support different
clockrate for each channel that opens it?  If it cannot, then
bug 014021 cannot be solved in 1.4 or 1.6.0, at least not with
trivial changes to the code.  It might be possible to resolve
it in 1.6.1 using the new res_timing_* interfaces.

Dan