| Age | Commit message (Collapse) | Author |
|---|
|
The retrieve_cache_control_directives test has been failing occasionally
in Jenkins. The apparent failure occurs when attempting to validate the
expiration of the retrieved file.
After reproducing, the problem was pretty clear. At the beginning of the
test, the current time is retrieved. The seconds value of this timestamp
is X. When the file is retrieved, res_http_media_cache calculates the
expiration and in doing so retrieves the current time. In most cases,
since the test executes quickly, it will also retrieve a timestamp with
X seconds. However, if the test starts very near to when the timestamp
seconds are set to increment, res_http_media_cache may retrieve a
timestamp with X+1 seconds instead.
The test attempted to account for this by allowing a tolerance of 1
second when validating the expiration. However, the problem was that the
comparisons being used in the validation used > and < operations. This
meant that values that fell within the tolerance (because they equaled
the upper bound of the tolerance) would fail.
The solution is to use >= and <= operators in the expiration validation.
However, I estimated that while the one second tolerance should be
fine on most machines, it would still be possible on a very slow machine
to end up falling outside the one second tolerance. So I have also
relaxed the tolerance of expiration validation to be three seconds
instead.
The final change here is to add a debug message when validating
expiration so that we can see what values are being compared.
ASTERISK-25959 #close
Reported by Joshua Colp
Change-Id: Ic1a0e10722c1c5d276d5a4d6a67136d6ec26c247
|
|
|
|
|
|
|
|
|
|
Testing has shown that our usage of UnixODBC is problematic
due to bugs within UnixODBC itself as well as the heavy weight
cost of connecting and disconnecting database connections, even
when pooling is enabled.
For users of UnixODBC 2.3.1 and earlier crashes would occur due
to insufficient protection of the disconnect operation. This was
fixed in UnixODBC 2.3.2 and above.
For users of UnixODBC 2.3.3 and higher a slow-down would occur
under heavy database use due to repeated connection establishment.
A regression is present where on each connection the database
configuration is cached again, with the cache growing out of
control.
The connection pool implementation present in this change helps
to mitigate these issues by reducing how much we connect and
disconnect database connections. We also solve the issue of
crashes under UnixODBC 2.3.1 by defaulting the maximum number of
connections to 1, returning us to the previous working behavior.
For users who may have a fixed version the maximum concurrent
connection limit can be increased helping with performance.
The connection pool works by keeping a list of active connections.
If the connection limit has not been reached a new connection is
established. If the connection limit has been reached then the
request waits until a connection becomes available before
continuing.
ASTERISK-26074 #close
ASTERISK-26054 #close
Change-Id: I6774bf4bac49a0b30242c76a09c403d2e856ecff
|
|
Icelandic has some weird grammar rules when dealing with dates and
numbers. There are different genders used depending on which number
you're dealing with, and only a handful of numbers do change depending
on the gender. There is also an implied gender in several cases.
This patch was originally written for asterisk 1.6, and has been in use
for several years without crashes. I cleaned it up a bit and rewrote
what was necessary for Asterisk 13.
The functions were copied from other similar languages and modified
where appropriate. If i recall correctly, the German and Danish
functions were used as a base.
ASTERISK-26087
Reported by: Örn Arnarson
Tested by: Örn Arnarson
Change-Id: Ib7d8bd7b0fede5767921ed821315b5b508c0e665
|
|
Since libSRTP 1.5, its Random Number Generator (RNG) is not maintained anymore.
Therefore, the symbol RAND_bytes is used instead of crypto_get_random.
ASTERISK-24436 #close
Change-Id: Iea0bae4d4e3c9aa0926ea442b6484b5159789d96
|
|
Change the awkward and not as flexible UnicastRTP options format
From:
Dial(UnicastRTP/127.0.0.1[/[<engine>][/[<codec>]]])
To:
Dial(UnicastRTP/127.0.0.1[/[<options>]])
Where <options> can be standard Asterisk flag options:
c(<codec>) - Specify which codec/format to use such as 'ulaw'.
e(<engine>) - Specify which RTP engine to use such as 'asterisk'.
More option flags can be easily added later such as the codec's RTP
payload type to use when the codec does not have a static payload type
defined.
Change-Id: I0c297aaf09e2ee515536cb7437bb8042ff8ff3c9
|
|
Added a new channel variable FORWARDERNAME which indicates which
channel was responsible for a forwarding requests received on dial attempt.
Fixed a bug in the app_queue: FORWARD_CONTEXT is not used.
ASTERISK-26059 #close
Change-Id: I34e93e8c1b5e17776a77b319703c48c8ca48e7b2
|
|
If you create a local channel and don't specify an originator channel
to take capabilities from, we automatically add all audio formats to
the new channel's capabilities. When we try to make the channel
compatible with another, the "best format" functions pick the best
format available, which in this case will be slin192. While this is
great for preserving quality, it's the worst for performance and
overkill for the vast majority of applications.
In the absense of any other information, adding all formats is the
correct thing to do and it's not always possible to supply an
originator so a new parameter 'formats' has been added to the channel
create/originate functions. It's just a comma separated list of formats
to make availalble for the channel. Example: "ulaw,slin,slin16".
'formats' and 'originator' are mutually exclusive.
To facilitate determination of format names, the format name has been
added to "core show codecs".
ASTERISK-26070 #close
Change-Id: I091b23ecd41c1b4128d85028209772ee139f604b
|
|
|
|
Add Uptime and LastReload to event FullyBooted.
ASTERISK-26058 #close
Reported by: Niklas Larsson
Change-Id: I909b330801c0990d78df9b272ab0adc95aecb15e
|
|
The 81b01a191a46_pjsip_add_contact_reg_server.py script was attempting
to use UniqueConstraint and failing. It was not imported and after
importing it also continued to fail.
I've changed the script to use the explicit name of the constraint
instead.
Change-Id: I2438b0be90b7ce583b47dd27983c0c1a02cea5b9
|
|
|
|
|
|
|
|
The stringfields refactor to allow adding stringfields to the end of a
structure (f6f4cf459f43f072604927209b39646f84aaa2e2) exposed some
incomplete cleanup code by some stringfield users.
The most noticeable leaker is the logging system where there is a leak for
every log message generated.
ASTERISK-26078 #close
Reported by: Etienne Lessard
Patches:
jira_asterisk_26078_v13.patch (license #5621) patch uploaded
by Richard Mudgett
Change-Id: If6a08b31336b492c3de6f9dfd07c447f8d5a8782
|
|
|
|
The pjproject doxygen for rdata->msg_info.info says to call
pjsip_rx_data_get_info() instead of accessing the struct member directly.
You need to call the function mostly because the function will generate
the struct member value if it is not already setup.
Change-Id: I4d519385a577f3e9d9193a88125e493cf17fa799
|
|
|
|
|
|
|
|
Dial events up to this point have come in two flavors
* A Dial event with no status to indicate that dialing has begun
* A Dial event with a status to indicate that dialing has ended
With this change, Dial events have been expanded to also give
intermediate events, such as "RINGING", "PROCEEDING", and "PROGRESS".
This is especially useful for ARI dialing, as it gives the application
writer the opportunity to place a channel into an early bridge when
early media is detected.
AMI handles these in-progress dial events by sending a new event called
"DialState" that simply indicates that dial state has changed but has
not ended. ARI never distinguished between DialBegin and DialEnd, so no
change was made to the event itself.
Another change here relates to dial forwards. A forward-related event
was previously only sent when a channel was successfully able to forward
a call to a new channel. With this set of changes, if forwarding is
blocked, we send a Dial event with a forwarding destination but no
forwarding channel, since we were prevented from creating one. This is
again useful for ARI since application writers can now handle call
forward attempts from within their own application.
ASTERISK-25925 #close
Reported by Mark Michelson
Change-Id: I42cbec7730d84640a434d143a0d172a740995543
|
|
|
|
|
|
|
|
|
|
Re-ordered the body items so Message-Account is second.
Messages-Waiting: no
Message-Account: sip:1571@<IP Removed>:5060
Voice-Message: 0/0 (0/0)
ASTERISK-26065 #close
Reported-by: Ross Beer
Change-Id: If5d35a64656eac98c2dd5e490cc0b2807bed80c3
|
|
Although all the patches we had against 2.4.5 were applied by Teluu,
a new bug was introduced preventing re-use of tcp and tls transports
This patch removes all the previous patches against 2.4.5, updates
the version to 2.5, and adds a new patch to correct the transport
re-use problem.
Change-Id: I0dc6c438c3910f7887418a5832ca186aea23d068
|
|
Added notes about when you can read or write headers. Specifically
about being able to read on the inbound channel and write on an
outbound channel.
ASTERISK-26063 #close
Reported by: Private Name
Tested by: Rusty Newton
Change-Id: Ibeb64af17d1f6451028b3c29855a3f151a01d8c5
|
|
This adds a new parameter to the end of a multicast RTP dialing string.
This parameter defines the following options:
* i: Set the interface from which multicast RTP is sent
* l: Set whether multicast packets are looped back to the sender
* t: Set the TTL for multicast packets
* c: Set the codec to use for RTP
ASTERISK-26068 #close
Reported by Mark Michelson
Change-Id: I033b706b533f0aa635c342eb738e0bcefa07e219
|
|
ARI dial had been implemented using the Dial API. This made great sense
when dialing was 100% separate from bridging. However, if a channel were
to be added to a bridge during the dial attempt, there would be a
conflict between the dialing thread and the bridging thread. Each would
be attempting to read frames from the dialed channel and act on them.
The initial attempt to make the two play nice was to have the Dial API
suspend the channel in the bridge and stay in charge of the channel
until the dial was complete. The problem with this was that it was
riddled with potential race conditions. It also was not well-suited for
the case where the channel changed which bridge it was in during the
dial.
This new approach removes the use of the Dial API altogether. Instead,
the channel we are dialing is placed into an invisible ARI dialing
bridge. The bridge channel thread handles incoming frames from the
channel. If the channel is added to a real bridge, it is departed from
the invisible bridge and then added to the real bridge. Similarly, if
the channel is removed from the real bridge, it is automatically added
back to the invisible bridge if the dial attempt is still active.
This approach keeps the threading simple by always having the channel
being handled by bridge channel threads.
ASTERISK-25925
Change-Id: I7750359ddf45fcd45eaec749c5b3822de4a8ddbb
|
|
|
|
As res_pjsip_nat rewrites contact's address, only the last Via header
can contain the source address of registered endpoint.
Also Call-Id header may contain the source address of registered
endpoint.
Added "via_addr", "via_port", "call_id" to contact.
Added new fields ViaAddress, CallID to AMI event ContactStatus.
ASTERISK-26011
Change-Id: I36bcc0bf422b3e0623680152d80486aeafe4c576
|
|
There are a lot of verbose messages about Endpoint and Contact status
changes if there are many dynamic endpoints.
The patch sets verbose level 2 for Endpoint status changes
and verbose level 3 for Contact status changes.
ASTERISK-26055 #close
Change-Id: Ie64e261ddbbc41bfff0f0190241152cc123fe6d7
|
|
Fixed some bugs:
- create dirpath when save downloading message from IMAP storage.
- create IMAP folder if not exists when saving to IMAP storage
- check if file successfully opened before write to it
- some IMAP checks
- remove non-standard flag 'Unseen'
etc
Change to debug IMAP mm_status log instead of verbose.
Remove unused X-Asterisk-VM-Caller-channel message header
for security reason. The clients should not know name of peer/endpoint.
ASTERISK-26045 #close
Change-Id: I7f83d88b69b36934e2539c114b9fb612deed971b
|
|
The pjproject doxygen for rdata->msg_info.info says to call
pjsip_rx_data_get_info() instead of accessing the struct member directly.
You need to call the function mostly because the function will generate
the struct member value if it is not already setup.
Change-Id: Iafe8b01242b7deb0ebfdc36685e21374a43936d2
|
|
Add the option 'enable_callee_prompt' to followme.conf. Enabled by
default. If disabled, a callee is not prompted to accept or reject
the forwarded call.
ASTERISK-26064 #close
Change-Id: I0a8b19d4cf95c86a07c992813babb9e4a4acfff5
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
|
|
destroying."
|
|
|
|
|
|
worker_start checked for ZOMBIE status without holding a lock. All
other read/write of worker status are performed with a lock, so this
check should do the same.
ASTERISK-25777 #close
Change-Id: I5e33685a5c26fdb300851989a3b82be8c4e03781
|
|
|
|
Recent changes to res_pjsip_outbound_publish have introduced a
race condition at shutdown where an outbound publish may be shutdown
twice. In this case the first succeeds as a result of the unpublish.
In the second invocation since it's been unpublished a task is
queued to just destroy the client. This task holds no ref to the
publish and as a result the publish may be destroyed before the
task is run, causing a crash.
This explicit destruction task now holds a reference to the publish
to ensure it remains valid.
ASTERISK-26053 #close
Change-Id: I10789b98add3e50292ee3b33a55a1d9061cec94b
|
|
recording"
|
|
|
|
|
|
Invisible bridges function the same as normal bridges, but they have the
following restrictions:
* They never show up in CLI, AMI, or ARI queries.
* They do not have Stasis messages published about them.
Invisible bridges' main use is for when use of the bridging system is
desired, but the bridge should not be known to users of the Asterisk
system.
ASTERISK-25925
Change-Id: I804a209d3181d7c54e3d61a60eb462e7ce0e3670
|
|
|
