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

amn

Members
  • Posts

    145
  • Joined

  • Last visited

  • Days Won

    12

Posts posted by amn

  1. Are you logged in as the top (superduper) user in master account?  You should see "+Add" option in Number Manager but I believe you only see that if you are superadmin or superduper.

    If it says invalid credentials then there is (obviously) something wrong with your credentials.  Make sure you are generating a hash using the proper user/pass.

    That screen shot is not telling me anything.  It looks like you are missing all the important bits at the beginning such as the generation of the user hash etc and then the actual curl command.

  2. Not sure what you mean by not being able to add numbers.  I just went to Number Manager > +Add and was able to add a number.

    To read about the API you can use these docs
    https://github.com/2600hz/kazoo/tree/master/applications/crossbar/doc

    Maybe start here for credentials
    https://docs.2600hz.com/sysadmin/doc/install/configure_kazoo/
    https://github.com/2600hz/kazoo/blob/master/applications/crossbar/doc/basic_auth.md

    You will probably want to look at using PostMan which can automate a lot of the things such as using credentials.
    https://docs.2600hz.com/ui/docs/using-postman-as-a-crud/

  3. There is an OpenSips module for CGrates that would probably simplify integration with Kazoo if it can be ported to Kamailio.

    ASTPP is actually a decent little project imo .  It's a little buggy but it works and pretty easy to modify.  Probably not that easy to integrate with Kazoo and probably doesn't scale all that well but works well with standalone Freeswitch.

  4. On 2/15/2018 at 2:00 AM, VincentdeWit said:

    Thanks for the tip! I've been using the template files provided by FusionPBX, they've saved a ton of time since they are already in their Github repo.
    I've been familiar with Twig, and using the node-twig implementation for templating. It's really easy to understand and one of the simplest out there.

    If you're looking into a NodeJS API, take a look at Cradle as CouchDB client.

     

    @Tom Hmm, I'll look into that one. The thing I'm more concerned about is security wise for provisioning, such as if I know a phone's MAC I can basically lookup every phone's SIP credentials. I could off-course apply IP address filtering (store an array of IP addresses in the account DB, but sounds too complex (how about different branches, remote working, VPN etc.)).

    FusionPBX templates appear to be using Smarty.  Did you convert them all to Twig?

  5. On 2/15/2018 at 2:00 AM, VincentdeWit said:

     

    @Tom Hmm, I'll look into that one. The thing I'm more concerned about is security wise for provisioning, such as if I know a phone's MAC I can basically lookup every phone's SIP credentials. I could off-course apply IP address filtering (store an array of IP addresses in the account DB, but sounds too complex (how about different branches, remote working, VPN etc.)).

     

    ACL (IP whitelist) for prevention.  For deterrent you can add a delay of several seconds.  Makes brute forcing much more difficult and less practical.  You can also code the software to only respond to phone user agents.  

    This software implements the delay and phone user agent trick.
    https://github.com/urueedi/kazoo-provision

    Anything that makes the hackers job harder and less efficient is worth doing.  The less low hanging fruit the better.

  6. 9 hours ago, VincentdeWit said:

    Been working on this for a while now, and found out that the existing solutions are a bit outdated.
    What we did is build a NodeJS API (based on Express) together with MongoDB where we store information such as MAC address, Account ID and Owner ID (if applicable). 
    Our beta solution now basically provides a few things;
    - Provisioning based on MAC address
    - Remote phonebook support linked to users and groups in Kazoo (CouchDB layer)
    - Custom editable fields, such as IP address, DNS, Language etc

    There still are some things that we're not sure of on how it would work best; such as security, scalability and overall performance.

    Would be happy to share code when it's fully up and running.

    I would be interested in seeing what you are doing on the back end.  What templating system are you using?  I am looking at maybe using Twig.  Using MySQL as the primary database and php-on-couch for tying in with CouchDB.

    https://github.com/PHP-on-Couch/PHP-on-Couch

    If you are stuck on how to do something have a look at how FusionPBX does it for an example.  The code on that project is fairly easy to follow.

  7. On 12/26/2017 at 10:37 AM, mc_ said:

    The wiki is in the process of being deprecated. Some of the pages were "auto-imported" into the docs site but require refreshing and updating to render properly. For instance, the SUP page can be found here. It needs love though; want to make the updates and issue a pull request? There's an edit link on the page if you're signed into Github.

    Those wiki pages are still what come up to the top most often on Google.  Not sure what the best solution is because I don't think github pages get the same SEO love from Google.  That new documentation system you guys are using also does not seem to show up much on Google searches.  Maybe it just needs a little SEO applied to it?

  8. On 1/22/2018 at 1:48 PM, Jack Noe said:

    Hi all.

     

    When listening to the voicemail's from my desktop phone, the system gives me the time the message was left, but not the phone number that left the message. so i cannot know who left the message.

     

    Any way how to add it, to receive the phone number as well ? 

    Does the number not show up in the GUI in Voicemail Manager?  I realize that what you are asking for is a voice prompt but having it in the GUI should make that need less important.

  9. 3 hours ago, cecchisandrone said:

    Anyone has successfully set zones? I'm trying to follow http://docs.couchdb.org/en/latest/cluster/databases.html but I don't understand how to modify _nodes database to add zone attribute. Am I wrong?

    /nodes is accessed via port 5986 (or 15986 if you are going through HAProxy).

    So from a web browser http://CouchDB_IP_Address:5986/nodes to access it via the Fauxton web interface.  That is assuming Fauxton is configured to also access 5986 by default as it is 5984.  I don't have an CouchDB install in front of me to check that. 

    If it is locked down you will need to know the user/pass for access.

    I believe you can also do it from CURL similar to the examples they give for front end configuration.

  10. Maybe DISA?

    https://2600hz.atlassian.net/wiki/spaces/docs/pages/11206689/DISA

    Only thing  I am not sure about is if the system can be made aware of what extension you want to masquerading as.  If you can masquerade as an extension, then you should be able to use feature codes.  If you are using IVR there might be a way to do it through that as well.

    Call-Forward
    Update Call-Forward
    *56
    Enable Call-Forward
    *72
    Disable Call-Forward
    *73
    Toggle Call-Forward
    *74
  11. On 12/18/2017 at 2:44 PM, Tom said:

    I'm running CouchDB 2 in production, and I haven't had any issues. I had the luxury of planning my first deployment around this transition, so I don't have any experience with the migration.

    I would be interested in your configs that are different from bigcouch.  Looks to be almost the same except for zones.  There is just one comment by the developer with one example but not explained in much detail.

     

  12. 12 hours ago, Uzair Mahmud said:

    @Anthony Manzella I see. Ok installing it right now.

    i had another question. Do you use a seperate ethernet interface for captagent to send packets to homer. I am guessing if  i use the same interface its going to decrease the number of calls throgh my voip ethernet interface by a little bit more than half unless i do some sort of compression on the data being sent.

     

    I could not install homer using your centos instructions.

    The ones that worked for me are these: 

    yum install redhat-lsb-core wget git 
    cd /usr/src
    wget https://cdn.rawgit.com/sipcapture/homer-installer/master/homer_installer.sh
    chmod +x homer_installer.sh
    ./homer_installer.sh

    Taken from Homer Git Repo

     

    Edit: 

    I also had to add the following two lines in sipinterface_1.xml to get the rtcp information working

    <param name="rtcp-audio-interval-msec" value="5000"/>
    <param name="rtcp-video-interval-msec" value="5000"/>

     

    Now freeswitch and captagent is sending rtcp information. It is ggetting saved in the databse with the correct corellation id.  I am stuck at not being able to view it with Homer gui.  

    I think one of the goals of HEP is to keep bandwidth low, so you probably don't have to worry about it adding too much extra traffic.  Another interface makes stuff more complicated so I would try avoid that if I were you.

  13. On 12/14/2017 at 1:22 AM, martin said:

    Changing )) haha that's old news, but it would be cool. I did see the http bookkeeper, and actually that's almost enough.

     

    I am trying to do something with http bookkeeper in combination with service plans and the API.  If there is a completely generic solution coming I might have to wait and see what that is all about.

  14. The billing stuff in Monster UI is designed for connecting to braintree and requires other things to be set up get that part working.  Braintree module does not run by default and you also need to add your braintree API.  I believe you also need to do things on the braintree end like create service plans.

    So most of those billing related things you see in Monster UI are there for use by 2600hz and anyone else who wants to set up all the braintree stuff with their own braintree account.

    If you are not going to use braintree you cannot use most of the billing things in Monster UI and need to develop those things yourself.

  15. On 12/12/2017 at 3:43 AM, martin said:

    Thats true, one could sent a

    1. specific header (or how we call that, flag?), depending if the carrier allows it of course. 
    2. Add an ip to your system and ask a Kazoo guru to explain how to force that ip to be used for this specific account.


    Inbound is no issue, but if Kazoo allows IP auth, and customers can bring their own carrier, then the risk is rather high to have duplicate ip adresses.
    If not 100% guarunteed. If u have 1000 clients, this problem will exist. 
    U could do smth with outbound CLI but that also depends on the provider and could be spoofed.

    I dont know how Kazoo handles this, but my brain does not see a solution other then stated

    10

    Kazoo does the same thing as the carriers. If you try create an IP auth device in callflow and then try create another IP auth device with the same IP (even if it is in a different account), Kazoo will give you a "SIP IP already in use" error.  

    Kazoo does not care about inbound IP from carriers as long as the IP is added to the ACL.  It knows which account to route the call to based on the DID number.  So again, that is the same as what most carriers seem to do.

     

  16. On 12/9/2017 at 7:10 AM, martin said:

    But if the carrier allows the ip to be used only once it should still work right? If its IP auth and the request comes from your server IP then it would be permitted.

    So u need to put the IPs of your kamailio server into the white list or ip list of your carrier.

     

    Im rereading the question, and have a feeling i did not really get the question ))

     

    If i want to use an outbound carrier for outbound calls, and they do ip auth, i add the IPs to their system and thats it. I can make calls.
    Inbound is indeed a matter of putting the ips from where the call will be setup in the Kazoo ACLs.

     

    Please let me know if i did not understand the question correctly

    If using IP authentication, the carrier is associating the IP with the customer account on their end.  So on the carrier end, you cannot have more than one customer account with that carrier using the same IP.  Otherwise the carrier would not know who to bill.  That is for termination (outbound calls to the carrier).  For origination (DID inbound) I am not sure if it would be a problem or not since the carrier knows which customers are using which DID's and should not care what IPs they are assigned to.

     

×
×
  • Create New...