[Home]

Summary:ASTERISK-11594: Distorted playback of G.722 prompts
Reporter:Paul Milazzo (milazzo)Labels:
Date Opened:2008-03-06 21:04:56.000-0600Date Closed:2008-05-29 14:38:53
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Codecs/codec_g722
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) g722.pcap
Description:With the changes in r106501, G.722 audio FROM a Polycom 650 now works properly; it can be recorded, transcoded, etc. without impairment.

Unfortunately, playback of G.722 audio TO a Polycom 650 is now distorted; it plays choppily at half speed. G.722 voicemail prompts, Playback() of a .g722 file, and G.722 MOH exhibit this distortion, as does a call being transcoded from GSM (the Polycom -> GSM direction sounds fine).

Playback of other file formats (uLaw, slin) sounds fine, as does a call being transcoded from uLaw.

****** STEPS TO REPRODUCE ******

Connect to Voicemail from a Polycom using G.722, or play back any .g722 file.
Comments:By: snuffy (snuffy) 2008-03-06 21:43:18.000-0600

This case seems like a duplicate... please see ASTERISK-11567 that was closed the problem should be now fixed.
By: Jason Parker (jparker) 2008-03-07 10:39:41.000-0600

Closing, per comment from snuffy.

This was fixed very shortly before this report was opened.

Please reopen if this is not the case.
By: Paul Milazzo (milazzo) 2008-03-07 17:14:46.000-0600

I'm sorry I was unclear. I opened this new issue precisely because I had just tested r106501 that was checked in as a resolution to Issue 0012130 and found that it did not entirely fix the problem.

I would simply have reopened 0012130, but apparently it was closed in such a way that I could not do so.
By: Russell Bryant (russell) 2008-03-07 17:27:45.000-0600

I just did a Playback of a g722 file to my 650 and it sounds fine ...
By: Russell Bryant (russell) 2008-03-07 17:28:15.000-0600

and I recorded and played back in g722 and that sounds fine.
By: Russell Bryant (russell) 2008-03-07 17:29:17.000-0600

and now I tested calling between a g722 phone and a phone using ulaw, and that works fine.

Can you please update to the latest trunk and try again?  You may not be running the version you think you are.
By: Paul Milazzo (milazzo) 2008-03-07 18:52:10.000-0600

"Can you please update to the latest trunk and try again?"

Sure; hang on... [F/X: frantic typing sounds]

OK, I just updated to r106896, did a "make distclean", reconfigured and recompiled everything, shut down Asterisk, manually removed all modules, sounds, and MOH files, reinstalled everything, checked for relevant updates to the configuration files (there were none), restarted Asterisk, and rebooted the Polycom 650 on my desk.

Here's what I observe:

"core show version" now reports "SVN-trunk-r106896M".

Placing a call from my 650 in G.722 mode to a Zap line (uLaw) works perfectly in both directions. Routing the same call through my VOIP provider in GSM format yields perfect outgoing audio (to the remote phone) but distorted incoming audio (to the 650).

Calling the VoiceMailMain in uLaw mode works perfectly. Calling VoiceMailMain in G.722 mode produces distorted, half-speed prompts. The console reports that it is playing:
   -- <SIP/xxx> Playing 'vm-youhave.g722' (language 'en')
   -- <SIP/xxx> Playing 'digits/2.g722' (language 'en')
   -- <SIP/xxx> Playing 'vm-Old.g722' (language 'en')
   -- <SIP/xxx> Playing 'vm-messages.g722' (language 'en')
   -- <SIP/xxx> Playing 'vm-onefor.g722' (language 'en')
   -- <SIP/xxx> Playing 'vm-Old.g722' (language 'en')
   -- <SIP/xxx> Playing 'vm-messages.g722' (language 'en')
   -- <SIP/xxx> Playing 'vm-opts.g722' (language 'en')
   -- <SIP/xxx> Playing 'vm-helpexit.g722' (language 'en')

I then set up the following extensions to test recording:
       // test extensions
       5081 => {
           Answer();
           Playback(priv-recordintro);
           Playback(then-press-pound);
           Wait(1);
           Record(/tmp/recorded-name-g722.g722);
           Wait(1);
           Playback(beep);
           Playback(/tmp/recorded-name-g722);
           Playback(beep);
           Hangup();
       };
       5083 => {
           Answer();
           Playback(priv-recordintro);
           Playback(then-press-pound);
           Wait(1);
           Record(/tmp/recorded-name-ulaw.ulaw);
           Wait(1);
           Playback(beep);
           Playback(/tmp/recorded-name-ulaw);
           Playback(beep);
           Hangup();
       };

When I called either extension from the 650, the prerecorded prompts were played half-speed and distorted. The .g722 recording played with the same distortion as the prompts, but the .ulaw recording sounded fine.

If I manually convert the .g722 recording to .wav with "file convert", the result also sounds fine when played on my PC, suggesting that the recording portion of the process is working properly.

MOH plays at the proper speed on my 650, but sounds somewhat distorted.
By: Russell Bryant (russell) 2008-03-19 14:14:36

What firmware are you using on the 650?  I'm using a 650, and doing the same tests as you, it's still working fine for me.

I'm using 3.0.0.0258
By: Jared Smith (jsmith) 2008-03-19 18:01:30

I'm having problems as well... Polycom 650 talking to latest 1.6.0 branch from SVN.  My sip.conf section is configured as:

[asterisk]
type=friend
secret=asterisk
host=dynamic
disallow=all
allow=g722
allow=ulaw
allow=gsm
context=g722demo
qualify=yes

and my dialplan looks like:

[g722demo]
exten => 123,1,Answer(200)
exten => 123,n,Playback(hello-world)
exten => 123,n,Playback(asterisk-friend)
exten => 123,n,DumpChan()
exten => 123,n,Playback(pbx-transfer)
exten => 123,n,Wait(30)
exten => 123,n,Hangup()

exten => 111,1,Answer(200)
exten => 111,n,MusicOnHold()

I'll attach the packet capture from tcpdump as well.
By: Paul Milazzo (milazzo) 2008-03-19 19:01:26

I'm also using 3.0.0.0258
By: Digium Subversion (svnbot) 2008-03-20 12:37:02

Repository: asterisk
Revision: 110268

U   trunk/main/channel.c
U   trunk/res/res_musiconhold.c

------------------------------------------------------------------------
r110268 | russell | 2008-03-20 12:36:59 -0500 (Thu, 20 Mar 2008) | 27 lines

Add some fixes that I made in regards to wideband codec handling to get
G.722 music on hold working for me.

(issue ASTERISK-11594, reported by milazzo and jsmith, patches by me)

res/res_musiconhold.c:
- I moved a single line so that the sample queue update happened before
  ast_write().  The reason that this was a bug is that the G.722 frame
  originally says it has 320 samples in it (which is correct).  However,
  when the frame is written to a channel that uses RTP, main/rtp.c modifies
  the frame to cut the number of samples in half before it sends it on
  the wire.  This is to account for the stupid incorrect G.722 spec that
  makes it so we have to lie about the number of samples with RTP.  I should
  probably go and re-work the RTP code so it doesn't modify the frame so
  that a bug like this won't happen in the future.  However, this change to
  MOH is harmless.

main/channel.c:
- I made two fixes in regards to generator timing.  Generators use samples
  for timing.  However, this code assumed 8 kHz samples.  In one case, it was
  a hard coded 160 samples, that is now written as the sample rate / 50.  The
  other place was dealing with timing a generator based on frames coming from
  the other direction.  However, that would have only worked if the sample
  rates for the formats in both directions were the same.  The code now takes
  into account that the sample rates may differ, and scales the generator
  samples accordingly.

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=110268
By: Digium Subversion (svnbot) 2008-03-20 12:37:22

Repository: asterisk
Revision: 110269

_U  branches/1.6.0/
U   branches/1.6.0/main/channel.c
U   branches/1.6.0/res/res_musiconhold.c

------------------------------------------------------------------------
r110269 | russell | 2008-03-20 12:37:21 -0500 (Thu, 20 Mar 2008) | 35 lines

Merged revisions 110268 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
r110268 | russell | 2008-03-20 12:41:22 -0500 (Thu, 20 Mar 2008) | 27 lines

Add some fixes that I made in regards to wideband codec handling to get
G.722 music on hold working for me.

(issue ASTERISK-11594, reported by milazzo and jsmith, patches by me)

res/res_musiconhold.c:
- I moved a single line so that the sample queue update happened before
  ast_write().  The reason that this was a bug is that the G.722 frame
  originally says it has 320 samples in it (which is correct).  However,
  when the frame is written to a channel that uses RTP, main/rtp.c modifies
  the frame to cut the number of samples in half before it sends it on
  the wire.  This is to account for the stupid incorrect G.722 spec that
  makes it so we have to lie about the number of samples with RTP.  I should
  probably go and re-work the RTP code so it doesn't modify the frame so
  that a bug like this won't happen in the future.  However, this change to
  MOH is harmless.

main/channel.c:
- I made two fixes in regards to generator timing.  Generators use samples
  for timing.  However, this code assumed 8 kHz samples.  In one case, it was
  a hard coded 160 samples, that is now written as the sample rate / 50.  The
  other place was dealing with timing a generator based on frames coming from
  the other direction.  However, that would have only worked if the sample
  rates for the formats in both directions were the same.  The code now takes
  into account that the sample rates may differ, and scales the generator
  samples accordingly.

........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=110269
By: Russell Bryant (russell) 2008-03-20 12:47:46

Please re-test with the fixes I just made.  I was finally able to get it to fail for me.  :)
By: Digium Subversion (svnbot) 2008-03-20 15:04:18

Repository: asterisk
Revision: 110303

U   trunk/main/file.c

------------------------------------------------------------------------
r110303 | russell | 2008-03-20 15:04:16 -0500 (Thu, 20 Mar 2008) | 8 lines

Fix a bug when using zaptel timing for playing back files that have a sample rate
other than 8 kHz.  The issue here is that format modules give a "whennext" sample
value, which is used to calculate when to set a timer for to retrieve the next
frame.  However, the zaptel timer operates on 8 kHz samples, so this must be taken
into account.

(another part of issue ASTERISK-11594, reported by milazzo and jsmith, patch by me)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=110303
By: Digium Subversion (svnbot) 2008-03-20 15:06:15

Repository: asterisk
Revision: 110304

_U  branches/1.6.0/
U   branches/1.6.0/main/file.c

------------------------------------------------------------------------
r110304 | russell | 2008-03-20 15:06:15 -0500 (Thu, 20 Mar 2008) | 16 lines

Merged revisions 110303 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
r110303 | russell | 2008-03-20 15:08:26 -0500 (Thu, 20 Mar 2008) | 8 lines

Fix a bug when using zaptel timing for playing back files that have a sample rate
other than 8 kHz.  The issue here is that format modules give a "whennext" sample
value, which is used to calculate when to set a timer for to retrieve the next
frame.  However, the zaptel timer operates on 8 kHz samples, so this must be taken
into account.

(another part of issue ASTERISK-11594, reported by milazzo and jsmith, patch by me)

........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=110304
By: Paul Milazzo (milazzo) 2008-03-22 18:28:31

Russell:

Thanks for working on this problem! It's *almost* fixed now. Here's what I observe using SVN-trunk-r110578M:

Recording / playback from Polycom 650 in G.722 mode to g722, ulaw, wav, gsm: all good.
Voicemail prompts, voicemail recording and playback: all good.
Music-on-hold in G.722 format: good.
Placing a call from Polycom 650 via G.722 on SIP -> uLaw on Zap: good.
Placing a call from Polycom 650 via G.722 on SIP -> GSM on IAX2: BAD.

In this last test, the outgoing audio (G.722 -> GSM) sounds fine at the remote site. The incoming audio (GSM -> G.722) is terribly distorted, though it does appear to be playing at the correct speed.

Curiously, if I transfer the remote party to a test extension that records in GSM format, then play back the resulting recording using the Polycom 650 in G.722 format, it sounds fine.

If I place the same call from the same Polycom phone, but force it to use uLaw with:

disallow=all
allow=ulaw

in my sip.conf, it sounds fine in both directions.

If there are any additional tests / logs / packet traces / etc. that would help, please let me know.

   Thanks again,
   Paul
By: Russell Bryant (russell) 2008-04-01 17:49:15

I tried the situation that you described as not working and it's working fine for me ... :(
By: Digium Subversion (svnbot) 2008-04-09 15:15:44

Repository: asterisk
Revision: 113924

U   team/group/NoLossCDR-Redux2/build_tools/cflags.xml
U   team/group/NoLossCDR-Redux2/pbx/pbx_ael.c
U   team/group/NoLossCDR-Redux2/phoneprov/000000000000-directory.xml
U   team/group/NoLossCDR-Redux2/phoneprov/polycom.xml
A   team/group/NoLossCDR-Redux2/phoneprov/polycom_line.xml

------------------------------------------------------------------------
r113924 | juggie | 2008-04-09 15:15:41 -0500 (Wed, 09 Apr 2008) | 211 lines

Merged revisions 110020,110023,110036,110084,110087,110132,110161,110164,110211,110237,110268,110270,110272,110303,110337,110339,110396,110444 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r110020 | file | 2008-03-19 14:25:33 -0400 (Wed, 19 Mar 2008) | 14 lines

Merged revisions 110019 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110019 | file | 2008-03-19 15:20:28 -0300 (Wed, 19 Mar 2008) | 6 lines

Make sure that the mark bit does not incorrectly cause video frame timestamps to be calculated as if they are audio frames.
(closes issue ASTERISK-10940)
Reported by: sperreault
Patches:
     11429-frametype.diff uploaded by qwell (license 4)

........

................
r110023 | russell | 2008-03-19 14:57:16 -0400 (Wed, 19 Mar 2008) | 2 lines

remove svnmerge-blocked property that is not supposed to be here

................
r110036 | file | 2008-03-19 15:13:39 -0400 (Wed, 19 Mar 2008) | 12 lines

Merged revisions 110035 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110035 | file | 2008-03-19 16:11:33 -0300 (Wed, 19 Mar 2008) | 4 lines

Add sanity checking for position resuming. We *have* to make sure that the position does not exceed the total number of files present, and we have to make sure that the position's filename is the same as previous. These values can change if a music class is reloaded and give unpredictable behavior.
(closes issue ASTERISK-11136)
Reported by: junky

........

................
r110084 | mmichelson | 2008-03-19 16:34:13 -0400 (Wed, 19 Mar 2008) | 12 lines

Merged revisions 110083 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110083 | mmichelson | 2008-03-19 15:33:03 -0500 (Wed, 19 Mar 2008) | 4 lines

Add a missing unlock in the case that memory allocation fails in app_chanspy.
Thanks to Russell for confirming that this was an issue.


........

................
r110087 | jpeeler | 2008-03-19 17:05:24 -0400 (Wed, 19 Mar 2008) | 2 lines

This change adds DNS manager support for registrations not referencing a peer entry. It looks like there is support for DNS manager for realtime peers as well, however it is not implemented correctly. The improper usage occurs when ast_dnsmgr_lookup is called with one of the arguments being an address from the stack to be continually updated. The variable from the stack will go out of scope and dnsmgr will continue to try and update the memory there, causing possible stack corruption. This problem will be worked on next as well as adding DNS manager support for peer entries.

................
r110132 | qwell | 2008-03-19 17:56:15 -0400 (Wed, 19 Mar 2008) | 1 line

Rename very poorly named function to reflect what it actually does.  This was causing quite a bit of confusion for me...
................
r110161 | qwell | 2008-03-19 18:25:34 -0400 (Wed, 19 Mar 2008) | 5 lines

Rename DSP_FEATURE_DTMF_DETECT, because we are *NOT* only detecting DTMF digits.
This was very misleading.

Early cleanup for issue ASTERISK-11413

................
r110164 | russell | 2008-03-19 18:58:33 -0400 (Wed, 19 Mar 2008) | 13 lines

Merged revisions 110163 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110163 | russell | 2008-03-19 17:57:59 -0500 (Wed, 19 Mar 2008) | 5 lines

Fix a bug where when calls on the trunk side hang up while on hold, the state
is not properly reflected.

(closes issue ASTERISK-11434, reported by anakaoka, patched by me)

........

................
r110211 | tilghman | 2008-03-19 23:14:59 -0400 (Wed, 19 Mar 2008) | 2 lines

Fix recent trunk breakage

................
r110237 | tilghman | 2008-03-20 01:06:12 -0400 (Thu, 20 Mar 2008) | 5 lines

Upgrade the sounds version; add several directory enhancements:
1) Number of digits to enter can now be configured
2) The digits can now match on both first AND last name, instead of only one or the other
(Closes issue ASTERISK-6965)

................
r110268 | russell | 2008-03-20 13:41:22 -0400 (Thu, 20 Mar 2008) | 27 lines

Add some fixes that I made in regards to wideband codec handling to get
G.722 music on hold working for me.

(issue ASTERISK-11594, reported by milazzo and jsmith, patches by me)

res/res_musiconhold.c:
- I moved a single line so that the sample queue update happened before
  ast_write().  The reason that this was a bug is that the G.722 frame
  originally says it has 320 samples in it (which is correct).  However,
  when the frame is written to a channel that uses RTP, main/rtp.c modifies
  the frame to cut the number of samples in half before it sends it on
  the wire.  This is to account for the stupid incorrect G.722 spec that
  makes it so we have to lie about the number of samples with RTP.  I should
  probably go and re-work the RTP code so it doesn't modify the frame so
  that a bug like this won't happen in the future.  However, this change to
  MOH is harmless.

main/channel.c:
- I made two fixes in regards to generator timing.  Generators use samples
  for timing.  However, this code assumed 8 kHz samples.  In one case, it was
  a hard coded 160 samples, that is now written as the sample rate / 50.  The
  other place was dealing with timing a generator based on frames coming from
  the other direction.  However, that would have only worked if the sample
  rates for the formats in both directions were the same.  The code now takes
  into account that the sample rates may differ, and scales the generator
  samples accordingly.

................
r110270 | russell | 2008-03-20 13:45:29 -0400 (Thu, 20 Mar 2008) | 2 lines

Remove astobj.h from some places where it wasn't needed

................
r110272 | mmichelson | 2008-03-20 14:01:36 -0400 (Thu, 20 Mar 2008) | 3 lines

Add missing unlock


................
r110303 | russell | 2008-03-20 16:08:26 -0400 (Thu, 20 Mar 2008) | 8 lines

Fix a bug when using zaptel timing for playing back files that have a sample rate
other than 8 kHz.  The issue here is that format modules give a "whennext" sample
value, which is used to calculate when to set a timer for to retrieve the next
frame.  However, the zaptel timer operates on 8 kHz samples, so this must be taken
into account.

(another part of issue ASTERISK-11594, reported by milazzo and jsmith, patch by me)

................
r110337 | russell | 2008-03-20 17:55:50 -0400 (Thu, 20 Mar 2008) | 22 lines

Merged revisions 110336 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

................
r110336 | russell | 2008-03-20 16:54:58 -0500 (Thu, 20 Mar 2008) | 14 lines

Merged revisions 110335 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2

........
r110335 | russell | 2008-03-20 16:53:27 -0500 (Thu, 20 Mar 2008) | 6 lines

Fix some very broken code that was introduced in 1.2.26 as a part of the security
fix.  The dnsmgr is not appropriate here.  The dnsmgr takes a pointer to an address
structure that a background thread continuously updates.  However, in these cases,
a stack variable was passed.  That means that the dnsmgr thread would be continuously
writing to bogus memory.

........

................

................
r110339 | russell | 2008-03-20 18:02:20 -0400 (Thu, 20 Mar 2008) | 3 lines

Use the correct buffer for g722tolin16_sample.  This shouldn't have caused any
problems, but Qwell noticed the typo here.

................
r110396 | russell | 2008-03-20 19:14:13 -0400 (Thu, 20 Mar 2008) | 17 lines

Merged revisions 110395 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110395 | russell | 2008-03-20 18:13:56 -0500 (Thu, 20 Mar 2008) | 9 lines

Shorten the ast_waitfor() timeout from 500 ms to 50 ms in the autoservice thread.
This really should not make a difference except in very rare cases.  That case would
be that all of the channels in autoservice are not generating any frames.  In that
case, this change reduces the potential amount of time that a thread waits in
ast_autoservice_stop() for the autoservice thread to wrap back around to the beginning
of its loop.

(closes issue ASTERISK-11689, reported by dimas)

........

................
r110444 | tilghman | 2008-03-20 21:44:38 -0400 (Thu, 20 Mar 2008) | 2 lines

Add note of the added Directory options, from commit 110237 (closes issue ASTERISK-6965)

................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=113924
By: Digium Subversion (svnbot) 2008-04-09 15:18:57

Repository: asterisk
Revision: 113925

U   team/group/NoLossCDR-Redux2/channels/chan_h323.c
U   team/group/NoLossCDR-Redux2/channels/chan_usbradio.c
U   team/group/NoLossCDR-Redux2/channels/misdn_config.c

------------------------------------------------------------------------
r113925 | juggie | 2008-04-09 15:18:55 -0500 (Wed, 09 Apr 2008) | 211 lines

Merged revisions 110020,110023,110036,110084,110087,110132,110161,110164,110211,110237,110268,110270,110272,110303,110337,110339,110396,110444 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r110020 | file | 2008-03-19 14:25:33 -0400 (Wed, 19 Mar 2008) | 14 lines

Merged revisions 110019 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110019 | file | 2008-03-19 15:20:28 -0300 (Wed, 19 Mar 2008) | 6 lines

Make sure that the mark bit does not incorrectly cause video frame timestamps to be calculated as if they are audio frames.
(closes issue ASTERISK-10940)
Reported by: sperreault
Patches:
     11429-frametype.diff uploaded by qwell (license 4)

........

................
r110023 | russell | 2008-03-19 14:57:16 -0400 (Wed, 19 Mar 2008) | 2 lines

remove svnmerge-blocked property that is not supposed to be here

................
r110036 | file | 2008-03-19 15:13:39 -0400 (Wed, 19 Mar 2008) | 12 lines

Merged revisions 110035 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110035 | file | 2008-03-19 16:11:33 -0300 (Wed, 19 Mar 2008) | 4 lines

Add sanity checking for position resuming. We *have* to make sure that the position does not exceed the total number of files present, and we have to make sure that the position's filename is the same as previous. These values can change if a music class is reloaded and give unpredictable behavior.
(closes issue ASTERISK-11136)
Reported by: junky

........

................
r110084 | mmichelson | 2008-03-19 16:34:13 -0400 (Wed, 19 Mar 2008) | 12 lines

Merged revisions 110083 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110083 | mmichelson | 2008-03-19 15:33:03 -0500 (Wed, 19 Mar 2008) | 4 lines

Add a missing unlock in the case that memory allocation fails in app_chanspy.
Thanks to Russell for confirming that this was an issue.


........

................
r110087 | jpeeler | 2008-03-19 17:05:24 -0400 (Wed, 19 Mar 2008) | 2 lines

This change adds DNS manager support for registrations not referencing a peer entry. It looks like there is support for DNS manager for realtime peers as well, however it is not implemented correctly. The improper usage occurs when ast_dnsmgr_lookup is called with one of the arguments being an address from the stack to be continually updated. The variable from the stack will go out of scope and dnsmgr will continue to try and update the memory there, causing possible stack corruption. This problem will be worked on next as well as adding DNS manager support for peer entries.

................
r110132 | qwell | 2008-03-19 17:56:15 -0400 (Wed, 19 Mar 2008) | 1 line

Rename very poorly named function to reflect what it actually does.  This was causing quite a bit of confusion for me...
................
r110161 | qwell | 2008-03-19 18:25:34 -0400 (Wed, 19 Mar 2008) | 5 lines

Rename DSP_FEATURE_DTMF_DETECT, because we are *NOT* only detecting DTMF digits.
This was very misleading.

Early cleanup for issue ASTERISK-11413

................
r110164 | russell | 2008-03-19 18:58:33 -0400 (Wed, 19 Mar 2008) | 13 lines

Merged revisions 110163 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110163 | russell | 2008-03-19 17:57:59 -0500 (Wed, 19 Mar 2008) | 5 lines

Fix a bug where when calls on the trunk side hang up while on hold, the state
is not properly reflected.

(closes issue ASTERISK-11434, reported by anakaoka, patched by me)

........

................
r110211 | tilghman | 2008-03-19 23:14:59 -0400 (Wed, 19 Mar 2008) | 2 lines

Fix recent trunk breakage

................
r110237 | tilghman | 2008-03-20 01:06:12 -0400 (Thu, 20 Mar 2008) | 5 lines

Upgrade the sounds version; add several directory enhancements:
1) Number of digits to enter can now be configured
2) The digits can now match on both first AND last name, instead of only one or the other
(Closes issue ASTERISK-6965)

................
r110268 | russell | 2008-03-20 13:41:22 -0400 (Thu, 20 Mar 2008) | 27 lines

Add some fixes that I made in regards to wideband codec handling to get
G.722 music on hold working for me.

(issue ASTERISK-11594, reported by milazzo and jsmith, patches by me)

res/res_musiconhold.c:
- I moved a single line so that the sample queue update happened before
  ast_write().  The reason that this was a bug is that the G.722 frame
  originally says it has 320 samples in it (which is correct).  However,
  when the frame is written to a channel that uses RTP, main/rtp.c modifies
  the frame to cut the number of samples in half before it sends it on
  the wire.  This is to account for the stupid incorrect G.722 spec that
  makes it so we have to lie about the number of samples with RTP.  I should
  probably go and re-work the RTP code so it doesn't modify the frame so
  that a bug like this won't happen in the future.  However, this change to
  MOH is harmless.

main/channel.c:
- I made two fixes in regards to generator timing.  Generators use samples
  for timing.  However, this code assumed 8 kHz samples.  In one case, it was
  a hard coded 160 samples, that is now written as the sample rate / 50.  The
  other place was dealing with timing a generator based on frames coming from
  the other direction.  However, that would have only worked if the sample
  rates for the formats in both directions were the same.  The code now takes
  into account that the sample rates may differ, and scales the generator
  samples accordingly.

................
r110270 | russell | 2008-03-20 13:45:29 -0400 (Thu, 20 Mar 2008) | 2 lines

Remove astobj.h from some places where it wasn't needed

................
r110272 | mmichelson | 2008-03-20 14:01:36 -0400 (Thu, 20 Mar 2008) | 3 lines

Add missing unlock


................
r110303 | russell | 2008-03-20 16:08:26 -0400 (Thu, 20 Mar 2008) | 8 lines

Fix a bug when using zaptel timing for playing back files that have a sample rate
other than 8 kHz.  The issue here is that format modules give a "whennext" sample
value, which is used to calculate when to set a timer for to retrieve the next
frame.  However, the zaptel timer operates on 8 kHz samples, so this must be taken
into account.

(another part of issue ASTERISK-11594, reported by milazzo and jsmith, patch by me)

................
r110337 | russell | 2008-03-20 17:55:50 -0400 (Thu, 20 Mar 2008) | 22 lines

Merged revisions 110336 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

................
r110336 | russell | 2008-03-20 16:54:58 -0500 (Thu, 20 Mar 2008) | 14 lines

Merged revisions 110335 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2

........
r110335 | russell | 2008-03-20 16:53:27 -0500 (Thu, 20 Mar 2008) | 6 lines

Fix some very broken code that was introduced in 1.2.26 as a part of the security
fix.  The dnsmgr is not appropriate here.  The dnsmgr takes a pointer to an address
structure that a background thread continuously updates.  However, in these cases,
a stack variable was passed.  That means that the dnsmgr thread would be continuously
writing to bogus memory.

........

................

................
r110339 | russell | 2008-03-20 18:02:20 -0400 (Thu, 20 Mar 2008) | 3 lines

Use the correct buffer for g722tolin16_sample.  This shouldn't have caused any
problems, but Qwell noticed the typo here.

................
r110396 | russell | 2008-03-20 19:14:13 -0400 (Thu, 20 Mar 2008) | 17 lines

Merged revisions 110395 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110395 | russell | 2008-03-20 18:13:56 -0500 (Thu, 20 Mar 2008) | 9 lines

Shorten the ast_waitfor() timeout from 500 ms to 50 ms in the autoservice thread.
This really should not make a difference except in very rare cases.  That case would
be that all of the channels in autoservice are not generating any frames.  In that
case, this change reduces the potential amount of time that a thread waits in
ast_autoservice_stop() for the autoservice thread to wrap back around to the beginning
of its loop.

(closes issue ASTERISK-11689, reported by dimas)

........

................
r110444 | tilghman | 2008-03-20 21:44:38 -0400 (Thu, 20 Mar 2008) | 2 lines

Add note of the added Directory options, from commit 110237 (closes issue ASTERISK-6965)

................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=113925
By: Russell Bryant (russell) 2008-05-29 14:38:52

I'm closing this out because I believe that I have the G.722 related issues fixed.

I think the remaining problem is the same as that reported in 12433