Clarification about source and destination IPs for internal clients and Edge server

Question

I just wanted to get some clarification on the correct traffic flow between internal Lync clients and the Edge server.
From all the diagrams I've looked at I was under the impression that if internal clients need to hit the Edge server to talk to external clients they should always do so through the Edge Internal interface which bridges to the Edge External interface and
out to the internet.  Specifically port 3478 from the Edge AV External interface to the internal clients.
We aren't seeing that in our environment.  When internal clients are talking to external clients we see the Edge AV External interface communicating directly with the internal client.  In fact we found this out because after the migration to Lync
2013 external users couldn't created a AV connection to internal users on either the Lync servers.  We saw traffic on 3478 being dropped between the Edge AV External interface and the internal client.  Once we opened that port AV traffic worked.
We never put this rule in until we introduced Lync 2013.  Lync 2010 didn't seem to require it.
Is that the correct flow?

Answer 1

I would also really love to know the outcome of this but it looks like the thread is marked as "Answered" and it is not so. 
I've been working with a troublesome Lync deployment in which internal users are having issues sharing their desktop with external and federated users. After opening up all the 50000-59999 range for TCP/UDP on the A/V Edge external interface things are working
much better, but we still see sporadic failures.
It lead us to start digging into the network traffic. We see that UDP traffic on port 3478 is being routed back from the external client to the Edge A/V's external interface, inside of the DMZ's perimeter, then directly to the internal client on the internal
network. It doesn't look like it's making a connection since the stream is so small, so I wonder if there is a design flaw in my topology?
There are persistent static routes on the Edge server that use the internal interface to route internally directed traffic over the internal gateway. Tracert confirms the flow, but in wireshark traces, running during successful connections, UDP port 3478
is still sending packets directly to the internal IP from Edge's A/V address. 
We also see successfully connected sessions communicate on a different network route that we use to handle internet traffic rather than our Lync topology's route (the one defined for A/V traffic). The connection opens on ports in the 50000 range, but goes
over a router that we have not configured for such traffic. Is that possible?
Why is UDP traffic on 3478 trying to go directly to internal clients from external interface ?
It sounds like it's happening elsewhere... Is this a legitimate issue to be diagnosing? Has it been observed and/or resolved by others?