Greenlight in #asterisk brought up that he was receiving an error message "Could
not create persistent member string, out of space" when running app_queue in
Asterisk 10. dump_queue_members() made an assumption that 8K would be enough to
store the generated string, but with queues that have large member lists this is
not always the case. This patch removes the limitation and uses ast_str instead
of a fixed sized buffer.
The complicating factor comes from the fact that ast_db_get requires a buffer
and buffer size argument, which doesn't let us pull back more than what we pass
in, so I introduced a new ast_db_get_allocated() which returns an ast_strdup()'d
copy of the value from astdb.
As an aside, I did some testing on the maximum size of data that we can store in
the BDB library we distribute and was able to store a 10MB string and retrieve
it with no problems, so I feel this is a safe patch.
Review: https://reviewboard.asterisk.org/r/2136/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@374108 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The opinion of development was that it is both improper to have Matt's
personal email address used in the source and that the command wouldn't
be useful without it.
(closes issue AST-467)
Reported by: Malcolm Davenport
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@374032 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The SendDTMF channel name parameter has two issues.
1) Crashes if the channel name does not exist.
2) Leaks a channel reference if the channel is the current channel.
Problem introduced by ASTERISK-15956.
* Updated SendDTMF documentation.
* Renamed app to senddtmf_name and tweaked the type.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373945 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If an Asterisk module specifies a dependency in ast_module_info.nonoptreq, it
is possible for Asterisk to skip calling the modules's .load function.
Asterisk was loading and linking the module via load_dynamic_module() but was
not adding the module to the resource_heap. Therefore the module was not
initialized based on it's priority along with the other modules in the heap.
Now use load_resource() instead of load_dynamic_module() for non-optional
requirement. This will add the module to the resource_heap so the module can
be properly initialized in the correct order.
This is required if there are any module global data structures initialized in
the .load() callback for the module on platforms which do not support weak
references.
(issue ASTERISK-20439)
Reported by: sruffell
Patches:
0001-loader-Ensure-dependent-modules-are-properly-initial.patch uploaded by sruffell (license 5417)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373909 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The chan_local channel driver returns a device state of in use even if a created Local
channel has not yet been dialed. This fix changes the logic to return a state of not
in use until the channel itself has been dialed.
(closes issue ASTERISK-20390)
Reported by: tim_ringenbach
Review: https://reviewboard.asterisk.org/r/2116/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373878 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Removed unnecessary case sensitivity in meetme list, lock, unlock, mute,
unmute, and kick commands.
* Separated meetme lock/unlock, mute/unmute, and kick commands into their
own registered commands to simplify tab completion and parameter checking.
meetme_lock_cmd(), meetme_mute_cmd(), and meetme_kick_cmd()
* Simplified meetme_show_cmd()
(closes issue AST-1006)
Reported by: John Bigelow
Tested by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373815 65c4cc65-6c06-0410-ace0-fbb531ad65f3
multiplelogin was removed from chan_agent back in 1.6.0 when
AgentCallbackLogin() was removed.
(closes issue AST-948)
reported by Steve Pitts
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373768 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(closes issue ASTERISK-20435)
Reported by: fhackenberger
Patches:
asterisk-20435-imap-del-greeting.diff uploaded by Michael L. Young (License #5026)
(with suggested modification made by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373735 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/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373705 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When tab-completing CLI commands starting with "queue", "show" appeared
twice in the list due to the way that Asterisk's tab completion
functions and the order in which the commands were registered. The
registration order has been altered to resolve this issue.
(closes issue AST-940)
Reported-by: Steve Pitts
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373666 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/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373652 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Valgrind found codec_ilbc using memcpy instead of memmove for overlapping
memory blocks.
(issue ASTERISK-19890)
(closes issue ASTERISK-20231)
Reported by: Walter Doekes
Patches:
ASTERISK-20231.patch (license #5674) patch uploaded by Walter Doekes
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373640 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This was previously stated to be "root", but is actually the name of
the context if unspecified.
(closes issue ASTERISK-20258)
Reported by: Stefan x
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373578 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When sending RTP packets via multicast the amount of data sent is stored in a variable and returned
from the write function. This is incorrect as any non-zero value returned is considered a failure while
a return value of 0 is success. For callers (such as ast_streamfile) that checked the return value
they would have considered it a failure when in reality nothing went wrong and it was actually a success.
The write function for the multicast RTP engine now returns -1 on failure and 0 on success, as it should.
(closes issue ASTERISK-17254)
Reported by: wybecom
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373550 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The change committed in r373236 attempted to account for endpoints that
increased their RTP timestamp in DTMF end of event re-transmissions. This
change attempted to make Asterisk continue to work with endpoints that
failed to follow the RFC while maintaining the fix that allowed for out of
order DTMF to be handled. Unfortunately, there is no free lunch, and this
patch broke any system that sent DTMF immediately after an RTP session was
established or when an SSRC is updated. As such, that patch is being
reverted for the previous behavior.
Endpoints that erroneously increase the RTP timestamp in DTMF end of event
packets will not work properly with Asterisk.
(issue ASTERISK-20424)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373504 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373500 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373438 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373424 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, 'queue reload members' cli command did not
work at all. This also affects the manager function 'QueueReload'
when supplied with the 'members: yes' field.
(closes issue AST-956)
Reported by: John Bigelow
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373298 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When using the 'e' or 'E' option to MeetMe the configured conference bridges are loaded and examined to see
if any are empty. If no conference bridges are empty the caller is prompted to enter the number of one.
This operation left around a pointer to the last created conference bridge still containing participants.
When the caller that was not able to find any empty conference bridge hung up this pointer was disposed of
and the reference count of the conference bridge decremented. If there was only a single participant in the
conference bridge it was ultimately destroyed prematurely.
(closes issue AST-994)
Reported by: John Bigelow
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373242 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While endpoints should not be changing the source timestamp between DTMF event
packets, the fact is there exists those endpoints that do exactly that. To
work around this, we absorb timestamps within the expected re-transmit period.
Note that this period only affects End of Event packets, so it should not
prevent the detection of new DTMF digits that happen to arrive right on top
of each other.
(closes issue ASTERISK-20424)
Reported by: Vladimir Mikhelson
Tested by: mjordan, Vladimir Mikhelson
Review: https://reviewboard.asterisk.org/r/2124
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373236 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A change was committed to fix direct media ACL support. This change wrongly assumed that
only a single channel technology structure exists for chan_sip. This is in fact false as
a second exists for calls using SIP INFO DTMF. The code which performs direct media ACL
checking now checks for both the non-INFO DTMF and INFO DTMF channel technology structures.
(closes issue ASTERISK-20409)
Reported by: michele cicciotti privatewave
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373165 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Before this commit, __astman_get_header would blindly dereference the passed in
'struct message *' to traverse the header list. There are cases, however, such
as '*CLI> sip qualify peer foo' where the message pointer is NULL, so we need
to check for that.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373131 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.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373090 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373061 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_waitfordigit_full would simply pass its timeout to ast_waitfor_nandfds,
expecting it to decrement the timeout by however many milliseconds were
waited. This is a problem if it consistently waits less than 1ms. The timeout
will never be decremented, and we wait... FOREVER!
This patch makes ast_waitfordigit_full manage the timeout itself. It maintains
the previously undocumented behavior that negative timeouts wait forever.
(closes issue ASTERISK-20375)
Reported by: Mark Michelson
Tested by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/2109/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373024 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When REF_DEBUG is enabled in certain files - most notably ccss.c - the 'tag'
parameter passed to __ao2_ref_debug will be a const char *. The function
currently expects that parameter to not be const. This causes a warning
when compiling, as the const qualifier is being discarded. With dev-mode
enabled, this prevents compiling Asterisk.
This patch makes __ao2_ref_debug's tag and file parameters const.
(closes issue ASTERISK-20408)
Reported by: mjordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372959 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The "autodestruct with owner in place" message is typically
indicative of a channel reference leak. Printing out the name
of the channel in the message may be helpful when trying to
debug the issue.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Changes chan_local channels to use an 8 digit hex identifier generated
atomically and sequentially in order to eliminate the chance of having
multiple channels with the same name during high call volume situations.
(issue ASTERISK-20318)
Reported by: Dan Cropp
Review: https://reviewboard.asterisk.org/r/2104/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372902 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When channels get bridged due to an AMI bridge action
or a DTMF attended transfer, the two channels that
get bridged have their application data pointing to
the other channel's name. This means that if one channel
is hung up but the other moves on, it means that the
channel that moves on will have its application data
pointing at freed memory.
(issue ASTERISK-20335)
Reported by: aragon
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372840 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When IAX2 debug was changed from iax_showframe to iax_outputframe,
some instances were missed (or added afterward). This was causing
debug output to not be displayed when expected.
(closes issue ASTERISK-20338)
Reported-by: John Covert
Patch-by: John Covert
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372804 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds a CLI warning when a SDP offer is rejected due to UDPTL
initialization failure. Previously, there was no indication of the
reason for offer rejection in this case.
(closes issue ASTERISK-20357)
Reported-by: Francesco Usseglio Gaudi
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372763 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, the user would have a parkinglot set on a channel that
was parked and when the channel was retrieved, any attempt by that channel
to park would simply use the default. This patch makes parkinglot values
set in this way be retained through the masquerade.
(closes issue AST-990)
Reported by: Nick Huskinson
Patches:
masquerade_parkinglot_patch.diff Uploaded by Jonathan Rose (license 6182)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372736 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.
In addition, in Asterisk 1.8 only, it was found that phones that offer
AES_CM_128_HMAC_SHA1_32 will end up with no audio if the phone is the
initiator of the call. The phone will send an INVITE request specifying
that AES_CM_128_HMAC_SHA1_32 be used for the cryptographic policy; Asterisk
will set its policy to that value. Unfortunately, when the call is Answered
and a 200 OK is sent back to the UA, the policy sent in the response's SDP
will be the hard coded value AES_CM_128_HMAC_SHA1_80. This potentially
results in Asterisk using the INVITE request's policy of
AES_CM_128_HMAC_SHA1_32, while the phone uses Asterisk's response of
AES_CM_128_HMAC_SHA1_80. Hilarity ensues as both endpoints think the other
is crazy.
This patch fixes that by caching the policy from the request and responding
with it. Note that this is not a problem in Asterisk 10 and later, as the
ability to configure the policy was added in that version.
(issue ASTERISK-20194)
Reported by: Nicolo Mazzon
Tested by: Nicolo Mazzon
Review: https://reviewboard.asterisk.org/r/2099
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372709 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Without this flag, those files will compile with the system installed
OpenSSL headers (if they exist). This is a real bummer if a different
path was specified using --with-ssl=
(closes issue ASTERISK-20392)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372682 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The AMI action VoicemailUsersList VoicemailUserEntry event headers
ServerEmail and MailCommand did not report the global values if they were
not overridden. The VoicemailUserEntry event header ServerEmail was not
populated with the global value if the voicemail user did not override it.
The VoicemailUserEntry event header MailCommand was never populated with a
value.
* Removed unused struct ast_vm_user member mailcmd[].
(closes issue AST-973)
Reported by: John Bigelow
Tested by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372620 65c4cc65-6c06-0410-ace0-fbb531ad65f3
