No MCU CDR logs on TMS

[smilewonee]

Hi cisco-ster!

I brought 2 simple issues regarding TMS(14.3.2) interoperation.

1) When it comes to Reporting-Call Detail Records-MCU, I couldn't see any records on the graph.

Even though the MCU is correctly registered on MCU(4.1), the records don't show in that page. Also I could see the records of every registered endpoints.

2) With the Packet Loss Logs on TMS Reporting category, I could only see the MXP endpoint's logs not C-series(TC6).

Have I missed some configuration? or both are working as per designed?

I would welcome any reply regarding this topic!

Thank you          

[Kjetil Ree]

Hi Paul,

Paul Changwon Choi wrote:
1) When it comes to Reporting-Call Detail Records-MCU, I couldn't see any records on the graph.
Even though the MCU is correctly registered on MCU(4.1), the records don't show in that page. Also I could see the records of every registered endpoints.

MCU software 4.1 is quite old (2010?), so we haven't tested it systematically with TMS 14.3.2. Would upgrading to 4.4 be an option?

2) With the Packet Loss Logs on TMS Reporting category, I could only see the MXP endpoint's logs not C-series(TC6).

That's expected, this feature was never implemented in TC software. The endpoint never gives the data to TMS.

Regards,

Kjetil

[Kjetil Ree · Accepted solution]

Kjetil Ree wrote:
Paul Changwon Choi wrote:
1) When it comes to Reporting-Call Detail Records-MCU, I couldn't see any records on the graph.
Even though the MCU is correctly registered on MCU(4.1), the records don't show in that page. Also I could see the records of every registered endpoints.
MCU software 4.1 is quite old (2010?), so we haven't tested it systematically with TMS 14.3.2. Would upgrading to 4.4 be an option?

I did some more digging, and TMS's asynchronous bridge CDR mechanism requires MCU 4.2 and later. I strongly recommend upgrading your MCU software.

If upgrading isn't an option, verify that the feedback receiver is set correctly on the MCU, and then do a network trace to have a look at how TMS is responding to the feedback. Is TMS always responding with a 200 OK? Anything about it logged in TMS's log-web-public.txt?

-Kjetil

[smilewonee]

I think this is a correct answer. I will try to upgrade the software of MCU and see if this issue to be resolved.

And for the second inquiry, it is very strange if it is expected. Eventhough TC software comes till 7.0.0 version and MCU has 4.4, Why do they still support only MXP which is becoming end-of-life, end-of-sale?

Most of our customer considers Paket Loss Logs function on TMS is highly important. Will there be any plan to implement this feature on MCU?

Best Regards,

Paul

[Martin Koch]

Kjetil, regards the feedback receiver, I did not try it, but what happens if the

TMS has secure management on and the MCU lacks the encryption key.

Culd this also cause issues. Not sure if the MCU would then show up at all,

but if it would, would a https feedback address be supported?

Regards the packet loss, I think thats a really sad story, we had complained about that

before. That was a really useful feature. I think it was a missed chance to not properly

gather / provide CDR and quality data from endpoints and the infrastructure.

Please remember to rate helpful responses and identify helpful or correct answers.

[Kjetil Ree]

Hi Martin,

Martin Koch wrote:
Kjetil, regards the feedback receiver, I did not try it, but what happens if the
TMS has secure management on and the MCU lacks the encryption key.
Culd this also cause issues. Not sure if the MCU would then show up at all,
but if it would, would a https feedback address be supported?

I haven't tried this setup, but I would assume it won't work.

Note that the feedback receiver method of generating CDRs is no longer used by TMS; since MCU 4.2, TMS uses the MCU's cdrlog.enumerate API call to gather CDRs created on the MCU itself, which TMS then just displays verbatim. Not that it changes your question though, if TMS is set up to speak HTTPS only, and the the MCU doesn't have HTTPS enabled, this would obviously not work.

Regards the packet loss, I think thats a really sad story, we had complained about that
before. That was a really useful feature. I think it was a missed chance to not properly
gather / provide CDR and quality data from endpoints and the infrastructure.

I also think this would be a nice feature. You could always try to raise the issue again through your account manager or other formal Cisco point of contact; if so, please refer to CSCtq54891.

Regards,

Kjetil