Do Lync 2010 clients dream of lyncdiscover records?

Lync client discovery should be well-known subject for being widely documented. Most will know that Lync 2010 client is (or was?) SRV record-oriented, that is, its preferred discovery methods were based on the two following records:

_sipinternaltls._tcp.sipdomain.com for internal  Lync pool
_sip._tls.sipdomain.com for external Lync edge pool

whereas Lync 2013 family clients (with some differences on the Lync store app) are A record-oriented, that is, its preferred discovery methods are based on the two following records:

lyncdiscoverinternal.sipdomain.com for internal Lync pool
lyncdiscover.sipdomain.com for external Lync edge pool

It seems to be common knowledge that more recent Lync 2010 clients introduced the same behaviour as Lync 2013 clients, supposedly having the feature to now query the lyncdiscoverinternal and lyncdiscover added through an unspecified CU (or, I was unable to find specific information).

This seems to be confirmed by the following Technet article and several other sources. Specifically:

"(...) Microsoft Lync 2010, Lync 2013, and Lync Mobile are similar in how the client finds and accesses services in Lync Server 2013 (...)" "(...) For all clients except for the Lync Windows Store app During DNS lookup, SRV records are queried and returned to the client in the following order:

1. lyncdiscoverinternal.<domain>   A (host) record for the Autodiscover service on the internal Web services

1. lyncdiscover.<domain>   A (host) record for the Autodiscover service on the external Web services

1. _sipinternaltls._tcp.<domain>   SRV (service locator) record for internal TLS connections

1. _sipinternal._tcp.<domain>   SRV (service locator) record for internal TCP connections (performed only if TCP is allowed)

1. _sip._tls.<domain>   SRV (service locator) record for external TLS connections

 " (...) Cumulative updates to the desktop clients change the DNS location process from Lync Server 2010 (...)"

On a customer's site, with Lync 2013 server, and an unusual proliferation of both Lync 2010 and 2013 desktop clients, however, a different behaviour was noted. The scenario was:

- Lyncdiscover and lyncdiscoverinternal records were deployed
- _sipinternaltls.tcp and _sip.tls records were NOT deployed

Lync 2010 clients were still able to perform server discovery and sign in both internally and externally, but it was determined Lync 2010 discovery happened through sip.domain.com A record (existing on both sides of split DNS) and not through Lyncdiscover and lyncdiscoverinternal. This was randomly discovered as sip.domain.com records were briefly removed due to a sip domain migration and caused Lync 2010 client sign in to start failing.

A test seemed to further confirm this:
This is a Wireshark trace of a Lync 2013 client sign-in process, and it shows the expected and documented behaviour:

This is a trace of a Lync 2010 client (January 2014 update - 4.0.7577.4419) - there is no trace of client trying to query lyncdiscoverinternal and lyncdiscover; SRV records are queried first, then failing back to sip.domain.com A record.

My takeaway was: ensure _sipinternaltls.tcp and _sip.tls records are deployed whenever Lync 2010 clients are or may be part of the game :)

About the dreaded 504 timeout error with Lync Push Notifications (rings a bell?)

Like several others, I was pestered with issue where at a customer site, Lync 2013 Push notifications to Apple and Windows Phone failed to work despite the apparently correct configuration. The error was 504 timeout, which is thrown out by the push notification test cmdlet:

Test-CsMcxPushNotification -AccessEdgeFqdn

(where -AccessEdgeFQDN is the internal Edge Pool FQDN).

Alas, this is a frequent although (fortunately) well-documented issue on a number of great blogs with several possible (and working) resolutions. Worth nothing reminding proper Push Notification functionality is dependent on 
But what happens if everything else fails and you still get stuck with it?
After some further research and attempts, the only quick fix for me was to break federation and re-create from scratch like follows:

1) remove federation with push.lync.com
2) remove federated provider for LyncOnline
3) disable push notifications
Set-CsPushNotificationConfiguration -EnableApplePushNotificationService $False -EnableMicrosoftPushNotificationService $False

3) add back Lync Online hosting provider:
New-CsHostingProvider -Identity "LyncOnline" -Enabled $True -ProxyFqdn "sipfed.online.lync.com" -VerificationLevel UseSourceVerification

4) add back allowed federated domain for Push Notifications:
New-CsAllowedDomain -Identity "push.lync.com"

5) Re-enable push notifications: 
Set-CsPushNotificationConfiguration -EnableApplePushNotificationService $True -EnableMicrosoftPushNotificationService $True

6) Worth checking that Federation is enabled:

Set-CsAccessEdgeConfiguration -AllowFederatedUsers $True

Tested again, and, happy days :)

If that did not work for you, or possibly BEFORE you try, I suggest you check these great resources for alternative resolutions:

I'm a UC Blog

The Lync Guy's Blog

Microsoft UC Made Easy

Lync SIP trunks: internet or private?

A recurrent question during Lync technical workshops (and a key design decision in Lync Enterprise Voice deployments with PSTN SIP trunking) is identifying the most appropriate SIP trunk type. Internet or private?

SIP trunks can be deployed over the Internet or over a dedicated private WAN connection (MPLS typically); each, with supposedly clear pros and cons. In reality, there's a bit of confusion around this topic and a decision is not necessarily straightforward.

There is great deal of public literature around the subject if you want to dive deeper into each aspect. The purpose of of the article is only to provide a quick reference table for elements and criteria that should be considered and discussed to determine which circuit is most suitable.

Feature	Internet-based SIP trunk			MPLS-based SIP trunk
	Pros	Cons	Mitigating factors	Pros	Cons	Mitigating factors
PROVISIONING	Fast delivery times. Easy to set up				Slower delivery times. More complex to set up. Likely to require a dedicated circuit to SIP trunk carrier	If core MPLS carrier is also a Telco might be able to provide SIP trunk on existing circuit
COST	Relatively cheap - lower TCO				Expensive - higher TCO
NETWORK READINESS	Pratically 100% businesses already connected to internet and might potentially have capacity for SIP trunking. If not, in-place bandwidth upgrade is usually viable and requires no infrastructure upgrade				Higher investment for small businesses that don't have MPLS circuits in place
BANDWIDTH	Relatively abundant and cheap	Bandwidth is not guaranteed (best effort, no SLA). Asynchronous connections like ADSL provide limited upstream bandwidth	Ensure accurate capacity planning is carried out to ensure bandwidth is adequate for expected number of PSTN sessions. Lync CAC may also help	Bandwidth is guaranteed with SLA	Significantly more expensive than Internet bandwidth	Appropriate capacity planning and QoS adoption would make significantly more efficient use of bandwidth
AVAILABILITY		Uptime is not guaranteed (best effort, no SLA)	Redundant internet connections to different carriers may reduce downtime	Uptime is usually guaranteed with SLA and significantly higher that internet connections
NETWORK PERFORMANCE		More network hops, more subject to packet loss, latency and jitter. Unpredictable performance irrespective of bandwidth	Geographically closer SIP trunk carriers might require fewer hops to their infrastructure.	Network performance is more predictable especially if QoS is implemented. MPLS less subject to packet loss, latency and jitter
CALL-CARRYING CAPACITY	Usually more abundant nominal bandwidth theorically allows for a greater call-carrying capacity	Call-carrying capacity is influenced by many other factors and network conditions, which become more likely as sessions are added on the wire. Internet-based SIP trunking is generally advisable for low call volume requirements		Call-carrying capacity is more easily predictable and voice traffic can be shaped. MPLS-based SIP trunking advisable for higher call volumes
QoS		QoS cannot be implemented end-to-end. Traffic cannot be prioritised by type	Buying a dedicated additional Internet line for SIP trunk would help segregating data/web and voice traffic, yet proper QoS is not achievable	QoS can be implemented. Proper traffic prioritisation by type is viable
SECURITY		Voice traffic flows through uncontrolled network and may potentially be intercepted.	Use a SIP trunk provider that supports TLS (encrypts SIP signalling and SRTP (encrypts media), or deploy SIP trunk through VPN (less recommended: adds further network overhead and may impact QoE)	Voice traffic flows through private and screened network. TLS and SRTP are still advisable for enhanced security
NAT		SIP protocol not NAT-friendly, several known issues when NAT is used	Prefer avoiding NAT when deploying SIP trunk. Alternatively, ensure firewalls are SIP-aware (SIP ALG)	NAT less likely to be deployed in MPLS network, but if so, same considerations apply		prefer avoiding NAT when deploying SIP trunk. Alternatively, ensure firewalls are SIP-aware (SIP ALG)