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

mc_

2600Hz Employees
  • Posts

    1,760
  • Joined

  • Days Won

    4

Posts posted by mc_

  1. @chinext its a good question and the short answer is no, KAZOO as-is doesn't support this use case. I'm assuming here that you mean a SIP device unknown to KAZOO sends an INVITE to to KAZOO for customercare@sip.realm.net and expects it to be routed.

    You ask about `customercare@publicip:5060` but there's no way to associate `customercare@publicip` with an account in KAZOO. Because KAZOO is a multi-tenant environment you need some kind identifier (a DID or an account's SIP realm) to identify the call as being for a particular account. KAZOO allows you to define carriers and add those carrier(s)' IPs to your ACLs to allow inbound calls from them. You then need to setup the DIDs in the database to be assigned to an account. Since `customercare` is not a DID it isn't searched for to associate with an account. Additionally, it is not "unique" so how would you handle two accounts defining a "customercare" callflow?

    Bigger picture, why can't your callers come through an authenticated portal of some kind? Why are they initiating calls to `customercare` and how are they doing so?

  2. By "funny money" I mean when you want to issue a service credit to your customer, say give them $20 for whatever reason, there's no credit card to charge or otherwise. It's just you updating their ledger with some "money". "real money" is when a CC is processed and those funds are added to the account to pay for services.

  3. Those look borked. See if you can revert the doc back a revision or two?

    {                                                                                                                                   
      "special_services_087_uk" : {                                                                                                     
        "friendly_name" : "special_services_087_uk"                                                                                     
      },                                                                                                                                
      "special_services_084_uk" : {                                                                                                     
        "special_services_087_uk" : {                                                                                                   
          "friendly_name" : "special_services_087_uk"                                                                                   
        },                                                                                                                              
        "friendly_name" : "special_services_084_uk"                                                                                     
      },                                                                                                                                
      "premium_uk" : {                                                                                                                  
        "special_services_087_uk" : {                                                                                                   
          "friendly_name" : "special_services_087_uk"                                                                                   
        },                                                                                                                              
        "special_services_084_uk" : {                                                                                                   
          "special_services_087_uk" : {                                                                                                 
            "friendly_name" : "special_services_087_uk"                                                                                 
          },                                                                                                                            
          "friendly_name" : "special_services_084_uk"                                                                                   
        },                                                                                                                              
        "friendly_name" : "premium_uk"                                                                                                  
      },                                                                                                                                
      "personal_number_uk" : {                                                                                                          
        "special_services_087_uk" : {                                                                                                   
          "friendly_name" : "special_services_087_uk"                                                                                   
        },                                                                                                                              
        "special_services_084_uk" : {                                                                                                   
          "special_services_087_uk" : {                                                                                                 
            "friendly_name" : "special_services_087_uk"                                                                                 
          },                                                                                                                            
          "friendly_name" : "special_services_084_uk"                                                                                   
        },
    ...

    How did you set these up initially? Lots of weird duplication going on...

  4. Depends on your definition of easy :)

    For the most control from your perspective, a Pivot callflow would allow you to maintain dynamic access codes and return the necessary callflow JSON to either complete the call in an authorized scenario, or respond/play media in an unauthorized scenario.

    If the access codes are more static, you could look at the menu callflow action and have the valid access codes be child branches of the menu action. Just back of napkin here but I could see:

    1. Set the callflow's "patterns":[..] to match international number formats, this way you won't conflict with extension of local dialing rules

    2. First action of the "flow" is the menu with a prompt to enter access code to authorize the call

    3. Children for each access code and a catch-all for invalid entries

    4a. Valid child branches will then have the "resources" action to route the call accordingly.

    4b. Invalid will play a media file or respond with SIP error codes.

     

    Maybe this can give you a little direction? You could also look at the DISA callflow to see if that would work better (similar step 1 though to match international calls).

  5. I think there's some confusion on terminology here; let's clarify a bit :)

    Pivot is an app that, on a per-call basis, sends an HTTP request to your server and receives callflow instructions (versus configuring the callflow statically). It has nothing to do with metaflows directly.

    So when you say "testing the metaflow through PIVOT" I'm not sure what that means.

    How are you initiating calls? What are the steps to recreate the issue you see? Basically, what are the steps in your two scenarios, from start to finish, for how the initial phone call is placed up until the call ends?

    Another thought, device ID is typically sent as 'Authorizing-ID' when the call is started by a known device, perhaps that is present for you to use?

     

    Finally, if you're in a bad spot, you might consider contracting with us for support, officially, and get dedicated engineering time to help you move forward. Obviously that's a business decision on your end but figured I'd mention it.

  6. It appears that app (not a 2600Hz monster app) is not compatible (at least not directly) with KAZOO 4.3:

    root@four monster-ui]# sup crossbar_maintenance init_app /var/www/html/monster-ui/apps/whitelabel http://192.168.122.119:8000/v2
    trying to init app from /var/www/html/monster-ui/apps/whitelabel
      failed to incorporate app because there was no app.json in /var/www/html/monster-ui/apps/whitelabel/metadata

    Unless there are missing steps to getting that metadata directory populated, anyway. Compare to SmartPBX's: https://github.com/2600hz/monster-ui-voip/tree/master/metadata

    For the Spanish stuff, I can only point to Monster's docs: https://docs.2600hz.com/ui/docs/internationalization/

    In any case, I think it is important to distinguish between MonsterUI (the web frontend) and the KAZOO backend - they are two distinct entities. But I also think the internationalization capabilities of Monster have improved (we have more native Spanish speakers on staff so hopefully that's the case :) ).

    Thanks for sharing what bogged you down. Hopefully you'll give it another shot at some point!

  7. The control queue is "ecallmgr@sandbox.testcomp.com-ecallmgr_call_control-<0.363.4>-35669c98". This tells you that the control queue is on the "ecallmgr@sandbox.testcomp.com" Erlang VM, an "ecallmgr_call_control" process at PID "0.363.4". Your logs, afaict, don't include the logs for that PID. You may need to increase ecallmgr's log level. sup, by default, talks to kazoo_apps@{hostname}. You can include "-necallmgr" to run commands against the ecallmgr VM: "sup -necallmgr kazoo_maintenance syslog_level debug" for instance.

  8. @Guillermo Prado sorry to hear your frustration with the platform. What in particular was out of date or poorly documented for you? What was hard that you thought should be easier? Would be great to know where to direct some attention.

    For reference, https://docs.2600hz.com/dev is refreshed every time a commit is merged into the master branch of KAZOO so it should always reflect the latest and greatest. Admittedly there is still some work to be done to backfill more information but we need to know what people are using so we can focus there.

  9. Possibly permissions on the database files themselves (I think they're under /srv/dbs ?). Try accessing a single bigcouch node and see what its logging.

    Also, n=4 (or any even number) is problematic in a network split. It is generally good to have n be odd to make it more likely to have a majority on one side of the split.

×
×
  • Create New...