In a test that starts 2 regular clusters and 1 bridge cluster, A sends a unicast message to B and B receives the message with the source address set to the SiteUUID of A:

19:56:29,563 DEBUG (testng-Test:[]) [GMS] C: installing view [A|2] (3) [A, B, C] ([A, B, C] joined)
19:56:32,720 DEBUG (jgroups-5,bridge-org.infinispan.xsite.offline.Test,_A:LON-1:[]) [GMS] _A:LON-1: installing view [_A:LON-1|7] (2) [_A:LON-1, _D:NYC-2] (_I:SFO-3 left)

19:56:33,055 TRACE (testng-Test:[]) [UNICAST3] A --> B: DATA(#33, conn_id=0)
19:56:33,055 TRACE (testng-Test:[]) [UDP] A: sending msg to B, src=A, size=239, headers are RequestCorrelator: corr_id=0, type=REQ, req_id=17, rsp_expected=true, UNICAST3: DATA, seqno=33, TP: [cluster=LON-1-org.infinispan.xsite.offline.Test]
19:56:33,056 TRACE (jgroups-8,B:[]) [UDP] B: received message batch of 1 messages from A:LON-1
19:56:33,056 TRACE (jgroups-8,B:[]) [UNICAST3] B <-- A:LON-1: DATA(#33 - #33)
19:56:33,056 TRACE (jgroups-8,B:[]) [UNICAST3] B: delivering #33 - #33 (1 messages)

The source address type is important for Infinispan: if it's a SiteAddress, Infinispan assumes the command being received is a x-site command.
Because this is a regular cluster command, the test fails with a ClassCastException.

I'm not sure what's making B's UDP set the SiteUUID of A as the source address on the message from A, but it may be related to the fact that SiteUUID does not implement equals(), and the implementation of equals() inherited from UUID ignores both the type difference and the SiteUUID fields.
AFAICT the SiteUUID of A has the same random bits as the regular UUID of A.

SiteMaster is similar: it implements equals(), but does it based on compare(), thus is could compare equal to regular a UUID.
That may not be a problem because SiteMaster sets all the bits to 0, but still equals() shouldn't rely on that.