Darren Schreiber

Yup that's the plan. This DDoS thing kinda crimped our schedule, but should be back on track next month I hope.

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.

Yup we are still working on completing this. I'm hoping it will launch in October.

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.

I would make sure you are on latest 4.3.x kazoo-kamailio-configs altogether. There was an exploit in the wild causing these crashes which we patched some time ago.

What Kamailio version though?

This sounds like a very old bug in an old version of Kamailio. We haven't had this in a long time. What is the version number?

Nothing has been reversed if that's what you mean. There may be waiting pull requests not accepted yet.

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)

No, it's not closed source. But we have paused on the public stuff to try and finish our app exchange. We are 10 years into this company and the entire point of the company was the app exchange, and it's still not done, so we're finishing that before we finalize and release 5.x

Greetings! We discussed this on last month's business partner call actually - I believe there's a recording of it floating around. But, no, not yet - but will be enabled next week or the week after. Look for an announcement! It's almost there.

Understood! Checking into that.

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

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.

Well, specifically you push the transfer key on whatever phone you're using - you'll get a dialtone. Then dial *3101, then transfer again. Then the call is parked in that slot.

Re #2 it is only available via API I believe. It is untested, so that's why it's not in the GUI yet. It is called max-members and you set it on a conference object.

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.

1) Correct. 2) It's how many people are in the bridge overall regardless of where they're calling from.

Nope, hasn't been much demand for it frankly but with all these folks WFH we are getting more folks interested again in conference features so we may revisit it. But at this time it's a no.

Isn't the callflow ID also in the CDR?

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.

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.

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.

Checking into this!

If you just add a callflow in advanced callflow of extension 0, it will also allow you to route it to whatever you want.