Thoughts - the fight for SIP SRVs between Cisco Jabber and Lync depolyments?

[Chris Swinney]

Hi all,

I suppose this is more a discussion rather than a direct question, but I would like to know your opinions.

We maintain a large VC network spanning many organisations. The has been based mainly on H.323 but we are trying to move toward SIP and so are requesting institutions add SIP SRV into their Internet DNS zones to point to the relevant VCS-Es.

However, a lot of the institutions are are looking to deploy Lync into their organisations - they are all essentially MS AD environment with Exchange and SharePoint, so it seem like s sensible option for them. Of course even though you can effectively trunk between the VCS and Lync server pool, at this moment in time only Lync 2010 is supported with a poor resolution (ignoring silly options like the AMG). although current (and upcoming) software from Cisco will support Lync 2013 and higher resolutions.

However, then we run into a quandary. Most institutions would want their users to be contatcable via a SIP URI that matches their e-mail address, and this is generally the root domain name of an organisation. I would love to be able to say that then should point the SIP SRV to the VCS-E, but they will want to point these toward the MS Lync server pool. Of course, we could point a secondary sub domain (i.e. video.domain.com) to the VCS and the root to the Lync pool, but is there any way we could get a a user to have both Lync and Jabber with the SAME URI (although I fear this would be also be regarded as confusing).

What do others do? Throughts and answer of a postcard (or just reply in this thread...)

Cheers

Chris

[Paulo Souza]

Hi Cris,

Nice subject to discuss about.  =)

I got your point and the issue you are discussing here, but definitely I think you cannot use the same URI (at least the domain portion) for both Jabber and Lync clients for calls coming from internet. That is impossible!! Not only because a dial plan mismatch, but because when calling from internet, the only way we have to decide which system (MS or Cisco) will receive the call, is by using DNS SRV records, and this configuration is fully related to a specific domain or subdomain, you cannot have a single domain point to both systems at the same time (in fact, you can use an A record point to VCSe and MS Server IP addresses, but it makes no sense and you will have problems to register the clients).

Well, in my opinion, there is no way to do that, except by having two different domains or subdomains, one for Cisco environment and another for MS environment. You could use the same address portion of the URI, but the domain portion should be different. For example, paulo.souza@cisco.com and paulo.souza@ms.cisco.com (that was hilarious rsrs). Something like that, as you stated before.

I have not implemented a project with such environment (Jabber and Lync receiving calls from internet), but if I did, I would suggest the customer to use two different domains.

However, I am aware the we are going to have many scenarios like that, because Cisco will bring amazing features for Jabber client in a near future. But when this happens, I personally believe that the customer will have to choose, either using Cisco Jabber or MS Lync, I really don't think they will want to have both things, Jabber and Lync, because Cisco Jabber will work such way that the customers won't no longer have reasons to keep Lync, Jabber will be enough to achieve all the needs of the customers.   =)

This is a personal opinion. I am not member of Cisco, obviously.

Regards

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

[Martin Koch]

No, sip is not a problem, lync and vcs can nicely coexist. Either independent or with the gw-vcs

with findme and the b2bua also integrated in between each other.

Its rare that I say  microsofts proprietary handling is good, but here it is.

Standard based SIP (Cisco) uses different SRV records for SIP as Lync is.

Regards Jabber, lets see if its more Jabber/XMPP, that could be interesting to see how to

integrate it , but thats more because I have never checked it out.

But I think I had seen some interdomain documents, ...

[Paulo Souza]

Martin,

I understand your point, but what about external video systems calling your Lync+Jabber video from internet? They will use standard SRV records to discover the server and make the call. I believe this is the point here, how to redirect the call to both systems by using DNS? It is not possible unless you use different SIP domains for MS and Cisco enviroments.

We are aware that it is possible to use FindMe + VCS-GW to integrate Cisco and Microsoft, but I think what Cris want to point here is related to external standard users calling your Jabber/Lync clients by dialing their email address. In this case, technically speaking, you cannot use the same email address to route the calls for both Lync and Jabber, so you would to create different SIP domains for Jabber and Lync. Of course FindMe+VCS-GW can be helpfull, but without it I dont think it is possible.

Regards

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

[Martin Koch]

But thats exactly the point, its not possible!

A "standard based video endpoint" can not dial lync

and lync can not dial do a standard based video endpoint.

If you want to do so, you would need a VCS which does the magic in between.

Lync does not care about the _sips._tcp srv and the vcs does not care about the _sip._tls

So without an integration both could work separate, but then standard calls would only hit the vcs based

infrastructure and lync calls only lync.

If you need to be transparent reachable you need the integration.

An other issue is dialing out, as without workarounds you can only handle the inbound calls,

so everyone would need their own vcs integration.

http://www.cisco.com/en/US/docs/telepresence/infrastructure/vcs/config_guide/Cisco_VCS_Microsoft_Lync_2010_Deployment_Guide_X7-2.pdf

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/im_presence/interdomain_federation/9_1_1/CUP0_BK_IB27169E_00_interdomain-federation-integration-guide-9_1_1_chapter_01.html

[Paulo Souza]

Hi Martin,

Now I think I understood your point better.  =)

This is the key statement: A "standard based video endpoint" can not dial lync and lync can not dial do a standard based video endpoint.

I didn't know that. Now I know. Probably it is because the video coding protocol used by Lync.

Resuming, it would be this:

• Lync integration with another Lync = DNS SRV is not standard
• Lync integration with standard endpoints (local and internet) = DNS SRV standard points to VCS; VCS-gw used to Lync integration; FindMe can be used

Tell me something, Have you already used FindMe having a device pattern pointing to a Lync client? I guess it supposed to work if VCS is properly integrated with Lync, but I have never done that personally.

Thanks for clarifying the things, Martin.  =)

Regards

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

[Paul Woelfel]

I also had this issue, that there is Lync and also Telepresence infrastructure. In most cases there was also the _sip._tcp record pointing to the Lync Edge Server, so I choose to use a subdomain, like video or vc.

I'm not the Lync expert, but I have seen this DNS entry in multiple domains, so I believe there is a reason fort that.

[t.svatek]

I have also observed, that _sip._tcp often points to the Lync Edge Server. I think this comes from older OCS Deployments. With Lync 2010 and 2013 _sip._tcp isn´t longer used. But in all Versions, MS recommends to also set a sip.domain entry.

For OCS 2007, during DNS lookup, SRV records are queried in parallel and returned in the following order to the client:

1. _sipinternaltls._tcp. - for internal TLS connections
2. _sipinternal._tcp. - for internal TCP connections (performed only if TCP is allowed)
3. _sip._tls. - for external TLS connections
4. _sip._tcp. - for external TCP connections

For Lync 2010 and 2013, Lync Mobile, during DNS lookup, SRV records are queried and returned to the client in the following order:

1. lyncdiscoverinternal.   A (host) record for the Autodiscover service on the internal Web services
2. lyncdiscover.   A (host) record for the Autodiscover service on the external Web services
3. _sipinternaltls._tcp.   SRV (service locator) record for internal TLS connections
4. _sipinternal._tcp.   SRV (service locator) record for internal TCP connections (performed only if TCP is allowed)
5. _sip._tls.   SRV (service locator) record for external TLS connections
6. sipinternal.   A (host) record for the Front End pool or Director, resolvable only on the internal network
7. sip.   A (host) record for the Front End pool or Director on the internal network, or the Access Edge service when the client is external
8. sipexternal.   A (host) record for the Access Edge service when the client is external

[Martin Koch]

Guess the main reason is the legacy and the thought which you had:

it was always there, it must have a reason ;-)

[Magnus Ohm]

Hi Paulo

Tell me something, Have you already used FindMe having a device pattern pointing to a Lync client? I guess it supposed to work if VCS is properly integrated with Lync, but I have never done that personally.

It works very well with FindMe

/Magnus

[Paul Woelfel]

Magnus Ohm schrieb:
Hi Paulo 

Tell me something, Have you already used FindMe having a device pattern pointing to a Lync client? I guess it supposed to work if VCS is properly integrated with Lync, but I have never done that personally.
It works very well with FindMe 
/Magnus

And what about without findme? If you got a large company with thousands of users, you may not want to configure a FindMe Account for every one right?

[Martin Koch]

Especially with thousands of users it makes sense to have a proper VCS Lync GW deployment

to properly offload presence traffic and only get messages for addresses which really exist.

If you have thousands of ulync sers you should have anyhow a good organized AD

where you can nicely import your users from, so not really much configuration needed.

[Magnus Ohm]

Hi Paul

Well to me it sound much easier to create thousands of FindMe accounts, you don´t have to configure the findme account one by one. You import all your users from AD (Lync accounts) to TMSPE. Enable B2BUA and if you have set it up correctly the FindMe users who is also lync accounts will start registering to lync automatically and voila. So the process for creating 10 000 findme accounts is not a timeconsuming job.

If you have you lync accounts in a different sipdomain you then create a new lync device for each user once and then regenerate the settings to all users in one click.

You do not have to have findme but I think you then need a static route from your lync server to the VCS. Then an active directory phonebook where you import the lync addresses should do the trick for the phonebook on the vc´s to reach the lync users. I´m not sure if presence will work (maybe only on the lync client side if you create a static route)

/Magnus

[Martin Koch]

think the only disadvantage I see is that only one lync sip domain is supported per gw-vcs / b2bua

[Magnus Ohm]

Here is the deployment guide which explains a lot.

http://www.cisco.com/en/US/docs/telepresence/infrastructure/vcs/config_guide/Cisco_VCS_Microsoft_Lync_2010_Deployment_Guide_X7-2.pdf

/Magnus