Hi all,

Currently this is Our Environment:

2x Edge server

1 Pool With 3x front end servers

2x mediation server

1 centralized siptrunk

We have users in different countries and regions (USA,Asia,Europe) With local read only DC.
Our setup is localized in Nordic.

Asia users complains that video,meet,voice is laggy and not useable,but chat is fine.

We are planning to setup a New Pool (frontend With mediation role) for asia users,but what about Edge?

Internally it shouldnt be a problem,since they will communicate within the pool (meet,voice,video).What about external,they still Connect to Our Edge in Nordic?

Whats best setup for best user experience (voice,video,meet) ?

t

You can have centralized Edge pool which can server all frontend pools. However for federated traffic, the traffic has to come to Edge servers from different pools.

If you would like to have dedicated edge pool for each Frontend pool check the below link:

https://social.technet.microsoft.com/Forums/lync/en-US/c0a2fa65-55a7-4401-ab26-e34a9a89f8ac/multiple-edge-servers-at-two-different-sites-san-entries-requirment

You can have both Front End pools use the same edge pool, but my suggestion for the best setup would be to add an edge pool in Asia as well, and assign it as the edge pool for media in the Topology builder to the Asian front end pool.  That way three users in Asia chatting from home don't have to have their media traffic leave the continent and come back.

If the Asian users use a different SIP domain, you could create the pool in a separate site in the topology builder and specify a different federation route.  The federation records for that sip domain could then go directly to the Asian edge.

Hi all and thanks for your replies.

So all in all we will need 1 edge and 1 frontend pool in Asia. We all use same sip domain,so means we will have to create another dialin and AV,what about sip?

According to the above link this is one statement i dont get:

"This is handled differently now in Lync 2013 with the introduction of Lyncdiscover.

If you leverage SRV/A records then all clients in the same SIP domain will always register through a single Access Edge Server regardless of their home pool location, but additional services will come directly from their local Edge pool (Webconf, AV).

But if you properly deploy the Lyncdiscover records then external clients will be redirected to their home Edge server for ALL services (SIP, Webconf, AV)."

What about external users?

Since you use the same sip domain, your dialin, av, lyncdiscover, and sip will all go to a single location where your edge is now.  Your federation will also go to a single edge pool.  But the media traffic, which is your big load and where you'd see delays, is what will flow through Asia for local users because it's assigned to that pool in topology builder.  You'll also want a reverse proxy in Asia to publish the external web service FQDN of the local pool to the Internet.

Lyncdiscover will return a small .json file which will tell the user where to connect next, so they can in fact connect directly to their own edge.  If you only deployed SRV records and sip.domain A records, they might hit the original edge first.

Is this 2010 or 2013?

Hi Anthony and thanks for reply,

we are using Lync server 2013.

The part i dont get is external URL for the Edge in Asia.

Now we have sip.domain.com,webconf.domain.com and av.domain.com

Surely we cannot use the same and must come up with 3 new names?

So if we setup a new Frontend pool and edge pool in Asia,Meet and dialin still points to the old edge.When external/internal clicks on that link,it will be redirected/proxied to Asia Edge?

And its ok to use same certificate(as long as it contains all required names) on the Edge server in Asia as well?

Thanks!

Yes, you'd come up with three new names.

Meet and dialin doesn't point to the old edge, it points to the old reverse proxy :)  When someone clicks on that link, for dialin it's tiny and doesn't matter.  For meet, if we're talking about a web meeting, then yes behind the scenes it will show information from your external web services FQDN in Asia, so the data will be local to Asia even though some of the framing is in another country.  If we're talking about the Lync client, then also yes, the media will stream through the Asia edge if the meeting is hosted on the Asia pool.

Technically, yes you can also use the same cert on both edge pools for the external interface.  Although the subject name of the cert should match the access edge name, this isn't really a requirement anymore unless you chat with OCS users still: https://technet.microsoft.com/en-us/library/gg398920(v=ocs.15).aspx

Hi and thanks for quick reply Anthony,

another question,lets say we drop Edge in Asia and just setup a new Frontend with mediation.Internally,what is the different ?

If we dont have Edge in Asia,then user in asia creates a new meeting,will he still be connecting "locally" ?

Then only external users will experience the delay?

If you don't have the Edge in Asia, then internal users will use the new Asian front end for conferences/meetings. An external user would still have traffic leave the country to get to the remote edge to get into the meeting. 

So, yes, only external users will experience the delay, but the delay may be worse.  Now, users in Asia connecting through edge have traffic flow over the Internet to another country then into that country's front end.  Without an Asian edge, an external users traffic will connect through the remote edge over the Internet as before, but that edge will then send the media traffic back over your WAN to the Asian front end.  If you have five external users connecting to the same meeting, you'll have five streams over the Internet and five over your WAN to the Asian front end. 

Ok,so to summarize it:

New Edge in Asia:

sip2.domain.com

av2.domain.com

conf2.domain.com

New Frontend.

Asiapool01.domain.local

Current Edge is the one used for federation and XMPP.

User in Asia pool connects from external network,it will hit reverse proxy of the old edge server,then proxy/redirect to Asia Edge which again next hop is asiapool01.(i guess this redirect is externally?)

External user connects to Meet/conference will connect to old edge,which again will redirect to Asia Edge.(this is also externally redirect?)

Thanks!

Yes.  Pretty much that.  It's not a proxy/redirect as much as a straight direct at times, but yes. 

Also, don't forget the Asian reverse proxy for publishing your Asian external web services FQDN.

great thanks,wont forget reverse proxy,but then we will have to add extra srv and a record exept federationtls?

Thanks for your help!

You could set an extra SRV for federation with a lower priority, but you don't have to.  What you really need is an A record for your web services so Asian users can download address books locally and the like.