t resides in, see Figure 6.7. Such a gateway will participate in multicast traffic originating from its residential network, which it will forward into the overlay according to the distributed multicast receiver domains of this group. It will also advertise group membership and receive data according to any subscription from its domain. On the overlay, the IMGs will jointly operate a distributed hash table, hosting an application layer multicast. Depending on specific requirements, any well-known ALM may be executed. The bidirectional shared tree approach introduced in [42] gives rise to fully transparent, mobility-agnostic, and proximity-aware multi- cast and broadcast overlay services. Like a SIP proxy, the IMG function may be positioned anywhere within the multicast domain, and provides a protocol interface to the locally deployed multicast routing. Activation of inter-domain multicast gateway services requires only a small amount of selected information for bootstrapping, i.e., an arbitrary contact member of the structured overlay, authentication, and authorization credentials, if applicable. Typically, such initialization is per- formed at SIP domain peering. The IMG further on remains under the admin- istrative control of the local network operator, who may restrict admission, scoping, and QoS characteristics of the group traffic flowing in and out of the intra-domain. Aside from general multicast peering policies, a service provider is thus enabled to implement firewall-type of packet filters at, or co-located with, these multicast gateways. It thereby can easily shape the inter-domain multicast layer according to conferencing application or community specific particularities-without control of the underlying network infrastructure. This architecture allows for flexibility in several additional ways. A domain operator is enabled to connect to several multicast overlays in parallel, may choose to replicate IMGs for load balancing or redundancy purposes or may transparently take advantage of the fail-safe un