Age | Commit message (Collapse) | Author | Files | Lines |
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@253631 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This re-renames ast_rtp_update_source to ast_rtp_new_source
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@253158 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@252175 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@251997 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@251986 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@250480 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@250394 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@249536 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@249365 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@249234 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #16792)
Reported by: vrban
Patches:
t38_606.patch uploaded by vrban (license 756)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@249100 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #16862)
Reported by: pwalker
Patches:
replaces_deadlock_1.4 uploaded by dvossel (license 671)
Tested by: pwalker, dvossel
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@248396 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@247910 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@245792 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@244785 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
expired frames in the queue.
(closes issue #16525)
Reported by: kobaz
Patches:
20100126__issue16525.diff.txt uploaded by tilghman (license 14)
20100129__issue16525__1.6.0.diff.txt uploaded by tilghman (license 14)
Tested by: kobaz, atis
(closes issue #16581)
Reported by: ZX81
(closes issue #16681)
Reported by: alexr1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@244070 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@243779 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@242226 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@241227 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@238411 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue 0016459)
Reported by: Rzadzins
Patches:
chan_sip_longer_cid.patch uploaded by Rzadzins (license 953)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@238409 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reviewboard: https://reviewboard.asterisk.org/r/452/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@237318 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@237135 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15609)
Reported by: aragon
Patches:
20091230__issue16521__1.4__chan_local_only.diff.txt uploaded by tilghman (license 14)
Tested by: aragon
Review: https://reviewboard.asterisk.org/r/452/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@236981 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
configured when T.38 is found but no audio stream is found.
(closes issue #16318)
Reported by: bird_of_Luck
Patches:
t38-sdp-parsing-fix3.diff uploaded by mnicholson (license 96), written by vrban and mnicholson
Tested by: vrban, mihaill
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@236261 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@236062 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@234492 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
destroyed.
(closes issue #15627)
Reported by: falves11
Patches:
20091209__issue15627__1.6.0.diff.txt uploaded by tilghman (license 14)
20091209__issue15627__1.4.diff.txt uploaded by tilghman (license 14)
Tested by: falves11
Review: https://reviewboard.asterisk.org/r/446/
(closes issue #15716)
Reported by: dant
(closes issue #16270)
Reported by: corruptor
(closes issue #15356)
Reported by: falves11
(issue #16382)
Reported by: lftsy
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@234095 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #16298)
Reported by: mgernoth
Patches:
reg_parse_issue_1.4.diff uploaded by dvossel (license 671)
Tested by: dvossel
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@233471 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #16387)
Reported by: zalex1953
Tested by: mnicholson, zalex1953
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@233392 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(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: http://svn.digium.com/svn/asterisk/branches/1.4@232090 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #16261)
Reported by: edguy3
Patches:
edguy16261.patch uploaded by edguy3 (license 917)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@231233 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
is not properly newline terminated, ensure that that line is included in the
debug output.
(part of issue #16268)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@230875 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
to correct.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@230839 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #16268)
Reported by: sgimeno
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@230772 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
The configuration option for allowing hosts to make non-token-based calls
is 'calltokenoptional', not 'calltokenignore'. (reported on asterisk-users)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@230246 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14446)
Reported by: frawd
Patches:
via_maddr.patch uploaded by frawd (license 610)
Tested by: frawd
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@230144 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
chan_local private structure when only one should.
(closes issue #15314)
Reported by: sroberts
Patches:
Issue15314_Move_Nulling_owner.patch uploaded by davidw (license 780)
Tested by: davidw, lottc
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@230038 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
AST-2009-006
(closes issue #16206)
Reported by: bklang
Tested by: bklang
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@229167 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #16175)
Reported by: paul-tg
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@229091 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
using users.conf
(issue ABE-1989)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@228547 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14970)
Reported by: tzafrir
Patches:
vpb_exception.diff uploaded by tzafrir (license 46)
Tested by: markwaters
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@228079 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@228078 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@227758 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
the From
URI and Authorization header would reveal whether it was valid or not.
(AST-2009-008)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@227700 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
for outgoing calls.
This is the relevant portion of asterisk/trunk -r226648
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@227275 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
the URI.
(closes issue #15909)
Reported by: kobaz
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@227166 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@227090 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(based on kpfleming's feedback)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@227089 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Review: https://reviewboard.asterisk.org/r/415/
Thanks kpfleming for a quick review.
(EDVX-003)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@227088 f38db490-d61c-443f-a65b-d21fe96a405b
|