A couple of months ago I took delivery on my Tesla Model 3 “Speedy”. In the time between placing the order and actually getting the car, aside from being beyond excited, I took a bit of time to learn about the car’s always-connected API and how to use it, and also signed up for off-peak billing from my local utility ComEd. Then I decided to take things to a new level by combining two API’s and making some triggers for charging, so this is the whole point of my post. ...

If you’ve never heard of Twilio before, you’d be surprised to learn that they are the largest backend for services around automated calling services, text messaging (and verification), and are pioneering Software Defined Telephony by use of APIs to route and handle texts/calls/faxes. Is your Uber driver calling you now? That’s Twilio… Got a text from Netflix for a password reset? Yup, that’s Twilio… PagerDuty sending you a SMS alert? You guessed it! ...

If running Lync Server 2010, Lync Server 2013 or Skype for Business Server 2015, and started noticing these in your Lync Server event log sometime between May and June of 2017, while at the same time people can’t share PowerPoints or do Whiteboards / Q&A… Then you’ve fallen victim of a known issue with the May 2017 .NET Framework Security and Quality Rollup affecting the Web Conferencing Service. Luckily, Microsoft detailed two workarounds, one involves getting a new Edge Internal cert, and another involved a registry change. Here’s the details: ...

TL;DR: When dual-homing, make sure both your NICs have the same link speed (1Gb, 10Gb). VMware’s E1000E is 1Gb, and VMXNET3 is 10Gb. Automatic metrics will prefer the 10Gb and that may cause the issue below…. After a power loss over the weekend, two Skype for Business Front-Ends were restarted and the RTCSRV service failed to start. A bit about these machines that’s relevant to the issue: Running Widnows Server 2012 R2 as VMware ESXi 5.5 guests. Collocated Mediation service. Dual-homed, with Data network as default gateway, and Voice network to talk to a Sonus SBC, with service usage limited to the specified addresses for Primary and PSTN in the topology. Certificate stores were in good order, so KB2795828 did not apply. ...

Let’s say it was totally underprovisioned at some point. Just bumping up the RAM won’t give you the performance you expect. Here’s why: You deploy a Server 2012 R2 template with 2GB RAM using your favorite hypervisor and just roll with the Skype for Business or Lync deployment without even thinking about it. Or… let’s say you ask for a VM to be provisioned so you can roll out SfB, and it’s underprovisioned from the start, but changing the resources would take too long so you go ahead with the deployment anyway and just wait for resources to be added later on. No time wasted. How many times has that happened? Plenty to me… ...

New features! Video Based Screen Sharing (VBSS) in meetings, enables much more efficient screen sharing with fluid motion (not the 2fps we’re used to in meetings. Multiple Emergency Numbers in a location policy, useful for universities that may have their own local emergency number in addition to 911 Busy Options like Busy on Busy and Voicemail on Busy. Get it here: https://support.microsoft.com/en-us/kb/3061064

Ever wondered what a proper T.38 Fax over IP (FoIP) transmission looks like running through Wireshark? Maybe you’re troubleshooting a call flow, or never seen a T.38 capture. Below I’ll try to explain the call flow and steps to look out for when troubleshooting T.38 calls. Here’s an Outbound FAX call originating from a FXS port in a Cisco CUBE, and going towards Flowroute. Initial SIP INVITE and early media receipt (ringback). Note this is all RTP. SDP from the INVITE shows media offered is all voice (RTP) 183 Session in Progress, and we start sending media too (again, RTP). Later on comes the 200 OK, meaning the call was answered on the remote end. Things changing now… in-dialog (RE)INVITE from Cisco CUBE to SIP trunk… RTP and T.38 packets mixed because the remote end has not accepted our INVITE yet, but we start sending media either way. And the SDP of the new INVITE now shows all T.38 media now. Once we get the 200 OK from Flowroute, it’s all T.38 media both ways. Now the flow gets interesting, more Fax-ey. Wireshark will decode the HDLC data and show interesting bits here TSI, is our Fax station number programmed in the machine. DCS, our Fax machine communicates the capabilities, and starts training. If we look inside the packet’s data, our DCS has a lot more information about our Fax machine’s settings and resolution Then we get an FTT, means the remote end “Failed to Train”. Not usually a sign something is wrong, but more a capability mismatch. The remote fax may accept only lower baud rates, and will fail to train any higher. This is normal unless it’s the only response we get back from the remote end. We see the same process of TSI, DCS and FTT until we hit the right baud rate… in our case it’s 9600… Once we get that, we receive a CFR. Followed by a short training to sync-up and data (because we did long training before the CFR) And our actual FAX data which will vary At the end of the data, Wireshark reassembles the packets and tells us whether there was a loss or not. In our case, we’re good! We send an EOP to signal the end of the transmission The remote end does an MCF to acknowledge receipt (this is how your Fax machine knows the fax is “good” on the other end) And then we send a DCN to logically hang up the HDLC stream, but we wait for the remote end… Remote end hangs up the call… and we’re done… And that was it. Many exchanges and training but in the end our page was sent over a SIP trunk, negotiating T.38, training with the remote fax machine at 9600 baud, and transmitting one page in about a minute.

Sophos UTM v9 comes with the tcpdump utility, which lets you run packet captures from the shell. This is great and all, but in order to look at those pcaps with Wireshark, you need to pipe to a file, copy the file, then run Wireshark against it. Annoying. All of it. What if we could remotely capture packets over an SSH tunnel? YES… turns out it’s a bit tricky if you’re on Windows, and the authentication piece to get root access without having to do the loginuser first. How? Keep reading… ...

VMware’s Performance Best Practices mentions you should set power management in the BIOS to “OS Controlled Mode” or equivalent. This is so you can control power saving from the hypervisor itself. It’s very useful when you want to change these settings on the fly without having to reboot into the BIOS, similar to how Windows power profiles work. But the “gotcha” here, which is also mentioned in the best practices documentation, is that the default Power Policy setting is set to Balanced, when you most likely want to set this to High Performance, as you’ll see later… ...