David Vossel [Fri, 10 Jul 2009 16:23:59 +0000 (16:23 +0000)]
SIP registration auth loop caused by stale nonce
If an endpoint sends two registration requests in a very short
period of time with the same nonce, both receive 401 responses
from Asterisk, each with a different nonce (the second 401
containing the current nonce and the first one being stale).
If the endpoint responds to the first 401, it does not match
the current nonce so Asterisk sends a third 401 with a newly
generated nonce (which updates the current nonce)... Now if
the endpoint responds to the second 401, it does not match the
current nonce either and Asterisk sends a fourth 401 with a
newly generated nonce... This loop goes on and on.
There appears to be a simple fix for this. If the nonce from
the request does not match our nonce, but is a good response
to a previous nonce, instead of sending a 401 with a newly
generated nonce, use the current one instead. This breaks
the loop as the nonce is not updated until a response is
received. Additional logic has been added to make sure no
nonce can be responded to twice though.
Mark Michelson [Fri, 10 Jul 2009 15:51:36 +0000 (15:51 +0000)]
Ensure that outbound NOTIFY requests are properly routed through stateful proxies.
With this change, we make note of Record-Route headers present in any SUBSCRIBE
request that we receive so that our outbound NOTIFY requests will have the proper
Route headers in them.
David Vossel [Wed, 8 Jul 2009 23:15:54 +0000 (23:15 +0000)]
Fixes 8khz assumptions
Many calculations assume 8khz is the codec rate. This
is not always the case. This patch only addresses chan_iax.c
and res_rtp_asterisk.c, but I am sure there are other areas
that make this assumption as well.
Mark Michelson [Wed, 8 Jul 2009 19:26:13 +0000 (19:26 +0000)]
Prevent phantom calls to queue members.
If a caller were to hang up while a periodic announcement or position
were being said, the return value for those functions would incorrectly
indicate that the caller was still in the queue. With these changes,
the problem does not occur.
(closes issue #14631)
Reported by: latinsud
Patches:
queue_announce_ghost_call2.diff uploaded by latinsud (license 745)
(with small modification from me)
David Vossel [Wed, 8 Jul 2009 16:53:40 +0000 (16:53 +0000)]
ast_samp2tv needs floating point for 16khz audio
In ast_samp2tv(), (1000000 / _rate) = 62.5 when _rate is 16000.
The .5 is currently stripped off because we don't calculate
using floating points. This causes madness with 16khz audio.
Russell Bryant [Wed, 8 Jul 2009 15:54:21 +0000 (15:54 +0000)]
Make OpenSSL usage thread-safe.
OpenSSL is not thread-safe by default. However, making it thread safe is
very easy. We just have to provide a couple of callbacks. One callback
returns a thread ID. The other handles locking. For more information,
start with the "Is OpenSSL thread-safe?" question on the FAQ page of
openssl.org.
Richard Mudgett [Thu, 2 Jul 2009 21:59:43 +0000 (21:59 +0000)]
Removed confusing warning message "Got Busy in Connected State"
If an incoming mISDN call is answered with the Answer application and a
subsequent Dial gets a busy endpoint then it is valid for that already
connected channel to get the busy indication. Asterisk will play the busy
tones until the dialplan plays something else or hangs up the call.
Tilghman Lesher [Tue, 30 Jun 2009 20:23:51 +0000 (20:23 +0000)]
More incorrect language codes, plus ensuring that regionalizations use the specified language, and not English for grammar.
(closes issue #15022)
Reported by: greenfieldtech
Patches:
20090519__issue15022.diff.txt uploaded by tilghman (license 14)
Mark Michelson [Mon, 29 Jun 2009 21:23:43 +0000 (21:23 +0000)]
Fix a problem where chan_sip would ignore "old" but valid responses.
chan_sip has had a problem for quite a long time that would manifest when
Asterisk would send multiple SIP responses on the same dialog before receiving
a response. The problem occurred because chan_sip only kept track of the highest
outgoing sequence number used on the dialog. If Asterisk sent two requests out,
and a response arrived for the first request sent, then Asterisk would ignore
the response. The result was that Asterisk would continue retransmitting the
requests and ignoring the responses until the maximum number of retransmissions
had been reached.
The fix here is to rearrange the code a bit so that instead of simply comparing
the sequence number of the response to our latest outgoing sequence number, we
walk our list of outstanding packets and determine if there is a match. If there is,
we continue. If not, then we ignore the response.
In doing this, I found a few completely useless variables that I have now removed.
David Vossel [Mon, 29 Jun 2009 17:04:04 +0000 (17:04 +0000)]
segfault after SPINLOCK schedule delete
Using the SPINLOCK schedule delete macro can result in the iax_pvt lock
being given up. This makes it possible for the iax_pvt to dissappear
when we thought we held the mutex the entire time. To resolve this, the
iax_pvt's ref count is incremented.
Richard Mudgett [Sat, 27 Jun 2009 00:55:12 +0000 (00:55 +0000)]
The ISDN CPE side should not exclusively pick B channels normally.
Before this patch, Asterisk unconditionally picked B channels exclusively
on the CPE side and normally allowed alternative B channels on the network
side. Now Asterisk does the opposite.
Reasons for the CPE side to normally not pick B channels exclusively:
* For CPE point-to-multipoint mode (i.e. phone side), the CPE side does
not have enough information to exclusively pick B channels. (There may be
other devices on the line.)
* Q.931 gives preference to the network side picking B channels.
* Some telcos require the CPE side to not pick B channels exclusively.
Russell Bryant [Fri, 26 Jun 2009 21:16:39 +0000 (21:16 +0000)]
Don't fast forward past the end of a message.
This is nice change for users of the voicemail application. If someone gets a
little carried away with fast forwarding through a message, they can easily
get to the end and accidentally exit the voicemail application by hitting the
fast forward key during the following prompt.
This adds some safety by not allowing a fast forward past the end of a message.
David Brooks [Fri, 26 Jun 2009 20:03:42 +0000 (20:03 +0000)]
Fixing voicemail's error in checking max silence vs min message length
Max silence was represented in milliseconds, yet vmminsecs (minmessage) was represented
as seconds.
Also, the inequality was reversed. The warning, if triggered, was "Max silence should
be less than minmessage or you may get empty messages", which should have been logged
if max silence was greater than minmessage, but the check was for less than.
Also, conforming if statement to coding guidelines.
Russell Bryant [Thu, 25 Jun 2009 16:02:16 +0000 (16:02 +0000)]
Resolve a crash related to a T.38 reinvite race condition.
This change resolves a crash observed locally during some T.38 testing.
A call was set up using a call file, and when the T.38 reinvite came in,
the channel state was still AST_STATE_DOWN. The reason is explained by
a comment in the code that previously lived in the handling of
AST_STATE_RINGING. This change modifies the logic to handle the same
race condition for any channel state that is not UP.
Mark Michelson [Mon, 22 Jun 2009 14:42:55 +0000 (14:42 +0000)]
Fix a situation in which Asterisk would not stop retransmitting 487s.
If a CANCEL were received by Asterisk, we would send a 487 in response
to the original INVITE and a 200 OK for the CANCEL. If there were a network
hiccup which caused the 200 OK and the 487 to be lost, then the UA communicating
with Asterisk may try to retransmit its CANCEL. Asterisk's response to this used
to be to try sending another 487 to the canceled INVITE and another 200 OK to the
CANCEL.
The problem here is that the originally-sent 487 was sent "reliably" meaning that
it will be retransmitted until it is received properly. So when we receive the second
CANCEL it is likely that the first batch of 487s we sent is still going strong and
reaches the UA. The result was that the second set of 487s would be retransmitted
constantly until the maximum number of retries had been reached.
The fix for this is that if we receive a second CANCEL for an INVITE, then we cancel
the retransmission of the first set of 487s and start a second set. This causes the
dialog to be terminated reasonably.
Mark Michelson [Mon, 22 Jun 2009 14:34:05 +0000 (14:34 +0000)]
Fix a possible infinite loop in SDP parsing during glare situation.
There was a while loop in get_ip_and_port_from_sdp which was controlled
by a call to get_sdp_iterate. The loop would exit either if what we were
searching for was found or if the return was NULL. The problem is that
get_sdp_iterate never returns NULL. This means that if what we were searching
for was not present, the loop would run infinitely. This modification of the
loop fixes the problem.
Tilghman Lesher [Fri, 19 Jun 2009 00:40:41 +0000 (00:40 +0000)]
If the "h" extension fails, give it another chance in main/pbx.c.
If the "h" extension fails, give it another chance in main/pbx.c, when it
returns from the bridge code. Fixes an issue where the "h" extension may
occasionally not fire, when a Dial is executed from a Macro.
Debugged in #asterisk with user tompaw.
Russell Bryant [Thu, 18 Jun 2009 15:24:31 +0000 (15:24 +0000)]
Fix memory corruption and leakage related reloads of non files mode MoH classes.
For Music on Hold classes that are not files mode, meaning that we are executing
an application that will feed us audio data, we use a thread to monitor the
external application and read audio from it. This thread also makes use of the
MoH class object. In the MoH class destructor, we used pthread_cancel() to ask
the thread to exit. Unfortunately, the code did not wait to ensure that the
thread actually went away. What needed to be done is a pthread_join() to ensure
that the thread fully cleans up before we proceed. By adding this one line, we
resolve two significant problems:
1) Since the thread was never joined, it never fully goes away. So, on every
reload of non-files mode MoH, an unused thread was sticking around.
2) There was a race condition here where the application monitoring thread
could still try to access the MoH class, even though the thread executing
the MoH reload has already destroyed it.
Mark Michelson [Wed, 17 Jun 2009 19:59:31 +0000 (19:59 +0000)]
Change the datastore traversal in ast_do_masquerade to use a safe list traversal.
It is possible for datastore fixup functions to remove the datastore from the list
and free it. In particular, the queue_transfer_fixup in app_queue does this. While
I don't yet know of this causing any crashes, it certainly could.
Found while discussing a separate issue with Brian Degenhardt.
David Vossel [Wed, 17 Jun 2009 19:28:12 +0000 (19:28 +0000)]
StopMixMonitor race condition (not giving up file immediately)
StopMixMonitor only indicates to the MixMonitor thread to stop
writing to the file. It does not guarantee that the recording's
file handle is available to the dialplan immediately after execution.
This results in a race condition. To resolve this, the filestream
pointer is placed in a datastore on the channel. When StopMixMonitor
is called, the datastore is retrieved from the channel and the
filestream is closed immediately before returning to the dialplan.
Documentation indicating the use of StopMixMonitor to free files
has been updated as well.
Kevin P. Fleming [Wed, 17 Jun 2009 12:03:25 +0000 (12:03 +0000)]
Correct AST_LIST_APPEND_LIST behavior when list to be appended is empty.
When the list to be appended is empty, and the list to be appended to is *not*,
AST_LIST_APPEND_LIST would actually cause the target list to become broken,
and no longer have a pointer to its last entry. This patch fixes the problem.
(reported by Stanislaw Pitucha on the asterisk-dev mailing list)
Kevin P. Fleming [Tue, 16 Jun 2009 17:05:38 +0000 (17:05 +0000)]
Improve support for media paths that can generate multiple frames at once.
There are various media paths in Asterisk (codec translators and UDPTL, primarily)
that can generate more than one frame to be generated when the application calling
them expects only a single frame. This patch addresses a number of those cases,
at least the primary ones to solve the known problems. In addition it removes the
broken TRACE_FRAMES support, fixes a number of bugs in various frame-related API
functions, and cleans up various code paths affected by these changes.
Sean Bright [Mon, 8 Jun 2009 19:24:32 +0000 (19:24 +0000)]
Increase the size of our thread stack on 64 bit processors.
We were setting the stack size for each thread to 240KB regardless of
architecture, which meant that in some scenarios we actually had less available
stack space on 64 bit processors (pointers use 8 bytes instead of 4). So now we
calculate the stack size we reserve based on the platform's __WORDSIZE, which
gives us:
32 bit -> 240KB
64 bit -> 496KB
128 bit -> 1008KB (that's right, we're ready for 128 bit processors)
Patch typed by me but written by several members of #asterisk-dev, including
Kevin, Tilghman, and Qwell.
Sean Bright [Thu, 4 Jun 2009 14:14:57 +0000 (14:14 +0000)]
Safely handle AMI connections/reload requests that occur during startup.
During asterisk startup, a lock on the list of modules is obtained by the
primary thread while each module is initialized. Issue 13778 pointed out a
problem with this approach, however. Because the AMI is loaded before other
modules, it is possible for a module reload to be issued by a connected client
(via Action: Command), causing a deadlock.
The resolution for 13778 was to move initialization of the manager to happen
after the other modules had already been lodaded. While this fixed this
particular issue, it caused a problem for users (like FreePBX) who call AMI
scripts via an #exec in a configuration file (See issue 15189).
The solution I have come up with is to defer any reload requests that come in
until after the server is fully booted. When a call comes in to
ast_module_reload (from wherever) before we are fully booted, the request is
added to a queue of pending requests. Once we are done booting up, we then
execute these deferred requests in turn.
Note that I have tried to make this a bit more intelligent in that it will not
queue up more than 1 request for the same module to be reloaded, and if a
general reload request comes in ('module reload') the queue is flushed and we
only issue a single deferred reload for the entire system.
As for how this will impact existing installations - Before 13778, a reload
issued before module initialization was completed would result in a deadlock.
After 13778, you simply couldn't connect to the manager during startup (which
causes problems with #exec-that-calls-AMI configuration files). I believe this
is a good general purpose solution that won't negatively impact existing
installations.
Sean Bright [Wed, 3 Jun 2009 20:39:10 +0000 (20:39 +0000)]
Fix a possible crash in pbx_spool.
We were trying to reference members of a struct that had previously been freed.
This patch makes sure that we free the struct after it has been removed from
the spooler queue.
David Vossel [Wed, 3 Jun 2009 15:49:46 +0000 (15:49 +0000)]
Generic call forward api, ast_call_forward()
The function ast_call_forward() forwards a call to an extension specified in an ast_channel's call_forward string. After an ast_channel is called, if the channel's call_forward string is set this function can be used to forward the call to a new channel and terminate the original one. I have included this api call in both channel.c's ast_request_and_dial() and res_feature.c's feature_request_and_dial(). App_dial and app_queue already contain call forward logic specific for their application and options.
Tilghman Lesher [Mon, 1 Jun 2009 20:07:04 +0000 (20:07 +0000)]
If using the old deprecated format, a reload would cause the class to disappear.
(closes issue #14759)
Reported by: lidocaineus
Patches:
20090518__issue14759.diff.txt uploaded by tilghman (license 14)
Tested by: lmadsen
Use AST_CDR_NOANSWER instead of AST_CDR_NULL as the default CDR disposition.
This change also involves the addition of an AST_CDR_FLAG_ORIGINATED flag that is used on originated channels to distinguish: them from dialed channels.
Leif Madsen [Thu, 28 May 2009 23:57:00 +0000 (23:57 +0000)]
Update MixMonitor documentation.
Updated the MixMonitor documentation for the 'b' option so that
it is more obvious that you must not optimize awat the Local
channel when using this option.
Mark Michelson [Thu, 28 May 2009 15:27:49 +0000 (15:27 +0000)]
Allow for media to arrive from an alternate source when responding to a reinvite with 491.
When we receive a SIP reinvite, it is possible that we may not be able to process the
reinvite immediately since we have also sent a reinvite out ourselves. The problem is
that whoever sent us the reinvite may have also sent a reinvite out to another party,
and that reinvite may have succeeded.
As a result, even though we are not going to accept the reinvite we just received, it
is important for us to not have problems if we suddenly start receiving RTP from a new
source. The fix for this is to grab the media source information from the SDP of the
reinvite that we receive. This information is passed to the RTP layer so that it will
know about the alternate source for media.
Use the address we already know when reloading a peer with nat=yes.
If we already have an address for a peer, and we are reloading the sip
configuration, try to use that address to contact the peer, instead of
getting it from the Contact.
Mark Michelson [Thu, 28 May 2009 14:49:13 +0000 (14:49 +0000)]
Add flags to chanspy audiohook so that audio stays in sync.
There are two flags being added to the chanspy audiohook here. One
is the pre-existing AST_AUDIOHOOK_TRIGGER_SYNC flag. With this set,
we ensure that the read and write slinfactories on the audiohook do
not skew beyond a certain tolerance.
In addition, there is a new audiohook flag added here,
AST_AUDIOHOOK_SMALL_QUEUE. With this flag set, we do not allow for
a slinfactory to build up a substantial amount of audio before
flushing it. For this particular issue, this means that the person
spying on the call will hear the conversations in real time with very
little delay in the audio.
Joshua Colp [Thu, 28 May 2009 13:44:58 +0000 (13:44 +0000)]
Fix a bug where the flag indicating the presence of rport would get overwritten by the nat setting.
The presence of rport is now stored as a separate flag. Once the dialog is setup and authenticated
(or it passes through unauthenticated) the proper nat flag is set.
Sean Bright [Wed, 27 May 2009 20:12:06 +0000 (20:12 +0000)]
Use bash explicitly when calling build_tools/mkpkgconfig from the Makefile.
Since we use bashisms in build_tools/mkpkgconfig, we should call on bash
explicitly when running from the Makefile, otherwise we get errors during a
'make install.'
Tilghman Lesher [Wed, 27 May 2009 19:09:42 +0000 (19:09 +0000)]
Use a different determinator on whether to print the delimiter, since leading fields may be blank.
(closes issue #15208)
Reported by: ramonpeek
Patch by me, though inspired in part by a patch from ramonpeek
Jeff Peeler [Wed, 27 May 2009 16:49:38 +0000 (16:49 +0000)]
Fix broken attended transfers
The bridge was terminating immediately after the attended transfer was
completed. The problem was because upon reentering ast_channel_bridge
nexteventts was checked to see if it was set and if so could possibly
return AST_BRIDGE_COMPLETE.
Sean Bright [Wed, 27 May 2009 13:54:35 +0000 (13:54 +0000)]
Fix handling of the 'state_interface' option of the 'queue add member' CLI
command.
This change relates to r184980, which was a backport of the state interface
changes to app_queue from trunk. trunk and all of the 1.6.x branches are not
affected.
'queue add member' allows for specifying an interface to use for device state
when adding a queue member via CLI, but the validation code was not properly
updated to reflect this optional argument.
Russell Bryant [Tue, 26 May 2009 18:14:36 +0000 (18:14 +0000)]
Resolve a file handle leak.
The frames here should have always been freed. However, out of luck, there was
never any memory leaked. However, after file streams became reference counted,
this code would leak the file stream for the file being read.
David Vossel [Thu, 21 May 2009 19:04:56 +0000 (19:04 +0000)]
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.
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.
Tilghman Lesher [Mon, 18 May 2009 20:24:13 +0000 (20:24 +0000)]
Add a similar dependency on SMDI for voicemail as already exists for ADSI.
(closes issue #14846)
Reported by: pj
Patches:
20090413__bug14846__1.4.diff.txt uploaded by tilghman (license 14)
20090507__issue14846__1.6.0.diff.txt uploaded by tilghman (license 14)
20090507__issue14846__1.6.1.diff.txt uploaded by tilghman (license 14)
David Vossel [Fri, 15 May 2009 22:43:13 +0000 (22:43 +0000)]
IAX2 REGAUTH loop
IAX was not sending REGREJ to terminate invalid registrations. Instead it sent another REGAUTH if the authentication challenge failed. This caused a loop of REGREQ and REGAUTH frames.
David Vossel [Thu, 14 May 2009 22:59:43 +0000 (22:59 +0000)]
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.
projects / thirdparty / asterisk.git / log
