New to Telepresence

[equinox198]

We have had the Cisco telepresence solution in place for about 1 year.  We have a VCS/VCSe/MCU/TMS13.1.2(yes old, but we are upgrading as we just had our smartnet upgraded.  We were without it for a bit).

We are having a weird problem with units not being to place calls after a certain situation (we don't know what causes it).

Basically we get an error message saying that we can't route to host, but on the units themselves, we are able to ping and traceroute as well as on the VCS. 

A reboot seems to resolve the issue, but I don't think that's practical.  This October I will finally be taking a class to get a better understanding, but looking for some help as TAC can't figure it out or the assigned tech can't.

9/3/2013 9:55:45 AM           Connection Error           Source Number: , Destination Number: h323:172.xxx.xxx.xxx, Cause Code: No route to destination

The devices can ping each other and a traceroute works from endpoints and vcs/vcse/tms

IN THE LOGS I HAVE SEEN CALL REECTED WITH A RESPONSDE CODE UNKNOWN REASON

Also what causes a call to be rejected with an unknown reason

[Paulo Souza]

Hi, welcome to Cisco Support Community!

Can you provide further information about your problem? Such as:

Are the endpoints registered to VCS?

Are you trying to make the call using TMS or dialling from the endpoint itself?

What is the endpoint and version involved?

About the log you posted, was it taken from the endpoint?

What equipment did you reboot to solve the problem?

Regards

Paulo Souza

Please rate useful replies and remember to mark any solved questions as "answered".

[dortewillemann911]

Hellu,

no route to destination> are yougetting it on ARQ serch message or in Setup serch message.

apparently one gets this message when correct regex is not configured and pointed towards the subzone/zone.

questions asked by paulo will halp.

additionally: 

end points you are trying to call. where are they located is it an onnet call or an offnet call.

please describe the call flow

like my assumption:

VCSc -----------|firewall|---------- VCSse

how are endpoints placed here,. Can you upload the logs youve taken.

I thank u.

Dorte..

Please rate useful replies and remember to mark any solved questions as "answered".

[noc]

I have a TMS(13.1.2)/VCS(x7.0.2)/VCSe(x7.0.2)/MCU 4501 v 4.3

VCS -> VCSe (internal Nic) ->Firewall -> VCSe (External Nic)

I have the dual nic license on the VCSe

The endpoints are behind the firewall.  There are 10 scattered throughout NY,NJ,CHI.

Here is an example.  This log is from the VCS:

2013-09-03:Sep  3 19:36:17 vcs1.fitchratings.com tvcs: Event="Message Received" Service="Q.931" Message-type="ReleaseComplete" Src-ip="172.xxx.xxx.2" Src-port="2776" Dst-ip="172.xxx.xxx.160" Dst-port="15035" Call-serial-number="9aa29d58-14f1-11e3-bef5-0010f3206072" Tag="9aa29e70-14f1-11e3-9ae0-0010f3206072" Detail="Q.931 Cause:No route to destination, H.225 Cause:Unreachable destination, Additional Info:None" Protocol="TCP" Level="2" UTCTime="2013-09-03 23:36:17,197"

2013-09-03:Sep  3 19:36:17 vcs1.fitchratings.com tvcs: Event="Message Sent" Service="Q.931" Message-type="ReleaseComplete" Src-ip="172.xxx.xxx.160" Src-port="1720" Dst-ip="172.xxx.xxx.242" Dst-port="11017" Call-serial-number="9aa29d58-14f1-11e3-bef5-0010f3206072" Tag="9aa29e70-14f1-11e3-9ae0-0010f3206072" Detail="Q.931 Cause:No route to destination, H.225 Cause:Unreachable destination, Additional Info:None" Protocol="TCP" Level="2" UTCTime="2013-09-03 23:36:17,199"

When I reboot the VCS and the unit, the issue goes away.  It happens periodically, but intermittently. 

Internal calls should go through the VCS and anything external should go through the VCSe.

Which logs are needed?  From the VCS or the units themselves?

The call was initial done with the touch screen.  After the reboots, I did everything from TMS.

This log was taken from the endpoint

9/3/2013 9:55:45 AM           Connection Error           Source Number: , Destination Number: h323:172.xxx.xxx.xxx, Cause Code: No route to destination

[Paulo Souza]

Hi,

Following the logs, I would say that you are receiving this message from VCS Expressway. VCSe is releasing the call with that error message "no route", then VCSc sends the same messge to the endpoint.

Tell something, is this an internal call or are you trying to call an externall endpoint?

-- If it is an internal call, why is the call being routed to VCS Expressway? Are you dialling IP address?? The call should be routed to the endpoint directly and not to VCSE. Is your dial plan configuration correct?

-- If it is an externall call, maybe your VCSe does not have the proper network configuration. As you use have dual nic interface, you should configure the default gateway point to the external network gateway, then you configure a static route to communicate to VCS Control and point it to the internal network gateway.

Can you check this?

Regards

Paulo Souza

Please rate useful replies and remember to mark any solved questions as "answered".

[equinox198]

The VCSe never gets the call as it is no suppose too.  It is the VCS that gets the call.  Since it is in gatekeeper mode shouldn't the calls be routed through it???   We have the setup with two nics and the static route coming in per the document so that is not the issue.  We also have subzone & sub zone membership rule which basically treats internal IPs differently from external IPs.  The VCSe is only used for external IPs and any alias that does not pass the search rules under our domain.

We also have a subzone with sub zone memberships for the private IP of our network.

From there I have 2 search rules which looks at address and then routes it to the local zone if it is know(subzone), if it is not, it will go to the traversal zone which gets passed on to the VCSe.  (Local IP dialing vs External IP dialing)

Would that be causing the issue???? 

[Paulo Souza]

Hi,

I am sure that this error is received from VCSe, take a look at the log you posted:

2013-09-03:Sep  3 19:36:17 vcs1.fitchratings.com tvcs: Event="Message Received" Service="Q.931" Message-type="ReleaseComplete" Src-ip="172.xxx.xxx.2" Src-port="2776" Dst-ip="172.xxx.xxx.160" Dst-port="15035" Call-serial-number="9aa29d58-14f1-11e3-bef5-0010f3206072" Tag="9aa29e70-14f1-11e3-9ae0-0010f3206072" Detail="Q.931 Cause:No route to destination, H.225 Cause:Unreachable destination, Additional Info:None" Protocol="TCP" Level="2" UTCTime="2013-09-03 23:36:17,197"

Do you see? The message comes from VCSE. So the call is probably not being routed correctly by VCS Control, then VCS Control tries to route it to VCSe. So, the main point here is not that error message, the point is, why VCS Control is not routing the call to the endpoint properly??

Can you share a search history output taken from VCSc related to a call attempt that is presenting that error?

The main point here is to figure out why VCS is not routing the call to the endpoint, the error message "Unreachable destination" can be ignored, once it comes from VCSe.

Regards

Paulo Souza

Please rate useful replies and remember to mark any solved questions as "answered".

[equinox198]

Log Files

[equinox198]

Paulo,

Thanks for your reply.  Thanks for the insight as it is opening up a few issues I'm having.

So this is what I found.  We have a few units that are registered to TMS but not the VCS for all communication due to various reason, mainly non-technical ones.

Some units get registered into TMS for easily manageablility but I think the issue is the global address book.

By default TMS adds in entries for IP, H323, and SIP for all registered TMS devices, but it doesn't mean it is necessarily registered to the VCS unless I specified that in configs.  Since some units can not be configured with the VCS as it's gateway at times, it creates issues.

For these units, I made SIP aliases and routing through the gatekeeper for SIP only.  Since the TMS address book adds in all three units by default under Discovered Systems and I think the default is calling method on the units are H323 via the touch screen, it gets pushed to the traversal zone as the VCS has no knowledge of the H323 record.  SIP works great because everything is registered under the VCS so it finds it's way.  Calls made through TMS or through the web, work because I specifiy SIP.

I removed the systems from TMS and just made non registered endpoint entries via IP and that works great.  My question is should I even be registering devices that I don't have full control as I want to see it in TMS, as the tool is helpful to have all units in one place?  Essentially the units are setup in Direct mode and not gatekeeper mode (THE ONES I'M HAVING AN ISSUE WITH). 

I will be attaching logs to show.

[Paulo Souza]

Just like I imagined, your issue has nothing to do with the "No route to destination" error message. 

Well, I don't know if I understand yor environment very well, but I think you have H323 endpoints in direct mode because you cannot register them to VCS. And you want to schedule those endpoint in TMS, right? In this case, I think you should add them to TMS as "Room", in this case, you wont manage the endpoints, you will only have them registered to TMS to scheduling and to control calendar. When adding the endpoint as "Room", you can choose if you want to dial SIP or H323 to reach the endpoint.

To avoid TMS to automatically register the system into System > Nvaigator, you can disable the "Auto discover" feature of TMS.

Is that what you need? Sorry, I don't know if I understand your issue well.

Regards

Paulo Souza

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

[equinox198]

The reason why I can't put some units in Gatekeeper mode is because we control the Americas and EMEA (Euope, Middle East, and Asia) is handled by another IT group in the same company.  So you can imagine the politics and so forth.

I had some issues with the rendevous function and the Video Sales guy says that it does not work with IP.  So to use SIP.  So I was able to setup SIP on those devices and point back to us just for SIP calls.  All other calls would be in direct mode and bypass the VCS.  When I imported them into TMS, it creates a phone book entry for all call methods even though it's not available.  For ex, the unit out in EMEA only had IP calling but no H323 alias with characters, so it puts in the address book the IP, H323 (but uses the hostname, but the service is actually off on the unit), and the SIP info I put.  The h323 address is not registered to my VCS because I have not set it up to, because I can't.  I was able to do SIP after talking to my counterparts as they don't know what it is or even use it, so it's not disruptive.

My issue is that the touch screens on the VC units default to h323 addresses in the address book, which I presume is configurable.  I think this is why the issue was so weird for me was because when I do the calling from TMS, I always select SIP and it works great.  When users walking in the room and call one of these remote units, it calls by H323 and not SIP and then the issues begin.  When they use the address

book for the units we have full control of, we have no issues. 

I can setup a print screen to show you want I mean.

In regards to understanding my issue, you are on point. Here is a brief overview of the layout.

Americas                                             EMEA

VCS                                                    C60

VCSe                                                   MX300

MCU                                                    MX200

TMS

15 MX,XM UNITS

EMEA: SIP WORKS GREAT VIA TMS OR WEB GUI.

FOR all users calling EMEA VIA THE TOUCH SCREEN

Address book entries default to H323 based off the logs and this ismy issue. As there are no H323 registrations on my VCS because I can't register it. 

In the future, EMEA will be getting there own infrastructure which should alleviate some issues.  People just like the whole dynamic rendevous feature where calling multiple units with the MCU, so they wanted us to incorporate it out in EMEA some how and I may have gone wrong about it.

I will try the meeting room as that seems like a great idea.  I just made a non registered endpoint entry in the address book for the UNIT1 and that seems to work well.  I want to test out the meeting room setup.  I will get back to you.

Again, thank you for your patience.  I will be attending a calls from Sept 30 to Oct 4 to get much needed insight.

[Paulo Souza · Accepted solution]

Now I got it.  =)

Well, If you register them to TMS as room, you leave all the H323 option in blank, so that only SIP information will be imported to the phonebook. Also, you can completly disable H323 scheduling for those system, so only SIP will be used.

This is an example that should work fine:

Don't configure any H323 field, then you will be able to have phonebooks in TMS for those system with only the SIP information. Then, when the users dial from touch device using phonebook, only the SIP URI will be used, so you won't have IP H323 dialling and you wont have the call being routed to VCS Expressway.

I hope this help.

If it solves your issue, please, mark your topic as answered.   =)

Regards

Paulo Souza

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

[equinox198]

Great!!!! I will test this out and if all is good, I will mark correct answer.  I believe I did so with the original reply you had as it definitely pointed me in the right direction.

[Patrick Pettit]

Hi. Your issue sounds familiar, but will need to comb through your logs to see if we can find something or evidence of what Im thinking may be happening here. Are you able to private message me your case number, so I can have a quick peek? What have you provided so far for your case? When was the last time you booted the VCS? Was a full system snapshot from VCS requested? Reason Im asking is because it may prove useful to look through.

Let me know?

VR
Patrick


Sent from Cisco Technical Support Android App

[equinox198]

Patrick, the Tech was is analyzing the logs, but do you still want the logs.  I think I have found my issue from what Paulo suggested.