The Asterisk Development Team is pleased to announce the release of Asterisk 1.8.9.0. This release is available for immediate download at http://downloads.asterisk.org/pub/telephony/asterisk/

The release of Asterisk 1.8.9.0 resolves several issues reported by the community and would have not been possible without your participation.

Thank you!

The following is a sample of the issues resolved in this release:

* AST-2012-001: prevent crash when an SDP offer is received with an encrypted video stream when support for video is disabled and res_srtp is loaded. (closes issue ASTERISK-19202)
Reported by: Catalin Sanda

* Handle AST_CONTROL_UPDATE_RTP_PEER frames in local bridge loop. Failing
to handle AST_CONTROL_UPDATE_RTP_PEER frames in the local bridge loop
causes the loop to exit prematurely. This causes a variety of negative side
effects, depending on when the loop exits. This patch handles the frame by
essentially swallowing the frame in the local loop, as the current channel
drivers expect the RTP bridge to handle the frame, and, in the case of the
local bridge loop, no additional action is necessary.
(closes issue ASTERISK-19095) Reported by: Stefan Schmidt Tested
by: Matt Jordan

* Fix timing source dependency issues with MOH. Prior to this patch,
res_musiconhold existed at the same module priority level as the timing
sources that it depends on. This would cause a problem when music on
hold was reloaded, as the timing source could be changed after
res_musiconhold was processed. This patch adds a new module priority
level, AST_MODPRI_TIMING, that the various timing modules are now loaded
at. This now occurs before loading other resource modules, such
that the timing source is guaranteed to be set prior to resolving
the timing source dependencies.
(closes issue ASTERISK-17474) Reporter: Luke H Tested by: Luke H,
Vladimir Mikhelson, zzsurf, Wes Van Tlghem, elguero, Thomas Arimont
Patched by elguero

* Fix RTP reference leak. If a blind transfer were initiated using a
REFER without a prior reINVITE to place the call on hold, AND if Asterisk
were sending RTCP reports, then there was a reference leak for the
RTP instance of the transferrer.
(closes issue ASTERISK-19192) Reported by: Tyuta Vitali

* Fix blind transfers from failing if an ‘h’ extension
is present. This prevents the ‘h’ extension from being run on the
transferee channel when it is transferred via a native transfer
mechanism such as SIP REFER. (closes issue ASTERISK-19173) Reported
by: Ross Beer Tested by: Kristjan Vrban Patches: ASTERISK-19173 by
Mark Michelson (license 5049)

* Restore call progress code for analog ports. Extracting sig_analog
from chan_dahdi lost call progress detection functionality. Fix
analog ports from considering a call answered immediately after
dialing has completed if the callprogress option is enabled.
(closes issue ASTERISK-18841)
Reported by: Richard Miller Patched by Richard Miller

* Fix regression that ‘rtp/rtcp set debup ip’ only works when a port
was also specified.
(closes issue ASTERISK-18693) Reported by: Davide Dal Reviewed by:
Walter Doekes

For a full list of changes in this release candidate, please see the ChangeLog:

http://downloads.asterisk.org/pub/telephony/asterisk/ChangeLog-1.8.9.0

Thank you for your continued support of Asterisk!

Greetings-

I’m about to dive into the process of virtualizing some of my Asterisk (primarily 1.4.x) infrastructure. In the past, when looking at virt solutions, the primary issue preventing me from moving was the lack of proper timing. We do not need it for MeetMe but rather for IAX2 trunking. I’d like to use either OpenVZ or KVM, but each seem to have independent “issues” that need to be addressed:

OpenVZ – Better resource usage, lower overhead. Primary issue is how to grant access to host node timing source (physical device, or dahdi_dummy in /dev/dahdi/) to the containerized Asterisk process.

KVM – Higher overhead, easier installation, ‘true virtualization’. Primary issue is not timing per se, but KVM scheduling. Timing source, while present from dahdi_dummy natively may still not get proper scheduling by KVM process. This could also affect general call quality (even non IAX2 trunked voice), DTMF, etc.

I have to believe there are others running virtualized Asterisk installations with some degree of success on OpenVZ or KVM. Care to share your thoughts?

You mean say

0=Slave (Use PSTN clock)
1=Master(generate Internal clock)

So best option is 0 for all span if you connected on PSTN right ?

Date: Fri, 27 May 2011 17:27:43 -0300
From: rafaelsnsa@gmail.com
To: asterisk-users@lists.digium.com
Subject: Re: [asterisk-users] DAHDI span timeing source

Hi
The timing source is the clock of the system. When a equipment is 0, the other should be 1. The correct is: 0=slave, 1=master. The default for private systems is “slave”.

On Fri, May 27, 2011 at 05:30:02PM +0000, daniel@danielknoll.de wrote:
>
> What is better more cores (eg. 2x quadcore) or more CPU speed for a server
> that handle a lot of of Meetme Concerences with hundreds of concurrent G711
> alaw Channels (no transcoding) ?
>
> in my opinion, more cores are better, because Asterisk ist multithreded and
> each channel has a good chance to distribute to the cores.
>
> is that right or what do you think?

I don’t have an answer for you (too many unknown variables to say one way or
another) but I do know that MeetMe currently is serialized onto a single CPU.

For example, all the conference participants threads queue up their audio data
on their pseudo channels which can happen in parallel on SMP systems. Then
they wait for the “masterspan” to mix the audio for all conferences currently
active. This happens on a single CPU to simplifly keeping channels
synchronized to whatever timing source is your master. When this was
originally written there were not too many SMP systems in use. Then the mixed
audio is queued back on the channels. Finally, all the user space channel
threads can read out the mixed audio which can happen in parallel on SMP.

If you have too many conferences, one CPU may not be able to mix all the audio
and you will have audio problems even if there are 7+ other CPUs that are
essentially idle while waiting for one CPU to mix everything. You should be
able to handle 512 conference participants on a modern server system without
problem. The current trunk of DAHDI linux limits the number of open pseudo
channels to 512 for this reason. [1]

[1] http://svn.asterisk.org/view/dahdi?view=revision&revision=9610

The new ConfBridge module in the upcoming 1.10 release may not have this
limitation.

On Tue, Mar 22, 2011 at 12:53 PM, satish patel wrote:
> Hey Guys!
>
> We have two Asterisk with A102D Sangoma cards now i want to connect them
> back-to-back over PRI line via Cross-cable so what would be the
> configuration specially timing source and all? anybody did it before like
> this ?
>
> I want to make sure everything before putting in production.. (saving my
> downtime)
>
> -S
>

If is no different then setting up the card to connect with a telco.
One Asterisk box will be the net and the other is cpe. You can use
whatever protocol national, 5ess, etc you like. Any reason not to join
the boxes via SIP?

Ryan