[asterisk-dev] zaptel timer for sip to iax proxy
spowage at gmail.com
Mon Nov 10 07:07:40 CST 2008
The first test today was to replace the embedded asterisk side with
a pc, and test with the Echo command. Voila, no problem.
Interesting, this problem came about after adding gtalk to the embedded
Gtalk from embedded to embedded is just fine, however embedded
to asterisk (gateway) via iax is choppy. Simple divide and conquer.
Well perhaps back off on gtalk for a start. Why the embedded board
chops up iax and not gtalk is peculiar.
Any suggestions are welcome.
For now i will remove gtalk.. and try to doctor iax.
Though now i am considering investing time in gtalk to do without iax,
now that should shake a few trees in the jungle :)
Why hang on to iax if gtalk can be made to deal with multiple inbound calls ?
On Mon, Nov 10, 2008 at 5:44 AM, Tim Panton <thp at westhawk.co.uk> wrote:
> On 10 Nov 2008, at 04:56, Mark Spowage wrote:
>> if just ONE sip phone is proxied , will IAX get choppy without a
>> zaptel timer ?
>> tests here at times are ok and other times often choppy
>> a zaptel timer seems to be required for trunking, but why bother for
>> just a few channels, a major effort
>> to get zaptel and a timer integrated,as well as more memory for an
>> embedded machine short on memory.
>> now if trunking is not used, then why would iax be choppy for serving
>> as a sip proxy or bridge between sip phones ?
>> a zaptel timer is on the main iax server side, but NOT on the
>> embedded side
>> gtalk never sounds choppy , so what is iax all chopped out about ?
>> ast 1.6 & 1.4 both sound ok at times and choppy at times as well
>> currently 1.6 is on the embedded side and 1.4 on the server.. perhaps
>> they both need to be the same version
>> is this some kind of iax circus ? :) help ! sinking in the iax
>> choppy sea
>> playing musiconhold from either side can come in chopped as well,
>> where as gtalk is always smooth..
>> grief !
> Mark, I think we need some more context to help answer properly.
> In the meanwhile here is my understanding of the situation....
> chan_iax (and most of asterisk) is externally clocked, i.e. if it is
> bridging a pair of
> channels then receiving an inbound voice frame will cause a voice
> frame to
> be sent out of the other end of the bridge. This works pretty well in
> cases where
> the incoming audio is being sampled (and sent) at a constant rate.
> There are a number of places where this won't work - e.g. meetme, where
> there isn't a single channel to use as a clock (each channel will
> drift slightly
> wrt the others), in this case Asterisk derives timing from the kernel,
> via a real telephony device (e.g. a PRI card) or from a kernel resource
> (timers etc) via zap_dummy.
> IAX trunking is another of these examples - audio from several channels
> need to be put into a single packet, so asterisk uses the kernel timer
> to decide when to send a packet. (Note this is _not_ the same as
> just using IAX to connect to a ITSP, IAX trunking tries to save on
> by multiplexing several calls into a single packet).
> I'm guessing what you are seeing is the difference in timing in the
> you are using - The IAX one is probably not using the local audio
> hardware to
> generate the timing, whereas the Gtalk one is.
> Might that make sense ?
> If not, give us some more clues ;-)
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
Fight back spam! Download the Blue Frog.
More information about the asterisk-dev