Forum Discussion
S4B Standard Edition deployement in a branch Site throught VPN Site-2-Site
Hello
The first question you should ask yourself is what you are trying to achieve? You mention that you're deploying a SIP trunk from an ITSP to Site A but not B.
If you look at the call flows
Skype to Skype callers (audio and video) internal to Site B will negotiate media locally and not use the S2SVPN. So for this reason an FE in Site B is providing minimal benefit.
Users in Site B who want to make a federated call or IM will always go via Edge servers (assumed in Site A) which will go over the S2SVPN regardless of whether there is an FE in Site B or not.
Users in Site B who want to make a call to the PSTN will connect to the mediation server in Site A over the S2SVPN because that is the one that is connected to your SIP trunk, again makes no odds that you have an FE in Site B or not.
Host users from Site B on a local FE, their conferences will be hosted on that server, but if they invite users from Site A or dialin PSTN users then those users will use the S2SVPN for media.
In the event the S2SVPN link goes down your users in Site B are going to go into limited functionality mode regardless of the fact they have an FE and AD available there because the CMS will (assumption) be hosted on Site A's FE. And you can only have one CMS active master in the enterprise domain so at this point what can users in Site B do? There is no presence, no calling of PSTN phone numbers, failed conferences, and just basically P2P audio and video is available.
IMO, you are far better off getting an SBA there for survivability on the PSTN.
However, calls between sites and PSTN in your model will always go over it and like you say quality is an issue potentially. So the MPLS fixes that as suggested, but the highlighted issues above will still be present even with this network upgrade.
HTH
I'm not sure, if VPNs goes down, SiteB's users goes in limited functionality.
For sure, replication and topolgy sync will be screwed, but IF in Site B I have all'MCUs, Mediation and PSTN BreakOut + optionally an Edge farm and a RProxy in Site B, the only thing that I loose will be (as already said) topo-sync, federation communications (and if I paired the 2 STD the DR Backup failures) ...isn't it ?
(note: obvious more complex config, more Cert SAN costs, more DNS names and configuration...but is part of the game IMHO)
Yep 100% they will go into limited functionality mode.
There can only be one active master CMS. I assume this to be on Site A's FE. You Pair them it doesn't become active active as far as the CMS is concerned.
The VPN goes down, I am assuming the users in Site A will still have use of SfB there where the CMS is.
You cannot force the CMS online in site B in this event and run a split brain model, When the link comes back up your CMS will be corrupted and everyone will go into limited functionality.
Regardless of all MCU services being there, if they cannot write to the active CMS after 20 mins users go into limited functionality and Skype protects itself from the point of no return.
You put an Edge in Site B, and the VPN goes down, you can only have 1 federation edge for signaling traffic. which assuming is Site A. media is negotiated via local edge to user but signaling will still go via the federation edge, so the session will never begin in this instance.
The only time that you can restore full service is to take Site A completely down. So youre sacraficing all users in site A to satisfy site B users when the link goes down.
If the link stays up but its Skype that fails in site A, then everything continues to work for both sites once you've performed failover.
Hi Mark,
First of all, thank you for your very sharp and contructive answer.
Indeed, my choice to deploy a server FE in the site B is based on some research I have on the internet and especially this article (http://ucken.blogspot.com/2012/10/lync-branch-site-options-and.html) pushed me to this choice there.
In addition I would like to have a complete environment so that soon I can create easly response groups in site B without changing the architecture of the servers.
In my case, Site B employees are completely dependent on Site A Servers (Exchanges servers and other production servers). So anyway if Site A falls, we can not do anything from Site B. (This is the case right now).
In the end, that's why I would like to have more visibility regarding SIP traffic separation.Sami,
