Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

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

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

Everyone's tags (4)
19 REPLIES

Re: Thoughts - the fight for SIP SRVs between Cisco Jabber and L

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.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

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

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, ...

Please remember to rate helpful responses and identify

Re: Thoughts - the fight for SIP SRVs between Cisco Jabber and L

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.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

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

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

Please remember to rate helpful responses and identify

Re: Thoughts - the fight for SIP SRVs between Cisco Jabber and L

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.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".
New Member

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

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.

Regards, Paul
New Member

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

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

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

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

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

Please remember to rate helpful responses and identify

Cisco Employee

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

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

New Member

Re: Thoughts - the fight for SIP SRVs between Cisco Jabber and L

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?

Regards, Paul

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

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.

Please remember to rate helpful responses and identify

Cisco Employee

Re: Thoughts - the fight for SIP SRVs between Cisco Jabber and L

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

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

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

Please remember to rate helpful responses and identify

Cisco Employee

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

Re: Thoughts - the fight for SIP SRVs between Cisco Jabber and L

Hi Magnus, thanks!

I have read all the VCS guides, literally, this is the only one I have never read, because I didn't receive a project involving VCS and Lync integration yet.

This doc is in my "read list" however.

Regards

Paulo Souza

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

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

Re: Thoughts - the fight for SIP SRVs between Cisco Jabber and L

Cheers Guys, some interesting comments - especially relating to the SIP SRV records and thier difference with Lync and a standard based SIP systems. This is didn't know as I misread the initial SIP SRV required for Lync thinking they conflicted (d@mn my dyslexia!).

I'm actually running through a basic Test Lync depolyment at this moment in time to see how we can set it up with the VCS - but what I really waiting for is x8..... (sooooon Chris, sooon....)

.

Re: Thoughts - the fight for SIP SRVs between Cisco Jabber and L

One or two other question regarding this subject and moving onto the actual  integration of the Cisco Videoconferencing infrastructure and Lync. I see  from above that we could actually use the same root external DNS zone to point to both the Lync servers AND the VCS-E without issue as they use different SRV records (ignoring backward compatibility with OCS), but is it possible or even advisable to host the same domain on both environments when integrating, or should they be different? The deployment guide actually shows an example scenario with different domains for the Lync and VC deployments. Maybe I am simply misreading the deploment guide (very likely), but I can't seem to find this outlined.

There is some talk above about the the use/non-use of  FindMe, however, I have just read in the "Microsoft Lync 2010 and Cisco  VCS - Deployment Guide" (page 17) that a FindMe licence is a pre-requisite prior to configuring Cisco VCS and Lync to interoperate. This in itself  might put us a bit on the back foot as we were looking to the potential  to integrate organisations Lync deployment with their current video  deployment, where a lot of VCS-Cs do not currently have the FIndMe licence.

To complicate matter further, we are not  able to follow the Cisco recommended deployment with a separate VCS/Lync  Gateway - as we have over 50+ organisations we simply cannot afford an  additional 50+ VCS-Cs!, although we recently had a conversation with our  Cisco partner and Cisco themselves say that this should be fine although  there are some limitations. For our purposes, we are mainly looking at  enabling simple video communication between the Lync world and standards  based VC world. I have included a sample diagram below and although I  have included Jabber clients, I doubt there will be too many institutions that will incorporate both Jabber AND Lync.Shame, but there you go. It also menas that things like presence and muitlplle user endpoint ringing may not be required by us.

Please note that I haven't included third party callers, I have just update the image to include third parties with standards based SIP/H.323 being routed via the VCS-E and Lync will come in via federated organisation and the Lync Edge Server. Ideally, all users should be able to contact and be contactable via all other users a and organisations.

To sum up, in this scenario:

  1. What is the requirement for configureing SIP domains in each of the requirements, even though we now know that is is possible to route a single domain to both Lync AND VCS, should they still be seperate?
  2. What is the actual requirement for a FindMe licence on the VCS-C?

Message was edited by: Chris Swinney  Updated image to include third parties

Re: Thoughts - the fight for SIP SRVs between Cisco Jabber and L

I have been thinking over this problem and come to a few conclusions about these questions

  1. I suppose that if you want to enable external standards based SIP clients to be able to dial Lync client, then the single domain idea with SRV records pointing to both Lync edge server AND VCS would be the way forward - sure I suppose you could set up a new address space, but this would just seem to make things complicated for the user. This means that the VCS above would need the dial plan to forward calls on to both Lync and potentially registered VCS endpoints.
  2. I also suppose that if endpoints on the VCS and Lync all use the same domain and alias, then it would be again be down to the Dial Plan to determine the potential for where the call is routed. I assume that the same rules apply to the way that the VCS handles calls placement via search rules and that if the VCS finds multiple alias in multiple zones (say through parallel searches of the same priority), then the call will be passed onto the first zone that responds. This means that only one end point (as far as the VCS is concerned) would ring (of course if the call is passed over the the Lync environment then potentially Lync will ring multiple devices?). With FindMe, then multiple alias could be defined and could be called at the same time - however, juts like FindMe is NOT required in the standard setup, I don't see why it would be required for Lync deployment, there are simply some caveats to take into consideration.

I do wonder what would happen on the Lync side if a call was placed to an alias of the same domain and even if this would be forwarded onto the VCS/Lync Gateway. However, I have just setup a demo Lync domain to test this so I'll see if I can figure it out.

I think the other thing that may need to be taken into account is if the is an "in house" remote Lync user that wished to place an call to and external standards based SIP client - in which case I believe the Extended OCS licence would be needed. I'm not sure if this applied to and external third party Lync user wishing to call a standard based SIP user in mydom.com organisation.

Re: Thoughts - the fight for SIP SRVs between Cisco Jabber and L

Well, I have a setup now in test that uses NO FindMe and I must say it works OK. Of course the limitations are with the potential to fork calls to different devices but this is try of an VCS deployment that doesn't run FindMe. We have used the same SIP domain on both the VCS and the Lync domain, so depending on where a user is registered and the search rules that have been implement, would depend upon how a device/user is looked up and called. For the majority of our particular installation, it should work just fine.

I can still see the benifit of setting up a seperat SIP domain for room based VC units, but for users, a single domain and address seems plausaable.

This essentially answer my question 1) and 2) posed above.

The issue now, as I see it, comes not particularly with the VCS deployment or set up, but the the setting of static rules on the Lync deployment. In a simple example in the deployment guide mentioned above, a single domain is forwarded through the Trusted Application to the VCS/Lync gateway. We expanding this slightly to forward a know SIP domain hosted on an entirely different VCS-C/VCS-E installation. Indeed, the deployment guide goes on to say (page 52):

Note: Static routes should only be set up where absolutely necessary, e.g. for allowing ad hoc calls to an MCU:
...
    

If static routes are set up, VCS will receive any requests to that domain that Lync cannot handle, and thus may receive significant volumes of mis-dial traffic.

Now this is all fine and dandy, but what if you actually want Lync users to be able to video call ANY standards based SIP endpoint (in the same way that a Jabber client could do), AND any Federated Lync endpoint?

In the same note, it states that the Lync will first check all registrations BEFORE failing back to a static route. But does this mean that it will check Federation as well before failing back to a static route? Further, Lync can be deployed not only to deal with Video, but more often that not will be looked upon for Voice calls. I can see that potentially routing all such calls through the VCS might be a step too far (especially WRT to call licensing), but still there may be a need to actually offer router all video calls to an unknown destination.

In essence, on the Lync side (and if there is anyone out there that might be able to answer this I would be greatful), I would like to know a few things:

  1. Can a static route be set up to forward ALL unknown address via a trusted application (in a similar vein to a default gateway)?
  2. Will all other possible routes through Lync (such as federated sites) be check before failing back to a static rule?
  3. Is it possible to set up a static rule to ONLY forward video based calls?

On the VCS side of things:

  1. What methods are their to monitor the actual resource usage of the VCS (i.e. CPU utilisation, memory usage, Ethernet port loading etc).

On the latter, I just ran a quick search in the VCS admin guide for the term "CPU" and came up with nothing! The VCS is a Linux box at the end of the day so I do assume that such monitoring would be available - but where and how?

4755
Views
0
Helpful
19
Replies
CreatePlease login to create content