Darren Schreiber
-
Posts
1,202 -
Joined
-
Days Won
27
Content Type
Profiles
Forums
Resource Library: Monster UI Apps for KAZOO
Events
Downloads
Posts posted by Darren Schreiber
-
-
The 162.242.163.176 address is just the proxy. The Central ones are hosted in a separate datacenter and don't really need prioritization frankly, the SIP packets should be fast enough.
I've never been able to get the RTP Status page on the Yealink to show properly until end of call, even on latest FW, but if it works for you that's great.
-
On 9/26/2017 at 8:18 AM, Logicwrath said:
Could this be an issue with the Kamailio configuration then? The vast majority of our calls when registered to US-CENTRAL are getting RTP media from SJC. When they don't get SJC they get EWR. However, we have not seen any RTP from ORD.
We have had to completely stop using US-CENTRAL.
us-central should be stable, but we did find a configuration issue where if ORD servers were maxed out they would failover to SJC. However, we also noted in your examples that you seem to be checking the RTP stats on the Yealink but that status screen doesn't update until your call hangs up. Can you detail exactly how you checked this?
us-central actually has our newest and best boards and network so it would surprise me if there was a real issue there.
-
2 hours ago, Uzair Mahmud said:
CGRates is a great piece of software!
I am wondering if something could be setup where you could post things that need sponsoring and people could donate however much they could through that. There could be a bar for each task that would show how much is collected and how much left to get to the goal. You could also integrate that with polling or surveys on what features people want the most and the list could grow organically that way.
We've actually considered this many, many times and looked at platforms like Tilt and even an open-source crowd-funding software. But the maintenance was very high and we don't want to hold people's money in "escrow" or deal with people who back out and we realized, how do we pay for the maintenance once it's built? So I have not written the idea off but it proved more complicated than we envisioned.
-
How does that accomplish telling the PSAP what room or floor the person is on?
-
We want to integrate with CGRates, I am considering working with them on it but just haven't found the time. They have approached us multiple times at conferences. Would be open to this if people want to sponsor it and then we can put a staff member on it, I would just open-source it once the time is paid off.
-
Also there's only like 3 actual certified VoIP PSAP interconnect companies, everyone is just reselling their stuff. I believe it's 911 Enable (now West?), Intrado (also now West?) and bandwidth.
-
1 hour ago, DinkyDonkey said:
I'm answering an RFP with a request for advanced e911 location based on the port the phone is plugged into. I imagine this can be done crudely with a unique e911 number for each building, floor, room (depending on granularity) and then updating the devices using LLDP and the Kazoo API.
Has anyone tackled granular e911 locations for larger buildings?
I've noticed in Bandwidth newsletters that they are working on this, https://www.bandwidth.com/9-1-1/
Hi there,
As far as I know, every number gets a unique address (even room number) so I am not aware of a way you can transmit the specifics of the room or location number with granularity at this time. If someone is working on that, it is news to me - right now they make money off each of those numbers so there's no motivation, to my knowledge, to fix that.We played with an idea at one point to change the APIs in realtime - person dials 911, we update the API with the latest address, pause for 2 seconds, then connect the call, but decided it was a terrible idea to have someone wait on the line, even for 2 seconds, when calling 911, so abandoned that (without the pause the databases didn't seem to update reliably enough / rapidly enough).
So I am unaware of a solution to this besides paying per number.
-
Thank you for all the input here so far.
-
Please note that the new recording API (as we have already told FastDevice) is NOT ready for production use yet, you should not be using it. We are still working on beta, pricing, permissions, etc. So things may change with it.
FastDevice has asked us to publish formal documentation when things are, and aren't, supported and with any strings, so I am working on that.
-
Avoids hackers scanning for open ports that reply, and then sending them harassing traffic where the phone rings randomly with fake Caller IDs like "test" and "100".
Basically it's a protection against crummy firewall/routers that are full cone NAT. See https://en.wikipedia.org/wiki/Network_address_translation for more.
-
I use 10000-65000
I suspect both handle and via rport but you can actually skip that option unless you have trouble with one-way audio.
-
Make sure to always:
* Change the local SIP port to a random even number
* Enable rport
* MOST IMPORTANT: Ensure your outbound proxy is a DNS name with SRV and that SRV is enabled (such as us-east.p.zswitch.net)
-
Both these items would need to be features the phone itself supports. The first one I've never heard of a phone supporting, though it may exist, because you are actually opening two calls at the same time, and outputting audio on two different components on the phone at the same time. I don't know of any phones that will do that.
The second one is also tricky - the phone has to acknowledge / send to the server when the handset is lifted, or automatically go on mute when on speaker and off mute when lifted. I don't know of any phones that will do that, either.
As far as I know this has no relevance to any software running on the server side.
-
Thanks @azefiel
It's important to note that what is being proposed in the tutorial above IS SAMPLES READY TO PLAY WITH! They are like a pre-loaded collection of examples (but real ones) that you can manipulate and use. They become a collection of every API.
I wonder if we can find somewhere central to keep the postman collections.
-
:-) This is why we have a forum now. I forget things.
(For those of you not aware of what Chris is doing, he just publicly shamed me in our company meeting for forgetting to nominate this feature. It has now been nominated).
-
That, I have no idea. If the config file was right in the GUI, we don't re-write the config file on disk unless you've made changes.
-
What does the phone show in advanced provisioner?
-
That didn't answer my question.
-
1 minute ago, Logicwrath said:
I am having issues now where we have G722 selected as the only codec for the phone in the device at Smart PBX. Then they will open a ticket that they cant receive phone calls and when I connect and logon to the phone it is set to only show PCMU in the phones settings. Not sure if this is related but this just started happening this week and the same client has already called twice.
Are you switching between SmartPBX's view and Advanced Provisioner? You can't do that. Once you have touched a device in Advanced Provisioner, ALL modifications to that device must be done in Advanced Provisioner from that point forward.
-
I swear we added this. It's been discussed like 50 times internally. That said, I don't see it. grumble grumble.
I'll bring it up at our next product roadmap meeting.
-
So actually we built the schemas so that they can have descriptions, and thus be "fed" into a friendlier tool. Let me talk to the UI team about what we can do here.
-
Someone rebuilt the old Kazoo UI developer app, perhaps we could merge that in and maintain it, if you really liked it?
-
I would not recommend that. You can make your own SRV records, but intentionally routing calls to a server that's not actually the closest to your customers doesn't make a ton of sense.
-
OK sounds good!
ACDC Strategy options
in General OS Kazoo Questions
Posted
ACDC is now maintained as a community project, I'm going to move this topic to the open source area so folks can respond there.