[Asterisk-Users] IAX voice distortion with full upload channel / SIP ok

[tim panton]

On 14 Jan 2006, at 10:47, Koopmann, Jan-Peter wrote:

> Hi,
>
> this is the scenario:
>
> One * is placed in a central location with more than enough up/down
> bandwidth. One * is placed behind a DSL 3000/384. Both * are linked  
> via
> IAX trunking. Everything is fine until the upload channel of the  
> remote
> site is filled with a download, then heavy voice distortion starts.  
> Well
> of course this is expected. So I fooled around with HFSC QoS  
> scheduling
> on the remote site Linux machine. The scheduling seems to work as the
> TOS marked traffic is put in the correct queue and the upload bandwith
> for other applications is going down.
>
> BUT: The voice quality problems definatly stay when using IAX. The  
> funny
> part: Doing the same with SIP shows no big problems. SIP calls to
> T-Online work nicely and even if I change the * <-> * link from IAX to
> SIP everything is fine even with full up-/downloads on the remote DSL
> connection.
>
> My conclusion would be that this depends on the IAX implementation
> somehow. I tried different settings for jitterbuffer, trunk and
> trunktimestamp all with the same result. This currently means we go  
> back
> to SIP for *<->* linkage.
>
> Any ideas? If I should rather post this over in -dev please let me  
> know!

That is weird, you would expect IAX to do better than SIP (bandwidth  
wise)
especially if you have trunking enabled.

Some questions :
	1) are you sure IAX trunking is actually happening ?
	2) what codecs are you using. Are the codecs the same for IAX as
for sip?
	3) is it possible that some of the network hardware is 'sip aware'
and is doing some additional QOS magic for you ?
	4) How many simultaneous calls are you running between the 2 endpoints?
	5) What happens if you turn trunking off ?

Tim.


http://www.westhawk.co.uk/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20060114/9ea9fd14/attachment.htm