Your Digital Media Has Never Looked So Good

 
Guardian-Droid
Topic Author
Posts: 2
Joined: Thu Jun 21, 2018 5:11 pm

Roku ECP - Invalid Service Syntax for uPnP?

Sat Jun 23, 2018 5:11 pm

I’m aware this is a long shot, but I wanted to do my due dilegence. Hoping this reaches a Roku Engineer. I have opened a support ticket with Roku Customer Support for an answer to my inquiry, but my questions along with supplied information/documentation have been ignored with a canned response of “it won’t work/not meant for non-home networks” without any acknowledgement of the syntax question. I’m a wireless network engineer at a university and understand all too well the “futility/struggles” of supporting devices typically used in home environments. With that said, we have made amazing progress in the past year to give student’s the “Home Experience” in the residence halls. Student’s are able to register and connect their Rokus, Apple TVs, ChromeCasts, Google Home Minis, Amazon Echos, etc to the wireless network and utilize them as they were at home through the use of a software module with our wireless vendor called “AirGroup” from HPE/Aruba – an mDNS/SSDP proxy/gateway - https://community.arubanetworks.com/t5/Controller-Based-WLANs/What-are-the-AirGroup-service-IDs-required-to-allow-casting-via/ta-p/340268

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]
UPnP architecture1.0
Please find the details below.

NT 


  • 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


  • urn:domain-name:device:deviceType:v
  • urn:domain-name:service:serviceType:v

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.
 
Guardian-Droid
Topic Author
Posts: 2
Joined: Thu Jun 21, 2018 5:11 pm

Re: Roku ECP - Invalid Service Syntax for uPnP?

Fri Aug 10, 2018 8:03 am

Unfortunately after multiple attempts, the end result was Roku Customer Support wouldn't even acknowledge my inquiry concerning the Service Syntax for Roku ECP in relation to uPnP being invalid due to me even mentioning a "University" network. I offered to take it a step further by configuring a home network - with a limited number of IP addresses - to try and appease them of each of their "reasons" for why they wouldn't even acknowledge my syntax inquiry - but at that point they directed me to e-mail their Customer Advocate e-mail address. I e-mailed their Customer Advocate department about 3 weeks ago, but haven't heard anything. At least I gave it a shot, just a shame that this is the one app/service we can't "AirGroup" among all the other devices out there that students are bringing.

Who is online

Users browsing this forum: No registered users and 2 guests