[Home]

Summary:ASTERISK-20341: playback of files from asterisk-core-sounds-en-g722-current sound garbled and half speed on Audiocodes and Yealink phones
Reporter:David Brillert (aragon)Labels:
Date Opened:2012-08-29 21:23:48Date Closed:2012-09-28 17:58:07
Priority:MinorRegression?Yes
Status:Closed/CompleteComponents:Codecs/codec_g722
Versions:1.8.16.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Attachments:( 0) core_show_translation.txt
( 1) ext221_comedianmail_g722_CLI1.rar
( 2) ext221_comedianmail_g7221.pcap
( 3) ext221_comedianmail_g7222.rar
( 4) messages.rar
( 5) sip.conf
( 6) sip1.pcap
Description:I know g722 is properly configured and it sounds perfect between 2 phones with G722 enabled.
But playing back vm-password.g722 sounds underwater.
[2012-08-29 22:06:07]     -- <SIP/501-00000122> Playing 'vm-password.g722' (language 'en')
Tested with Audiocodes 320HD, 420HD, and Yealink T28P, Aastra 57i (Polycom untested).
Downloaded the sounds file today from http://downloads.asterisk.org/pub/telephony/sounds/ to be sure I had latest files before opening a ticket.

Hard to believe this is a bug but I can reproduce every time.
Comments:By: Rusty Newton (rnewton) 2012-09-06 17:18:42.266-0500

How do other g722 files from the same pack sound? Do any others exhibit the issue, or just this one file?
By: David Brillert (aragon) 2012-09-06 18:58:14.414-0500

I randomly tested a few sounds and they all sounded like fish talk.

[2012-09-06 19:56:10]     -- <SIP/220-00000003> Playing 'T-is-not-available.g722' (language 'en')
[2012-09-06 19:56:12]     -- <SIP/220-00000003> Playing 'a-collect-charge-of.g722' (language 'en')
[2012-09-06 19:56:15]     -- <SIP/220-00000003> Playing 'vm-passchanged.g722' (language 'en')
[2012-09-06 19:56:19]     -- <SIP/220-00000003> Playing 'vm-pls-try-again.g722' (language 'en')
[2012-09-06 19:56:22]     -- <SIP/220-00000003> Playing 'to-report-emergency.g722' (language 'en')
[2012-09-06 19:56:25]     -- <SIP/220-00000003> Playing 'demo-congrats.g722' (language 'en')
By: Rusty Newton (rnewton) 2012-09-07 09:26:28.924-0500

What happens with playback of ulaw sound files, or any other files besides g722 ?

Please post your sanitized sip.conf , plus an Asterisk log of a test call demonstrating the issue with VERBOSE and DEBUG message types turned on at level 5. If you can, at the same time gather a SIP and RTP packet trace (tcpdump, wireshark) of that call. Please attach all the debug to the issue as separate files.

https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines

https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information
By: David Brillert (aragon) 2012-09-07 12:06:34.921-0500

Its super easy to reproduce.
Enable g722 in the sip.conf for the peer and playback any of the g722 files and they sound like fish.
SLIN, ULAW sound fine.

I'll upload the files later when I have some time on my hands.
By: Rusty Newton (rnewton) 2012-09-17 16:29:49.222-0500

Aragon,  please provide the output of "sip show channel <channel>" for the channel demonstrating the issue during playback.  I'll also try to reproduce the issue.
By: David Brillert (aragon) 2012-09-17 16:39:02.435-0500

[2012-09-17 17:36:20]     -- <SIP/501-00000098> Playing 'demo-congrats.g722' (language 'en')
sip*CLI> sip show channels
Peer             User/ANR         Call ID          Format           Hold     Last Message    Expiry     Peer
192.168.192.71   501              3044e82c3b9d406  0x1000 (g722)    No       Tx: ACK                    501

sip*CLI> sip show channel 3044e82c3b9d406

 * SIP Call
 Curr. trans. direction:  Outgoing
 Call-ID:                3044e82c3b9d40683e3c11fb7471f3d2@192.168.192.1:5060
 Owner channel ID:       SIP/501-00000098
 Our Codec Capability:   0x1004 (ulaw|g722)
 Non-Codec Capability (DTMF):   1
 Their Codec Capability:   0x1000 (g722)
 Joint Codec Capability:   0x1000 (g722)
 Format:                 0x1000 (g722)
 T.38 support            No
 Video support           No
 MaxCallBR:              384 kbps
 Theoretical Address:    192.168.192.71:5062
 Received Address:       192.168.192.71:5062
 SIP Transfer mode:      open
 Force rport:            No
 Audio IP:               192.168.192.1 (local)
 Our Tag:                as0d35c74a
 Their Tag:              1478815853
 SIP User agent:         Yealink SIP-T28P 2.61.0.80
 Username:               501
 Peername:               501
 Original uri:           sip:501@192.168.192.71:5062
 Caller-ID:              501
 Need Destroy:           No
 Last Message:           Tx: ACK
 Promiscuous Redir:      No
 Route:                  sip:501@192.168.192.71:5062
 DTMF Mode:              rfc2833
 SIP Options:            (none)
 Session-Timer:          Inactive

By: Rusty Newton (rnewton) 2012-09-17 18:11:22.897-0500

Thanks. I tested this out real quickly on a slightly older version (1.8.11) - what I had on hand, with a Digium D40 and had no problems playing back the sound files you mentioned with G722 - G722. I'll try 1.8.16 when I get a chance.

If you can attach packet captures that would help. Also if you haven't already, you might post on asterisk-users to see if anyone else has experienced similar issues, or can test with your same models of phone and version of Asterisk.


By: David Brillert (aragon) 2012-09-17 18:26:57.772-0500

I tested 1.8.11 and g722 works fine.
Not working with 1.8.16 or 1.8 SVN
By: David Brillert (aragon) 2012-09-17 18:33:14.971-0500

tcpdump attached
By: David Brillert (aragon) 2012-09-20 09:55:51.529-0500

Since this no longer works in 1.8 SVN I am marking this as a regression.
By: Rusty Newton (rnewton) 2012-09-20 16:59:25.872-0500

Just tested on "SVN-branch-1.8-r373242"

Digium D40,

{noformat}

ubuntu*CLI>
 == Using SIP RTP CoS mark 5
   -- Executing [2222@internal_phones:1] Playback("SIP/6002-00000001", "g722/vm-passchanged") in new stack
   -- <SIP/6002-00000001> Playing 'g722/vm-passchanged.g722' (language 'en')
   -- Executing [2222@internal_phones:2] Playback("SIP/6002-00000001", "g722/demo-congrats") in new stack
   -- <SIP/6002-00000001> Playing 'g722/demo-congrats.g722' (language 'en')
ubuntu*CLI> sip show channels
Peer             User/ANR         Call ID          Format           Hold     Last Message    Expiry     Peer      
10.24.18.138     6002             Jm3llkdajhW50p3  0x1000 (g722)    No       Rx: ACK                    6002      
1 active SIP dialog
{noformat}

Sounds fine. I don't think I have an Audiocodes or Yealink phone to test with, but I'll see if we have one around. I'm sure we have some Polycoms. I'll see if someone can take a look at your pcap. Can you attach sanitized sip.conf configs as well?
By: David Brillert (aragon) 2012-09-21 07:20:58.173-0500

I also tested with Aastra 57i with bad result.
Attaching scrubbed sip.conf summary.
I have a Polycom IP450 I am going to test.
By: David Brillert (aragon) 2012-09-21 07:30:02.885-0500

I tried a newer SVN checkout and I can no longer reproduce.
Closing.
By: David Brillert (aragon) 2012-09-21 07:46:53.501-0500

D'oh, complete brain fart.
Please reopen this bug report, I checked out 1.4 SVN by accident.  No problem in 1.4.
Problem still exists in SVN branch r373047
By: David Brillert (aragon) 2012-09-21 08:09:31.916-0500

Just reproduced on my Polycom IP450
By: Rusty Newton (rnewton) 2012-09-21 15:54:48.978-0500

Tested on Polycom IP550, on 1.8-r373242.  G722 test sounds good.

In your pcap, I'm assuming the Call-ID of 72eda4a124c4e6a3394dfe646fb4d59e is the call demonstrating the issue based on the SDP containing G722 and the other call does not.

1)The call appears to originate from Asterisk and not from the phone. How are you originating this call? (i tested also with a CLI originate to the phone, and connecting to a playback, still tested good)

2)Unfortunately, your pcap does not include RTP, so we can't get a look at the audio. Can you attach a pcap including RTP?

3)For your next pcap, please additionally include a full Asterisk log (logger.conf) with VERBOSE and DEBUG set to level 5 at least, so we can correlate what Asterisk is doing with what's in the pcap. Please point out some unique identifier for the particular call in question, so we can locate it in the debug.

4)Your sip.conf has significantly more options defined than in mine. Can you reduce your sip.conf to be as simple as possible during test? Then include that new sip.conf as well for the next set of debug if the test still fails. Here is what I used for example:

{noformat}
[general]
context=default

[6003]
type=friend
host=dynamic
disallow=all
allow=g722
context=whatever
secret=6003
mailbox=6003
qualify=yes
{noformat}




By: David Brillert (aragon) 2012-09-23 09:14:04.920-0500

There is only one active call in the attached pcap and CLI trace.
I connected a hub to the Asterisk server and the phone and my laptop and used Wireshark.
Verbose enabled.
Debug enabled.
Extension 221 is a Polycom phone dialing Comedian Mail.
Phone IP 192.168.192.52
Asterisk IP 192.168.192.1
By: David Brillert (aragon) 2012-09-23 09:49:35.135-0500

Attaching new traces since I set up the putty logging wrong.
Please delete ext221_comedianmail_g722_CLI.rar and ext221_comedianmail_g722_CLI.pcap
By: David Brillert (aragon) 2012-09-23 09:54:31.263-0500

New traces uploaded.
ext221_comedianmail_g722_CLI(1).rar
ext221_comedianmail_g722(1).pcap
By: Rusty Newton (rnewton) 2012-09-25 15:59:47.395-0500

Thanks. Did you use a reduced sip.conf for this new capture? Also is there any way you can provide the actual full log produced by Asterisk? It's a bit easier to look through depending on your editor.
By: David Brillert (aragon) 2012-09-25 16:13:46.759-0500

Same sip.conf since the conf file gets generated by a graphical interface and stuff breaks when I strip it down.
The new pcap just involves a call to voicemail to prompt for g722 password.
/var/log/messages has nothing useful in it.
ext221_comedianmail_g722_CLI(1).rar is a compressed putty session * CLI capture with sip set debug on, verbose, and debug enabled.  I can see that putty messed up the formatting pretty good.
I'll run the trace again as soon as I can (probably a few days).
By: Rusty Newton (rnewton) 2012-09-25 17:44:40.791-0500

Thanks again - see https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information  , set logger.conf up for full log, with debug, verbose, plus you can get sip debug going to it as well if you "logger reload" after turning it on. Just attach that file once you get it, rather than capturing the actual CLI through putty. It's easier all around.
By: Rusty Newton (rnewton) 2012-09-28 17:03:21.717-0500

We are not finding anything outstanding so far. We are unable to reproduce. I can't find any other reports of this issue.

Where is Asterisk getting it's timing? https://wiki.asterisk.org/wiki/display/AST/Timing+Interfaces

Do you have any patches from other issues or versions applied to this 1.8.16 version of Asterisk? Can you describe anything unique about your setup?
By: David Brillert (aragon) 2012-09-28 17:17:27.161-0500

timing module is res_timing_dahdi.so
Using a sangoma card A20101D
wanpipe-3.5.28
dahdi-2.6.0
No custom patches

[root@sip ~]# timertest
Opened timer...
Set timer duration to 8000 samples (1000 ms)
Waiting...
Timer Expired (1000 ms)!
Timer Expired (2000 ms)!
Timer Expired (3000 ms)!
Timer Expired (4000 ms)!
Timer Expired (5000 ms)!
Timer Expired (6000 ms)!
Timer Expired (7000 ms)!

By: Rusty Newton (rnewton) 2012-09-28 17:58:07.347-0500

Thanks again for posting the additional info.

After looking through it I'm closing this as "cannot reproduce", as we can't reproduce it and see no obvious lead that would allow us to investigate the problem.

If you can find other reports of the issue, or if you can narrow down the issue to particular settings or a configuration then the issue can be re-opened.

I recommend trying to strip down your sip.conf configuration line by line and testing with more and more default settings (closer to the ones I used). If you can find a particular aspect of the configuration that triggers the issue that would give a developer something to work with.

If there is a bug it may be a complex combination of configuration elements that causes it. Until we have a better lead, we still have hundreds of other issues that affect more than one machine.

All your data provided so far will still be here available to others to find if someone runs into the same problem, or if you find a community member willing to take a deep dive into attempting reproduction.

Let us know what else you find out. You can always ping someone in #asterisk-bugs to have the issue re-opened.

By: Rusty Newton (rnewton) 2012-09-28 18:00:41.132-0500

Forgot to mention, you could try other timing sources too, and see if that leads to anything.