Can't disconnect interaction in IRD 7.5 strategy

Hello all,
I’m fighting a strange issue (to me). In the actual routing method, I usually split the strategy in 2 parts; a main “IN” application that invokes GVP (** DeliverCall[‘return:ok|dn:601|rdn:601|switch:GVP|target_location:StatServer75URS|target_name:601_GVP|target_type:RP’,DELIVERTOAGENT] **) in order to be able to use gvp play applications (play&continue/play&collect/play&exit) ended by a play&exit app called by a play application block. On the Avaya VDN I set a return DN where the “OUT” application is loaded. To disconnect the call, where needed, I set a Update Data and where the condition is “UData =xx’” I use a function block with the RouteCall[‘return:ok|dn:27417’] function. 27417 is a DN corresponding to an Avaya VDN with a simple disconnect string on the vector. Usually this works fine… other times simply the RouteCall doesn’t works and the interaction repeates the last strategy it is coming from.

In URS logs:

_I_I_009c024525f5dbe5 [07:2a] HERE IS ROUTE TO TARGET: return:ok|dn:27417
_T_I_009c024525f5dbe5 [07:2a] check call routing states: state=0 delivery=0 treatment=0 held=0 reserving=0 ivr=0 - false
_I_E_009c024525f5dbe5 [09:04] error in strategy: 0008 Routing done
_I_I_009c024525f5dbe5 [09:04] ASSIGN: RETURN(LOCAL) <- STRING: return:error

There is another disconnect method I could use instead of RouteCall[‘return:ok|dn:27417’] ?

Any tip will do.

Regards,

Gef.

0008 error usually means that URS already “definitively” routed this call (execute some
routing object or RouteCall or TRoute function which routes the call,
DeliverCall is not counted as routing function).
After routing happens URS will reject any other “call moving function”
with 0008 error message.
Probably will be good to check logs etc. as call moves through routing points in regards of why
URS might consider this call as already routed.

Thank you Terry. I’ll look in log to understand what happens, but there is a way to force call disconnection from ird ?

Depends on your PBX. Which one you have?

Hi Cavagnaro. Avaya s8720 (CM3).

Ok, so you have a strategy running on URS/SIP Server to call GVP application?
If so, do this after calling the application:

In URS, we use the bloc “Multifonction Function properties” and we first use sip option : “ExtensionAttach[‘{d}sip-status-code’,‘486’]” and then the function TRoute[‘’,‘’,RouteTypeReject,‘’]

Check here:

http://www.sggu.com/smf/index.php/topic,7577.msg32601.html#msg32601

The idea is that GVP ends application and returns control to SIP Server /URS

If on Avaya CDN check your TServer guide and see if it supports the ReleaseCall Treatment and apply it if supported

Thanks a lot, but I haven’t SIP Server; all here works in h.323.

Did you think I could try with a event generation (error or disconnect) instead of the SIP Error event and then using the troute ?

Running GVP 7.6?

Hybrid 7.5/7.2

URS 7.5, TServer 7.5, IVRServer 7.2

Ok…kinda oldy but lets see
You say that after it fails to route it repeats the same strategy, correct? Can you say on your URS how you are handling the on_router_error option? I guess is reroute.
You could try to do a OnRoute Error function on your strategy. By some reason I think the VDN can’t accept more calls, you have to see on TServer what is happening

Quite oldy indeed, but this is all I’ll have for a long time

In URS default option section, there isn’t an “on_router_error” option; there’s an “on_route_error” instead and it is set as “delete”.

And yes, it repeats the last strategy, or the strategy loaded on the default dn if a return destination is set on pbx’s vdn.

I’ll try to introduce an onroute error function and I’ll let you know.

May be it is possible to see entire URS log for the call from first TEvent on routing point where you finally get 0008 error to this error itself?

Here an extract searching for specific ConnID. Tell me if I should provide deeper logs.

http://web.tiscali.it/modifiche/case_001.7z

Looks like error 0008 happen on attempt route call from inside strategy activated by OnCallAbandon, in other words after EventAbandoned was
received for the call. As far as I know after EventAbandoned most (though not all) of functions which might send request to tservers (those that route call including) raise errors if called.

It seems I can end the call using an event generaction function, reject type.