The issue at hand is that some legacy (dying) PBX systems send empty media frames on PRI
links *before* any call progress. The SIP channel receives these frames and by default
signals 183 Session progress and starts sending media. This will cause phones to
play silence and ignore the later 180 ringing message. A bad user experience.
The fix is twofold:
- We discovered that asterisk apps that support early media ("noanswer") did not send
any PROGRESS frame to indicate early media. Fixed.
- We introduce a setting in chan_sip so that users can disable any relay of media frames
before the outbound channel actually indicates any sort of call progress.
In 1.4, 1.6.0 and 1.6.1, this will be disabled for backward compatibility. In later versions
of Asterisk, this will be enabled. We don't assume that it will change your Asterisk
phone experience - only for the better.
We encourage third-party application developers to make sure that if they have applications
that wants to send early media, add a PROGRESS control frame transmission to make sure that
all channel drivers actually will start sending early media. This has not been the default
in Asterisk previous to this patch, so if you got inspiration from our code, you need to
update accordingly. Sorry for the trouble and thanks for your support.
This code has been running for a few months in a large scale installation (over 250
servers with PRI and/or BRI links to old PBX systems).
That's no proof that this is an excellent patch, but, well, it's tested :-)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@216430 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We have kept this comment around long enough, that it's pretty clear that we're
keeping the code, because changing the code would require a pretty fundamental
architectural shift. We've also taken criticism in some quarters, because it
was believed that it was referring to the code being nasty. No, the code isn't
nasty, just the operation itself is rather odd. Fixed for eternity (probably
not).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@214701 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In ast_write(), if a channel has a list of audiohooks, those
lists are written to and the resulting frame is what ast_write()
should continue with. The problem was the returned audiohook frame
was not being handled at all, and the original frame passed
into it did not contain the mixed audio, so essentially audio
was being lost. One result of this was chan_spy's whisper
mode no longer worked. To complicate the issue, frames
passed into ast_write may either be a single frame, or a list
of frames. So, as the list of frames is processed in the
audiohook_write, the returned frames had to be added to a new
list.
(closes issue #15660)
Reported by: corruptor
Tested by: dvossel
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@214194 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Without this patch, asterisk creates a temporary file before determining if the
specified command is valid. If invalid, we weren't properly cleaning up the file.
(closes issue #15730)
Reported by: zmehmood
Patches:
M15730.diff uploaded by junky (license 177)
Tested by: zmehmood
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@212763 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The latest GCC (what will become 4.5.x) has a few new warnings, that in these
cases found some either downright buggy code, or at least seriously poorly
designed code that could be improved.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@209759 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are some VoIP providers out there that will not accept SDP
offers with odd numbered UDPTL ports. While it is my personal opinion
that these VoIP providers are misinterpreting RFC 2327, it really is
not a big deal to play along with their silly little games. Of course,
since restricting UDPTL ports to only even numbers reduces the range
of available ports by half, so the option to use only even port numbers
is off by default. A user can enable the behavior by setting
use_even_ports=yes in udptl.conf.
(closes issue #15182)
Reported by: CGMChris
Patches:
15182.patch uploaded by mmichelson (license 60)
Tested by: CGMChris
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@209131 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Mostly trivial changes, but I did not know of any other way to fix the
"dereferencing type-punned pointer will break strict-aliasing rules" error
without creating a tmp variable in chan_skinny.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@208746 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit changes the build system so that user-provided flags (in ASTCFLAGS
and ASTLDFLAGS) are supplied to the compiler/linker *after* all flags provided
by the build system itself, so that the user can effectively override the
build system's flags if desired. In addition, ASTCFLAGS and ASTLDFLAGS can now
be provided *either* in the environment before running 'make', or as variable
assignments on the 'make' command line. As a result, the use of COPTS and LDOPTS
is no longer necessary, so they are no longer documented, but are still supported
so as not to break existing build systems that supply them when building Asterisk.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@207647 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I changed this check to only happen in a dev-mode build. I also added a
comment explaining what is going on. I also made it so that detection of
this situation does not affect ast_read() operation.
(closes issue #14723)
Reported by: seadweller
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@207360 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the CALLERPRES() dialplan function is set to nothing,
a segfault occurs. This is user error to begin with, but
I'd rather see a cli warning message than have Asterisk
crash on me.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@206867 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes a few issues with incorrect extension states and adds
a cli command, core show device2extenstate, to display all possible
state mappings.
(closes issue #15413)
Reported by: legart
Patches:
exten_helper.diff uploaded by dvossel (license 671)
Tested by: dvossel, legart, amilcar
Review: https://reviewboard.asterisk.org/r/301/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@204681 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is nice change for users of the voicemail application. If someone gets a
little carried away with fast forwarding through a message, they can easily
get to the end and accidentally exit the voicemail application by hitting the
fast forward key during the following prompt.
This adds some safety by not allowing a fast forward past the end of a message.
(closes issue #14554)
Reported by: lacoursj
Patches:
21761.patch uploaded by lacoursj (license 707)
Tested by: lacoursj
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@203785 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It is possible for datastore fixup functions to remove the datastore from the list
and free it. In particular, the queue_transfer_fixup in app_queue does this. While
I don't yet know of this causing any crashes, it certainly could.
Found while discussing a separate issue with Brian Degenhardt.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@201450 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are various media paths in Asterisk (codec translators and UDPTL, primarily)
that can generate more than one frame to be generated when the application calling
them expects only a single frame. This patch addresses a number of those cases,
at least the primary ones to solve the known problems. In addition it removes the
broken TRACE_FRAMES support, fixes a number of bugs in various frame-related API
functions, and cleans up various code paths affected by these changes.
https://reviewboard.asterisk.org/r/175/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@200991 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Hints with two or more devices that include ONHOLD gave unexpected results.
(closes issue #15057)
Reported by: p_lindheimer
Patches:
onhold_trunk.diff uploaded by dvossel (license 671)
pbx.c.1.4.patch uploaded by p (license 558)
devicestate.c.trunk.patch uploaded by p (license 671)
Tested by: p_lindheimer, dvossel
Review: https://reviewboard.asterisk.org/r/254/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@199297 65c4cc65-6c06-0410-ace0-fbb531ad65f3
During asterisk startup, a lock on the list of modules is obtained by the
primary thread while each module is initialized. Issue 13778 pointed out a
problem with this approach, however. Because the AMI is loaded before other
modules, it is possible for a module reload to be issued by a connected client
(via Action: Command), causing a deadlock.
The resolution for 13778 was to move initialization of the manager to happen
after the other modules had already been lodaded. While this fixed this
particular issue, it caused a problem for users (like FreePBX) who call AMI
scripts via an #exec in a configuration file (See issue 15189).
The solution I have come up with is to defer any reload requests that come in
until after the server is fully booted. When a call comes in to
ast_module_reload (from wherever) before we are fully booted, the request is
added to a queue of pending requests. Once we are done booting up, we then
execute these deferred requests in turn.
Note that I have tried to make this a bit more intelligent in that it will not
queue up more than 1 request for the same module to be reloaded, and if a
general reload request comes in ('module reload') the queue is flushed and we
only issue a single deferred reload for the entire system.
As for how this will impact existing installations - Before 13778, a reload
issued before module initialization was completed would result in a deadlock.
After 13778, you simply couldn't connect to the manager during startup (which
causes problems with #exec-that-calls-AMI configuration files). I believe this
is a good general purpose solution that won't negatively impact existing
installations.
(closes issue #15189)
(closes issue #13778)
Reported by: p_lindheimer
Patches:
06032009_15189_deferred_reloads.diff uploaded by seanbright (license 71)
Tested by: p_lindheimer, seanbright
Review: https://reviewboard.asterisk.org/r/272/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@199022 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The function ast_call_forward() forwards a call to an extension specified in an ast_channel's call_forward string. After an ast_channel is called, if the channel's call_forward string is set this function can be used to forward the call to a new channel and terminate the original one. I have included this api call in both channel.c's ast_request_and_dial() and res_feature.c's feature_request_and_dial(). App_dial and app_queue already contain call forward logic specific for their application and options.
(closes issue #13630)
Reported by: festr
Review: https://reviewboard.asterisk.org/r/271/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@198891 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change also involves the addition of an AST_CDR_FLAG_ORIGINATED flag that is used on originated channels to distinguish: them from dialed channels.
(closes issue #12946)
Reported by: meral
Patches:
null-cdr2.diff uploaded by mnicholson (license 96)
Tested by: mnicholson, dbrooks
(closes issue #15122)
Reported by: sum
Tested by: sum
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@198068 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When we receive a SIP reinvite, it is possible that we may not be able to process the
reinvite immediately since we have also sent a reinvite out ourselves. The problem is
that whoever sent us the reinvite may have also sent a reinvite out to another party,
and that reinvite may have succeeded.
As a result, even though we are not going to accept the reinvite we just received, it
is important for us to not have problems if we suddenly start receiving RTP from a new
source. The fix for this is to grab the media source information from the SDP of the
reinvite that we receive. This information is passed to the RTP layer so that it will
know about the alternate source for media.
Review: https://reviewboard.asterisk.org/r/252
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@197588 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are two flags being added to the chanspy audiohook here. One
is the pre-existing AST_AUDIOHOOK_TRIGGER_SYNC flag. With this set,
we ensure that the read and write slinfactories on the audiohook do
not skew beyond a certain tolerance.
In addition, there is a new audiohook flag added here,
AST_AUDIOHOOK_SMALL_QUEUE. With this flag set, we do not allow for
a slinfactory to build up a substantial amount of audio before
flushing it. For this particular issue, this means that the person
spying on the call will hear the conversations in real time with very
little delay in the audio.
(closes issue #13745)
Reported by: geoffs
Patches:
13745.patch uploaded by mmichelson (license 60)
Tested by: snblitz
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@197537 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The bridge was terminating immediately after the attended transfer was
completed. The problem was because upon reentering ast_channel_bridge
nexteventts was checked to see if it was set and if so could possibly
return AST_BRIDGE_COMPLETE.
(closes issue #15183)
Reported by: andrebarbosa
Tested by: andrebarbosa, tootai, loloski
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@197124 65c4cc65-6c06-0410-ace0-fbb531ad65f3
