cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3892
Views
6
Helpful
19
Replies

VCS X7 B2BUA to Microsoft Lync integration problem with Static route

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

1 Accepted Solution

Accepted Solutions

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

View solution in original post

19 Replies 19

awinter2
Level 7
Level 7

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

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

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

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

totoT1700@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

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

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

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

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

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

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.

  • Multiway for all the endpoints that do not have built in multisite (most don't)
  • Allowing CUCM and PSTN audio only participants to join in (listen only) on a video conference
  • Scheduling of Conference which provides a "dial in" sip / h.323 uri for all video participants LYNC included
  • Adhoc and always running meetme bridges.

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:

  • 1 findme for each "Multiway" possibility. So if Multiway for simplicity had a range of 20 numbers, then would I not need 20 Findme acconts and 20 Lync accounts?
  • 1 Findme/1Lynce account for each Scheduled Conference URI
  • 1 Findme /1Lync account for each meetme or adhoc always running bridge

I hope what i'm explaining makes sense to you

Cheers Ryan

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

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

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

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