https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113927 | mmichelson | 2008-04-09 15:54:31 -0500 (Wed, 09 Apr 2008) | 8 lines
We need to set the persistant_route [sic] parameter for the sip_pvt
during the initial INVITE, no matter if we're building the route set from
an INVITE request or response.
(closes issue #12391)
Reported by: benjaminbohlmann
Tested by: benjaminbohlmann
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@113928 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113681 | mmichelson | 2008-04-09 09:40:05 -0500 (Wed, 09 Apr 2008) | 9 lines
If Asterisk receives a 488 on an INVITE (not a reinvite), then
we should not send a BYE.
(closes issue #12392)
Reported by: fnordian
Patches:
chan_sip.patch uploaded by fnordian (license 110) with small modification from me
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@113682 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r113013 | jpeeler | 2008-04-07 10:18:10 -0500 (Mon, 07 Apr 2008) | 15 lines
Merged revisions 113012 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113012 | jpeeler | 2008-04-07 10:16:44 -0500 (Mon, 07 Apr 2008) | 7 lines
(closes issue #12362)
(closes issue #12372)
Reported by: vinsik
Tested by: tecnoxarxa
This one line change makes an if inside a for loop (in realtime_peer) check all the ast_variables the loop was intending to test rather than just the first one.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@113241 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113012 | jpeeler | 2008-04-07 10:16:44 -0500 (Mon, 07 Apr 2008) | 7 lines
(closes issue #12362)
(closes issue #12372)
Reported by: vinsik
Tested by: tecnoxarxa
This one line change makes an if inside a for loop (in realtime_peer) check all the ast_variables the loop was intending to test rather than just the first one.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@113013 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Attaching to a running asterisk with "telnet hostname 5060", I would input "something", then hit return three times, and asterisk crashes.
I traced it to handle_request_do(), which zeroes out the data (an ast_str ptr) if the string is too short.
Instead of freeing the struct and nulling the pointer, it now just resets it, because this
ast_str is expected by the calling routine to still be there after handle_request_do() returns.
This appears to fix the crash. I assume that it was introduced with ast_str's being adopted. It's a subtle and easy-to-miss sort of problem.
I also found all the places where the req.data is freed, and made sure the ptr is Nulled out as well;
no good leaving bad ptrs laying around-- I didn't need to do this, but it seemed a good thing to do...
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@112874 65c4cc65-6c06-0410-ace0-fbb531ad65f3
that valgrind no longer complains and that calls do complete correctly.
The fix is along the same lines as before: Make sure the final null terminator gets copied
into the new sip_request's data pointer. Without it, parse_request will read and potentially
write past the end of the string, causing potential crashes.
(closes issue #12284...for real this time!)
reported by falves11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@111811 65c4cc65-6c06-0410-ace0-fbb531ad65f3
for the string to be copied into. This resulted in parse_request reading invalid
memory beyond the end of the string, and in some cases led to crashes. Thanks
to falves11 for providing the valgrind output which led to the closure of this issue.
(closes issue #12284)
Reported by: falves11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@111662 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r110635 | mmichelson | 2008-03-25 10:40:33 -0500 (Tue, 25 Mar 2008) | 7 lines
When reverting a commit, I accidentally left in this bit which was an experiment
to see what would happen. It passed the compile test, and I didn't notice I had
left this change in too.
So this is a revert of a revert...sort of.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@110636 65c4cc65-6c06-0410-ace0-fbb531ad65f3
SIP REGISTER requests. rjain points out that RFC 3265 specifies
that the Event: header is not a valid header for REGISTER requests
and that the "registration" value is not defined at IANA.
(closes issue #12279)
Reported by: rjain
Patches:
chan_sip.c.diff uploaded by rjain (license 226)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@110621 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r110618 | mmichelson | 2008-03-24 14:17:41 -0500 (Mon, 24 Mar 2008) | 15 lines
This is a revert for revision 108288. The reason is that that revision
was not for an actual bug fix per se, and so it really should not have been in 1.4 in
the first place. Plus, people who compile with DO_CRASH are more likely
to encounter a crash due to this change. While I think the usage of DO_CRASH
in ast_sched_del is a bit absurd, this sort of change is beyond the scope of 1.4
and should be done instead in a developer branch based on trunk
so that all scheduler functions are fixed at once.
I also am reverting the change to trunk and 1.6 since they also suffer from
the DO_CRASH potential.
(closes issue #12272)
Reported by: qq12345
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@110619 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r110336 | russell | 2008-03-20 16:54:58 -0500 (Thu, 20 Mar 2008) | 14 lines
Merged revisions 110335 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r110335 | russell | 2008-03-20 16:53:27 -0500 (Thu, 20 Mar 2008) | 6 lines
Fix some very broken code that was introduced in 1.2.26 as a part of the security
fix. The dnsmgr is not appropriate here. The dnsmgr takes a pointer to an address
structure that a background thread continuously updates. However, in these cases,
a stack variable was passed. That means that the dnsmgr thread would be continuously
writing to bogus memory.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@110337 65c4cc65-6c06-0410-ace0-fbb531ad65f3
actual problems, per se. I also added format attributes to any printf wrapper functions I found that didn't have them. -Wsecurity and -Wmissing-format-attribute added to --enable-dev-mode.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109447 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r108737 | mmichelson | 2008-03-14 11:44:08 -0500 (Fri, 14 Mar 2008) | 33 lines
Fix a race condition in the SIP packet scheduler which could cause a crash.
chan_sip uses the scheduler API in order to schedule retransmission of reliable
packets (such as INVITES). If a retransmission of a packet is occurring, then the
packet is removed from the scheduler and retrans_pkt is called. Meanwhile, if
a response is received from the packet as previously transmitted, then when we
ACK the response, we will remove the packet from the scheduler and free the packet.
The problem is that both the ACK function and retrans_pkt attempt to acquire the
same lock at the beginning of the function call. This means that if the ACK function
acquires the lock first, then it will free the packet which retrans_pkt is about to
read from and write to. The result is a crash.
The solution:
1. If the ACK function fails to remove the packet from the scheduler and the retransmit
id of the packet is not -1 (meaning that we have not reached the maximum number of
retransmissions) then release the lock and yield so that retrans_pkt may acquire the
lock and operate.
2. Make absolutely certain that the ACK function does not recursively lock the lock in
question. If it does, then releasing the lock will do no good, since retrans_pkt will
still be unable to acquire the lock.
(closes issue #12098)
Reported by: wegbert
(closes issue #12089)
Reported by: PTorres
Patches:
12098-putnopvutv3.patch uploaded by putnopvut (license 60)
Tested by: jvandal
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108738 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r108530 | russell | 2008-03-13 16:06:33 -0500 (Thu, 13 Mar 2008) | 10 lines
Make a tweak that gets the LEDs on polycom phones to blink when an extension that
has been subscribed to goes on hold. Otherwise, they just stay on like it does
when an extension is in use.
(closes issue #11263)
Reported by: russell
Patches:
notify_hold.rev1.txt uploaded by russell (license 2)
Tested by: russell
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108531 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This set of changes removes the hard coded maximum packet size of 4kB from chan_sip.
It now starts by allocating 1kB, and growing the buffer as needed to accommodate large
packets.
(closes issue #8556, reported by mikma, patch by jamesgolovich)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108439 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r108288 | mmichelson | 2008-03-12 16:53:46 -0500 (Wed, 12 Mar 2008) | 14 lines
Change AST_SCHED_DEL use to ast_sched_del for autocongestion in chan_sip.
The scheduler callback will always return 0. This means that this id
is never rescheduled, so it makes no sense to loop trying to delete
the id from the scheduler queue. If we fail to remove the item from the
queue once, it will fail every single time.
(Yes I realize that in this case, the macro would exit early because the
id is set to -1 in the callback, but it still makes no sense to use
that macro in favor of calling ast_sched_del once and being done with it)
This is the first of potentially several such fixes.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108289 65c4cc65-6c06-0410-ace0-fbb531ad65f3
