Skip to content

3.19.15
Compare
Choose a tag to compare
@k-anderson k-anderson released this 10 Feb 00:15
· 235 commits to 3.19 since this release
3.19.15
416cb12

Kazoo Changes

Changes to 3.19 after version 3.19.14

Resolved Tickets

Blocker (1)

  • KAZOO-3247 As a developer, I would like smart pbx to send me "enabled = true" so that the provisioner knows that the line has been configured

Major (1)

  • KAZOO-3290 When listing port requests of descendants, the API sends back a list of all accounts, even those without port requests

Normal (11)

  • KAZOO-3300 handle sip unregister
  • KAZOO-3295 As a developer, I would like to issue metaflow commands against the b-leg of a call with metaflows configured at the account level
  • KAZOO-3293 eavesdrop: call redirection
  • KAZOO-3258 BigCouch can return 409 but still store the document which does not flush the cache
  • KAZOO-3237 As a UI developer, I want a way to search for callflows by both their name and number(s), so that I can implement a usable search feature in the Callflows App
  • KAZOO-3234 As a system admin, I would like Doodle to stop trying to start when access is refused by the broker so that my logs don't fill up with errors
  • KAZOO-3209 Konami transfer takeback not working as expected
  • KAZOO-3169 Crossbar bug handling invalid request to post resoruces.
  • KAZOO-2592 When filling a port via the porting manager the numbers should be listed
  • KAZOO-472 Support an option in the timezone on the device section to override the account level setting
  • KAZOO-3125 TIcket to track issues with init scripts in centos 6.5

Trivial (1)

  • KAZOO-3276 As a UI dev, I want a "Content-Disposition" header when requesting the cdrs as a CSV file, so that the browser can correctly interpret it

Change Details

KAZOO-3247

Summary:
As a developer, I would like smart pbx to send me "enabled = true" so that the provisioner knows that the line has been configured

Description:
Currently, all lines are disabled by default. I would like smart pbx to include the enabled = 1, for true, when the device is initially created.

"settings": {
"lines": [
{
"basic": {
"enable": "0",
....

Reporter:
Ricky Ing <[email protected]>

KAZOO-3290

Summary:
When listing port requests of descendants, the API sends back a list of all accounts, even those without port requests

Description:
It would be better to only send back the accounts with existing, port requests, using this format:

[
{
id: {{account_id}},
name: {{account_name}},
port_requests: [
{{port_requests}}
]
}
]

Acceptance criteria:

  • send only accounts which contains port requests,
  • use the new format to send the data.

Reporter:
Joris Tirado <[email protected]>

KAZOO-3300

Summary:
handle sip unregister

Description:
some devices send unregister (REGISTER with expires=0) but we keep the registration active.

Reporter:
Luis Azedo <[email protected]>

KAZOO-3295

Summary:
As a developer, I would like to issue metaflow commands against the b-leg of a call with metaflows configured at the account level

Description:
It appears that when bridging to devices, a metaflow request for the b-leg isn't sent when the account is configured for metaflows. It should!

Reporter:
James Aimonetti <[email protected]>

KAZOO-3293

Summary:
eavesdrop: call redirection

Description:

Reporter:
SIPLABS Communications <[email protected]>

KAZOO-3258

Summary:
BigCouch can return 409 but still store the document which does not flush the cache

Description:
Sometimes we got conflicting error when updating a doc and we have not figure out the exact root cause. But we do notice that normally the 1st "POST" was successful based on the "pvt_modified" field but somehow we still got 409 error. The real problem is all the "POST" against the same doc after the 1st one failed with 409 and those 409 were real(doc was not updated). I think the current cache mechanism cause this. For example for doc XYZ, the current revision is 7 in both bigcouchDB and cache. We issue a "POST" request and the revision become 8 in bigcouchDB but somehow we get 409 error. Since the cache will not be cleaned in case the operation failed(it is a fake failure in this case), all the following "POST" operations will fail with 409 because they are all based on the old doc(revision 7) in the cache.

So is it possible to clean the cache on receipt of 409 on kazoo like what is happening for successful "POST" operation. At least make it a operation so we can set.

Reporter:
Karl Anderson <[email protected]>

KAZOO-3237

Summary:
As a UI developer, I want a way to search for callflows by both their name and number(s), so that I can implement a usable search feature in the Callflows App

Description:
Right now, the search API allows us to search for callflows by "name", but not by "numbers" (which is an array).
We want to be able to search by both, and moreover by both at the same time (as in "look in both name and numbers field for a match for the searched value").

Reporter:
Maxime Roux <[email protected]>

KAZOO-3234

Summary:
As a system admin, I would like Doodle to stop trying to start when access is refused by the broker so that my logs don't fill up with errors

Description:
When Doodle is configured with default creds, it will try, ad-nauseum, to connect to the broker even though it will never succeed. When the broker returns "ACCESS_REFUSED" as in the log line below, Doodle should log loudly (lager:warning or lager:error maybe) that the creds are wrong; Doodle should then stop trying to access the broker.

2015-01-13T13:45:07.168330-05:00 apps001-staging 2600hz[4387]: |00000000000|wh_amqp_connection:320 (<0.31754.6>) failed to connect to 'amqp://user:[email protected]:5672/babble' will retry: {auth_failure,"ACCESS_REFUSED - Login was refused using authentication mechanism PLAIN. For details see the broker logfile."}

Reporter:
James Aimonetti <[email protected]>

KAZOO-3209

Summary:
Konami transfer takeback not working as expected

Description:
Takeback (*1) works fine as long as the transferee did not yet pickup the call (during 'ringing'), but if used during the conversation of transferer and transferee the call is dropped and the caller is left on hold waiting forever.

Reporter:
Arne van Balgoijen <[email protected]>

KAZOO-3169

Summary:
Crossbar bug handling invalid request to post resoruces.

Description:
Cross bar returns 500 error on invalid json (gateways in this request was incorrect as it should be an array of objects). Instead of returnign an error, the request passed JSON validation and caused an error on the server side. Reqeust was definitely invalid, but it

Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|api_resource:101 (<0.17350.36>) PUT: /v1/accounts/97b2b81afa212847f3a8484ee18830b0/local_resources? from 10.26.0.100
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|api_resource:156 (<0.17350.36>) run: known_methods
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|api_resource:176 (<0.17350.36>) run: allowed_methods
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|api_util:181 (<0.17350.36>) application/json content type when getting req data
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|api_util:443 (<0.17350.36>) request has a json payload: {"data":{"name":"offnet 0","makebusy":{"test":true,"gateway":true,"proxy":"10.26.0.127","register":false},"gateways":{"enabled":true,"server":"10.26.0.130","prefix":"^\d+$"}}}
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|api_util:463 (<0.17350.36>) request envelope is valid
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|kazoo_bindings:679 (<0.17350.36>) matched [<<"local_resources">>,<<"allowed_methods">>,<<"">>] to [<<"local_resources">>,<<"allowed_methods">>,<<"v1_resource">>]
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|api_resource:219 (<0.17350.36>) adding cors headers
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|cb_accounts:957 (<0.17350.36>) account 97b2b81afa212847f3a8484ee18830b0 db exists, setting operating database as account%2F97%2Fb2%2Fb81afa212847f3a8484ee18830b0
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|api_util:652 (<0.17350.36>) using auth token from header
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|kazoo_bindings:679 (<0.17350.36>) matched [<<"authenticate">>,<<"">>] to [<<"authenticate">>,<<"v1_resource">>]
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|cb_ip_auth:88 (<0.17350.36>) attemping to authenticate ip 10.26.0.100
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|crossbar_doc:361 (<0.17350.36>) getting start_key from request: undefined
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|crossbar_doc:320 (<0.17350.36>) not enabling pagination
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|crossbar_doc:269 (<0.17350.36>) limit: undefined page_size: undefined
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|crossbar_doc:295 (<0.17350.36>) paginating view 'accounts/listing_by_ip' from 'accounts', starting at 'undefined'
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|crossbar_doc:803 (<0.17350.36>) applying filter fun undefined and maybe qs filter: false
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|kz_buckets:116 (<0.17350.36>) bucket 10.26.0.100/97b2b81afa212847f3a8484ee18830b0 missing, starting
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|cb_token_auth:159 (<0.17350.36>) checking auth token: '468a07846ec080074fae7403c07592f9'
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|cb_token_auth:203 (<0.17350.36>) no restrictions, check as object
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|kazoo_bindings:672 (<0.17350.36>) exact match for v1_resource.authenticate
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|kazoo_bindings:679 (<0.17350.36>) matched [<<"authorize">>,<<"">>] to [<<"authorize">>,<<"v1_resource">>]
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|cb_media:140 (<0.17350.36>) failing authz media: [{<<"local_resources">>,[]},{<<"accounts">>,[<<"97b2b81afa212847f3a8484ee18830b0">>]}] <<"97b2b81afa212847f3a8484ee18830b0">>
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|cb_modules_util:332 (<0.17350.36>) checking for superduper admin: 97b2b81afa212847f3a8484ee18830b0 (account%2F97%2Fb2%2Fb81afa212847f3a8484ee18830b0)
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|cb_modules_util:337 (<0.17350.36>) the requestor is a superduper admin
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|cb_simple_authz:130 (<0.17350.36>) authorizing, the request does not contain any system administration modules
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|cb_simple_authz:56 (<0.17350.36>) authorizing the request
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|kazoo_bindings:672 (<0.17350.36>) exact match for v1_resource.authorize
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|api_util:737 (<0.17350.36>) is application/json acceptable content type: true
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|api_resource:352 (<0.17350.36>) run: content_types_provided
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|api_resource:429 (<0.17350.36>) run: languages_provided
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|api_resource:441 (<0.17350.36>) adding first accept-lang header language: en-us
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|api_resource:470 (<0.17350.36>) run: resource_exists
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|kazoo_bindings:679 (<0.17350.36>) matched [<<"local_resources">>,<<"resource_exists">>,<<"">>] to [<<"local_resources">>,<<"resource_exists">>,<<"v1_resource">>]
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|api_resource:482 (<0.17350.36>) requested resource exists, validating it
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|kazoo_bindings:698 (<0.17350.36>) routing v1_resource.validate.accounts matches *.validate.accounts
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|cb_accounts:957 (<0.17350.36>) account 97b2b81afa212847f3a8484ee18830b0 db exists, setting operating database as account%2F97%2Fb2%2Fb81afa212847f3a8484ee18830b0
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|kazoo_bindings:698 (<0.17350.36>) routing v1_resource.validate.local_resources matches *.validate.local_resources
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|kazoo_bindings:648 (<0.17350.36>) unable to find function clause for lists:any(#Fun<cb_local_resources.0.20374944>, {[{<<"enabled">>,true},#12 {<<"server">>,<<"10.26.0.130">>},#12 {<<"prefix">>,<<"^\d+$">>}]}) in lists.erl:1158
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|kazoo_bindings:654 (<0.17350.36>) as part of cb_resources:validate/1
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|kazoo_bindings:655 (<0.17350.36>) st: {cb_local_resources,check_for_registering_gateways,2,[{file,"src/modules/cb_local_resources.erl"},{line,46}]}
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|kazoo_bindings:655 (<0.17350.36>) st: {kazoo_bindings,fold_bind_results,5,[{file,"src/kazoo_bindings.erl"},{line,577}]}
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|kazoo_bindings:655 (<0.17350.36>) st: {lists,foldl,3,[{file,"lists.erl"},{line,1197}]}
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|kazoo_bindings:655 (<0.17350.36>) st: {kazoo_bindings,fold_processor,3,[{file,"src/kazoo_bindings.erl"},{line,691}]}
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|kazoo_bindings:655 (<0.17350.36>) st: {api_util,validate,1,[{file,"src/api_util.erl"},{line,800}]}
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|kazoo_bindings:655 (<0.17350.36>) st: {api_resource,does_request_validate,2,[{file,"src/api_resource.erl"},{line,484}]}
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|kazoo_bindings:655 (<0.17350.36>) st: {cowboy_rest,call,3,[{file,"src/cowboy_rest.erl"},{line,972}]}
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|api_resource:494 (<0.17350.36>) failed to validate resource
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|api_util:1036 (<0.17350.36>) halting execution here
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|api_util:993 (<0.17350.36>) generating error 500 init failed response
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|api_util:1039 (<0.17350.36>) setting resp body: {"error":"500","message":"init failed","status":"error","request_id":"6668635f3767f38447892b84d0851b3c","auth_token":"468a07846ec080074fae7403c07592f9"}
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|api_util:1043 (<0.17350.36>) ensured CORS headers are on the response
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|api_util:1045 (<0.17350.36>) setting status code: 500
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|api_resource:145 (<0.17350.36>) PUT request fulfilled in 11 ms
Dec 3 22:15:09 test 2600hz[1433]: |6668635f3767f38447892b84d0851b3c|cb_token_auth:114 (<0.17354.36>) auth doc is too new (2205s to go), not saving

Reporter:
sean <[email protected]>

KAZOO-2592

Summary:
When filling a port via the porting manager the numbers should be listed

Description:
When customers file a port request they expect to be able to preemptively create callfows or assign them to PBXs. At the moment you can not do this if the number was submitted to the porting manager.

Update the system to add numbers that are being ported to the account phone_numbers document. If the port fails they need to be removed.

Reporter:
Karl Anderson <[email protected]>

KAZOO-472

Summary:
Support an option in the timezone on the device section to override the account level setting

Description:
Any way to have the auto provisioning pick up the time zone from somewhere we set up? Right now I have yealink T22 phones and the provisioning is working great however it keeps resetting the time zone to PDT (we are in EST). Even after I manually set it on the phone it eventually goes back to PDT. Thanks.

Reporter:
Brian Sloan <[email protected]>

KAZOO-3125

Summary:
TIcket to track issues with init scripts in centos 6.5

Description:

  1. on linode recently I ran an install of kazoo, we found that after installing freeswitch would not start and was issuing errror "/etc/init.d/functions: line 181: 8828 Segmentation fault (core dumped) $cgroup $nice runuser -s /bin/bash "

This was due to on old version of the initscripts on linode:
initscripts-9.03.40-2.el6.centos.1.x86_64

Next I updated all of yum repositories using:
yum -y update
yum -y groupinstall core
yum -y groupinstall base

which upgraded init scripts to:
initscripts-9.03.46-1.el6.centos.1.x86_64
This breaks kz-ecallmgr and kz-whistle_apps init scripts which produce error:
Starting ecallmgr: /usr/bin/dirname: extra operand &amp;.pid&#039; Try/usr/bin/dirname --help' for more information.

to fix this I manually downgraded to the only working verision of initscripts that i can find (which fortunately is what comes with centos minimal currently).

The only version thus far I have found to work was:
initscripts-9.03.40-2.el6.centos.4.x86_64.rpm

Putting in this ticket so when this comes up 6 months from now we have a solution. I would start advising operations/customers not to do yum update -y or to yum lock initscripts-9.03.40-2.el6.centos.4.x86_64.rpm prior to installing the update.

Reporter:
sean <[email protected]>

KAZOO-3276

Summary:
As a UI dev, I want a "Content-Disposition" header when requesting the cdrs as a CSV file, so that the browser can correctly interpret it

Description:
When requesting a CSV file for the "transactions" API, the response headers include:
Content-Disposition: attachment; filename="data.csv"

Please add a similar response header (perhaps with "cdrs.csv" as a filename?) to the cdrs API ( /accounts/{accountID}/cdrs?created_from={from}&created_to={to} ) when it is called with the "Accept" header "text/csv".

Reporter:
Maxime Roux <[email protected]>

Maintenance/Community Commits

Assets 2
Loading