Audio dropped between asterisk servers

Hello,

I have a set up with two asterisk servers, and am having problems with the incoming voice not working on some calls.

One server is in an office (“remote Server”), and the other (“main Server”) is in a rack in a colocation center. Remote server has a DSL connection which is used only for VOIP traffic. Users sit in the remote office, and use a sip client to connect to the remote server. Any calls which are not destined for another extension at the remote office get sent to the main server for delivery.

Most of the time calls work fine, but on about 1 in 20 calls the caller cannot hear the person they are calling, although the person who recieve the call can hear the caller.

When this happens, I see the error message on the interface of the server in the office:

Nov 20 15:41:14 WARNING[2921]: chan_iax2.c:7665 socket_read: Received mini frame before first full voice frame
Nov 20 15:41:14 WARNING[2921]: chan_iax2.c:7665 socket_read: Received mini frame before first full voice frame
Nov 20 15:41:14 WARNING[2921]: chan_iax2.c:7665 socket_read: Received mini frame before first full voice frame
Nov 20 15:41:14 WARNING[2921]: chan_iax2.c:7665 socket_read: Received mini frame before first full voice frame
Nov 20 15:41:14 WARNING[2921]: chan_iax2.c:7665 socket_read: Received mini frame before first full voice frame
… this message repeats many (100+) times.

I have these settings in the iax.conf:
[general]
register => UUUUUUUU:XXXXXXX@999.999.999.999
iaxcompat=yes
bandwidth=high
disallow=all
allow=ulaw
allow=alaw
jitterbuffer=no
forcejitterbuffer=no
trunktimestamps=yes
tos=lowdelay
autokill=yes

[remsales]
context=mlogiqin
type=friend
username=UUUUUUUU
secret=XXXXXXXX
host=999.999.999.999
disallow=all
allow=ulaw
allow=alaw

Any suggestions would be appreciated!

Thanks,
Ord

[quote=“omillar”]Hello,

I have a set up with two asterisk servers, and am having problems with the incoming voice not working on some calls.

One server is in an office (“remote Server”), and the other (“main Server”) is in a rack in a colocation center. Remote server has a DSL connection which is used only for VOIP traffic. Users sit in the remote office, and use a sip client to connect to the remote server. Any calls which are not destined for another extension at the remote office get sent to the main server for delivery.

Most of the time calls work fine, but on about 1 in 20 calls the caller cannot hear the person they are calling, although the person who recieve the call can hear the caller.

When this happens, I see the error message on the interface of the server in the office:

Nov 20 15:41:14 WARNING[2921]: chan_iax2.c:7665 socket_read: Received mini frame before first full voice frame
Nov 20 15:41:14 WARNING[2921]: chan_iax2.c:7665 socket_read: Received mini frame before first full voice frame
Nov 20 15:41:14 WARNING[2921]: chan_iax2.c:7665 socket_read: Received mini frame before first full voice frame
Nov 20 15:41:14 WARNING[2921]: chan_iax2.c:7665 socket_read: Received mini frame before first full voice frame
Nov 20 15:41:14 WARNING[2921]: chan_iax2.c:7665 socket_read: Received mini frame before first full voice frame
… this message repeats many (100+) times.

I have these settings in the iax.conf:
[general]
register => UUUUUUUU:XXXXXXX@999.999.999.999
iaxcompat=yes
bandwidth=high
disallow=all
allow=ulaw
allow=alaw
jitterbuffer=no
forcejitterbuffer=no
trunktimestamps=yes
tos=lowdelay
autokill=yes

[remsales]
context=mlogiqin
type=friend
username=UUUUUUUU
secret=XXXXXXXX
host=999.999.999.999
disallow=all
allow=ulaw
allow=alaw

Any suggestions would be appreciated!

Thanks,
Ord[/quote]

can you show the iax.conf on SERVER A and SERVER B

can you show CLI for SERVER A : iax2 show peers and iax2 show registry and iax2 show users . also do the same for server B

also can you show a channel up and “running” between the 2 servers?

is there any networking considerations? NAT? NAT on both sides? direct VPN?

what version of asterisk are you running?

also is it 5% completely random? or can you reproduce the error? is at after say 5 calls are online ? The reason I ask is I have seen WIERD behavious when passing traffic through sonic walls with all of the IDS virus, spam blah blah blah bells and whistles turned on. The problem was ALOT like this, un replicatable, 100% random. then simply put a stupid linksys up doing nothing but nat, and the problem vanished.

Thanks for the help. The details for the servers are below.

The 5% does seem random. I have only seen it happen when there was one call in progress at once. Typically there are from 1-4 calls going on at any one time.

This morning I added jitterbuffer=yes and trunk=yes to both iax.conf files, and have not seen it happen since. I do still get some of the

Nov 21 09:42:58 WARNING[2921]: chan_iax2.c:7665 socket_read: Received mini frame before first full voice frame

errors, but this only repeats 4 or 5 times whereas it repeated continuously before.

Thanks again for the help.

This is serverA - no NAT.

[general]

jitterbuffer=yes
tos=lowdelay

disallow=all
allow=ulaw
allow=alaw

; omitted registers to our providers

[remsales]
trunk=yes
disallow=all
allow=ulaw
allow=alaw
type=friend
host=dynamic
user=remsales
secret=XXXXXXXX
context=remote

crocop*CLI> iax2 show peers
Name/Username Host Mask Port Status
remsales 70.52.14.157 (D) 255.255.255.255 60012 Unmonitored
1 iax2 peers [0 online, 0 offline, 1 unmonitored]

crocop*CLI> iax2 show registry
Host Username Perceived Refresh State
64.26.157.230:4569 5146670717 204.19.186.5:4569 60 Registered
64.26.157.230:4569 6477235349 204.19.186.5:4569 60 Registered
64.26.157.230:4569 8885944272 204.19.186.5:4569 60 Registered
64.26.157.230:4569 8885448218 204.19.186.5:4569 60 Registered
64.26.157.230:4569 8884439126 204.19.186.5:4569 60 Registered
64.26.157.230:4569 8882502391 204.19.186.5:4569 60 Registered
64.26.157.230:4569 8882453880 204.19.186.5:4569 60 Registered
64.26.157.230:4569 5146670638 204.19.186.5:4569 60 Registered
64.26.157.230:4569 5149070873 204.19.186.5:4569 60 Registered
64.26.157.230:4569 5149070872 204.19.186.5:4569 60 Registered

crocop*CLI> iax2 show users
Username Secret Authen Def.Context A/C Codec Pref
remsales XXXXXXXX 000000000000003 remote No Host
8885448218 -no secret- 000000000000003 lepto-inbound No Host
6477235349 -no secret- 000000000000003 pptc-inbound No Host
5146670717 -no secret- 000000000000003 pptc-inbound No Host
5149070873 -no secret- 000000000000003 pptc-inbound No Host
8884439126 -no secret- 000000000000003 pptc-inbound No Host
8882502391 -no secret- 000000000000003 fic-inbound No Host
8882453880 -no secret- 000000000000003 unlimitel-inbou No Host
5149070872 -no secret- 000000000000003 fic-inbound No Host

This is server B - has NAT

iax.conf is shown in the previous post. Since then I have added trunk=yes and jitterbuffer=yes.

penn*CLI> iax2 show peers
Name/Username Host Mask Port Status
remsales/remsal 204.19.186.5 (S) 255.255.255.255 4569 Unmonitored
1 iax2 peers [0 online, 0 offline, 1 unmonitored]

penn*CLI> iax2 show registry
Host Username Perceived Refresh State
204.19.186.5:4569 remsales 70.52.14.157:60012 60 Registered

penn*CLI> iax2 show users
Username Secret Authen Def.Context A/C Codec Pref
remsales XXXXXXXX 000000000000003 mlogiqin No Host

Here are some in progress calls:

crocop*CLI> iax2 show channels
Channel Peer Username ID (Lo/Rem) Seq (Tx/Rx) Lag Jitter JitBuf Format
IAX2/remsales-9 70.52.14.157 remsales 00009/00003 00013/00010 00040ms 0000ms 0040ms ulaw
IAX2/64.26.157.230:4 64.26.157.230 5149070872 00019/00473 00011/00012 00040ms 0000ms 0040ms ulaw
2 active IAX channels

penn*CLI> iax2 show channels
Channel Peer Username ID (Lo/Rem) Seq (Tx/Rx) Lag Jitter JitBuf Format
IAX2/remsales-1 64.26.157.230 remsales 00001/00027 00003/00003 00000ms 0000ms 0040ms ulaw
IAX2/remsales-3 64.26.157.230 remsales 00003/00473 00001/00001 00040ms 0000ms 0040ms ulaw
IAX2/remsales-4 64.26.157.230 remsales 00004/00127 00007/00007 00000ms 0000ms 0040ms ulaw
3 active IAX channels

It turns out that turning on jitterbuffer did not solve the problem, it is still happening.

Try to lower your MTU. It worked for me (1492 on Czech DSL line).