Summary:	ASTERISK-11672: Choppy voicemail recording for SIP calls via TELES softswitch
Reporter:	Fabian Hoppe (fabianhoppe)	Labels:
Date Opened:	2008-03-18 05:07:04	Date Closed:	2011-06-07 14:03:11
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_voicemail
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	PROBLEM SUMMARY We're experiencing severe audio problems with (voicemail) recordings on our Asterisk servers for calls originating from a SIP provider using a TELES softswitch/PSTN-gateway. Calls originating from a __PSTN-source__, encoded from SS7 to VOIP by the TELES gateway and then routed via his TELES softswitch to us show strange audio artefacts. Calls originating from a _VOIP source_, bypassing the providers PSTN gateway but still being routed via the TELES softswitch don't show the artefacts. Calls coming in from other SIP providers (using other softswitches) are recorded just fine. The problem is reproduceable and is related to the recording part as the record application shows the some behaviour. The perceived audio quality is in any case very good. Replacing the call to voicemail by the echo application shows a perfect audio quality. PROBLEM SYMPTOMS While systems announcements (especially voicemail menus and personal announcements) are replayed cristal clear, the recordings are often choppy and miss the audio signal in a range of fractions of a second up to several seconds. Please refer to the attached WAV files which were recorded in parallel, one originated in the PSTN coming in via the TELES gateways and the TELES softswitch as SIP call w/ GSM codec and one originating from a VOIP source, coming bypassign the TELES gateway but being still routed through the TELES softswitch. The problem is reproducable using the ALAW codec. OUR FINDINGS SO FAR - RTP packet size is 20ms for all calls - Jitter is not a problem (<5ms) - Packet loss is not a problem (0%) - Enabling the SIP jitterbuffer nevertheless (including the JB for app patch as proposed by Russell Bryant) has no effect - The network connection between the TELES softswitch and our servers is irrelevant to the issue as it can be reproduced with an Asterisk server installed in the same GBit-LAN as the softswitch - The load of the system is not relevant (the test systems have a load near 0) - zaptel-precision is not an issue (and 99,99% on all system anyway) - problem can be reproduced with using format_wav and format_wav_gsm - problem persistes even if the 32KB writebuffer for the write-function is enabled (as proposed by another bug report / feature request in mantis) MY QUESTIONS - Can someone analyse the attached tcpdump for any differences in the two audio stream which might cause the audio artefacts? Are there any differences? - Are implementation variances for the GSM and ALAW codecs possible? - Any ideas but chosing another SIP provider? ****** ADDITIONAL INFORMATION ****** OUR ENVIRONMENT INTEL DUO CORE 2,6 GHz, 2GB RAM openSuSe 10.2 Kernel 2.6.22-5-31 with HP Timer Support and Timer set to 1000hz mysql 5.0.26 Asterisk 1.4.18 with ARA (SIP, QUEUES, VOICEMAIL) but static dialplan TC400B trabscoder card installed and configured Zaptel 1.4.8 with wtc4xx and ztdummy support with zttest reporting 99,99X% timing accuracy even under high system load SIP-only environment FURTHER DETAILS voicemail.conf [general] format=wav|gsm|wav49 fromstring = XXXXXx emailsubject = Neue Sprachnachricht von ${VM_CIDNUM} emailbody = XXXXXXXX attach = yes maxmsg = 100 maxmessage = 180 minmessage = 3 maxgreet = 60 skipms = 3000 maxsilence = 10 silencethreshold = 128 maxlogins = 3 emaildateformat = %d.%m.%C um %H:%M:%S serveremail=XXXXXX attach=yes skipms=3000 maxsilence=10 silencethreshold=128 maxlogins=3 odbcstorage=asteriskVM odbcstoragewrite=asteriskVMwrite odbctable=tblvoicemessages emaildateformat=%A, %B %d, %Y at %r sendvoicemail=yes Log of voicemail recording -- Recording the message -- x=0, open writing: /var/spool/asterisk/voicemail/K0001/121/tmp/dqaSDF format: wav, 0x875db38 -- x=1, open writing: /var/spool/asterisk/voicemail/K0001/121/tmp/dqaSDF format: gsm, 0x8cef3c0 -- x=2, open writing: /var/spool/asterisk/voicemail/K0001/121/tmp/dqaSDF format: wav49, 0x8e7d9f8 -- User hung up == Parsing '/var/spool/asterisk/voicemail/K0001/121/INBOX/msg0000.txt': Found lsmod excerpt wctc4xxp 54324 0 zttranscode 12168 1 wctc4xxp firmware_class 14080 1 wctc4xxp ztdummy 8376 0 zaptel 190084 26 zttranscode,ztdummy dmesg excerpt Zapata Telephony Interface Registered on major 196 Zaptel Version: 1.4.8 Zaptel Echo Canceller: MG2 ztdummy: Trying to load High Resolution Timer ztdummy: Initialized High Resolution Timer ztdummy: Starting High Resolution Timer ztdummy: High Resolution Timer started, good to go Zaptel Transcoder support loaded ACPI: PCI Interrupt 0000:04:01.0[A] -> GSI 22 (level, low) -> IRQ 19 Registered codec translator 'DTE Encoder' with 92 transcoders (srcs=0000000c, ds ts=00000101) Registered codec translator 'DTE Decoder' with 92 transcoders (srcs=00000101, ds ts=0000000c) Zaptel DTE (G.729a / G.723.1) Transcoder support LOADED (firm ver = 6.12) Found and successfully installed a Wildcard TC: Wildcard TC400P+TC400M ATTACHMENTS A recording of a choppy voicemail coming from PSTN in via the TELES gateway and softswitch, a parallel voicemail coming in from a VOIP source via the TELES softswitch bypassing the TELES gateway and a tcpdump of both calls showing jitter <5ms and no packet loss for both calls can be retrieved under ftp://88.217.254.5, login digium, password digium
Comments:	By: Russell Bryant (russell) 2008-03-18 10:28:06 Please try using a jitterbuffer to see if it helps.  I wrote up some info on how to use the jitterbuffer with voicemail, but my site is currently down.  Here is a link to the google cache of the text ... http://209.85.207.104/search?q=cache:yNxuH3UBZ4YJ:www.russellbryant.net/blog/index.php/2007/10/09/asterisk-jitterbuffer-support-for-applications/+jitterbuffer+support+for+applications&hl=en&client=firefox-a&gl=us&strip=1 By: Fabian Hoppe (fabianhoppe) 2008-03-18 10:44:50 Hi Russel, I already tried that patch (nice work btw) but it had no effect at all. According the wireshark th e jitter is below 5ms anyway... Cheers, Fabian By: Frank Waller (explidous) 2008-03-18 21:29:23 Just for a try, we have seen similar issues with the gcc 4.2 problem from ASTERISK-1118243, so if your compiler was a gcc 4.2.X and if you recompile setting the DONT_OPTIMIZE flage for everything do you still have the problem? By: Fabian Hoppe (fabianhoppe) 2008-03-19 03:26:37 The system has gcc 4.1.2 installed, nevertheless I already tried the DONT_OPTIMIZE flag and it didn't change anything. Is it worth to update to the latest gcc version? By: Fabian Hoppe (fabianhoppe) 2008-03-19 10:36:49 We just installed gcc 4.3.0 and recompiled asterisk 1.4.18 (one time w/o and one time w/ compiler flag DONT_OPTIMIZE). The artefacts are still reproduceable. Is anybody able to analyse the RTP packets in the tcpdump arriving from the softswitch? Can any difference be recognized? By: Russell Bryant (russell) 2008-03-19 11:12:02 I really do appreciate your detailed report.  However, I really do consider this more of a technical support ticket than a bug report.  There is no magic involved in writing files.  Asterisk literally writes out the audio that it receives.  There is nowhere where it can mess up your audio, unless transcoding was broken.  And, we have pretty much ruled the known issues in that area already.  In that case, since this is not a support forum, I'm going to close this out.