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.4@249536 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:
based on overlap_receiving_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
(closes issue #16789)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@249365 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@247910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@245792 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/#9700@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 => #9700,1,Wait(1) ;1 works, 3 did not
exten => #9700,n,ChannelRedirect(${TESTCHAN},parkedcalls,701,1)
(closes issue #14992)
Reported by: davidw
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@244785 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@241227 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@238411 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@236062 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@234492 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(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.4@232090 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The configuration option for allowing hosts to make non-token-based calls
is 'calltokenoptional', not 'calltokenignore'. (reported on asterisk-users)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@230246 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@228078 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
Tested by: frawd, mnicholson, file
Review: https://reviewboard.asterisk.org/r/385/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@227758 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.4@226972 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It is possible for the PBX thread to queue up signaling frames before
a destination call number is received. This can result in signaling
frames being sent out with no destination call number. Since recent
versions of Asterisk require accurate destination callnumbers for all
Full Frames, this can cause a VNAK loop to occur. To resolve this
no signaling frames are sent until a destination callnumber is received,
and destination call numbers are now only required for iax_pvt matching
when the frame is an ACK.
Review: https://reviewboard.asterisk.org/r/413/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@225243 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The shrinking of caller id removes '(', ' ', ')', non-trailing '.',
and '-' from the string. This means values such as 555.5555 and
test-test result in 555555 and testtest. There are instances,
such as Skype integration, where a specific value is passed via
caller id that must be preserved unmodified. This patch makes
the shrinking of caller id optional in chan_sip and chan_iax in
order to support such cases. By default this option is on to
preserve previous expected behavior.
(closes issue #15940)
Reported by: dimas
Patches:
v2-15940.patch uploaded by dimas (license 88)
15940_shrinkcallerid_trunk.c uploaded by dvossel (license 671)
Tested by: dvossel
Review: https://reviewboard.asterisk.org/r/408/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@225032 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The problem here is that chan_dahdi is designed in such a way to set
certain values in the dahdi_pvt only once. One of those such values
is the configured caller id data in chan_dahdi.conf. For PRI, the
configured caller id data could be overwritten during a call. Instead
of saving the data and restoring, it was decided that for all non-analog
channels it was simply best to not set the configured caller id in the
first place and also clear it at the end of the call.
(closes issue #15883)
Reported by: jsmith
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@224330 65c4cc65-6c06-0410-ace0-fbb531ad65f3
