The module is able to process discovery and query packets of both kinds – classify them as either “AirGroup Server, AirGroup User, or both” – and filter them based on the user-name that registered them without flooding the entire network. So only Billy’s Smart Phone can discover Billy’s ChromeCast or Janet’s Apple Homepod can discover Janet’s Apple Tv. Aruba Airgroup has worked wonderfully for the Apple TV, Apple Homepod, Amazon Firesticks, Google ChromeCast, Google Home, Google Home Mini, and various apps that run on these devices such as casting to the YouTube App on the Roku. This also works for wireless printers that make use of mDNS and SSDP. One of the other additional features is if a newer devices comes out that – we can define/configure new “AirGroup Services” by extracting the service ids from the discovery protocols - https://community.arubanetworks.com/t5/Controller-Based-WLANs/What-are-the-AirGroup-service-IDs-required-to-allow-casting-via/ta-p/340268 - which was also necessary for the _googlezone mDNS service which is needed for multi-room control.
However, the one application we have been unable to get discovery working with AirGroup has been the Roku Remote control app. We performed packet-captures and worked with our vendor HPE Aruba and their developers informed us that the service “Roku:ECP” is invalid syntax with uPnP Architecture 1.0. I’ve included the response from our vendor (from last year during our initial testing – I’m finally taking the time to pursue this further again as more and more students are taking advantage of our services and this has been the one last piece asked of us that isn’t capable yet):
Good Morning. Thank you for your patience. Our development team informed that the service (Roku:ecp) used by the Roku devices are not currently supported in Aruba OS. Aruba OS is compliant with [font=Arial, sans-serif]http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0-20080424.pdf[/font]
Please find the details below.
- Required. Notification Type. Must be one of the following. (cf. table above.) Single URI.
- upnp:rootdevice Sent once for root device.
- uuid:device-UUID Sent once for each device, root or embedded. Device UUID specified by UPnP vendor.
- urn:schemas-upnp-org:device:deviceType:v Sent once for each device, root or embedded. Device type and version defined by UPnP Forum working committee. Specifies the highest supported version of the device type.
- urn:schemas-upnp-org:service:serviceType:v Sent once for each service. Service type and version defined by UPnP Forum working committee. Specifies the highest supported version of the service type.
- urn:domain-name:device:deviceType:v Sent once for each device, root or embedded. Domain name, device type and version defined by UPnP vendor. Specifies the highest supported version of the device type. Period characters in the domain name must be replaced with hyphens in accordance with RFC 2141. urn:domain-name:service:serviceType:v
- Sent once for each service. Domain name, service type and version defined by UPnP vendor. Specifies the highest supported version of the service type. Period characters in the domain name must be replaced with hyphens in accordance with RFC 2141.
Even in this we support the URN only in following format
roku:ecp is sending the NT in following format
NT : roku:ecp
This is not supported by AOS since the above service is an invalid syntax.
Next action :
We need to understand what RFC or architecture Roku is complaint with and we need to register a RFE( Request feature enhancement) with Aruba if the same service is used by multiple vendors. Once we have the above said information from the Roku we can raise a RFE with Aruba.
Reading up on the “URN:” from RFC 2141 – [font=Arial, sans-serif]https://www.ietf.org/rfc/rfc2141.txt - does specify that the URN must contain the pre-fix “urn:” – something that I immediately noticed while debugging the AirGroup Service for suppressed queries (every other one contained a prefix of uuid or urn) - but not the roku:ecp.[/font]
My question I was trying to get answer was if Roku agreed that they're using invalid syntax in regards to the uPnp Architecture 1.0, why they weren't following that syntax, and if it would be possible to get it compliant with the uPnP Architecture so that we would be able to AirGroup the service to give students this capability. For now they use the IP Address (which I'm thankful that Roku added that feature and the "Dorm Mode/Captive Portal" feature years ago - but it's the last single piece that isn't working - and with our IP Address lease time can be - IP Addresses can periodically change on the students. It would also be beneficial as enterprise vendors such as HPE Aruba and Cisco are recognizing this need, implementating software solutions, as other universities are running into this same problem with the Roku being singled out - http://community.arubanetworks.com/t5/Wireless-Access/Roku-streaming-stick-Not-registering-with-AirGroup/td-p/283086
I'm not expecting much will come from this. I tried the general support route with all the information I provided above - but it was immediately discarded/ignored with "public network - too many ip addresses - it's designed for home use" even though my specific repeated inquiry was about the "Syntax/Architecture" and reference that AirGroup gets around that limitation by building a "Virtual Home Discovery Domain" - which is why the YouTube App on the Roku works wonderful with casting from smartphones, controlling Google Home Mini music from smartphone music app, and controlling Apple TV from Apple HomePod works as well.
Thank you for your time.