[asterisk-dev] zaptel timer for sip to iax proxy

[Mark Spowage]

clue #2
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
asterisk :)..

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,
> either
> 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
> headers
> by multiplexing several calls into a single packet).
>
> I'm guessing what you are seeing is the difference in timing in the
> softphone
> 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 ;-)
>
> T.
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>



-- 
-----
Fight back spam! Download the Blue Frog.
http://www.bluesecurity.com/register/s?user=c3Bvd2FnZTI3NTk%3D