Jump to content

RuhNet

Members
  • Posts

    141
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by RuhNet

  1. An easy way to proxy WS to encrypted WSS is using HAProxy, thusly:

    listen kazoo-websockets
        bind *:7777 ssl crt /etc/ssl/yourcertificate.pem
        default_backend kapps-blackhole
    
    backend kapps-blackhole
      balance source
        option forwardfor
        option http-server-close
        option forceclose
        no option httpclose
        server kz1.z100-blackhole 1.2.3.4:5555 check
        server kz2.z100-blackhole 2.3.4.5:5555 check
        server kz1.z200-blackhole 123.123.123.234:5555 check backup
        

    Note that the certificate file is a full PEM file with cert, ca, and key all smashed into one file. Certbot, GetSSL, and my LEAPI system can all generate these automatically when using Let's Encrypt.

    You can also use Nginx to proxy WS to WSS, and an example is in the Switchboard readme file.

  2. @naveed6865The first thing I would look at is the network---CouchDB is not meant to cluster over a WAN network. So if your zones have a WAN connection between them, there can be network latency or lost packets that can messup cluster communication. 

    Next, you mention two nodes in each zone? I would check your quorum and W and R settings---if a node is temporarily offline, and there are not enough copies of data that can be accessed to provide a quorum, CouchDB will not be able to serve the data. (I don't think this would cause it to go offline in most cases, rather it would probably just error, but it's something to check.)

     

  3. I corrected the code to disable pagination on API requests. This was an issue if there were more than 50 devices on a system---the app wouldn't show them all properly. So you'll want to do a git pull to bring down the latest changes.

    Also, I found the delay before websockets kicking in only happens if you are masquerading---when you first login to the parent account, if you open Switchboard there, and then move to a child account, the websocket connection has to time out on the old account before it can be re-established on the child account you switched to. It doesn't not occur if you log directly into an account. I will see if I can modify the code so that an unsubscribe is triggered if the account is changed via a masquerade.

  4. @tomas_ @fmateo05 I have updated the README file now with correct instructions.

    You need to add the following line into your api block in the MonsterUI js/config.js file:

    socket: 'ws://mykazooserver.tld:5555',

    Or if you proxy websockets with TLS, which I strongly recommend:

    socket: 'wss://mykazooserver.tld:5443',

    Of course substitute the port for the one you actually use.

    Then make sure the port is open to the public in your firewall:

    firewall-cmd --permanent --add-port=5443/tcp
    firewall-cmd --reload

     

    I also found a typo in the app metadata file, so that is the reason the icon and screenshot were not being picked up @tomas_

    Sorry about that. I thought I had previously checked and corrected that but evidently not. Do a git pull (or delete and re-clone) and try re-initializing the app and it should work.

  5. @tomas_ and @fmateo05 I’ve noticed that sometimes web sockets subscription takes a minute or so to activate before events start flowing. I need to look more into that. 

    Also, I just realized I forgot to include something important in the installation instructions—you have to add your websockets url in monsterui config.js. Also, the web sockets port needs to be open in your firewall so the app can connect to it. I’ll update the readme file with proper instructions in just a bit.

  6. Hi all! I have released another Monster UI app that I think will be of use to some people. It is called Switchboard and is a real-time device/call monitoring app.

    You can view registered devices on the system, along with their owners, current extension, temporary hotdesk extensions. Call status of devices is updated in real time via websockets, along with an activity log, which can be collapsed if you don't need it. When the Switchboard app is first loaded, Crossbar APIs are queried to see which devices are currently registered, and then the channels API is used to set the current state of the devices. After that, websocket events via Blackhole update the devices visually as calls come in/out. You can see when a device rings, is idle, is answered, or is on hold., along with caller/callee name and number, call direction, and an in-call timer.

    https://ruhnet.co/blog/switchboard-kazoo-app-monster-ui

    Part of the reason I developed this app was for a client that uses a combination of hotdesking and normal extensions. Users and management were often confused about who was logged in where, and why they were getting calls for someone else (their device was hotdesked to another user and they forgot to logout). So, in addition to the real time call monitoring, this app gives a very clear visual indication of which devices are hotdesked, and which extension[s] are currently active on any particular device.

     

    Try it out and let me know what you think!

    Also, give me a GitHub star if you find it useful, and feel free to send pull requests if you make useful changes to the source code. I intend to continue development and add features over time.

    switchboard.png

  7. 23 hours ago, FASTDEVICE said:

    I believe you can use Transfer ** to send a call directly to voicemail. You may have to answer it first and then do the blind transfer, but maybe you can create a macro on the phone to accomplish the entire sequence on a single button. 

    This is what I would do---Polycom is extremely flexible with macros for things like this. You could program a button with a macro that answers the call with phone on mute and immediately blind transfers the caller to your voicemail. 

    Alternately, you could use the Channels API to get the incoming channel and reroute the call to VM when you dialed a star code. Might need Pivot or a web UI for this to work fancily but you maybe could do it simply with webhooks and the Channels API and a simple external PHP/Python script or small node app.

    But I would recommend just creating a macro on your phones.

  8. Yes, the UAC module would need to be loaded, but also some additional config. You add the registration details to the database. Check out the "Nick vs Networking" blog for more info on this--he has a very good UAC explanation and example that you can work from. Not for Kazoo specifically but vanilla Kamailio, but as far as the UAC config it should be the same.

    As for method 2, (using external Asterisk as "carrier" for Kazoo) yes you are correct.

  9. @Mehedi Hasan Tanim Although outbound registration is not supported with Kazoo, you can make it work by modifying the Kamailio config to use the UAC module. Alternately, (and this is probably the easiest way) you could place an external Kamailio/Asterisk/Freeswitch server outside of Kazoo and use it for the "carrier" for Kazoo; have the external server do your registrations and pass calls along to your Kazoo Kamailio server like normal carrier calls.

  10. Thanks @tomas_! I haven't implemented it yet, but using websockets is definitely next on my list for this particular app.  I have been busy working on my Kazoo phone provisioner so mostly stopped working on the call parking for now, but at some point I expect to resume and improve this app even further. I'm also looking at making an open source operator console style app. Not sure yet if I will expand this one, or do it in a separate app. 

  11. Great stuff, @Mehedi Hasan Tanim

    When I asked you to document this so that other people could benefit, I did not expect you to start from the beginning with auth and the Flowroute setup, I just meant the part we covered about the click2call, but this is fantastic. Bravo for your contribution to the community; I'm sure others will benefit now. Good job!

×
×
  • Create New...