similar to: Some links on new docs asterisk org not working

On Wed, Aug 9, 2023 at 3:20 PM Dan Cropp <dcropp at amtelco.com> wrote: > I have a customer who just encountered a crash while running Asterisk > 18.17.1 version. > > > > I’m trying to adapt to the changes so not sure where best to look or how > to possibly report this. > > > > I started by going through >

I am working on a project that uses Asterisk ARI ExternalMedia request to stream the RTP audio from Asterisk to an UDP/RTP receiver project. Using slin16 format. 1) I believe I am seeing is a 12-byte header followed by 640 bytes of data. Is this correct? 2) Is there some place I can find a description of the 12-byte packet header fields? Dan -------------- next part -------------- An HTML

We have a customer who wants us to record anywhere from 2-4 participants on a call in stereo (as opposed to mono) quality audio. Some background.. We are using asterisk 16.6.1 We are also currently using AMI/AsyncAGI and ConfBridge to bring the parties together. I believe recording in the various file formats (based on extension), it's always recording in mono quality. My one thought is to

I was able to put the crash through the gdb on the original VM that encountered the problem. (Not sure why the VM I initially tried to analyze the crash dump on didn’t do this correctly, but not concerned about it now). It’s providing additional details. Would this be considered a better example of the crash? I will go through the version comparisons and see if there are any updates since

I have a customer who just encountered a crash while running Asterisk 18.17.1 version. I'm trying to adapt to the changes so not sure where best to look or how to possibly report this. I started by going through https://github.com/asterisk/asterisk/compare/18.17.1...18.19.0 to see if any of the changes seemed to apply to code reported by the backtrace. Entirely possible I missed something,

On Tue, Aug 22, 2023 at 08:50:03AM +0200, Ralph Boehme wrote: >On 8/21/23 22:55, Jeremy Allison wrote: >>On Mon, Aug 21, 2023 at 03:19:59PM +0200, Ralph Boehme wrote: >>>On 8/21/23 11:53, Jones Syue ??? via samba wrote: >>>>>OH - that's *really* interesting ! I wonder how it is >>>>>changing the SMB3+ redirector to do this ? >>>>

Pipeline #976539953 has failed! Project: libnbd ( https://gitlab.com/nbdkit/libnbd ) Branch: master ( https://gitlab.com/nbdkit/libnbd/-/commits/master ) Commit: 4e891bdb ( https://gitlab.com/nbdkit/libnbd/-/commit/4e891bdb37b62d3a11fc32e9170ed2a5df4a16c5 ) Commit Message: ci: Update to latest lcitool, for FreeBSD Yet ... Commit Author: Eric Blake ( https://gitlab.com/ebblake ) Pipeline

Thanks to those on IRC confirming quickly that this was not something supported (yet) in Asterisk. Below is a quick fix/patch to tcptls.c for Asterisk 18 against this particular provider. Dw static int check_tcptls_cert_name(ASN1_STRING *cert_str, const char *hostname, const char *desc) { unsigned char *str; int ret; ret = ASN1_STRING_to_UTF8(&str, cert_str);

On 8/22/23 18:02, Jeremy Allison wrote: > On Tue, Aug 22, 2023 at 08:50:03AM +0200, Ralph Boehme wrote: >> I don't get it. Iirc 8 MB is the default max io size the kernel client >> will use which is also, iirc, the limit of the protocol. > > Don't get what ? The FastCopy.exe above is using 8MB write sizes. sure, so? FastCopy.exe uses 8 meg, Explorer and Robocopy use

On Mon, Aug 21, 2023 at 03:19:59PM +0200, Ralph Boehme wrote: >On 8/21/23 11:53, Jones Syue ??? via samba wrote: >>>OH - that's *really* interesting ! I wonder how it is >>>changing the SMB3+ redirector to do this ? >> >>It looks like applications could do something and give a hint to SMB3+ >>redirector, so far not quite sure how to make it, >>per

On 8/21/23 22:55, Jeremy Allison wrote: > On Mon, Aug 21, 2023 at 03:19:59PM +0200, Ralph Boehme wrote: >> On 8/21/23 11:53, Jones Syue ??? via samba wrote: >>>> OH - that's *really* interesting ! I wonder how it is >>>> changing the SMB3+ redirector to do this ? >>> >>> It looks like applications could do something and give a hint to SMB3+

Hello virtio folks, I noticed a mismatch between the way the specification defines device-specific virtqueue indexes and the way device and driver implementers have interpreted the specification. As a practical example, consider the traditional memory balloon device [1]. The first two queues (indexes 0 and 1) are available as part of the baseline device, but the rest of the queues are tied to

On Tue, Aug 22, 2023 at 6:41?PM Danilo Krummrich <dakr at redhat.com> wrote: > Currently, NO_PREFETCH is passed implicitly through > drm_nouveau_gem_pushbuf_push::length and drm_nouveau_exec_push::va_len. > > Since this is a direct representation of how the HW is programmed it > isn't really future proof for a uAPI. Hence, fix this up for the new > uAPI and split up

Currently, NO_PREFETCH is passed implicitly through drm_nouveau_gem_pushbuf_push::length and drm_nouveau_exec_push::va_len. Since this is a direct representation of how the HW is programmed it isn't really future proof for a uAPI. Hence, fix this up for the new uAPI and split up the va_len field of struct drm_nouveau_exec_push, such that we keep 32bit for va_len and 32bit for flags. For

On Mon, Aug 21, 2023 at 03:18:50PM -0700, Daniel Verkamp wrote: > Hello virtio folks, Hi Daniel, I have CCed those involved in the free page hint and page reporting features. Stefan > > I noticed a mismatch between the way the specification defines > device-specific virtqueue indexes and the way device and driver > implementers have interpreted the specification. As a practical

Some background... We use AMI and AsyncAGI to be able to receive events about calls (and other Asterisk details) and control it from our application. Works great and have about 100 sites (some newer, some older) without issues. I was notified this morning about a customer who had something strange happen and I can't explain it. Asterisk 16.23.0 and PJSIP. Call comes into Asterisk. Asterisk