S4B Standard Edition deployement in a branch Site throught VPN Site-2-Site

[Sami CHNITER]

Hi,

I'm currently studying the deployment of Skype For Business.

In my case:

- I have two sites A and B in two different countries. Let A be the main site.
- A Trunk SIP will be deployed only into main site A.

- I will have the same Active Directory on both sites and share the same SIP domain.
- Currently these two sites are linked together through a Site-2-Site VPN and each site has a firewall (TMG 2010).

My objectives:

- Have Skype For Business on both sites with full functionality.

My constraints:

- Use Skype For Business Standard Edition in main site A.

- I would like to have a complete installation of skype for business Standard Edition in the branch site B (no SBA and no SBS).

My question:

1- Is it possible to bypass the VPN for SIP traffic in the branch B site to avoid SIP performance issues?

Thank you!

[#2]

Hi, why are you worried about the SIP traffic?

It's the *lighter* one that you will have to deal, the "heavy weight" actors there will be Media(A/V), Replication, Conferencing Data traffic and not the SIP (IMHO).

[#3]

Hi Andrea,

Thanks for your Reply.

In fact, I'd like to bypass any traffics that is already secured by Skype either signal or media.

[#4]

Any cross-region network connection like MPLS? There is a good article write-up about it https://blogs.technet.microsoft.com/nexthop/2011/11/14/enabling-lync-media-to-bypass-a-vpn-tunnel/

[#5]

Yes, i already found this article. I am bot in the same case but i will try that.

Thanks!

[#6]

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

[#7]

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) 

[#8]

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.

[#9]

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,

[#10]

Hi

Your issue is not SIP separation. It is down to the CMS Database.

I get what you are trying to do, my point is to note that if the S2S VPN failed and both Skype FE's where technically online then no matter what you are going to lose functionality in Site B. Users will go into Limited Functionality even though technically there is nothing wrong with their server.

As I said the reason for this is the CMS can only be active on one server, and this will more than likely be in Site A. As it's just the link between the two sites down Site A retains full functionality, but Site B will suffer if 20 minutes has past with no fix to the VPN. You wouldn't be able to have full mode in Site B. You couldn't "failover" Site B as you'd go into split brain and a whole world of pain!

But in a perfect world, if you localised SBCs, PSTN lines, Exchange etc in Site B for Site B users then when the link is up, you're going to achieve your BAU goal of reducing media over the S2S VPN. My point has always been if that link drops specifically then the hardware in Site B will be of limited use.

thanks