In general, if you search for your wireless vendor and Bonjour, you should find documentation to at least point you in the right direction. And the specific configuraition will depend heavily on your current wireless solution (Cisco, Aerohive, Ubiquity, etc). To directly address your questions, it will usually require very specialized configurations to accomplish the spanning of Airplay services across your network. The problem is so prevalent that many educational institution IT staff got together a few years ago, and petitioned Apple to fix Bonjour to work better in these environments. Enterprise/educational networks just aren't structured that way. However, as you pointed out, these features rely upon a single broadcast domain for service discovery.
Apple has done an excellent job of selling iPads and Macs to students/staff and they want to utilize Airplay/Airprint/other Bonjour functionality. This is a common problem in educational environments. Go on, test it and let us know about your results. But even with this there are some possibilities (for Apple engineers) to break it. There is one more (again theoretical though ) brute force option - create a DNS-SD entry for your router address as an Airplay receiver for the network with Airplay senders and forward (NAT) the UDP stream to the real Airplay receiver. You could get all info correctly to the potential sender, but iOS/MacOSX might still reject it because it just doesn't like it for some reason and so on. Now, I said "theoretically", because I haven't tested it and whatever you do with protocols, forwarding and so on, there MIGHT be some roadblocks beyond your control - it's the Apple after all. There is also DNS-SD proxies (for example avahi can be used as such). Execute this command in the LAN with Airplay receiver and this should give to you all the info you need: $ dns-sd -Z _airplay._tcp You can use normal DNS to announce the very same info normally distributed automatically via multicast DNS-SD and you can use a little help from dns-sd(1) utility on your MacOSX to get an info what exactly to write into your DNS zone file. RTFM how exactly, but the idea is that you have to forward multicast traffic with destination address 224.0.0.251 to another network and you have to do it without decrementing TTL.Īnother option is to use unicast DNS-SD. It might be tricky though, but there are routers/firewalls capable of this. Now the main problem is how you get the info about Airplay receiver to the potential senders in another network. The streaming itself is "normal" UDP unicast.
It's using multicast and that's the point if someone is telling to you that "Airplay is for local LAN only" or something. It's done normally via service called Bonjour (at least Apple calls it so) or DNS-SD.
The first one is about service discovery and it's the way how devices capable of receiving Airplay streams announce to the network "Hey! I can receive Airplay!". There is two different things in term "Airplay".
0 kommentar(er)
