Jump to content

Darren Schreiber

Administrators
  • Posts

    1,202
  • Joined

  • Last visited

  • 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. 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)

     

  4. 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.

     

  5. 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.

     

  6. 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.

  7. 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.

  8. 5 hours ago, esoare said:

    Well @avig2 you may want to wait. There seems to be some problem with Advanced Provisioner at this time. Not sure if anyone else could verify

     

    @Plau ^^^^ not getting configs to phones/changes. 

    This is not correct. Provisioner is working. As noted in your ticket to support, this seems to be isolated to some issue possibly related to Polycoms and you downgrading the firmware.

    Provisioner is not down. Your comments have caused some FUD in the community, please be careful with any unproven assumptions.

×
×
  • Create New...