mc_
-
Posts
1,765 -
Joined
-
Days Won
4
Content Type
Profiles
Forums
Resource Library: Monster UI Apps for KAZOO
Events
Downloads
Posts posted by mc_
-
-
@Eduardo Almeida The "easier" option might be to set the syslog logging level to debug for a time, capturing the logs you want, then using tools like grep to extract the log lines you're interested in.
In general log lines will contain the call-id (or API request-id) and the erlang module / line number in the source file where the log line was called, followed by the message.
You should be able to "attach" to the running Erlang VM to run your trace command - my guess off hand is the trace is tied to the PID you start the trace with and, when your erl_call is done, that PID (and trace) die. Why the node is unresponsive after that I don't know.
Aside - 3.18 last got attention in 2015. You might want to encourage time/money to be spent upgrading (or investigating hosting with us) as the scalability and feature set of latest KAZOO versions (4.3 currently for community members, 5.0 for paid members) are leaps and bounds better than the 3.x series. If you are comfortable talking about the custom code and its goals, we could also see if you can use stock KAZOO now as well.
Welcome to the land of Erlang; its the best koolaid of any language out there! (probably)
-
RECOVERY_ON_TIMER_EXPIRE generally points to a firewall issue on the client side. See https://freeswitch.org/confluence/display/FREESWITCH/Hangup+Cause+Code+Table
Glad you got it sorted on your end!
-
Outbound calls from the phones take a different path through KAZOO. But, knowing they can make calls means their credentials are likely correct.
For inbound calls, you need to check the "Call History" in SmartPBX for those calls and see if there are "b-legs" generated to the devices. Check the hangup cause to give hints on why the call wasn't delivered. If this is your KAZOO cluster, you can check logs from FreeSWITCH and Kamailio for the SIP side.
-
You may want to investigate the phone's REGISTER sequence here. We've seen some softphones that send a REGISTER for 300s then immediately follows up with a REGISTER with no Expires header which KAZOO treats as a deregister.
-
Just to be an agent of chaos, work commitments have changed such that Wednesday 10 isn't a viable time now (and actually Tuesday at 9:30 has opened back up again).
So Tuesday 9:30??? :)
-
Leaning Wednesday 10:00 pacific myself, least often to have a conflicting meeting these days.
We'll see if more folks trickle in with requests; will update the calendar here on the forum once we solidify something.
-
The module will look for a child branch in "children" that matches the value found at "variable"'s path in the "scope" data structure.
So if "scope" is "custom_channel_vars" and "variable" is "authorizing_type", the module will look for children based on "authorizing_type" (like "device", "resource", etc) in the call's "custom_channel_vars" JSON object
-
-
Firewalls with SIP ALG typically target UDP (and maybe TCP) packets destined for port 5060 on the remote side.
When ALG can't be turned off at the client site, moving traffic to port 7000 (a typical alternative SIP port) makes the packets pass through the firewall unmolested.
Adding TLS obviously encrypts the packets to keep them from being mangled as well - not required to move to 7000 to do this. Not sure if there's a standard or convention, but I think TLS-enabled connectivity targets ports 5061 and 7001 on KAZOO: https://github.com/2600hz/kazoo-configs-kamailio/blob/69840f0c5a11237b1b216072e411d3d98df006eb/kamailio/listener-defs.cfg#L9
-
What is KAZOO doing at this time? There are routines that run monthly for updating account balances and things like that; could also be that your server is underpowered
-
Check /etc/kazoo/bigcouch/local.ini the database_dir config: https://github.com/2600hz/kazoo-configs-bigcouch/blob/master/bigcouch/local.ini#L16
-
The API is the callflows API. These are actions within the "flow" of a callflow.: https://docs.2600hz.com/dev/applications/crossbar/doc/callflows/
About callflow structure: https://docs.2600hz.com/dev/applications/callflow/doc/
-
Your best bet for a system reset is, on each couch server, delete everything in /srv/db then restart kazoo-bigcouch. Then restart kazoo-applications to re-initialize system databases.
-
Also, is the network between the zones experiencing issues? Could be a failure to communicate and sync with the other zone.
-
I can't answer an ETA as its outside my purview; I can only say that I'm very annoyingly asking the same questions internally. I have assurances that code/applications in 4.3 will resume their open status in 5.x when we're given the go-ahead.
-
On 4/4/2022 at 4:28 PM, Bitrate said:
Greetings and thank you for making such a great open source project!
We're also using the open source version and are interested in purchasing apps from you guys. Whats going on with this and the open source 5.0 release? Also, whats the timeframe on the 4.3 re-release with all the apps?
4.3 remains open. Aside from high priority bug fixes and such, that branch is "done". So the latest 4.3 RPMs represent the end of the line for that development.
For 5.0 + purchasing private apps, there should be annoucements at this year's virtual KAZOOCon. We're anxious to get 5.0 back into public repos but want to make sure as many issues are ironed out before doing so.
-
@jeroen what version of KAZOO are you running? Your log line numbers don't match up to recent 4.3 so its hard to say if your crash has been fixed already.
-
The virtual KAZOOCon this year should have some announcements in that regard.
-
Have you compared the call logs of the working and non-working calls? I'm surprised the a-leg's CAVs have your value in the answered call, and don't have the CAV in the unanswered. I would expect the CAV to be set on the a-leg even before the PIVOT request is made. Of course, click2call might be messing that up since it does use loopbacks.
-
Any in particular? A few are exported across the bridge but most pertain to the leg itself and shouldn't be exported. You can see the bridge strings have the exported CCVs on them when creating b-legs.
-
-
use_local_resources:true will check the account for carrier docs; use only if the account itself has carriers defined.
DIDs on the system are forced outbound by either carrier module = knm_local OR "force_outbound" set to true (I think just those two).
Try `sup stepswitch process_number {DID}` and see if the output includes forcing the DID offnet. If using local resources, I think you can add the account ID as an argument after {DID}.
-
When the endpoint with "push" settings is being built, the code doesn't know yet if the SIP device itself is registered or reachable yet. So the "push" options are delayed 5s to allow the SIP device a chance to be contacted. If there's no registration or the network doesn't work to deliver the call to the SIP device, the "push" device is called (meaning push notification sent and Kamailio is ready and waiting for the SIP device to register its new location on the network.
-
When you have push configs on a device, KAZOO will create two endpoint configs for FreeSWITCH/Kamailio - the "real" device and the "push" device. KAZOO gives the "real" device 5s to answer the call before initiating the push notification to allow for network shenanigans.
Raise log level of a specific module
in General OS Kazoo Questions
Posted
@Eduardo Almeidacircling back, great that you got into some Erlang code!
Future versions of KAZOO have this tracing functionality added too.