This fall your wireless networks will experience many devices upgrading to the new Android 5.0(L-release) and Apple iOS 8 releases (cue: IT managers groan). There have now been many blogs attempting to capture the enhancements expected with these releases. Today I am going to focus on describing how Android L and iOS 8 may affect customers deploying Cisco enterprise grade Wi-Fi networks based upon our research and testing of the Apple seed. Our verdict: Carry on with business as usual.
Here are four features we predict will have the most impact your networks:
1. Chromecast and Google Cast Enhancements (Android L)
Rishi Chandra, the Director of Chromecast Product Management announced that, starting with the Android L release, users have the ability to cast to your neighboring devices such as a TV without having to connect to your Wi-Fi network. In the demo, a phone used the cellular connection to connect to chromecast through the cloud. A variety of techniques are used to authenticate the users in the same room OR use a pin-code as an alternative. Users can Google Cast an ecosystem of applications or even their own applications over any Android or iOS device as well as Cloud based apps on Chrome.
Predicted Impact: Given that this feature works transparently to the Wi-Fi, it is expected that there is no impact on the WLAN in your classrooms or dorm rooms or auditoriums where this will most likely be used.
2. Peer-to-peer AirPlay discovery and playback (iOS 8)
Starting with the iOS 7.1 release, AirPlay devices will discover an AppleTV via the bluetooth network. Users could also secure their AppleTV via a 4 digit pin-code. With the iOS 8 release, Airplay devices can also mirror their content via Airdrop. This feature offers an alternative method for customers to discover and mirroring of Bonjour traffic without accessing the corporate Wi-Fi network.
Predicted Impact: Again this feature operates transparent to the Wi-Fi and therefore customers using this feature should not see any impact on the WLAN. Cisco wireless customers also have the ability to use the Service Discovery Gateway on Cisco IOS based switches, routers or wireless LAN controllers or the Bonjour Services Directory on AireOS controllers. Read More »
A lot can change in 25 years. At the first Cisco Live (then known as Networkers conferences) in 1989, 200 geeks gathered for the inaugural event. Fast forward to three weeks ago, when we welcomed a whopping 25,000 attendees into the arms of our namesake, beautiful San Francisco.
We heard there was some interest in how the network performed at the show, so I wanted to share some of the interesting statistics about the network at Cisco Live! I shudder at the thought of the ancient network from 25 years ago. So here we go:
Wi-Fi Client Devices
This year we saw 30,705 unique devices, with 7000 in the theater for John Chambers’ keynote.
# of Unique Clients
# of Sessions
# of Unique Users
# of Unique APs
Avg Users per AP
Max. Concurrent Connected Wi-Fi Devices
There was a peak of 14216 concurrently connected device at SF this year.
This week we have two opportunities for you to learn about Cisco technologies from company experts as well as our technology partners.
The first webinar,How Smarter Branches Lower Costs, is on Wednesday, December 11 at 8am Pacific and discusses how Cisco Intelligent WAN (IWAN) along with Akamai’s Unified Performance solution can help your branch offices can realistically utilize Internet as WAN for a cost-effective, reliable, and secure option.
A preview for this webinar is a quick video we did with Akamai in October!
Last week, my colleague Rajiv walked you through an overview of how our Mobility Services API now supports REST based APIs. As a developer for the Mobility Services Engine (MSE) team, I am very excited about this update because it means that it will be easier for developers to create apps using the MS-API, which hopefully means that more and more organizations will be able to take advantage of the location-based services and functionalities of the MSE. I’m going use this blog to walk you through some of the more technical aspects of the change.
The REST API is now widely used in the field of API based web applications. The REST stands for REpresentational State Transfer. It is an architecture that is based on set of six rules, and APIs that support REST follow all those rules, making them RESTful.
Compared to SOAP, REST has better performance, scalability, simplicity, modifiability, visibility, portability, and reliability. For secured REST API transactions, HTTPS is recommended.
RESTful Mobility Services API
7.5 applications, including features from the Connected Mobile Experiences (CMX) solution such as Browser Engage and CMX Analytics, are now supporting REST APIs in addition to the existing SOAP APIs previous releases (backward compatibility).
CMX utilizes the basic authentication scheme to authenticate each REST API request. It utilizes the Authorization header in the HTTP packet. The Authorization header is composed as follows:
- Username and password are combined into a string “username:password”.
- The resulting string literal is then encoded using Base64.
- The authorization method, a space and the string “Basic” is then put before the encoded string.
The API credentials can be accessed from Prime Infrastructure (PI), which manages CMX (page is located under Mobility Services > Specific MSE > System > Users).
As Rajiv mentioned last week, the Mobility Services REST APIs can be grouped in the following way:
- MAP APIs
- Real time location APIs
- Location history APIs
- Notification APIs
Let’s break them down with use cases to get a better picture of when you’d use which. Read More »