Make user removals and traversals thread safe in meetme.
Race conditions present in meetme involving the user list where a lack of
locking has the potential for a user to be removed during a traversal or as in
the case of the reporter after checking if the list is empty could cause a
crash. Fixing this was done by convering the userlist to an ao2 container.
Terry Wilson [Tue, 13 Jul 2010 17:11:37 +0000 (17:11 +0000)]
Destroy RTP fds when we schedule final dialog destruction
Since we are only keeping the dialog around for retransmissions at this point
and there is no possibility that we are still handling RTP, go ahead and
destroy the RTP sessions. Keeping them alive for 32 past when they are used
is unnecessary and can lead to problems with having too many open file
descriptors, etc.
Access peer->cdr directly instead of through a saved off reference.
At this point in the code, it is possible that peer_cdr may be invalid.
Specifically, in the blind transfer code, CDRs are swapped between channels.
So, peer_cdr is no longer == peer->cdr.
The scenario that exposed a crash in this code was a blind transfer that hit
the system call limit, causing the transferee channel to get destroyed after
the transfer attempt failed. Even if it succeeds and this code doesn't crash,
this code was still trying to reset a CDR on a channel that was now owned by
a different thread, which is a BadThing(tm).
Change ast_write to not stop generator when called from ast_prod.
For SIP channels configured with the progressinband option on, the ringback was
being immediately stopped. This problem was due to ast_prod being moved for a
deadlock fix in 259858. Prodding the channel after setting up the generator
triggered the check in ast_write to stop the generator. The fix here should
write the frame the same as was done before the call to ast_prod was moved.
This change adds an ERROR message to let you know when a failure exists to
get the columns from the pgsql database, which typically means that the
table does not exist.
When creating a conference for a unit test, it is not mandatory to open a
dahdi pseudo channel, so if we fail doing it, continue creating the conference.
Russell Bryant [Fri, 9 Jul 2010 21:57:21 +0000 (21:57 +0000)]
Fix some issues related to dynamic feature groups in features.conf.
The bridge handling code did not properly consider feature groups when setting
parameters that would affect whether or not a native bridge would be attempted.
If DYNAMIC_FEATURES only include a feature group, a native bridge would occur
that may prevent features from working.
Fix a bug in verbose output that would show the key mapping as empty if it was
using the default mapping and not a custom mapping in the feature group.
Add feature groups to the output of "features show".
Adjust the feature execution logic to match that of the logic when executing
a feature that was not configured through a feature group.
Update features.conf.sample to show that an '=' is still required if using
the default key mapping from [applicationmap].
Finally, clean up a little bit of formatting to better coform to coding
guidelines while in the area.
(closes issue #17589)
Reported by: lmadsen
Patches:
issue_17589.rev4.txt uploaded by russell (license 2)
Tested by: russell, lmadsen
Mark Michelson [Fri, 9 Jul 2010 20:58:52 +0000 (20:58 +0000)]
Fix error in parsing SIP registry strings from ASTdb.
It was essentially an off-by-one error. The easiest way
to fix this was to use the handy-dandy AST_NONSTANDARD_RAW_ARGS
macro to parse the pieces of the registration string out. Tested
and it works wonderfully.
Mark Michelson [Fri, 9 Jul 2010 19:46:20 +0000 (19:46 +0000)]
Fix port parsing in check_via.
If a Via header contained an IPv6 address, we would not properly parse
the port. We would instead get the information after the first colon in
the address.
Mark Michelson [Fri, 9 Jul 2010 19:29:30 +0000 (19:29 +0000)]
Fix an issue where the port for p->ourip was being set to 0.
This should fix all the CDR tests that were not passing. When they would
originate a call, all fields in the INVITE that contained the source port would
have the port set to 0. Most troubling of these was the Contact header. Tests
are passing locally now and should also pass on the bamboo build agents.
Mark Michelson [Fri, 9 Jul 2010 14:27:07 +0000 (14:27 +0000)]
Fix sip_uri_parse test comparison.
Part of the change with the IPv6 changes is to treat a host:port as
a single 'domain' entity. This test was not updated to have the correct
expectation after calling parse_uri().
Mark Michelson [Thu, 8 Jul 2010 22:08:07 +0000 (22:08 +0000)]
Add IPv6 to Asterisk.
This adds a generic API for accommodating IPv6 and IPv4 addresses
within Asterisk. While many files have been updated to make use of the
API, chan_sip and the RTP code are the files which actually support
IPv6 addresses at the time of this commit. The way has been paved for
easier upgrading for other files in the near future, though.
Big thanks go to Simon Perrault, Marc Blanchet, and Jean-Philippe Dionne
for their hard work on this.
(closes issue #17565)
Reported by: russell
Patches:
asteriskv6-test-report.pdf uploaded by russell (license 2)
Set proper FAXOPT(status), FAXOPT(statusstr), and FAXOPT(error) values where possible. Previously some failure cases did not result in proper FAXOPT values.
Correct how 100, 200, 300, etc. is said. Also add the crazy British numbers.
(closes issue #16102)
Reported by: Delvar
Patches:
say.conf.fix.patch uploaded by Delvar (license 908)
(plus a few additional fixes and simplifications by me)
........
Add option to not do a call forward on 482 Loop Detected
Asterisk has always set up a forwarded call when receiving a 482 Loop Detected.
This prevents handling the call failure by just continuing on in the dialplan.
Since this would be a change in behavior, the new option to disable this
behavior is forwardloopdetected which defaults to 'yes'.
Properly detect and report invalid maxrate and maxrate values in the FAXOPT dialplan function. Also make fax_rate_str_to_int() return an unsigned int and return 0 instead of -1 in the event of an error.
Fix problem with RFC 2833 DTMF not being accepted.
A recent check was added to ensure that we did not erroneously
detect duplicate DTMF when we received packets out of order.
The problem was that the check did not account for the fact that
the seqno of an RTP stream will roll over back to 0 after hitting
65535. Now, we have a secondary check that will ensure that the
seqno rolling over will not cause us to stop accepting DTMF.
Make get_member_status return QUEUE_NO_MEMBERS instead of QUEUE_NO_REACHABLE_MEMBERS to make joinempty=no work again. This regression was introduced in 273639. Also fixed whitespace.
........
Allow admin user to join conference without using admin mode and no user pin.
Configuring the conference in meetme.conf like the following:
conf => 2345,,6666
did not prompt for pin when used without admin mode. This meant that the
conference could not be joined as an admin even if the user knew the correct
pin. The original bug report was submitted claiming that the blank user pin
should deny entry into the conference. I think a better way to handle this
would be with a feature enhancement that used the following syntax:
conf => 2345,X,6666 - where X denotes no acceptable pin allowed
David Vossel [Thu, 1 Jul 2010 16:40:17 +0000 (16:40 +0000)]
correct handling of get_destination return values
A failure when calling the get_destination can mean multiple things. If
the extension is not found, a 404 error is appropriate, but if the URI
scheme is incorrect, a 404 is not approperiate. This patch adds the
get_destination_result enum to differentiate between these and other failure
types. The only logical difference in this patch is that we now send a "416
Unsupported URI scheme" response instead of a "404" when the scheme is not
recognized. This indicates to the initiator of the INVITE to retry the request
with a correct URI.
Ensure channel placed in meetme in ringing state is properly hung up.
An outgoing channel placed in meetme while still ringing which was then hung up
would not exit meetme and the channel was not properly destroyed. Specifically
checking for this scenario by looking at the appropriate control frames resolves
the issue.
(closes issue #15871)
Reported by: Ivan
Patches:
meetme_congestion_trunk_v2.patch uploaded by Ivan (license 229)
........
David Vossel [Tue, 29 Jun 2010 20:44:05 +0000 (20:44 +0000)]
send a 400 Bad Request on malformed sip request
RFC 2361 section 24.4.1 send a 400 Bad Request if the request
can not be understood due to malformed syntax. Currently we
simply ignore a packet with a missing callid, to, from, or
via header. Instead of ignoring we now send the 400 Bad request.
David Vossel [Mon, 28 Jun 2010 18:38:47 +0000 (18:38 +0000)]
rfc compliant sip option parsing + new unit test
RFC 3261 section 8.2.2.3 states that if any unsupported options
are found in the Require header field, a "420 (Bad Extension)"
response should be sent with an Unsupported header field containing
only the unsupported options.
This is not currently being done correctly. Right now, if Asterisk
detects any unsupported sip options in a Require header the entire
list of options are returned in the Unsupported header even if some
of those options are in fact supported. This patch fixes that by
building an unsupported options character buffer when parsing the
options that can be sent with the 420 response. A unit test verifying
this functionality has been created. Some code refactoring was required.
David Vossel [Mon, 28 Jun 2010 14:55:25 +0000 (14:55 +0000)]
code guidelines cleanup for retrans_pkt() function
I am doing work in this function. I noticed a large number of
coding guidline fixes that needed to be made. Rather than have
those changes distract from my functional changes I decided
to separate these into a separate patch.
David Vossel [Fri, 25 Jun 2010 19:39:53 +0000 (19:39 +0000)]
chan_sip: more accurate retransmissions
RFC3261 states that Timer A should start at 500ms (T1) by default.
In chan_sip this value initially started at 1000ms and I changed
it to 500ms recently. After doing that I noticed in my packet
captures that it still occasionally retransmitted starting at
1000ms instead of 500ms like I told it to. This occurs because
the scheduler runs in the do_monitor thread. If a new retransmission
is added while the do_monitor thread is sleeping then it may not
detect that retransmission for nearly 1000ms. To fix this I just
poke the do_monitor thread to wake up when a new packet is sent
reliably requiring retransmits. The thread then detects the new
scheduler entry and adjusts its sleep time to account for it.
projects / thirdparty / asterisk.git / log
