similar to: MOH with SIP

Hi, I've managed to get X-Lite (v2 build 1050) working pretty well with *, but am having problems with the DTMF signalling. I've used inband signalling with no problems on the uncompressed codecs (G711), but obviously this doesn't work with the compressed ones (GSM). However when I try to use RFC 2833 it doesn't seem to pick up "0" properly. For example if I dial the

Hi, I'm having a problem with DTMF tones from my SIP client apparently crashing the chan_capi driver. However I'm not sure whether this is a bug or misconfiguration on my part: if I set "softdtmf=1" in /etc/asterisk/capi.conf the problem goes away. Does the AVM B1 not support DTMF detection? The set up I have is using latest CVS (3 days old) running RH8 on a 933MHz P3. SIP

Hi, when I make a call, chan_capi always uses controller 2, and never uses controller 1 (so I have 4 lines for incoming calls, but only 2 lines instead of 4 for outgoing calls). this is with 2 AVM Fritz cards PCI. -- _______________________________ Simone Vasoli BK s.r.l. - Brain and Knowledge e-mail: simone.vasoli[at]b-k.it cell: +39 348 0830539 tel: 0187 1874200

What have people found to be the ideal setup for recording asterisk prompts? I'm looking for both the ideal application to record them in, the ideal format, as well as hardware (do I need a fancy studio mic or will a headset mic work?). Thanks, Justin

We've been using SIP with Asterisk for a couple of years now, and it's generally worked fine. However we're now trying to use a more complicated codec setup, and I've hit a problem with how codecs are selected that I can't get around. For a simple configuration: XLite > GSM > Asterisk where GSM is the _only_ codec selected on XLite, and in sip.conf we have:

I'm currently running firmware version 3.2 on my Cisco 7960. I've seen on the list that several people are running the 5.x latest versions. I've avoided going to higher firmware versions because I'm worried about potential problems or issues with the encryption mechanism used in the later firmware versions. (Once you go to an encrypted firmware version, you can't go back,

Does anyone have any opinions on the music on hold quality over G729? The stock files seem to sound terrible over it, this is enhanced further by calls coming from the PSTN via a Zaptel gateway. I am only using the stock wav files and have not attempted to use much else so far. I've ruled out timing issues on the system generating the MOH itself (ztdummy on the PBX itself, our Zaptel gateway

Yea, I have faked that with a silent mp3, but to do it right it should also be a config flag in the agent.conf file for each agent, prolly add another arg to each agent definition for the MOH class, & the arg 'none' means don't play music for that agent -----Original Message----- From: James Golovich <james@wwnet.net> To: asterisk-users@lists.digium.com

Type 'mpg123' at the Linux CL. (no quotes) If the version is anything other than 59r, you problem is solved. Go to the Wiki and search for Music On Hold. Do the install of version 59r ONLY as described in the docs. Cheers, Wiley -----Original Message----- From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Neil A. Hillard

Hi All, Sorry if this has been covered already, but I don't tend to follow this list as close as I should these days. Problem is that if a call comes in to a queue without option 'r' specified - moh plays as expected. Now, when that call is answered, all is fine. Trouble comes when that person then puts the caller on-hold. No moh is heard by the caller (in fact, they get silence).

Hi I thought I share this one, just in case this is an indication of some bug ... When I was trying to use music on hold at first, I didn't bother to copy any music into /var/lib/asterisk/mohmp3 since there was a sample- hold.mp3 in there which played just fine in a standalone MP3 player. But after uncommenting one of the lines in musiconhold.conf and doing reload on the console, there

Hello, i?ve a problem i dont find the reason for. An incoming call coming over iax is connected to a Sip phone. Until the phone picks up the call i could hear moh without problems. Then the phone sets the call on hold and opens another call to another extension. The incoming call hears the Hold music and also the call to the other extension hears another moh. Everything works so far as it

Hi, Has anybody else noticed that MOH does not play on parked calls in 1.6.2.14? Or is it just my setup? MOH seems to work in every other respect (Call Held or in-Queue), but when a call is parked, the logs show MOH being started, but the parked party hears nothing. The verbose logs show the following. Any thoughts on whet to check next? Thanks, Steve ### Call comes in here and is answered

I need to avoid MOH on my asterisk box, so i need to have a ringing tone when attendant transfer is made, or a call is on hold.. Is there any way to do that. I did not see a simple way to do that. Regards

I have an * setup with sip phones and sip fxo gateway. When a sip phone places a sip/fxo call on hold, MOH is very choppy. It looks like RTP has a real problem with timing if it is not receiving RTP packets. If the outside call that is placed on hold is not generating any audio, the sip/fxo gateway does not send * RTP packets. Is this valid? Is this a problem with the sip/fxo gateway or a problem

I am trying to music on hold but I am having all sorts of problems with it. I am running RH9 and the latest version of Asterisk as of yesterday. Here is what I did to test it: 1. I manually deleted the mpg123 softlink to mpg321. 2. I downloaded mpg123-0.59r-1.n0i.src.rpm, compiled and installed the the archive and loaded ztdummy.o module. 3. I threw a couple extra files in the mohmp3 directory

Would anyone mind emailing me, or maybe posting somewhere their music on hold .so file? thx -ben

I'm having an issue where SROA will throw away no-alias information on some loads after inlining, because the loads are derived from a store to an alloca which can be removed after inlining. The pointers that were originally stored into the alloca do *not *have any aliasing information - the only context that allowed me to assert aliasing was that the inlined-function guaranteed it to be so.

Tried a bunch of them there (x86-64, haswell, znver2) and they all defaulted to 4-wide - haswell additionally caused some extra loop unrolling but still with 8-wide pows. Cheers, -Neil. On Thu, Jul 16, 2020 at 2:39 PM Roman Lebedev <lebedev.ri at gmail.com> wrote: > Did you specify the target CPU the code should be optimized for? > For clang that is -march=native/znver2/... /

So for us we use SLEEF to actually implement the libcalls (LLVM intrinsics) that LLVM by default would generate - and since SLEEF has highly optimal 8-wide pow, optimized for AVX and AVX2, we really want to use that. So we would not see 4/8 libcalls and instead see 1 call to something that lights up the ymm registers. I guess the problem then is that the default expectation is that pow would be