Jump to content
KAZOOcon: hackathon signup and details here! ×

Darren Schreiber

Administrators
  • Posts

    1,202
  • Joined

  • Days Won

    27

Posts posted by Darren Schreiber

  1. Just now, extremerotary said:

    Just adding my 2-cents in here; It's not up to 2600hz to build this. Every carrier charges VoIP providers on a per-location basis. So even if 2600hz built something to make it look like it was all one, they would be getting charged on the backend so that wouldn't make sense from a business perspective. However, i know for a fact that since Ray Baum's Act, Bandwidth,com (3 day outage, i know i know) has been actively working on a dynamic E911 addressing service. In this way, 2600 could pass additional, more specific data to the PSAP using SIP headers (Like "room 121") instead of requiring an e911 registration per room. Last I heard they were close. Might be ready at this point. Bandwidth wasn't the only carrier looking into this, so since 2600hz aggregates multiple outbound carriers, i'm sure they are working with one to develop this dynamic e911 farther and bring that to their customers!

    Actually we are already finishing testing and planning to release the dynamic address feature. It's not just a bandwidth.com thing. You can pass the geo-location lat/long or a full address at the time of dialing 911.

     

  2. 13 hours ago, Logicwrath said:

    The setting to allow the same account to register multiple times has been turned off since Kazoo essentially generates revenue based on the number of accounts that get setup.

    As I understand it, you can register multiple devices using the same account.  However, whichever device was the last one to check in to the cluster is likely the device that will receive any inbound calls.

    You can for example, create a generic account configured to dial out as a secondary phone number and register this one account onto multiple devices at the same time.  Any outbound calls placed to this account should work normally.   It would be the incoming calls that would generate a problem.  However, in this use case, you may not require inbound calling since the main priority is the ability to switch phone numbers for an outbound call easily.

     

    This is mostly correct. It wasn't about revenue, though. It was about controlling the features of the phone reliably from both the web interface and the phone itself - something that's impossible to do if the phones use the same registration. For example if someone enables call forwarding in their NY office to their cell while traveling to their SF office, then gets to SF, realizes they want to disable call forwarding, but it was set on their NY phone, now there's no way to do that if it's on the phone locally. But they'll still call support demanding we fix it (which we really can't, at least not without server-side sync which is model-specific and complex to build). So we decided early on not to do this.

     

  3. On 10/8/2020 at 3:21 PM, fmateo05 said:

    Frequently, i give some information to  asterisk users, in their forums about the existence of Kazoo as an excellent alternative, typically when they  have issues on their asterisk installs. Most of them don't know about Kazoo Platform and they resist thinking about a new learning curve.

    On some of those forums they forbid me to talk about alternatives, may be to avoid losing customers and so on. Anyway i am  finding out some other methods and also would give them a tour about migrating to kazoo platform.

     

    Thanks for this. We debated a migration tool once upon a time. I'd still be open to it. Our findings were that most people:

    * Hated re-recording prompts/greetings

    * Wanted their voicemail setup and greetings transferred over (but oddly didn't  care about their existing/old messages)

    * Wanted their dialplan to stay the same

     

    Those were the main sticking points unless somebody was a heavy fax user. With Kazoo's APIs I don't think it'd be that hard. I'll see what I can come up with. Of course Asterisk is a bit free-form textbox so it's not straightforward, but it does seem possible.

     

  4. I would hang on to those changes, or you can submit them, but we have to break up all the apps into individual repos anyway because that's how the app exchange works, so it may require some work to backport once we've got everything the way we want it.

     

    (Also, to be clear, I don't know what you mean by 5.0 branches - we've only had master which was 5.x)

     

  5. 1 minute ago, Ben Bradford said:

    Do you plan on pulling the commits made to the repos when they were broken apart back in to the combined kazoo repo as you have lost just over a week of commits by doing a revert and deleting the repos? 

     

    Ahh interesting, that was not intentional. Let me see what we can do about that.

  6. Hi gang,
                    We got some great feedback and excitement regarding the 5.x breakening. Thanks for that, that was great to hear.
     
                    However, after some internal deliberations we’ve come to the conclusion that we did it a bit prematurely. Sorry the whiplash and to  disappoint, but we are going to REVERT the repository breakup we just did and postpone it for a later date. But don’t worry, the master branch that it came from (in github.com/2600hz/kazoo) has also been restored.
     
                    We’ll be back to you with more news once we’ve had some time to re-group on this work.

     

  7. 1) We've heard this concern before, but it's been 15 years now and we've had exactly 0 instances of abuse. But, it's possible.

    2) The conference limiter has no relation to the trunks. You are limited by whichever is lower. You do need a trunk for someone to call in from the outside but let's say you have 5 inbound trunks and 5 local extensions  also  call in but your conference is limited to 8, well two of those people aren't going to be let in.

     

  8. Thanks, the remaining list is more inline with what I was thinking, I was surprised at some of the ones you crossed out. I thought maybe that was more a training issue or I wasn't understanding. So, that revised list helps a lot!

     

    We'll talk to engineering. We're sorting through a few launch issues right now that are particularly nasty so engineering has their hands a bit tied. Then we'll look at improvement requests for Q2/Q3.

     

    (Also great feedback! Thanks! Keep it coming!)

  9. Thanks for this nice list! It seems to be more an education thing, though, or maybe I'm a bit confused.

    If you use Call Center Pro and go to the Performance tab, the metrics you requested for # of calls a rep has taken, time they've taken calls, number of missed calls, basically most of the stuff you requested, is all there?

    Also for differentiation between missed and abandoned calls during and after biz hours, isn't that just two queues? The stats are inherently split out then...

  10. I don't think so. It would have to be on the Comcast equipment frankly. But if you wanted to try something, find the setting on your Cisco phone for marking/tagging packets and use value 46 as I mentioned. I believe that's correct anyway, someone else may have a better suggestion.

  11. This can be confusing but actually the flags have to be honored not just by your local network but by your ISP. Usually they're no, so this is not a useful setting.

     

    A good explanation if you want one:

    https://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/qos_solutions/QoSVoIP/QoSVoIP.html

     

    Expedited forwarding is typically value 46. So if you want to tag packets, use 46 as the value. But again, if it's not honored by anything on your network AND your ITSP/ISP, it's pretty useless.

×
×
  • Create New...