You appear to have the wrong idea of how multicast works. Join/Leave are client (receiver) functions. The sender of a stream doesn't join the group.
If you have two isolated 192.168.1.0/24 private LANs, then NAT would have to be applied to the multicast traffic leaving/entering each LAN, just like any other layer-3 traffic... a src of 1.1 doesn't mean anything to the rest of the internet, and will only be confusing to the other network. A multicast packet is fundamentally the same as a unicast packet: it has a source address and destination address. If you transport a multicast stream from 192.168.1.1 to 220.127.116.11 into the other network, the source is now nonsense; the 1.1 in the local network is not the sender. Any client attempting to send a message to the apparent sender will be talking to the wrong node:
(A) (server) 192.168.1.1>18.104.22.168 <-> intermediate net(s) <-> (B) (client) 192.168.1.1>22.214.171.124 [assuming the private addresses can even cross the intermediate network(s)]
NAT MUST be applied at the boundaries of the private networks. Lets say each side sees the other as 192.168.2.0/24... ("I'm one, you're two" is true in both networks.)
(A) (server) 192.168.1.1>126.96.36.199 <-> intermediate net(s) <-> (B) (client) 192.168.2.1>188.8.131.52
The "B" side router will see a join for 184.108.40.206 from the local 1.x host(s); it doesn't necessarily care who is joining the group, just that there's a group it needs to request from upstream. If SSM is being used, then the stream source address matters, again, meaning NAT must happen.
[Note: interconnecting overlapping networks is a pain that everyone tries to avoid. Attempting to mix multicast into that mess is suicide.]