This patch adds a new CLI command to the res_corosync module. It is primarily
used as a debugging tool. It lets you fire off an event which will cause
res_corosync on other nodes in the cluster to place messages into the logger if
everything is working ok. It verifies that the corosync communication is
working as expected.
I didn't put anything in the CHANGES file for this, because this module is new
in Asterisk 11. There is already a generic "res_corosync new module" entry in
there so I figure that covers it just fine.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370535 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The while loop responsible for reading AGI messages from a fastAGI service
can end up looping indefinitely when an AGI script fails to indicate the end
of a message with a \n character. This patch adds an indication that we are
expecting a \n character to end the message to make it more clear to users
that this is necessary if they are receiving this warning over and over.
(issue ASTERISK-20061)
Reported by: Eike Kuiper
........
Merged revisions 370494 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 370495 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370510 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A number of applications/AMI commands in Asterisk have specific behavioral
differences depending on the resource or channel technology those
applications are executed on. For example, the MessageSend application/
command is technology agnostic, but how the channel drivers that support
that functionality behave is dependant on the protocols and channel
driver implementation. Prior to this patch, those details were either
documented in the application/command documentation itself, or were left
undocumented.
This patch adds a new element to the documentation schema, <info/>. An info
node is essentially a piece of technology specific reference information that
can be included by any top level XML documentation node. For example, the
MessageSend application can now include XMPP/SIP specific information, where
that technology specific information can be defined in chan_motif/res_xmpp/
chan_sip. Likewise, that information can also be included in the MessageSend
AMI command.
Review: https://reviewboard.asterisk.org/r/2049
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370278 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The current implementation of RFC 2833 DTMF handling in res_rtp_asterisk will,
if a packet arrives out of order, drop the packet. This is to prevent
duplicate ton generation in the Asterisk core. Since the RTP layer does not
buffer data itself, this is the only option the RTP layer currently has for
handling packets that arrive out of order.
For the most part, this doesn't matter. For a particular digit, so long as a
BEGIN packet arrives before the first END packet, the digit will be produced.
If subsequent BEGIN packets arrive interleaved with the ENDs, they will be
dropped; likewise, if the BEGIN or END packets themselves are out of order,
those packets are dropped but sufficient information is conveyed to the
Asterisk core to produce the appropriate digit.
For certain sequences of DTMF packets - most notably when, for a particular
digit, an END packet arrives before any BEGIN packet for that digit - this
is a real problem. When an END arrives before any BEGINs, the END packet is
dropped - but at the same time, it causes subsequent BEGIN packets for that
digit to be ignored. When the next in order END packet arrives, it too is
dropped - Asterisk believes that there was no initial BEGIN.
The solution this patch provides is to trust the END packet to convey the
information needed for the Asterisk core to produce the DTMF digit. If we
receive an END packet, and it:
* Has a timestamp greater then the last timestamp received from an END
packet
* Does not have the same sequence number as the last received sequence
number (and is thus not an END packet retransmission)
Then we send the END frame up to the Asterisk core. It contains enough
DTMF information for Asterisk to produce the digit.
On the other hand, if we receive a BEGIN or continuation packet that occurs
with a timestamp equal to or less then the last END timestamp, then we've
received something out of order - but we already have received enough
information to produce the digit. These packets are dropped.
Much thanks goes to Olle Johansson (oej) for providing the idea for this
solution.
Review: https://reviewboard.asterisk.org/r/2033/
(closes issue ASTERISK-18404)
Reported by: Stephane Chazelas
Tested by: Matt Jordan
........
Merged revisions 370252 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 370271 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370272 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The initial ICE connectivity check is scheduled as a timer item that is to be executed immediately. It is possible for this timer item to start executing while the ICE session it is working on is destroyed. To reduce the chance of this any timer items that need to be immediately executed will be executed within the thread that has started the initial ICE connectivity check.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370177 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The pubsub code did not attempt to remove subscriptions at all. This has now changed so that if a client is being disconnected it will unsubscribe. It will also unsubscribe at connection time so if it unexpectedly disconnected duplicate subscriptions will not occur.
(closes issue ASTERISK-19882)
Reported by: mattvryan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370157 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The MWI and device state propagation code wrongly assumes that an XMPP client connection will remain established at all times. This fix corrects that by making the lifetime of the subscription the same as the lifetime of the connection itself. As the connection is established and disconnected the subscription itself is created and destroyed.
(closes issue ASTERISK-18078)
Reported by: elguero
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370152 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A server sending a service discovery request to us may or may not put a from attribute in the message. If the from attribute is present use it in the to attribute for the result. If the from attribute is not present do not add a to attribute.
(issue ASTERISK-16203)
Reported by: wubbla
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370126 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds legacy STUN support for RTCP sockets, adds RTCP candidates to the Google transport information, and adds required codec parameters.
(closes issue ASTERISK-20106)
Reported by: Malcolm Davenport
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369864 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The STUN packets should *not* be blocked by strict RTP.
(closes issue ASTERISK-20102)
Reported by: Malcolm Davenport
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369817 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This channel driver is a replacement for both chan_gtalk and chan_jingle but adds additional features not found in either.
These features include full configuration reload, video, full codec support, bidirectional cause code mapping, hold,
unhold, and ringing indication. It is also compliant with the current published Jingle and Google Jingle specifications.
The original Google Talk protocol is also supported for Google Voice interoperability.
You may ask yourself though where the name motif comes from... and I would say to you... music!
motif: a perceivable or salient recurring fragment or succession of notes
Sorta like a jingle!
Review: https://reviewboard.asterisk.org/r/1917/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369769 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a new CLI command, 'stun show status'. This command will show
a table describing all known STUN servers and statuses.
(closes issue ASTERISK-18046)
Reported by: Jeremy Kister
Tested by: Jeremy Kister
patches:
(stun-show-status-v4-trunk.patch license #6232 uploaded by Jeremy Kister)
Review: https://reviewboard.asterisk.org/r/2001
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369681 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r369001 | kpfleming | 2012-06-15 10:56:08 -0500 (Fri, 15 Jun 2012) | 11 lines
Add support-level indications to many more source files.
Since we now have tools that scan through the source tree looking for files
with specific support levels, we need to ensure that every file that is
a component of a 'core' or 'extended' module (or the main Asterisk binary)
is explicitly marked with its support level. This patch adds support-level
indications to many more source files in tree, but avoids adding them to
third-party libraries that are included in the tree and to source files
that don't end up involved in Asterisk itself.
........
r369002 | kpfleming | 2012-06-15 10:57:14 -0500 (Fri, 15 Jun 2012) | 3 lines
Add a script to enable finding source files without support-levels defined.
........
Merged revisions 369001-369002 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 369005 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369013 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Recently, various issues surrounding weak symbols have caused problems with
modules that rely on that feature to be enabled in menuselect. This includes
app_voicemail and chan_dahdi, as they both rely upon res_smdi and res_adsi,
which, in certain circumstances, may not be enabled by default in menuselect.
Because res_smdi/res_adsi are dependencies for chan_dahdi/app_voicemail, this
patch marks both as 'core' supported modules. This will allow both
app_voicemail and chan_dahdi to be enabled as well, regardless of whether or
not that system supports weak symbols.
(issue AST-900)
Reported by: Thomas Arimont
(issue AST-885)
Reported by: Denis Alberto Martinez
........
Merged revisions 368894 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 368895 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368896 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses a number of memory leaks in a variety of modules that were
found by a static analysis tool. A brief summary of the changes:
* app_minivm: free ast_str objects on off nominal paths
* app_page: free the ast_dial object if the requested channel technology
cannot be appended to the dialing structure
* app_queue: if a penalty rule failed to match any existing rule list
names, the created rule would not be inserted and its memory
would be leaked
* app_read: dispose of the created silence detector in the presence of
off nominal circumstances
* app_voicemail: dispose of an allocated unique ID field for MWI event
un-subscribe requests in off nominal paths; dispose of
configuration objects when using the secret.conf option
* chan_dahdi: dispose of the allocated frame produced by ast_dsp_process
* chan_iax2: properly unref peer in CLI command "iax2 unregister"
* chan_sip: dispose of the allocated frame produced by sip_rtp_read's
call of ast_dsp_process; free memory in parse unit tests
* func_dialgroup: properly deref ao2 object grhead in nominal path of
dialgroup_read
* func_odbc: free resultset in off nominal paths of odbc_read
* cli: free match_list in off nominal paths of CLI match completion
* config: free comment_buffer/list_buffer when configuration file load
is unchanged; free the same buffers any time they were
created and config files were processed
* data: free XML nodes in various places
* enum: free context buffer in off nominal paths
* features: free ast_call_feature in off nominal paths of applicationmap
config processing
* netsock2: users of ast_sockaddr_resolve pass in an ast_sockaddr struct
that is allocated by the method. Failures in
ast_sockaddr_resolve could result in the users of the method
not knowing whether or not the buffer was allocated. The
method will now not allocate the ast_sockaddr struct if it
will return failure.
* pbx: cleanup hash table traversals in off nominal paths; free
ignore pattern buffer if it already exists for the specified
context
* xmldoc: cleanup various nodes when we no longer need them
* main/editline: various cleanup of pointers not being freed before being
assigned to other memory, cleanup along off nominal paths
* menuselect/mxml: cleanup of value buffer for an attribute when that attribute
did not specify a value
* res_calendar*: responses are allocated via the various *_request method
returns and should not be allocated in the various
write_event methods; ensure attendee buffer is freed if no
data exists in the parsed node; ensure that calendar objects
are de-ref'd appropriately
* res_jabber: free buffer in off nominal path
* res_musiconhold: close the DIR* object in off nominal paths
* res_rtp_asterisk: if we run out of ports, close the rtp socket object and free
the rtp object
* res_srtp: if we fail to create the session in libsrtp, destroy the
temporary ast_srtp object
(issue ASTERISK-19665)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1922
........
Merged revisions 366880 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 366881 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366917 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes two problems pointed out by a static analysis tool.
* In chan_dahdi, when an event is handled the index of the sub channel is first
obtained. In very off nominal cases, the method that determines the index
can return a negative value. In the event handling code, whether or not
the index returned is valid was being checked after that value was used to
index into an array. This patch makes it so the value is checked before
any indexing is done.
* In res_calendar_ews, sizeof was being passed a pointer instead of the struct to
determine the amount of memory to allocate.
(issue ASTERISK-19651)
Reported by: Matt Jordan
(closes issue ASTERISK-19671)
Reported by: Matt Jordan
........
Merged revisions 366740 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 366741 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366746 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This resolves core findings from ASTERISK-19650 numbers 0-2, 6, 7, 9-11, 14-20,
22-24, 28, 30-32, 34-36, 42-56, 82-84, 87, 89-90, 93-102, 104, 105, 109-111,
and 115. Finding numbers 26, 33, and 29 were already resolved. Those skipped
were either extended/deprecated or in areas of code that shouldn't be
disturbed.
(Closes issue ASTERISK-19650)
........
Merged revisions 366167 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 366168 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366169 65c4cc65-6c06-0410-ace0-fbb531ad65f3
These three all are in RTP code that attempts to print the number of sequence number cycles
in an RTCP RR report. The code was masking out the upper 16 bits and then shifting the number
right by 16 bits. This led to an all zero result in all cases. The fix is to do the shift without
the bit masking.
(issue ASTERISK-19649)
........
Merged revisions 365298 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 365299 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@365300 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reimplement the "corosync show members" CLI command using a CPG iterator
instead of the cpg_membership_get API call. This will also show all
CPG members, including those in groups other than 'asterisk', which may
be useful at some point for debugging purposes.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@363045 65c4cc65-6c06-0410-ace0-fbb531ad65f3