Now matches are made on both the IP address and port number, or if the insecure setting is set to "port" then just match on the
IP address.
In order to accomplish this, I also added a new API call, ast_category_root, which returns the first variable of an ast_category struct
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@78103 65c4cc65-6c06-0410-ace0-fbb531ad65f3
will just return immediately. Also, fix some logic so the thread's lock
isn't unlocked twice in the weird case of dynamic threads getting acquired
right after a timeout.
(pointed out by SteveK)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@78028 65c4cc65-6c06-0410-ace0-fbb531ad65f3
during the first time it runs. This shouldn't ever happen, but we should
account for it anyway.
(pointed out by pete, who works with mihai)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77949 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also rearrange messages to better fit with what a wireshark trace shows it should be.
Issue 10299, initial patch and solution by sbisker, modified by me to fit with wireshark trace.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
thread timed out waiting for something to do, but was acquired to perform an
action immediately afterwords, then wait on the condition again to give the
other thread a chance to finish setting up the data for what action this thread
should perform. Otherwise, if it immediately continues, it will perform the
wrong action.
(reported on IRC by mihai, patch by me)
(related to issue #10289)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77943 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The most notable problem is that people have been seeing storms of VNAK frames
being sent due to really old frames mysteriously being in the retransmission
queue and never getting removed.
It was possible that a dynamic thread got created, but did not acquire its lock
before the thread that created it signals it to perform an action. When this
happens, the thread will sleep until it hits a timeout, and then get destroyed.
So, the action never gets performed and in some cases, means a frame doesn't
get transmitted and never gets freed since the scheduler never gets a chance
to reschedule transmission.
Another less severe race condition is in the handling of a timeout for a dynamic
thread. It was possible for it to be acquired to perform at action at the same
time that it hit a timeout. When this occurs, whatever action it was acquired
for would never get performed.
(patch contributed by Mihai and SteveK)
(closes issue #10289)
(closes issue #10248)
(closes issue #10232)
(possibly related to issue #10359)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77887 65c4cc65-6c06-0410-ace0-fbb531ad65f3
due to sending packets in the wrong order during hangup.
Also make sure we clear tones/messages on the correct line/instance.
Issue 10291, patch by DEA, tested by sbisker and myself.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77883 65c4cc65-6c06-0410-ace0-fbb531ad65f3
servers between endpoints, the Asterisk servers will not keep retransmitting the re-invites.
(closes issue #10274, reported by cstadlmann, patched by me with approval from file)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77824 65c4cc65-6c06-0410-ace0-fbb531ad65f3
queue. In the network_thread() loop, it traverses the list using the
AST_LIST_TRAVERSE_SAFE macro. However, to remove an element of the list within
this loop, it used AST_LIST_REMOVE, instead of AST_LIST_REMOVE_CURRENT, which I
believe could leave some of the internal variables of the SAFE macro invalid.
Mihai says that he already made this change in his local copy and it didn't help
his VNAK storm issues, but I still think it's wrong. :)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77794 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: julianjm
Patches:
chan_sip_device_state_hold_fix.v1.diff.txt uploaded by julianjm (license 99)
Clear ONHOLD flag when decrementing the onHold peer count. If we did not do this the count may keep decreasing.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: mvanbaak
Patches:
chan_skinny_openbsd.diff uploaded by mvanbaak (license 7)
Add another OS that has to use the Macros for byte ordering.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@76519 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the network. Using an unsigned value here made it impossible to handle an
error returned from recvfrom(). Furthermore, in the case that recvfrom()
did return an error, this would cause a crash due to a heap overflow.
(closes issue #10265, reported by and fix suggested by timrobbins)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@76485 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Cancel ringing if endpoint hangs up before answering.
Fixes were backported from trunk (there was apparently a bit of confusion during merge of a previous patch).
(closes issue #10241)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@76178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r75927 | russell | 2007-07-19 10:49:42 -0500 (Thu, 19 Jul 2007) | 6 lines
When processing full frames, take sequence number wraparound into account when
deciding whether or not we need to request retransmissions by sending a VNAK.
This code could cause VNAKs to be sent erroneously in some cases, and to not
be sent in other cases when it should have been.
(closes issue #10237, reported and patched by mihai)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@75928 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r75757 | russell | 2007-07-18 16:09:13 -0500 (Wed, 18 Jul 2007) | 5 lines
When traversing the queue of frames for possible retransmission after
receiving a VNAK, handle sequence number wraparound so that all frames that
should be retransmitted actually do get retransmitted.
(issue #10227, reported and patched by mihai)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@75759 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: elandivar
It is possible for hold status to exist without call limits set, so we need to ensure update_call_counter is executed regardless.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@75621 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r75444 | russell | 2007-07-17 15:45:27 -0500 (Tue, 17 Jul 2007) | 5 lines
Ensure that when encoding the contents of an ast_frame into an iax_frame, that
the size of the destination buffer is known in the iax_frame so that code
won't write past the end of the allocated buffer when sending outgoing frames.
(ASA-2007-014)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@75445 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r75052 | russell | 2007-07-13 14:10:00 -0500 (Fri, 13 Jul 2007) | 12 lines
(closes issue #9660)
Reported by: mmacvicar
Patches submitted by: bbryant, russell
Tested by: mmacvicar, marco, arcivanov, jmhunter, explidous
When using a TDM400P (and probably other analog cards) there was a chance that
you could hang up and pick the phone back up where it has been long enough to
be not considered a flash hook, but too soon such that the device reports that
it is busy and the person on the phone will only hear silence. This patch
makes chan_zap more tolerant of this and gives the device a couple of seconds
to succeed so the person on the phone happily gets their dialtone.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@75053 65c4cc65-6c06-0410-ace0-fbb531ad65f3
since loginstart is used after logoff. Thanks to makoto for pointing this out and suggesting the fix.
(closes issue #10178, reported and patched by makoto, with modification by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@74998 65c4cc65-6c06-0410-ace0-fbb531ad65f3
