Hi all

I've a question as regards Lync 2010 simple URL and public DNS entries for the EDGE Access: The RKIT explains very well all the Join-Launcher mechanism and how the LYNC client parse the join-meeting URL to retrieve all information needed to join the conference (I copy this explanation at the end of this message). in this description, the simple URL example correspond to the case 1 of the simple URL declaration method, which is http://meet.contoso.com/user/Z4A57TQ

But as you already know, there are 3 options to the format that you can define simple URLs (according to http://technet.microsoft.com/en-us/library/gg425874(v=ocs.14).aspx). the RKIT explanation is using the URL format as describe above (which correspond to the scenario 1 of the link above):

https://meet.AAAAA.com and  https://meet.BBBBB.com

So, what will be the behavior if my company choose the following format below (which correspond to the scenario 3)? the aims of my question is to determine what DNS SRV I will need for the EDGE Acces service.

https://lync.contoso.com/AAAAA/Meet and https://lync.contoso.com/BBBBB/Meet

How can connect my LYNC Attendee to the Edge server if the sip domain is unknown ?

Extract from the MS RKIT:

1/

The web browser opens the Meeting Join page, which, if installed, opens Lync 2010 or Lync 2010 Attendee. If neither client is available, the attendee will join the user by using the Microsoft Lync Web App. For details about the Meeting Join page, see Configure the Meeting Join Page in the Lync Server 2010 documentation, http://go.microsoft.com/fwlink/?linkid=214478.

The Meeting Join Launcher application converts the conference URL that is included in the invitation to the conference URI, which the client needs to join the conference. The Meeting Join Launcher application extracts three pieces of information from the meeting URL to construct the conference URI:

• The base meeting URL (for example, meet.contoso.com)
• The user portion of the organizers SIP URI
• The randomly generated string of alpha-numeric characters that is the conference ID

Lync Server maintains a mapping of meeting URLs to SIP domains, which it uses to convert the base meeting URL extracted from the meeting URL to the SIP domain required by the conferencing service.

For example, using the sample meeting URL described earlier in the Scheduling section (http://meet.contoso.com/user/Z4A57TQ), the domain is identified by using http://meet.contoso.com, the conference organizer is user, and the conference ID is Z4A57TQ. The converted conference URI for this example would then be:

sip:user@ <domain>;gruu;opaque=app:conf:focus:id:Z4A57TQ

2/

The browser opens the selected Lync Server client, and then passes it the meeting URL and any other information required to join the meeting. The client then closes the browser.

Thanks for your help

Matt

Hi,

There is no direct relationship between DNS of Simple URLs and Edge Access service.

The external meeting request would point to Lync external web services through reverse proxy rule. The DNS record for simple url should be pointed to the IP of external network interface of the reverse proxy. If you choose scenario one, at least three DNS A record must to be added in public DNS server. For scenario three, only one DNS record would get it to work.

Simple URLs also don't need SRV record. The SRV record for Lync external access is specific for SIP Access Edge external interface.

_sip._tls.<sip domain>---FQDN of SIP Access Edge external interface

In addition, you can refer to Multiple SIP Domains section in the Jeffs blog for more details:

http://blog.schertz.name/2012/07/lync-edge-server-best-practices/

Note: Microsoft is providing this information as a convenience to you. The sites are not controlled by Microsoft. Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. Please make sure that you completely understand the risk before retrieving any suggestions from the above link.

The Attendee client does not locate the Edge Server on its own, the Edge FQDN, among other service FQDNs, are passed to the client in-band after it has connected to the web service.  So these clients only need to locate the web services on their own.

The mobility clients in Lync work the same way, as does the 2013 Lync Windows clients.  Only the Windows Lync 2010 clients attempt to locate their SIP registrar first and then connect to the web services.  The newer clients all support the Autodiscover service which simplifies the task of locating the different services.

These articles cover this topic in detail:

http://blog.schertz.name/2013/07/understanding-lync-2013-mobility

http://blog.schertz.name/2012/12/lync-2013-client-autodiscover