[Home]

Summary:ASTERISK-05230: [patch] Asynchronous generation of outgoing frames when timing device available
Reporter:Carlos Antunes (cmantunes)Labels:
Date Opened:2005-10-03 21:25:20Date Closed:2009-11-19 09:28:04.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 2005-10-03_asynchronous.patch
( 1) 2005-10-04-1-asynchronous.patch
( 2) 2005-10-04-2-asynchronous.patch
( 3) 2005-10-04-3-asynchronous.patch
( 4) asterisk-1.2.4-silence_suppression-4.patch
( 5) silence_suppression-4.diff
( 6) silence-suppression.diff
( 7) silence-suppression-1.diff
( 8) silence-suppression-2.diff
( 9) silence-suppression-3.diff
Description:One common complain from Asterisk users is its inability to generate outgoing RTP packets when incoming packets stop arriving, due to silence supression, for example. This is due to the fact that Asterisk generates outgoing frames in the same function where incoming frames are processed (ast_read). When this routine isn't called, outgoing framnes aren't generated either (well, unless a CNG frame arrives, which served as inspiration for this patch.)

This patch basically forces Asterisk to always generate outgoing frames asynchronously when a timing device is available (zaptel). On the other end, if a timing device isn't available, Asterisk will fall back to generate outgoing frames synchronously, in ast_read.

This patch was only tested for a few hours with a couple of SIP clients. As such, I cannot guarantee in any way, shape of form that it will work for everybody. It is my hope, however, that people test this patch and report any possible issues.

****** ADDITIONAL INFORMATION ******

(NOTE: I faxed the disclaimer but never got any confirmation back from anyone.)
Comments:By: Andrew Lindh (andrew) 2005-10-03 22:40:16

It breaks Milliwatt....no audio.

But asterisk needs to be able to generate fames on its own!

By: Carlos Antunes (cmantunes) 2005-10-04 01:00:38

andrew: new patch (2005-10-04-1-asynchronous.patch) includes milliwatt fix. Would you be able to give it a try?

By: Olle Johansson (oej) 2005-10-04 01:46:45

Moving this to post 1.2, since it came in too late for 1.2.

If we can get this working stable and for all apps, it's a major update to Asterisk! Keep on working!

Question: Will this affect the work done on jitterbuffers?

By: Andrew Lindh (andrew) 2005-10-04 10:05:01

The Milliwatt patch fixed that issue. MOH is working better than ever (I'm using a raw player). I tested X-lite (windows) with "transmit silence=NO" and it works well now, so does the Polycom 600 with VAD enabled. Now I always get MOH audio with the patch, even with mute on (no RTP generated from the phone). I still get the rfc3389 warning in the console, but audio works. I have used ulaw, gsm, and digium g.729 codecs between phones and to asterisk. So far so good...

Is there an asterisk "checklist" for QA before a patch can be approved for CVS HEAD? This seems so simple and important that it should be part of 1.2.

By: Carlos Antunes (cmantunes) 2005-10-04 10:58:31

Uploaded new patch with fixes for all (hopefully) apps my asynchronous patch broke. This new patch, 2005-10-04-2-asynchronous.patch, includes fixes for app_milliwatt, app_sms and app_chanspy.

By: Olle Johansson (oej) 2005-10-04 11:03:09

Please test app_record and app_voicemail as well, thanks.

By: Carlos Antunes (cmantunes) 2005-10-04 11:03:27

oej: my gut feeling is that it shouldn't affect jitterbuffers in any way but I'm going to give it a hard look in any case.

andrew: I need to see the best way to address the rfc3389 thing. Havne't looked hard enough yet.

By: Andrew Lindh (andrew) 2005-10-04 13:28:02

Looking good. I used chanspy, voicemail record, and milliwatt on SIP. It sounds better than non-patched asterisk across ADSL/WiFi/VPN because asterisk is not counting on getting RTP back from my phone to send me packets, so it now sounds "normal". I was testing with/without VAD and both seem good.

I think this would help asterisk local functions (IVR, voicemail, MOH) more than anything. This should also help JB as outbound is not locked to inbound.

App record is an "issue" that will need to be addressed with RFC3389. With VAD disabled everything works as expected. With VAD enabled it works, but when audio is muted the "blank" space is compressed into one blank frame. Not a big deal and I don't think a problem with this patch, just something people will run into as they start to use VAD. Leaving voicemail has the same issue, just something to address with VAD/CNG/RFC3389....

By: Russell Bryant (russell) 2005-10-04 13:28:31

A couple initial comments about the patch:

1) Please do not include arbitrary formatting changes or leftover debug code in the patch.  It makes it more difficult to see what is actually being changed.

2) There is an API call to determine the number of bytes required to hold a given number of samples of a given format.  See ast_codec_get_len(...) toward the bottom of include/asterisk/frame.h.

Thanks!



By: philipp2 (philipp2) 2005-10-04 13:47:12

Wondering: What effect will RFC3389 have on BackgroundDetect()?

By: Carlos Antunes (cmantunes) 2005-10-04 14:26:54

drumkilla:

1) basically, I made sure that the code I touched didn't exceed 80 collumns. Is that bad? I tend to considerer it a Good Thing(tm). Let me know, please.

2) wasn't aware of that nice ast_codec_get_len function. I'm going to replace the relevant code with it and upload a new patch later today.

Thanks!

By: Carlos Antunes (cmantunes) 2005-10-04 14:34:24

andrew, philipp2: well, I guess that warning about incomplete RFC3389 support will have to stay there for now. But that is something I will look once this patch is in (let's hope! :-))

By: Russell Bryant (russell) 2005-10-04 14:40:33

Re: 1)  Well, we generally try to do that for text files - sample configs, READMEs, etc.  However, this isn't followed throughout the code base.  Throughout the code, lines don't get manually wrapped except in some extreme cases.  In general, it's best to just match the formatting of the code that surrounds what you are working on.  

Also, if you are submitting a patch that changes code, it should be submitted without any changes to lines that are *only* formatting.  It just makes the code review process easier.  Not only that, but if there are problems later on related to the patch, it is much easier to go back and look at the changes between versions of affected files to find the problem if the changes only include the code changes.  The coding guidelines talk about some of this stuff and can be found in doc/CODING-GUIDELINES.

I don't mean to be picky.  I'm just trying to help move things along.  Given the incredible number of patches that we receive, this stuff becomes more and more important.  :)

Thanks!

By: Russell Bryant (russell) 2005-10-04 14:47:07

Re: 2)  Yeah, I put that function this summer when I was working on some MusicOnHold stuff.  It's convenient to use, but doesn't support some codecs - speex, g723, and lpc10.  I didn't worry about it at the time, because I didn't think anyone would be providing an external MusicOnHold source in those formats.  I'm sure someone will come along one day and fix that.  Anyway, the parts of the code that you are touching only deal with signed linear, ulaw, and alaw, so it's nothing to worry about.

By: Olle Johansson (oej) 2005-10-04 14:49:09

Anyone that can test meetme with a combination of SIP and zap channels and see if this takes away the increasing echo problem?

By: Carlos Antunes (cmantunes) 2005-10-04 20:39:38

drumkilla: I have been thinking (Oh oh!) and I'm starting to feel that it is better not to use ast_codec_get_len. The reason is simple: to use ast_codec_get_len, the generator code takes longer to execute. Given that these generators are called every 20ms or so, if you have a bunch of them, you want them to be as lean as possible. In reality, they could even be further optimized but I'll stick to what I'm doing right now. In any case, I'm going to upload a newer patch with better coding guidelines compliance. Let me know what you think.

By: Carlos Antunes (cmantunes) 2005-10-04 21:11:45

Latest patch (2005-10-04-3-asynchronous.patch) has been uploaded mainly to address drumkilla's comments about formating.

By: Russell Bryant (russell) 2005-10-04 21:55:27

cmantunes: Yeah, I actually had that exact same thought about ast_codec_get_len after we started talking about it here.

My first reaction was that maybe it should be converted to be an inline function using the AST_INLINE_API.  This would probably be a good idea, but I think you made a good call in keeping your code the way it is.  There is no reason to use it if the format is known.  The reason I needed it for MusicOnHold is that I was making the source format for a MOH source configurable.

Thanks for being patient with my comments.  :)

By: Carlos Antunes (cmantunes) 2005-10-05 09:48:00

drumkilla: no problem. Now, how do we go about actually having this commited to CVS HEAD? Is there anything that reamins to be done on my side? If yes, please, let me know. Thanks!

By: Russell Bryant (russell) 2005-10-05 13:39:50

I'm removing "[post 1.2]" from this since Kevin indicated in ASTERISK-5048 that this feature would be considered for addition to 1.2.

For now, the best thing that can done is more and more testing by various people.

By: Danny Froberg (dfroberg) 2005-10-05 16:05:45

This patch works excellently on an entirely SIP/IAX system with 2.6 kernel and ztdummy as timer. lag in meetme is almost entirely gone even with all the bells and whistles turned on.

By: philipp2 (philipp2) 2005-10-05 16:57:59

Tested successfilly with SNOM 320 (with silence suppression, SIP) and BT101 (w/o silence suppression, via IAX): Direct call, BackgroundDetect and Meetme (shortly). No problems encountered.

With silence suppression ON on the the snom 320 the echo test "displays" some very faint "softly boiling water" sound instead of constant soft white noise that I expected.

By: Sergey Okhapkin (sokhapkin) 2005-10-05 17:11:54

Shouldn't chan_sip be modified to NOT send a line

a=silenceSupp:off - - - -

in SDP message?

By: Russell Bryant (russell) 2005-10-05 18:22:54

Yes, it will, but only in the case that zap timing is available.

By: Andrew Lindh (andrew) 2005-10-06 10:20:36

I would say, no...don't remove "a=silenceSupp:off" for now because asterisk still does not support it. Asterisk needs CNG support before it can be happy with silence.

The JB should deal with PLC and CGN in a dynamic playout buffer, and with async self-timed RTP generation asterisk would now deal with audio like all the phones and other VoIP servers do....correctly...

Asterisk sill needs "silence" to make audio record and sound correct. But it's only a problem with local functions (VM, Zap channels, etc). I guess true "dead air" would be a good thing for meetme. You don't need comfort noise from everyone in a conference!

So, once again, it's not this patch's job to make all that work.

As for echo....if there's nothing to inbound to echo, what is it sending? Nothing? meaning packet "loss" to the phone? Or is it generating "empty" audio that the phone is confused about or the "empty" blanks that echo is sending is not very "empty"?

By: Carlos Antunes (cmantunes) 2005-10-06 10:24:52

sokhapkin: I'm with andrew on this one. There are still things that need to be implemented on asterisk for it to be able to always deal with silence supression gracefully.

philipp2: could you be a little bit more specific about the echo "steam engine" issue you experienced?

By: philipp2 (philipp2) 2005-10-06 11:35:56

Hehe - echo "steam engine": This really isn't a problem, it's almost inaudible and could also be somehow due to my network (I am not such a hot shot at network diagnosis). BTW, might be smart to also test with g729 and iLBC.

By: Sergey Okhapkin (sokhapkin) 2005-10-06 11:45:32

If I enable silence suppression on PSTN channel of my sipura-3000, I'm getting  choppy sound and static. Not sure if it's asterisk or sipura problem though.

By: Carlos Antunes (cmantunes) 2005-10-06 13:17:55

sokhapkin:

Don't know whether it's a sipura problem or not but it just confirms the fact that silence supression is not complete yet.

Quick question, though: are you using a timing device, meaning ztdummy/zaptel/whatever?



By: Sergey Okhapkin (sokhapkin) 2005-10-06 18:48:24

cmantunes: I run ztdummy.

By: Carlos Antunes (cmantunes) 2005-10-06 19:19:15

sokhapkin: when asterisk is compiling, do you see -DZAPTEL_OPTIMIZATIONS being used?

By: Sergey Okhapkin (sokhapkin) 2005-10-06 20:01:21

cmantunes: Yes, asterisk is compiled with -DZAPTEL_OPTIMIZATIONS. I believe it's a sipura PSTN-related problem, but not a problem with you patch. All my FXSs (spa-3000 FXS port and Telco Systems AC-211) runs fine with the silence suppression enabled, "rtp debug" and sipura's statistics shows that SS is in effect.

Looks like spa-3000 PSTN SS treshold is very aggressive and there is no "sensitivity" setting like for FXS port.

I did a lot of testing of your patch and I didn't find any problems so far. I vote for the patch inclusion to 1.2.

By: reformed (reformed) 2005-10-06 21:15:24

Its working perfect so far.
On Grandstream GXP-2000 i can hear remote party after pressing MUTE button.

By: Andrew Lindh (andrew) 2005-10-11 12:30:14

What generates the timing the packets now? I have been trying to test timing and I have found the zap pseudo timer running at 8000.02 hz, a little fast.

So far I have not been able to hear any problems...

By: dea (dea) 2005-10-14 11:12:47

The patch works like magic here.  Version 1.2beta1 with a patched
version of ooh323c (support for configurable frame sizes), using
ztdummy on a 2.6 kernel.  All clients are connected via H323 for MeetMe conferences.

Before this patch when a caller put a conference on hold, they would
be disconnected, which I have always considered a bug in the remote
endpoints.  With this patch there are no more disconnects.  Light
testing shows no quality regressions.

By: Donny Kavanagh (donnyk) 2005-10-19 17:23:16

How is this looking for 1.2?

By: yow (yow) 2005-10-20 23:50:37

This is quite absurd: "On the other end, if a timing device isn't available, Asterisk will fall back to generate outgoing frames synchronously, in ast_read."

Modern UNIX-like operating systems provide timing mechanisms for apps to use.
You're expected to use them. Hacking up an icky (and very buggy) little ztdummy
driver is not at all polite.

For you reading pleasure, please investigate the real-time POSIX timers.
They are designed to do the job well. If you are certain that they won't
do, discuss the matter on the linux-kernel@vger.kernel.org mailing list.
(and expect to be corrected)

By: Mark Spencer (markster) 2005-10-22 21:53:03

cmantunes: It is generally better to run the transmit function of a generator from the receiver when there is received audio in order that the transmitted data be phase locked to the received data.  

Current generator implementation is to use zaptel whenever we have a CNG frame received to continue generator operation (see ast_activate_generator and ast_read).  What would you suggest as an improvement upon the current strategy?

By: Sergey Okhapkin (sokhapkin) 2005-10-31 06:06:59.000-0600

The patch fails to apply to app/app_chanspy.c using current CVS HEAD.

By: Sergey Okhapkin (sokhapkin) 2005-10-31 06:10:37.000-0600

Clarification - the patch applies to CVS HEAD, but compilation of app_chanspy fails (unknown symbol buf0).

By: Mark Spencer (markster) 2005-11-02 21:50:41.000-0600

cmantunes: Do you want to arrange a time to discuss this proposed feature in a more realtime fashion (e.g. phone, irc?)

By: Carlos Antunes (cmantunes) 2005-11-02 23:56:00.000-0600

markster: sorry, I've been very busy. I'll add an explanation note tomorrow and we can then proceeed from there.

By: Carlos Antunes (cmantunes) 2005-11-03 10:28:15.000-0600

markster: initially, when I first start to play with Asterisk, MusicOnHold never sounded quite right over a SIP/RTP IAX2 session. I had no clue why but saw that other people were complaining too. As such, I decided to investigate.

Eventually, I realized that line generators wouldn't be called unless frames were being received. Of course, this meant that silence suppresion could not be used, which, in my view, is a big loss. Silence supression is one of the most important features of RTP, to preserve network bandwidth as much as possible. As a consuquence, this also affected people that unwilling put their SIP phones on Mute.

Another problem was the effective use of incoming frames as a timing device for generated ones. Basically, Whatever jitter was present on the incoming stream was being reflected on the generated frames. As such, Asterisk was generating frames with jitter already! This didn't seem good either. And, if an incoming packet was lost, there would be an even greater delay in the generation of the next frame, contributing further to jitter.

All-in-all, the use of the incoming stream creates several problems and doesn't really solve anything. In my opinion, asynchronous generation simply gives better results. Some people have tested this patch and their positive experiences are posted here.

By: dea (dea) 2005-11-03 12:10:44.000-0600

I find this patch very usefull on a server dedicated to MeetMe conferences.  If it could be merged, perhaps with config option that defaults to disabled,
it would be possible to collect statistics to support or reject the approach.

I think I understand Mark's position, but in our environment and the situations I have encountered with other VoIP technologies, I think cmantunes
is right.  Either way I think this is a case where 'one size fits all' cannot
suit all situations

Caveat-  I dabble at coding for asterisk, but I am no developer by any stretch of the imagination.

By: puzzled (puzzled) 2005-11-07 10:10:01.000-0600

sokhapkin: I asked cmantunes and he responded with the following:
Locate the spy_generate function on app_chanspy and inside delete the
folowing three lines:
/* We are using slin. But use size of one buffer element instead of
  * 2 * samples                                                      */
  len = samples * sizeof(buf0[0]);
This should be enough to enable compilation.

By: kb1_kanobe2 (kb1_kanobe2) 2005-11-07 10:59:26.000-0600

I think I can see the benefit in not 'unlocking' the transmission when doing things like spandsp and so on. If there is no objection to the basic strategy implemented here then perhaps this could be treated on a call-by-call basis, similarly to fax/data tone disabling of echo cancellation? Perhaps by a channel varaible that's passed down the call path, or something similar?

Just one idle persons musings...

By: Mark Spencer (markster) 2005-11-07 16:48:19.000-0600

I would be okay with a global option that simply enables/disables this feature globally, but it should be much easier to implement since essentially it's all there already.

By: reformed (reformed) 2005-11-11 21:43:24.000-0600

Weird,

My remote users on higher latency DSL links reporting 100% reliability on CC machines (Credit Card).

Out of over 500+ transactions only 6 failed (and there is no way to check if it was the problem on the banks side).

Without this patch its was almost 50-50 of getting stable connection to the banks on those DSL link.

The voice quality improved quite considerably with less "breaks" in the conversation after the patch was applied.

It would be nice to have runtime control (or per peer) of this feature but if it is done as a switch as mark suggested i can live with that.

Mind you i didn’t notice any difference on low latency links, only links with high latency improved.

By: Sergey Okhapkin (sokhapkin) 2005-11-12 12:02:45.000-0600

Because of cmantunes seems to me went offline I decided to modify his patch to implement the suggestions sounded in this thread (silence-suppression.diff). The changes are:

1. Added Asterisk command line option -s and asterisk.conf parameter "silence_suppression" to enable the feature.
2. chan_sip.c is modified to not emit "a=silenceSupp:off - - - -" line to SDP message if the silence suppression could take place.

Please try the new patch.

By: kuj (kuj) 2005-11-12 14:39:21.000-0600

sokhapkin: your new patch installs and works fine for calling (Polycom and eyebeam, vad on and off).

One small bug in the getopt option parsing in asterisk.c:
 while((c=getopt(argc, argv, "tThfdvVqprRgcinxs:U:G:C:L:M:")) != -1) {
needs to be
 while((c=getopt(argc, argv, "tThfdvVqprRgcinsx:U:G:C:L:M:")) != -1) {

(Notice the x and s option reversal. x has an argument, s does not).

If this goes in, can we increase the required verbosity for the ast_verbose in ast_silence_suppression_enabled in channel.c? That's way too chatty on my console with default verbose = 3. Thanks!

By: Sergey Okhapkin (sokhapkin) 2005-11-12 14:57:04.000-0600

Oops, kuj, thank you for your note, x<==>s getopt options order changed (*-1 patch). Regarding verbosity level, I don't think it would worth to report it with a level < 3, this "insignificant" feature just works:-) Thanx to cmantunes.

By: Sergey Okhapkin (sokhapkin) 2005-11-13 15:50:50.000-0600

I need help... The check in ast_silence_suppression_enabled() is

ret = option_silence_suppression && chan->timingfunc && chan->timingfd > -1;

What is the reason to check for chan->timingfunc??? It shouldn't matter if callback timer function is registered or not, only chan->timingfd matters. Am I wrong? I modified the line to be

ret = option_silence_suppression && chan->timingfd > -1;

And... It works fine! chan_sip no longer sends a=silenceSupp:off in SDP and everything seems to me working fine, all FXS ports connected to asterisk are set to SS mode, IAX calls are fine also. I would like everyone to try the same, I didn't find any problems so far, "rtp debug" shows one way RTP traffic on "Background" or voicemail prompts.

If I don't get any complaints I will upload a modified patch.

By: Sergey Okhapkin (sokhapkin) 2005-11-15 16:09:20.000-0600

I updated the patch to not check for chan->timingfunc and to reflect recent CVS HEAD "doxyfication" changes.

By: Serge Vecher (serge-v) 2005-11-15 16:14:11.000-0600

sokhapkin:

Does your patch complement or replace cmantunes's patch? If former, is there any sequence to applying them? In that case, perhaps you could merge them into one patch for ease of application. Thanks

By: Sergey Okhapkin (sokhapkin) 2005-11-15 16:24:55.000-0600

vechers: my patch replaces cmantunes patch, it's an extension of cmantunes patch.

By: dea (dea) 2005-11-18 12:15:27.000-0600

The commandline option -s works fine, but the asterisk.conf does not.
option_silence_supression defaults to 0
The -s triggers option_silence_supression++
while the config file entry relies on option_silence_supression = ast_true(v->value)

It looks like replacing line 1895 :
option_silence_supression = ast_true(v->value)
with:
if (ast_true(v->value)
    option_silence_supression++;
would resolve the issue.

By: Sergey Okhapkin (sokhapkin) 2005-11-18 12:23:49.000-0600

DEA: in asterisk.conf I have

silence_suppression=1

Asterisk is started without -s command line option, ang the log shows

Nov 18 08:56:57 VERBOSE[19684] logger.c:     -- Silence suppression is enabled (
option_silence_suppression=-1 chan->timingfd=27)

I suspect you put option_silence_suppression=1 (or true) instead of silence_suppression=1 (or true).

By: dea (dea) 2005-11-18 13:31:43.000-0600

Nope.  silence_supression=yes
I tried silence_supression=1, but that also fails.

I'm most interested in enabling this support in MeetMe conferences
from chan_ooh323.

Call from chan_ooh323 to chan_sip works.
Call from chan_sip to chan_ooh323 fails.
Call from chan_sip to MeetMe works.
Call from chan_ooh323 to MeetMe fails.

By works, I mean that I get this:
-- Silence suppression is enabled (option_silence_suppression=1 chan->timingfd=30)

By fails, I get no output, not even the disabled notice.

I applied the patch to 1.2.0 with a handful of rejects, which I
tried to merge manually, so I may have screwed it up.

By: dea (dea) 2005-11-18 13:36:08.000-0600

OK, I contiune to prove I am an idiot.  There's two 'P's in suppresion.

The rest of the report is accurate.  I'll poke to see how, if within
my knowledge, to add support to chan_ooh323.

Thanks.

By: Sergey Okhapkin (sokhapkin) 2005-11-19 08:09:05.000-0600

Added silence_suppression option to README.asterisk.conf

By: Atif Rasheed (atif) 2005-11-20 10:49:02.000-0600

Just tried to compile cvs-v1-2-0-beta2 after applying silence-suppression-3.diff. But hunks failed for asterisk.c, chan_sip.c, README.asterisk.conf.
which tag this patch works with beta1 or beta2.

By: Sergey Okhapkin (sokhapkin) 2005-11-20 12:20:28.000-0600

The patch is against CVS HEAD.

By: Serge Vecher (serge-v) 2005-11-20 17:24:23.000-0600

atif: 1.2 has been released -- why bother with betas?

By: Atif Rasheed (atif) 2005-11-20 23:51:37.000-0600

sorry guys, little confused .... cvs-head or cvs-v1-2-0.

sokhapkin: cvs-head of which branch 1-0 or 1-2 ???

By: Olle Johansson (oej) 2005-11-21 02:48:09.000-0600

cvs head is now version 1.3 and that's where we add new functionality. Release version (tagged) is 1.2.

By: Atif Rasheed (atif) 2005-11-22 11:49:23.000-0600

Thanx all for help, patch also worked with cvs-v1-2-0, and its working. right now I have only tested it for MOH which is working beautifully with Nuera Media Gateways.

one suggestion: that verbose message "Silence Suppression is Enabled" should be thrown once. Its probably coming with each voice frame :)



By: Andrew Lindh (andrew) 2005-11-22 15:13:08.000-0600

I think this should go into CVS HEAD (now 1.3) so it can be well tested and then back ported into the 1.2 version. I was hoping that it was going to be part of 1.2 before it's release (yes, I know I can still patch 1.2 installs and I do).

By: reformed (reformed) 2005-11-22 15:26:53.000-0600

I think it well tested already.
At least from my prospective. :)
The patch is running on production server doing many, many calls and i had nothing but good feedback about it.

It works, improves the quality of the audio on high latency links and makes mute function work properly on Grandstream phones (they cut outgoing RTP stream).
Also a nice side effect is that CC machines and faxes on ATA’s started working more reliably.
My logic tells me that async rtp stream would actually be bad for them but here we are…

If it makes it into 1.3 I’d be glad!



By: BJ Weschke (bweschke) 2005-12-05 22:17:05.000-0600

I've updated the patch to be in spec with drumkilla's latest config macro changes to /trunk and put it into /asterisk/team/bweschke/bug_5374 in the SVN repository so we can keep the branch from getting stale as changes continue and it should be fairly easy to merge back in when it's ready to be merged.

I tested this tonight against X-Lite with Transmit Silence set to "No". It worked well.

By: raarts (raarts) 2005-12-08 06:14:45.000-0600

I am testing silence-suppression-3.diff with
some SIP provider. I noticed in the source that
asterisk *always* says silence suppression is not
supported when using G729A. (In chan_sip in
function add_codec_to_sd()).

Is this some known limitation?

By: Andrew Lindh (andrew) 2005-12-08 09:06:28.000-0600

I guess that's a rhetorical question....

According to the standard:
G.729a does not include silence suppression,
G.729b does include silence suppression.

And as far as I know, there is no G.729b codec available for Asterisk.....

http://www.nortel.com/products/01/succession/es/collateral/tb_g729.pdf

By: raarts (raarts) 2005-12-08 09:22:38.000-0600

No, a rhetorical question is one you already know the answer to. Anyway, thanks for clarifying this. I guess we won't be doing VAD support with G729 even with this patch.

You (andrew) reported having used g729 successfully with this patch between phones and asterisk. And I inferred you tested with VAD enabled. But that was wrong.

Is there a list of codecs vs VAD support?

By: Andrew Lindh (andrew) 2005-12-08 09:39:56.000-0600

I did not use VAD with G.729....it was more of a cisco issue that the as5300/7960 was trying to force use of VAD/G.729B and asterisk was very unhappy with that (calls did not work). With Asterisk (as of v1.2.1) explicitly saying NO ANNEX B (no supression) on G.729 things are working correctly.

(sorry, did not mean to sound that harsh in the last post)

By: apignard (apignard) 2005-12-11 16:32:28.000-0600

i have a customer how send us call with cisco as5x00 and have disable comfort noise but we still get "process_rfc3389: Comfort noise support incomplete in Asterisk (RFC 3389)" (G729 only used). Seems this patch can help me for better support ? Currently testing the patch without crash (around 7000 calls today) but not sure of improve result (ACD stats seems unchange).

By: reformed (reformed) 2005-12-11 18:07:48.000-0600

This is post 1.2 right?

Is this going to SVN in any near future?

It is well tested in our environment and so far you're getting only positive feedback about it. :)

Thanks

By: ctrix1972 (ctrix1972) 2005-12-12 08:57:36.000-0600

It works for me.
Faxes over SIP with *law works better than before.
I'm wondering if, with some patches to rx_fax & tx_fax, they may work too (I know these are 3rd party modules)

By: reformed (reformed) 2005-12-19 17:12:01.000-0600

Latest patch is not compatible with latest -HEAD.
Can this be updated so it applies cleanly to -HEAD (with the new options structure) or be integrated to -HEAD?

Please? Thanks! :)

By: BJ Weschke (bweschke) 2005-12-19 17:15:11.000-0600

reformed: current code is available at http://svn.digium.com/view/asterisk/team/bweschke/bug_5374/ for checkout via svn.

By: hypherion (hypherion) 2005-12-22 17:21:46.000-0600

I seem to be experiencing a crash with Asterisk 1.2.1 and this patch applied:

#0  0x080672e7 in ast_silence_suppression_enabled (chan=0x0) at channel.c:1778
1778            int ret = option_silence_suppression && chan->timingfd > -1;
(gdb) bt
#0  0x080672e7 in ast_silence_suppression_enabled (chan=0x0) at channel.c:1778
#1  0x0050b4de in add_sdp (resp=0x5f7620, p=0x97109e8) at chan_sip.c:4450
#2  0x004ff1d3 in transmit_invite (p=0x97109e8, sipmethod=5, sdp=1, init=1) at chan_sip.c:4926
#3  0x00527716 in do_proxy_auth (p=0x97109e8, req=0x97109e8, header=0x97109e8 "\001", respheader=0x97109e8 "\001", sipmethod=5, init=158403048)
   at chan_sip.c:8885
#4  0x0052cff4 in handle_response_invite (p=0x97109e8, resp=5439001, rest=0x605984 "Proxy Authentication Required", req=0x605760, ignore=0, seqno=102)
   at chan_sip.c:9516
ASTERISK-1  0x00523c23 in handle_response (p=0x97109e8, resp=0, rest=0x605984 "Proxy Authentication Required", req=0x605760, ignore=0, seqno=102)
   at chan_sip.c:9776
ASTERISK-2  0x0051f563 in handle_request (p=0x97109e8, req=0x605760, sin=0x605750, recount=0x97109e8, nounlock=0x97109e8) at chan_sip.c:10901
ASTERISK-3  0x0051c761 in sipsock_read (id=0x94cd7e8, fd=12, events=1, ignore=0x0) at chan_sip.c:11100
ASTERISK-4  0x0805584b in ast_io_wait (ioc=0x94c1cd0, howlong=158403048) at io.c:284
ASTERISK-5  0x00512a0a in do_monitor (data=0x0) at chan_sip.c:11249
ASTERISK-6 0x00e0fdec in start_thread () from /lib/tls/libpthread.so.0
ASTERISK-7 0x001eda2a in clone () from /lib/tls/libc.so.6

I'm not familiar with gdb but it seems that the crash occured in the silence suppression code..

By: Sergey Okhapkin (sokhapkin) 2005-12-22 17:43:27.000-0600

Hmm, seems to me like asterisk bug not related to the patch.

(gdb) bt
http://bugs.digium.com/view.php?id=0  0x080672e7 in
ast_silence_suppression_enabled (chan=0x0) at
channel.c:1778

Why chan=0???

To avoid the crash ast_silence_suppression_enabled() could be modified:

int ret = option_silence_suppression && chan && chan->timingfd > -1

By: dea (dea) 2005-12-29 12:56:32.000-0600

Silence_suppression-4.diff applies to SVN from 12/29/2005.
I added a small patch to the Makefile to create the proper
option in asterisk.conf, defaulted to disabled.

By: BJ Weschke (bweschke) 2005-12-29 13:42:16.000-0600

DEA: This original patch has already been ported to /trunk and is being kept current to /trunk here: http://svn.digium.com/view/asterisk/team/bweschke/bug_5374/

Can you please take a look at that code and let me know if there's anything I've missed in the original port of the patch that you've got in your diff?

By: dea (dea) 2005-12-29 14:10:59.000-0600

I'm new to subversion, but a quick check looks good except the Makefile
changes.  It took me awhile to figure out the correct option to add to
the asterisk.conf, so I thought it would be appropriate to add to the
make install.

Oh, and disclaimer on file.

By: Matt Ranney (mjrmjr2) 2006-01-04 12:00:05.000-0600

I've been running team/bweschke/bug_5374 for a while on a few different servers, and it has caused no ill effects.  Can this be added to trunk soon?

By: BJ Weschke (bweschke) 2006-01-13 10:55:58.000-0600

HOUSEKEEPING

markster - we really need your "yes or no" before we can move forward with committing this to /trunk. several sites have it in production and aren't reporting problems and your earlier suggestion to make it an option to be on or off has been implemented. Latest code is being maintained in the branch at http://svn.digium.com/view/asterisk/team/bweschke/bug_5374/

By: apignard (apignard) 2006-01-16 19:17:29.000-0600

Working fine here, terminate 2 E1 from a CISCO and still no crash and better ACD since active

By: reformed (reformed) 2006-01-18 00:04:22.000-0600

Is it in sync with the trunk?

Generating a diff between the trunk and this bug gives me a HUGE diff.
I'm unable to install any revisions after 7710 because i cannot get this patch on any other revision

Are we expecting it to be merged any time soon?
I probably understand Digium's reluctance to merge it because the patch sell's itself a silence suppression (the options to use).

It really is a sync/async clock generation switch. :)


PLEASE, can we move from a "dead" point here and have it in the trunk?
Its a patch that can be turned on/off at startup and it defaults to off so i dont see any problems with merging it. :)

Sorry to be so pushy? :)

By: puzzled (puzzled) 2006-01-19 16:01:15.000-0600

Is there a version of this patch available that applies to the 1.2 branch? I am interested in testing it but only have boxes running 1.2 branch. Thanks.

By: dea (dea) 2006-01-19 16:17:07.000-0600

Puzzled,
The patch silence-suppression-4.diff has a pretty good chance to apply.
It's based of an early branch of trunk, and I think I've applied it to
a 1.2.X

By: reformed (reformed) 2006-01-20 04:46:06.000-0600

bweschke: you're legend!!! :) automerged /team/bweschke/bug_6047/

Thank you!!!!!!!!

By: Nikolai Saoukh (nms) 2006-01-22 01:30:25.000-0600

Well, this patch is little bit noisy for verbose modes. It write "-- Silence suppression is enabled (option_silence_suppression ...." for every rtp packet while playing music_on_hold, IMHO.

By: Matt Ranney (mjrmjr2) 2006-01-27 15:24:00.000-0600

Does the /asterisk/team/bweschke/bug_5374/ tree have the timestamp wraparound bridged channels problem fixed?  I just checked out a fresh copy on a new machine, and I had either one-way or no audio.

Oh, how I wish this fix was in trunk.

By: Matthew Fredrickson (mattf) 2006-01-27 16:58:32.000-0600

I see no problems with moving this along.  Bweschke, do you feel this is ready to be put into trunk?

By: reformed (reformed) 2006-01-27 18:12:42.000-0600

I'm thinking all the oprions should be renamed from silence supressions something else like async clock gen. it will confuse people..

By: BJ Weschke (bweschke) 2006-01-28 07:32:48.000-0600

I've just brought the branch up to date with /trunk. My apologies for not having it done it earlier. I've also moved the verbose msg about silence suppression being enabled from _read to _answer in channel.c so it's no longer so chatty as it might have previously been under certain circumstances (MOH, etc).
mattf: I think this one has been ready to go. We just need to get signoff from markster or kpfleming and that's what this one has been waiting on.

By: Tony Mountifield (softins) 2006-01-28 15:17:42.000-0600

There was an issue reported by BRIstuff users where MoH was messed up (double speed or something) when using this patch with silence suppression turned off. Has this been investigated?

I had a look at the latest patch on this bugnote, and noticed that when silence suppression is OFF, the code logic in channel.c does not revert exactly to what it was before the patch was applied:

(a) this segment was removed by the patch, but is not restored when silence_suppression=no:

if (chan->timingfunc) {
ast_log(LOG_DEBUG, "Generator got voice, switching to phase locked mode\n");
ast_settimeout(chan, 0, NULL, NULL);
}

(b) likewise for this segment:

} else if (f && (f->frametype == AST_FRAME_CNG)) {
if (chan->generator && !chan->timingfunc && (chan->timingfd > -1)) {
ast_log(LOG_DEBUG, "Generator got CNG, switching to zap timed mode\n");
ast_settimeout(chan, 160, generator_force, chan);
}

I haven't had time to check these out myself, but thought it might help to flag them up.

By: dea (dea) 2006-01-31 13:53:59.000-0600

I came to the same findings as Softins.  I re-implimented those checks
and MoH quality was restored.  I'm not sure this is the right way to
handle it, but I've run out of options to try.

By: Sergey Okhapkin (sokhapkin) 2006-02-02 17:34:07.000-0600

bweschke, any chance to upgrade /team/bweschke/bug_5374 to SVN HEAD?

By: BJ Weschke (bweschke) 2006-02-06 02:34:32.000-0600

Will try and get the branch back up to date with /trunk sometime today. Sorry for the delay.

By: BJ Weschke (bweschke) 2006-02-07 12:37:06.000-0600

The branch is now back in tune with the latest and greatest in /trunk

By: juan salas (jsalas) 2006-02-09 14:11:12.000-0600

Hello, I am newy on this patch...
I am using asterisk 1.2.4, can I patch this version?
What version I must to use?

Thanks.

By: Serge Vecher (serge-v) 2006-02-09 14:16:11.000-0600

jsalas: there are no patches for the stable branch. You will have to test the /team/bweschke/bug_5374 branch from Digium's svn server to test this feature.

By: jacs (jacs) 2006-02-10 03:33:03.000-0600

bweschke, did markster respond to your housekeeping call? Its 3 months since he posted anything on this.

By: Nikolai Saoukh (nms) 2006-02-10 03:59:08.000-0600

Small suggestion -- rename option name from 'silence_suppression' to 'async_rtp_frames'.

By: puzzled (puzzled) 2006-02-17 05:48:08.000-0600

Hi, I made tried a version of silence_suppression-4.diff that applies cleanly to asterisk-1.2.4. Compilation with gcc-4.0.2 on Fedora Core 4 shows a couple of warnings. I am not C proficient enough to fix these warnings so any help is most welcome. Since I'm on a offnet laptop I have not tested if this patch works properly. I know Asterisk starts fine and I could enable rtcp stats. Warnings:
gcc  -pipe  -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations  -Iinclude -I../include -D_REENTRANT -D_GNU_SOURCE  -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64 -mtune=nocona -DZAPTEL_OPTIMIZATIONS         -m64 -fomit-frame-pointer  -DT38_SUPPORT   -c -o rtp.o rtp.c
rtp.c:204: warning: no previous prototype for 'timeval2ntp'
rtp.c:226: warning: no previous prototype for 'ast_rtcp_calc_interval'
rtp.c:1335: warning: no previous prototype for 'ast_rtp_get_quality'
rtp.c:1495: warning: no previous prototype for 'ast_rtcp_send_h261fur'
rtp.c:1506: warning: no previous prototype for 'ast_rtcp_write_sr'
rtp.c:1618: warning: no previous prototype for 'ast_rtcp_write_rr'

By: puzzled (puzzled) 2006-02-17 05:53:29.000-0600

Please ignore my previous remark about the rtp.c warnings. They are related to ASTERISK-2815. Sorry for the mixup.

By: philipp2 (philipp2) 2006-02-20 15:27:16.000-0600

Just a note about what I just came across in the 'changes' file of bristuff

bristuff 0.3.0-PRE-1h
- REMOVED patch for bug 5374 (asynchronous generation of outgoing frames) since it was affection MusicOnHold, SMS and IAX2 jitter buffer

Note that bristuff is now at 0.3.0-PRE-1l. The MoH issue was apparently already adressed, but I see no mention of SMS or IAX2 jb compatibility problems here. I don't currently test this patch, but maybe I can still somehow be of help with this info.

By: James Feeney (james nurealm net) 2006-02-22 19:48:27.000-0600

Using patch  asterisk-1.2.4-silence_suppression-4.patch on asterisk-1.2.4 with Fedora Core 4, which has
"gcc (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8)".

mpg123-0.59r does not work - no sound output.  This shows up as a problem for MusicOnHold, which creates the impression of MOH not working since there is no sound output from mpg123.  mpg123-0.59r will not even compile with "make linux-alsa".

madplay, though, from madplay-0.15.2b, works for MusicOnHold, with configuration based on the example in musiconhold.conf.

The silence_suppression patch also generates around 350 lines of
   -- Silence suppression is disabled (option_silence_suppression=0 chan->timingfd=23)
of debug output with sip debug for MusicOnHold - still.  Very annoying.

By: Mark Spencer (markster) 2006-02-23 11:20:59.000-0600

I'm basically okay with this.  My only real concern is that the option name doesn't really describe what's going on.  This patch doesn't enable silence suppression.  All it does is it changes how we handle generators.  I suggest we call it something like "internal_timing" or "generate_timing" or something better that would more clearly indicate what the purpose of this patch is.  It's possible that we might have another patch one that that caused Asterisk to *really* do silence suppression.

By: Hakan Lindestaf (hakanl) 2006-02-27 01:00:23.000-0600

Are you suggesting that more or less all references to silence suppression in this patch is changed to internal/generate timing?

On another note, I don't really see the need to maintain a command line parameter for this since it can be set in the conf-file. I believe only settings that affect the major "interface" of an application should be specified on the command line (for example no fork, verbose level, etc). Options could be specified with a generic "-o option1=yes" or something like that, but not take up "new characters like -s". My personal take on command lines...

By: Jamuel Starkey (jamuel) 2006-03-07 05:09:17.000-0600

Seems like the Asterisk generated dial tone (say when the user presses # to park a call) is distorted/affected (sounds like it's switching on and off really fast so the user hears more of a fluttering or buzzing or static-ky sort of dialtone)   MOH for the caller that is placed on hold sounds fine.  

If you have verbose = 3 and are viewing logging messages from the CLI you can sort of associated the really fast breaks in dialtone with the logging entries generated (i.e. Silence suppression is disabled (option_silence_suppression=0 chan->timingfd=27))

Hope that is descriptive enough.

I tried this patch with 1.2.4 and 1.2.5 on a FC4 box and had the same results.

By: Olle Johansson (oej) 2006-03-07 13:52:12.000-0600

Kind of agree with Mark, that this is not Silence Suppression. This is a patch that puts us on a timed clock instead of running on incoming packets, which has the effect that the devices that communicates with us can enable silence suppression.

As I see it, but I may be wrong, this patch does not enable silence suppression in Asterisk, meaning that it does not add a function that checks for silence in the media stream and stops sending empty audio packets.

By: Olle Johansson (oej) 2006-03-07 14:08:25.000-0600

sokhapkin: We need a confirmation of your disclaimer since you added code to this patch.

cmantunes and DEA have confirmed their respective dislaimers.

Anyone else that was involved in producing this patch?

As soon as we've changed the names, I want to include this in the test-this-branch branch.

By: Donny Kavanagh (donnyk) 2006-03-07 14:20:24.000-0600

I agree with mark and oej, this really isnt silent supression, its a patch to allow * communicate with devices that support silence suppresion without breaking the return stream due to now using a timer as a rtp timeing source rather then the incomming packets.

Curious question, with this patch if two sip phones are connected via * with this patch, with canreinvite=no (so asterisk remains in the stream) and both have silence supression enabled.  Will everything work correct, with silence supression and all to both legs of the call?

By: Sergey Okhapkin (sokhapkin) 2006-03-07 14:29:11.000-0600

oej: my disclaimer should be on file with Digium, I sent it when fixed some ael issues.

By: Donny Kavanagh (donnyk) 2006-03-07 14:34:32.000-0600

I kinda didnt explain my question clear, here goes again.

With this patch, * and two silence suppression supporting phones.

With canreinvite=no

Which of the following will happen:
a) the calls are bridged through asterisk, * receives the silence supression enabled rtp from the phone, mangles it into its own audio engine, and transmits a non silence supression enabled stream to the receiving phone.

b) same as above, except the silence supression enabled rtp flows through to the other end point.

I'm going to safely assume a? Since as mark mentioned this patch does not enable silence supression in asterisk, it only allows us to receive it without causing timeing issues.

By: Olle Johansson (oej) 2006-03-07 14:46:03.000-0600

sokhapkin: Thanks for confirming disclaimer. You need to confirm it in every issue report you contribute in, so we have it in the archives.

By: mike240se (mike240se) 2006-03-07 20:56:07.000-0600

So if i have problems with music on hold, where the caller always has choppy musiconhold where it cuts out alot, but the telephone conversation is pretty much ok, this could be helpful?  The other end is teliax, so i dont think silence supresion is on, but i guess any packets lost from them, will cause the outgoing music to be messed up?

By: Olle Johansson (oej) 2006-03-22 15:09:19.000-0600

since bweschke's branch hasn't been updated for five weeks, I've created a new branch to make some changes and test this.

team/oej/rtptiming

By: Olle Johansson (oej) 2006-03-22 15:24:22.000-0600

Changed the name of the option to "internal_timing" and the setting to 'I' (upper-case i).

Please test this branch. Thanks.

By: Olle Johansson (oej) 2006-03-22 15:30:26.000-0600

Now also included in test-this-branch.

By: mtaht (mtaht) 2006-03-23 16:37:10.000-0600

OK, so I pulled down this branch and started testing the rtp clocking code

testing from asterisk 1.2.5 FC3 -> test-this-branch on linux 2.6.12 FC1 box

issues:

I think the new iax threaded code is causing all sorts of problems on this older OS and kernel. I randomly get anything from a busy signal to no audio on successive calls to app_milliwatt and echo. Admittedly this is on a box with the older threading model (linuxthreads)

upgrading to a FC4 test-this-branch connecting to a FC5 test-this-branch shortly
(ntpl)... -r 14560M

OK, updated to FC5 on a 1Ghz C3 box with SJPhone, ztdummy, asterisk -p Started by going back to "internal timing is disabled". (screenfuls at verbosity=3) There is a regular interruption in app_milliwatt approximately once every 6 seconds that isn't there on a "normal asterisk" box. set internal_timing=yes (screenfuls of internal timing is enabled) - no sound from app_milliwatt, no sound at all...

installing a real T1 card next.....



By: mtaht (mtaht) 2006-03-24 11:15:51.000-0600

I rebuilt FC5 with linux-2.6.16 configured for preempt (1ms clock). Same issue - with internet_timing = no, app_milliwatt works with a regular roughly 4.5 second interruption (on SJPHONE), with = yes, no sound at all. I tried doing things like changing fstab to commit=30 on the filesystems and disabling ntp entirely, no dice.

On the other hand, the echo command is working this time.

to make sure I'm not chasing a chimera I'm going to put in a zaptel card, then go back to mainline then try the rtptiming branch rather than the test-this-branch....

Packet traces from app_milliwatt show that data is being sent, but it appears to be silence...
but first, some packet traces.



By: mtaht (mtaht) 2006-03-24 13:28:07.000-0600

The periodic gap in app_milliwatt appears to be an artifact of SJPhone. On a grandstream, and with the below applied, milliwatt is happy on a grandstream.

Ah, you missed app_milliwatt in this merge. fix is (disclaimer on file) is:

Index: apps/app_milliwatt.c
===================================================================
--- apps/app_milliwatt.c        (revision 14785)
+++ apps/app_milliwatt.c        (working copy)
@@ -71,13 +71,20 @@
{
       struct ast_frame wf;
       unsigned char buf[AST_FRIENDLY_OFFSET + 640];
-       int i,*indexp = (int *) data;
+       const int maxsamples = sizeof (buf) / sizeof (buf[0]);
+       int i, *indexp = (int *) data;
+       /* Instead of len, use samples, because channel.c generator_force
+        * generate(chan, tmp, 0, 160) ignores len. In any case, len is
+        * a multiple of samples, given by number of samples times bytes per
+        * sample. In the case of ulaw, len = samples. for signed linear
+        * len = 2 * samples                                                 */

-       if (len + AST_FRIENDLY_OFFSET > sizeof(buf))
-       {
-               ast_log(LOG_WARNING,"Only doing %d bytes (%d bytes requested)\n",(int)(sizeof(buf) - AST_FRIENDLY_OFFSET),len);
-               len = sizeof(buf) - AST_FRIENDLY_OFFSET;
-       }
+       if (samples > maxsamples)
+       {
+               ast_log(LOG_WARNING, "Only doing %d samples (%d requested)\n", maxsamples, samples);
+               samples = maxsamples;
+       }
+       len = samples * sizeof (buf[0]);
       wf.frametype = AST_FRAME_VOICE;
       wf.subclass = AST_FORMAT_ULAW;
       wf.offset = AST_FRIENDLY_OFFSET;



By: Olle Johansson (oej) 2006-03-27 20:07:31.000-0600

Updated the rtptiming branch and the test branch with Mike's patch.

By: Justin Unger (justinu) 2006-03-28 13:28:09.000-0600

Hi, I was referred to this issue from ASTERISK-4152.

I'm having the same problem described in that issue, 2 SIP channels in a meetme conference. No Zaptel hardwre, using Ztdummy. At first, latency is fine. But after a few minutes go buy, the latency between the two channels is well over a second.

I've applied the patch contained in this issue to Asterisk 1.2.6 (clean patch, btw) and enabled the misnamed "silence_supression" option.

I'm still having the problem with meetme latency though. Anyone have any suggestions or general knowledge that may help me solve this issue?

Thanks

By: Denis Smirnov (mithraen) 2006-03-28 14:18:45.000-0600

See at 5971, this patch to ztdummy can solve your problem

By: Olle Johansson (oej) 2006-03-28 17:21:45.000-0600

Fixed the -I switch on startup (I hope). Please update your branches, recompile and test.

By: Olle Johansson (oej) 2006-03-29 13:26:38.000-0600

We do need more test results from this patch, good and bad. THank you for your cooperation.

It's critical that we get material to base a decision on. We need to decide how to proceed with this code soon. Mark is positive about it, if it doesn't cause new crashes or bugs (of course) :-)

By: John Laur (gork) 2006-03-29 14:41:19.000-0600

I have been running it in production (with an unpatched version ready to go at a moment's notice) but have not had any problems. I have had fewer complaints regarding poor audio quality after installing the patch. We have a situation where our QoS on outbound traffic will cause the inbound to jitter when not using this patch. The problem is occasional and difficult to reproduce artificially, so I'm just relying on my complaint stack to tell me this is working right.

By: dea (dea) 2006-03-29 15:08:37.000-0600

I have an older version of the patch running against SVN-trunk-r7668M
and am quite pleased.

Unforunately I cannot upgrade at this time, so I don't know how much
value this report has.

By: hypherion (hypherion) 2006-03-29 20:05:56.000-0600

I still cannot get internal_timing to actually enable on test-this-branch.  It doesn't complain about the -I option anymore, but even with internal_timing=yes in asterisk.conf, it tells me it is disabled.  It was working great when it was silence_suppresion.



By: Olle Johansson (oej) 2006-03-30 00:02:27.000-0600

Committed to svn trunk after approval by markster.

Restored CNG support, fixed documentation and some other issues.

Thanks everyone for your hard work with code and testing - this is how we extend Asterisk!

/Olle and Mark

By: Olle Johansson (oej) 2006-03-30 00:07:20.000-0600

Rev 16473

By: Digium Subversion (svnbot) 2008-01-15 17:47:22.000-0600

Repository: asterisk
Revision: 14189

A   team/oej/rtptiming/

------------------------------------------------------------------------
r14189 | oej | 2008-01-15 17:47:22 -0600 (Tue, 15 Jan 2008) | 2 lines

Issue ASTERISK-5230 - Internal timing for RTP

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

http://svn.digium.com/view/asterisk?view=rev&revision=14189