See if this article is helpful http://wiki.snom.com/FAQ/How_to_fix_my_Snom_phone's_audio_problems_with_Fritzbox%3F Thanks, Moishe Grunstein Tornado Computer Systems, Inc. 212.400.7650 888.IPPBX.US Service Request Email: support@nysolutions.com<mailto:support@nysolutions.com> Polycom Certified VAR Microsoft Small Business Specialist, Cisco SMB Select Certified [cid:image001.jpg@01C72F94.9EE45D60]<http://www.nysolutions.com/> Computer Networking * Managed Services * IP Video Surveillance * Network Assessments * Web Solutions * Voice over IP * Disaster Recovery * Network Security * Site Surveys * CMS From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Hristo Trendev Sent: Monday, December 09, 2013 6:35 AM To: freeswitch-users@lists.freeswitch.org Subject: [Freeswitch-users] autofix incorrect packetization Hi, I get choppy audio in conferences from endpoints that send G722@30ms packets. The endpoint in question is a FRITZ!Box CPE and this seems to be a known problem with these type of devices. They simply ignore the offered ptime in SDP and stick to sending 30ms RTP packets no matter what. The last time I tested with a FRITZ!Box CPE was in February and I am absolutely sure that FS used to auto fix this type of problems in the past and when this was happening I would see the following lines in the logs: "Asynchronous PTIME not supported, changing our end from 20 to 30" "Changing Codec from G722@20ms@8000hz to G722@30ms@8000hz" and also something to do with timer resolution being increased to deal with 30ms intervals. This doesn't happen any more (v1.2.14) and all I can hear is choppy audio from these CPEs. The only relevant lines I could find in the logs were: "mod_conference.c:3590 Setup timer soft success interval: 20 samples: 160" "switch_core_io.c:759 Engaging Read Buffer at 640 bytes vs 240" I also verified with a packet trace that FS is indeed receiving RTP packets with payload of 240 bytes, which would correspond to 30ms and is sending packets with 160 bytes of payload (20ms), so as far as I can tell this would actually classify as async ptime. I only see the problem one way - the choppy audio comes from the remote party, which is sending the 30ms packets into the conference. The remote party however still hears normal audio coming from the conference (although it is packetized and sent out at 20ms). Could it be that for some reason FS or the conference application is mistakenly treating the 30ms packets as 20ms ones when mixing the audio into the conference? I do recognize that this is caused by misbehaving end device and it is not a FS issue, but I just wanted to know if someone else is also seeing similar problems or if this can somehow be related to a recent change in the FS code? I have updated to v1.2.15 so I can retest, but I will only get a chance to do it on Friday. Best Hristo
