hi guys and thanks for taking the time to read this. i will try and keep it short and sweet but also i will try not to miss anything out.
basic description of the fault
The phone rings, the number comes up on the display screen , you pick it up and… silence at both ends
this happens for about 1 in 10 calls, all ports are forwarded, there is plenty of bandwidth and out going calls are all fine. i have been studying the log files and i think i have found the culprit but i have no idea what it meens? i have pasted what i think is the issue below.
2011-07-04 13:01:33] WARNING[3914] chan_sip.c: Asked to transmit frame type ulaw, while native formats is 0x8 (alaw) read/write = 0x8 (alaw)/0x8 (alaw)
[2011-07-04 13:01:33] WARNING[3914] chan_sip.c: Asked to transmit frame type ulaw, while native formats is 0x8 (alaw) read/write = 0x8 (alaw)/0x8 (alaw)
[2011-07-04 13:01:33] WARNING[3914] chan_sip.c: Asked to transmit frame type ulaw, while native formats is 0x8 (alaw) read/write = 0x8 (alaw)/0x8 (alaw)
[2011-07-04 13:01:33] WARNING[3914] chan_sip.c: Asked to transmit frame type ulaw, while native formats is 0x8 (alaw) read/write = 0x8 (alaw)/0x8 (alaw)
[2011-07-04 13:01:33] WARNING[3914] chan_sip.c: Asked to transmit frame type ulaw, while native formats is 0x8 (alaw) read/write = 0x8 (alaw)/0x8 (alaw)
[2011-07-04 13:01:33] WARNING[3914] chan_sip.c: Asked to transmit frame type ulaw, while native formats is 0x8 (alaw) read/write = 0x8 (alaw)/0x8 (alaw)
[2011-07-04 13:01:33] WARNING[3914] chan_sip.c: Asked to transmit frame type ulaw, while native formats is 0x8 (alaw) read/write = 0x8 (alaw)/0x8 (alaw)
[2011-07-04 13:01:33] WARNING[3914] chan_sip.c: Asked to transmit frame type ulaw, while native formats is 0x8 (alaw) read/write = 0x8 (alaw)/0x8 (alaw)
[2011-07-04 13:01:33] WARNING[3914] chan_sip.c: Asked to transmit frame type ulaw, while native formats is 0x8 (alaw) read/write = 0x8 (alaw)/0x8 (alaw)
if anyone knows what the problem is and how i can fix it i would be eternally great full.
thanks in advance
You have a CODEC mismatch somewhere (hence the alaw v ulaw error)
thanks for your reply,
i figured that so i rang my SIP provider (gradwell) and they confirmed that was most likely to be the cause of the problem. they said thy support all codecs but the main one is ulaw, i had tickes in ulaw,alaw and gsm so i removed the tickes from the other 2 and left ulaw selected. this was done at about 5pm today so everyone had gone home and the phones have not rang to test it.
once again thank you for your reply and i will update tomorrow to let you know if it has sorted it out.
thanks
just a quick update.
i spoke with gradwell and they recommended using ulaw on its own, i did this as mentioned above and again it happened again this morning but this time it was slightly different, we had the silence at both ends but then after a few seconds we got darlek like noises. i know that usually darlek like noises are bandwidth related but we have a BT infinity line running at 40up and 10 down and there were only 2 people on the phone so i dont think its a bandwidth issue.
i have now change the codec to alaw to see if that helps any but one think i cant understand is, why has everything been fine for the past 6 months with alaw,ulaw and gsm ticked and now its all gone wrong?
once agian thank you for taking the time to read this and any help or input is hugely appreciated
sorry to keep posting, i just thought the spec of the PBX may come in handy
Processors 2
Model Pentium® Dual-Core CPU E5500 @ 2.80GHz
CPU Speed 2.8 GHz
Cache Size 2.00 MB
System Bogomips 11203.39
PCI Devices - Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
- Host bridge: Intel Corporation 4 Series Chipset DRAM Controller
- IDE interface: Intel Corporation 82801G
- IDE interface: Intel Corporation N10/ICH7 Family SATA IDE Controller
- ISA bridge: Intel Corporation 82801GB/GR
- PCI bridge: Intel Corporation 82801 PCI Bridge
- PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1
- USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1
- USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2
- USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3
- USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4
- USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller
- VGA compatible controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller
IDE Devices none
SCSI Devices - ATA Corsair CSSD-V32 (Direct-Access)
- TSSTcorp CDDVDW SH-S223C (CD-ROM)
USB Devices none
more updates,
in the incoming setting of the actual trunk settings it was specified to
disallow =all
allow-g729&gsm
i have changed this to match the other config page so it now reads allow=alaw
i am only updating this post in case anyone else is having this issue
we will see how we go.
and as i was typing this post it has just done it again so back to the drawing board!
any help is appreciated
If you do a ‘sip show settings’ and a ‘sip show peer trunkname’ what is in the CODEC order field?
hi sorry for the dumb question, how would i do that?
also i noticed today that the modem is getting quite warm and i dont think its upto the job, its netgear dg834gt. i have just oredered a draytek to replace it and that shoud be here in the morning.
thanks
Those are Asterisk CLI commands. You have to substitute trunkname for the name of your trunk.
The Asterisk CLI is accessed via asterisk -r
I am curious, how can you administer one of these system and not have ever seen Asterisk?
hi again, thanks for your patience.
usually i do not administer the PBX, as a rule i am computer systems admin only, however the chap that usually maintains the PBX is on annual leave and as a result the task has been left with me, hence my very limited experience with the system.
anyway it seems i have fixed it, well i dont want to speak too soon but it was happening about 15 times a day and as of 1:30 yesterday it has not happened once. and i think i have also found an explanation for the problem also.
after going back to basics i decided to work from the ground up to make sure everything was by the book. and whilst in the modem checking ports were forwarded correctly i noticed that logging was enabled in the router for the port forwarding rules. i disabled the logging and the problem got better, now it was happening about 50% less. i can only guess that due to the sheer amount of traffic that the modem was trying to log it was using its resources logging and not routing. to cut a long story short i put the draytek in yesterday at 1:30pm and touch wood all is fine. i know that the netgear was never the ideal VOIP router but when you are given a budget to work too what can you do??
once again i would like to thank everyone that had a go at helping me and i hope this post comes in handy to someone else in the future.
i am 98% confident that the modem was the issue, but if the problem comes back i will be sure to resurrect this post !
thanks again