DanH

Hi Community, back again this week with an interesting bit of structural information, this time about the order of precedence in setting and observing caller ID. As you likely know, there are many places to set a caller ID within an account, however in the case of a conflict or collision, there is an order of operations applied when determining what actually shows up on someone's device when a call is placed. We will refer to this as the "caller ID hierarchy", and below we'll describe how that flows and is set, in order of "least specific" to "more specific" (the "winning" definition is the one that is used/displayed): Account Level: Within Callflows > Account, you can set the caller ID; if no other caller ID is set, this is the caller ID that will be used. This will also be the caller ID set as the Main Number in SmartPBX, as seen below: User Level: Within Advanced Callflows > Users > Advanced > Caller ID, you can set a caller ID; this will override the account Caller ID and will be used when a call is made; this can also be set in SmartPBX. The following is the view from Advanced Callflows: Device Level: In Advanced Callflows > Device > Advanced > Caller ID, the caller ID may be set and is the most "specific" caller ID setting possible; this will override the Account and User Caller ID, and will be used when a call is made, this setting can not be set in SmartPBX: There you have it, the "order of precedence" for setting a caller ID and which will "win" when multiple instances are defined! If you would like to see this and other settings discussed and demonstrated in video format, head on over to Kazoo Academy: Bootcamp to sign up for our learning platform and observe all these features in SmartPBX and Advanced Callflows.

Hi Community! We're back with a setup- and devicement-management oriented bit this week, in the form of avoiding a security block on provisioning of new devices on accounts. As many here likely already know, a common scenario when setting up a new end user account (or managing an existing one) is to add and provision devices to an account under the reseller's supervision before shipping/delivering them to the end user. While this is an effective way to preempt any initial setup issues and do an initial quality check on the devices intended for end users, there is one thing to keep in mind: provisioning is a secure process that is connected to different mechanisms intended to prevent fraud or malicious actors from hijacking devices. Specifically, if the device is added to Provisioner and is not able to successfully provision within a certain time frame, the device will become "locked for initial provisioning", a status which will require unlocking the device in the Advanced Provisioner application. For more information about provisioning and the Advanced Provisioner app, we have a whole mini course on it in Kazoo Academy, click here for more information and registration! For now, what follows is a simple guide to manually setting a provisioning window of time of your choosing, avoiding the automatic device lock in case of excess time from adding to Provisioner app and first actual provisioning of device: --- When adding devices to Advanced Provisioner and before sending them out to the client, long delays before booting and provisioning the devices can cause the office site's IP address to get blocked by the security measures when they finally do receive the devices and plug them in. To avoid this issue, you can set a Provisioning Window in within Advanced Provisioner. In Advanced Provisioner, while in devices click on the “Set Provisioning Window” button: This will bring up a pop-up, where you can input the IP and a Provisioning Window in hours: And voila! Once you coordinate with your client about when they will be setting up the devices on site, you can set this window and allow for more room for error with scheduling and such, a quality of life measure that still maintains our security standards for provisioning measures.

Hi community! Back to announce the registration for our upcoming KAZOOcon hackathon, including the important event details, so please have a look at the following form to register for our exciting hackathon, to see what you can KAZOO! As a reminder, tickets are still available here: https://kazoocon.rsvpify.com/ Registration form link: https://forms.gle/kC7wftKNTr8z9H7TA Thanks for joining us, can't wait to see what you build!

Hi @Byron Knott, thanks for joining us!

Hello community, we have another TWIL installment for you here in the form of a specific softphone setup. Zoiper is a popular softphone with a large user base that many in the Kazooniverse have used with great success on the platform. Those familiar with our hosted platform also know that registering devices of all types to specific zones is a practice that can be helpful for testing or optimising different geographic factors. Here we have a brief guide on how to set your Zoiper softphone up on a specific zone as your needs dictate! In Zoiper, click on the 'gear' button next to the account you are using to open up the settings menu. See below: Once in the settings menu, click on accounts and select the account you wish to modify. Enable “use outbound proxy” and enter the zone you wish the app to register over, as seen below: On zswitch, our hosted platform, these zones are: us-east.p.zswitch.net us-central.p.zswitch.net us-west.p.zswitch.net And voila, your Zoiper softphone will now register specifically over one of those geographic zones!

Hello community, we're back with another installment of insightful TWIL knowledge, thanks again to our intrepid support team! This week we get a little deeper than we have so far: we're rolling up our sleeves and playing with APIs in this one, so please be sure you're familiar and comfortable with basic API usage concepts before diving into this one. As a reminder, the Kazoo Academy bootcamp course covers the basics of APIs for Kazoo and some basic concepts in this area (including using Postman), in particular Level 6: Basic APIs, so it might be worth a visit if you need a refresher or an intro into the world of APIs. If you've ever wondered about other possible use cases for the BLF functionality of modern office phones, and you happen to use our wonderful Call Center application, good news! You can set a BLF key to see if a user is Logged out a Queue, Away and Ready. In order to do this, you will need to configure a ‘Presence_ID’ in the Qubicle settings for the user via the API, also the user will need to be a member of a queue in call center. Using Postman you can pull up the users API by using the following path: http://{SERVER}:8000/v1/accounts/{ACCOUNT_ID}/users/{RECIPIENT_ID} Once the API is pulled up, scroll down to the Qubicle section and add: "presence_id": "Value", Value can be anything, but has to be unique to the user. See the below example: Once the Queue Presence ID is added to the user, you can use Advanced Provisioner to add the Queue BLF key by using the Presence ID: The BLF states correspond to the following recipient states: (Green)IDLE: logged out (Flashing Red)RINGING: logged in, but away (Red)ON-A-CALL: logged in, ready And there you have it: a clever use of BLF for a quick visual reference of queue status!

Welcome @HugoC and thanks for joining us in the community! Be sure to watch for updates on those releases and come back here to discuss them!

Hey @Skunkbeard and @tomas_, so I just checked with the team and the official response on this was as follows: Unfortunately due to the nature of the STIR/SHAKEN compliance requirements, the workaround proposed isn't possible for hosted accounts based on how the authentication works on our platform. However, this would be an option for Private Cloud and Global Infrastructure customers as they manage their own compliance with those requirements. I hope that's helpful in some way, and thanks for bringing this up, interesting area and use case!

@Skunkbeard Thank you for this! I was signed into my testing account for other shenanigans and didn't see this, sorry for the delay! I'm also going to ask the team about that workaround, that's an interesting one, I'll have to put on my robe and wizard hat to get into the Cabal of Fax archives but we'll see what we find. EDIT: I may have misread that a bit, the actual workaround would be for getting the call to be forwarded in that scenario of the number not complying with STIR/SHAKEN requirements (not being owned by the account), not exclusively for fax purposes though but as an example; still going to check on that with the team, still dressing up for it.

Just stopping by to say thanks for the input folks, I'm discussing then feedback with the team and am keeping tabs on this thread, just as a heads up!

Hi @AaronFM thanks for joining us; apologies for the delay here, this one slipped past me! That is an interesting use case and I am curious to know more, so I'm glad you've decided to enter the community and I hope this proves to be a resource to you in all your endeavors!

Hi @LogicalBot! Welcome to our forums and community. We're excited to have you here and for you to share your perspective from the Australian small business world, and I hope we can also be of service!

Hi all, Please use the poll and this thread as an opportunity to check in and let me know how we can improve the overall community experience here for all us Herzians, thanks for reading and for your time!

Hi all, TWIL returns from hiatus again this week with a bit of conundrum-clearing content for your consumption, specifically in the voicemail config sphere of things. I'm going to make two statements now: "Use Cellphone’s Voicemail" and "Require Key Press" affect the same function but are found in different apps within Monster UI. Requiring the keypress cannot also use the cell phone’s voicemail as you need to press 1 to accept the call, which will not work as a cell phone's voicemail system isn't capable of sending DTMF of 1 to "accept" the call to leave a voicemail. Additionally, to further clear things up, THIS setting in SmartPBX for the editing of a cellphone device...: Affects the same internal functionality as this setting for the same device as edited in Advanced Callflows: I hope that clears things up for everyone as much as it did me, a benign eccentricity that adds charm no doubt, but helpful for those making use of the feature!

Hi @voiceuser! Sorry I missed this intro of yours! We're pretty busy with Kazoocon preparations and such right now, which by the way if you're in the area at the time, GREAT way to get well immersed in the Kazooniverse! This year it's at the fabulous Palms in Las Vegas on October 23-25. To read more about the event, checkout https://www.kazoocon.com. To register, head to https://kazoocon.rsvpify.com/ As far as your use case, that makes a lot of sense from a workflow standpoint, definitely can understand the drive to get that setup process streamlined as you mentioned. I would suggest checking out the /Developer forums for help with that API angle, found here: https://forums.2600hz.com/forums/forum/35-developer/ Also, you might want to check out our CSV Onboarding application for more setup streamlining! Here is a link to some documentation about it (this is a little outdated, we are working on new documentation all the time though): https://forums.2600hz.com/forums/monsteruiapps/csv-onboarding/171_user-resources/ I hope that helps, and thanks for joining us!