Search results

You can change the console loglevel with "/log <log level> ".

You could whip something up with "bind_digit_action" that invokes a lua script. It should be relatively simple to just reuse the send_email function that the voicemail script uses. https://freeswitch.org/confluence/display/FREESWITCH/mod_dptools%3A+bind_digit_action

Ah, good catch. I always get the delimiters mixed up, should've looked that up before posting.

Is it possible one of your UA's is forwarding the call? If you are using the "simultaneous" strategy fs will blindly follow any redirect from the UA. Have you tried "enterprise" origination? This will bridge each channel in a separate thread and ignore redirects. In my experience, this is...

When you set the Hold Music in the destination does it actually change the XML in associated "inbound route"?

Yeah advanced -> sip profiles.The auth-calls param is what tells the profile to do digest authentication on inbound invites. The 487 is the "challenge" from freeswitch, a normal UA will respond to the 487 with a hash of it's creds and nounce string(sent in the 487). The only way that a profile...

If you cannot anticipate the ip signalling originates from, you will need to use the external context. Allowing 0.0.0.0 is a terrible solution, since it allows anyone to assume the role of any extension on your pbx without authentication. If you had the same trouble (487 response to an invite)...

Yes

It looks like you are trying to route calls from your carrier directly to the internal context. The only way I can think of that you could get this to work would be to add the carrier IP to the "domains" ACL. It would be much easier if you just used the external profile, and terminate calls...

Yeah, you are really opening yourself up to some serious toll fraud. If you disable authentication on the internal context you're going to get hacked very quickly. I would recommend pointing inbound calls from the provider to the external profile on 5080. Once you get a better understanding of...

Post some logs or a siptrace or at least some more details about your configuration. No one is going to be able to help you without more information.

A default fusionpbx instance has an internal profile that runs on port 5060. The internal profile is pointed to each domains "authenticated context". This will always respond with a 487 which informs the client to perform digest authentication. The UA is expected to send another invite with a...

Those are all response codes that end a transaction. Unfortunately that does nothing in the way of helping to narrow down your problem. I'd recommend installing sngrep on your server and start by posting a screen shot of the dialog between your server and the provider.

You're dialing *22 and it's asking for a password still? Hard to say, that should definitely work. You'd have to look at the log to see what is going on exactly. Maybe the cache isn't getting flushed when you update the GUI. You could check the cache file to verify it matches up to what you...

The tag should be "action" not condition. Like this:

Freeswitch documenting is pretty sparse and hard to come by in a lot of cases, but the dialplan wiki is excellent. I'd read this a few times and try to understand it, it will help with stuff like this ALOT...

You need to set it inside a condition that is actually matched. If you are dialing *22 that bottom condition never gets parsed. It's also in the wrong spot. You need to set the variable before invoking the lua script. I would set it in both condition blocks before the "lua" action.

It's pretty clear that the setting the "agent_authorized" channel var bypasses the auth in the login script: /fusionpbx/blob/master/app/scripts/resources/scripts/app/agent_status/index.lua You need to make sure to add it to an extension that is actually getting parsed. Easiest way would be add...

Sounds like a firewall may be closing the port. You most likely need to do some kind of UDP hole punching. Have you made sure "nat-options-ping" is enabled on the profile? I think you can turn it on per extension as well by enabling "Force ping". If NAT pinging is already on you could also try...

Hmm hard to say just from the pics. I would verify the call center is running. You can check this by running "callcenter_config queue list". Otherwise I might be able to help narrow it down with a CDR example, or some logs would be even better.