If you've mistakenly put a space before typing in a command, the
leading space will be included as part of the command, and the command
parser will not find the corresponding command. This patch rectifies
that situation by stripping the leading spaces on commands.
Review: https://reviewboard.asterisk.org/r/2709/
Patch-by: Tilghman Lesher
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@396745 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Depending on certain conditions it was possible for the hashtab counting thread
to starve other threads, preventing them from executing in the expected fashion.
This change adds a sleep to allow the others to do what they need to do. While
this doesn't thrash the hashtab as much as previously, it at least works.
(closes issue ASTERISK-22276)
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@396619 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a peer is used in a register line and TLS is defined as the transport, the
registration fails since the transport on the dialog is never set properly
resulting in UDP being used instead of TLS.
This patch sets the dialog's transport based on the transport that was defined
in the register line. If the register line does not specify a transport, the
parsing function for the register line always defaults back to UDP.
(closes issue ASTERISK-21964)
Reported by: Doug Bailey
Tested by: Doug Bailey
Patches:
asterisk-21964-set-reg-dialog-transport.diff
by Michael L. Young (license 5026)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@396240 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The commit (r387133) for fixing ASTERISK-21466 accidentally removed an extra
line break between the peers returned by the AMI action SIPPeers. This
results in some parsers breaking because they expect this extra line break.
This patch restores that extra line break.
(closes issue ASTERISK-22239)
Reported by: Jacek Konieczny
Tested by: Jacek Konieczny, Michael L. Young
Patches:
asterisk-ami_sippeers_separator.patch by Jacek Konieczny (license 6298)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@396236 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch cleans up documentation in func_channel for the following items:
* rtpsource
* secure_signaling
* secure_media
(closes issue ASTERISK-20969)
Reported by: snuffy
patches:
func_chan-update.diff uploaded by snuffy (License 5024)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@394980 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ring tone provided in the sample indications.conf was incorrect. This patch
modifies the sample ring tone to be what it should:
ring = 425/400,0/200,425/400,0/2000
This brings it in line with the tone definition in DAHDI 2.7.0. (zonedata.c)
(closes issue ASTERISK-21997)
Reported by: Filip Jenicek
patches:
malaysia_ring.patch uploaded by phill (License 6277)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@394940 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch modifies parsing of cookies in Asterisk's http server by doing an
explicit comparison of the "Cookie" header instead of looking at the first
6 characters to determine if the header is a cookie header. This avoids
parsing "Cookie2" headers and overwriting the previously parsed "Cookie"
header.
Note that we probably should be appending the cookies in each "Cookie"
header to the parsed results; however, while clients can send multiple
cookie headers they never really do. While this patch doesn't improve
Asterisk's behavior in that regard, it shouldn't make it any worse either.
Note that the solution in this patch was pointed out on the issue by the
issue reporter, Stuart Henderson.
(closes issue ASTERISK-21789)
Reported by: Stuart Henderson
Tested by: mjordan, Stuart Henderson
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@394899 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch updates the realtime SQL scripts with an entry that will create the
queue_log table. This brings the PostgreSQL scripts inline with the MySQL
scripts, with respect to what tables they will create.
(closes issue ASTERISK-21021)
Reported by: Eugene
patches:
queue_log.sql uploaded by varnav (license 6360)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@394896 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The connectedline parameter for a chan_iax2 peer was undocumented. This patch
documents the options in the sample configuration file.
(closes issue ASTERISK-21953)
Reported by: Birger "WIMPy" Harzenetter
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@394886 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If there is an error streaming an audio file, the current return status makes it
difficult for an AGI script to determine that there was an error with the audio
file.
This patches changes the result to return -1 and the function returns
RESULT_FAILURE instead of RESULT_SUCCESS. From looking at other parts of
res_agi, this would appear to be the proper way to handle an error.
(closes issue ASTERISK-21903)
Reported by: Ariel Wainer
Tested by: Ariel Wainer
Patches:
asterisk-21903-return-stream-res_1.8.diff
by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2625/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@394640 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It is not apparent to the average user that the PASSTHRU function should not
be passed as ${PASSTHRU(string)} but just as PASSTHRU(string) to functions
which take a variable name and not its contents.
This patch clarifies the behavior in the documentation and provides an example.
(closes issue ASTERISK-21717)
Reported by: Richard Miller
patches:
func_strings.diff uploaded by Richard Miller (license 5685)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@394302 65c4cc65-6c06-0410-ace0-fbb531ad65f3
from mixing different variants or general MFC-R2 settings within the same E1 line.
Most users do not have a problem with this since MFC-R2 lines are usually fractional E1s, or
the whole E1 has the same country variant and R2 settings.
In Venezuela however is common to have inbound MFC-R2 and outbound DTMF-R2 within the same E1.
This fix now properly parses the chan_dahdi.conf file to generate a new openr2 context every
time a new channel => section is found and the configuration was changed.
(closes issue ASTERISK-21117)
Reported by: Rafael Angulo
Related Elastix issue: http://bugs.elastix.org/view.php?id=1612
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@394106 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The SLA code within app_meetme was written before asotbj2 had been
merged into Asterisk. Worse, support for reloads did not exist at first
and was added later as a bolt-on feature. I knew at the time that
reloading was not safe at all while SLA was in use, so the reload would
be queued up to execute when the system was idle. Unfortunately, this
approach was still prone to errors beyond the fact that this was the
only place in Asterisk where configuration was not reloaded
instantly when requested.
This patch converts various SLA objects to be reference counted objects
using astobj2. This allows reloads to be processed while the system is
in use. The code ensures that the objects will not disappear while one
of the other threads is using them. However, they will be immediately
removed from the global trunk and station containers so no new calls
will use them if removed from configuration.
Review: https://reviewboard.asterisk.org/r/2581/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@393928 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When we load a module with the LOAD_PRIORITY flag, we remove its entry from
the load order list. Unfortunately, we don't free the memory associated with
entry in the list. This patch corrects that and properly frees the memory for
the module in the list.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@391489 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1). When touching the bridgecallno, we need to lock it.
2). Remove magic number '0' and replace with TRANSFER_NONE.
3). Exit early if no bridgecallno.
4). Reduce indentation.
Reported by: alecdavis
Tested by: alecdavis
alecdavis (license 585)
Review https://reviewboard.asterisk.org/r/2613/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@391333 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r386792, the ability to play prompts to the first caller in a call queue was
added. While this is arguably a bug fix for those who expect the first caller
to continue receiving prompts while the agent is dialed, it has the side effect
of preventing the first caller from hearing the agent immediately upon
bridging. This may not be a problem for those who really want this option, but
for those who didn't care whether or not the first caller in queue heard their
position, it was an issue.
This patch disables the ability for the first caller in the queue to hear
prompts and adds a new option, announce-to-first-user, to queues.conf. Those
who the behavior can enable it by setting this value to True.
Note that if we ever implement the ability to have the prompts be stopped
upon bridging, this option can be removed.
(closes issue ASTERISK-21782)
Reported by: Remi Quezada
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@391215 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1). When touching the bridgecallno, we need to lock it.
2). stop_stuff() which calls iax2_destroy_helper()
Assumes the lock on the pvt is already held, when iax2_destroy_helper() is called.
Thus we need to lock the bridgecallno pvt before we call stop_stuff(iaxs[fr->callno]->bridgecallno);
3). When evaluating the state of 'callno->transferring' of the current leg,
we can't change it to READY unless the bridgecallno is locked.
Why, if we are interrupted by the other call leg before 'transferring = TRANSFER_RELEASED',
the interrupt will find that it is READY and that the bridgecallno is also READY so Releases the legs.
(closes issue ASTERISK-21409)
Reported by: alecdavis
Tested by: alecdavis
alecdavis (license 585)
Review https://reviewboard.asterisk.org/r/2594/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@391062 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Check the returned bridged pointer for NULL to avoid a crash. It looks
like chan_agent is returning a NULL pointer when it probably should be
returning a pointer to the channel the Agent channel is pretending to be.
(closes issue ASTERISK-21793)
Reported by: Rodrigo P. Telles
Patches:
jira_asterisk_21793_v1.8.patch (license #5621) patch uploaded by rmudgett
Tested by: Rodrigo P. Telles
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@390044 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: Michael Walton
Tested by: Jonathan Rose
Patches:
slinfactory.c.ASTERISK-21799.patch uploaded by Michael Walton (license 6502)
(closes issue ASTERISK-21799)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@389895 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk shuts down and shuts down the loggin gsubsystem, any
messages currently in flight will not get logged. This patch prevents the
loop writing messages from breaking out prematurely, such that all of the
messages are logged.
(closes issue ASTERISK-21716)
Reported by: Corey Farrell
patches:
logger-process-all-messages.patch uploaded by Corey Farrell (license 5909)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@389676 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If DEBUG_THREADS is enabled __ast_rwlock_destroy causes a segfault while trying
to access a possible NULL t->track object. A NULL check has been added before
trying to access the memory.
(closes issue ASTERISK-21724)
Reported by: Corey Farrell
Fixed by: Corey Farrell
Patches:
ast_rwlock_destroy-segv.patch uploaded by Corey Farrell (license 5909)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@388838 65c4cc65-6c06-0410-ace0-fbb531ad65f3
AMI actions must never return non-zero unless they intend to close the AMI
connection. (Which is almost never.)
(closes issue ASTERISK-21779)
Reported by: Paul Goldbaum
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@388477 65c4cc65-6c06-0410-ace0-fbb531ad65f3
pbx_dundi added an io context without removing
it. This caused a memory leak when the module was
unloaded.
(closes ASTERISK-21718)
Reported by Corey Farrell
Patches:
pbx_dundi-ast_io_remove.patch uploaded by Corey Farrell (License #5909)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@388376 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When we send out a CN packet (for instance, in the case of using rtpkeepalives),
we are not setting the payload code properly. Also, we are setting the marker
bit when we shouldn't be according to RFC 3389, section 4.
AST_RTP_CN is not defined by AST_FORMAT codes. Therefore, we should be using
ast_rtp_codecs_payload_code() rather than ast_rtp_codecs_payload_lookup().
11 and trunk already use the appropriate function.
* In 1.8, use ast_rtp_codecs_payload_code()
* Remove the setting of the marker bit
* Fix the debug message by incrementing the seqno after the debug message is set
in order to display the correct seqno that was sent out
(closes issue ASTERISK-21246)
Reported by: Peter Katzmann
Tested by: Peter Katzmann, Michael L. Young
Patches:
asterisk-21246-rtp-cng-payload-error_1.8_v2.diff
uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2500/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@388111 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RFC6665 4.2.2: ... after a failed State NOTIFY transaction remove the subscription
The problem is that the State Notify requests rely on the 200OK reponse for pacing control
and to not confuse the notify susbsystem.
The issue is, the pendinginvite isn't cleared if a response isn't received,
thus further notify's are never sent.
The solution, follow RFC 6665 4.2.2's 'SHOULD' and remove the subscription after failure.
(closes issue ASTERISK-21677)
Reported by: Dan Martens
Tested by: Dan Martens, David Brillert, alecdavis
alecdavis (license 585)
Review https://reviewboard.asterisk.org/r/2475/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@387875 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reload support was originally not included for SLA. It was added later,
but in a fairly non-traditional way. It basically sets a flag
indicating that a reload is pending, and then waits for a time where it
thinks everything SLA related is idle and unused, and *then* executes
the reload. It does this because the reload process is destructive. It
starts by throwing everything away and starting over.
There are a number of problems with this approach. One of them is that
the check to see if anything in use was incomplete. This patch makes it
more complete and thus less likely for a crash to occur during reload
processing. However, this approach still has problems so some much more
significant reworking of this code will need to come in as a next step.
Patch credit and testing by CoreDial, LLC.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@387688 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Alec's patch that added the Asterisk version to 'core show locks' angered the
items in utils, as they exist somewhat outside of the Asterisk build system.
Some day, this Makefile should get nuked from high orbit, but for now, include
version.c in its list of stuff to pile in.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@387421 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RFC 4028 Section 10
if the side not performing refreshes does not receive a
session refresh request before the session expiration, it SHOULD send
a BYE to terminate the session, slightly before the session
expiration. The minimum of 32 seconds and one third of the session
interval is RECOMMENDED.
Prior to this asterisk would refresh at 1/2 the Session-Expires interval,
or if the remote device was the refresher, asterisk would timeout at interval end.
Now, when not refresher, timeout as per RFC noted above.
(closes issue ASTERISK-21742)
Reported by: alecdavis
Tested by: alecdavis
alecdavis (license 585)
Review https://reviewboard.asterisk.org/r/2488/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@387344 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RFC 4028 Section 7.2
"UACs MUST be prepared to receive a Session-Expires header field in a
response, even if none were present in the request."
What changed
After ASTERISK-20787, inbound calls to asterisk with no Session-Expires in the INVITE are now are offered
a Session-Expires (1800 asterisk default) in the response, with asterisk as the refresher.
Symptom:
After 900 seconds (asterisk default refresher period 1800), asterisk RE-INVITEs the device, the device
may respond with a much lower Session-Expires (180 in our case) value that it is now using.
Asterisk ignores this response, as it's deemed both an INBOUND CALL, and a RE-INVITE.
After 180 seconds the device times out and sends BYE (hangs up), asterisk is still working with the
refresher period of 1800 as it ignored the 'Session Expires: 180' in the previous 200OK response.
Fix:
handle_response_invite() when 200OK, remove check for outbound and reinvite.
(closes issue ASTERISK-21664)
Reported by: alecdavis
Tested by: alecdavis
alecdavis (license 585)
Review https://reviewboard.asterisk.org/r/2463/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@387312 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Lower bound of a 16bit signed int is -32768 not -32767
(closes issue ASTERISK-21744)
Reported by: alecdavis
Tested by: alecdavis
alecdavis (license 585)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@387297 65c4cc65-6c06-0410-ace0-fbb531ad65f3
