Release trunk on external transfer?

[atrain24]

We have a PRI and when our Reception transfers Calls back out to the PSTN it ties up 2 trunks and stays on our system.
We have also noticed at the 15 minute mark it drops the calls.

Any ideas on how we can resolve?

Older 3300 ICP as well.

TIA!

[x-man]

The 15 minute bit is controlled by a timer in the trunks class of service. You can change the time or turn it off altogether there.

There is a specific service to stop a trunk using another trunk to complete a call. Its available in the UK but not at all sure about Canada. In the Uk its called call deflection . Its a paid for service but is really only useful if your trunks are getting busy because there are a lot of redirected calls. Simply put the call is routed via the exchange rather than the telephone system once a call is diverted out and releases both lines at the system.

[atrain24]

Is it considered normal behaviour for a call to be transferred externally and yet it still consumes trunks on the PBX?

I would think the call should then be removed off the system.....

[x-man]

Yes, it is considered normal unless you have the correct pri service as noted. Check with your line supplier to see if they do the service.

 Alternatively get some SIP trunks and use these to be a cheaper way of not consuming your PRI's for externally transferred calls.

[atrain24]

The biggest issue is it seems to drop the call after 20 or 25 minutes - Wondering if there is a COS timer doing this?

[x-man]

Call timers are in COS for trunks or phones. There are call timers for internal and external calls and the ability to turn them of altogether.Set trunks to match extensions to avoid conflicts unless you give extensions different COS. I would turn it off on trunks in that case. Be aware that there is a possibility that a call could be held for a long time and hackers love that kind of setup. It differs for SIP trunks unless things have changed in release 9.

[atrain24]

Here is an SMDR record for one of the calls:

+04/16 12:33P 01:02:29 T100  005 9258528572 4700 5555        3515T T100         
     011   9258528572 4700
+04/16 12:33P 01:02:12 3515      3515 17079398841          A T100               
     011   

This call was transferred to 7079398841 and I still don't get why it stays on for the entire duration of the call - They transferred and hung up so why is the call staying on the system?

[Dogbreath]

Because either
a) The phone system isn't telling your PRI provider to divert the call and does it itself
b) The PRI provider will not accept a request to divert the call so the phone system must do it itself
c) Something in the call flow causes the phone system to do something on the call before the divert, eg play a RAD message.

After writing the above, I've re-read your original post. I am sceptical that there is a mechanism with PRI signalling to have the provider handle the divert after you've answered the call.

[x-man]

I am sceptical that there is a mechanism with PRI signalling to have the provider handle the divert after you've answered the call

Call deflection should work on PRI (its in the price list anyway under ISDN30e). You still pay for the diverted leg of the call but the connection is done in the exchange

[ZuluAlpha]

3515 is definitely disconnecting after the transfer, correct?

[atrain24]

Yes 3515 is disconnecting after the transfer.

[Dogbreath]

I am sceptical that there is a mechanism with PRI signalling to have the provider handle the divert after you've answered the call

Call deflection should work on PRI (its in the price list anyway under ISDN30e). You still pay for the diverted leg of the call but the connection is done in the exchange

It doesn't apply to the OP's scenario:

Reference ETS 300 202 [45], ETS 300 206 [46] and ETS 300 207-1 [47].
Call Deflection enables the served user to respond to an incoming call by requesting redirection of that
call to another user. The call deflection feature can only be invoked before connection is established
by the served user i.e. in response to the offered call, or during the period that the served user is being
informed of the call.