One week and tons of hours of work later - we got a working solution.
Multicast locally bridge out of RAP in split-tunnel is a no go. Its not supported in this AOS.
Bridge-mode works - of course, but not exactly ideal.
We reverted back to Tunnel mode for the IP-TV multicast solution. Then how to implement this.. In lab environment the testing we did wasn´t close enough to the customer solution to copy directly.
So we saw that a set-top box multicast client got it´s stream directly no problem. If we placed a RAP between the stream stopped. So we configured IGMP Proxy on the client VLAN towards the uplink interface. No go.
Requirement to use IGMP Snooping or Proxy is:
* The VLAN has to be forwarded to the upstream router
* The router needs to do all the multicast routing
* The client VLAN can not be NAT by Controller so "no ip routing" on the client interface.
Using IGMP Snooping means that the Controller handles the IGMP joins per AP. No stream is sent n AP that doesnt have clients subscribing to the stream.
IGMP Proxy handles the same per user, and is required if you need L3 Mobility.
More information about this in the User Guide, but imho. it´s not easy to understand HOW and WHAT to choose.
At this customer it was defined that the Client/multicast VLAN was not to be routed directly, but had to be NAT´ed. The VLAN was not defined in Core.
So we ended up having to set up a separate Router that handled the multicast routing and NAT´ed the traffic from this client/multicast VLAN.
Of course we also ran into some nasty jitter issue underway, that we didn´t find the root couse of. We eventually changed the controllers IP and narrowed the ACL´s to these from the infrastructure to a bare minimum. That solved it - for some odd reason..