Age | Commit message (Collapse) | Author | Files | Lines |
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@271300 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
According to RFC 3261 section 17.2.2, which describes non-INVITE server
transaction, when a dialog enters the Completed state it must destroy
the dialog after Timer J (T1*64) fires. For a BYE transaction Asterisk
terminates the dialog immediately during sip_hangup() when it should be
waiting T1*64 ms. This results in some odd behavior. For instance if
Asterisk receives a BYE and transmits a 200ok in response, if the endpoint
never receives the 200ok it will retransmit the BYE to which Asterisk
responds with a "481 Call leg/transaction does not exist" because the
dialog is already gone.
To resolve this I made a function called sip_scheddestroy_final(). This
differs slightly from sip_schedestroy() in that it enables a flag that
will prevent the destruction from ever being rescheduled or canceled
afterwards. It also prevents the pvt's needdestroy flag from being set
which triggers the destruction of the dialog within the do_monitor thread().
By using this function we are guaranteed destruction will not occur
until the scheduled time. This allows Asterisk to respond to any possible
retransmits for a dialog after we process the initial BYE request for T1*64 ms.
Other changes: I removed two instances where sip_cancel_destroy is used
right before calling sip_scheddestroy. sip_scheddestroy always calls
sip_cancel_destroy before scheduling the new destruction so it is completely
unnecessary.
Review: https://reviewboard.asterisk.org/r/694/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@271262 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@271192 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@271056 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@270983 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r270980 | qwell | 2010-06-16 16:10:09 -0500 (Wed, 16 Jun 2010) | 4 lines
Need to lock the agent chan before access its internal bits.
Pointed out by russellb on asterisk-dev mailing list.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@270981 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #16293)
Reported by: malcolmd
Patches:
g719.passthrough.patch.7 uploaded by malcolmd (license 924)
format_g719.c uploaded by malcolmd (license 924)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@270940 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@270867 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Clearing the callwaitcas flag in analog_call was causing the incoming D digit
to be ignored which triggers sending the caller ID.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@270836 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@270726 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@270658 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Also found a place where sig_pri_init_pri() was inlined and called it
instead.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@270298 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
The "channel" option would chop the channel name at the last '-', which made
it useless for something like a channel transfer from the dialplan. The
"fullchannel" option will return the channel name as-is.
ABE-2218
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@270260 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Add the append_msn_to_cid_tag option to chan_dahdi like chan_misdn.
Review: https://reviewboard.asterisk.org/r/696/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@270219 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
http://bamboo.asterisk.org/download/AST-TRUNKFREEBSD/build_logs/AST-TRUNKFREEBSD-187.log
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@269602 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r269495 | russell | 2010-06-09 17:18:37 -0500 (Wed, 09 Jun 2010) | 2 lines
Don't stop Asterisk if chan_oss fails to register 'Console' (due to another channel driver already claiming it).
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@269497 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@269308 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@269307 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
* chan_dahdi supports dialing configuring and dialing by device file name.
DAHDI/span-name!local!1 will use /dev/dahdi/span-name/local/1 . Likewise
it may appear in chan_dahdi.conf as 'channel => span-name!local!1'.
* A new options for chan_dahdi.conf: 'ignore_failed_channels'. Boolean.
False by default. If set, chan_dahdi will ignore failed 'channel' entries.
Handy for the above name-based syntax as it does not depend on
initialization order.
* have my_pri_make_cc_dialstring() only manupulate dial-strings of group
(gGrR) dialing, which make it lsightly more complicated.
https://reviewboard.asterisk.org/r/535/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@269238 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #17336)
Reported by: snuffy
Patches:
doxygen-fixes1.diff uploaded by snuffy (license 35)
Tested by: russell
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@268969 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
After 5 years in mantis and over a year on reviewboard, SRTP support is finally
being comitted. This includes generic CHANNEL dialplan functions that work for
getting the status of whether a call has secure media or signaling as defined
by the underlying channel technology and for setting whether or not a new
channel being bridged to a calling channel should have secure signaling or
media. See doc/tex/secure-calls.tex for examples.
Original patch by mikma, updated for trunk and revised by me.
(closes issue #5413)
Reported by: mikma
Tested by: twilson, notthematrix, hemanshurpatel
Review: https://reviewboard.asterisk.org/r/191/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@268894 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@268857 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@268818 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Also, optimize the allocation of mailboxes to avoid additional memory structures.
(closes issue #16320)
Reported by: Marquis
Patches:
20100525__issue16320.diff.txt uploaded by tilghman (license 14)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@268817 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Extract the SS7 specific code out of chan_dahdi like what was done to
ISDN/PRI and analog signaling. The new SS7 structures were modeled on
sig_pri.
The changes to sig_pri are an enhancement and a bug fix made possible
because SS7 was extracted.
1) The sig_pri TRANSFERCAPABILITY channel variable should have been set
unconditionally in sig_pri_new_ast_channel().
2) SS7/PRI transfer capability interaction in dahdi_new() fixed because of
SS7 extraction.
3) Module ref count error in dahdi_new() if startpbx failed to start the
PBX for some reason.
Review: https://reviewboard.asterisk.org/r/661/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@268774 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
is expressed as a double, the last value would not also need to be a double.
(closes issue #15807)
Reported by: klaus3000
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@268773 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@268734 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@268495 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@268281 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
option tweak
Changes.
1. RFC 3261 states in section 17.1.2.2 and 17.1.1.2 that retransmission
timers should initially be set to timer T1. T1 by default is 500ms.
Asterisk was starting the retransmission timers at T1*2 which shouldn't
cause any problems, but is not RFC compliant.
2. RFC 3261 states in section 17.1.2.2 that for a non-INVITE client transaction,
if the retransmit timer fires while in the proceeding state that
the request must be retransmitted. Asterisk currently ack's
requests for both INVITE and non-INVITE transactions when a
1XX response is received, this patch changes this for non-INVITE requests.
3. The 'registerattempts' option in sip.conf is supposed to set
how many registry attempts will be made before giving up. When
this option is set to 1, I would expect only one registry attempt
to be made before stopping because of a failure, but instead two are
made. In my opinion this is not expected behavior. This option does
not indicate that these are re-attempts. The logic behind this option
has been changed to only attempt registers the exact number of times
this option is set to. If this option is 0, it still continues to
re-attempt the registration forever.
Review: https://reviewboard.asterisk.org/r/687/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@268205 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
The problem would manifest itself if your dialplan matching could accept
more digits to match than were actually dialed. The time out waiting for
overlap digits disconnected the call instead of matching any accumulated
digits to the dialplan.
Accidental conversion of a break out of loop as a break out of switch.
(closes issue #17401)
Reported by: avalentin
Patches:
issue17401_digit_timeout.patch uploaded by rmudgett (license 664)
Tested by: avalentin, rmudgett
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@267928 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
From issue ABE-2247. RFC 3261 compliance for sections 13.2.24 and 17.1.1.2.
Review: https://reviewboard.asterisk.org/r/692/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@267863 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@267537 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@267490 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@267445 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Add the ability to report waiting messages to ISDN endpoints (phones).
Relevant specification: EN 300 650 and EN 300 745
Review: https://reviewboard.asterisk.org/r/599/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@267399 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@267352 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Add the ability to report malicious callers as an AMI event in the call
event class.
Relevant specification: EN 300 180
Review: https://reviewboard.asterisk.org/r/576/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@267350 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Add the ability to announce a call to an endpoint when there are no B
channels available. A call waiting call is a SETUP message with no B
channel selected.
Relevant specification: EN 300 056, EN 300 057, EN 300 058
For DAHDI/ISDN channels, the CHANNEL() dialplan function now supports the
"no_media_path" option.
* Returns "0" if there is a B channel associated with the call.
* Returns "1" if no B channel is associated with the call. The call is
either on hold or is a call waiting call.
If you are going to allow incoming call waiting calls then you need to use
CHANNEL(no_media_path) do determine if you must drop a call to accept the
new call.
Review: https://reviewboard.asterisk.org/r/568/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@267261 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Two struct sockaddr_ins are created when applying directmedia
host access rules. The addresses of these are passed to the RTP
engine to be filled in. However, the RTP engine inspects the fields
of the structs before actually taking action. This inspection caused
valgrind to be a bit unhappy.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@267097 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Asterisk Generic AOC Representation
- Generic AOC encode/decode routines.
(Generic AOC must be encoded to be passed on the wire in the AST_CONTROL_AOC frame)
- AST_CONTROL_AOC frame type to represent generic encoded AOC data
- Manager events for AOC-S, AOC-D, and AOC-E messages
Asterisk App Support
- app_dial AOC-S pass-through support on call setup
- app_queue AOC-S pass-through support on call setup
AOC Unit Tests
- AOC Unit Tests for encode/decode routines
- AOC Unit Test for manager event representation.
SIP AOC Support
- Pass-through of generic AOC-D and AOC-E messages to snom phones via the
snom AOC specification.
- Creation of chan_sip page3 flags for the addition of the new
'snom_aoc_enabled' sip.conf option.
IAX AOC Support
- Natively supports AOC pass-through through the use of the new
AST_CONTROL_AOC frame type
DAHDI AOC Support
- ETSI PRI full AOC Pass-through support
- 'aoc_enable' chan_dahdi.conf option for independently enabling
pass-through of AOC-S, AOC-D, AOC-E.
- 'aoce_delayhangup' option for retrieving AOC-E on disconnect.
- DAHDI A() dial string option for requesting AOC services.
example usage:
;requests AOC-S, AOC-D, and AOC-E on call setup
exten=>1111,1,Dial(DAHDI/g1/1112/A(s,d,e))
Review: https://reviewboard.asterisk.org/r/552/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@267096 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This feature generates AMI events in the new aoc event class from the
events passed up by libpri.
Review: https://reviewboard.asterisk.org/r/537/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@267008 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Added ability to send and receive ETSI Explicit Call Transfer (ECT)
messages to eliminate tromboned calls.
Note: Asterisk already supported initiating the transfer of calls to
eliminate tromboned calls to libpri so there was nothing to do for the
asterisk portion.
Review: https://reviewboard.asterisk.org/r/520/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@266926 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #17264)
Reported by: falves11
Patches:
issue_17264_reviewboard_fix.diff uploaded by dvossel (license 671)
issue_17264_1.6.2_reviewboard_fix.diff uploaded by dvossel (license 671)
Tested by: falves11
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@266292 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This patch breaks up every part of the sip registry string during
config parsing and removes all parsing from transmit_register().
Thanks to Nick_Lewis for contributing this patch!
(closes issue #14331)
Reported by: Nick_Lewis
Patches:
chan_sip.c-domparse.patch uploaded by Nick Lewis (license 657)
chan_sip.c.patch uploaded by Nick Lewis (license 657)
chan_sip.c.domainparse3.patch uploaded by Nick Lewis (license 657)
chan_sip.c-domparse4.patch uploaded by Nick Lewis (license 657)
chan_sip.c-domparse5.patch uploaded by Nick Lewis (license 657)
nicklewispatch.diff uploaded by dvossel (license 671)
Tested by: Nick_Lewis, dvossel
Review: https://reviewboard.asterisk.org/r/628/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@266090 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #17339)
Reported by: one47
Patches:
sip_magic_pickup2 uploaded by one47 (license 23)
Tested by: one47, dvossel
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@266006 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@265844 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #17016)
Reported by: twilson
Patches:
17016.patch uploaded by mmichelson (license 60)
Tested by: devmod
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@265842 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@265698 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #17109)
Reported by: under
Patches:
logstream.diff uploaded by under (license 914)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@265451 f38db490-d61c-443f-a65b-d21fe96a405b
|