When you are using chan_dahdi ISDN signaling with immediate=yes and a call
comes in without a DNID then you get the DNID of a previous call.
Chan_dahdi does not touch the DNID field on a new call if it does not have
a DNID.
Made always copy the DNID from the new call.
The patches backport the relevant changes from trunk -r210387.
(closes issue #17568)
Reported by: wuwu
Patches:
issue17568_v1.4.patch uploaded by rmudgett (license 664)
issue17568_v1.6.2.patch uploaded by rmudgett (license 664)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@278703 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes some cases of no outgoing calls on FXO before an incoming call.
Remove an unnecessary testing of an "off-hook" bit from DAHDI for FXO
(KS/GS) channels.In some cases the bit would not be initialized properly
before the first inbound call and thus prevent an outgoing call.
If those tests are actually required by anybody, they should define
DAHDI_CHECK_HOOKSTATE in channels/sig_analog.c .
(closes issue #14577)
Reported by: jkroon
Patches:
asterisk_chan_dahdi_hookstate_fix.diff uploaded by frawd (license 610)
Tested by: frawd
Review: https://reviewboard.asterisk.org/r/699/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@278524 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r277530 | mnicholson | 2010-07-16 16:24:45 -0500 (Fri, 16 Jul 2010) | 11 lines
Merged revisions 277497 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r277497 | mnicholson | 2010-07-16 16:18:38 -0500 (Fri, 16 Jul 2010) | 4 lines
Default to no udptl error correction so that error correction will be disabled in the event that the remote end indicates that they do not support the error correction mode we requested.
FAX-128
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@277563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r277467 | rmudgett | 2010-07-16 15:27:51 -0500 (Fri, 16 Jul 2010) | 22 lines
Merged revisions 277419 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r277419 | rmudgett | 2010-07-16 15:18:54 -0500 (Fri, 16 Jul 2010) | 15 lines
priexclusive in chan_dahdi.conf ignored when reloading dahdi module
During a reload, the priexclusive and outsignalling parameters are not
read in from the config file as intended. Unfortunately, they get set to
defaults as a result. This patch makes sure that they do not get set to
defaults during a reload.
(closes issue #17441)
Reported by: mtryfoss
Patches:
issue17441_v1.4.patch uploaded by rmudgett (license 664)
issue17441_v1.6.2.patch uploaded by rmudgett (license 664)
issue17441_trunk.patch uploaded by rmudgett (license 664)
Tested by: rmudgett
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@277485 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r276788 | jpeeler | 2010-07-15 15:21:03 -0500 (Thu, 15 Jul 2010) | 6 lines
Correct not setting the bindport before attempting to open the socket.
Related to changes from 276571, I was accidentally testing with a port set in
my configuration causing me to miss this. Also moved the TCP handling as well
to occur before build_peer is called.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@276809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r276571 | jpeeler | 2010-07-14 17:58:24 -0500 (Wed, 14 Jul 2010) | 21 lines
Fix MWI notification transmission problems over SIP.
MWI updates were not being sent if no messages were found in the event cache.
This was corrected since a phone may need to clear its MWI status configured
previously from another mailbox.
Upon module or sip reload, MWI updates could not be sent due to the sipsock
socket not being set early enough in reload_config. The code handling the
descriptor assignment and such has simply been moved before the call to
build_peer.
Issuing a sip reload cleared the IP address of the peer, but skipped checking
the database for registration information. The database is now checked both
for sip reload and actually reloading the module.
If a transmission occurs before the do_monitor thread has started, do not
attempt to send a signal to it.
(closes issue #17398)
Reported by: ip-rob
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@276572 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r245192 | mmichelson | 2010-02-06 08:43:03 -0600 (Sat, 06 Feb 2010) | 21 lines
Remove useless sip options related to hash table size.
First off, these options weren't actually doing anything.
By the time the options were parsed, the peer and dialog
containers had already been allocated with their default
values.
Second, hash table size is something that doesn't really
make sense to change in a config file. If a user is that
interested in changing the hashtable size, he can modify
the source itself.
I have removed the parsing of the hash_peer, hash_user,
and hash_dialog options. I have removed the hash_user_size
variable altogether since it is not used at all. I also
changed hash_peer_size and hash_dialog_size to be constant,
and have changed the symbols to be in all caps as constants
typically are. I have also removed the entire section in
sip.conf.sample regarding configurable hashtable sizes.
........
(merge to 1.6.2 inspired by issue #17553)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@275469 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r274284 | twilson | 2010-07-06 17:15:27 -0500 (Tue, 06 Jul 2010) | 18 lines
Merged revisions 274280 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r274280 | twilson | 2010-07-06 17:08:20 -0500 (Tue, 06 Jul 2010) | 9 lines
Add option to not do a call forward on 482 Loop Detected
Asterisk has always set up a forwarded call when receiving a 482 Loop Detected.
This prevents handling the call failure by just continuing on in the dialplan.
Since this would be a change in behavior, the new option to disable this
behavior is forwardloopdetected which defaults to 'yes'.
Review: https://reviewboard.asterisk.org/r/764/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@274360 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r273078 | tilghman | 2010-06-29 18:20:40 -0500 (Tue, 29 Jun 2010) | 17 lines
Merged revisions 273060 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r273060 | tilghman | 2010-06-29 18:15:28 -0500 (Tue, 29 Jun 2010) | 10 lines
Allow the "useragent" value to be restored into memory from the realtime backend.
This value is purely informational. It does not alter configuration at all.
(closes issue #16029)
Reported by: Guggemand
Patches:
realtime-useragent.patch uploaded by Guggemand (license 897)
Tested by: Guggemand
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@273087 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r272370 | russell | 2010-06-23 18:09:28 -0500 (Wed, 23 Jun 2010) | 23 lines
Resolve some errors produced during module unload of chan_iax2.
The external test suite stops Asterisk using the "core stop gracefully" command.
The logs from the tests show that there are a number of problems with Asterisk
trying to cleanly shut down. This patch addresses the following type of error
that comes from chan_iax2:
[Jun 22 16:58:11] ERROR[29884]: lock.c:129 __ast_pthread_mutex_destroy:
chan_iax2.c line 11371 (iax2_process_thread_cleanup):
Error destroying mutex &thread->lock: Device or resource busy
For an example in the context of a build, see:
http://bamboo.asterisk.org/browse/AST-TRUNK-739/log
The primary purpose of this patch is to change the thread pool shutdown
procedure to be more explicit to ensure that the thread exits from a point
where it is not holding a lock. While testing that, I encountered various
crashes due to the order of operations in unload_module() being problematic.
I reordered some things there, as well.
Review: https://reviewboard.asterisk.org/r/736/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@272371 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r271690 | mnicholson | 2010-06-22 07:58:28 -0500 (Tue, 22 Jun 2010) | 18 lines
Merged revisions 271689 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r271689 | mnicholson | 2010-06-22 07:52:27 -0500 (Tue, 22 Jun 2010) | 8 lines
Modify chan_sip's packet generation api to automatically calculate the Content-Length. This is done by storing packet content in a buffer until it is actually time to send the packet, at which time the size of the packet is calculated. This change was made to ensure that the Content-Length is always correct.
(closes issue #17326)
Reported by: kenner
Tested by: mnicholson, kenner
Review: https://reviewboard.asterisk.org/r/693/
........
This change also adds an ast_str_copy_string() function (similar to ast_copy_string), that copies one ast_str into another, properly handling embedded nulls.
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@271691 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r269307 | rmudgett | 2010-06-09 11:54:38 -0500 (Wed, 09 Jun 2010) | 12 lines
Eliminate deadlock potential in dahdi_fixup().
Calling dahdi_indicate() within dahdi_fixup() while the owner pointers are
in a potentially inconsistent state is a potentially bad thing in
principle.
However, calling dahdi_indicate() when the channel private lock is already
held can cause a deadlock if the PRI lock is needed because
dahdi_indicate() will also get the channel private lock. The pri_grab()
function assumes that the channel private lock is held once to avoid
deadlock.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@271338 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r270867 | dvossel | 2010-06-16 12:36:51 -0500 (Wed, 16 Jun 2010) | 28 lines
Merged revisions 270866 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r270866 | dvossel | 2010-06-16 12:35:29 -0500 (Wed, 16 Jun 2010) | 22 lines
fixes chan_iax2 race condition
There is code in chan_iax2.c that attempts to guarantee that only a single
active thread will handle a call number at a time. This code works once
the thread is added to an active_list of threads, but we are not currently
guaranteed that a newly activated thread will enter the active_list immediately
because it is left up to the thread to add itself after frames have been
queued to it. This means that if two frames come in for the same call number
at the same time, it is possible for them to grab two separate threads because
the first thread did not add itself to the active_list fast enough. This
causes some pretty complex problems.
This patch resolves this race condition by immediately adding an activated
thread to the active_list within the network thread and only depending on
the thread to remove itself once it is done processing the frames queued to
it. By doing this we are guaranteed that if another frame for the same call
number comes in at the same time, that this thread will immediately be found
in the active_list of threads.
Review: https://reviewboard.asterisk.org/r/720/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@270868 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r270658 | twilson | 2010-06-15 15:18:04 -0500 (Tue, 15 Jun 2010) | 20 lines
Make contactdeny apply to src ip when nat=yes
chan_sip's "contactdeny" feature screens the "to be registered contact".
In case of nat=yes it should not use the address information from the
Contact header (which is not used at all for routing), but the source
IP address of the request.
Thus, if nat=yes and a client sends a request from a denied IP address
(e.g. by spoofing the src-IP address) it can bypass the screening.
This commit makes contactdeny apply to the src ip when nat=yes instead.
(closes issue #17276)
Reported by: klaus3000
Patches:
patch-asterisk-trunk-contactdeny.txt uploaded by klaus3000 (license 65)
Tested by: klaus3000
Review: [full review board URL with trailing slash]
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@270693 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r267352 | russell | 2010-06-02 17:46:37 -0500 (Wed, 02 Jun 2010) | 7 lines
try to fix some random chan_h323 compilation failures
After some debugging, the random chan_h323 build failures appear to be due
to complications introduced by some chan_h323 specific build stuff getting
triggered during a clean. Simplify this by moving the h323 clean commands
down into channels/makefile.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@267353 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r265698 | mmichelson | 2010-05-25 15:59:04 -0500 (Tue, 25 May 2010) | 12 lines
Properly use peer's outboundproxy for outbound REGISTERs.
The logic used in transmit_register to get the outboundproxy for a peer
was flawed since this value would be overridden shortly afterwards when
create_addr was called.
In addition, this also fixes some logic used when parsing users.conf so
that the peer name is placed in the internally-generated register string
so that an outboundproxy set in the Asterisk GUI will be used for outbound
REGISTERs.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@265699 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r264452 | mmichelson | 2010-05-19 16:29:08 -0500 (Wed, 19 May 2010) | 86 lines
Fix transcode_via_sln option with SIP calls and improve PLC usage.
From reviewboard:
The problem here is a bit complex, so try to bear with me...
It was noticed by a Digium customer that generic PLC (as configured in
codecs.conf) did not appear to actually be having any sort of benefit when
packet loss was introduced on an RTP stream. I reproduced this issue myself
by streaming a file across an RTP stream and dropping approx. 5% of the
RTP packets. I saw no real difference between when PLC was enabled or disabled
when using wireshark to analyze the RTP streams.
After analyzing what was going on, it became clear that one of the problems
faced was that when running my tests, the translation paths were being set
up in such a way that PLC could not possibly work as expected. To illustrate,
if packets are lost on channel A's read stream, then we expect that PLC will
be applied to channel B's write stream. The problem is that generic PLC can
only be done when there is a translation path that moves from some codec to
SLINEAR. When I would run my tests, I found that every single time, read
and write translation paths would be set up on channel A instead of channel
B. There appeared to be no real way to predict which channel the translation
paths would be set up on.
This is where Kevin swooped in to let me know about the transcode_via_sln
option in asterisk.conf. It is supposed to work by placing a read translation
path on both channels from the channel's rawreadformat to SLINEAR. It also
will place a write translation path on both channels from SLINEAR to the
channel's rawwriteformat. Using this option allows one to predictably set up
translation paths on all channels. There are two problems with this, though.
First and foremost, the transcode_via_sln option did not appear to be working
properly when I was placing a SIP call between two endpoints which did not
share any common formats. Second, even if this option were to work, for PLC
to be applied, there had to be a write translation path that would go from
some format to SLINEAR. It would not work properly if the starting format
of translation was SLINEAR.
The one-line change presented in this review request in chan_sip.c fixed the
first issue for me. The problem was that in sip_request_call, the
jointcapability of the outbound channel was being set to the format passed to
sip_request_call. This is nativeformats of the inbound channel. Because of this,
when ast_channel_make_compatible was called by app_dial, both channels already
had compatibly read and write formats. Thus, no translation path was set up at
the time. My change is to set the jointcapability of the sip_pvt created during
sip_request_call to the intersection of the inbound channel's nativeformats and
the configured peer capability that we determined during the earlier call to
create_addr. Doing this got the translation paths set up as expected when using
transcode_via_sln.
The changes presented in channel.c fixed the second issue for me. First and
foremost, when Asterisk is started, we'll read codecs.conf to see the value of
the genericplc option. If this option is set, and ast_write is called for a
frame with no data, then we will attempt to fill in the missing samples for
the frame. The implementation uses a channel datastore for maintaining the
PLC state and for creating a buffer to store PLC samples in. Even when we
receive a frame with data, we'll call plc_rx so that the PLC state will have
knowledge of the previous voice frame, which it can use as a basis for when
it comes time to actually do a PLC fill-in.
So, reviewers, now I ask for your help. First off, there's the one line change
in chan_sip that I have put in. Is it right? By my logic it seems correct, but
I'm sure someone can tell me why it is not going to work. This is probably the
change I'm least concerned about, though. What concerns me much more is the
set of changes in channel.c. First off, am I even doing it right? When I run
tests, I can clearly see that when PLC is activated, I see a significant increase
in RTP traffic where I would expect it to be. However, in my humble opinion, the
audio sounds kind of crappy whenever the PLC fill-in is done. It sounds worse to
me than when no PLC is used at all. I need someone to review the logic I have used
to be sure that I'm not misusing anything. As far as I can see my pointer arithmetic
is correct, and my use of AST_FRIENDLY_OFFSET should be correct as well, but I'm
sure someone can point out somewhere where I've done something incorrectly.
As I was writing this review request up, I decided to give the code a test run under
valgrind, and I find that for some reason, calls to plc_rx are causing some invalid
reads. Apparently I'm reading past the end of a buffer somehow. I'll have to dig around
a bit to see why that is the case. If it's obvious to someone reviewing, speak up!
Finally, I have one other proposal that is not reflected in my code review. Since
without transcode_via_sln set, one cannot predict or control where a translation
path will be up, it seems to me that the current practice of using PLC only when
transcoding to SLINEAR is not useful. I recommend that once it has been determined
that the method used in this code review is correct and works as expected, then
the code in translate.c that invokes PLC should be removed.
Review: https://reviewboard.asterisk.org/r/622/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@264453 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r264331 | dvossel | 2010-05-19 14:21:04 -0500 (Wed, 19 May 2010) | 13 lines
fixes crash in check_rtp_timeout
During deadlock avoidance the sip dialog pvt is locked and
unlocked. When this occurs we have no guarantee the pvt's owner
is still valid. We were trying to access the pvt's owner after
this without checking to see if it still existed first.
(closes issue #17271)
Reported by: under
Patches:
check_rtp_timeout.diff uploaded by under (license 914)
Tested by: dvossel
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@264332 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r262236 | dvossel | 2010-05-10 13:36:10 -0500 (Mon, 10 May 2010) | 11 lines
fixes crash in chan_console
There is a race condition between console_hangup()
and start_stream(). It is possible for console_hangup()
to be called and then the stream thread to begin after the hangup.
To avoid this a check in start_stream() to make sure the pvt-owner
still exists while the pvt lock is held is made. If the owner
is gone that means the channel hung up and start_stream should
be aborted.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@262237 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r261560 | tilghman | 2010-05-06 10:39:10 -0500 (Thu, 06 May 2010) | 8 lines
Permit more lines within a SIP body to be parsed.
The example given within the related issue showed 120 lines, which was mostly
a result of the body being XML.
(closes issue #17179)
Reported by: khw
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@261563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r254450 | kpfleming | 2010-03-25 10:27:31 -0500 (Thu, 25 Mar 2010) | 49 lines
Improve handling of T.38 re-INVITEs that arrive before a T.38-capable
application is executing on a channel.
This patch addresses an issue found during working with end-users
using res_fax. If an incoming call is answered in the dialplan, or
jumps to the 'fax' extension due to reception of a CNG tone (with
faxdetect enabled), and then the remote endpoint sends a T.38
re-INVITE, it is possible for the channel's T.38 state to be
'T38_STATE_NEGOTIATING' when the application starts up. Unfortunately,
even if the application wants to use T.38, it can't respond to the
peer's negotiation request, because the AST_CONTROL_T38_PARAMETERS
control frame that chan_sip sent originally has been lost, and the
application needs the content of that frame to be able to formulate a
reply.
This patch adds a new 'request' type to AST_CONTROL_T38_PARAMETERS,
AST_T38_REQUEST_PARMS. If the application sends this request, chan_sip
will re-send the original control frame (with
AST_T38_REQUEST_NEGOTIATE as the request type), and the application
can respond as normal. If this occurs within the five second timeout
in chan_sip, the automatic cancellation of the peer reinvite will be
stopped, and the application will 'own' the negotiation process from
that point onwards.
This also improves the code path in chan_sip to allow sip_indicate(),
when called for AST_CONTROL_T38_PARAMETERS, to be able to return a
non-zero response, which should have been in place before since the
control frame *can* fail to be processed properly. It also modifies
ast_indicate() to return whatever result the channel driver returned
for this control frame, rather than converting all non-zero results
into '-1'. Finally, the new request type intentionally returns a
positive value, so that an application that sends
AST_T38_REQUEST_PARMS can know for certain whether the channel driver
accepted it and will be replying with a control frame of its own, or
whether it was ignored (if the sip_indicate()/ast_indicate() path had
properly supported failure responses before, this would not be
necessary).
This patch also modifies res_fax to take advantage of the new request.
In addition, this patch makes sip_t38_abort() actually lock the
private structure before doing its work... bad programmer, no donut.
This patch also enhances chan_sip's 'faxdetect' support to allow
triggering on T.38 re-INVITEs received as well as CNG tone detection.
Review: https://reviewboard.asterisk.org/r/556/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@260884 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r260437 | jpeeler | 2010-04-30 17:36:49 -0500 (Fri, 30 Apr 2010) | 18 lines
Merged revisions 260434 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r260434 | jpeeler | 2010-04-30 17:22:46 -0500 (Fri, 30 Apr 2010) | 11 lines
Ensure channel state is not incorrectly set in the case of a very early answer.
The needringing bit was being read in dahdi_read after answering thereby
setting the state to ringing from up. This clears needringing upon answering
so that is no longer possible.
(closes issue #17067)
Reported by: tzafrir
Patches:
needringing.diff uploaded by tzafrir (license 46)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@260441 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r260231 | rmudgett | 2010-04-29 17:44:14 -0500 (Thu, 29 Apr 2010) | 33 lines
Merged revisions 260195 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r260195 | rmudgett | 2010-04-29 17:11:47 -0500 (Thu, 29 Apr 2010) | 26 lines
DTMF CallerID detection problems.
The code handling DTMF CallerID drops digits on long CallerID numbers and
may timeout waiting for the first ring with shorter numbers.
The DTMF emulation mode was not turned off when processing DTMF CallerID.
When the emulation code gets behind in processing the DTMF digits it can
skip a digit.
For shorter numbers, the timeout may have been too short. I increased it
from 2 seconds to 4 seconds. Four seconds is a typical time between rings
for many countries.
(closes issue #16460)
Reported by: sum
Patches:
issue16460.patch uploaded by rmudgett (license 664)
issue16460_v1.6.2.patch uploaded by rmudgett (license 664)
Tested by: sum, rmudgett
Review: https://reviewboard.asterisk.org/r/634/
JIRA SWP-562
JIRA AST-334
JIRA SWP-901
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@260234 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r259870 | dvossel | 2010-04-28 16:20:03 -0500 (Wed, 28 Apr 2010) | 39 lines
Merged revisions 259858 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r259858 | dvossel | 2010-04-28 16:16:03 -0500 (Wed, 28 Apr 2010) | 33 lines
resolves deadlocks in chan_local
Issue_1.
In the local_hangup() 3 locks must be held at the same time... pvt, pvt->chan,
and pvt->owner. Proper deadlock avoidance is done when the channel to hangup
is the outbound chan_local channel, but when it is not the outbound channel we
have an issue... We attempt to do deadlock avoidance only on the tech pvt, when
both the tech pvt and the pvt->owner are locked coming into that loop. By
never giving up the pvt->owner channel deadlock avoidance is not entirely possible.
This patch resolves that by doing deadlock avoidance on both the pvt->owner and the pvt
when trying to get the pvt->chan lock.
Issue_2.
ast_prod() is used in ast_activate_generator() to queue a frame on the channel
and make the channel's read function get called. This function is used in
ast_activate_generator() while the channel is locked, which mean's the channel
will have a lock both from the generator code and the frame_queue code by the
time it gets to chan_local.c's local_queue_frame code... local_queue_frame
contains some of the same crazy deadlock avoidance that local_hangup requires,
and this recursive lock prevents that deadlock avoidance from happening correctly.
This patch removes ast_prod() from the channel lock so only one lock is held during
the local_queue_frame function.
(closes issue #17185)
Reported by: schmoozecom
Patches:
issue_17185_v1.diff uploaded by dvossel (license 671)
issue_17185_v2.diff uploaded by dvossel (license 671)
Tested by: schmoozecom, GameGamer43
Review: https://reviewboard.asterisk.org/r/631/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@259899 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r259307 | rmudgett | 2010-04-27 13:29:33 -0500 (Tue, 27 Apr 2010) | 21 lines
Merged revisions 259270 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r259270 | rmudgett | 2010-04-27 13:14:54 -0500 (Tue, 27 Apr 2010) | 14 lines
hidecalleridname parameter in chan_dahdi.conf
Issue #7321 implements a new chan_dahdi configuration option. However, a
change mentioned in the issue was never implemented. This is the change
that will allow the feature to work.
I added a note to chan_dahdi.conf.sample about the feature.
(closes issue #17143)
Reported by: djensen99
Patches:
diff.txt uploaded by djensen99 (license NA) (One line change)
Tested by: djensen99
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@259310 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r258305 | dvossel | 2010-04-21 13:13:36 -0500 (Wed, 21 Apr 2010) | 12 lines
fixes issue with double "sip:" in header field
This is a clear mistake in logic. Future discussions
about how to avoid having to handle uri's like this
should take place in the future, but this fix needs
to go in for now.
(closes issue #15847)
Reported by: ebroad
Patches:
doublesip.patch uploaded by ebroad (license 878)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@258314 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r257493 | tilghman | 2010-04-15 15:30:15 -0500 (Thu, 15 Apr 2010) | 20 lines
Merged revisions 257467 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r257467 | tilghman | 2010-04-15 15:24:50 -0500 (Thu, 15 Apr 2010) | 13 lines
Don't recreate peer, when responding to a repeated deregistration attempt.
When a reply to a deregistration is lost in transmit, the client retries the
deregistration. Previously, this would cause a realtime/autocreate peer to be
loaded back into memory, after it had already been correctly purged. Instead,
we just want to resend the reply without loading the peer.
(closes issue #16908)
Reported by: kkm
Patches:
20100412__issue16908.diff.txt uploaded by tilghman (license 14)
Tested by: kkm
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@257510 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The bug is exposed if MFC/R2 support is built into asterisk (i.e.,
openr2.h is present in the include path). Code that unconditionally
clears the CallerID name and number is included.
Also fixed a malformed if test in mkintf() added by issue 15883.
Converted the if statement to a switch statement for clarity.
Regression of the issue 15883 fix.
(closes issue #16968)
Reported by: grecco
Patches:
issue16968.patch uploaded by rmudgett (license 664)
(closes issue #16747)
Reported by: viniciusfontes
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@256368 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r252089 | twilson | 2010-03-12 16:04:51 -0600 (Fri, 12 Mar 2010) | 20 lines
Only change the RTP ssrc when we see that it has changed
This change basically reverts the change reviewed in
https://reviewboard.asterisk.org/r/374/ and instead limits the
updating of the RTP synchronization source to only those times when we
detect that the other side of the conversation has changed the ssrc.
The problem is that SRCUPDATE control frames are sent many times where
we don't want a new ssrc, including whenever Asterisk has to send DTMF
in a normal bridge. This is also not the first time that this mistake
has been made. The initial implementation of the ast_rtp_new_source
function also changed the ssrc--and then it was removed because of
this same issue. Then, we put it back in again to fix a different
issue. This patch attempts to only change the ssrc when we see that
the other side of the conversation has changed the ssrc.
It also renames some functions to make their purpose more clear.
Review: https://reviewboard.asterisk.org/r/540/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@252137 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r250481 | jpeeler | 2010-03-03 13:06:06 -0600 (Wed, 03 Mar 2010) | 22 lines
Merged revisions 250480 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r250480 | jpeeler | 2010-03-03 13:04:11 -0600 (Wed, 03 Mar 2010) | 15 lines
Make sure to clear red alarm after polarity reversal.
From the issue:
The automatic overnight line tests (or manual ones) used on UK (BT) lines causes
a red alarm on a dahdi / TDM400P connected channel. This is because the line
uses voltage tests (battery loss) and polarity reversal. The polarity reversal
causes chan_dahdi to initiate v23 CallerID processing but during this the event
DAHDI_EVENT_NOALARM is ignored so that the alarm is never cleared.
(closes issue #14163)
Reported by: jedi98
Patches:
chan_dahdi-1.4-inalarm.diff uploaded by jedi98 (license 653)
Tested by: mattbrown, Chainsaw, mikeeccleston
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@250484 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r250395 | dvossel | 2010-03-03 12:03:19 -0600 (Wed, 03 Mar 2010) | 22 lines
Merged revisions 250394 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r250394 | dvossel | 2010-03-03 12:02:27 -0600 (Wed, 03 Mar 2010) | 16 lines
fixes problem with duplicate TXREQ packets
When Asterisk receives an IAX2 TXREQ packet, try_transfer()
will call store_by_transfercallno() to link the chan_iax2_pvt
struct into iax_transfercallno_pvts. If a duplicate TXREQ
packet is received for the same call, the pvt struct will be
linked into iax_transfercallno_pvts multiple times. This patch
fixes this. Thanks rain for debugging this and providing a patch!
(closes issue #16904)
Reported by: rain
Patches:
iax2-double-txreq-fix.diff uploaded by rain (license 327)
Tested by: rain, dvossel
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@250396 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r249893 | dvossel | 2010-03-02 13:08:38 -0600 (Tue, 02 Mar 2010) | 11 lines
fixes adaptive jitterbuffer configuration
When configuring the adaptive jitterbuffer, the target_extra
value not only could not be set from the configuration, but was
not even being set to its proper default. This value is required
in order for the adaptive jitterbuffer to work correctly. To resolve
this a config option has been added to expose this value to the conf
files, and a default value is provided when no config specific value
is present.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@249895 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r249538 | jpeeler | 2010-03-01 11:11:31 -0600 (Mon, 01 Mar 2010) | 18 lines
Merged revisions 249536 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r249536 | jpeeler | 2010-03-01 11:02:03 -0600 (Mon, 01 Mar 2010) | 11 lines
Modify queued frames from local channels to not set the other side to up
In this case, attended transfers were broken due to ast_feature_request_and_dial
detecting the channel being set to up before the answer frame could be read and
therefore failing to mark the channel as ready. This fix is a regression fix for
244785, which should continue to work properly as well.
(closes issue #16816)
Reported by: jamhed
Tested by: jamhed, corruptor
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@249580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Following Q.931 5.2.4
When the user has determined that sufficient call information has been received the
user shall stop T302 and send CALL PROCEEDING to the network.
Previously timeouts were possible if the dialplan took a long time to issue any
response back to the network.
Verified that our local TELCO also does the same.
(issue #16789)
Reported by: alecdavis
Patches:
overlap_receiving_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@249321 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r228798 | tilghman | 2009-11-09 01:37:52 -0600 (Mon, 09 Nov 2009) | 14 lines
Fix various problems detected with Valgrind.
* chan_console accessed pvts after deallocation.
* The module loader did not check usecount on shutdown, which led to chan_iax2
reading a timer that was already unloaded.
(closes issue #16062)
Reported by: alexanderheinz
Patches:
20091109__issue16062.diff.txt uploaded by tilghman (license 14)
Tested by: tilghman
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@248011 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r247914 | rmudgett | 2010-02-19 11:33:33 -0600 (Fri, 19 Feb 2010) | 62 lines
Merged revisions 247910 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r247910 | rmudgett | 2010-02-19 11:18:49 -0600 (Fri, 19 Feb 2010) | 55 lines
Merged revision 247904 from
https://origsvn.digium.com/svn/asterisk/be/branches/C.2-...
..........
r247904 | rmudgett | 2010-02-19 10:49:44 -0600 (Fri, 19 Feb 2010) | 49 lines
Make chan_misdn DTMF processing consistent with other channel technologies.
The processing of DTMF tones on the receiving side of an ISDN channel is
inconsistent with the way it is handled in other channels, especially
DAHDI analog. This causes DTMF tones sent from an ISDN phone to be
doubled at the connected party.
We are using the following 2 options of misdn.conf
1) astdtmf=yes
2) senddtmf=yes
Option one is necessary because the asterisk DSP DTMF detection is better
than mISDN's internal DSP. Not as many false positives.
Option two is necessary to transmit DTMF tones end to end when mISDN
channels are connected to SIP channels with out of band DTMF for example.
The symptom is that DTMF tones sent by an ISDN phone are doubled on the
way through asterisk when two mISDN channels are connected with a Local
channel in between or if it is bridged to an analog channel.
The doubling of DTMF tones is because DTMF is passed inband to asterisk by
the mISDN channel and passed out of band once again after the release of
the DTMF tone. Passing it inband is wrong. Neither an analog channel nor
SIP channel passes DTMF inband if configured to inband DTMF. Analog and
SIP channels filter out the DTMF tones because they use the voice frames
returned by ast_dsp_process. But chan_misdn passes the unfiltered input
voice frames instead.
To overcome one aspect of the problem, the doubling of DTMF tones when two
mISDN channels are directly bridged, someone made an 'optimization', where
in that case the DTMF tone passed out-of-band to the peer channel is not
translated to an inband tone at the transmit side. This optimization is
bad because it does not work in general. For example, analog channels or
mISDN channels when bridged through an intermediary local channel will
generate DTMF tones from out-of-band information. Also, of course, it
must not be done when there is no inband DTMF available.
This patch fixes the issue. Now chan_misdn will filter the received
inband DTMF signal the same as other channel types.
Another change included: No need to build an extra translation path
because ast_process_dsp does it if required.
Patches:
misdn-dtmf.patch
JIRA ABE-2080
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@248004 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r247915 | dvossel | 2010-02-19 11:40:26 -0600 (Fri, 19 Feb 2010) | 7 lines
handle_request_invite revise comment, fix coding guideline issues
I'm working with this code right now trying to analyze a deadlock.
This change is just to clean up a few things before I make a more
complex patch.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@247916 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r247787 | tilghman | 2010-02-18 15:42:53 -0600 (Thu, 18 Feb 2010) | 17 lines
If the peer record is from realtime, it could be set to 0, due to MySQL not representing NULL well in integer columns.
NULL means the value is not specified for the column, which normally means
the driver uses whatever is the default value. However, on MySQL, placing
a NULL in either a float or integer column results in a retrieval of the 0
value. Hence, users get an errant error on load. This patch suppresses
that error and makes the value as if it was not there.
Note that this cannot be done in the realtime driver, because the lack of
difference between NULL and 0 can only be intepreted correctly by the
driver itself. If we did it in the realtime driver, then it would be
effectively impossible to set any realtime field to 0, because it would act
as if the field were unspecified and possibly take on a different value.
(closes issue #16683)
Reported by: wdoekes
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@247792 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r246070 | jpeeler | 2010-02-10 10:47:37 -0600 (Wed, 10 Feb 2010) | 22 lines
Change channel state on local channels for busy,answer,ring.
Previously local channels channel state never changed. This became problematic
when the state of the other side of the local channel was lost, for example
during a masquerade. Changing the state of the local channel allows for the
scenario to be detected when the channel state is set to ringing, but the peer
isn't ringing. The specific problem scenario is described in 164201. Although
this was noted on one of the issues, here is the tested dialplan verified to
work:
exten => 9700,1,Dial(Local/*9700@default&Local/0009700@default)
exten => *9700,1,Set(GLOBAL(TESTCHAN)=${CHANNEL:0:${MATH(${LEN(${CHANNEL})}-1):0:2}}1)
exten => *9700,n,wait(3) ;3 works, 1 did not
exten => *9700,n,Dial(SIP/5001)
exten => 0009700,1,Wait(1) ;1 works, 3 did not
exten => 0009700,n,ChannelRedirect(${TESTCHAN},parkedcalls,701,1)
(closes issue #14992)
Reported by: davidw
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@246073 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r245793 | dvossel | 2010-02-09 17:07:17 -0600 (Tue, 09 Feb 2010) | 18 lines
Merged revisions 245792 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r245792 | dvossel | 2010-02-09 16:55:38 -0600 (Tue, 09 Feb 2010) | 12 lines
Fixes iaxs and iaxsl size off by one issue.
2^15 = 32768 which is the maximum allowed iax2 callnumber.
Creating the iaxs and iaxsl array of size 32768 means the maximum
callnumber is actually out of bounds. This causes a nasty crash.
(closes issue #15997)
Reported by: exarv
Patches:
iax_fix.diff uploaded by dvossel (license 671)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@245794 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r245578 | tilghman | 2010-02-08 16:31:40 -0600 (Mon, 08 Feb 2010) | 12 lines
Actually use _ASTLDFLAGS in the main/ and channels/ Makefiles.
They were previously passed correctly, but they simply weren't used. This
caused issues with various platforms whose builds needed to pass special
linker flags via the configure script.
(closes issue #16596)
Reported by: pprindeville
Patches:
asterisk-1.6-astldflags.patch uploaded by pprindeville (license 347)
Tested by: tilghman
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@245581 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r244505 | tilghman | 2010-02-03 12:34:29 -0600 (Wed, 03 Feb 2010) | 8 lines
The chanvar= setting should inherit the entire list of variables, not just the first one.
(closes issue #16359)
Reported by: raarts
Patches:
dahdi-setvars.diff uploaded by raarts (license 937)
Tested by: raarts
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@244508 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r243482 | russell | 2010-01-27 11:32:07 -0600 (Wed, 27 Jan 2010) | 13 lines
Fix the ability to specify an OSP token for an outbound IAX2 call.
When this patch was originally submitted, the code allowed for the token to be
set via a channel variable. I decided that a cleaner approach would be to
integrate it into the CHANNEL() function. Unfortunately, that is not a suitable
approach. It's not possible to get the value set on the channel soon enough
using that method. So, go back to the simple channel variable method.
(closes issue #16711)
Reported by: homesick
Patches:
iax-svn.diff uploaded by homesick (license 91)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@243485 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r241314 | jpeeler | 2010-01-19 12:46:11 -0600 (Tue, 19 Jan 2010) | 20 lines
Merged revisions 241227 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r241227 | jpeeler | 2010-01-19 11:22:18 -0600 (Tue, 19 Jan 2010) | 13 lines
Fix deadlock in agent_read by removing call to agent_logoff.
One must always lock the agents list lock before the agent private. agent_read
locks the private immediately, so locking the agents list lock is not an
option (which is what agent_logoff requires). Because agent_read already
has access to the agent private all that is necessary is to do the required
hanging up that agent_logoff performed.
(closes issue #16321)
Reported by: valon24
Patches:
bug16321.patch uploaded by jpeeler (license 325)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@241318 65c4cc65-6c06-0410-ace0-fbb531ad65f3
SIP show channelstats show current RTCP statistics for calls - if we have it. Calls bridged
in RTP p2p bridge doesn't have any statistics. In calls where the remote end doesn't send
RTCP or we can't receive it due to NAT, there's no reliable data as well.
Thanks, Klaus, for the patch. Sorry for the delay.
(closes issue #15819)
Reported by: klaus3000
Patches:
asterisk-sip-show-channelstats-1.6.2.txt uploaded by klaus3000 (license 65)
Tested by: klaus3000, oej
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@239703 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r239427 | dvossel | 2010-01-12 10:14:41 -0600 (Tue, 12 Jan 2010) | 14 lines
fixes text support in sdp answer
The code that handled setting 'm=text' in the sdp was not executing
in the correct order. The check to see if text was needed came after
the check to add 'm=text' to the sdp, this resulted in 'm=text' always
being set to 0 because it looked like text was never required.
(closes issue #16457)
Reported by: peterj
Patches:
textportinsdp.diff uploaded by peterj (license 951)
issue16457.diff uploaded by dvossel (license 671)
Tested by: peterj
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@239428 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r238412 | dvossel | 2010-01-07 14:15:27 -0600 (Thu, 07 Jan 2010) | 16 lines
Merged revisions 238411 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r238411 | dvossel | 2010-01-07 14:14:25 -0600 (Thu, 07 Jan 2010) | 10 lines
fixes crash in "scheduled_destroy" in chan_iax
A signed short was used to represent a callnumber. This is makes
it possible to attempt to access the iaxs array with a negative
index.
(closes issue #16565)
Reported by: jensvb
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@238416 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r236063 | dvossel | 2009-12-22 11:00:08 -0600 (Tue, 22 Dec 2009) | 18 lines
Merged revisions 236062 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r236062 | dvossel | 2009-12-22 10:58:19 -0600 (Tue, 22 Dec 2009) | 11 lines
fixes issue with p->method incorrectly set to ACK
It is possible for a second ACK to come in for a retransmitted message.
If an ack does not match an unacked message in our queue, restore the previous
p->method as this ACK is completely ignored.
(closes issue #16295)
Reported by: omolenkamp
Patches:
issue16295_v2.diff uploaded by dvossel (license 671)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@236064 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r235521 | file | 2009-12-17 19:21:07 -0400 (Thu, 17 Dec 2009) | 3 lines
Remove some old code for going to the 'fax' extension when a T.38 switchover occurs. This would have
already happened when we detected the CNG tone so this was basically a noop.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@235522 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r234526 | oej | 2009-12-14 11:46:20 +0100 (Mån, 14 Dec 2009) | 16 lines
Merged revisions 234492 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r234492 | oej | 2009-12-14 11:16:00 +0100 (Mån, 14 Dec 2009) | 8 lines
Stop sending 183's after call hangup.
There where still cases where the 183 keep-alive mechanism would not stop
sending 183's even though the Asterisk server had sent a final reply to
the invite.
EDVX-28
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@234559 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r232345 | file | 2009-12-02 12:40:14 -0400 (Wed, 02 Dec 2009) | 7 lines
Add support for handling the 415 Unsupported media type response like we do for a 488 Not acceptable here response.
(closes issue #16186)
Reported by: atis
Patches:
sip_t38_response_415.patch uploaded by atis (license 242)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@232348 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r232091 | jpeeler | 2009-12-01 18:45:18 -0600 (Tue, 01 Dec 2009) | 17 lines
Merged revisions 232090 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r232090 | jpeeler | 2009-12-01 18:42:58 -0600 (Tue, 01 Dec 2009) | 10 lines
Do not modify the gain settings on data calls.
(The digital flag actually represents a data call.)
(closes issue #15972)
Reported by: udosw
Patches:
transcap_digital_fix.diff.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@232094 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r231692 | kpfleming | 2009-11-30 15:47:42 -0600 (Mon, 30 Nov 2009) | 22 lines
Another round of UDPTL stack fixes/improvements:
1) Allow users of UDPTL stack to associate a character-string tag with a UDPTL
session, so that log/error/debug messages generated by the UDPTL stack can
be 'connected' to the endpoint that caused them to be generated.
2) Improve comments (and process) of calculating the far end's maximum IFP size
when redundancy mode is in use for error correction.
3) When an IFP larger than the calculated 'far max IFP' size is presented for
writing, truncate it rather than putting in the buffer and allowing the buffer
to overflow; this will cause the ends to retrain to a lower bit rate that
produces IFPs of an appropriate size if possible, and if not possible, the
FAX transfer will fail completely. In these cases, it is due to the one endpoint
supplying a T38FaxMaxDatagram value that is improperly calculated and is
too low to be of use; we have configuration options available to override
this behavior.
4) Eliminate use of T38FaxMaxDatagram value in udptl.conf; it is no longer
needed.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@231696 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r230881 | file | 2009-11-23 09:45:45 -0600 (Mon, 23 Nov 2009) | 7 lines
Change fax detection in chan_sip so it behaves as one would expect.
Internally the way T.38 is negotiated has changed and the option no longer
reflects a behavior that is valid. It will now look for a CNG tone on
received calls and if present send the call to the 'fax' extension. It is
then up to the application or channel to request the switch over to T.38.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@230884 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In sip_hangup we attempted to lock p->owner after we set it to NULL.
Thanks to fhackenberger for reporting the issue and submitting a patch.
(closes issue #15848)
Reported by: fhackenberger
Patches:
digium_bug_0015848 uploaded by fhackenberger (license 592)
Tested by: fhackenberger, lmadsen, TomS, shin-shoryuken, dvossel
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@229012 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r228145 | dbrooks | 2009-11-05 13:34:50 -0600 (Thu, 05 Nov 2009) | 16 lines
Merged revisions 228078 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r228078 | dbrooks | 2009-11-05 12:59:41 -0600 (Thu, 05 Nov 2009) | 9 lines
chan_misdn Asterisk 1.4.27-rc2 crash
Crash related to chan_misdn connection. Patch submitted by gknispel_proformatique, tested
by francesco_r. "I have many crash since i have upgraded to Asterisk 1.4.27-rc2. Attached
a full bt." This patch zeros out an ast_frame.
(closes issue #16041)
Reported by: francesco_r
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@228148 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With the new code, media level proprieties should no longer be confused with session level proprieties. This change also reorganizes some of the SDP parsing code which should make it easier to manage in the future.
(closes issue #14994)
Reported by: frawd
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@227760 65c4cc65-6c06-0410-ace0-fbb531ad65f3
SIP channel names were supposed to be unique by way of a name suffix derived from the
pointer to the channel's private data. Uniqueness was preserved on 32-bit systems, but
not on 64-bit systems. This patch, as suggested by kpfleming, replaces this suffix with
a simple incremented unsigned int.
(closes issue #15152)
Reported by: palbrecht
Review: https://reviewboard.asterisk.org/r/420/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@226978 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r225912 | jpeeler | 2009-10-26 14:40:26 -0500 (Mon, 26 Oct 2009) | 12 lines
ACL check not present for verifying SIP INVITEs
The ACL check in check_peer_ok was missing and has now been restored. The
missing check allowed for calls to be made on prohibited networks where an ACL
was defined in sip.conf and the allowguest option was set to off. See the AST
security advisory below for more information.
Merge code associated with AST-2009-007.
(closes issue #16091)
Reported by: thom4fun
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@225914 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Mark Michelson
Tzafrir Cohen
Richard Mudgett
Matthew Nicholson
Jeff Peeler
Russell Bryant
Paul Belanger
Terry Wilson
Tilghman Lesher
Jason Parker
David Vossel
Leif Madsen
Sean Bright
Moises Silva
Alec L Davis
Kevin P. Fleming
Olle Johansson
Joshua Colp
David Brooks