Before I left Cisco, I was doing a rotation with an Advanced Services project to get a better understanding of the delivery aspect of the Contact Center ecosystem. In one of the customer calls, they mentioned the use of Okta as their Identity Provider and the need to use SSO for their UCCE environment. Immediately the TAC engineer thought "this is unsupported" based on the compatibility matrix and what my interactions had been but it got me thinking to what would be require especially since the 11.6 release had big claim that it was protocol based implementation.

Being someone who lives by the lab, I got to work.

I immediately spun up a dev account on Okta and some IdS servers, rooted boxes, tested configurations, and looked through plenty of logs.

Tl;dr - UCCE integration with Okta. CCEAdmin, Finesse, CUIC, and even ECE works, CCMP does not. UCCX uses the same backend, so it also works.

Contact Center SSO with Okta Identity on

This was my last article to be written and published on but one of the most fun and interesting problems I had a chance to work on the side with. One of the biggest challenges was my Cisco lab had some interesting proxy settings that required some fine tuning and showing some BU folk that had attempted this but failed that this would actually work.


Note: This was a proof of concept article. This was tested for functionality and failover with a few agents but was not thoroughly vetted in pre-production or production environments.

Last week Wink released an interesting article on their blog regarding home automation and smart homes. It reads off more as a marketing tool than statistics but still some interesting numbers.

  • Almost half (48%) purchased connected product to save energy followed by 44% to keep home safe

  • 57% of people have forgotten to do a routine household task in last 6 months.
    -51% turning off light
    -29% locking main door
    -24% closing garage door

  • People have a desire for monitoring
    -63% make sure home isn't broken into
    -38% to check in on pet
  • 36% of Renters would pay more to rent a home with smart products as amenities.
  • Renters would pay on average of 5% more in rent for smart homes
  • 63% of millennial said they've forgotten to lock front door in last 6 months.
  • 34% of Americans believe it would cost $5000 to turn home into smart home
  • 9% of Americans believe it would cost $20000 to turn home into smart home
  • Wink says most users start out with 4 products with an average cost of 200 bucks.

This is fascinating. The price points that some people think it takes to get into automation is crazy.

I started off with Hue starter kit and my home came with Ecobee3 system. Once I was gifted my Echo I felt like I had a proper smart home because I could use my voice instead of apps and the home finally felt "smart" at that point. Obviously my home system has grown but it's still nowhere near the $5000 mark but I also don't think $200 will get you a decent experience.

My recommendation for folks getting into smart home:

  • Basic
    • Google Home or Amazon Echo (I prefer the Home)
    • Hue Light starter kit (3 lights + hub)
  • Once you get the hang of it
    • More Google Homes or Amazon Dots/Echos
    • More bulbs
    • SmartThings Hub
    • Smart Outlets (TP Link makes a great one for 25-30 bucks)
    • GE Smart Light Switches
    • GE Fan Controllers
    • Smart Doorlocks
    • Video Doorbells
    • Garage door openers
    • Much much more.

Note that once you get into the home automation grind, you tend to start buying more interesting gadgets. It is an addiction that hamper the pocketbook but that the wife can benefit from too at the end of the day.

Link to blog post - Blog
Link to full data - PDF with more stats

With Home Automation and Internet of Things (IoT), there is always a concern over security. As a user of Ring Pro, a thread on reddit's /r/homeautomation caught my attention when a user found that the Ring Pro was sending packets to China.

/u/sp0di posted:

So recently installed a ring doorbell and found some interesting network traffic.
At random intervals, it seems to be sending a UDP/1 packet to (China). All other traffic goes to AWS.
Anyone have any thoughts to iot devices calling back to China

This caught my attention so I sent a tweet out to Ring with a link to the thread and never had a chance to look back. After doing so, I was somewhat alarmed at what their VP of security had to say:


Hi I'm the VP of Security at Ring and I thought it might be helpful to give you all some background on what you are seeing.

Occasionally at the end of live call or motion, we will lose connectivity. Rather than abandoning the entire call, we send the last few audio packets that are corrupted anyway to a non-routable address on a protocol no one uses. The right way to do that is to use a virtual interface or the loopback to discard the packets. The choice to send it to somewhere across the world and let the ISP deal with blocking is a poor design choice that the teams on working on addressing ASAP.

From a risk/disclosure perspective, it's relatively benign but like the everyone else, when my team first saw it in the wild we had similar concerns.

i will circle back when we have updated firmware.


I'm not a security expert, but I smelled some nonsense being spewed. Luckily, /u/33653337357_8 also felt the same and went through the post and laid out some concerns.

This is ridiculous. You are trolling, right? Let's pretend you were even going to do this ridiculous technical implementation and you didn't have an explicit loopback. Why can't you just drop? Why would you pick some random address (not even RFC1918)? Why not just send it to the IP address of the Ring device itself? Or how about the default gateway? Why not and maybe it makes it out to be blocked by an egress filter but at least it doesn't get to a routable public network.

The state of IoT security is already poor - and this is is what Ring does to deal with "end of call" packets? Come on.

**Later edit**:

Sorry Matt, but I am going to have to pull your response apart a bit more here.

This is what the traffic looks like (from /u/sp0di):
    10:06:12.263764 6c:0b:84:f9:df:fc > 90:6c:ac:84:51:9e, ethertype IPv4 (0x0800), length 214: (tos 0x0, ttl 64, id 6080, offset 0, flags [DF], proto UDP (17), length 200) > [udp sum ok] UDP, length 172

    13:10:22.224408 6c:0b:84:f9:df:fc > 90:6c:ac:84:51:9e, ethertype IPv4 (0x0800), length 214: (tos 0x0, ttl 64, id 5547, offset 0, flags [DF], proto UDP (17), length 200) > [udp sum ok] UDP, length 172

You state....
Occasionally at the end of live call or motion, we will lose connectivity. Rather than abandoning the entire call, we send the last few audio packets that are corrupted anyway to a non-routable address on a protocol no one uses.

This is not a non-routable address ( This is owned by Baidu.
    % Information related to ' -'
    inetnum: -
    netname:        Baidu
    descr:             Beijing Baidu Netcom Science and Technology Co., Ltd.
    descr:             Baidu Plaza, No.10, Shangdi 10th street,
    descr:             Haidian District Beijing,100080
UDP is a protocol no one uses? Do you mean port 1 (tcpmux)? What exactly happened to your end point (the other host) and why aren't packets just continuing to be sent there, even if they are disregarded on that side?

"we send the last few audio packets that are corrupted anyway to a non-routable address on a protocol no one uses"
"The choice to send it to somewhere across the world and let the ISP deal with blocking is a poor design choice"
are mutually exclusive statements.

How does a non-routable address make "somewhere across the world" so an "ISP [can] deal with blocking"?

**Edit #2**

It has now been confirmed by two users that Ring is using a fixed source port, destination, and destination port. This means that Ring is effectively poking a UDP NAT hole that would allow return traffic to traverse the NAT gateway and reach the Ring.

Protocol: UDP
Static source port: 51506
Static destination:
Static destination port: 1

In a very theoretical scenario, let's say this transmits periodically (which it does), then this would keep open a NAT translation on your edge router and many common NAT devices will use the same OUTSIDE source port if it isn't already in in use for translation.

Traffic sourced from and destined for yourip:51506 would reach the Ring device. Let's now pretend the Ring has a backdoored firmware that is simply waiting for a UDP packet to show up and provide an IP for the next command and control channel. In theory, it would only require 2^32 packets to hit every host on the Internet. You can now simply spray every host with one packet and wait to see who shows up.

I'm going to assume this isn't a backdoored firmware, but it very easily could be and the attack vector looks plausible.

**Matt, I think you need to provide a little more information. This isn't adding up.**


What's concerning is that a VP of Security said that throwing packets onto the internet and hoping they get dropped is better than locally disposing of them on a null interface or with a static route on the device itself and that leaving a port open on your egress gateway is not a security concern.

The above is very concerning especially with the Vault7 leaks just a few days ago. Now I will try not to attribute malice to what could be an oversight but I would hope that someone at Ring would give a hoot about securing their devices and properly routing data themselves. Hopefully they fix this and take a look at other security concerns that may be brought up.

In the mean time, I am trashing all packets for via an ACL and plan on taking some pcaps to verify that nothing is making it to the outside.

Full reddit thread

EDIT: To follow up on this topic, I ran around 15 different calls through my Ring Pro with motion activation and calling using a live stream but did not see any packet destined for There may be a specific trigger for this behavior that is not easily reproducible but a few folks on reddit were able to reproduce this but am reaching out to Ring to see if this was fixed or if there is a plan to address this.

EDIT 2: I reached out to Ring for comment and received the following response.

Hello Pavan,

Thank you for contacting Ring Community Support. My name is Genero.

Our development team is fully aware and is hard at work in finding a solution to the packet routing issue you mentioned above. We expect the firmware to be released by the end of this month. We do not have an exact release date but will have more information on this subject matter as we draw towards the end of this month.

We appreciate your patients and for being a valued neighbor in the Ring Community. If you have any other questions or concerns please let us know.


Ring Community Support

At least that's a start.

I've subscribe to a food delivery service called HelloFresh (referral link for free trial). They send recipes and ingredients every week for my wife and I to turn into meals. It's a great service because I come in contact with ingredients I typically wouldn't pick up and we eat fresh and healthy meals at least 3 times a week. Also on the rare occasion when some ingredients are missing or spoiled, we get to play Chopped like on Food Network!

Over the past few weeks, I have had some problems with deliveries. It is frustrating because it's not cheap and the grocery shopping for the week is done with 3 full meals from HelloFresh in the equation. The problem with deliveries has been that the food arrives late and in yesterday's delivery, it didn't even arrive until a day late.

This got me thinking. I know a few folks who personally emailed CEOs of companies that they've had grievances and suggestions for and had pretty decent responses. With that fresh in my head I thought it would be a perfect chance to reach out to the HelloFresh team with not only a complaint, but a suggestion that can help quality control. I originally wrote this long letter saying they have a guy write a script that can parse the pick up time and the delivery time and see if that data is useful. But after typing it all out, it looked simple enough and figured, I may as well brush up on my Python and show them what I mean. was born as well as the first actual post on this blog in years.

import requests
import re
import urllib.request
import datetime
from datetime import datetime

### Hello Fresh has a u, id, and e strings in the URL from their emails. Removing for privacy.
hfu = 'REMOVED'
hfid = 'REMOVED'
hfe = 'REMOVED'

## Buld HF Tracking URL with the different strings
hf_url = ''+hfu+'&id='+hfid+'&e='+hfe

req = urllib.request.Request(hf_url)
resp = urllib.request.urlopen(req)
respData =

fullEx = '(Picked Up|Delivered).*?(\d{2}\/\d{2}\/\d{4}\s+(\d{1}|\d{2})\:\d{2}\s(A|P)M)'
paragraphs = re.findall(r''+fullEx,str(respData))

## Time Object Created
c_Event = paragraphs[0][0]
c_Time = paragraphs[0][1]
print ("Created", c_Time)

## Time Object Picked up by Shipping Company
p_Event = paragraphs[1][0]
p_Time = paragraphs[1][1]
print (p_Event, p_Time)

## Time Delivered
d_Event = paragraphs[2][0]
d_Time = paragraphs[2][1]
print (d_Event, d_Time)

## Converting strings to find total hours between creation,arrival and delivery
t_Format = '%m/%d/%Y  %I:%M %p'
cT = datetime.strptime(c_Time, t_Format)
pT = datetime.strptime(p_Time, t_Format)
dT = datetime.strptime(d_Time, t_Format)
t_Delta = dT - pT
h_Delta = (t_Delta.days * 24)+(t_Delta.seconds/60/60 )

## Final Print Statement
print ('Hours taken from pickup to delivery', h_Delta)

In my case I found the following:

Created 02/24/2017 2:50 PM
Picked Up 02/26/2017 9:07 PM
Delivered 02/28/2017 1:47 PM

Assuming that the delivery was not refrigerated from Pickup to Delivery the entire time, the box of food was not refrigerated for 40.67 hours.
Assuming that the delivery was not refrigerated from Creation on the shipping page to Delivery, the box of food was no refrigerated for 94.95 hours.

At the end of the day, my wife and I love HelloFresh. We hope that they look at this or already look at these numbers and work on delivery times to ensure fresh food is delivered.

Thanks for reading.