ties. In general, multicast routing dynamically adapts to session topologies, which may then change under mobility. However, depending on the topology and the protocol in use, routing convergence may be far too slow to support seamless handovers. In multicast routing, the roles of senders and receivers need to be distin- guished. Any listener subscribed to a group while in motion, requires delivery branches to pursue its new location; any mobile source requests the entire delivery tree to adapt to its changing positions. Operations should facili- tate seamless data flows compliant to real-time requirements and at the same time ensure routing convergence without compromising network functionality, see [40] for a detailed discussion. In a conference, multicast routing will always be exposed to listener mobility, while source movement in some schemes may be hidden to the network layer, e.g., by a central static mixer. Like in the unicast case, SIP may assist multicast mobility on the appli- cation layer, even though the undertaking is more complex. Subsequent to handover, a listening user agent client can initiate unicast data forwarding by third party call control until multicast routing has converged. A mov- ing source may either rely on static entities for packet redistribution or take advantage of application layer tunneling between conference members. Note that a change of its source address will trigger a user agent to issue SIP/SDP updates within immediate signaling relations. Thereafter, address information needed for SSM specific rejoins are in place. In concordance with mobile IP, a natural and efficient way to manage mul- ticast mobility will reside on the network layer. Three approaches to mobile multicast are commonly around: Bi-directional tunneling guides the mobile node to tunnel all multicast data via its home agent and thereby hides its mobility. Remote subscription forces the mobile node to re-initiate multicast distri- bution subsequent to handover by submitting an IGMP join or MLD listener repor