PDA

View Full Version : GMS CDR woes???


carolyn
08-07-2004, 04:39 AM
I was asked to review the monthly stats that are generated monthly through GMS for our endpoints. It has been a while since I reviewed the raw data it gathers and what we use for our monthly activity reports. I don't know if I stumbled across a bug or have discovered a flaw in our installation and set up of the system.

We've been using GMS since 2.6....we are at 6.0. I have 29 systems...25 FX, 3 512's and 2 VS4000's. 3 FX's and 1 512 are in IP only rooms. The rest have 384 BRI and IP. Our connections do not use speeds above 384 for either IP or ISDN. We have an MGC 100 as well...2 ISDN PRI and IP. Many of our conferences are internal MP's due to multi site locations...US only. We typically use the built in MP of an FX or VS for most MP..the MGC is used for specific hi profile VTC, for connections having more than 4 sites, connecting our IP rooms to the outside, and other specific set ups. I keep the software on all endpoints updated so they are current. We do not do any streaming, use visual concert, etc...all room pc's have their own LAN connection..basically it is a straight forward operation.

When I was reviewing the data I noticed some weird calculations. I ran the report for all the sites, IP, ISDN, IN OUT, ..etc...and reviewed that to doubdl check and saw a big issue....Furthermore, thinking it may be a bug in GMS 6.0 or FX/VS 6.0 I looked back through our reports and as far as I can tell..at least since April of 2003 (the last raw data I could find)...the same issues exist. I looked through Polycom's website and forums like this for any info and found nothing...am I the only one? Let me briefly explain it as best I can and you tell me...

Upon initial review...I noticed that GMS was registering a site's activity under the wrong connection type...It would list site A's ISDN activity ...show the IN/OUT and destination (from or to)...what was odd is that it would list the call as ISDN:172..(ip address of other site) instead of ISDN: 5551212(isdn # of other site)...this was true in both IN and OUT ISDN...and it would be recorded as a single ISDN call only (meaning the same call would not show up for site A when compared to the IP activity for site A). In looking into this wierd stat, i went to site A's web interface/call log as well as our schedule for that specific event date/time.

As it turns out, when I cross checked the sources, I discovered that it was a multpoint event with a mixed connection (using both ISDN and IP). I did the same for ther occurences reflecting this same error in the report and concluded the following:
FOR OUT listings
1. When originating EP makes a mixed MP call, GMS interpret6s the event as a SINGL OUT event for that EP. It record the event as an ISDN connection but in identifying the destination it lists the IP address of the last site it connects to in the event. Furthermore, it specifies the duration according to the length of time the ISDN site is connected to it. (if an IP site leaves the VTC connection).

2. In the EP's internal call log, it breaks down and details each site that site A has connected to in the MP event.

FOR IN listings
1. If site B was a participant in the event (A originated), and was connected as the ISDN site...GMS reports it as an ISDN connection for Site B's location (ISDN:5551212...IN....384)...which is correct. BUT
2. If site C participated via IP connection (A originated), GMS will record the connection as an ISDN connection but use the IP address of site A (ISDN: 172..a's ip...IN....384) and this is incorrect as it is an IP call and should be under site C's IP activity.

What's EVEN more BIZAAR is

1. When we use the bridge..bridge dials out to A...IP and then connects to D using ISDN...GMS will report this as an ISDN connection and list the IP of the bridge.

2. If you connect to A from a PC using NetMeeting...GMS also records it as an ISDN connection but uses the PC's IP address to identify the connection destination.

ON THE IP activity recording
1. It appears if B connects to A via IPO and to C as ISDN...GMS record as IP but uses the ISDN address of B. Basically the opposite of above.

When cross referencing..ALL EP call logs are accurate. I did see a coup-le of events whereby an IP only room fell to the recordings of GMS for ISDN. I did not see where it involved the 512 systems.

Why did take so long to uncover...we have realy begun using the mixed connections in MP from the polycoms over the past 3 months or so.. before, most MP from a polycom were all IP(and I have not been doing the data collections for a year). Nothing changed when we have upgraded, swapped out dead systems, etc...like I said..I have seen it in the data as far back as April 03.

What does this mean...well, we use this data to accurately report activity for proper planning and forecasting..and for our executive business summeries

Now that I have uncovered this..I am going to do some controlled testing. I am aslo going to Polycom with it..but I hope this is the result of something with our set up and not an inherent bug that has gone undetected by anyone till now?

I would bve intrested to see any explainations, similiarities, experiences,,,,etc.

tom9933
08-09-2004, 09:20 AM
Carolyn,
I haven’t seen the problems you describe but we are typically using only IP calls. Curious are you using the systems with a gatekeeper? I ask because I have seen problems in the past were a system sometimes says its doing an isdn call when it’s calling the e.164 alias (IP call through the gatekeeper). I’m also a little confused about this problem because I was told (probably long ago) that GMS pulled the CDR data from the endpoint but it seems like this is not the case. BTW make sure you let your rep know about this problem, assuming you already haven’t.
I’ll try to do some IP MP call tests today and see if I can duplicate the problem here as well.

carolyn
08-09-2004, 10:48 AM
Thanks Tom...just to clarify the problem simply...

In a mixed MP call, GMS will record the event for the originating system as a single event(OUT). (I believe it it does this for a IP MP event too...you may want to check that). It will classify this event on record by the first site it connects to (IP or ISDN). It will label the destination based on its LAST connection for the event (IP address or ISDN number).

When a site is hosting a mixed MP, GMS will record this event as (IN). It will classify the connection by whatever site was connected fist in this mixed MP event BY the originating site. It will label the destination based upon the actual connection with either the IP address or ISDN number of the originating site.

For example, we got a recorded event labeled:
AIDHC-ARB234 7/21/2004 14:50 ISDN:172.19.6.100 Out

I cross checked this event and discovered that ARB234 called out ISDN to the first site and then connected to site through IP

Another example...this was a connection made by our MGC100 to a site through IP and a site by ISDN. The site here is an IP only site (however, it was once ISDN capable too..leading me to believe it only happens with FX units that are ISDN/IP):

AIDHC 1F 16 7/26/2004 16:07 ISDN:172.25.52.100 In

I am sending an email to Polycom with this info...

Let me know if you find anything and I will do the same.

BTW we are not registering with a gatekeeper

trapehzoid
08-09-2004, 07:41 PM
Carolyn,
I haven’t seen the problems you describe but we are typically using only IP calls. Curious are you using the systems with a gatekeeper? I ask because I have seen problems in the past were a system sometimes says its doing an isdn call when it’s calling the e.164 alias (IP call through the gatekeeper). I’m also a little confused about this problem because I was told (probably long ago) that GMS pulled the CDR data from the endpoint but it seems like this is not the case. BTW make sure you let your rep know about this problem, assuming you already haven’t.
I’ll try to do some IP MP call tests today and see if I can duplicate the problem here as well.

For a MP/SP unit, GMS needs to 'calculate' the CDR. For a FX and newer it can use the cdr of the endpoint.

tom9933
08-10-2004, 01:28 PM
Carolyn,
I just checked this by making a multipoint calls from a VSX80000 a VS40000 and the MGC. It appears that the problem is only related to the VS4000 because the VSX 8000 unit correctly reported all calls that were made. The problem calls on the VS4000 were exactly as you reported in your earlier post. Just as a reference here are the versions that I’m presently using.
GMS 6.11.176
VS 4000 6.0.1
VSX 8000 7.0
MGC 6.00.65
PathNavigator 5.20.5

carolyn
08-10-2004, 01:56 PM
Well, I know I am not crazy now! I will will your info to Polycom (I do not use the VSX7000)...will you posted! THANKS!