Currently AppleTVs are department run devices, they are not network infrastructure devices and therefore not configured or otherwise managed by us (not that they could be remotely managed). So although we could make configuration recommendations, those may/may not be followed. I agree, if they do not set a pw/code, they could be in for a surprise. But even those measures won't be foolproof.
For non-Reshall use we might suggest devices like these are managed by an AV services group, but just as users install their own APs/small switches, I'd not expect any difference here. Being small devices (designed for the home), departments might also invest in some liquidNails. On Wed, Apr 10, 2013 at 7:05 AM, Jennifer Francis Wilson < [email protected]> wrote: > 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]> 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]] *On Behalf Of *Garret Peirce > *Sent:* 09 April 2013 14:16 > *To:* [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 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/.
