When we specifically release all limits on a channel we destroy the
hash table stored in the "limit_hash" private channel data but we
don't destroy the private data as it will be reclaimed as part of the
session. If limit increment is called after the limit release we can
reuse that channel private, but we need to check whether the hash
table is null first. Fortunately this makes the code look better
anyway.
FS-6775 #resolve
FS-6783 #resolve
* Added BERT stats channel variables
* Check if the channel is going down when out of sync to avoid flagging it
as out of sync, if the channel is going down it is expected to have some errors
* Calculate sampling error rate over a time window
* Create the following variables to control bert testing behavior:
bert_timeout_ms - Milliseconds to wait for bert sync before timing out
bert_window_ms - Window of time to calculate sampling error rate percentage
bert_max_err - Max percentage of error tolerated before going out of sync
bert_hangup_on_error - Hangup when error occurs (Timeout or going out of sync)
* commit '388e9638de7c14e00272777245dacc87cf09fc1c':
F-5946 add the patches. if in the sofia gateway config the param pin-monitoring is true, then every ping result raise an sofia::gateway-state event
if read multi times when waiting for a slow client, then bytes is much shorter than datalen
so it could incorrectly terminate the string and data could be lost
In `sofia status gateway ...` let's show the uptime in seconds rather
than in microseconds. We'll output the uptime in microseconds in
`xmlstatus` and we'll label it as such.
The 'UP' status indicates a gateway is online as determined by
registration and/or SIP OPTIONS pinging.
The time the gateway has been in the 'UP' status is recorded,
and can be monitored using 'sofia status' and 'sofia xmlstatus'.
This can be used to detect and graph when there are outages.
ref: FS-6772
Reviewed-by: Travis Cross <tc@traviscross.com>
What if the hash were destroyed by one thread holding the lock while
another thread was waiting for the lock? The waiting thread would
have already checked that the hash was non-null and would proceed on
that assumption after acquiring the lock.
With this commit we check only after acquiring the lock.
ref: FS-6783
ref: FS-6775
`switch_core_hash_first` allocates an iterator on each call that is
never freed except when the hash table is empty.
By using `switch_core_hash_first_iter` we allocate only one iterator,
and that iterator is freed after the last item is processed.
In some configurations where many limits are used, the limit increases
and releases were generating a lot of noise and making it harder to
see when limits were exceeded, which was at the same log level.
As an example of using mod_sofia's gateway parameter `contact-params`
we'd used the value `tport=tcp`. Looking around, it's clear this has
misled people into believing you can specify `tport=tcp` to make the
gateway use TCP or `tport=tls` to make the gateway use TLS. This does
not work.
The actual contact parameter is named `transport` rather than `tport`,
and you shouldn't use `transport` in `contact-params` because we
automatically add a `transport` to the Contact: based on the value of
`register-transport` (even if the gateway is set to not register).
It's clear why this would be confusing, so we'll just remove this as
an example.
mod_curl currently does not verify the authenticity of the peer's
certificate, and does not verify whether the common name on the
certificate matches the server. This makes mod_curl initiated TLS
connections completely insecure. We should fix this, but until we do,
we'll warn people that it's not doing what they may think it is.
ref: http://curl.haxx.se/libcurl/c/CURLOPT_SSL_VERIFYPEER.html
ref: http://curl.haxx.se/libcurl/c/CURLOPT_SSL_VERIFYHOST.html
* commit 'c736cf2f22e4f0a5d490db995ebaed69b9963daa':
Add sofia gateway parameter "destination-prefix"
FS-5497 add sofia gateway parameter destination-prefix in case you need to send Invites with prefix only to this gateway
`curl_sendfile` generates a multipart message with Content-Type:
multipart/form-data with no separate Content-Type headers in the parts
for each non-file argument. These parts therefore default to
text/plain. However, prior to this commit, we were putting the URL
encoded POST data into these parts, which is not correct. We should
be putting raw text into the parts.
With this commit, we urldecode each argument key and value before
composing the multipart message.
See:
http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.2
* commit 'b60df39b96b05b6c3cf220d5049ea5fc20dfa6e1':
mod_http_cache: fix configuration so that carriage returns or other whitespace is OK around S3 keys
mod_http_cache: fixed S3 URL parser to allow mybucketsubdomain.com.s3.amazonaws.com
Dušan Dragić