UCCE: How to match Routing Client to IP address of Peripheral

[RyanBurtch]

I work in Managed Services.  I have to get into different customer environments when issues happen. Many times, I'm researching a dropped call or something like that via the AW/HDS.

I see the calls come into RCD/TCD via some Routing Client '5001, 5002, etc', but I need a way to correlate these routing clients to the actual peripheral's IP ADDRESS (CVP1,2,3, CUCM, etc.)

I know I can get this from PG setup, but I can't take the environment down when I'm troubleshooting, plus I have no idea which PG to pull from as many of these environments are quite large.

Is there any other way to get this info quickly?  Thoughts.

[Slavik Bialik]

I have a nice workaround that I'm using always in that exactly case when I don't want to shut down the PG service in order to see how it is configured.

I just go to the registry in the PG server and go to a location like this for example:

HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\ICM\{instance_name}\PG2A\PG\CurrentVersion\PIMS\pim1\VRUData\Config

The above case is for a VRU PG instance. As you can see there's a VRUData folder in it.

Anyway, in the Config folder, you can find a key called "VRUIpHostName" which will contain the IP address of the CVP or the hostname of it so you can just ping and get the IP.

In case of a CUCM PG instance, you can find the IP address of the CUCM in the following path:

HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\ICM\{instance_name}\PG3A\PG\CurrentVersion\JGWS

In there, you'll find one or more folders called "jgw1" and "jgw2" and etc, depending on how many PIMs you configured towards your CUCMs (for example one goes to Publisher and one goes to Subscriber).

So if for example you want to look into jgw1 that's the full path where you'll find the CUCM IP address:

HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\ICM\{instance_name}\PG3A\PG\CurrentVersion\JGWS\jgw1\JGWData\Config

In a key named jtapiService.

Hope it helped ;)

[Ryan Burtch]

That is really helpful.  So now my question is, what if they have like 20 cvp servers?  How do you know which PG to log into?  I may be splitting hairs, but I'm trying to speed things up when I have to get into a customer's environment that I've never been in.

[Slavik Bialik]

Well, in my case, I'm also part of managed services. And for that we have conventions that we go by. For example, PG1A will be always for CUCM PG and PG2A will serve the VRU PG. So in my case, it is always easy to know which PG holds the CVPs.

Anyway, if you go by my tip, viewing the registry... if a PIM have a VRUData, it means it serves a VRU, if not.... so it probably don't ;)

Another fast way, you can go into a PG server to: C:\icm\{instance_name}

and go into all the PG folders (PG1A, PG2A, etc....) you have in there. If a folder contains a folder named "vrucap" means it is holds VRU services.

Another way... going into Diagnostic Framework Portico, to List Processes. There you'll see all your PGs are their processes, and all of the PIMs. Each PIM has a the peripheral name written near it, so if you have a naming convention for the peripherals like "CustomerCVPA" and "CustomerCVPB" you can easily understand that those PIMs and this PG is serving CVPs and not something else.

[bill.king1]

I might be misunderstanding your question, but if you're already looking in SQL, why not just look in/join the Routing_Client and/or Peripheral tables? You could put the IP address in the description for one of those and use that to determine where the call originated from?

[geoff]

Ryan

But you do know the Logical Controller that the Routing Client belongs to. Therefore you know the name of the PG. True, you don't know it's IP address. I don't see an easy way of getting that. You will have hostnames or IP addresses in the Machine Table - but only for Agent PGs (this is used by Live Data). If you had 40 CVP Call Servers and 4 pairs of CVP PGs running 10 PIMs each there is no easy way but to create a spreadsheet to guide you. 

You won't know if the PIM was active on the A side or the B side at the time of the incident from the database so you will have to check both sides.

The fastest thing would be dumplog pimN /m <ANI> where N is the PIM number and the /m flag to dumplog is the pattern matcher. I do this all the time as a first pass - and if you see a match you see the timestamp, so you can refine your dumplog with a /bt and /et to span the time of interest and use the /o to create the text file. If you don't see a match you are on the wrong side. 

Regards,

Geoff