PDA

View Full Version : Tandberg Call Log Collection


Mark6292
10-04-2004, 10:53 AM
Collection is Tandberg TMS 8.0 with Tandberg codecs running either E3.0 or B8.0. For some reason TMS is not collecting call records from all of the remote sites. For instant I had a 13 site bridged call managed by external supplier, which dialled the systems and only 1 system has posted a call record.

The systems are based in the UK and Europe and are all contactable from TMS for management purposes.

Any ideas ?

Mark

Gary Miyakawa
10-04-2004, 12:23 PM
Interesting. Does that mean a Tandberg endpoint doesn't keep a call log history ? (I'm kinda new to the T'berg folks).

Sorry I don't have an answer for your collection problem.

Gary Miyakawa

Mark6292
10-04-2004, 12:47 PM
The Tandberg codec keeps a record of the last 10 calls. I'm not sure how TMS pulls these records from the Codec, whether by Telnet or SNMP.

Regards

Mark

Sean Lessman
10-04-2004, 02:47 PM
The Tandberg codec keeps a record of the last 10 calls. I'm not sure how TMS pulls these records from the Codec, whether by Telnet or SNMP.

Regards

Mark

I think its the last 20 calls and its communicated back to TMS via SNMP. If you aren't getting them, try checking your SNMP connectivity between TMS and the endpoints.

If you have further trouble, contact your service representative. It works here :-)

Sean

Mark6292
10-05-2004, 03:36 AM
I think its the last 20 calls and its communicated back to TMS via SNMP. If you aren't getting them, try checking your SNMP connectivity between TMS and the endpoints.

If you have further trouble, contact your service representative. It works here :-)

Sean
Sean

I tend to agree with you that it's probably SNMP that's the issue. The stange thing with this problem is that some calls are being collected, therefore SNMP is working to an extent. I have passed to service representative, but was doing some internal investigations.

Regards

Mark

Mark6292
10-08-2004, 09:53 AM
Sean

I tend to agree with you that it's probably SNMP that's the issue. The stange thing with this problem is that some calls are being collected, therefore SNMP is working to an extent. I have passed to service representative, but was doing some internal investigations.

Regards

Mark

As an extra question does any one know how the call record collection process work on the Tandberg equipment, ie when a call is made, a record is written to the call log, then when is the call log written to TMS ?

Regards

Mark

Morgan81
10-08-2004, 12:31 PM
As an extra question does any one know how the call record collection process work on the Tandberg equipment, ie when a call is made, a record is written to the call log, then when is the call log written to TMS ?

Regards

Mark

From what I've heard and from what I have seen, when the endpoint sends the SNMP trap to TMS saying that the call has ended, is when TMS reports it.


I've also seen this exact problem before in our units, however they were running B4.x versions of software. Anything new than that (all E's have worked without a problem) has been fine. Usually we see an error in the trap log by a call status trap saying, "(Error getting Call Log: SNMP++: Agent indicates error in SNMP request Timeout set to: 1000)", and it usually doesn't matter what we have the timeout set to in Admin tools.
What really is strange is that these same units then tend to dump their calls all on one day. What I mean by this is that we will recieve multiple traps, all at virtually the same time, of legitimate calls that were made over the course of a few weeks sometimes. Hour long calls back to back, only recieved seconds apart. The only fix that we have seen work is to upgrade to the newest software. But E3 and B8 have always worked perfectly for me... that's strange stuff.

Mark6292
10-12-2004, 03:29 AM
From what I've heard and from what I have seen, when the endpoint sends the SNMP trap to TMS saying that the call has ended, is when TMS reports it.


I've also seen this exact problem before in our units, however they were running B4.x versions of software. Anything new than that (all E's have worked without a problem) has been fine. Usually we see an error in the trap log by a call status trap saying, "(Error getting Call Log: SNMP++: Agent indicates error in SNMP request Timeout set to: 1000)", and it usually doesn't matter what we have the timeout set to in Admin tools.
What really is strange is that these same units then tend to dump their calls all on one day. What I mean by this is that we will recieve multiple traps, all at virtually the same time, of legitimate calls that were made over the course of a few weeks sometimes. Hour long calls back to back, only recieved seconds apart. The only fix that we have seen work is to upgrade to the newest software. But E3 and B8 have always worked perfectly for me... that's strange stuff.

Morgan

THanks for the information. I've seen the SNMP time out message on the TMS logs, even on the latest software releases. Will do further invetsigation.

Regards

Mark

trapehzoid
10-14-2004, 10:57 PM
Try downloading a SNMP test tool and use that. SNMP uses UDP so its succeptable to network conditions. I think TMS also comes with its own SNMP tool as well.

And the tandberg codecs hold their call logs in SNMP.

Mark6292
10-15-2004, 04:52 AM
Try downloading a SNMP test tool and use that. SNMP uses UDP so its succeptable to network conditions. I think TMS also comes with its own SNMP tool as well.

And the tandberg codecs hold their call logs in SNMP.

Trapehzoid

The SNMP Tool in TMS only provides a mechanism for checking that codec can be contacted. I'm looking for the TSNMP tool that is mentioned in the Tandberg SNMP White Paper.

Regards

Mark

Sean Lessman
10-18-2004, 02:18 PM
Trapehzoid

The SNMP Tool in TMS only provides a mechanism for checking that codec can be contacted. I'm looking for the TSNMP tool that is mentioned in the Tandberg SNMP White Paper.

Regards

Mark

TSNMP tool should be on the TMS CD.

Mark6292
10-19-2004, 04:18 AM
TSNMP tool should be on the TMS CD.

Sean

It's not on the CD I have.

Mark

Sean Lessman
10-20-2004, 06:50 PM
Sean

It's not on the CD I have.

Mark

Maybe I do not know what I am talking about :) send me an email at sean.lessman@tandbergusa.com and I will make sure you get it.

Sean

Mark6292
11-16-2004, 08:18 AM
Maybe I do not know what I am talking about :) send me an email at sean.lessman@tandbergusa.com and I will make sure you get it.

Sean

Have resolved issue. Was due to SNMP configuration on the TMS server having too many community names. Have only placed TMS community name on server and it works OK.

Mark

patcheye
11-22-2004, 06:10 PM
Hi all,
On a related TMS question: Our TMS 9.2 can't determine whether our Polycom FX endpoints (both v6.0.1 and v5.1) are making H320 or H323 outbound calls. Therefore the "endpoint" report that's generated by TMS is inaccurate because it will not report usage of any calls where the protocol is "unknown" (Reporting > CDR > Endpoint).
Our calls are 99% IP and our endpoints are registered to a RVSN gatekeeper so we dial using a e164 alias. Not sure if dialing using an e164 extension is confusing the TMS but calling using IP addresses makes the TMS recognize the call as H323 (I don't want users dialing by IP addresses).

Any suggestions as to how TMS can recognize the calling protocol of Polycom endpoints when making outbound calls to e164 aliases?

As an alternative, if TMS can generate Endpoint reports listing all H320, H323 and Unknown protocols then it would be acceptable as I need an accurate endpoint usage report.

Mark6292
11-29-2004, 03:33 AM
Hi all,
On a related TMS question: Our TMS 9.2 can't determine whether our Polycom FX endpoints (both v6.0.1 and v5.1) are making H320 or H323 outbound calls. Therefore the "endpoint" report that's generated by TMS is inaccurate because it will not report usage of any calls where the protocol is "unknown" (Reporting > CDR > Endpoint).
Our calls are 99% IP and our endpoints are registered to a RVSN gatekeeper so we dial using a e164 alias. Not sure if dialing using an e164 extension is confusing the TMS but calling using IP addresses makes the TMS recognize the call as H323 (I don't want users dialing by IP addresses).

Any suggestions as to how TMS can recognize the calling protocol of Polycom endpoints when making outbound calls to e164 aliases?

As an alternative, if TMS can generate Endpoint reports listing all H320, H323 and Unknown protocols then it would be acceptable as I need an accurate endpoint usage report.

I've been down this route with Tandberg before. I'm currently running TMS 8 and have 1 Polycom Viewstation on the network and it does report H.323 and H.320 accurately. Due to upgrade to TMS 9 in the next few weels. I'll do some tests and see what happens.

Mark