If we already have an address for a peer, and we are reloading the sip
configuration, try to use that address to contact the peer, instead of
getting it from the Contact.
(closes issue #15194)
Reported by: ibc
Patches:
sip.patch uploaded by eliel (license 64)
Tested by: manwe
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@197562 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 presence of rport is now stored as a separate flag. Once the dialog is setup and authenticated
(or it passes through unauthenticated) the proper nat flag is set.
(closes issue #13823)
Reported by: dimas
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@197466 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since we use bashisms in build_tools/mkpkgconfig, we should call on bash
explicitly when running from the Makefile, otherwise we get errors during a
'make install.'
(closes issue #15209)
Reported by: seandarcy
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@197264 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
command.
This change relates to r184980, which was a backport of the state interface
changes to app_queue from trunk. trunk and all of the 1.6.x branches are not
affected.
'queue add member' allows for specifying an interface to use for device state
when adding a queue member via CLI, but the validation code was not properly
updated to reflect this optional argument.
(closes issue #15198)
Reported by: loloski
Patches:
05272009_app_queue.diff uploaded by seanbright (license 71)
Tested by: loloski
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@197024 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The frames here should have always been freed. However, out of luck, there was
never any memory leaked. However, after file streams became reference counted,
this code would leak the file stream for the file being read.
(closes issue #15181)
Reported by: jkroon
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@196826 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are rare cases in which a frame's delivery timestamp is slightly less than the iax2_pvt's offset. This causes the pvt's timestamp to be a small negative number, but since the timestamp value is unsigned it looks like a huge positive number. This patch checks for this negative case and sets the ms to zero. A similar check is already done right below this one in the 'else' statement.
(closes issue #15032)
Reported by: guillecabeza
Patches:
chan_iax2.c.patch_timestamp uploaded by guillecabeza (license 380)
Tested by: guillecabeza
(closes issue #14216)
Reported by: Andrey Sofronov
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@195991 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is accomplished by adding two functions to update the answer time and disposition of calls that checks for the proper lock flags. These functions are used in the ast_bridge_call() function so that ForkCDR(A) calls are respected.
This patch also modifies the way ast_bridge_call() chooses the cdr record to base the bridged_cdr on. Previously the first unlocked cdr record would be chosen, now instead the first cdr record is chosen and forked cdr records are moved to the bridge_cdr. This allows the original cdr record and any forked cdr records to be properly updated with answer and end times.
(closes issue #13797)
Reported by: sh0t
Tested by: sh0t
(closes issue #14744)
Reported by: deepesh
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@195881 65c4cc65-6c06-0410-ace0-fbb531ad65f3
IAX was not sending REGREJ to terminate invalid registrations. Instead it sent another REGAUTH if the authentication challenge failed. This caused a loop of REGREQ and REGAUTH frames.
(Related to Security fix AST-2009-001)
(closes issue #14867)
Reported by: aragon
Tested by: dvossel
(closes issue #14717)
Reported by: mobeck
Patches:
regauth_loop_update_patch.diff uploaded by dvossel (license 671)
Tested by: dvossel
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@194873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There is a bug tracker issue where people are reporting "Ghost" channels in their 'iax2 show channels' output. The confusion is caused by channels being listed as "(NONE)" with format "unknown". These are not channels of coarse. They are usually just pending registration or poke requests, but it is confusing output. To help make sense of this I have added two columns to 'iax2 show channels'. One shows the first message which started the transaction, and the second shows the last message sent by either side of the call. This helps diagnose why the entry exists and why it may not go away.
(closes issue #14207)
Reported by: clive18
Review: https://reviewboard.asterisk.org/r/246/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@194557 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The loop detection/spiral detection code in chan_sip used the owner
channel's state as a criterion for determining if the incoming INVITE
is a looped request. The problem with this is that the INVITE-handling
code happens in a different thread than the thread that marks the owner
channel as being up. As a result, if a reinvite were to come in very quickly,
say from another Asterisk on the same LAN, it was possible for the reinvite
to arrive before the owner channel had been set to the up state.
This patch corrects the problem by using the invitestate of the sip_pvt
instead, since that can be guaranteed to be set correctly by the time
the reinvite arrives. Since there is a switch statement further in the
INVITE-handling code, the AST_STATE_RINGING state also checks the invitestate
of the sip_pvt in case we should actually be treating the channel as if it were
up already.
(closes issue #12215)
Reported by: jpyle
Patches:
12215_confirmed.patch uploaded by mmichelson (license 60)
Tested by: lmadsen
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@194484 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In the case that we could not remove the desired channel from the
list of channels, there was an extra call to unlock the channel list.
Since we unlock the list later on in the function anyway, this results
in the list being unlocked twice yet only being locked once.
(closes issue #15098)
Reported by: tim_ringenbach
Patches:
remove_extra_unlock.diff uploaded by tim (license 540)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@194356 65c4cc65-6c06-0410-ace0-fbb531ad65f3
situations.
This involves setting a proper cdr disposition coresponding to the given
failure condition and ensuring the proper information is stored in the cdr
record.
(closes issue #13691)
Reported by: dferrer
Tested by: mnicholson
(closes issue #13637)
Reported by: atis
Tested by: atis
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@194028 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The problem was that the hangup code was setting the invitestate too early. The result of
this was that we would always send a CANCEL request, even if it was not an appropriate
time to do so (e.g. we have not yet received a provisional response for our INVITE).
Note that this same fix had been applied to trunk and the 1.6.X branches starting with
revision 155467. This is why you will see this revision being blocked from those places.
AST-216
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@193880 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This allows more concurrent extensions to be copied for a single voicemail,
without creating a possibility of upsetting existing users, where a dialplan
could run out of stack space where it had run fine before. Alternatively,
we could have allocated off the heap, but that is a larger change and would
have increased the chance for instability introduced by this change.
This is really solved starting in 1.6.0.11, as the use of an ast_str buffer
allows an unlimited number of extensions (up to available memory). We
additionally create a new warning message when the buffer length is exceeded,
permitting administrators to see an issue after the fact, whereas previously
the list was silently truncated.
(closes issue #14739)
Reported by: p_lindheimer
Patches:
20090417__bug14739.diff.txt uploaded by tilghman (license 14)
Tested by: p_lindheimer
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@193755 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In the state MISDN_CALLING (i.e. SETUP was sent but no answer has arrived yet),
it is not allowed to clear the call with RELEASE_COMPLETE. It must be
cleared with DISCONNECT. A RELEASE_COMPLETE is only allowed as an answer
to a SETUP. (See Q.931 ch. 5.3.2, 5.3.2.a, 5.3.2.b)
Patches:
chan-misdn-ccstate7.patch uploaded by customer.
JIRA ABE-1862
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@193613 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(Note: This is not a new feature, it was previously undocumented and broken.)
The Asterisk logger has a feature to support absolute pathnames for logger channels, but the code implementing the feature was broken. This has been fixed, and the absolute path feature is now documented in the sample logger.conf.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@193193 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the single digit DTMF is an extension in the specified context, then
go there and signal no DTMF. Otherwise, we should exit with that DTMF.
If we're in Macro, we'll exit and seek that DTMF as the beginning of an
extension in the Macro's calling context. If we're not in Macro, then
we'll simply seek that extension in the calling context. Previously,
someone complained about the behavior as it related to the interior of a
Gosub routine, and the fix (#14011) inadvertently broke FreePBX
(#14940). This change should fix both of these situations, but with the
possible incompatibility that if a single digit extension does not exist
(but a longer extension COULD have matched), it would have previously
gone immediately to the "i" extension, but will now need to wait for a
timeout.
(closes issue #14940)
Reported by: p_lindheimer
Patches:
20090420__bug14940.diff.txt uploaded by tilghman (license 14)
Tested by: p_lindheimer
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@193119 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added the dialed extension and context to the chan_misdn messages warning
that the dialed number cannot be matched in the dialplan.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@193050 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the fullcontact field appears in both the sippeers and the
sipregs table, then during reconstruction of the field, it will
otherwise be doubled.
(closes issue #14754)
Reported by: Alexei Gradinari
Patches:
20090506__bug14754.diff.txt uploaded by tilghman (license 14)
Tested by: lmadsen
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@192932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Just changed park_exec to always return non-zero. I really wasn't entirely sure
at first if this was a bug. Decided it was since it would be surprising when
not using ParkedCall in the dialplan to hang up and have dialplan execution
continue.
(closes issue #14555)
Reported by: francesco_r
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@192858 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Internet Explorer (tested with 7.0) does not like trailing commas on constructs
like object initializers, so get rid of them to avoid some errors.
(closes issue #15026)
Reported by: rajnishgiri
Patches:
bug15026.patch uploaded by seanbright (license 71)
Tested by: seanbright
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@192524 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The CDR code involved with bridges wrongly assumed that the currently executing application and data
values will always exist. It is possible for this to be false when call forwarding is involved.
(closes issue #14984)
Reported by: gincantalupo
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@192454 65c4cc65-6c06-0410-ace0-fbb531ad65f3
mohinterpret and mohsuggest global variables were not copied over during build_users and build_peers.
(closes issue #14728)
Reported by: dimas
Patches:
v1-14728.patch uploaded by dimas (license 88)
Tested by: dimas, dvossel
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@192213 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes a case where a certain message could get played twice.
(closes issue #13155)
Reported by: greenfieldtech
Patches:
app_voicemail.c.multi-lang-patch uploaded by greenfieldtech (license 369)
Tested by: greenfieldtech
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@191778 65c4cc65-6c06-0410-ace0-fbb531ad65f3
