03-12-2012 01:32 PM - edited 03-17-2019 10:54 PM
Hello All,
I am trying to integrate our Cisco VCS Control and Microsoft Lync server but cannot get it to work. Indeed in the documentation (Cisco VCS X7.0 Microsoft OCS 2007 R2 Microsoft Lync 2010) I've see that you have to create Trusted application Pool and trusted application for the VCS.
The call works fine when I try to call from endpoint to lync client but when I try to call from lync client to endpoint I've the message "cannot locate" I think it's normal because I've no static route to the VCS.
I didn't find any information about static route to add on the lync server for send the request to the VCS in the documentation
(Cisco VCS X7.0 Microsoft OCS 2007 R2 Microsoft Lync 2010) is it normal?
I've try this configuration:
New-CsTrustedApplicationPool -Identity vcs.visio.company.fr -Registrar srvlync-fe1.comiris.com -site 1 -ComputerFqdn vcs.video.company.fr -RequiresReplication $False -ThrottleAsServer $True -TreatAsAuthenticated $True
New-CsTrustedApplication -ApplicationID VCSApplication1 -TrustedApplicationPoolFqdn vcs.visio.company.fr -Port 5061
set-CsMediaConfiguration -EncryptionLevel supportencryption
Enable-CsTopology
$Route1 = New-CsStaticRoute -TLSRoute -Destination "vcs.visio.company.fr" –Port 5061 -MatchUri "visio.company.fr" -UseDefaultCertificate $True
Set-CsStaticRoutingConfiguration -Identity global -Route @{Add=$Route1}
Now I can call Endpoint to LYNC --> ok ( I see during a call in the "status ->call-> B2BUA zone used LYNC and To microsoft lync B2UA)
Lync to endpoint -> video and audio ok in the endpoint side and No video in the lync client (I see during a call in the status->call> default zone to subzone where is the endpoint. I have no B2BUA lunk used.
Can you confirm me that my static route is good or I need to modify the port for static route AND trusted application with port B2BUA 65072?
Like this:
New-CsTrustedApplication -ApplicationID VCSApplication1 -TrustedApplicationPoolFqdn vcs.visio.company.fr -Port 65072
$Route1 = New-CsStaticRoute -TLSRoute -Destination "vcs.visio.company.fr" –Port 65072 -MatchUri "visio.company.fr" -UseDefaultCertificate $True
Thanks by advance for your help
Solved! Go to Solution.
03-14-2012 02:41 PM
Hi Abdel,
I just set up a call from Lync to a PIN-protected auto attendant of an 8510 MCU, and I discovered something which is likely to be related to your issue:
From what it looks in the tests I just made, Lync seems to internally mute the outgoing audio stream if there microphone does not sense any sound activity. This would affectc DTMF tones since these are sent as RFC2833 RTP events on the audio stream. I noticed this as I was sitting in my quiet office - when I set up the call and started sending DTMF tones, these did not appear to be registered by the auto attendant (I would expect to see white dots in the white PIN-frame in the AA).
Once I made some noise so that the Lync client unmuted the audio channel, I could successfully send DTMF tones and they were registered by the auto attendant.
The Lync client did not show any indication that the audio stream was muted.
For the scenario where you call your ISDN GW from your Lync client and the keypad disappears, I believe this is because the ISDN GW only supports in-band DTMF, while Lync 2010 only supports DTMF via out-of-band/RFC2833 RTP events. I therefore don't think that you will be able to place outbound ISDN calls from Lync via the gateway's auto attendant, while it should work (as far as I'm aware) to place outgoing PSTN calls via regular dialing rules on the gateway.
Hope this helps,
Andreas
03-12-2012 02:14 PM
Hi Abdelkader,
for any VCS<>OCS/Lync integration with B2BUA, the trusted application and static route port should be defined as the port configured in 'Port on B2BUA for OCS/Lync call communications' in the advanced settings part of the B2BUA configuration page on the OCS/Lync gateway VCS. This port defaults to 65072, as you suggested in your post.
Please note that you should only create static routes for any domain which is not your FindMe domain if you have enabled FindMe registrations in the B2BUA configuration.
Hope this helps,
Andreas
03-12-2012 02:29 PM
Hello Andreas,
Thanks for your quickly answer.
If I've understand we need to create static route only for domain which is not my find me domain therefore in my case I don't need to do that.
LYNC domain : company.fr
VCS domain: visio.company.fr
findme domain coinfiguration in B2BUA : I've chose company.fr because all my endpoint have findMe names like this:abdelC20@company.fr.
Is it good?
Regards,
Abdel
03-12-2012 02:33 PM
Abdel,
that config looks alright.
Can you clarify why you need the static route for the 'visio.company.fr' domain? Are there any devices you plan on calling from Lync to VCS which you can not reach via its FindMe alias?
Regards
Andreas
03-12-2012 02:47 PM
Andreas,
I think i don't need the static route.
I've done migration from OCS to Lync and previously on OCS all endpoint will be reachable will findme-names:
abdelC20@company.fr with H323 or SIP alias :abdelC20@visio.company.fr
etc....
During the Lync integration I didn't find any information about route therefore i've done the route static as you seen before.
No I've understand if your endpoint use findme names with the same domain that LYNC domain you do not need to create a static route.
Can you confirm?
Thanks again
Abdel
03-12-2012 03:01 PM
Hi Abdel,
yes that is correct, you only have to add static routes in order for reaching devices which are not associated with a FindMe account where the FindMe domain is the same as the OCS/Lync domain.
Regards
Andreas
03-12-2012 06:47 PM
What about in the event you want to use an MCU and have Lync participants route to ad-hoc or meet me bridge Addresses. Would static routes be the best way To achieve this?
Sent from Cisco Technical Support iPhone App
03-13-2012 01:48 AM
Hi Ryan,
yes with certain types of MCU usage, such as Ad-hoc/MeetMe conferences and Multiway, it is recommended and in some cases required to register the MCU in a separate domain and set up a static route from OCS/Lync towards this domain.
This is in fact mentioned in the "Optional: MCUs" section of the OCS/Lync deployment guide. This section also has instructions on how to create such routes.
Hope this helps,
Andreas
03-13-2012 04:33 AM
Hi Andreas,
I'm presently doing a VCS / Lync integration using this guide you referenced above. My take on Findme within the guide is it demonstrates how to utilize "personal" endpoints (e20's, ex60, MXP1700, etc..) with a lync environment. We lab'ed this out and the guide works very well. As for the Room Systems such as "C20's, c40's etc.. and of course the MCU's mentioned above" I was considering not using findme for these systems because there isn't really a person tied to them. In addition to this you would have to create a findeme account and a lync account for each room you have out there. For the room systems I was thinking of doing the same as the guide recommends for the MCU where the endpoints are just in a sub-domain such as "@vc.example.com" and 1 static route in Lync. The only drawbacks we seen in our lab to this method is that.
- 1 less presence field for visible endpoints on Lync (unable to see in a call / busy) just online or offline
- Since we are not creating a Lync account for the room systems the, route is not published in Lync, the users must manually add the route to "endpoint@vc.example.com" (to overcome this we considering asking the exchange person to send out the routes to everyone's contact list when we are done"
-There may or may not be some pushback from the AD people about the requirment for adding a sub domain.
Your feedback and experiences are appreciated.
Cheers
03-13-2012 05:21 AM
Hi Ryan,
this is a matter of preference really - and you have correctly listed the drawbacks of omitting FindMe registrations towards Lync.
Having "Busy/In call" presence for room systems could be useful, while people who dial into these room systems would normally do so to attend a scheduled meeting - in which it would not make much of a difference if the system is Online or Busy.
For MCU-hosted virtual meeting rooms however, having Busy/In Call presence could be useful since users would then be able to see if a virtual meeting room is available or already in use.
There's also the challenge with phone books as you mention - If you introduce a sub/secondary domain for room systems and MCU conferences, this might have the consequence that users will have to manually type in the destination number, and depending on your users and their technical skills, this might or might not work well
The only additional work needed for enabling FindMe accounts for room systems and static MCU conferences/virtual meeting rooms is really the creation of the FindMe account itself (Which could be done automatically via provisioning/TMS) and creating the corresponding AD account, enabling this for Lync and logging into it once with Lync.
I would say that the benefit you get by doing this (Enabling rich presence for room systems and virtual meeting rooms) outweighs the workload needed for this, but that is my personal opinion and is obviously much easier to do in a lab environment than in production.
Hope this helps,
Andreas
03-13-2012 05:43 AM
Andreas,
Yes abosolutly this helps, great feedback.I do have 1 followup question. The MCU is the only piece i'm missing in my Lab so I havent' been able to validate pro's / con's with Findme and without for the MCU.
Can you provide some info on how Findme will work with and MCU. My customer uses the MCU in their environment for the following.
Lets say the ask is all of the above. How does 1 Findme reference for the MCU facilitate this or am I over simplifying what you are explaining? I envisioned that i would need the following findme accounts:
I hope what i'm explaining makes sense to you
Cheers Ryan
03-13-2012 08:10 AM
Ryan,
as far as FindMe goes in relation with MCU's, the most applicable use would be when using virtual (static conference) meeting rooms, where it would be beneficial to create one FindMe account per virtual meeting room, so that you could leverage 'Available' and 'Busy' presence to determine if a particular virtual meeting room is available/free or currently in use.
You could optionally also have a FindMe account for one or multiple auto attendants on an MCU, if that makes sense in your environment. Some customers use auto attendants heavily while others do not use them at all.
Multiway does not work well with FindMe, so in those cases it would be recommended to use a subdomain with a static route from Lync to VCS rather than creating a FindMe account for every possible Multiway conference number. With Multiway conferences, you are not really interested in Busy presence anyways since you will normally be automatically included in the Multiway conference.
In my opinion, presence is mostly useful for seeing the availability of static resources, such as personal and room systems, (static) virtual meeting rooms and so on.
For CUCM/PSTN audio only participants, using FindMe or not depends on what device these callers will dial to. If the destination is a static conference or video endpoint, FindMe could be used, while if the destination is a Multiway conference, FindMe would not make much sense, since FindMe is intended to be used with static/permanent addresses.
Hope this helps.
-Andreas
03-13-2012 08:29 AM
Hi Andreas,
Excellent feedback thanks.
My take away would be that in my situation there is definate value in creating a sub-domain for the MCU. Create Findme accounts for the MCU that is for anything that is static such as "meetme" rooms and "AA" Then use STatic routing for Multiway and everything else.
On a side note
I'm trying to give you 5 star rating but for what ever reason my bowser selected 1 star. I will try from another broswer this is suppose to be 5 stars
03-13-2012 08:33 AM
Ryan,
I'm glad to hear my comments are helpful to you. I'm not posting here because I'm hunting ratings so you don't have to bother about fixing that
Regards
Andreas
03-13-2012 09:42 AM
Hello Andreas,
Thanks for your help yesterday, now all call LYNC<->VCS works fine, I've just add a static route for to be able to call TO internet or ISDN GW. I success to call to the internet from my client LYNC->VCS-c->VCS-E but I've DTMF issue.
Indeed when I try to send DTMF from lync client to MCU codian or GWCodian it doesn't works.
Before the upgrade OCS->to Lync i I had these issue but the latest version has resolve these problem but now with Lync it's same problelm no dtmf send from LYNC client to COdian Product.
Any Idea
Thanks by advance,
Abdel
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide