mc_

I think you want to set the forwarded device's call_forward:{keep_caller_id:true} (assuming you're doing the forwarding server-side. Then look in your system_config's kazoo_endpoint doc for "should_add_diversion_header" and set it to true. `sup kapps_config set_default kazoo_endpoint should_add_diversion_header true` should work. See if the carrier likes that.

@Matrixdz2002 As @mat1010 points out, you can use the "rules" regular expressions to filter what types of numbers can be routed using a particular resource (carrier). See https://docs.2600hz.com/dev/applications/crossbar/doc/resources/ There's also a 'resource selectors' option: https://docs.2600hz.com/dev/applications/crossbar/doc/resource_selectors/ contributed to the community. May help you too (though I haven't personally used it). That should cover the "destination" portion of your question. For caller ID, you would need to setup the callflow(s) with branching based on the caller ID: https://docs.2600hz.com/dev/applications/callflow/doc/check_cid/ Using the match/nomatch branches, you could then use the "resources" callflow action and set an outbound_flag "use_c" or whatever, which the resource doc would need to have in its "flags" as well. See https://docs.2600hz.com/dev/applications/callflow/doc/resources/

wss://sandbox.2600hz.com:5065

I suspect you need to find out what is using the number, no? The number should have a "used_by" attribute that can hint at it. Or search your callflows. Did SmartPBX get opened on the account and auto-create them and you don't realize it?

@Ken Rowland it is my expectation that using the 'set_variables' callflow action with '"data":{"custom_application_vars":{"my":"secret"}}' will cause all subsequent call events for this call leg to include '{"my":"secret"}'. If you add '"export":"true"` then the bridged call leg should also carry them. If that's not the case, please open a support ticket so we can investigate. But we do have customers that rely on these CAVs being present and, AFAIK, we have not received additional reports of missing CAVs.

@simonp22 No not yet, sorry. It is not forgotten, just keeps getting trumped by other work. I'll throw this into the engineering pool and see if anyone else has spare cycles to look too. Otherwise I will try to get to it this week.

This guy's blog is great in general for SIP stuff but specifically https://andrewjprokop.wordpress.com/2013/09/23/lets-play-sip-tag/

I believe msg_id for call events is the timestamp from FreeSWITCH, at least in 4.3. So presumably msg_id + event_name should be "unique"?

Interesting that the mod_kazoo processes in your logs restart the event streams. I suspect your packet framing sizes are mismatched between ecallmgr and mod_kazoo. Check those settings (there's a recent thread about it) and hopefully that addresses the issue.

Thanks for the examples! I'll see if I can find time to try them out locally and reproduce the error you're seeing

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.

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...

What's `sup knm_converters available_classifiers` return?

Port 8000 is the API port, not the HTTP port for serving the MonsterUI Javascript, CSS, etc. If you just access http://${IP_ADDR}/ with no port or /v2 you should see the UI load.

What version of KAZOO are you running? Did you recently upgrade and not run `sup kapps_maintenance refresh` or `sup kapps_maintenance migrate`?

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).

AFAIR these are still using the FreeSWITCH say command so you'll need to look for a language pack for FreeSWITCH. Check the FreeSWITCH log of the call to see if it is using a URL (kazoo prompt file) or the 'say' command to be sure though.

Could be a ulimit issue? Check those settings, make sure you have enough file descriptors...

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!

@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.

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.

I would guess the "bridged" part is necessary for the export to happen, but I'm hazy on the details at the moment.

Sorry to hear, this is one of those cases where I think we've been in the weeds so long it wouldn't even occur to us to use the platform's hostname as a SIP realm for an account. Would love to see a pull request against https://github.com/2600hz/docs-sysadmin/blob/master/doc/install/install_via_centos7.md Put the text you wish had been there?

@Ken Rowland that particular PR was merged into the master branch (what is going to be 5.0). I'm not sure if there was a backport to the 4.3 branch so it will not be available until 5.0.

@Ken Rowland are you looking for some kind of macro-expansion to add the group ID? I don't believe those exist for custom application vars. Are you seeing any attempt in your KAZOO logs to set the CAV on the channel (should be in ecallmgr and FreeSWITCH logs at a minimum if KAZOO is trying).