Search results

Sorry, I was never ever to figure out what caused it, but haven't had it happen since. It could have been related to version. The client was originally on 4.4.6 server, but we have moved them to a 4.5.24 server. Not 100% sure that fixed it though. It was happening very randomly.

I managed to figure this out with some trial and error. I think the real issue was setting Extension to "auth_to_user" with the quotes. If I did it without the quotes, it wouldn't work. Odd, but at least it is working. Thanks for all the help.

So I spent some time with the trunk provider going over this. They tell me that the invite being sent is gw+<uuid of fusion gateway>+<phonenumber> From doing some googling, i saw a post about putting auto_to_user in the extension field in the advanced settings for the gateway. This does not...

Yes, that might be a better way to do it, my issue is I really don't want to do something "special" with the inbound route, as if I do someting else, I need to remember to fix it again. Is there something I can get the trunk provider to change, or something I can do with the gateway definition...

I am having an issue with a gateway with Jive.net (GotoConnect is the new name) An inbound call is passing the FROM information as the username of the gateway, then +phone number. Ex. 0zQFTo7cYVdESeD1fio3EK9TpYUP19+xxx5551212 I can't do alpha numberic in the destination number, so is there a...

That would be a PHP call to which script? I'm used to using a MTA (sendmail, postfix), so not sure what to call here to make it retry. Thanks.

I've noticed that if a voicemail email doesn't get delivered for what ever reason, it never gets retried. Is there a way to have it retry sending the emails? I'm running 4.5.24. Thanks

No. One provider for the phone lines.

Oh OK. I see you took out the "hangup_after_bridge" and "continue_on_fail" lines from the original route definition. Are they not needed? Thanks.

Not sure I follow. I'm still fairly new to digging into dialplans. So under the DialPlan -> Dialplan Manager menu, which item are you editing? The item for the Ring Group or something different? Thanks

Is that a ringgroup or an extension? Did you alter the XML directly or do it through the GUI of Fusion? Reason I ask is if I modify he XML directly of a ring group then make a change, those previous changes are gone. Thanks,

Hey @Nik3000 Here is the code for my email_recordings.lua script. Make sure to set the owner as www-data:www-data -- email.lua -- Part of FusionPBX -- Copyright (C) 2010 Mark J Crane <markjcrane@fusionpbx.com> -- All rights reserved. -- -- Redistribution and use in source and...

OK. I was thinking about modifying the dialplan for the ringgroup, but it doesn't show any of the lines in the page for it. If I go to the XML view I see them. My thinking is if I modify the XML side, it will get overwritten if I change the ring group. Am I correct in that thinking? I guess in...

Thanks for pointing that out to me. Would I want to change that api_hangup_hook or add one before ot after it for doing the email_recordings lua script? Thanks.

I managed to get this to work by adding the following lines to the user_record dialplan <condition field="${record_session}" expression="^true$"> <action application="set" data="email_recordings_to=email@domain.com" inline="true"/> <action application="set"...

Hey @mak_make Did you turn off all three CallBack events? I did get the issue with a message being resent every 5 mins a couple of days ago. I was able to stop it by restarting NGINX, but this will be better if it just doesn't happen. Thanks for the updated hook file. I'll get that in place...

UGH!!!! Don't I feel like an idiot. The message are actually getting through. I wasn't getting a notification for them in the GroundWire app, so didn't realize they were coming into the 1xxxxxxx verison of the number, not xxxxxxx version of the number. I'm sorry, but I guess it is working...

Should also say adding: fastcgi_buffers 16 16k; fastcgi_buffer_size 32k; to the nginx.conf file got rid of the upstream sent too big header while reading response header from upstream error. Thanks

Didn't notice there was actual Freeswitch logging for this as well. Here is that if it helps: 2021-05-03 14:20:19.673367 [NOTICE] switch_cpp.cpp:1465 [sms] DIRECTION: inbound 2021-05-03 14:20:19.673367 [INFO] switch_cpp.cpp:1465 chat console 2021-05-03 14:20:19.673367 [NOTICE]...

If I check the MDRS section in fusion, I can see all the incoming messages now, so I am guessing the hook is working to some extent. :)