Whilst looking at the performance of the search for an available queue member
I've come across code that handles the ringinuse flag that seems to count busy
an inuse as the same, that doesn't make sense to me. I've also come across
very long standing code that means ringinuse disables state
The same rule in the RFC covers the case where Session-Expires is sent, but no
refresher is sent as covers the case where no Session-Expires is sent at all,
as long as session timers are supported:
UAC supports? refresher parameter refresher parameter
in
I don't believe that the code that adds Required: timers to a 200 OK response
will work, even in Asterisk 13, current branch version.
In my back port, it produces an error saying headers cannot be added after
lines have been added. The same conditions for this seem to apply in version
13:
In
Mark Michelson mmichel...@digium.com wrote:
Looking in my Asterisk 11 version of chan_sip.c, in start_session_timer(), the
first if block looks like this:
if (p-stimer-st_schedid -1) {
/* in the event a timer is
In trying to do a back port of some of the fixes to session timers, we
encountered a situation where multiple refreshes are sent in quick succession
(with incrementing CSEQ values). Asterisk survives for a little while, but
then gets very confused.
Looking at the code, it seems to me that
Looking at the branch version of 1.8, the following code in
handle_request_refer appears to blatantly breach the pre-conditions for
ast_cel_report_event, namely that no locks be held.
/* XXX - what to we put in CEL 'extra' for attended transfers to
external systems? NULL for now
Walter Doekes walter+asterisk-...@osso.nl wrote:
AFAICT, local_attended_transfer does that as well (locked by
[[djw]]
And it looks like handle_invite_replaces does, although the place I've found
has both relevant channels locked, so may be safe.
owner_chan_ref = sip_pvt_lock_full(p) in
Whilst trying to debug a probable race causing module reload app_queue to
lose a queue when it clashed with offering a call to an agent channel, I found
a potential race condition that still seems to exist in trunk. Unfortunately
this race condition seems to fail towards not setting the queue
We have a situation where about 1% of incoming 302 responses result in the call
failing as busy, rather than redirecting. We are using a heavily patched
1.6.1.0, however we have a theory for the mechanism that still seems to be
valid on Asterisk 12. Could anyone verify the analysis and
Richard wrote:
Without looking into the code, queueing a busy frame to wake up the read
thread and look at the call-forward string seems wrong. The null frame
should be queued instead.
This is the code from branch 11 SVN (branch 12 seems to be the same). Whilst
it is done as a drop
10 matches
Mail list logo
