| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@221303 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15865)
Reported by: kobaz
Patches:
20090915__issue15865.diff.txt uploaded by tilghman (license 14)
Tested by: kobaz
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@221200 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15471)
Reported by: dkerr
Patches:
csv_quote_14.txt uploaded by mnick (license )
Tested by: mnick
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@221157 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@221153 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Be default, change SSRC when doing an audio stream changes Asterisk doesn't
honor marker bit when reinvited to already-bridged RTP streams,resulting in
far-end stack discarding packets with "old" timestamps that areactually part of
a new stream. This patch sends AST_CONTROL_SRCUPDATE whenever there is a
reinvite, unless the 'constantssrc' is set to true in sip.conf.
The original issue reported to Digium support detailed the following situation:
ITSP <-> Asterisk 1.4.26.2 <-> SIP-based Application Server Call comes in
fromITSP, Asterisk dials the app server which sends a re-invite back
toAsterisk--not to negotiate to send media directly to the ITSP, but to
indicatethat it's changing the stream it's sending to Asterisk. The app
servergenerates a new SSRC, sequence numbers, timestamps, and sets the marker
bit on the new stream. Asterisk passes through the teimstamp of the new stream,
butdoes not reset the SSRC, sequence numbers, or set the marker bit.
When the timestamp on the new stream is older than the timestamp on the
originalstream, the ITSP (which doesn't know there has been any change) discards
the newframes because it thinks they are too old. This patch addresses this by
changing the SSRC on a stream update unless constantssrc=true is set in
sip.conf.
Review: https://reviewboard.asterisk.org/r/374/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@221086 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
chanspy_ds_chan_fixup() is called with the channel locked.
(closes issue #15965)
Reported by: atis
Patches:
chanspy-deadlock-fix1.diff uploaded by mnicholson (license 96)
Tested by: atis
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@220907 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This fixes a 100% CPU problem in the SIP driver, found by profiling
the driver while the problem was occurring.
(closes issue #14309)
Reported by: pkempgen
Patches:
20090924__issue14309.diff.txt uploaded by tilghman (license 14)
Tested by: pkempgen, vrban
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@220873 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
so we override any default optimization levels for a particular install.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@220717 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Call Progress() in your dialplan if you explicitly want progress to be sent.
(Reverts change 216430, closes issue #15957)
Reported by: Pavel Troller on the Asterisk-Dev mailing list
http://lists.digium.com/pipermail/asterisk-dev/2009-September/039897.html
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@220288 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by Klaus Darilion on the asterisk-dev mailing list.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@220213 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@220099 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This fixes building on all systems that don't have bash
at /bin/bash
Reported by _ys on #asterisk-dev
Tested by _ys on #asterisk-dev
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@220027 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
new values.
This change introduces a configuration version variable, which ensures that
connections with the old values are not reused but are allowed to expire
normally.
(closes issue #15934)
Reported by: viniciusfontes
Patches:
20090922__issue15934.diff.txt uploaded by tilghman (license 14)
Tested by: viniciusfontes
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@219816 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@219720 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15129)
Reported by: bmh
Patches:
20090918__issue15129.diff.txt uploaded by tilghman (license 14)
Review:
https://reviewboard.asterisk.org/r/372/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@219653 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This fixes the latest crash posted on issue 15609.
(issue #15609)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@219586 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
The iax frame's retrans sched id was written over right
before iax2_frame_free was called. In iax2_frame_free that
retrans id is used to delete the sched item. By writing over
the retrans field before the sched item could be deleted, it was
possible for a retransmit to occur on a freed frame.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@219519 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
INVITE requests must always contain a new unique branch id. When
a new branch id is created for an INVITE, the dialog's invite_branch
variable must be updated so CANCEL requests use the correct branch id.
(closes issue #15262)
Reported by: maniax
Patches:
asterisk-1.6.1.0-sip-branch.patch uploaded by tweety (license 608)
invite_new_branch_trunk.diff uploaded by dvossel (license 671)
Tested by: maniax, dvossel
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@219450 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This was problematic during spiral tests at SIPit...
along with some other things as well.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@219320 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This patch cleans up the locking logic in chan_sip.c's
handle_invite_replaces() function as well as making use
of ast_do_masquerade() rather than forcing the masquerade
on an ast_read(). The code had several redundant unlocks
that would result in 'freed more times than we've locked!'
errors. I cleaned these up as well as moving all the unlock
logic to the end of the function. This patch should also
resolve the issue people were having with the replacecall
channel never being unlocked with one legged calls.
(closes issue #15151)
Reported by: irroot
Patches:
invite_w_replaces_1.4.diff uploaded by dvossel (license 671)
Tested by: irroot, dvossel
Review: https://reviewboard.asterisk.org/r/371/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@219303 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
removing the channel from the channel list before begining channel tear down.
This fix may potentially cause problems with CDR backends that access the channel a CDR is associated with via the channel list. This fix makes the channel unavabile at the time when the CDR backend is invoked. This has been documented in include/asterisk/cdr.h.
(closes issue #15316)
Reported by: vmarrone
Tested by: mnicholson
Review: https://reviewboard.asterisk.org/r/362/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@219136 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15583)
Reported by: pkempgen
Patches:
20090726__issue15583.diff.txt uploaded by tilghman (license 14)
20090726__issue15583-1.4-4.diff.txt uploaded by pkempgen (license 169)
Tested by: pkempgen
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@219023 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
matching.
Pattern matching for extensions uses a type of scoring system, giving values for
specificity to each character in the pattern. Unfortunately, this is done character
by character, in order. This does lead to some less specific patterns being first
in line for matching, but it will usually get the job done.
This patch merely brings CID matching to the same level as extension matching.
This patch does not attempt to tackle the problem shared by extension matching.
(closes issue #14708)
Reported by: klaus3000
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@218867 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
The firmware can now be found on downloads.digium.com, where the rest of our
binary downloads live. This was the last part of our Asterisk tarballs that
was considered non-free by Debian. :-)
(closes issue #15838)
Reported by: paravoid
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@218798 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
the change does nothing.
(closes issue #15492)
Reported by: cbbs70a
Patches:
20090713__issue15492.diff.txt uploaded by tilghman (license 14)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@218730 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
attr before returning.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@218623 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
of the address of record.
(closes issue #14438)
Reported by: ravindrad
Patches:
regquerypatch uploaded by ravindrad (license 684)
Tested by: ravindrad
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@218578 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Also, not in the original bug report, but related fields are accountcode and
musicclass, and the inheritance of datastores.
(closes issue #15372)
Reported by: Romik
Patches:
20090828__issue15372.diff.txt uploaded by tilghman (license 14)
Tested by: cervajs
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@218577 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@218498 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@218497 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
After talking to rmudgett about some of his recent iflist locking changes, it
was determined that the only place that would destroy a channel without being
explicitly to do so was in handle_init_event. The loop to walk the interface
list has been modified to wait to destroy the channel until the dahdi_pvt of
the channel to be destroyed is no longer needed.
(closes issue #15378)
Reported by: samy
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@218401 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
again.
(issue #15055, SWP-129)
Reported by: jthurman
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@218331 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15100)
Reported by: lmsteffan
Patches:
(modified) pickup.patch uploaded by lmsteffan (license 779)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@218223 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
answer.
(Fixes AST-228)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@217989 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@217917 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
The IAX2 Call Token security patch inadvertently broke the use of
encryption due to the reorganization of code in the socket_process()
function. When encryption is used, an incoming full frame must first
be decrypted before the information elements can be parsed. The
security release mistakenly moved IE parsing before decryption in
order to process the new Call Token IE. To resolve this, decryption
of full frames is once again done before looking into the frame. This
involves searching for an existing callno, checking the pvt to see if
encryption is turned on, and decrypting the packet before the internal
fields of the full frame are accessed.
associated with AST-2009-006
(closes issue #15834)
Reported by: karesmakro
Patches:
iax2_encryption_fix_1.4.diff uploaded by dvossel (license 671)
Tested by: dvossel, karesmakro
Review: https://reviewboard.asterisk.org/r/355/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@217806 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
muted doesn't compile any more on os/x, so I have to disable it in order to testcompile other code...
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@217735 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Remove code that causes loops in registrations.
We have agreed that the patch that this code was part of was bad. I am ripping out the code that causes
the issue. putnopvut needs to check the rest of the patch, if it needs to be changed as well.
This solves the issue reported in #15540, but needs more work before we close it (as described above).
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@217668 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
conference are not heard.
(closes issue #14588)
Reported by: voipas
Patches:
20090716__issue14588__2.diff.txt uploaded by tilghman (license 14)
Tested by: lmadsen, twisted, tilghman
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@217156 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@216435 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@216432 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
media issue in SIP
The issue at hand is that some legacy (dying) PBX systems send empty media frames on PRI
links *before* any call progress. The SIP channel receives these frames and by default
signals 183 Session progress and starts sending media. This will cause phones to
play silence and ignore the later 180 ringing message. A bad user experience.
The fix is twofold:
- We discovered that asterisk apps that support early media ("noanswer") did not send
any PROGRESS frame to indicate early media. Fixed.
- We introduce a setting in chan_sip so that users can disable any relay of media frames
before the outbound channel actually indicates any sort of call progress.
In 1.4, 1.6.0 and 1.6.1, this will be disabled for backward compatibility. In later versions
of Asterisk, this will be enabled. We don't assume that it will change your Asterisk
phone experience - only for the better.
We encourage third-party application developers to make sure that if they have applications
that wants to send early media, add a PROGRESS control frame transmission to make sure that
all channel drivers actually will start sending early media. This has not been the default
in Asterisk previous to this patch, so if you got inspiration from our code, you need to
update accordingly. Sorry for the trouble and thanks for your support.
This code has been running for a few months in a large scale installation (over 250
servers with PRI and/or BRI links to old PBX systems).
That's no proof that this is an excellent patch, but, well, it's tested :-)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@216430 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This is the same as rev 216222 in trunk but 1.4 is affected as well
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@216369 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r216262 | russell | 2009-09-04 05:47:37 -0500 (Fri, 04 Sep 2009) | 2 lines
Add a plain text version of the IAX2 security document.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@216263 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
........
r216087 | russell | 2009-09-03 14:37:05 -0500 (Thu, 03 Sep 2009) | 2 lines
Fix a typo.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@216089 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r216080 | russell | 2009-09-03 14:35:23 -0500 (Thu, 03 Sep 2009) | 2 lines
Add a note about IAX2 to UPGRADE.txt.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@216085 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r216005 | russell | 2009-09-03 13:42:24 -0500 (Thu, 03 Sep 2009) | 2 lines
Add IAX2 security document related to AST-2009-006.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@216008 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #12912)
Reported by: rathaus
Tested by: tilghman, russell, dvossel, dbrooks
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@216000 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
From section 13.3.1.1 of RFC 3261:
If the UAS desires an extended period of time to answer the INVITE,
it will need to ask for an "extension" in order to prevent proxies
from canceling the transaction. A proxy has the option of canceling
a transaction when there is a gap of 3 minutes between responses in a
transaction. To prevent cancellation, the UAS MUST send a non-100
provisional response at every minute, to handle the possibility of
lost provisional responses.
(closes issue #11157)
Reported by: rjain
Tested by: twilson
Review: https://reviewboard.asterisk.org/r/315/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@215682 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
In general channel names are in the form Foo/Bar-Z, but the channel name
could have multiple hyphens and look like Foo/B-a-r-Z. Use strrchr to
truncate the channel name at the last hyphen.
(closes issue #15810)
Reported by: dhubbard
Patches:
dw-softhangup-1.4.patch uploaded by dhubbard (license 733)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@215270 f38db490-d61c-443f-a65b-d21fe96a405b
|
