We are facing a strange issue where voice and screen sharing quality in MS Teams is bad over 1G wired connection and normal/good on WIFI.   Strangely this issue hits only specific clients. The AP and the clients are connected to the same access switch. and the subnets are also routed over the same WAN-connection.   I would say, 90% of the calls on wire are bad quality. When the user then disconnects the cable and connects to wifi, everything works fine. We were able to find out, that Teams is reporting a lot of udp packet loss on those wired calls. We also checked cable length and quality test result of the physical cable from when it was installed (10 yrs ago) and they are fine. The users are no complaining about any network issues when doing normal work with the computers. The clients are connected d directly to the access switch with no in-between-device like an IP phone or something.   We use GPO to set the right DSCP values on teams traffic and we are also setting the DSCP bits when teams traffic enters the access switch or any WIFI AP. Anyways, QoS should not be the point, because any interconnects along the path are far away from traffic congestion...   Any ideas how to investigate further? As a next task I would task an external company to reevaluate the quality of the physical cable connection... ... View more

Hi folks @Meraki   you just made my day with the news, that Cisco just acquired Modcam 😀 @Saralyn @GeorgeB Is there a roadmap of what we can expect from this deal? Will we finally get real retail analytics? And if so, when? 😉   I would appreciate to get some further information...     ... View more

I don't know how important this is to you guys out there, but from the talks that I had, I feel that many people are rather disappointed about what you really can achieve with the MV cameras in the sense of people counting and people detection.   if you don't want to read all the complaining stuff, just skip the next block 🙂   ---start of complaining--- Meraki continues to praise the analytics functions for the cameras. The truth from my point of view is, that the analytics features, especially for retailers are rather useless. Don't get me wrong, I am not here to just let out my frustration. I write this post in the hope, that some folks at Meraki @MeredithW @Saralyn  read this and start thinking about my suggestions.   I work in retail and I especially spoke to many other customers that do so also. Every one I spoke to stated, that they are not going to replace their existing security cameras with ones from Meraki. BUT IF the Meraki ones would have a significant additional benefit in retail analytics, especially in people counting and people analytics the would instantly go for it. I was at a Meraki roadshow event in 2019 November and Meraki praised some new MV model by showing a 3rd party dashboard which had counters for people in/out by gender. When we tried to implement this afterwards it turned out, that gender detection will just don't work.   Then I went to a talk with Todd Nightingale and asked him whether Meraki is going to implement some more analytics features into the camera software itself instead leaving all the analytics stuff up to the customers or 3rd parties. He stated, that Meraki is never going to do so, because it's not legal and he will go to jail then. I don't know how Axis does it, but anyways... He recommended to use the APIs to do analytics by ourselves or use 3rd party software.   Ok, wow, "challenge accepted" was my first thought and so I started to write own software. We have about 90 retail stores and we wanted to achieve these goals for a proof of concept (and that are the goals EVERY retailer wants to achieve):   count the INCOMING customers detect gender of customers count OUTGOING customers calculate, how long a customer stayed in the store   After some really short research I encountered these problems:   count the incoming customers would be possible by analyzing the MQTT feed of a camera by calculating the moving direction of a person If the MQTT receiver or the network wents down for some reason, you will lose data for that time period. detect gender of customers my approach was to analyze the MQTT feed, export all the single frames with the incoming persons and pass them to AWS or Azure face recognition (worked well in manual tests) you have to do a separate API call for every frame. The camera then exports each frame in maximum quality and loads it onto AWS storage from where you then can download it again and do some further processing We have 90 stores with >1000 customers a day. you will instantly run into the API call limit per second/minute waste of bandwith, as I would only need the exact person rectangle from the MQTT feed not to mention the privacy aspect of storing images of persons on AWS where they are downloadable for everyone. Yes, it's a crypted link, but security by obscurity is no security. duration of stay simply impossible, because the same person is a new person for the camera every time it enters the fov of a camera Axis does some kind of hash for a person and you're able to follow the person over multiple cameras   So to conclude I really don't believe, that it would be a big deal for Meraki to implement the following features, but a HUGE deal for your retail customers:   --- end of complaining---   implement an API call where you can request the camera to export multiple frames instead of just a single frame per call it should be possible to define multiple needed rectangles per requested frame, so that only these will get exported the requested frame rectangles should be stored on the camera instead of directly loading it onto AWS ( at least you should let the caller choose to do so) the requested frames should be bundled into an archive instead of exporting every one separate. make the API call async and give back a jobID or statusD. The caller then continues to poll and will download the export from the camera once its finished. implement an API call to delete finished export archives manually before they expire automatically if it's not possible to store the exports on the camera. encrypt them with a caller-provided password and THEN load it onto AWS. stream the MQTT feed to the dashboard and make it available for download for the last n days or store it directly at the camera. The stuff is ASCII and has a possible compression rate of ~95%   I think many retailers and 3rd party analytics developers would really appreciate this features. I also wrote those ideas to some folks at Cisco and Meraki directly in last years November, but I never got any update on this...                     ... View more