Lync Reporting - Response Group Usage Report wrong - Transferred calls always zero

When using Response Group Usage Report the number in the column "Transferred calls" is always 0.

Testing with queue overflow and queue timeout still shows 0.

It looks like all fields with information about call transfer are not filled in the stored procedure dbo.CdrRGSCallList.

Can somebody confirm this issue / bug?

Is there a better way of displaying information of queue timeout and queue overflow?

February 26th, 2013 3:33pm

Same issue here, Transferred calls report 0 for all response groups.
Free Windows Admin Tool Kit Click here and download it now
February 27th, 2013 3:02am

Hi,

Would you check event log to see if there is any relevant error message?

Please make sure you choose the correct filters to query the metrics.

February 27th, 2013 10:26am

Hi,

Thanks for your answer.

There are no relevant errors in the event viewer. 

At first we noticed this behavior in the report itself, with no filters applied. Normally the field "Transferred calls" in the Response Group Usage Report should give the number of calls that were transferred on queue timeout or queue overflow. But the numbers in this field are always 0.

Then we started looking in the stored procedure itself (dbo.CdrRGSCallList). The results for fields TCId, TransferTo, IsTransferPickedUp, TCStartTime, TCEndTime, TCResponse, TCDiagnosticId are always NULL for a calltype <> 4 (call transfer according to the comments in the stored procedure).

When executing the stored procedure with calltype 4 there are no results. And we are sure that for our test RGS call transfers has happened. We've configured a queue timeout at which calls are transferred to another number. 

I could post the stored procedure SQL code if this is helpfull?


Free Windows Admin Tool Kit Click here and download it now
February 27th, 2013 11:38am

The strangest thing happened yesterday, in the previous tests we have always used my cell phone as calling device and nothing showed up in the Transferred Calls field and the query gave us 0 calls.

As a test a Lync Enterprise user called the RGS, got transfered and the query returned results! We tested it out on a new RGS and the same thing happened, so if you have 1 Lync to RGS call in the time span the query works.

We (VleugelsJef and myself) have opened a ticket at the support center and are awaiting results of the SQL team.

@bjnorman, could you try our second test as well?

February 28th, 2013 9:50am

I am also experiencing this issue, did you get a resolution?
Free Windows Admin Tool Kit Click here and download it now
May 14th, 2013 11:52am

Hi,

No, not yet.
MS Support thinks REFER support on the trunk is the issue.

On the SIP trunk from the SIP service provider, it is not possible to enable REFER support, as call forwarding does not work at all then.

MS Support tries now to recreate the problem with a gateway, but they seem to have not all resources available...

I don't know if you have a SIP trunk with REFER enabled? Or a trunk between a gateway and Lync where you can test incoming calls from PSTN to Lync with REFER enabled?

May 15th, 2013 10:40am

I'm also encountering this issue.  The SSRS report just times out and if you call the [CdrRGSCallList] stored procedure directly and pass in the transferred calls option (@_CallType = 4) nothing is ever returned.

Any ideas on how to get this working?

Free Windows Admin Tool Kit Click here and download it now
July 1st, 2013 7:32pm

Actually I'm not sure I'm experiencing the same issue you are describing but this is the only result on Google for 'CdrRGSCallList'.  For me, the stored procedure was taking so long to execute when using the transferred calls flag (@_CallType = 4) that it was completely unusable.

After doing some further digging into the stored procedure it seems like the transferred calls report worked but only for a very small time period, passing in a period of 1hr54m work returned results within 16 seconds, however passing in a time period of 1hr55m took several minutes to execute.  If you pass in an even longer period the time taken to execute took exponentially longer, so long that SSRS times out whilst trying to generate the report.

Anyway, I added two missing indexes that the execution plan recommended adding and now it executes in <1 second.

CREATE NONCLUSTERED INDEX [IX_CdrRGSUsage_MissingIX] ON [dbo].[SessionDetails]
(
	[ReplacesDialogIdTime] ASC,
	[ReplacesDialogIdSeq] ASC,
	[MediaTypes] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

CREATE NONCLUSTERED INDEX [IX_CdrRGSUsage_MissingIX2] ON [dbo].[SessionDetails]
(
	[CorrelationId] ASC,
	[MediaTypes] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO

Hope this helps somebody.

July 2nd, 2013 5:37am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics