" /> tracking number of trunks - Genesys CTI User Forum

Author Topic: tracking number of trunks  (Read 3963 times)

This topic contains a post which is marked as Best Answer. Press here if you would like to see it.

Vic

  • Guest
tracking number of trunks
« on: January 01, 1970, 12:00:00 AM »
Advertisement
Hi, all,

we all know that Avaya does not allow you to track number of trunks in use, so in a multisite environment with limited number of lines connecting two sites, if you use URS, there is always a chance that you will try to route a call to another site even though there is no trunk available, thus effectively dropping the call.

I do not know how to avoid this, so if someone knows a simple way to have Avaya NOT drop the call and instead route it somewhere else, please tell me!

I was thinking about if there is some programmatic way of keeping track of trunks in use.

I was hoping to use VQ for this purposes. The idea was to increase a count in VQ whenever call passes through it. Since Genesys dequeues a call before sending it to the agent, I was thinking about using SendEvent[EventQueued] to increase the count in some arbitrary VQ.

So it would be something like this:

1. When calls passes routing point A, I generate event SendEvent[EventQueued, thisqueue=VQ_Test] and route the call to its destination.

2. When call is released, StatServer would delete this call from it memory.


I was able to get URS to increment the count of calls in queue in VQ_Test and have it remain so after routing the call to the agent. But unfortunately, the count was never decreased, even after call is released!!!

Why? I thought that release call would force StatServer to remove that ConnID from VQ, since it is no longer valid, but this did not happen!

How can I decrease the count of VQ on Release without modifying all the softphones? Is there a simpler way of doing it?

One way I thought of getting it to work would be to create a simple TLib application which would register for all DNs and when EventRelease happens, inarbitrary issue EventAbandoned for VQ_Test, thus effectively removing it from the queue...
It may not be pretty, but it seems to be pretty simple...
Of course, later, it would also monitor the original routing point and issue EventQueued and EventDiverted by itself, right?

But before that, what do you think?

Vic

Tony Tillyer

  • Guest
tracking number of trunks
« Reply #1 on: January 01, 1970, 12:00:00 AM »
Hi Vic,

It is possible that you want Call Concentrator(*) to track the ConnID's through a VQ. With the GCDR Table, it should be fairly straightforwards to monitor "live" calls, showing the number in use in a VQ at any time. You can also produce retrospective reports based on the VQ,s using a timeslice that would show concurrency.

I tried something simlar before, to monitor the concurrent use of calls via 48 VTO Ports, with little success I was advised to use Call Concentrator but we couldn't justify the licenses.

(*)Licensed Product

Hope this helps?

Tony

Vic

  • Guest
tracking number of trunks
« Reply #2 on: January 01, 1970, 12:00:00 AM »
Hi, Tony,

can you explain how GCDR would help me track number of trunks in use?
By default count would be decreased before call is routed to the client, so how can we tell how many trunks are still being used?

I was thinking about something else:

what if I add attach data to calls before routing them to a remote site and then i would create a statistic which counts number of agents talking while using a filter on the attached data? Would it not give me realtime number of agents handling remote calls, thus number of trunks in use?


Marked as best answer by on May 07, 2025, 01:26:09 AM

Tony Tillyer

  • Guest
tracking number of trunks
« Reply #3 on: January 01, 1970, 12:00:00 AM »
  • Undo Best Answer
  • That is one of a number of ways...

    The GCDR Table suggestion is along the same lines of providing a means to record the calls. You've got StatServer, DMA, ETL as well. I was just picking one of them pretty much at random...

    The basics you've stated are right attach data and monitor the data through an RP and you're on the right track. CCPulse should be able to show you the concurrent number of calls using the attached data on that RP.

    Tony