[asterisk-users] lost packets when bridging zap and iax

[Rich Adamson]

Simone Cittadini wrote:
> We have a machine with a TE410P in it acting as a client to route calls 
> via iax2 to our central server,
> 
> caller --> ( zap -> iax ) ---> ( iax -> whatever ) --> called
>                 client                  server
> 
> often the called can't hear the caller (both machines on public ip)
> 'iax2 show netstats" on client machine shows more and more dropped 
> packets on the local side
> 
> if we use sip as the "entering point" for the calls all works well :
> 
> caller --> ( sip -> iax ) ---> ( iax -> whatever ) --> called
>                 client                  server
> 
> seems something in the bridging between zap and iax screws up, but I 
> don't know if it's a bug or a misconfiguration, my conf files follows, 
> someone has similar experiences to share ?
> 
> /etc/asterisk# cat iax.conf
> 
> [general]
> bindport=4569
> bindaddr=xxx.xx.xx.xxx
> 
> disallow=all
> allow=alaw
> 
> jitterbuffer=yes
> forcejitterbuffer=no
> 
> tos=lowdelay
> autokill=yes
> 
> language=it
> notransfer=yes
> 
> 
> /etc/asterisk# cat sip.conf
> 
> [general]
> 
> context=invalid
> 
> bindport=5060
> bindaddr=xxx.xx.xx.xxx
> 
> srvlookup=no
> 
> disallow=all
> allow=alaw
> 
> progressinband=no
> canreinvite=no
> 
> language=it
> 
> [authentication]
> 
> [some-ip]
> type=friend
> context=ip
> host=some-ip
> 
> 
> /etc/asterisk# cat zapata.conf
> 
> [channels]
> language=it
> context=default
> 
> switchtype=euroisdn
> pridialplan=national
> prilocaldialplan=national
> signalling=pri_cpe
> immediate=no
> 
> callerid=asreceived
> usecallingpres=yes
> 
> echocancel=yes
> echocancelwhenbridged=no
> ;echotraining=yes
> 
> rxgain=0.0
> txgain=0.0
> 
> group=1
> callgroup=1
> pickupgroup=1
> 
> group = 1
> channel => 1-15
> channel => 17-31
> 
> channel => 32-46
> channel => 48-62
> 
> channel => 63-77
> channel => 79-93
> 
> channel => 94-108
> channel => 110-124
> 
> 
> /etc/asterisk# cat /etc/zaptel.conf
> 
> span=1,1,0,ccs,hdb3
> bchan=1-15
> dchan=16
> bchan=17-31
> 
> span=2,1,0,ccs,hdb3,crc4
> bchan=32-46
> dchan=47
> bchan=48-62
> 
> span=3,1,0,ccs,hdb3
> bchan=63-77
> dchan=78
> bchan=79-93
> 
> span=4,1,0,ccs,hdb3
> bchan=94-108
> dchan=109
> bchan=110-124
> 
> loadzone=it
> defaultzone=it

Only "one" of the above four "span" entries should have a "1" as the 
second digit. That second digit is telling the digium card which span to 
sync its on-board clock to. Pick the span that goes to a central office 
and specify it as "1" and all other spans should be either "0" or 
increasing numerical digits (eg, 2,3,4).

If none of the spans go to a central office, its still a problem.

You'll have to reload the drivers for the change to take effect.