Change public IP for NATed Lync 2013 Edge

Occasionally we are involved in changing Public IP's for the Lync Edge pool. This is normally easy-peasy work performed in public DNS and a small change in the Topology for the A/V Edge service under the Edge Pool:

We did however experience some problems on a customer site where AV traffic through the Edge pool was dead after changing the Topology. The Lync client received a message indicating network problems - "Call failed due to network issues":

We checked that the changes in Management Store replicated successfully throughout the Lync Topology by use of the command Get-CsManagementStoreReplicationStatus:

Tracing the Lync call gave the following ms-client-Diagnostics:
“ms-client-diagnostics: 26; reason=”A federated call failed to establish due to a media connectivity failure where one endpoint is internal and the other is Remote”

Traces done on the network, verified that the traffic returned into the OLD IP-address - even though the topology replicated successfully in the Lync environment!

Inspection of the Invite message showed that Lync was still sending the old IP-address in the Candidate segment:

 
A restart of the Edge services did fix this situation:

Other references related to this kind of problem:

• UDP 3478 Bi-Directional and Internal Routing by UCPrimer
• Port requirements for Lync Server 2013 by TechNet
• Dual homed Lync servers by Stoknes
• WireShark download

Update 2016.08.31: ms-client-Diagnostic found in Skype for Busines

We did today experience a problem with traffic through the AV portion of the Skype for Business Edge server. Users experienced problems connecting to Skype for Business meetings, problems with audio/video calls to federated partners and problems with audio/video calls and PSTN calls while working offsite.

Tracing gave the same ms-client-Diagnostic as found above:
"ms-client-diagnostics: 26; reason=A federated call failed to establish due to a media connectivity failure where one endpoint is internal and the other is remote"

Thankfully Google lead me to my own post about this issue. Unfortunately a restart of the Services did not work this time since the services didn't respond to the stop-cswindowsservice command.

A restart of the Skype for Business Edge server did fix the problem this time.