This is used to solve an issue where a poll on a file
descriptor does not necessarily correspond to the readiness
of a FILE handle to be read.
This change makes it so that for TCP connections, we do a
recv() on the file descriptor instead.
Because TCP does not guarantee that an entire message or even
just one single message will arrive during a read, a loop has
been introduced to ensure that we only attempt to handle a
single message at a time. The tcptls_session_instance structure
has also had an overflow buffer added to it so that if more
than one TCP message arrives in one go, there is a place to
throw the excess.
Huge thanks goes out to Walter Doekes for doing extensive review
on this change and finding edge cases where code could fail.
(closes issue ASTERISK-20212)
reported by Phil Ciccone
Review: https://reviewboard.asterisk.org/r/2123
........
Merged revisions 374905 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 374906 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 374914 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374924 65c4cc65-6c06-0410-ace0-fbb531ad65f3
During testing, it was discovered that having chan_sip
export global symbols was problematic.
The biggest problem was that load order was affected.
Trying to use realtime could be problematic since in
all likelihood the necessary realtime driver(s) would
not be loaded before chan_sip.
In addition, it was found that it was impossible to
use the Digium Phone Module for Asterisk since it
must be loaded before chan_sip since it must hook
into chan_sip's configuration parsing.
The solution is to use a virtual table in the same
manner that other modules in Asterisk do, like
app_voicemail.
(closes issue ASTERISK-20545)
Reported by: kmoore
........
Merged revisions 374842 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374849 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
................
r374515 | rmudgett | 2012-10-04 17:52:36 -0500 (Thu, 04 Oct 2012) | 10 lines
chan_misdn: Remove some deadcode
* Made setup_bc() static.
Patches:
patch1_unused-code.diff (license #6372) patch uploaded by Guenther Kelleter
Modified
JIRA ABE-2882
................
r374516 | rmudgett | 2012-10-04 18:01:01 -0500 (Thu, 04 Oct 2012) | 7 lines
chan_misdn: Remove unused bchan states
Patches:
patch2_unused-states.diff (license #6372) patch uploaded by Guenther Kelleter
JIRA ABE-2882
................
r374517 | rmudgett | 2012-10-04 18:17:51 -0500 (Thu, 04 Oct 2012) | 16 lines
chan_misdn: Remove unnecessary null pointer checks and checks for stack->nt
* cleanup_bc() is always called with valid bc (or it would've crashed
before).
* Value of stack->nt is known in advance at some places.
* Rename handle_event() to handle_event_te(), handle_frm() to
handle_frm_te().
Patches:
patch3_checks.diff (license #6372) patch uploaded by Guenther Kelleter
Modified
JIRA ABE-2882
................
r374518 | rmudgett | 2012-10-04 18:21:59 -0500 (Thu, 04 Oct 2012) | 7 lines
chan_misdn: Fix spelling in log messages
Patches:
patch4_spelling.diff (license #6372) patch uploaded by Guenther Kelleter
JIRA ABE-2882
................
r374519 | rmudgett | 2012-10-04 18:31:59 -0500 (Thu, 04 Oct 2012) | 15 lines
chan_misdn: Don't cleanup a bc twice.
In handle_frm_te() after calling misdn_lib_send_event(bc,
EVENT_RELEASE_COMPLETE) bc is emptied, cleaned and set not in use,
although misdn_lib_send_event() already did the same. This is bad. When
it's not in use we are not allowed to touch it.
* Moved log message in front of the resulting actions and fixed it to
match the case.
Patches:
patch5_bccleanup.diff (license #6372) patch uploaded by Guenther Kelleter
JIRA ABE-2882
................
r374520 | rmudgett | 2012-10-04 18:43:56 -0500 (Thu, 04 Oct 2012) | 12 lines
chan_misdn: Fix memory leaks, bc, chan not cleaned up etc., really bad stuff.
* Fix return codes of cb_events() for EVENT_SETUP to use caller's cleanup
mechanisms.
* Move cl_queue_chan() call after bearer check.
Patches:
patch6_leaks.diff (license #6372) patch uploaded by Guenther Kelleter
JIRA ABE-2882
................
r374521 | rmudgett | 2012-10-04 18:48:38 -0500 (Thu, 04 Oct 2012) | 11 lines
chan_misdn: We must initialize cause on sending a DISCONNECT.
We must initialize cause on sending a DISCONNECT, so it is later correctly
indicated to ast_channel in case the answer (RELEASE/RELEASE_COMPLETE)
does not include one.
Patches:
patch7_hangupcause.diff (license #6372) patch uploaded by Guenther Kelleter
JIRA ABE-2882
................
r374522 | rmudgett | 2012-10-04 19:03:56 -0500 (Thu, 04 Oct 2012) | 7 lines
chan_misdn: Remove unused code for upqueue
Patches:
patch8_unused-upqueue.diff (license #6372) patch uploaded by Guenther Kelleter
JIRA ABE-2882
................
r374523 | rmudgett | 2012-10-04 19:11:50 -0500 (Thu, 04 Oct 2012) | 7 lines
chan_misdn: Improve debugging (port number, messages fixed, dups removed)
Patches:
patch9_debug.diff (license #6372) patch uploaded by Guenther Kelleter
JIRA ABE-2882
................
r374533 | rmudgett | 2012-10-05 12:17:18 -0500 (Fri, 05 Oct 2012) | 8 lines
chan_misdn: Better debug: we can print_bc_info even if there's no ast leg.
Patches:
patch10_debug-bc-2.diff (license #6372) patch uploaded by Guenther Kelleter
Modified.
JIRA ABE-2882
................
r374534 | rmudgett | 2012-10-05 12:34:10 -0500 (Fri, 05 Oct 2012) | 16 lines
chan_misdn: setup_bc() is called too early for an incoming SETUP on TE.
This prevents the B channel from being setup for HDLC mode when requested
by the bearer capability and config option hdlc=yes. It violates
ETS300102 Ch.5.2.3.2: "The user, in any case, must not connect to the
channel until a CONNECT ACKNOWLEDGE message has been received."
* Call setup_bc() on receipt of CONNECT_ACKNOWLEGDE for PTMP, and on first
response to SETUP for PTP.
Patches:
abe-2881-2.diff (license #6372) patch uploaded by Guenther Kelleter
Modified.
JIRA ABE-2881
................
r374535 | rmudgett | 2012-10-05 12:41:05 -0500 (Fri, 05 Oct 2012) | 2 lines
chan_misdn: Remove some more deadcode.
................
........
Merged revisions 374536 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 374537 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 374538 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374539 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* The following dialplan applications now recognize 'W' to pause sending
DTMF for one second in addition to the previously existing 'w' that paused
sending DTMF for half a second. Dial, ExternalIVR, and SendDTMF.
* The chan_dahdi analog port dialing and deferred DTMF dialing for PRI now
distinguishes between 'w' and 'W'. The 'w' pauses dialing for half a
second. The 'W' pauses dialing for one second.
* Created dahdi_dial_str() in chan_dahdi that eliminated a lot of
duplicated dialing code and diagnostic messages for the channel driver.
(closes issue ASTERISK-20039)
Reported by: Jeremiah Gowdy
Patches:
jgowdy-wait-6-22-2012.diff (license #5621) patch uploaded by Jeremiah Gowdy
Expanded patch to add support in chan_dahdi.
Tested by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374030 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Users of the T.38 API can indicate AST_T38_REQUEST_PARMS on a channel to request that the
channel indicate a T.38 negotiation with the parameters present on the channel. The return
value of this indication is expected to be AST_T38_REQUEST_PARMS upon success but with
chan_local involved this could never occur.
This fix changes chan_local to always return AST_T38_REQUEST_PARMS for this situation. If
the underlying channel technology on the other side does not support T.38 this would have
been determined ahead of time using ast_channel_get_t38_state and an indication would
not occur.
(closes issue ASTERISK-20229)
Reported by: wdoekes
Patches:
ASTERISK-20229.patch uploaded by wdoekes (license 5674)
Review: https://reviewboard.asterisk.org/r/2070/
........
Merged revisions 373705 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 373706 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 373707 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373708 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This allows for the REDIRECTING dialplan function to be
used to set the reason to any string.
The SIP channel driver has been modified to set the redirecting
reason string to the value received in a Diversion header. In
addition, SIP 480 response reason text will set the redirecting
reason as well.
(closes issue AST-942)
reported by Malcolm Davenport
(closes issue AST-943)
reported by Malcolm Davenport
Review: https://reviewboard.asterisk.org/r/2101
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373701 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The SIP session timer mechanism contains a mandatory 'refresher' parameter
(included in the Session-Expires header) which is used in the session timer
offer/answer signaling within a SIP Invite dialog. It looks like asterisk is
interpreting the uac resp. uas role only as the initial role of client and
server (caller is uac, callee is uas). The standard rfc 4028 however assigns
the client role to the ((RE)-Invite) requester, the server role to the
((RE)-Invite) responder.
This patch has Asterisk track the actual refresher as "us" or "them" as opposed
to relying on just the configured "uas" or "uac" properties.
(closes issue AST-922)
Reported by: Thomas Airmont
Review: https://reviewboard.asterisk.org/r/2118/
........
Merged revisions 373652 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 373665 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 373690 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373691 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When setting CALLERID(pres)=unavailable in the dialplan, the From header
in the SIP message contains "Anonymous" <sip:Anonymous@anonymous.invalid>.
For consistency, Asterisk should use a lowercase a in the userpart of the
URI.
* Make the From header use a lowercase A in the userpart of the anonymous
URI.
(closes issue ASTERISK-19838)
Reported by: Antti Yrjola
Patches:
chan_sip_patch_ASTERISK-19838.patch (license #6383) patch uploaded by Antti Yrjola
........
Merged revisions 373500 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 373501 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 373502 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373503 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk v1.8 and later was not as vulnerable to this issue.
* Made find_call() lock each private as it processes the found dialogs.
(Primary cause of ABE-2876)
* Made the other functions that traverse the dialogs container lock each
private as it examines them.
* Fix race condition in sip_call() if the thread that sent the INVITE is
held up long enough for a response to be processed. The p->initid for the
INVITE retransmission could be added after it was canceled by the response
processing.
* Made __sip_destroy() clean up resource pointers after freeing. This is
primarily defensive in case someone has a stale private pointer.
* Removed redundant memset() in reqprep(). The call to init_req() already
does the memset() and is the first reference to req in reqprep().
* Removed useless set of req.method in transmit_invite(). The calls to
initreqprep() and reqprep() have to do this because they memset() the req.
JIRA ABE-2876
..........
Merged -r373423 from https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
........
Merged revisions 373424 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 373466 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 373469 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373471 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If conditions were right it was possible for both the PBX core and chan_sip to deadlock by both having a lock that the other
wants. In the case of the PBX core it had the contexts lock and wanted a SIP dialog lock, while in the case of chan_sip it
had the SIP dialog lock and wanted the contexts lock.
This fix unlocks the SIP dialog before getting the extension state so that the other thread will not block on trying to lock
it. Once the extension state is retrieved the SIP dialog is locked again and life carries on.
As the SIP dialog is reference counted it is not possible for it to go away after unlocking.
(closes issue ASTERISK-20437)
Reported by: jhutchins
........
Merged revisions 373438 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 373440 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 373454 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373456 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The H.264 format attribute module compares two format attribute structures to determine if they are
compatible or not. In some instances it was possible for this check to determine that both structures
were incompatible when they actually should be considered compatible. This check has now been made even
more permissive by assuming that if no attribute information is available the two structures are compatible.
If both structures contain attribute information a base level comparison of the H.264 IDC value is done to
see if they are compatible or not.
The above issue uncovered a secondary issue in chan_sip where the SDP being produced would be incorrect if
the formats were considered incompatible. This has now been fixed by checking that all information required
to produce the SDP is available instead of assuming it is.
(closes issue ASTERISK-20464)
Reported by: Leif Madsen
........
Merged revisions 373413 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373414 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Whitespace, doc-blocks, spelling, case, missing and incorrect tags.
* Add cleanup to Makefile for the Doxygen configuration update
* Start updating Doxygen configuration for cleaner output
* Enable inclusion of configuration files into documentation
* remove mantisworkflow...
* update documentation README
* Add markup to Tilghman's email and talk with him about updating his email, he knows...
* no code changes on this commit other than the mentioned Makefile change
(issue ASTERISK-20259)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373384 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Doxygen updates including mistakes, misspellings, missing parameters, updates for Doxygen style. Some missing txt file links are removed but their content or essense will be included in some later updates. A majority of the txt files were removed in the 1.6 era but never noted. The HR and EXTREF are simple changes that make the documentation more compatable with more versions of Doxygen.
Further updates coming.
(issue ASTERISK-20259)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373330 65c4cc65-6c06-0410-ace0-fbb531ad65f3
As mentioned on the review for this, WebRTC has moved towards choosing
DTLS-SRTP as the mechanism for key exchange for SRTP. This commit adds
support for this but makes it available for normal SIP clients as well.
Testing has been done to ensure that this introduces no regressions with
existing behavior and also that it functions as expected.
Review: https://reviewboard.asterisk.org/r/2113/
........
Merged revisions 373229 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373234 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the patch to handle arbitrary SDP stream arrangements went into
Asterisk, it also included an ability to transparently decline unknown
stream types. The scanf calls used were not checked properly causing
this part of the functionality to be broken.
(closes issue ASTERISK-20203)
........
Merged revisions 373211 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373212 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For SS7, the companding law for a call was chosen inconsistently depending
upon ss7type (ITU vs ANSI) and the DAHDI companding default (T1 vs E1).
For incoming calls, the companding law was determined by ss7type. For
outgoing calls, the companding law was determined by the DAHDI default.
With the wrong combination you would get A-law/u-law conflicts. An
A-law/u-law conflict sounds like bad static on the line.
SS7 ITU signaling with E1 line: ok
SS7 ITU signaling with T1 line: noise
SS7 ANSI signaling with E1 line: noise
SS7 ANSI signaling with T1 line: ok
* Fix the companding law used to be determined by the SS7 signaling type
only.
........
Merged revisions 373090 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 373101 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 373107 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373108 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch resolves two sources of memory leaks when using TLS in Asterisk:
1) It removes improper initialization (and multiple re-initializations) of
portions of the SSL library. Asterisk calls SSL_library_init and
SSL_load_error_strings during SSL initialization; collectively this
obviates the need for calling any of the following during initialization
or client connection handling:
* ERR_load_crypto_strings (handled by SSL_load_error_strings)
* OpenSSL_add_all_algorithms (synonym for SSL_library_init)
* SSLeay_add_ssl_algorithms (synonym for SSL_library_init)
2) Failure to completely clean up all memory allocated by Asterisk and by
the SSL library for TLS clients. This included not freeing the SSL_CTX
object in the SIP channel driver, as well as not clearing the error
stack when the TLS client exited.
Note that these memory leaks were found by Thomas Arimont, and this patch
was essentially written by him with some minor tweaks.
(closes issue AST-889)
Reported by: Thomas Arimont
Tested by: Thomas Arimont
patches:
(bugAST-889.patch) by Thomas Arimont (license 5525)
Review: https://reviewboard.asterisk.org/r/2105
........
Merged revisions 373061 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 373062 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 373079 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373080 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, The acknowledgement wasn't produced until after
executing the sip_poke_peer action actually responsible for
qualifying the peer. Now the response is given immediately once it is
known that a peer will be qualified and a SIPqualifypeerdone event
is issued when the process is finished. Thanks to OEJ for identifying
the problem and helping to come up with a solution.
(issue AST-969)
Reported by John Bigelow
Review: https://reviewboard.asterisk.org/r/2098/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372808 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r356604, SRTP handling was fixed to accomodate multiple crypto keys in an
SDP offer and the ability to re-create an SRTP session when the crypto keys
changed. In certain circumstances - most notably when a phone is put on
hold after having been bridged for a significant amount of time - the act
of re-creating the SRTP session causes problems for certain models of phones.
The patch committed in r356604 always re-created the SRTP session regardless
of whether or not the cryptographic keys changed. Since this is technically
not necessary, this patch modifies the behavior to only re-create the SRTP
session if Asterisk detects that the remote key has changed. This allows
models of phones that do not handle the SRTP session changing to continue
to work, while also providing the behavior needed for those phones that do
re-negotiate cryptographic keys.
(issue ASTERISK-20194)
Reported by: Nicolo Mazzon
Tested by: Nicolo Mazzon
Review: https://reviewboard.asterisk.org/r/2099
........
Merged revisions 372709 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 372710 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 372711 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372712 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Using the AMI redirect action to take an ISDN call out of a parking lot
causes the MOH state to get confused. The redirect action does not take
the call off of hold. When the call is subsequently parked again, the
call no longer hears MOH.
* Make chan_dahdi/sig_pri restart MOH on repeated AST_CONTROL_HOLD frames
if it is already in a state where it is supposed to be sending MOH. The
MOH may have been stopped by other means. (Such as killing the generator.)
This simple fix is done rather than making the AMI redirect action post an
AST_CONTROL_UNHOLD unconditionally when it redirects a channel and thus
potentially breaking something with an unexpected AST_CONTROL_UNHOLD.
(closes issue ABE-2873)
Patches:
jira_abe_2873_c.3_bier.patch (license #5621) patch uploaded by rmudgett
........
Merged revisions 372521 from https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
........
Merged revisions 372522 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 372523 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372524 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to 1.8, it was not necessary for an explicit "type" to be set for an
asterisk LDAP realtime peer. Now the routine find_peer actually checks the
type field during registration and fails to find the peer if it is not set.
The attached patch makes the realtime type equal whatever type is being
searched for if the type is 0 upon return from routine build_peer.
(closes issue ASTERISK-17222)
Reported by: John Covert
Patch by: David Vossel
Tested by: Darren Sessions
Review: https://reviewboard.asterisk.org/r/2095/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372290 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The problem had to do with logic used when checking for what the oldest ringing channel
was. The problem was that if no channel was found, then no notification would be sent.
For custom device states, there is no associated channel, so no notification would get
sent. This fixes the issue by still sending the notification even if no associated
channel can be found for a ringing device state change.
(closes issue ASTERISK-20297)
Reported by Noah Engelberth
........
Merged revisions 372137 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372138 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When an IAX2 call is made using the credentials of a peer defined in a dynamic
Asterisk Realtime Architecture (ARA) backend, the ACL rules for that peer are
not applied to the call attempt. This allows for a remote attacker who is aware
of a peer's credentials to bypass the ACL rules set for that peer.
This patch ensures that the ACLs are applied for all peers, regardless of their
storage mechanism.
(closes issue ASTERISK-20186)
Reported by: Alan Frisch
Tested by: mjordan, Alan Frisch
........
Merged revisions 372028 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372029 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes numerous doxygen warnings across Asterisk. It also updates
the makefile to regenerate the doxygen configuration on the local system
before running doxygen to help prevent warnings/errors on the local system.
Much thanks to Andrew for tackling one of the Asterisk janitor projects!
(issue ASTERISK-20259)
Reported by: Andrew Latham
Patches:
doxygen_partial.diff uploaded by Andrew Latham (license 5985)
make_progdocs.diff uploaded by Andrew Latham (license 5985)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371989 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Matt Jordan informed me that it was more appropriate to use an
astman_send_ack here instead of making an event response. I've also
used this opportunity to update UPGRADE.txt to mention this change
in behavior.
(issue AST-969)
Reported by: John Bigelow
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371889 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, Issuing SIPqualifypeer either resulted in an
error or if it succeeded, a few \r\ns. This patch adds a
SIPqualifypeerComplete event issued as a response when the command
is successfully executed.
(closes issue AST-969)
Reported by: John Bigelow
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371823 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Mark Michelson
Joshua Colp
Richard Mudgett
Matthew Jordan
Andrew Latham
Terry Wilson
Jonathan Rose
Kinsey Moore
Darren Sessions