True enough. I agree 100% it will be a pain if Apple keep chopping and changing the services required to make their Airplay, Airprint devices work.
Surprised you aren't doing any kind of password or on-screen code protection, what's to stop someone connecting to the device from across campus and displaying some kind of inappropriate material? Jen. From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[email protected]] On Behalf Of Garret Peirce Sent: 09 April 2013 17:22 To: [email protected] Subject: Re: [WIRELESS-LAN] AppleTV service string and Cisco 7.4 Bonjour gateway ok - I do see Airtunes uses that same string as well but I don't think it's enabled as a default service either. My intent was only to allow the AppleTV service preparing to keep the # of advertised services at a minimum. As the AppleTV service name is an enabled default, I thought that might work. It was actually a bit worse that not working at all, as the initial attempt partially worked working only for Photos app. The fix was easy, but perhaps my point was more that this service is at the mercy of an (automatic) client update. Instead of a planned change, we might have to rely on users to tell us when a service breaks , make a configuration change and hope there aren't negative consequences for other existing clients. I'm not sure I like Airtunes and AppleTV services using the same string. Seems to me it'd be nicer to have the flexibility to filter specific devices by their service type. If the service type is more of an umbrella, there's less flexibility and the list of advertised services may grow. Is the _airplay._tcp.local. service type to be deprecated? I did try creating a WLC service name using the full device service name within a profile. using '7CD1C33D3DCB@Living Room ITS._raop._tcp.local' - the service is not found. using '._raop._tcp.local' - the service with the above name is found and advertised. If this is not meant to work then creating a full service name should not be accepted. If it did work, we'd have a much finer level of control of advertisements. My thought is currently to initially create a single campus-wide wired vlan for such devices to be joined to the controllers. I don't want to put them on the buildings's wired vlan as then many more vlans (broadcasts...) would have to be sent to the controllers as well and with a more umbrella service type, other devices might exist that would end up being included into the list of services to scroll through. For us at this time, these devices are currently all dept owned. Meaning they are not monitored, the service names follow no similar syntax, and we cannot require onscreen codes nor passwords be implemented. Being in the middle of the service, we'll then surely take calls when the airplay icon doesn't appear. On Tue, Apr 9, 2013 at 9:36 AM, Jennifer Francis Wilson <[email protected]<mailto:[email protected]>> wrote: Don't you just have to allow the "AirTunes" service, as well as the "AirPlay" service? Regards, Jen Jennifer Wilson Senior Networks Officer University of Central Lancashire 01772 89 2116 From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Garret Peirce Sent: 09 April 2013 14:16 To: [email protected]<mailto:[email protected]> Subject: [WIRELESS-LAN] AppleTV service string and Cisco 7.4 Bonjour gateway I ran into this issue and thought I'd pass it on. Using Cisco's bonjour gateway feature in 7.4, I found I could make use of Airplay through the Photo App but nothing else. Working with Apple, we found that the service string for AppleTV being looked for in iOS (6.1?) devices has changed from: _airplay._tcp.local. to _raop._tcp.local. After creating a new profile for this string, the iOS device became aware of the ATV and now is able to work with it. The ATV looks to be advertising both types. I assume the PhotosApp was the only app that I found still looking for the older service name. Cisco is has documented this as bug: CSCue54207. I'm not really sure this rises to the level of a bug as any change in any advertised service string would require a the WLC to be aware of it. The workaround is easy enough, one just adds the correct string as a new service (max of 64 btw). I'd still prefer to be able to use DNS-SD for AppleTV (across subnets) or generically a more 'enterprise' friendly protocol over this feature, but given the lack of those, this feature looks to be the best option in our environment. However, when a service needs this type of network infrastructure glue, things can get messy as it inserts a network operations group into a service they don't have much control of. I'd be interested in anyone else's experience with this feature, especially if in production. -- Garry Peirce Networkmaine, University of Maine System ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. -- Garry Peirce Network Architect Networkmaine, University of Maine System 1-207-561-3539 ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
