[asterisk-dev] [Code Review] 4497: logger: init_logger_chain has unreachable code
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4497/ --- Review request for Asterisk Developers. Bugs: ASTERISK-24817 https://issues.asterisk.org/jira/browse/ASTERISK-24817 Repository: Asterisk Description --- init_logger_chain has a block of code to set a default console logger if logger.conf was invalid or not found. Since the code is unreachable, no logger channels to be created. This changes it so the default console logger is applied any time logger.conf load fails. Diffs - /branches/11/main/logger.c 432991 Diff: https://reviewboard.asterisk.org/r/4497/diff/ Testing --- Verified that nothing was logged to console with missing logger.conf, and that this patch caused console logging to be enabled in that case. Also verified that valid logger.conf was not effected. Thanks, Corey Farrell -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Regression issue] Garbage RTP data with Asterisk
On 02/27/15 09:11, Hans Petter Selasky wrote: On 02/26/15 15:19, Hans Petter Selasky wrote: On 02/08/15 11:24, Hans Petter Selasky wrote: On 02/08/15 08:45, Hans Petter Selasky wrote: On 02/08/15 08:44, Hans Petter Selasky wrote: Hi, From time to time the Asterisk RTP engine outputs some 4-byte ULAW packets (even when the data stream is ALAW), making me believe that the packets don't come from the source channel driver. The content of the packets is constant: 0x02 0x8A 0x02 0x80 These cause pops/clicks at the receiver. How can the source of these packets be found? Is there perhaps a race in Asterisk? Has anyone seen this issue before. I have a very old installation of Asterisk ~v1.6 which does not exhibit this issue. --HPS Forgot to mention: Seen with Asterisk 1.8 and 11 --HPS Hi, Some further investigation reveals that the payload type is 0 instead of 101 for DTMF. The 4 bytes are a DMTF packet and apparently this function has failed: /* Grab the payload that they expect the RFC2833 packet to be received in */ payload = ast_rtp_codecs_payload_code(ast_rtp_instance_get_codecs(instance), 0, AST_RTP_DTMF); --HPS Hi Matthew, Sorry for late reply, there was a problem with my list subscription. What is the DTMF payload code negotiated by both sides? How can I find this out using the asterisk cli? --HPS What I know is that uLAW and aLAW is used for the audio, and these invalid DTMFs cause regular pops and clicks in the audio stream. --HPS Anyone have any patches I can try? --HPS -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4465: Update the kqueue timing module to conform to current timer API.
On March 10, 2015, 1:26 p.m., Ed Hynan wrote: /trunk/res/res_timing_kqueue.c, line 240 https://reviewboard.asterisk.org/r/4465/diff/1/?file=71888#file71888line240 Portability: at least EVFILT_USER and NOTE_TRIGGER are not defined on all kqueue(2) systems. Justin T. Gibbs wrote: Which platforms are you referring to? OS-X added support in 10.6. Why they haven't updated their man pages is anyones guess: http://www.opensource.apple.com/source/xnu/xnu-1699.24.23/tools/tests/xnu_quick_test/kqueue_tests.c Ed Hynan wrote: OpenBSD and NetBSD. These do not have the user event filter. Ed Hynan wrote: I adapted a test program so see if uncollected EVFILT_TIMER events can make poll() return -- reliably. After testing on FreeBSD 9.0 and OpenBSD 5.5 (leaving NetBSD alone unless something seemed promising), I find that both will fail to return from poll initially; also both can be 'kicked' with a signal or a EVFILT_READ event -- but the result differs on the two systems, and this is undocumented and almost certainly undefined behavior and a side effect (and I assume the EVFILT_USER event was just a similar 'kick'). I haven't studied this timing code, so I shouldn't say much, but *if* res_timing_kqueue.c expects to return a kqueue fd for use with poll, and that poll will wake for EVFILT_TIMER expire events, then that won't work (judging by the test program trying to do just that). The technique in res_timing_pthread.c looks promising: return the read end of a pipe, signal poll by writing a byte, unsignal by consuming the byte (works in the test), and just using EVFILT_TIMER for the ticks. Justin T. Gibbs wrote: I'm not sure what you mean by 'kick'. I believe that EVFILT_TIMER events are reliable. If the application is slow to consume timer events, the kevent will accumulate them and the file descriptor for the kqueue() cause poll to return immediately. The goal of this change is to ensure that continuous mode is cheap and activates the file descriptor immediately. Setting the timer to run as quickly as possible just burns CPU cycles and means continuous mode blocks until the timer goes off at least once. Depending on the timer resolution of the system, this could be a long time. I need to do some more testing with the original driver to quantify this, but I believe this was the cause of my failures on FreeBSD. I coded up a version to use EVFILT_READ on a file descriptor of a closed pipe. This worked on FreeBSD. But since it consumes another fd, I think its still better to use EVFLT_USER if it is available. Ed Hynan wrote: Yes, EVFILT_TIMER events are reliable. I mean the interaction of kqueue with a timer and poll -- the expectation that poll will return for a kqueue timer expiration. kqueue_timer_fd(), assigned to ast_timing_interface kqueue_timing.timer_fd in svn trunk source, returns the kqueue descriptor (timer-handle) -- this code was not present in 11.* sources, so I haven't had the possible problems, but *if* the descriptor returned from ast_timing_interface kqueue_timing.timer_fd() is used with poll (e.g. main/timing.c), expectations might/will fail to be met. By kick I mean that in tests after poll initially fails to return for kqueue timer expiration, some other events e.g. a signal might be followed by poll suddenly starting to return for kqueue timer expiration -- like something stuck was kicked loose. My guess is that the user event you added was doing just that; but it seems to be unexpected side effect behavior. Regardless of all that, the idea that it's better to use EVFLT_USER if it is available would lead to substantially different code for the kqueue systems. Of course, it's up to asterisk-devs whether that is acceptable (I'm a contributor). I was wrong that poll does not return for EVFILT_TIMER, and of course that EVFILT_USER was some unexpected trigger. I had quickly added code to an existing test program, and failed to make sure the kqueue fd was assigned the kqueue() return when passed to poll -- I was observing poll on the wrong descriptor. Reduce my statements to the issue of portability, and pardon the noise. - Ed --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4465/#review14623 --- On March 13, 2015, 2:07 a.m., Justin T. Gibbs wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4465/ --- (Updated March 13, 2015, 2:07 a.m.) Review request for Asterisk
[asterisk-dev] [Code Review] 4496: res_xmpp: Buddies are always auto-registered when processing the roster
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4496/
---
Review request for Asterisk Developers and Joshua Colp.
Bugs: ASTERISK-24780
https://issues.asterisk.org/jira/browse/ASTERISK-24780
Repository: Asterisk
Description
---
From the issue:
{quote}
In both xmpp_roster_hook and xmpp_client_create_buddy, it ignores the
XMPP_AUTOREGISTER setting and sets buddy-subscribe = 1 if there is no
subscription.
This is a regression as it was already fixed in ASTERISK-14233. It is extremely
inconvenient to have Asterisk send Greetings! I am the Asterisk Open Source
PBX and I want to subscribe to your presence to everyone in your contact list.
I am sharing my own XMPP account with Asterisk (at a negative priority) and
this needs to be a recognised use case where Asterisk should not do
inappropriate things.
{quote}
We are indeed ignoring the XMPP_AUTOREGISTER setting. This is due to not
properly copying over the global settings to the client settings. Thanks to
Simon Arlott for providing the patch for this.
Diffs
-
/branches/11/res/res_xmpp.c 432991
Diff: https://reviewboard.asterisk.org/r/4496/diff/
Testing
---
Thanks,
Matt Jordan
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
