Maxing out VTO ports

[CTIgem]

We have 48 vto ports maxed out at one point and calls got dropped.
Is anyone know why calls getting dropped and how to cound those calls?

Thanks.

[cavagnaro]

Dropped? How do you know calls are dropped? By dropped you mean VTO cuts them, right? Maybe at the max point you have more calls on your PRI and try to send those calls to the VTO place group and as there are no more resources URS drops the call.
You will have to receive a complain from a customer, find out from which phone number he called you so you can use this ANI or any other recollected info to track the call down and seek why it was droped.

[bcyk]

When URS is configured a busy treatment, calls are 'queued' for avaiable free VTO port at Route Point.

VTO ports are assigned in top-down manner by URS; the seqential order is determined by URS.
In other word, if the sequential order is 1003, 1004, 1002, 1001, 1005, the extension 1003 will always be searched and assigned first.


One of reasons to count free VTO ports is to have different strategy call flow.

Method 1. configure an agent group equivalent to VTO place group members
  - all VTO ports are logged-in an agent and use AgentAvailable statistics
    to get ready ports before calling the target object with busy treatment
      Cons: requiring additional switch licenses!
      Pros: better exception handling in T1/E1 configuratin
            when VTO server is down, all agents will be logged-out
              ** no auto agent logout if analogue ports are used!

Method 2. configure a customised "OnHook" statistics in IRD
  - Retrieve number of "Onhook" ports in VTO place group before calling
    the target object with busy treatment
      Cons: when VTO server is down, T1/E1 line(s) are out of service but VTO server
              and URS cannot detect such event
      Pros: not requiring VTO port agent log-in


Under 'normal' operation, queued VTO calls will not be dropped.
Without debugging log files to identity exact dropped point, some potential causes for dropped calls could be:

1. extensions and physical voice circuit ports are mis-matched
  -> verify T1/E1 circuits / extensions configuration

2. telephone voice circuit malfunction
  -> the port is out of service due to whatsoever reason
      when URS sends interaction to it, call will be dropped
  -> similar case may happen when analogue lines with incorrect switch configuration are used as VTO ports

3. time-out at switch Route Point
  -> it may happen in some switch configurations
  -> example: Avaya Adjunct     
      06 adjunct    routing link 1
      07 wait-time  20  secs hearing ringback
      08 stop

      -> assuming that URS target object waits for 16 seconds before giving busy treatment
      -> under normal case with available ports, queued calls will be routed to VTO ports.
      -> once voice interaction has been "Answered" by physical device, the switch adjunct
        routing is completed; thus, switch does not control the voice interaction afterwards
      -> Calls arrive at VTO ports are now controlled by URS (it is why all VTO ports are available in IRD!)

      -> if there is no available VTO, URS "queues" voice interaction.
      -> With above vector script commands, call control will be returned to switch after 20 seconds
      -> IF there is no special handling in vector command, interaction will be dropped
      -> in this case, the easiest work-around is to increae the wait-time to larger value
        although such configuration does not have good exception or fallback handling


regards

[CTIgem]

I'm seeing

10:13:13.914_G_I_ [01:0b] look for hanged interactions: 61 at all now
    _G_W_00f1019c6bf0a38f [01:0b] call waits too long (98 sec)

Then drops.

Does it make sense?

[bcyk]

"call waits for too long"?
Was the statement extracted from URS debug log file?
What are the switch and CTI-link?

Suggest to check both switch Route Point configuration and URS strategy again.
Under proper configuration, URS waits for available VTO port and does not drop the call.

BTW, starting from 7.x (forget behavior in 6.x), URS waits for VTO and target ready agent simultaneously. In older version URS/IR waited for VTO only; thus, the interaction must "park" at VTO before transferring to ready agent.

[bcyk]

hold on..... 98 seconds call queuing without being answered by any device!

These calls can be terminated by PSTN / telco carrier!

[fixed-line/mobile] ----> PSTN ---> PBX ---> extension
                                        ^^^^
                                        timer (90~120 seconds)

When a call is distributed from PSTN to PBX, there is a time-out value.
The value varies from telco carrier. In other word, if PBX does not return any answer signal or 'line-reversal' signal within the timer interval, PSTN drops the call.


It can be verified quite easy; make a call to direct extension but don't answer it.
After 90 or up to 120 seconds, the call will be terminated by PSTN.

Check this point as well!

[CTIgem]

Thanks for the input.
Let me check with PBX forks.

[S]

I would think you check the timeout value for the Busy treatment, it should be same or less than the target agents queuing timeout. Second, provide a coverage path in PBX for those VTO extensions, so when the VTO ports are not available or doesn't answer for any reason, the coverage path kicks in and you can see stats on that coverage path or an externsion assigned to that path.

S

[CTIgem]

Timeout value is same on both busy treatment and target.
What is coverage path? we have nortel environment.

Thanks.

[S]

I can tell from avaya side... if the DN is not answering, we use the coverage path, meaning route to a default VDN for VTO... just like your desk phone if not answered goes to voice mail or fwded to another phone #(if its setup).
There should be something like this in Nortel PBX also ....
hope this helps...

S