The MinivmMWI application was not being unregistered on unload and we were not
able to load again the module or reload it.
(closes issue #15174)
Reported by: junky
Patches:
unregister_minivm_mwi.diff uploaded by junky (license 177)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@196377 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A new xml element was created to manage the AMI actions documentation,
using AstXML.
To register a manager action using XML documentation it is now possible
using ast_manager_register_xml().
The CLI command 'manager show command' can be used to show the parsed
documentation.
Example manager xml documentation:
<manager name="ami action name" language="en_US">
<synopsis>
AMI action synopsis.
</synopsis>
<syntax>
<xi:include xpointer="xpointer(...)" /> <-- for ActionID
<parameter name="header1" required="true">
<para>Description</para>
</parameter>
...
</syntax>
<description>
<para>AMI action description</para>
</description>
<see-also>
...
</see-also>
</manager>
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@196308 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since we are dealing with a 'const char * const' now, we have to create a
temporary copy of the string to work on rather than the original. Fix inspired
by reporter. Reviewed by everyone-and-their-mother in #asterisk-dev.
(closes issue #15184)
Reported by: andrew
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@196270 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds 'const' tags to a number of Asterisk APIs where they are appropriate (where the API already demanded that the function argument not be modified, but the compiler was not informed of that fact). The list includes:
- CLI command handlers
- CLI command handler arguments
- AGI command handlers
- AGI command handler arguments
- Dialplan application handler arguments
- Speech engine API function arguments
In addition, various file-scope and function-scope constant arrays got 'const' and/or 'static' qualifiers where they were missing.
Review: https://reviewboard.asterisk.org/r/251/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@196072 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r195991 | dvossel | 2009-05-21 14:04:56 -0500 (Thu, 21 May 2009) | 14 lines
Sign problem calculating timestamp for iax frame leads to no audio on the receiving peer.
There are rare cases in which a frame's delivery timestamp is slightly less than the iax2_pvt's offset. This causes the pvt's timestamp to be a small negative number, but since the timestamp value is unsigned it looks like a huge positive number. This patch checks for this negative case and sets the ms to zero. A similar check is already done right below this one in the 'else' statement.
(closes issue #15032)
Reported by: guillecabeza
Patches:
chan_iax2.c.patch_timestamp uploaded by guillecabeza (license 380)
Tested by: guillecabeza
(closes issue #14216)
Reported by: Andrey Sofronov
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@195995 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r195881 | mnicholson | 2009-05-21 10:25:50 -0500 (Thu, 21 May 2009) | 13 lines
This commit prevents cdr records with AST_CDR_FLAG_ANSLOCKED and AST_CDR_FLAG_LOCKED from being updated in certain cases.
This is accomplished by adding two functions to update the answer time and disposition of calls that checks for the proper lock flags. These functions are used in the ast_bridge_call() function so that ForkCDR(A) calls are respected.
This patch also modifies the way ast_bridge_call() chooses the cdr record to base the bridged_cdr on. Previously the first unlocked cdr record would be chosen, now instead the first cdr record is chosen and forked cdr records are moved to the bridge_cdr. This allows the original cdr record and any forked cdr records to be properly updated with answer and end times.
(closes issue #13797)
Reported by: sh0t
Tested by: sh0t
(closes issue #14744)
Reported by: deepesh
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@195882 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When receiving a 200 OK response to an INVITE, it was possible to transmit two
connected line updates instead of a single one. Furthermore, the second did not
have the proper information present.
Now the two have been combined into a single update and the correct information
is presented.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@195798 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since we may have copied connected line info into the chanlist struct prior
to placing an outbound call, we need to be sure to free the allocated data
when we hang the call up.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@195763 65c4cc65-6c06-0410-ace0-fbb531ad65f3
SIP purists may want to look the other way...
When COLP/CONP support for SIP was committed, there was a condition under
which Asterisk may transmit a SIP UPDATE in order to communicate the change
in connected line information. The issue here is that while we could send a
SIP UPDATE message, we were not prepared to receive such an UPDATE and would
always responde with a 501 when we received an UPDATE.
The situation was a bit rough. We really want to be able to receive UPDATEs
having to do with connected line changes, but the amount of effort involved
in properly supporting RFC 3311 was staggering. This commit represents a
compromise.
First, it was decided that it is important to only send a SIP UPDATE to
an endpoint that is able to handle one. So, now we have added parsing of
the Allow header into SIP. We store the allowed methods on SIP peers so
that when we communicate with them, we already will know what we can and
cannot send to them. We will parse the peer's allowed methods when he registers
with us. If the peer is not the type to register with us, but the qualify option
is enabled, then we will use the response to the OPTIONS request we send
the peer to determine the peer's allowed methods. When the peer's registration
expires, or when qualify deems the peer to be unreachable, we clear the allowed
methods from the peer.
For an actual call, we will copy the peer's allowed methods to the sip_pvt
representing the call leg. If we are communicating with an endpoint which is
not a peer, then we will just parse the Allow header from the first message
we receive during the call and store the information in the sip_pvt.
If, during communication with a peer, we receive a 501 response, then we will
make sure to save the fact that we cannot use that method when communicating
with that peer.
Now, with all that infrastructure in place, the only actual place we use this
information currently is when attempting to send a connected line change using
an UPDATE request. If we cannot send the change immediately using an UPDATE,
we will set the SIP_NEEDREINVITE flag so that we can send a REINVITE as soon
as it is allowed.
The second part of the changes here is for Asterisk to accept UPDATE requests
that have connected line changes. Since we are not fully supporting RFC 3311,
Asterisk will NOT place the UPDATE method in Allow headers it sends. Instead,
if you are communicating with what you know to be another Asterisk box, you may
set the rpid_update parameter in sip.conf so that we will send UPDATEs to that
Asterisk box. When we send a connected line update, we set a custom header
called "X-Asterisk-rpid-update."
On the receiving end, if Asterisk receives an UPDATE that does not have the
"X-Asterisk-rpid-update" header present, then Asterisk will respond with a 501
since media-changing UPDATEs are not supported. We should never get such
UPDATEs, since as was stated earlier, Asterisk does not put UPDATE in its Allow
header. If the custom header is present in the received UPDATE, though, then we
will check the incoming request for connected line updates and queue the update
on the channel where the change occurred.
ABE-1840
ABE-1822
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@195589 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The CLI command 'manager show command' supports passing multiple action names in
the same line, but it was not allowing that because of a incorrect check in the
argumentes counter. Also the documentation was updated to show that this usage
of the command is possible.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@195369 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The CLI command 'manager show command' supports passing multiple AMI actions
at a time. The issue with this command was in another place.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@195368 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When running the autocomplete of the CLI command 'manager show command <action>'
it was autocompleting everything else after the <action> argument, giving an error,
because this command doesn't support multiple AMI action names at a time.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@195367 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This avoids possible conflicts with the internal implementation of
daemon(3).
(closes issue #15093)
Reported by: tzafrir
Patches:
20090513__issue15093__2.diff.txt uploaded by tilghman (license 14)
Tested by: tzafrir
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@195320 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The command had a for loop that was guaranteed to only execute once since
the continuation operation of the loop would set the input buffer NULL. I rewrote
the loop so that its operation was more obvious, and it would set multiple variables
correctly.
I also reduced stack space required for the function, constified the input string,
and modified the function so that it would not modify the input string while I was
at it.
(closes issue #15114)
Reported by: chris-mac
Patches:
15114.patch uploaded by mmichelson (license 60)
Tested by: chris-mac
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@195316 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r195206 | file | 2009-05-18 12:51:22 -0300 (Mon, 18 May 2009) | 7 lines
Fix a typo which caused loss of audio when using G729 in some scenarios with a smoother present.
(closes issue #15105)
Reported by: bamby
Patches:
process-vad-correctly.diff uploaded by bamby (license 430)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@195207 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Up to now, cdr_custom would only accept a single filename/format from
cdr_custom.conf. This change allows you to specify multiple filename
& format directives.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@195165 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Update applications documentation to warn the user about the use of the
WaitExten() application within a Macro(). Recommend the use of Read()
instead.
(closes issue #14444)
Reported by: ewieling
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@195162 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Avoid duplicating xml documentation by allowing to include other parts of
the xml documentation using XInclude.
Example:
<xi:include xpointer="xpointer(/docs/function[@name='CHANNEL']/synopsis)" />
(Insert this line to include the synopsis of the CHANNEL function xml
documentation).
It is also possible to include documentation from other files in the
'documentation/' directory using the href="" attribute inside a xinclude
element.
(closes issue #15107)
Reported by: lmadsen
(issue #14444)
Reported by: ewieling
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@194982 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Always free the allocated memory for a string field, because
we are always using it (not only when xmldocs are enabled).
Also if there is an error allocating memory for the string field
remember to unlock the list of registered applications, before returning.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@194945 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r194557 | dvossel | 2009-05-14 17:59:43 -0500 (Thu, 14 May 2009) | 10 lines
IAX2 "Ghost" Channels
There is a bug tracker issue where people are reporting "Ghost" channels in their 'iax2 show channels' output. The confusion is caused by channels being listed as "(NONE)" with format "unknown". These are not channels of coarse. They are usually just pending registration or poke requests, but it is confusing output. To help make sense of this I have added two columns to 'iax2 show channels'. One shows the first message which started the transaction, and the second shows the last message sent by either side of the call. This helps diagnose why the entry exists and why it may not go away.
(closes issue #14207)
Reported by: clive18
Review: https://reviewboard.asterisk.org/r/246/
........
r194685 | dvossel | 2009-05-15 10:40:37 -0500 (Fri, 15 May 2009) | 6 lines
Update to previous IAX2 "Ghost" Channels patch.
Fixed some comments made on reviewboard for the previous patch.
(issue #14207)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@194833 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Sean Bright
Eliel C. Sardanons
Tilghman Lesher
Mark Michelson
Russell Bryant
Richard Mudgett
Joshua Colp
Kevin P. Fleming
David Vossel
Matthew Nicholson